commit b883bf3d0b58e9584a0b080bb6ea4d1206cef11f
parent 836f41df677921b1d8f0c395fe470d2fa32b029a
Author: Martin Schanzenbach <schanzen@gnunet.org>
Date: Mon, 3 Jan 2022 18:38:38 +0100
indent
Diffstat:
1 file changed, 210 insertions(+), 210 deletions(-)
diff --git a/draft-schanzen-r5n.xml b/draft-schanzen-r5n.xml
@@ -1143,225 +1143,225 @@ Connectivity | |Underlay| |Underlay|
Applications can and should define their own block types.
The block type determines the format and handling of the block
payload by nodes in PUT and RESULT messages.
- Block types MUST be registered with GANA <xref target="gana"/>.
+ Block types MUST be registered with GANA <xref target="gana"/>.
+ </t>
+ <t>
+ For bootstrapping and node discovery, the DHT implementation uses
+ its own block type called "HELLO". A block with this block type
+ contains the NodeID of the node initiating the GET request.
+ </t>
+ <section anchor="hello_block">
+ <name>HELLO</name>
+ <t>
+ The HELLO block type wire format is illustrated in
+ <xref target="figure_hello"/>. A query for block of type HELLO MUST
+ NOT include extended query data (XQuery). Any implementation
+ encountering a HELLO block with XQuery data MUST consider the
+ block invalid and ignore it.
+ </t>
+ <figure anchor="figure_hello">
+ <artwork name="" type="" align="left" alt=""><![CDATA[
+0 8 16 24 32 40 48 56
++---+-----+-----+-----+-----+-----+-----+-----+
+| TYPE | SIZE | NODEID /
++---+-----+-----+-----+ (variable length) /
+/ /
++---+-----+-----+-----+-----+-----+-----+-----+
+| ADDRESSES /
+/ (variable length) |
++---+-----+-----+-----+-----+-----+-----+-----+
+]]/artwork>
+ </figure>
+ <dl>
+ <dt>TYPE</dt>
+ <dd>
+ is the type of HELLO. A 16-bit number in network byte order.
+ This value determines the type of the NODEID field.
+ </dd>
+ <dt>SIZE</dt>
+ <dd>
+ is the SIZE of the following fields NODEID and ADDRESSES in bytes.
+ In network byte order.
+ </dd>
+ <dt>NODEID</dt>
+ <dd>
+ is the Node ID of the node which has generated this HELLO.
+ The length content of this field is determined by the TYPE.
+ Usually, this is a cryptographic public key which allows the
+ Underlay to uniquely identify and authenticate the node.
+ </dd>
+ <dt>ADDRESSES</dt>
+ <dd>
+ is a list of UTF-8 strings <xref target="RFC3629"/> which can be
+ used as addresses to contact the node.
+ The strings MUST be 0-terminated.
+ FIXME: Examples? Format determined?
+ </dd>
+ </dl>
+ <t>
+ A HELLO reply block MAY be empty. Otherwise, it contains the
+ HELLO of a node.
</t>
<t>
- For bootstrapping and node discovery, the DHT implementation uses
- its own block type called "HELLO". A block with this block type
- contains the NodeID of the node initiating the GET request.
+ For the string representation of the node public key,
+ the base-32 encoding "StringEncode" is used.
+ However, instead of following <xref target="RFC4648"/> the
+ character map is based on the optical character recognition friendly
+ proposal of Crockford <xref target="CrockfordB32"/>.
+ The only difference to Crockford is that the letter
+ "U" decodes to the same base-32 value as the letter "V" (27).
</t>
- <section anchor="hello_block">
- <name>HELLO</name>
- <t>
- The HELLO block type wire format is illustrated in
- <xref target="figure_hello"/>. A query for block of type HELLO MUST
- NOT include extended query data (XQuery). Any implementation
- encountering a HELLO block with XQuery data MUST consider the
- block invalid and ignore it.
- </t>
- <figure anchor="figure_hello">
- <artwork name="" type="" align="left" alt=""><![CDATA[
-0 8 16 24 32 40 48 56
-+-----+-----+-----+-----+-----+-----+-----+-----+
-| TYPE | SIZE | NODEID /
-+-----+-----+-----+-----+ (variable length) /
-/ /
-+-----+-----+-----+-----+-----+-----+-----+-----+
-| ADDRESSES /
-/ (variable length) |
-+-----+-----+-----+-----+-----+-----+-----+-----+
-]]></artwork>
- </figure>
- <dl>
- <dt>TYPE</dt>
- <dd>
- is the type of HELLO. A 16-bit number in network byte order.
- This value determines the type of the NODEID field.
- </dd>
- <dt>SIZE</dt>
- <dd>
- is the SIZE of the following fields NODEID and ADDRESSES in bytes.
- In network byte order.
- </dd>
- <dt>NODEID</dt>
- <dd>
- is the Node ID of the node which has generated this HELLO.
- The length content of this field is determined by the TYPE.
- Usually, this is a cryptographic public key which allows the
- Underlay to uniquely identify and authenticate the node.
- </dd>
- <dt>ADDRESSES</dt>
- <dd>
- is a list of UTF-8 strings <xref target="RFC3629"/> which can be
- used as addresses to contact the node.
- The strings MUST be 0-terminated.
- FIXME: Examples? Format determined?
- </dd>
- </dl>
- <t>
- A HELLO reply block MAY be empty. Otherwise, it contains the
- HELLO of a node.
- </t>
- <t>
- For the string representation of the node public key,
- the base-32 encoding "StringEncode" is used.
- However, instead of following <xref target="RFC4648"/> the
- character map is based on the optical character recognition friendly
- proposal of Crockford <xref target="CrockfordB32"/>.
- The only difference to Crockford is that the letter
- "U" decodes to the same base-32 value as the letter "V" (27).
- </t>
- <t>
- The <tt>ADDRESSES</tt> part of the <tt>HELLO</tt> indicate endpoints
- which can be used by the Underlay in order to establish a connection
- with the node identified by <tt>NODEKEY</tt>.
- An example of an addressing scheme used throughout
- this document is "ip+tcp", which refers to a standard TCP/IP socket
- connection. The "hier"-part of the URI must provide a suitable
- address for the given addressing scheme.
- The following is a non-normative example of address strings:
- </t>
- <figure>
- <artwork name="" type="" align="left" alt=""><![CDATA[
-ip+tcp://1.2.3.4:6789 \
-gnunet+tcp://12.3.4.5/ \
-i2p+udp://1.2.4.5:424/ \
-tor+onionv3://rasdflkjasdfliasduf.onion/
-]]></artwork>
- </figure>
- </section>
+ <t>
+ The <tt>ADDRESSES</tt> part of the <tt>HELLO</tt> indicate endpoints
+ which can be used by the Underlay in order to establish a connection
+ with the node identified by <tt>NODEKEY</tt>.
+ An example of an addressing scheme used throughout
+ this document is "ip+tcp", which refers to a standard TCP/IP socket
+ connection. The "hier"-part of the URI must provide a suitable
+ address for the given addressing scheme.
+ The following is a non-normative example of address strings:
+ </t>
+ <figure>
+ <artwork name="" type="" align="left" alt=""><![CDATA[
+ipcp://1.2.3.4:6789 \
+gnet+tcp://12.3.4.5/ \
+i2udp://1.2.4.5:424/ \
+toonionv3://rasdflkjasdfliasduf.onion/
+]]/artwork>
+ </figure>
</section>
</section>
- <section anchor="security" numbered="true" toc="default">
- <name>Security Considerations</name>
- <!-- FIXME: Here we should (again) discuss how the system is open and
- does not have/require a trust anchor a priori. This is (again) in contrast
- to RELOAD -->
- </section>
- <section anchor="gana" numbered="true" toc="default">
- <name>GANA Considerations</name>
- <t>
- GANA <xref target="GANA"/>
- is requested to create a "DHT Block Types" registry.
- The registry shall record for each entry:
- </t>
- <ul>
- <li>Name: The name of the block type (case-insensitive ASCII
- string, restricted to alphanumeric characters</li>
- <li>Number: 32-bit</li>
- <li>Comment: Optionally, a brief English text describing the purpose of
- the block type (in UTF-8)</li>
- <li>Contact: Optionally, the contact information of a person to contact for
- further information</li>
- <li>References: Optionally, references describing the record type
- (such as an RFC)</li>
- </ul>
- <t>
- The registration policy for this sub-registry is "First Come First
- Served", as described in <xref target="RFC8126"/>.
- GANA is requested to populate this registry as follows:
- </t>
- <figure anchor="figure_btypenums">
- <artwork name="" type="" align="left" alt=""><![CDATA[
-Number | Name | Contact | References | Description
--------+--------+---------+------------+-------------------------
-0 ANY N/A [This.I-D] Reserved
-7 HELLO N/A [This.I-D] Type of a block that contains
-a HELLO for a node
-11 GNS N/A GNS Block for storing record data
-]]></artwork>
- </figure>
- <t>
- GANA is requested to amend the "GNUnet Signature Purpose" registry
- as follows:
- </t>
- <figure anchor="figure_purposenums">
- <artwork name="" type="" align="left" alt=""><![CDATA[
-Purpose | Name | References | Description
---------+-----------------+------------+--------------------------
-]]></artwork>
- </figure>
- </section>
- <!-- gana -->
- <section>
- <name>Test Vectors</name>
- </section>
- </middle>
- <back>
- <references><name>Normative References</name>
+ </section>
+ <section anchor="security" numbered="true" toc="default">
+ <name>Security Considerations</name>
+ <!-- FIXME: Here we should (again) discuss how the system is open and
+ does not have/require a trust anchor a priori. This is (again) in contrast
+ to RELOAD -->
+ </section>
+ <section anchor="gana" numbered="true" toc="default">
+ <name>GANA Considerations</name>
+ <t>
+ GANA <xref target="GANA"/>
+ is requested to create a "DHT Block Types" registry.
+ The registry shall record for each entry:
+ </t>
+ <ul>
+ <li>Name: The name of the block type (case-insensitive ASCII
+ string, restricted to alphanumeric characters</li>
+ <li>Number: 32-bit</li>
+ <li>Comment: Optionally, a brief English text describing the purpose of
+ the block type (in UTF-8)</li>
+ <li>Contact: Optionally, the contact information of a person to contact for
+ further information</li>
+ <li>References: Optionally, references describing the record type
+ (such as an RFC)</li>
+ </ul>
+ <t>
+ The registration policy for this sub-registry is "First Come First
+ Served", as described in <xref target="RFC8126"/>.
+ GANA is requested to populate this registry as follows:
+ </t>
+ <figure anchor="figure_btypenums">
+ <artwork name="" type="" align="left" alt=""><![CDATA[
+Nuer | Name | Contact | References | Description
+-----+--------+---------+------------+-------------------------
+0 ANY N/A [This.I-D] Reserved
+7 HELLO N/A [This.I-D] Type of a block that contains
+a LLO for a node
+11 GNS N/A GNS Block for storing record data
+]]/artwork>
+ </figure>
+ <t>
+ GANA is requested to amend the "GNUnet Signature Purpose" registry
+ as follows:
+ </t>
+ <figure anchor="figure_purposenums">
+ <artwork name="" type="" align="left" alt=""><![CDATA[
+Puose | Name | References | Description
+------+-----------------+------------+--------------------------
+]]/artwork>
+ </figure>
+ </section>
+ <!-- gana -->
+ <section>
+ <name>Test Vectors</name>
+ </section>
+ </middle>
+ <back>
+ <references><name>Normative References</name>
- &RFC2119;
- &RFC3629;
- &RFC4634;
- &RFC4648;
- &RFC6940;
- &RFC8126;
- &RFC8174;
+ &RFC2119;
+ &RFC3629;
+ &RFC4634;
+ &RFC4648;
+ &RFC6940;
+ &RFC8126;
+ &RFC8174;
- <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>
+ <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>
- <reference anchor="CrockfordB32" target="https://www.crockford.com/base32.html"><front><title>Base32</title><author initials="D." surname="Douglas" fullname="Crockford">
- </author><date year="2019" month="March"/></front></reference>
+ <reference anchor="CrockfordB32" target="https://www.crockford.com/base32.html"><front><title>Base32</title><author initials="D." surname="Douglas" fullname="Crockford">
+ </author><date year="2019" month="March"/></front></reference>
- <reference anchor="GANA" target="https://gana.gnunet.org/"><front><title>GNUnet Assigned Numbers Authority (GANA)</title><author><organization>GNUnet e.V.</organization></author><date month="April" year="2020"/></front></reference>
+ <reference anchor="GANA" target="https://gana.gnunet.org/"><front><title>GNUnet Assigned Numbers Authority (GANA)</title><author><organization>GNUnet e.V.</organization></author><date month="April" year="2020"/></front></reference>
- </references>
- <references>
- <name>Informative References</name>
- <reference anchor="R5N" target="https://doi.org/10.1109/ICNSS.2011.6060022">
- <front>
- <title>R5N: Randomized recursive routing for restricted-route networks</title>
- <author initials="N. S." surname="Evans" fullname="Nathan S. Evans">
- <organization>Technische Universität München</organization>
- </author>
- <author initials="C." surname="Grothoff" fullname="Christian Grothoff">
- <organization>Technische Universität München</organization>
- </author>
- <date year="2011"/>
- </front>
- </reference>
- <reference anchor="Kademlia" target="http://css.csail.mit.edu/6.824/2014/papers/kademlia.pdf">
- <front>
- <title>Kademlia: A peer-to-peer information system based on the xor metric.</title>
- <author initials="P." surname="Maymounkov" fullname="Petar Maymounkov">
- </author>
- <author initials="D." surname="Mazieres" fullname="David Mazieres">
- </author>
- <date year="2002"/>
- </front>
- </reference>
- <reference anchor="cadet" target="https://doi.org/10.1109/MedHocNet.2014.6849107">
- <front>
- <title>CADET: Confidential ad-hoc decentralized end-to-end transport</title>
- <author initials="B." surname="Polot" fullname="Bartlomiej Polot">
- <organization>Technische Universität München</organization>
- </author>
- <author initials="C." surname="Grothoff" fullname="Christian Grothoff">
- <organization>Technische Universität München</organization>
- </author>
- <date year="2014"/>
- </front>
- </reference>
- <reference anchor="I-D.draft-schanzen-gns" target="https://datatracker.ietf.org/doc/draft-schanzen-gns/">
- <front>
- <title>The GNU Name System</title>
- <author initials="M." surname="Schanzenbach" fullname="Martin Schanzenbach">
- <organization>GNUnet e.V.</organization>
- </author>
- <author initials="C." surname="Grothoff" fullname="Christian Grothoff">
- <organization>GNUnet e.V.</organization>
- </author>
- <author initials="B." surname="Fix" fullname="Bernd Fix">
- <organization>GNUnet e.V.</organization>
- </author>
- <date year="2021"/>
- </front>
- </reference>
- </references>
- <!-- Change Log
- v00 2017-07-23 MS Initial version
- -->
- </back>
- </rfc>
+ </references>
+ <references>
+ <name>Informative References</name>
+ <reference anchor="R5N" target="https://doi.org/10.1109/ICNSS.2011.6060022">
+ <front>
+ <title>R5N: Randomized recursive routing for restricted-route networks</title>
+ <author initials="N. S." surname="Evans" fullname="Nathan S. Evans">
+ <organization>Technische Universität München</organization>
+ </author>
+ <author initials="C." surname="Grothoff" fullname="Christian Grothoff">
+ <organization>Technische Universität München</organization>
+ </author>
+ <date year="2011"/>
+ </front>
+ </reference>
+ <reference anchor="Kademlia" target="http://css.csail.mit.edu/6.824/2014/papers/kademlia.pdf">
+ <front>
+ <title>Kademlia: A peer-to-peer information system based on the xor metric.</title>
+ <author initials="P." surname="Maymounkov" fullname="Petar Maymounkov">
+ </author>
+ <author initials="D." surname="Mazieres" fullname="David Mazieres">
+ </author>
+ <date year="2002"/>
+ </front>
+ </reference>
+ <reference anchor="cadet" target="https://doi.org/10.1109/MedHocNet.2014.6849107">
+ <front>
+ <title>CADET: Confidential ad-hoc decentralized end-to-end transport</title>
+ <author initials="B." surname="Polot" fullname="Bartlomiej Polot">
+ <organization>Technische Universität München</organization>
+ </author>
+ <author initials="C." surname="Grothoff" fullname="Christian Grothoff">
+ <organization>Technische Universität München</organization>
+ </author>
+ <date year="2014"/>
+ </front>
+ </reference>
+ <reference anchor="I-D.draft-schanzen-gns" target="https://datatracker.ietf.org/doc/draft-schanzen-gns/">
+ <front>
+ <title>The GNU Name System</title>
+ <author initials="M." surname="Schanzenbach" fullname="Martin Schanzenbach">
+ <organization>GNUnet e.V.</organization>
+ </author>
+ <author initials="C." surname="Grothoff" fullname="Christian Grothoff">
+ <organization>GNUnet e.V.</organization>
+ </author>
+ <author initials="B." surname="Fix" fullname="Bernd Fix">
+ <organization>GNUnet e.V.</organization>
+ </author>
+ <date year="2021"/>
+ </front>
+ </reference>
+ </references>
+ <!-- Change Log
+ v00 2017-07-23 MS Initial version
+ -->
+ </back>
+ </rfc>
