commit 143e86e92267f1324eeeeeaf0973831fa7e190ee
parent 128a1dbad6d2fa1677674784d2cfe77f5c2b2284
Author: Martin Schanzenbach <schanzen@gnunet.org>
Date: Sun, 25 Dec 2022 18:20:49 +0900
Remove bootstrap
Integrated bootstrap into peer discovery and appendix.
Questions on HelloMessage / SHOULD HELLO URLs...
Diffstat:
1 file changed, 114 insertions(+), 131 deletions(-)
diff --git a/draft-schanzen-r5n.xml b/draft-schanzen-r5n.xml
@@ -202,6 +202,18 @@
The peer that initially creates and sends a GetMessage (<xref target="p2p_get"/>) or
PutMessage message (<xref target="p2p_put"/>).
</dd>
+ <dt>HELLO block</dt>
+ <dd>
+ A HELLO block is a block with a dedicated block type and is specified in this document.
+ The HELLO block is used to store and retrieve Peer addresses.
+ In this document, HELLO blocks are used by the peer discovery mechanism.
+ </dd>
+ <dt>HELLO URL</dt>
+ <dd>
+ HELLO URLs are URL-formatted HELLO blocks.
+ They can used for out-of-band exchanges of peer information and are used for
+ address update signalling messages to neighbours.
+ </dd>
<dt>Key</dt>
<dd>
512-bit identifier of a location in the DHT. Multiple <tt>Block</tt>s can be
@@ -320,8 +332,8 @@
<t>
In order to establish an initial connection to a network of R<sup>5</sup>N
peers, an initial, addressable bootstrap peer is required.
- Further peers, including neighbors, are then learned via a bootstrapping
- process as defined in <xref target="bootstrapping"/>.
+ Further peers, including neighbors, are then learned via a peer discovery
+ process as defined in <xref target="find_peer"/>.
</t>
<t>
Across this document, the functional components of an R<sup>5</sup>N
@@ -519,133 +531,6 @@ Connectivity | |Underlay| |Underlay|
and message transmission.
</t>
</section>
- <section anchor="bootstrapping">
- <name>Bootstrapping</name>
- <t>
- Initially, the implementation depends upon either the Underlay providing at
- least one initial connection to a peer (signalled through
- <tt>PEER_CONNECTED</tt>), or the application/end-user providing at
- least one working HELLO to the DHT for bootstrapping.
- While details on how the first connection is established <bcp14>MAY</bcp14>
- depend on the specific implementation, this <bcp14>SHOULD</bcp14> usually be done
- by an out-of-band exchange of the information from a HELLO block.
- <!-- FIXME: Is this really an encoding of a block? It seems to me that "HELLO"
- is not properly defined. -->
- For this, section <xref target="hello_url"/> specifies a URL format for encoding HELLO
- blocks as text strings which <bcp14>SHOULD</bcp14> be supported by implementations.
- </t>
- <t>
- Regardless of how the initial connections are established, the
- peers resulting from these initial connections
- are subsequently stored in the routing table component
- <xref target="routing_table"/>.
- </t>
- <t>
- Furthermore, the Underlay <bcp14>SHOULD</bcp14> provide the implementation with one or more
- addresses signalled through <tt>ADDRESS_ADDED</tt>. Zero addresses <bcp14>MAY</bcp14> be
- provided if a peer can only establish outgoing connections and is otherwise unreachable.
- <!-- FIXME: What about HelloMessages? What is the distinction between HELLO blocks
- and HELLO messages? -->
- The implementation periodically advertises all
- active addresses in a HELLO block <xref target="hello_block"/>.
- </t>
- <t>
- <!-- FIXME: Maybe make this a SHOULD and explain what happens if the implementation
- does not. We should allow a minimal implementation of the protocol. -->
- In order to fill its routing table by finding close peers in the network, an
- implementation <bcp14>MUST</bcp14> now periodically send peer discovery messages
- <xref target="find_peer"/>.
- </t>
- <t>
- The frequency of advertisement and peer discovery messages
- <bcp14>MAY</bcp14> be adapted according to network conditions,
- the set of already connected neighbors,
- the workload of the system and other factors which are at the discretion of
- the developer.
- </t>
- <t>
- <!-- FIXME: This whole section is a bit odd and I think we should breat it up
- into an overview and the below explanaton should be part of message
- processing -->
- Any implementation encountering a HELLO GET request <bcp14>MUST</bcp14> respond
- with its own HELLO block except if that block is
- filtered by the request's result filter (see <xref target="result_filter"/>).
- Implementations <bcp14>MAY</bcp14> respond
- with additional valid HELLO blocks of other peers with keys
- closest to the key of the GET request. A HELLO block is "valid"
- if it is non-expired and
- is not excluded by the result filter. "closest" is defined
- by considering the distances between the request's key and the
- peer addresses of all of the valid HELLO blocks known at the local node.
- </t>
- <section anchor="hello_url">
- <name>HELLO URLs</name>
- <t>
- The general format of a HELLO URL uses "gnunet://"
- as the scheme, followed by "hello/" for the name
- of the GNUnet subsystem, followed by "/"-separated values
- with the GNS Base32 encoding (<xref target="I-D.schanzen-gns"/>) of
- the <tt>Peer ID</tt>, a Base32-encoded EdDSA signature, and an expiration
- time in seconds since the UNIX Epoch in decimal format.
- After this a "?" begins a list of key-value pairs where the key
- is the URI scheme of one of the peer's addresses and the value
- is the URL-escaped payload of the address URI without the "://".
- </t>
- <t>
- For example, consider the following URL:
- </t>
- <figure>
- <artwork type="abnf"><![CDATA[
-gnunet://hello/RH1M20EPK834M6MHZ72\
-G3CMBSF3ECKNY4W0T9VAQP9Z7SZEM6Y3G/\
-NGRTAH6RA04X467CGCH7M7CEXR5F9CV5HT\
-ZFK0G9BWETY3CCE2QWGVT4WA7JN5M9HMWG\
-60A00R71F1PJP8N5628EKGHHBAGA7M8JW3\
-0/1647134480?udp=127.0.0.1%3A2086
-
-FIXME: signature is invalid, should
-maybe generate proper test vector.
-]]>
- </artwork>
- </figure>
- <t>
- It specifies that the peer with the ID "RH1M...6Y3G"
- is reachable via "udp" at 127.0.0.1 on port 2086 until
- 1647134480 seconds after the Epoch. Note that "udp"
- here is underspecified and just used as a simple example.
- <!-- FIXME: Must be supported by which underlay?
- This does not make sense. I may be able to generate
- addr-names that my underlay supports, but there is not
- way to guarantee that all underlays support it. -->
- In practice, the key (addr-name)
- <bcp14>MUST</bcp14> refer to a scheme supported by a
- DHT Underlay.
- </t>
- <t>
- The general syntax of HELLO URLs specified using
- Augmented Backus-Naur Form (ABNF) of <xref target="RFC5234"/> is:
- </t>
- <figure>
- <artwork type="abnf"><![CDATA[
-hello-URL = "gnunet://hello/" meta [ "?" addrs ]
-meta = pid "/" sig "/" exp
-pid = *bchar
-sig = *bchar
-exp = *DIGIT
-addrs = addr *( "&" addr )
-addr = addr-name "=" addr-value
-addr-name = scheme
-addr-value = *pchar
-bchar = *(ALPHA / DIGIT)
-]]>
- </artwork>
- </figure>
- <t>
- 'scheme' is defined in <xref target="RFC3986" /> in Section 3.1.
- 'pchar' is defined in <xref target="RFC3986" />, Appendix A.
- </t>
- </section>
- </section>
<section anchor="routing" numbered="true" toc="default">
<name>Routing</name>
<t>
@@ -689,6 +574,20 @@ bchar = *(ALPHA / DIGIT)
upper limit on the number of neighbors kept per k-bucket.
</t>
<t>
+ Initially, the implementation depends upon either the Underlay providing at
+ least one initial connection to a peer (signalled through
+ <tt>PEER_CONNECTED</tt>), or the application/end-user providing at
+ least one working HELLO to the DHT for bootstrapping.
+ While details on how the first connection is established <bcp14>MAY</bcp14>
+ depend on the specific implementation, this <bcp14>SHOULD</bcp14> usually be done
+ by an out-of-band exchange of the information from a HELLO block.
+ <!-- FIXME: Is this really an encoding of a block? It seems to me that "HELLO"
+ is not properly defined.
+ FIXME: Should? Isn't this part of the HelloMessage? -->
+ For this, section <xref target="hello_url"/> specifies a URL format for encoding HELLO
+ blocks as text strings which <bcp14>SHOULD</bcp14> be supported by implementations.
+ </t>
+ <t>
Implementations <bcp14>SHOULD</bcp14> try to keep at least
5 entries per k-bucket. Embedded systems that cannot manage
this number of connections <bcp14>MAY</bcp14> use connection-level
@@ -730,6 +629,22 @@ bchar = *(ALPHA / DIGIT)
Peer Discovery requests. Details about the format of the
HELLO message are given in <xref target="p2p_hello_wire"/>.
</t>
+ <t>
+ The frequency of advertisement and peer discovery messages
+ <bcp14>MAY</bcp14> be adapted according to network conditions,
+ the set of already connected neighbors,
+ the workload of the system and other factors which are at the discretion of
+ the developer.
+ </t>
+ <t>
+ Furthermore, the Underlay <bcp14>SHOULD</bcp14> provide the implementation with one or more
+ addresses signalled through <tt>ADDRESS_ADDED</tt>. Zero addresses <bcp14>MAY</bcp14> be
+ provided if a peer can only establish outgoing connections and is otherwise unreachable.
+ <!-- FIXME: What about HelloMessages? What is the distinction between HELLO blocks
+ and HELLO messages? -->
+ The implementation periodically advertises all
+ active addresses in a HELLO block <xref target="hello_block"/>.
+ </t>
</section>
<section anchor="routing_bloomfilter">
<name>Peer Bloom Filter</name>
@@ -1767,7 +1682,8 @@ BEGIN
<li>
If <tt>BTYPE</tt> indicates a request for a HELLO block or
<tt>ANY</tt>,
- the peer <bcp14>MUST</bcp14> consult the HELLOs it has cached for the
+ the peer <bcp14>MUST</bcp14> consult its own HELLO as well as
+ the HELLOs it has cached for the
peers in its routing table instead of the local block
storage (while continuing to respect flags like
<tt>DemultiplexEverywhere</tt>
@@ -3020,5 +2936,72 @@ Type | Name | References | Description
</t>
</section>
</section>
- </back>
+ <section anchor="hello_url">
+ <name>HELLO URLs</name>
+ <t>
+ The general format of a HELLO URL uses "gnunet://"
+ as the scheme, followed by "hello/" for the name
+ of the GNUnet subsystem, followed by "/"-separated values
+ with the GNS Base32 encoding (<xref target="I-D.schanzen-gns"/>) of
+ the <tt>Peer ID</tt>, a Base32-encoded EdDSA signature, and an expiration
+ time in seconds since the UNIX Epoch in decimal format.
+ After this a "?" begins a list of key-value pairs where the key
+ is the URI scheme of one of the peer's addresses and the value
+ is the URL-escaped payload of the address URI without the "://".
+ </t>
+ <t>
+ For example, consider the following URL:
+ </t>
+ <figure>
+ <artwork type="abnf"><![CDATA[
+gnunet://hello/RH1M20EPK834M6MHZ72\
+G3CMBSF3ECKNY4W0T9VAQP9Z7SZEM6Y3G/\
+NGRTAH6RA04X467CGCH7M7CEXR5F9CV5HT\
+ZFK0G9BWETY3CCE2QWGVT4WA7JN5M9HMWG\
+60A00R71F1PJP8N5628EKGHHBAGA7M8JW3\
+0/1647134480?udp=127.0.0.1%3A2086
+
+FIXME: signature is invalid, should
+maybe generate proper test vector.
+]]>
+ </artwork>
+ </figure>
+ <t>
+ It specifies that the peer with the ID "RH1M...6Y3G"
+ is reachable via "udp" at 127.0.0.1 on port 2086 until
+ 1647134480 seconds after the Epoch. Note that "udp"
+ here is underspecified and just used as a simple example.
+ <!-- FIXME: Must be supported by which underlay?
+ This does not make sense. I may be able to generate
+ addr-names that my underlay supports, but there is not
+ way to guarantee that all underlays support it. -->
+ In practice, the key (addr-name)
+ <bcp14>MUST</bcp14> refer to a scheme supported by a
+ DHT Underlay.
+ </t>
+ <t>
+ The general syntax of HELLO URLs specified using
+ Augmented Backus-Naur Form (ABNF) of <xref target="RFC5234"/> is:
+ </t>
+ <figure>
+ <artwork type="abnf"><![CDATA[
+hello-URL = "gnunet://hello/" meta [ "?" addrs ]
+meta = pid "/" sig "/" exp
+pid = *bchar
+sig = *bchar
+exp = *DIGIT
+addrs = addr *( "&" addr )
+addr = addr-name "=" addr-value
+addr-name = scheme
+addr-value = *pchar
+bchar = *(ALPHA / DIGIT)
+]]>
+ </artwork>
+ </figure>
+ <t>
+ 'scheme' is defined in <xref target="RFC3986" /> in Section 3.1.
+ 'pchar' is defined in <xref target="RFC3986" />, Appendix A.
+ </t>
+ </section>
+ </back>
</rfc>
