commit 381092687c61438e1654dd5950f9102451e94712
parent 33b669e084d8800e80246c54a3a98505e82876db
Author: Martin Schanzenbach <schanzen@gnunet.org>
Date: Sat, 17 Feb 2024 10:03:47 +0100
Add RFC9498; Remove URI requirement from underlay address
Diffstat:
1 file changed, 44 insertions(+), 49 deletions(-)
diff --git a/draft-schanzen-r5n.xml b/draft-schanzen-r5n.xml
@@ -20,7 +20,7 @@
<!ENTITY RFC8126 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8126.xml">
<!ENTITY RFC8174 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8174.xml">
<!ENTITY RFC8324 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8324.xml">
-<!ENTITY I-D.schanzen-gns PUBLIC '' "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.schanzen-gns.xml">
+<!ENTITY RFC9498 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.9498.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc strict="yes" ?>
@@ -82,7 +82,7 @@
and data structure for decentralized applications.
It features an open peer-to-peer overlay routing mechanism which supports ad-hoc
permissionless participation and support for topologies in restricted-route
- environments. If desired, the paths data takes through the overlay can be
+ environments. Optionally, the paths data takes through the overlay can be
recorded, allowing decentralized applications to use the DHT to discover routes.
</t>
<t>
@@ -148,35 +148,25 @@
<dt>Address</dt>
<dd>
<t>
- is a UTF-8 <xref target="RFC3629"/> URI
- <xref target="RFC3986"/> which can be
- used to contact a <em>peer</em>.
- In this document we use the example scheme for URIs.
- It is expected that schemes refer suitable transport protocols
- are used.
- The "hier"-part of the URI must provide a suitable
- address for the given addressing scheme.
- The following are non-normative examples of <em>address</em> strings:
+ An <em>Address</em> is a UTF-8 <xref target="RFC3629"/> string which can be
+ used to address a <em>peer</em> through the Underlay (<xref target="underlay"/>).
+ The format of an address is not enforced by this specification,
+ but it is expected that in most cases the address is a URI <xref target="RFC3986"/>.
</t>
- <figure title="Example Address URIs.">
- <artwork name="" type="" align="left" alt=""><![CDATA[
-example://1.2.3.4:6789/
-example://12.3.4.5/
-]]></artwork>
- </figure>
</dd>
<dt>Applications</dt>
<dd>
- <em>Applications</em> are higher-layer components which directly use the DHT overlay
- interfaces. Possible <em>applications</em> include the GNU Name System
- <xref target="I-D.schanzen-gns"/> and the GNUnet
+ <em>Applications</em> are higher-layer components which directly use the
+ <em>Core Operations</em>.
+ Possible <em>applications</em> include the GNU Name System
+ <xref target="RFC9498"/> and the GNUnet
Confidential Ad-hoc Decentralized End-to-End Transport (CADET)
<xref target="cadet"/>.
</dd>
- <dt>Application API</dt>
+ <dt>Core Operations</dt>
<dd>
- The <em>application API</em> exposes the core operations of the DHT overlay
- to <em>applications</em>.
+ The <em>Core Operations</em> provide an interface to the
+ core operations of the DHT overlay to <em>applications</em>.
This includes storing <em>blocks</em> in the DHT and retrieving
<em>blocks</em> from the DHT.
</dd>
@@ -202,10 +192,9 @@ example://12.3.4.5/
</dd>
<dt>Bootstrapping</dt>
<dd>
- <em>Bootstrapping</em> is the initial process of establishing a connection
- to the peer-to-peer
- network.
- This initially requires an initial, non-empty set of reachable <em>peers</em> and corresponding
+ <em>Bootstrapping</em> is the process of establishing a connection
+ to the peer-to-peer network.
+ It requires an initial, non-empty set of reachable <em>peers</em> and corresponding
<em>addresses</em> supported by the implementation to connect to.
</dd>
<dt>Initiator</dt>
@@ -217,15 +206,14 @@ example://12.3.4.5/
<dd>
A <tt>HELLO block</tt> is a <em>block</em> with a <em>block-type</em> <tt>DHT_HELLO</tt> (13).
A <tt>HELLO block</tt> is used to store and retrieve <em>addresses</em> of a <em>peer</em>.
- In this document, <tt>HELLO</tt> blocks are used by the peer discovery mechanism.
+ <tt>HELLO</tt> blocks are used by the peer discovery mechanism in <xref target="find_peer"/>.
</dd>
<dt>HELLO URL</dt>
<dd>
<tt>HELLO</tt> URLs are <tt>HELLO</tt> blocks represented as URLs.
- They can used for out-of-band exchanges of <em>peer</em> <em>address</em>
- information and are used for
- address update signalling messages to <em>neighbours</em>. Example HELLO URLs and their
- format can be found in <xref target="hello_url"/>.
+ They are used for out-of-band exchanges of <em>peer</em> <em>addresses</em>
+ and for signalling address updates to <em>neighbours</em>.
+ Implementation details of HELLO URLs and examples are found in <xref target="hello_url"/>.
</dd>
<dt>Key</dt>
<dd>
@@ -272,7 +260,7 @@ example://12.3.4.5/
</dd>
<dt>Underlay Interface</dt>
<dd>
- The <em>inderlay interface</em> is an abstraction layer on top of the
+ The <em>underlay interface</em> is an abstraction layer on top of the
supported links of a <em>peer</em>. Peers may be linked by a variety of
different transports, including "classical" protocols such as
TCP, UDP and TLS or higher-layer protocols such as GNUnet, I2P or Tor.
@@ -294,8 +282,9 @@ example://12.3.4.5/
and is ineffective for some physical networks.
</t>
<t>
- For example, some nodes which in terms of a classical distance metric such as XOR
- are considered close, may not be reachable due to a firewall.
+ Nodes which in terms of a classical distance metric such as XOR
+ would be considered close may not be reachable, for example due to a firewall
+ or NAT.
This leads to multiple (local) minima with respect to where data may be
stored or where data can be retrieved.
From a particular fixed location in the network, a node may only be able to
@@ -321,9 +310,15 @@ example://12.3.4.5/
<xref target="RFC6940"/> specifies the RELOAD DHT. The R<sup>5</sup>N DHT
described in this document differs from RELOAD in its objectives
and thus in its design.
- In particular, <xref target="RFC6940"/> explicitly states that node identifier
- are either assigned by a central authority, or self-issued in the case of closed
- networks.
+ The authors of RELOAD make the case that P2P networks are often established
+ among a set of peers that do not trust each other.
+ It addresses this issue by requiring that node identifiers
+ are either assigned by a central authority, or self-issued in the case of closed networks.
+ In other words, by enforcing the P2P network to be established among a set
+ of <em>trusted</em> peers.
+ This misses the point that this openness is a core requirement of efficient and
+ useful DHTs as they serve a fundamental part in a decentralized network
+ infrastructure.
R<sup>5</sup>N, by contrast, is intended for open
overlay networks, and thus does not include a central enrollment server to
certify participants and does not limit participation in another way.
@@ -368,8 +363,8 @@ example://12.3.4.5/
<section>
<name>Overview</name>
<t>
- In R<sup>5</sup>N peers communicate with each other to provide
- the two fundamental operations of any distributed hash table:
+ In R<sup>5</sup>N peers provide
+ the two fundamental core operations of any DHT to their applications:
</t>
<ul>
<li>
@@ -459,7 +454,7 @@ example://12.3.4.5/
| +-----------------+ +-------+
Applications | | GNU Name System | | CADET | ...
| +-----------------+ +-------+
--------------+------------------------------------ Application API
+-------------+------------------------------------ Core Operations
| ^
| | +---------------+
| | | Block Storage |
@@ -487,15 +482,15 @@ Connectivity | |Underlay| |Underlay| | Underlay | ...
<t>
How peers are addressed in the underlay is out of scope of this document.
For example, a peer may have a TCP/IP address, or expose a QUIC endpoint.
- While the specific addressing options and mechanisms are out of scope
- for this document, it is necessary to define a universal addressing
+ While the specific addressing options and mechanisms are out of scope,
+ it is necessary to define a universal addressing
format in order to facilitate the distribution of <em>address</em>
information to other <em>peers</em> in the DHT overlay.
This standardized format is the <em>HELLO Block</em>
(described in <xref target="hello_block"/>),
- which contains sets of URIs.
- The scheme of each URI indicates which underlay understands the
- respective <em>address</em> details which are encoded in the rest of the URI.
+ which contains sets of addresses.
+ If the address is a URI, it may indicate which underlay understands the
+ respective <em>address</em> details.
</t>
<!--
1) The current API is always fire+forget, it doesn't allow for flow
@@ -2701,7 +2696,7 @@ BEGIN
control such as <xref target="RFC6940"/> which, like R<sup>5</sup>N, provides
a peer-to-peer (P2P) signaling protocol with extensible routing and topology
mechanisms.
- Some decentralized applications, such as the GNU Name System (<xref target="I-D.schanzen-gns"/>),
+ Some decentralized applications, such as the GNU Name System (<xref target="RFC9498"/>),
require an open system that enables ad-hoc participation.
</t>
</section>
@@ -2845,7 +2840,7 @@ Type | Name | References | Description
&RFC8126;
&RFC8174;
&RFC8324;
- &I-D.schanzen-gns;
+ &RFC9498;
<reference anchor="ed25519" target="http://link.springer.com/chapter/10.1007/978-3-642-23951-9_9"><front><title>High-Speed High-Security Signatures</title><author initials="D." surname="Bernstein" fullname="Daniel Bernstein"><organization>University of Illinois at Chicago</organization></author><author initials="N." surname="Duif" fullname="Niels Duif"><organization>Technische Universiteit Eindhoven</organization></author><author initials="T." surname="Lange" fullname="Tanja Lange"><organization>Technische Universiteit Eindhoven</organization></author><author initials="P." surname="Schwabe" fullname="Peter Schwabe"><organization>National Taiwan University</organization></author><author initials="B." surname="Yang" fullname="Bo-Yin Yang"><organization>Academia Sinica</organization></author><date year="2011"/></front></reference>
@@ -3113,7 +3108,7 @@ Type | Name | References | Description
The general format of a <tt>HELLO</tt> 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
+ with the GNS Base32 encoding (<xref target="RFC9498"/>) of
the peer public key, 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
