summaryrefslogtreecommitdiff
path: root/draft-schanzen-r5n.xml
diff options
context:
space:
mode:
Diffstat (limited to 'draft-schanzen-r5n.xml')
-rw-r--r--draft-schanzen-r5n.xml145
1 files changed, 143 insertions, 2 deletions
diff --git a/draft-schanzen-r5n.xml b/draft-schanzen-r5n.xml
index 317d784..92815ef 100644
--- a/draft-schanzen-r5n.xml
+++ b/draft-schanzen-r5n.xml
@@ -6,6 +6,7 @@
6<!ENTITY RFC3686 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3686.xml"> 6<!ENTITY RFC3686 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3686.xml">
7<!ENTITY RFC3826 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3826.xml"> 7<!ENTITY RFC3826 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3826.xml">
8<!ENTITY RFC3912 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3912.xml"> 8<!ENTITY RFC3912 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3912.xml">
9<!ENTITY RFC3986 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3986.xml">
9<!ENTITY RFC4648 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4648.xml"> 10<!ENTITY RFC4648 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4648.xml">
10<!ENTITY RFC5869 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5869.xml"> 11<!ENTITY RFC5869 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5869.xml">
11<!ENTITY RFC5890 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5890.xml"> 12<!ENTITY RFC5890 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5890.xml">
@@ -106,6 +107,102 @@
106 107
107 </t> 108 </t>
108 </section> 109 </section>
110 <section anchor="connectivity" numbered="true" toc="default">
111 <name>Connectivity and addressing</name>
112 <t>
113 In the DHT overlay, a peer is addressable by its Peer ID.
114 The Peer ID is the 256-bit hash of the peer public key.
115 The peer public key is the public key of the corresponding
116 Ed25519<xref target="ed25519" /> peer private key.
117 </t>
118 <t>
119 In the network underlay, a peer is addressable by traditional
120 means out of scope of this document. For example, the peer may
121 have a TCP/IP address, or a HTTPS endpoint.
122 While the specific addressing options and mechanisms are out of scope
123 for this document, it is necessary to define a universal addressing
124 format in order to facilitate the distribution of connectivity
125 information to other peers in the DHT overlay.
126 This format is the "HELLO" message. A "HELLO" is a human-readable
127 UTF-8 <xref target="RFC3629" /> string consisting of the peer
128 public key and the HELLO URI <xref target="RFC3986" />.
129 </t>
130 <figure>
131 <artwork name="" type="" align="left" alt=""><![CDATA[
132hello-format := <peer-public-key> <hello-uri>
133peer-public-key := [A-HJ-NP-Z1-9]+
134 ]]></artwork>
135 </figure>
136 <t>
137 For the string representation of the peer public key,
138 the base-32 encoding "StringEncode" is used.
139 However, instead of following <xref target="RFC4648"/> the
140 character map is based on the optical character recognition friendly
141 proposal of Crockford <xref target="CrockfordB32"/>.
142 The only difference to Crockford is that the letter
143 "U" decodes to the same base-32 value as the letter "V" (27).
144 </t>
145 <t>
146 The "scheme" part of the HELLO URI defined the addressing scheme
147 which is used. An example of an addressing scheme used throughout
148 this document is "ip+tcp", which refers to a standard TCP/IP socket
149 connection. The "hier"-part of the URI must provide a suitable
150 address for the given addressing scheme.
151 The following is a non-normative example of a HELLO containing three
152 HELLO URIs:
153 </t>
154 <figure>
155 <artwork name="" type="" align="left" alt=""><![CDATA[
156Y924NSHMMZ1N1SQCE5TXF93ED6S6JY311K0QT86G9WJC68F6XVZ0 \
157 ip+tcp://1.2.3.4:6789 \
158 gnunet+tcp://12.3.4.5/ \
159 i2p+udp://1.2.4.5:424/ \
160 tor+onionv3://rasdflkjasdfliasduf.onion/
161 ]]></artwork>
162 </figure>
163
164 <t>
165 It is expected that there are basic mechanisms available to
166 manage peer connectivity and addressing.
167 The required functionality are abstracted through the following
168 procedures and events:
169 </t>
170 <dl>
171 <dt>PEER_CONNECTIVITY_CHANGED</dt>
172 <dd>
173 is a signal that allows the DHT to react to peers which connect or
174 disconnect. Such an event triggers, for example, updates in the
175 routing table.
176 </dd>
177 <dt>CONNECT</dt>
178 <dd>
179 A function which allows a peer to attempt the establishment of
180 a connection to another peer using an address.
181 </dd>
182 <dt>RECEIVE</dt>
183 <dd>
184 A function or event that allows the peer to receive protocol
185 messages as defined in this document from a connected peer.
186 </dd>
187 <dt>SEND</dt>
188 <dd>
189 A function that allows a peer to send protocol messages as defined
190 in this document to a connected peer.
191 </dd>
192 <dt>NETWORK_SIZE_ESTIMATE</dt>
193 <dd>
194 A function or event that provides estimates on the network size
195 for use in the DHT routing algorithms.
196 </dd>
197 <dt>ADDRESS_CHANGED</dt>
198 <dd>
199 An event that allows the DHT to learn and react to address changes
200 of the peer. This information is used, for example, to publish
201 connectivity as part of the bootstrapping and overlay creation.
202 </dd>
203 </dl>
204 </section>
205
109 <section anchor="p2p_messages" numbered="true" toc="default"> 206 <section anchor="p2p_messages" numbered="true" toc="default">
110 <name>Peer-to-peer wire formats</name> 207 <name>Peer-to-peer wire formats</name>
111 <section anchor="p2p_bf" numbered="true" toc="default"> 208 <section anchor="p2p_bf" numbered="true" toc="default">
@@ -439,8 +536,52 @@ Purpose | Name | References | Description
439 <references> 536 <references>
440 <name>Normative References</name> 537 <name>Normative References</name>
441 538
442 &RFC2119; 539 &RFC2119;
443 &RFC8126; 540 &RFC3629;
541 &RFC3986;
542 &RFC4648;
543 &RFC8126;
544
545 <reference anchor="ed25519" target="http://link.springer.com/chapter/10.1007/978-3-642-23951-9_9">
546 <front>
547 <title>High-Speed High-Security Signatures</title>
548 <author initials="D." surname="Bernstein" fullname="Daniel Bernstein">
549 <organization>University of Illinois at Chicago</organization>
550 </author>
551
552 <author initials="N." surname="Duif"
553 fullname="Niels Duif">
554 <organization>Technische Universiteit Eindhoven</organization>
555
556 </author>
557 <author initials="T." surname="Lange"
558 fullname="Tanja Lange">
559 <organization>Technische Universiteit Eindhoven</organization>
560
561 </author>
562 <author initials="P." surname="Schwabe"
563 fullname="Peter Schwabe">
564 <organization>National Taiwan University</organization>
565
566 </author>
567 <author initials="B." surname="Yang"
568 fullname="Bo-Yin Yang">
569 <organization>Academia Sinica</organization>
570
571 </author>
572 <date year="2011"/>
573 </front>
574 </reference>
575
576 <reference anchor="CrockfordB32" target="https://www.crockford.com/base32.html">
577 <front>
578 <title>Base32</title>
579 <author initials="D." surname="Douglas" fullname="Crockford">
580 </author>
581
582 <date year="2019" month="March"/>
583 </front>
584 </reference>
444 585
445 <reference anchor="GANA" target="https://gana.gnunet.org/"> 586 <reference anchor="GANA" target="https://gana.gnunet.org/">
446 <front> 587 <front>