draft-ietf-dtn-ipn-update-09.txt | draft-ietf-dtn-ipn-update-13.txt | |||
---|---|---|---|---|
Delay/Disruption Tolerant Networking R. Taylor | Delay/Disruption Tolerant Networking R. Taylor | |||
Internet-Draft Ori Industries | Internet-Draft High Frontier Ltd | |||
Updates: [9171, 7116] (if approved) E. Birrane | Updates: [9171, 7116, 6260] (if approved) E. Birrane | |||
Intended status: Standards Track JHU/APL | Intended status: Standards Track JHU/APL | |||
Expires: 6 June 2024 4 December 2023 | Expires: 4 January 2025 3 July 2024 | |||
Update to the ipn URI scheme | Update to the ipn URI scheme | |||
draft-ietf-dtn-ipn-update-09 | draft-ietf-dtn-ipn-update-13 | |||
Abstract | Abstract | |||
This document updates both the specification of the ipn URI scheme | This document updates the specification of the ipn URI scheme | |||
previously defined in RFC 7116 and the rules for encoding of these | previously defined in RFC 6260, the IANA registries established in | |||
URIs when used as an Endpoint Identifier (EID) in Bundle Protocol | RFC 7116, and the rules for the encoding and decoding of these URIs | |||
Version 7 (BPv7) as defined in RFC 9171. These updates update and | when used as an Endpoint Identifier (EID) in Bundle Protocol Version | |||
clarify the structure and behavior of the ipn URI scheme, define | 7 (BPv7) as defined in RFC 9171. These updates clarify the structure | |||
encodings of ipn scheme URIs, and establish the registries necessary | and behavior of the ipn URI scheme, define new encodings of ipn | |||
to manage this scheme. | scheme URIs, and establish the registries necessary to manage this | |||
scheme. | ||||
About This Document | About This Document | |||
This note is to be removed before publishing as an RFC. | This note is to be removed before publishing as an RFC. | |||
The latest revision of this draft can be found at | The latest revision of this draft can be found at | |||
https://ricktaylor.github.io/ipn2/draft-taylor-dtn-ipn-update.html. | https://ricktaylor.github.io/ipn2/draft-taylor-dtn-ipn-update.html. | |||
Status information for this document may be found at | Status information for this document may be found at | |||
https://datatracker.ietf.org/doc/draft-ietf-dtn-ipn-update/. | https://datatracker.ietf.org/doc/draft-ietf-dtn-ipn-update/. | |||
skipping to change at page 2, line 10 ¶ | skipping to change at page 2, line 10 ¶ | |||
Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
Drafts is at https://datatracker.ietf.org/drafts/current/. | Drafts is at https://datatracker.ietf.org/drafts/current/. | |||
Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
This Internet-Draft will expire on 6 June 2024. | This Internet-Draft will expire on 4 January 2025. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2023 IETF Trust and the persons identified as the | Copyright (c) 2024 IETF Trust and the persons identified as the | |||
document authors. All rights reserved. | document authors. All rights reserved. | |||
This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
Provisions Relating to IETF Documents (https://trustee.ietf.org/ | Provisions Relating to IETF Documents (https://trustee.ietf.org/ | |||
license-info) in effect on the date of publication of this document. | license-info) in effect on the date of publication of this document. | |||
Please review these documents carefully, as they describe your rights | Please review these documents carefully, as they describe your rights | |||
and restrictions with respect to this document. Code Components | and restrictions with respect to this document. Code Components | |||
extracted from this document must include Revised BSD License text as | extracted from this document must include Revised BSD License text as | |||
described in Section 4.e of the Trust Legal Provisions and are | described in Section 4.e of the Trust Legal Provisions and are | |||
provided without warranty as described in the Revised BSD License. | provided without warranty as described in the Revised BSD License. | |||
Table of Contents | Table of Contents | |||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 | |||
2. Conventions and Definitions . . . . . . . . . . . . . . . . . 4 | 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 5 | |||
3. Core Concepts . . . . . . . . . . . . . . . . . . . . . . . . 5 | 3. Core Concepts . . . . . . . . . . . . . . . . . . . . . . . . 5 | |||
3.1. The Null ipn URI . . . . . . . . . . . . . . . . . . . . 5 | 3.1. The Null ipn URI . . . . . . . . . . . . . . . . . . . . 6 | |||
3.2. Allocator Identifiers . . . . . . . . . . . . . . . . . . 5 | 3.2. Allocator Identifiers . . . . . . . . . . . . . . . . . . 6 | |||
3.2.1. Allocator Identifier Ranges . . . . . . . . . . . . . 6 | 3.2.1. Allocator Identifier Ranges . . . . . . . . . . . . . 7 | |||
3.2.2. The Default Allocator . . . . . . . . . . . . . . . . 8 | 3.2.2. The Default Allocator . . . . . . . . . . . . . . . . 8 | |||
3.3. Node Numbers . . . . . . . . . . . . . . . . . . . . . . 8 | 3.3. Node Numbers . . . . . . . . . . . . . . . . . . . . . . 9 | |||
3.3.1. Fully-qualified Node Numbers . . . . . . . . . . . . 9 | 3.3.1. Fully-qualified Node Numbers . . . . . . . . . . . . 9 | |||
3.4. Special Node Numbers . . . . . . . . . . . . . . . . . . 9 | 3.4. Special Node Numbers . . . . . . . . . . . . . . . . . . 9 | |||
3.4.1. The Zero Node Number . . . . . . . . . . . . . . . . 9 | 3.4.1. The Zero Node Number . . . . . . . . . . . . . . . . 10 | |||
3.4.2. LocalNode ipn URIs . . . . . . . . . . . . . . . . . 9 | 3.4.2. LocalNode ipn URIs . . . . . . . . . . . . . . . . . 10 | |||
3.4.3. Private Use Node Numbers . . . . . . . . . . . . . . 10 | 3.4.3. Private Use Node Numbers . . . . . . . . . . . . . . 10 | |||
3.5. Service Numbers . . . . . . . . . . . . . . . . . . . . . 10 | 3.5. Service Numbers . . . . . . . . . . . . . . . . . . . . . 10 | |||
4. Textual Encoding of ipn URIs . . . . . . . . . . . . . . . . 10 | 4. Textual Representation of ipn URIs . . . . . . . . . . . . . 11 | |||
5. Usage of ipn URIs with BPv7 . . . . . . . . . . . . . . . . . 11 | 4.1. ipn URI Scheme Text Syntax . . . . . . . . . . . . . . . 11 | |||
5.1. Uniqueness Constraints . . . . . . . . . . . . . . . . . 11 | 5. Usage of ipn URIs with BPv7 . . . . . . . . . . . . . . . . . 12 | |||
5.2. The Null Endpoint . . . . . . . . . . . . . . . . . . . . 11 | 5.1. Uniqueness Constraints . . . . . . . . . . . . . . . . . 12 | |||
5.3. BPv7 Node ID . . . . . . . . . . . . . . . . . . . . . . 12 | 5.2. The Null Endpoint . . . . . . . . . . . . . . . . . . . . 13 | |||
5.4. LocalNode ipn EIDs . . . . . . . . . . . . . . . . . . . 12 | 5.3. BPv7 Node ID . . . . . . . . . . . . . . . . . . . . . . 13 | |||
5.5. Private Use Endpoints . . . . . . . . . . . . . . . . . . 12 | 5.4. LocalNode ipn EIDs . . . . . . . . . . . . . . . . . . . 13 | |||
5.6. Well-known Service Numbers . . . . . . . . . . . . . . . 12 | 5.5. Private Use ipn EIDs . . . . . . . . . . . . . . . . . . 14 | |||
5.7. Administrative Endpoints . . . . . . . . . . . . . . . . 13 | 5.6. Well-known Service Numbers . . . . . . . . . . . . . . . 14 | |||
6. Encoding ipn URIs with BPv7 . . . . . . . . . . . . . . . . . 13 | 5.7. Administrative Endpoints . . . . . . . . . . . . . . . . 15 | |||
6.1. ipn EID CBOR Encoding . . . . . . . . . . . . . . . . . . 13 | 6. CBOR representation of ipn URIs with BPv7 . . . . . . . . . . 15 | |||
6.1.1. Two-Element Scheme-Specific Encoding . . . . . . . . 14 | 6.1. ipn EID CBOR Encoding . . . . . . . . . . . . . . . . . . 15 | |||
6.1.2. Three-Element Scheme-Specific Encoding . . . . . . . 15 | 6.1.1. Two-Element Scheme-Specific Encoding . . . . . . . . 16 | |||
6.2. ipn EID CBOR Decoding . . . . . . . . . . . . . . . . . . 15 | 6.1.2. Three-Element Scheme-Specific Encoding . . . . . . . 16 | |||
6.3. ipn EID Matching . . . . . . . . . . . . . . . . . . . . 16 | 6.2. ipn EID CBOR Decoding . . . . . . . . . . . . . . . . . . 17 | |||
7. Special Considerations . . . . . . . . . . . . . . . . . . . 16 | 6.3. ipn URI Scheme CBOR syntax . . . . . . . . . . . . . . . 18 | |||
7.1. Scheme Compatibility . . . . . . . . . . . . . . . . . . 16 | 6.4. ipn EID Matching . . . . . . . . . . . . . . . . . . . . 18 | |||
7.2. Late Binding . . . . . . . . . . . . . . . . . . . . . . 17 | 7. Special Considerations . . . . . . . . . . . . . . . . . . . 19 | |||
8. Security Considerations . . . . . . . . . . . . . . . . . . . 17 | 7.1. Scheme Compatibility . . . . . . . . . . . . . . . . . . 19 | |||
8.1. Reliability and consistency . . . . . . . . . . . . . . . 17 | 7.2. CBOR Representation Interoperability . . . . . . . . . . 19 | |||
8.2. Malicious construction . . . . . . . . . . . . . . . . . 17 | 7.3. Text Representation Compatibility . . . . . . . . . . . . 20 | |||
8.3. Back-end transcoding . . . . . . . . . . . . . . . . . . 18 | 7.4. Bundle Protocol Version 6 Compatibility . . . . . . . . . 21 | |||
8.4. Rare IP address formats . . . . . . . . . . . . . . . . . 18 | 7.5. Late Binding . . . . . . . . . . . . . . . . . . . . . . 21 | |||
8.5. Sensitive information . . . . . . . . . . . . . . . . . . 18 | 8. Security Considerations . . . . . . . . . . . . . . . . . . . 21 | |||
8.6. Semantic attacks . . . . . . . . . . . . . . . . . . . . 18 | 8.1. Reliability and consistency . . . . . . . . . . . . . . . 21 | |||
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 | 8.2. Malicious construction . . . . . . . . . . . . . . . . . 22 | |||
9.1. 'ipn' Scheme URI Allocator Identifiers registry . . . . . 18 | 8.3. Back-end transcoding . . . . . . . . . . . . . . . . . . 22 | |||
9.1.1. Guidance for Designated Experts . . . . . . . . . . . 20 | 8.4. Local and Private Use ipn EIDs . . . . . . . . . . . . . 22 | |||
8.5. Sensitive information . . . . . . . . . . . . . . . . . . 22 | ||||
8.6. Semantic attacks . . . . . . . . . . . . . . . . . . . . 22 | ||||
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 | ||||
9.1. 'ipn' Scheme URI Allocator Identifiers registry . . . . . 23 | ||||
9.1.1. Guidance for Designated Experts . . . . . . . . . . . 24 | ||||
9.2. 'ipn' Scheme URI Default Allocator Node Numbers | 9.2. 'ipn' Scheme URI Default Allocator Node Numbers | |||
registry . . . . . . . . . . . . . . . . . . . . . . . . 20 | registry . . . . . . . . . . . . . . . . . . . . . . . . 24 | |||
9.3. 'ipn' Scheme URI Well-known Service Numbers for BPv7 | 9.3. 'ipn' Scheme URI Well-known Service Numbers for BPv7 | |||
registry . . . . . . . . . . . . . . . . . . . . . . . . 21 | registry . . . . . . . . . . . . . . . . . . . . . . . . 25 | |||
9.3.1. Guidance for Designated Experts . . . . . . . . . . . 23 | 9.3.1. Guidance for Designated Experts . . . . . . . . . . . 26 | |||
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 | 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 | |||
10.1. Normative References . . . . . . . . . . . . . . . . . . 23 | 10.1. Normative References . . . . . . . . . . . . . . . . . . 27 | |||
10.2. Informative References . . . . . . . . . . . . . . . . . 24 | 10.2. Informative References . . . . . . . . . . . . . . . . . 28 | |||
Appendix A. ipn URI Scheme Text Syntax . . . . . . . . . . . . . 24 | Appendix A. ipn URI Scheme Text Representation Examples . . . . 28 | |||
Appendix B. ipn URI Scheme Text Representation Examples . . . . 25 | A.1. Using the Default Allocator . . . . . . . . . . . . . . . 28 | |||
B.1. Using the Default Allocator . . . . . . . . . . . . . . . 25 | A.2. Using a non-default Allocator . . . . . . . . . . . . . . 29 | |||
B.2. Using a non-default Allocator . . . . . . . . . . . . . . 25 | A.3. The Null ipn URI . . . . . . . . . . . . . . . . . . . . 29 | |||
B.3. The Null ipn URI . . . . . . . . . . . . . . . . . . . . 25 | A.4. A LocalNode ipn URI . . . . . . . . . . . . . . . . . . . 29 | |||
B.4. A LocalNode ipn URI . . . . . . . . . . . . . . . . . . . 26 | Appendix B. ipn URI Scheme CBOR Encoding Examples . . . . . . . 29 | |||
Appendix C. ipn URI Scheme CBOR Encoding . . . . . . . . . . . . 26 | B.1. Using the Default Allocator . . . . . . . . . . . . . . . 29 | |||
Appendix D. ipn URI Scheme CBOR Encoding Examples . . . . . . . 26 | B.2. Using a non-default Allocator . . . . . . . . . . . . . . 30 | |||
D.1. Using the Default Allocator . . . . . . . . . . . . . . . 27 | B.3. The 'null' Endpoint . . . . . . . . . . . . . . . . . . . 30 | |||
D.2. Using a non-default Allocator . . . . . . . . . . . . . . 27 | Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 31 | |||
D.3. The 'null' Endpoint . . . . . . . . . . . . . . . . . . . 28 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 | |||
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 28 | ||||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 | ||||
1. Introduction | 1. Introduction | |||
The ipn URI scheme was originally defined in [RFC7116] as a way to | The ipn URI scheme was originally defined in [RFC6260] and [RFC7116] | |||
identify network nodes and node services using concisely-encoded | as a way to identify network nodes and node services using concisely- | |||
integers that can be processed faster and with fewer resources than | encoded integers that can be processed faster and with fewer | |||
other verbose identifier schemes. The scheme was designed for use | resources than other verbose identifier schemes. The scheme was | |||
with the experimental Bundle Protocol version 6 (BPv6, [RFC5050]) and | designed for use with the experimental Bundle Protocol version 6 | |||
IPN was defined as an acronym for the term "InterPlanetary Network" | (BPv6, [RFC5050]) and IPN was defined as an acronym for the term | |||
in reference to its intended use for deep-space networking. Since | "InterPlanetary Network" in reference to its intended use for deep- | |||
then, the efficiency benefit of integer identifiers makes ipn scheme | space networking. Since then, the efficiency benefit of integer | |||
URIs useful for any networks operating with limited power, bandwidth, | identifiers makes ipn scheme URIs useful for any networks operating | |||
and/or compute budget. Therefore the term IPN is now used as a non- | with limited power, bandwidth, and/or compute budget. Therefore, the | |||
acronymous name. | term IPN is now used as a non-acronymous name. | |||
Similar to the experimental BPv6, the standardized Bundle Protocol | Similar to the experimental BPv6, the standardized Bundle Protocol | |||
version 7 (BPv7, [RFC9171]) codifies support for the use of the ipn | version 7 (BPv7, [RFC9171]) codifies support for the use of the ipn | |||
URI scheme for the specification of bundle Endpoint Identifiers | URI scheme for the specification of bundle Endpoint Identifiers | |||
(EIDs). The publication of BPv7 has resulted in operational | (EIDs). The publication of BPv7 has resulted in operational | |||
deployments of BPv7 nodes for both terrestrial and non-terrestrial | deployments of BPv7 nodes for both terrestrial and non-terrestrial | |||
use cases. This includes BPv7 networks operating over the | use cases. This includes BPv7 networks operating over the | |||
terrestrial Internet and BPv7 networks operating in self-contained | terrestrial Internet and BPv7 networks operating in self-contained | |||
environments behind a shared administrative domain. The growth in | environments behind a shared administrative domain. The growth in | |||
the number and scale of deployments of BPv7 DTNs has been accompanied | the number and scale of deployments of BPv7 has been accompanied by a | |||
by a growth in the usage of the ipn URI scheme which has highlighted | growth in the usage of the ipn URI scheme which has highlighted areas | |||
areas to improve the structure, moderation, and management of this | to improve the structure, moderation, and management of this scheme. | |||
scheme. | ||||
This document updates the specification of the ipn URI scheme, in a | By updating [RFC7116] and [RFC9171], this document updates the | |||
backwards-compatible way, to provide needed improvements both in the | specification of the ipn URI scheme, in a backwards-compatible way, | |||
scheme itself and its usage to specify EIDs with BPv7. Specifically, | to provide needed improvements both in the scheme itself and its | |||
this document introduces a hierarchical structure for the assignment | usage to specify EIDs with BPv7. Specifically, this document | |||
of ipn scheme URIs, clarifies the behavior and interpretation of ipn | introduces a hierarchical structure for the assignment of ipn scheme | |||
scheme URIs, defines efficient encodings of ipn scheme URIs, and | URIs, clarifies the behavior and interpretation of ipn scheme URIs, | |||
updates/defines the registries associated for this scheme. | defines efficient encodings of ipn scheme URIs, and updates/defines | |||
the registries associated for this scheme. | ||||
Although originally developed by the deep space community for use | Although originally developed by the deep space community for use | |||
with Bundle Protocol, the ipn URI scheme is sufficiently generic to | with Bundle Protocol, the ipn URI scheme is sufficiently generic to | |||
be used in other environments where a concise unique representation | be used in other environments where a concise unique representation | |||
of a resource on a particular node is required. | of a resource on a particular node is required. | |||
It is important to remember that like most other URI schemes, the ipn | It is important to remember that, like most other URI schemes, the | |||
URI scheme defines a unique identifier of a resource, and does not | ipn URI scheme defines a unique identifier of a resource, and does | |||
include any topological information describing how to route messages | not include any topological information describing how to route | |||
to that resource. | messages to that resource. | |||
2. Conventions and Definitions | 2. Conventions and Definitions | |||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | |||
"OPTIONAL" in this document are to be interpreted as described in | "OPTIONAL" in this document are to be interpreted as described in | |||
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all | BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all | |||
capitals, as shown here. | capitals, as shown here. | |||
For the remainder of this document the term "ipn URI" is used to | For the remainder of this document, the term "ipn URI" is used to | |||
refer to a URI that uses the ipn scheme. | refer to a URI that uses the ipn scheme. | |||
3. Core Concepts | 3. Core Concepts | |||
Every ipn URI, no matter the textual representation or binary | Every ipn URI, no matter whether it is expressed with the textual | |||
encoding, MUST be considered as a tuple of the following three | representation or a binary encoding, MUST be considered as a tuple of | |||
components: | the following three components: | |||
* The Allocator Identifier | * The Allocator Identifier | |||
* The Node Number | * The Node Number | |||
* The Service Number | * The Service Number | |||
The Allocator Identifier indicates the entity responsible for | The Allocator Identifier indicates the entity responsible for | |||
assigning Node Numbers to individual resource nodes, maintaining | assigning Node Numbers to individual resource nodes, maintaining | |||
uniqueness whilst avoiding the need for a single registry for all | uniqueness whilst avoiding the need for a single registry for all | |||
skipping to change at page 5, line 42 ¶ | skipping to change at page 6, line 11 ¶ | |||
Node Number provides a mechanism to uniquely identify the node on | Node Number provides a mechanism to uniquely identify the node on | |||
which a particular resource is expected to exist. See | which a particular resource is expected to exist. See | |||
Fully-qualified Node Number (Section 3.3.1). | Fully-qualified Node Number (Section 3.3.1). | |||
3.1. The Null ipn URI | 3.1. The Null ipn URI | |||
It has been found that there is value in defining a unique 'null' ipn | It has been found that there is value in defining a unique 'null' ipn | |||
URI to indicate "nowhere". This ipn URI is termed the "Null ipn | URI to indicate "nowhere". This ipn URI is termed the "Null ipn | |||
URI", and has all three components: Allocator Identifier, Node | URI", and has all three components: Allocator Identifier, Node | |||
Number, and Service Number, set to the value zero (0). No resource | Number, and Service Number, set to the value zero (0). No resource | |||
identified by Null ipn URI exists, and any such resource is therefore | identified by Null ipn URI exists, and any destination identified by | |||
by definition unreachable. | such a resource is therefore by definition unreachable. | |||
3.2. Allocator Identifiers | 3.2. Allocator Identifiers | |||
An Allocator is any organization that wishes to assign Node Numbers | An Allocator is any organization that wishes to assign Node Numbers | |||
for use with the ipn URI scheme, and has the facilities and | for use with the ipn URI scheme, and has the facilities and | |||
governance to manage a public registry of assigned Node Numbers. The | governance to manage a public registry of assigned Node Numbers. The | |||
authorization to assign these numbers is provided through the | authorization to assign these numbers is provided through the | |||
assignment of an Allocator Identifier by IANA. Regardless of other | assignment of an Allocator Identifier by IANA. Regardless of other | |||
attributes of an Allocator, such as a name, point of contact, or | attributes of an Allocator, such as a name, point of contact, or | |||
other identifying information, Allocators are identified by Allocator | other identifying information, Allocators are identified by Allocator | |||
Identifiers: a unique, unsigned integer. | Identifiers: a unique, unsigned integer, in the range 0 to 2^32-1. | |||
The Allocator Identifier MUST be the sole mechanism used to identify | The Allocator Identifier MUST be the sole mechanism used to identify | |||
the Allocator that has assigned the Node Number in an ipn URI. An | the Allocator that has assigned the Node Number in an ipn URI. An | |||
Allocator may have multiple assigned Allocator Identifiers, but a | Allocator may have multiple assigned Allocator Identifiers, but a | |||
given Allocator Identifier MUST only be associated with a single | given Allocator Identifier MUST only be associated with a single | |||
Allocator. | Allocator. | |||
A new IANA "'ipn' Scheme URI Allocator Identifiers" registry is | A new IANA "'ipn' Scheme URI Allocator Identifiers" registry is | |||
defined for the registration of Allocator Identifiers, see 'ipn' | defined for the registration of Allocator Identifiers, see 'ipn' | |||
Scheme URI Allocator Identifiers registry (Section 9.1). Although | Scheme URI Allocator Identifiers registry (Section 9.1). Although | |||
skipping to change at page 6, line 28 ¶ | skipping to change at page 6, line 46 ¶ | |||
experimentation or future use. | experimentation or future use. | |||
Each Allocator assigns Node Numbers according to its own policies, | Each Allocator assigns Node Numbers according to its own policies, | |||
without risk of creating an identical ipn URI, as permitted by the | without risk of creating an identical ipn URI, as permitted by the | |||
rules in the Node Numbers (Section 3.3) section of this document. | rules in the Node Numbers (Section 3.3) section of this document. | |||
Other than ensuring that any Node Numbers it allocates are unique | Other than ensuring that any Node Numbers it allocates are unique | |||
amongst all Node Numbers it assigns, an Allocator does not need to | amongst all Node Numbers it assigns, an Allocator does not need to | |||
coordinate its allocations with other Allocators. | coordinate its allocations with other Allocators. | |||
If a system does not require interoperable deployment of ipn scheme | If a system does not require interoperable deployment of ipn scheme | |||
URIs, then the Private Use Node Number range, reserved by the Default | URIs, then the Private Use Node Numbers (Section 3.4.3) range, | |||
Allocator (Section 3.2.2) for this purpose SHOULD be used. | reserved by the Default Allocator (Section 3.2.2) for this purpose, | |||
are to be used. | ||||
3.2.1. Allocator Identifier Ranges | 3.2.1. Allocator Identifier Ranges | |||
Some organizations with internal hierarchies may wish to delegate the | Some organizations with internal hierarchies may wish to delegate the | |||
allocation of Node Numbers to one or more of their sub-organizations. | allocation of Node Numbers to one or more of their sub-organizations. | |||
Rather than assigning unique Allocator Identifiers to each sub- | Rather than assigning unique Allocator Identifiers to each sub- | |||
organization on a first-come first-served basis, there are | organization on a first-come first-served basis, there are | |||
operational benefits in assigning Allocator Identifiers to such an | operational benefits in assigning Allocator Identifiers to such an | |||
organization in a structured way so that an external observer can | organization in a structured way so that an external observer can | |||
detect that a group of Allocator Identifiers are organizationally | detect that a group of Allocator Identifiers are organizationally | |||
skipping to change at page 7, line 26 ¶ | skipping to change at page 7, line 45 ¶ | |||
Allocator Identifier ranges differ from CIDR addresses in two | Allocator Identifier ranges differ from CIDR addresses in two | |||
important ways. | important ways. | |||
1. Allocator Identifiers are used to identify organizations and are | 1. Allocator Identifiers are used to identify organizations and are | |||
not, themselves, addresses. | not, themselves, addresses. | |||
2. Allocator Identifiers may be less than 32 bits in length. | 2. Allocator Identifiers may be less than 32 bits in length. | |||
In order to differentiate between Allocator Identifier ranges using | In order to differentiate between Allocator Identifier ranges using | |||
efficient bitwise operations, all ranges MUST be of a length that is | efficient bitwise operations, all ranges MUST be of a size S that is | |||
a power of 2, and for given range of length N bits, the least- | a power of 2, and for a given range of length N bits, with S = 2^N, | |||
significant N bits of the first Allocator Identifier MUST be all 0. | the least-significant N bits of the first Allocator Identifier MUST | |||
be all 0. | ||||
An example of the use of Allocator Identifier ranges for four | An example of the use of Allocator Identifier ranges for four | |||
organizations (A, B, C, and D) is as follows: | organizations (A, B, C, and D) is as follows: | |||
+==============+=============+=============+=====================+ | +==============+=============+=============+=====================+ | |||
| Organization | Range (dec) | Range (hex) | Range Length (Bits) | | | Organization | Range (dec) | Range (hex) | Range Length (Bits) | | |||
+==============+=============+=============+=====================+ | +==============+=============+=============+=====================+ | |||
| Org A | 974848 .. | 0xEE000 .. | 7 bits | | | Org A | 974848 .. | 0xEE000 .. | 7 bits | | |||
| | 974975 | 0xEE07F | | | | | 974975 | 0xEE07F | | | |||
+--------------+-------------+-------------+---------------------+ | +--------------+-------------+-------------+---------------------+ | |||
skipping to change at page 8, line 4 ¶ | skipping to change at page 8, line 25 ¶ | |||
| | 974993 | 0xEE091 | | | | | 974993 | 0xEE091 | | | |||
+--------------+-------------+-------------+---------------------+ | +--------------+-------------+-------------+---------------------+ | |||
| Org D | 974994 | 0xEE092 | 0 bits | | | Org D | 974994 | 0xEE092 | 0 bits | | |||
+--------------+-------------+-------------+---------------------+ | +--------------+-------------+-------------+---------------------+ | |||
Table 1: Allocator Identifier Range Assignment Example | Table 1: Allocator Identifier Range Assignment Example | |||
With these assignments, any Allocator Identifier whose most- | With these assignments, any Allocator Identifier whose most- | |||
significant 25 bits match 0xEE000 belong to organization A. | significant 25 bits match 0xEE000 belong to organization A. | |||
Similarly, any Allocator Identifier whose most-significant 28 bits | Similarly, any Allocator Identifier whose most-significant 28 bits | |||
match 0xEE080 belong to organization B and any Allocator Identifier | match 0xEE080 belong to organization B, and any Allocator Identifier | |||
whose most-significant 31 bits are 0xEE090 belong to organization C. | whose most-significant 31 bits are 0xEE090 belong to organization C. | |||
Organisation D has a single Allocator Identifier, and hence a range | Organization D has a single Allocator Identifier, and hence a range | |||
of bit-length 0. | of bit-length 0. | |||
3.2.2. The Default Allocator | 3.2.2. The Default Allocator | |||
As of the publication of [RFC7116], the only organization permitted | As of the publication of [RFC7116], the only organization permitted | |||
to assign Node Numbers was the Internet Assigned Numbers Authority | to assign Node Numbers was the Internet Assigned Numbers Authority | |||
(IANA) which assigned Node Numbers via the IANA "CBHE Node Numbers" | (IANA) which assigned Node Numbers via the IANA "CBHE Node Numbers" | |||
registry. This means that all ipn URIs created prior to the addition | registry. This means that all ipn URIs created prior to the addition | |||
of Allocator Identifiers are assumed to have Node Number allocations | of Allocator Identifiers are assumed to have Node Number allocations | |||
that comply with the IANA "CBHE Node Numbers" registry. | that comply with the IANA "CBHE Node Numbers" registry. | |||
The presumption that, unless otherwise specified, Node Numbers are | The presumption that, unless otherwise specified, Node Numbers are | |||
allocated by IANA from a specific registry is formalized in this | allocated by IANA from a specific registry is formalized in this | |||
update to the ipn URI scheme by designating IANA as the "Default | update to the ipn URI scheme by designating IANA as the Default | |||
Allocator", and assigned the Allocator Identifier zero (0) in the | Allocator, and by assigning the Allocator Identifier zero (0) in the | |||
'ipn' Scheme URI Allocator Identifiers registry (Section 9.1). In | 'ipn' Scheme URI Allocator Identifiers registry (Section 9.1) to the | |||
any case where an encoded ipn URI does not explicitly include an | Default Allocator. In any case where an encoded ipn URI does not | |||
Allocator Identifier, an implementation MUST assume that the Node | explicitly include an Allocator Identifier, an implementation MUST | |||
Number has been allocated by the Default Allocator. | assume that the Node Number has been allocated by the Default | |||
Allocator. | ||||
A new IANA "'ipn' Scheme URI Default Allocator Node Numbers" registry | A new IANA "'ipn' Scheme URI Default Allocator Node Numbers" registry | |||
is defined to control the allocation of Node Numbers values by the | is defined to control the allocation of Node Numbers values by the | |||
Default Allocator. This new registry inherits behaviours and | Default Allocator. This new registry inherits behaviors and existing | |||
existing assignments from the IANA "CBHE Node Numbers" registry, and | assignments from the IANA "CBHE Node Numbers" registry, and reserves | |||
reserves some other values as defined in the Special Node Numbers | some other values as defined in the Special Node Numbers | |||
(Section 3.4) section below. | (Section 3.4) section below. | |||
3.3. Node Numbers | 3.3. Node Numbers | |||
A Node Number identifies a node that hosts a resource in the context | A Node Number identifies a node that hosts a resource in the context | |||
of an Allocator. A Node Number is an unsigned integer. A single | of an Allocator. A Node Number is an unsigned integer. A single | |||
Node Number assigned by a single Allocator MUST refer to a single | Node Number assigned by a single Allocator MUST refer to a single | |||
node. | node. | |||
All Node Number assignments, by all Allocators, MUST be in the range | All Node Number assignments, by all Allocators, MUST be in the range | |||
skipping to change at page 9, line 22 ¶ | skipping to change at page 9, line 42 ¶ | |||
the sending node has been colloquially referred to as the "node | the sending node has been colloquially referred to as the "node | |||
number" or "node identifier". | number" or "node identifier". | |||
To avoid future confusion, when referring to the identifier of a | To avoid future confusion, when referring to the identifier of a | |||
particular node the term "Fully-qualified Node Number" (FQNN) MUST be | particular node the term "Fully-qualified Node Number" (FQNN) MUST be | |||
used to refer to the combination of the Node Number component and | used to refer to the combination of the Node Number component and | |||
Allocator Identifier component of an ipn URI that uniquely identifies | Allocator Identifier component of an ipn URI that uniquely identifies | |||
a particular node. In other words, an FQNN is the unique identifier | a particular node. In other words, an FQNN is the unique identifier | |||
of a particular node that supports services identified by ipn URIs. | of a particular node that supports services identified by ipn URIs. | |||
In examples in this document, FQNNs are written as (Allocator | In the examples in this document, FQNNs are written as (Allocator | |||
Identifier, Node Number), e.g. (977000,100) is the FQNN for a node | Identifier, Node Number), e.g., (977000,100) is the FQNN for a node | |||
assigned Node Number 100 by an Allocator with Allocator Identifier | assigned Node Number 100 by an Allocator with Allocator Identifier | |||
977000. | 977000. | |||
3.4. Special Node Numbers | 3.4. Special Node Numbers | |||
Some special-case Node Numbers are defined by the Default Allocator, | Some special-case Node Numbers are defined by the Default Allocator, | |||
see 'ipn' Scheme URI Default Allocator Node Numbers registry | see 'ipn' Scheme URI Default Allocator Node Numbers registry | |||
(Section 9.2). | (Section 9.2). | |||
3.4.1. The Zero Node Number | 3.4.1. The Zero Node Number | |||
skipping to change at page 9, line 51 ¶ | skipping to change at page 10, line 23 ¶ | |||
ipn URIs MUST consider them as the Null ipn URI. | ipn URIs MUST consider them as the Null ipn URI. | |||
3.4.2. LocalNode ipn URIs | 3.4.2. LocalNode ipn URIs | |||
The Default Allocator reserves Node Number 2^32-1 (0xFFFFFFFFF) to | The Default Allocator reserves Node Number 2^32-1 (0xFFFFFFFFF) to | |||
specify resources on the local node, rather than on any specific | specify resources on the local node, rather than on any specific | |||
individual node. | individual node. | |||
This means that any ipn URI with a zero (0) Allocator Identifier and | This means that any ipn URI with a zero (0) Allocator Identifier and | |||
a Node Number of 2^32-1 refers to a service on the local bundle node. | a Node Number of 2^32-1 refers to a service on the local bundle node. | |||
ipn URIs of this form are termed "LocalNode ipn URIs". | This form of ipn URI is termed a "LocalNode ipn URI". | |||
3.4.3. Private Use Node Numbers | 3.4.3. Private Use Node Numbers | |||
The Default Allocator provides a range of Node Numbers that are | The Default Allocator provides a range of Node Numbers that are | |||
reserved for "Private Use", as defined in [RFC8126]. | reserved for "Private Use", as defined in [RFC8126]. | |||
Any ipn URI with a zero (0) Allocator Identifier and a Node Number | Any ipn URI with a zero (0) Allocator Identifier and a Node Number | |||
reserved for "Private Use" is not guaranteed to be unique beyond a | reserved for "Private Use" is not guaranteed to be unique beyond a | |||
single administrative domain. An administrative domain, as used | single administrative domain. An administrative domain, as used | |||
here, is defined as the set of nodes that share a unique allocation | here, is defined as the set of nodes that share a unique allocation | |||
of FQNNs from the "Private Use" range. These FQNNs can be considered | of FQNNs from the "Private Use" range. These FQNNs can be considered | |||
to be functionally similar to "Private Address Space" IPv4 addresses, | to be functionally similar to "Private Address Space" IPv4 addresses, | |||
as defined in [RFC1918]. | as defined in [RFC1918]. | |||
Because of this lack of uniqueness, any implementation of a protocol | ||||
using ipn URIs that resides on the border between administrative | ||||
domains MUST have suitable mechanisms in place to prevent protocol | ||||
units using such "Private Use" Node Numbers to cross between | ||||
different administrative domains. | ||||
3.5. Service Numbers | 3.5. Service Numbers | |||
A Service Number is an unsigned integer that identifies a particular | A Service Number is an unsigned integer that identifies a particular | |||
service operating on a node. A service in this case is some logical | service operating on a node. A service in this case is some logical | |||
function that requires its own resource identifier to distinguish it | function that requires its own resource identifier to distinguish it | |||
from other functions operating on the same node. | from other functions operating on the same node. | |||
4. Textual Encoding of ipn URIs | 4. Textual Representation of ipn URIs | |||
All ipn scheme URIs comply with [RFC3986], and are therefore | All ipn scheme URIs comply with [RFC3986], and are therefore | |||
represented by scheme identifier, and a scheme-specific part. The | represented by scheme identifier, and a scheme-specific part. The | |||
scheme identifier is: ipn, and the scheme-specific parts are | scheme identifier is: ipn, and the scheme-specific parts are | |||
represented as a sequence of numeric components separated with the | represented as a sequence of numeric components separated with the | |||
'.' character. It is formally defined in Appendix A (Appendix A), | '.' character. A formal definition is provided below, see ipn URI | |||
and can be informally considered as: | Scheme Text Syntax (Section 4.1), and can be informally considered | |||
as: | ||||
ipn:[<allocator-identifier>.]<node-number>.<service-number> | ipn:[<allocator-identifier>.]<node-number>.<service-number> | |||
To keep the text representation concise, the follow rules apply: | To keep the text representation concise, the following rules apply: | |||
1. All leading 0 characters MUST be omitted. A single '0' is valid. | 1. All leading 0 characters MUST be omitted. A single '0' is valid. | |||
2. If the Allocator Identifier is zero (0), then the <allocator- | 2. If the Allocator Identifier is zero (0), then the <allocator- | |||
identifier> and '.' MUST be omitted. | identifier> and '.' MAY be omitted. | |||
3. If the Allocator Identifier is zero (0), and the Node Number is | 3. If the Allocator Identifier is zero (0), and the Node Number is | |||
2^32-1, i.e. the URI is an LocalNode ipn URI (Section 3.4.2), | 2^32-1, i.e., the URI is a LocalNode ipn URI (Section 3.4.2), | |||
then the character '!' MAY be used instead of the digits | then the character '!' SHOULD be used instead of the digits | |||
4294967295, although both forms are valid encodings. | 4294967295, although both forms are valid encodings. | |||
Examples of the textual representation of ipn URIs can be found in | Examples of the textual representation of ipn URIs can be found in | |||
Appendix B (Appendix B). | Appendix A (Appendix A). | |||
4.1. ipn URI Scheme Text Syntax | ||||
The text syntax of an ipn URI MUST comply with the following ABNF | ||||
[RFC5234] syntax, and reiterates the core ABNF syntax rule for DIGIT | ||||
defined by that specification: | ||||
ipn-uri = "ipn:" ipn-hier-part | ||||
ipn-hier-part = fqnn "." service-number | ||||
fqnn = "!" / allocator-part | ||||
allocator-part = [allocator-identifier "."] node-number | ||||
allocator-identifier = number | ||||
node-number = number | ||||
service-number = number | ||||
number = "0" / non-zero-number | ||||
non-zero-number = (%x31-39 *DIGIT) | ||||
DIGIT = %x30-39 | ||||
5. Usage of ipn URIs with BPv7 | 5. Usage of ipn URIs with BPv7 | |||
From the earliest days of experimentation with the Bundle Protocol | From the earliest days of experimentation with the Bundle Protocol | |||
there has been a need to identify the source and destination of a | there has been a need to identify the source and destination of a | |||
bundle. The IRTF standardisation of the experimental BPv6 termed the | bundle. The IRTF BPv6 experimental specification termed the logical | |||
logical source or destination of a bundle as an "Endpoint" identified | source or destination of a bundle as an "Endpoint" identified by an | |||
by an "Endpoint Identifier" (EID). BPv6 EIDs are formatted as URIs. | "Endpoint Identifier" (EID). BPv6 EIDs are formatted as URIs. This | |||
This definition and representation of EIDs was carried forward from | definition and representation of EIDs was carried forward from the | |||
the IRTF BPv6 specification to the IETF BPv7 specification. BPv7 | IRTF BPv6 specification to the IETF BPv7 specification. BPv7 | |||
additionally defined an IANA registry called the "Bundle Protocol URI | additionally defined an IANA registry called the "Bundle Protocol URI | |||
Scheme Types" registry which identifies those URI schemes than might | Scheme Types" registry which identifies those URI schemes than might | |||
be used to represent EIDs. The ipn URI scheme is one such URI | be used to represent EIDs. The ipn URI scheme is one such URI | |||
scheme. | scheme. | |||
This section identifies the behavior and interpretation of ipn scheme | This section identifies the behavior and interpretation of ipn scheme | |||
URIs that MUST be followed when using this URI scheme to represent | URIs that MUST be followed when using this URI scheme to represent | |||
EIDs in BPv7. An ipn URI used as a BPv7 or BPv6 EID is termed an | EIDs in BPv7. An ipn URI used as a BPv7 or BPv6 EID is termed an | |||
"ipn EID". | "ipn EID". | |||
skipping to change at page 11, line 48 ¶ | skipping to change at page 13, line 22 ¶ | |||
registered on any other bundle processing node. | registered on any other bundle processing node. | |||
5.2. The Null Endpoint | 5.2. The Null Endpoint | |||
Section 3.2 of [RFC9171] defines the concept of the 'null' endpoint, | Section 3.2 of [RFC9171] defines the concept of the 'null' endpoint, | |||
which is an endpoint that has no members and which is identified by a | which is an endpoint that has no members and which is identified by a | |||
special 'null' EID. | special 'null' EID. | |||
Within the ipn URI scheme, the 'null' EID is represented by the Null | Within the ipn URI scheme, the 'null' EID is represented by the Null | |||
ipn URI (Section 3.1). This means that the URIs dtn:none | ipn URI (Section 3.1). This means that the URIs dtn:none | |||
(Section 4.2.5.1.1 of [RFC9171]) and ipn:0.0 both refer to the BPv7 | (Section 4.2.5.1.1 of [RFC9171]), ipn:0.0, and ipn:0.0.0 all refer to | |||
'null' endpoint. | the BPv7 'null' endpoint. | |||
5.3. BPv7 Node ID | 5.3. BPv7 Node ID | |||
Section 4.2.5.2 of [RFC9171] introduces the concept of a "Node ID" | Section 4.2.5.2 of [RFC9171] introduces the concept of a "Node ID" | |||
that has the same format as an EID and that uniquely identifies a | that has the same format as an EID and that uniquely identifies a | |||
bundle processing node. | bundle processing node. | |||
Any ipn EID can serve as a "Node ID" for the bundle processing node | Any ipn EID can serve as a "Node ID" for the bundle processing node | |||
identified by its Fully-qualified Node Number (Section 3.3.1). That | identified by its Fully-qualified Node Number (Section 3.3.1). That | |||
is, any ipn EID of the form ipn:A.B.C may be used as the Source Node | is, any ipn EID of the form ipn:A.B.C may be used as the Source Node | |||
ID of any bundle created by the bundle processing node identified by | ID of any bundle created by the bundle processing node identified by | |||
the FQNN (A,B). | the FQNN (A,B). | |||
5.4. LocalNode ipn EIDs | 5.4. LocalNode ipn EIDs | |||
When a LocalNode ipn URI (Section 3.4.2) is used as a BPv7 or BPv6 | When a LocalNode ipn URI (Section 3.4.2) is used as a BPv7 or BPv6 | |||
EID it is termed a "LocalNode ipn EID". | EID, it is termed a "LocalNode ipn EID". | |||
Because a LocalNode ipn EID only has meaning on the local bundle | Because a LocalNode ipn EID only has meaning on the local bundle | |||
node, any such EID MUST be considered 'non-routeable'. This means | node, any such EID MUST be considered 'non-routable'. This means | |||
that any bundle using a LocalNode ipn EID as a bundle source or | that any bundle using a LocalNode ipn EID as a bundle source or | |||
bundle destination MUST NOT be allowed to leave the local node. | bundle destination MUST NOT be allowed to leave the local node. | |||
Similarly, LocalNode ipn EIDs SHOULD NOT be present in any other part | Equally, all externally received bundles featuring LocalNode EIDs as | |||
of a bundle that is transmitted off of the local node. For example, | a bundle source or bundle destination MUST be discarded as invalid. | |||
a LocalNode ipn EID SHOULD NOT be used as a Bundle Protocol Security | ||||
[RFC9172] security source EID for a bundle transmitted from the local | ||||
bundle node, because such a source EID would have no meaning at a | ||||
downstream bundle node. | ||||
5.5. Private Use Endpoints | LocalNode ipn EIDs MUST NOT be present in any other part of a bundle | |||
that is transmitted off of the local node. For example, a LocalNode | ||||
ipn EID MUST NOT be used as a Bundle Protocol Security [RFC9172] | ||||
security source for a bundle transmitted from the local bundle node, | ||||
because such a source EID would have no meaning at a downstream | ||||
bundle node. | ||||
LocalNode ipn EIDs MUST NOT be published in any node identification | ||||
directory, such as a DNS registration, or presented as part of | ||||
dynamic peer discovery, as the EID has no valid meaning for other | ||||
nodes. For example, a LocalNode ipn EID MUST NOT be advertised as | ||||
the peer Node ID during session negotiation in [RFC9174]. | ||||
5.5. Private Use ipn EIDs | ||||
Bundles destined for EIDs that use an ipn URI with a Fully-qualified | Bundles destined for EIDs that use an ipn URI with a Fully-qualified | |||
Node Number (Section 3.3.1) that is within the "Private Use" range of | Node Number (Section 3.3.1) that is within the "Private Use" range of | |||
the Default Allocator (Section 3.2.2) MUST be considered 'non- | the Default Allocator (Section 3.2.2) are not universally unique, and | |||
routeable'. | therefore are only valid within the scope of the current | |||
administrative domain. This means that any bundle using a Private | ||||
Use ipn EID as a bundle source or bundle destination MUST NOT be | ||||
allowed to cross administrative domains. All implementations that | ||||
could be deployed as a gateway between administrative domains MUST be | ||||
sufficiently configurable to ensure that this is enforced, and | ||||
operators MUST ensure correct configuration. | ||||
This means that they MUST NOT be permitted to exit a single | Private Use ipn EIDs MUST NOT be present in any other part of a | |||
administrative domain, see Private Use (Section 3.4.3). | bundle that is destined for another administrative domain when the | |||
lack of uniqueness prevents correct operation. For example, a | ||||
Private Use ipn EID MUST NOT be used as a Bundle Protocol Security | ||||
[RFC9172] security source for a bundle, when the bundle is destined | ||||
for a different administrative domain. | ||||
5.6. Well-known Service Numbers | 5.6. Well-known Service Numbers | |||
It is convenient for BPv7 services that have a public specification | It is convenient for BPv7 services that have a public specification | |||
and wide adoption to by identified by a pre-agreed default Service | and wide adoption to be identified by a pre-agreed default Service | |||
Number, so that unless extra configuration is applied, such services | Number, so that unless extra configuration is applied, such services | |||
can be sensibly assumed to be operating on the well-known Service | can be sensibly assumed to be operating on the well-known Service | |||
Number on a particular node. | Number on a particular node. | |||
If a different service uses the number, or the service uses a | If a different service uses the number, or the service uses a | |||
different number, BPv7 will continue to operate, but some | different number, BPv7 will continue to operate, but some | |||
configuration may be required to make the individual service | configuration may be required to make the individual service | |||
operational. | operational. | |||
A new IANA "'ipn' Scheme URI Well-known Service Numbers for BPv7" | A new IANA "'ipn' Scheme URI Well-known Service Numbers for BPv7" | |||
skipping to change at page 13, line 26 ¶ | skipping to change at page 15, line 21 ¶ | |||
5.7. Administrative Endpoints | 5.7. Administrative Endpoints | |||
The service identified by a Service Number of zero (0) MUST be | The service identified by a Service Number of zero (0) MUST be | |||
interpreted as the Administrative Endpoint of the node, as defined in | interpreted as the Administrative Endpoint of the node, as defined in | |||
Section 3.2 of [RFC9171]. | Section 3.2 of [RFC9171]. | |||
Non-zero Service Numbers MUST NOT be used to identify the | Non-zero Service Numbers MUST NOT be used to identify the | |||
Administrative Endpoint of a bundle node in an ipn EID. | Administrative Endpoint of a bundle node in an ipn EID. | |||
6. Encoding ipn URIs with BPv7 | 6. CBOR representation of ipn URIs with BPv7 | |||
Section 4.2.5.1 of [RFC9171] requires that any URI scheme used to | Section 4.2.5.1 of [RFC9171] requires that any URI scheme used to | |||
represent BPv7 EIDs MUST define how the scheme-specific part of the | represent BPv7 EIDs MUST define how the scheme-specific part of the | |||
URI scheme is CBOR encoded. To meet this requirement, this section | URI scheme is encoded with CBOR [RFC8949]. To meet this requirement, | |||
describes the CBOR encoding and decoding approach for ipn EIDs. The | this section describes the CBOR encoding and decoding approach for | |||
formal definition of these encodings is presented in Appendix C | ipn EIDs. The formal definition of the CBOR representation is | |||
(Appendix C). | specified, see ipn URI Scheme CBOR syntax (Section 6.3). | |||
While there is a single, canonical, textual representation of an ipn | ||||
URI, there may exist multiple encodings for that URI. For example, | ||||
Section 2.1 of [RFC3986] defines a percent-encoding mechanism for a | ||||
URI text string. Alternatively, Section 3.4.5.3 of [RFC8949] allows | ||||
for the encoding of URIs as CBOR text strings identified with a CBOR | ||||
tag value of 32. | ||||
6.1. ipn EID CBOR Encoding | 6.1. ipn EID CBOR Encoding | |||
Generic URI approaches to encoding ipn EIDs are unlikely to be | Generic URI approaches to encoding ipn EIDs are unlikely to be | |||
efficient because they do not consider the underlying structure of | efficient because they do not consider the underlying structure of | |||
the ipn URI scheme. Since the creation of the ipn URI scheme was | the ipn URI scheme. Since the creation of the ipn URI scheme was | |||
motivated by the need for concise identification and rapid | motivated by the need for concise identification and rapid | |||
processing, the encoding of ipn EIDs maintains these properties. | processing, the encoding of ipn EIDs maintains these properties. | |||
Fundamentally, [RFC9171] ipn EIDs are represented as a sequence of | Fundamentally, [RFC9171] ipn EIDs are represented as a sequence of | |||
identifiers. In the text syntax, the numbers are separated with the | identifiers. In the text syntax, the numbers are separated with the | |||
'.' delimiter; in CBOR, this ordered series of numbers can be | '.' delimiter; in CBOR, this ordered series of numbers can be | |||
represented by an array. Therefore, when encoding ipn EIDs for use | represented by an array. Therefore, when encoding ipn EIDs for use | |||
with BPv7, the scheme-specific part of an ipn URI MUST be represented | with BPv7, the scheme-specific part of an ipn URI MUST be represented | |||
as a CBOR array of either two (2) or three (3) elements. Each | as a CBOR array of either two (2) or three (3) elements. Each | |||
element of the array MUST be encoded as a single CBOR unsigned | element of the array MUST be encoded as a single CBOR unsigned | |||
integer. | integer. | |||
The structure and mechanisms of the two-element and three-element | The structure and mechanisms of the two-element and three-element | |||
encodings are described below, and examples of the different | encodings are described below, and examples of the different | |||
encodings are provided in Appendix D (Appendix D). | encodings are provided in Appendix B (Appendix B). | |||
6.1.1. Two-Element Scheme-Specific Encoding | 6.1.1. Two-Element Scheme-Specific Encoding | |||
In the two-element scheme-specific encoding of an ipn EID, the first | In the two-element scheme-specific encoding of an ipn EID, the first | |||
element of the array is an encoding of the Fully-qualified Node | element of the array is an encoding of the Fully-qualified Node | |||
Number (Section 3.3.1) and the second element of the array is the ipn | Number (Section 3.3.1) and the second element of the array is the ipn | |||
EID Service Number. | EID Service Number. | |||
The FQNN encoding MUST be a 64 bit unsigned integer constructed in | The FQNN encoding MUST be a 64-bit unsigned integer constructed in | |||
the following way: | the following way: | |||
1. The least significant 32 bits MUST represent the Node Number | 1. The least significant 32 bits MUST represent the Node Number | |||
associated with the ipn EID. | associated with the ipn EID. | |||
2. The most significant 32 bits MUST represent the Allocator | 2. The most significant 32 bits MUST represent the Allocator | |||
Identifier associated with the ipn EID. | Identifier associated with the ipn EID. | |||
For example the ipn EID of ipn:977000.100.1 has an FQNN of | For example the ipn EID of ipn:977000.100.1 has an FQNN of | |||
(977000,100) which would be encoded as 0xEE86800000064. The | (977000,100) which would be encoded as 0xEE868_00000064. The | |||
resulting two-element array [0xEE86800000064, 0x01] would be encoded | resulting two-element array [0xEE868_00000064, 0x01] would be encoded | |||
in CBOR as the 11 octet value 0x821B000EE8680000006401. | in CBOR as the following 11 octet sequence: | |||
The two-element scheme-specific encoding provides for backwards | 82 # 2-Element Endpoint Encoding | |||
02 # uri-code: 2 (IPN URI scheme) | ||||
82 # 2 Element ipn EID scheme-specific encoding | ||||
1B 000EE86800000064 # Fully-qualified Node Number | ||||
01 # Service Number | ||||
The two-element scheme-specific encoding provides for backwards- | ||||
compatibility with the encoding provided in Section 4.2.5.1.2 of | compatibility with the encoding provided in Section 4.2.5.1.2 of | |||
[RFC9171]. When used in this way, the encoding of the FQNN replaces | [RFC9171]. When used in this way, the encoding of the FQNN replaces | |||
the use of the "Node Number" that was specified in RFC9171. When the | the use of the "Node Number" that was specified in RFC9171. When the | |||
Node Number is allocated by the Default Allocator (Section 3.2.2), | Node Number is allocated by the Default Allocator (Section 3.2.2), | |||
the encoding of the FQNN and the RFC9171 encoding of the "Node | the encoding of the FQNN and the RFC9171 encoding of the "Node | |||
Number" are identical. | Number" are identical. | |||
This encoding scheme MUST be implemented by any BPv7 bundle | ||||
processing node that supports ipn URIs for the representation of BPv7 | ||||
EIDs. | ||||
6.1.2. Three-Element Scheme-Specific Encoding | 6.1.2. Three-Element Scheme-Specific Encoding | |||
In the three-element scheme-specific encoding of an ipn EID, the | In the three-element scheme-specific encoding of an ipn EID, the | |||
first element of the array is the Allocator Identifier, the second | first element of the array is the Allocator Identifier, the second | |||
element of the array is the Node Number, and the third element of the | element of the array is the Node Number, and the third element of the | |||
array is the Service Number. | array is the Service Number. | |||
For example, the ipn EID of ipn:977000.100.1 would result in the | For example, the ipn EID of ipn:977000.100.1 would result in the | |||
three-element array of [977000,100,1] which would be encoded in CBOR | three-element array of [977000,100,1] which would be encoded in CBOR | |||
as the 9 octet value 0x831A000EE868186401. | as the following 9 octet sequence: | |||
82 # 2-Element Endpoint Encoding | ||||
02 # uri-code: 2 (IPN URI scheme) | ||||
83 # 3 Element ipn EID scheme-specific encoding | ||||
1A 000EE868 # Allocator Identifier | ||||
64 # Node Number | ||||
01 # Service Number | ||||
The three-element scheme-specific encoding allows for a more | The three-element scheme-specific encoding allows for a more | |||
efficient representation of ipn EIDs using smaller Allocator | efficient representation of ipn EIDs using smaller Allocator | |||
Identifiers. | Identifiers, and implementations are RECOMMENDED to use this encoding | |||
scheme, unless explicitly mitigating for interoperability issues, see | ||||
Scheme Compatibility (Section 7.1). | ||||
When encoding an ipn EID using the Default Allocator (Section 3.2.2) | When encoding an ipn EID using the Default Allocator (Section 3.2.2) | |||
with this encoding scheme, the first element of the array MUST be the | with this encoding scheme, the first element of the array is the | |||
value zero (0). In this case using the two-element encoding will | value zero (0). In this case using the equivalent Two-Element | |||
result in a more concise CBOR representation, and it is RECOMMENDED | Scheme-Specific Encoding (Section 6.1.1) will result in a more | |||
that implementations do so. | concise CBOR representation, and therefore it is RECOMMENDED that | |||
implementations use that encoding instead. | ||||
6.2. ipn EID CBOR Decoding | 6.2. ipn EID CBOR Decoding | |||
The presence of different scheme-specific encodings does not | The presence of different scheme-specific encodings does not | |||
introduce any decoding ambiguity. | introduce any decoding ambiguity. | |||
An ipn EID CBOR decoder can reconstruct an ipn EID using the | An ipn EID CBOR decoder can reconstruct an ipn EID using the | |||
following logic. In this description, the term enc_eid refers to the | following logic. In this description, the term enc_eid refers to the | |||
CBOR encoded ipn EID, and the term ipn_eid refers to the decoded ipn | CBOR encoded ipn EID, and the term ipn_eid refers to the decoded ipn | |||
EID. | EID. | |||
skipping to change at page 16, line 5 ¶ | skipping to change at page 18, line 5 ¶ | |||
ipn_eid.node_number := enc_eid[1]; | ipn_eid.node_number := enc_eid[1]; | |||
ipn_eid.service_number := enc_eid[2]; | ipn_eid.service_number := enc_eid[2]; | |||
} | } | |||
else if enc_eid.len() == 2 | else if enc_eid.len() == 2 | |||
{ | { | |||
ipn_eid.allocator_identifier := enc_eid[0] >> 32; | ipn_eid.allocator_identifier := enc_eid[0] >> 32; | |||
ipn_eid.node_number := enc_eid[0] & (2^32-1); | ipn_eid.node_number := enc_eid[0] & (2^32-1); | |||
ipn_eid.service_number := enc_eid[1]; | ipn_eid.service_number := enc_eid[1]; | |||
} | } | |||
6.3. ipn EID Matching | 6.3. ipn URI Scheme CBOR syntax | |||
A BPv7 endpoint identified by an ipn URI, when encoded in Concise | ||||
Binary Object Representation (CBOR) [RFC8949], MUST comply with the | ||||
following Concise Data Definition Language (CDDL) [RFC8610] | ||||
specification: | ||||
eid = $eid .within eid-structure | ||||
eid-structure = [ | ||||
uri-code: uint, | ||||
SSP: any | ||||
] | ||||
; ... Syntax for other uri-code values defined in RFC9171 ... | ||||
$eid /= [ | ||||
uri-code: 2, | ||||
SSP: ipn-ssp2 / ipn-ssp3 | ||||
] | ||||
ipn-ssp2 = [ | ||||
fqnn: uint, ; packed value | ||||
service-number: uint | ||||
] | ||||
ipn-ssp3 = [ | ||||
allocator-identifier: uint .lt 4294967296, | ||||
node-number: uint .lt 4294967296, | ||||
service-number: uint | ||||
] | ||||
Note: The node-number component will be the numeric representation of | ||||
the concatenation of the Allocator Identifier and Node Number when | ||||
the 2-element encoding scheme has been used. | ||||
6.4. ipn EID Matching | ||||
Regardless of whether the two-element or three-element scheme- | Regardless of whether the two-element or three-element scheme- | |||
specific encoding is used, ipn EID matching MUST be performed on the | specific encoding is used, ipn EID matching MUST be performed on the | |||
decoded EID information itself. Different encodings of the same ipn | decoded EID information itself. Different encodings of the same ipn | |||
EID MUST be treated as equivalent when performing EID-specific | EID MUST be treated as equivalent when performing EID-specific | |||
functions. | functions. | |||
For example, the ipn EID of ipn:977000.100.1 can be represented as | For example, the ipn EID of ipn:977000.100.1 can be represented as | |||
either the two-element encoding of 0x821B000EE8680000006401 or the | either the two-element encoding of 0x821B000EE8680000006401 or the | |||
three-element encoding of 0x831A000EE868186401. While message | three-element encoding of 0x831A000EE868186401. While message | |||
integrity and other syntax-based checks may treat these values | integrity and other syntax-based checks may treat these values | |||
differently, any EID-based comparisons MUST treat these values the | differently, any EID-based comparisons MUST treat these values the | |||
same - as representing the ipn EID ipn:977000.100.1. | same - as representing the ipn EID ipn:977000.100.1. | |||
7. Special Considerations | 7. Special Considerations | |||
The ipn URI scheme provides a compact and hierarchical mechanism for | The ipn URI scheme provides a compact and hierarchical mechanism for | |||
identifying services on network nodes. There is a significant amount | identifying services on network nodes. There is a significant amount | |||
of utility in the ipn URI scheme approach to identification. | of utility in the ipn URI scheme approach to identification. | |||
However, implementers should take into consideration the following | However, implementers should take into consideration the following | |||
observations on the use of the ipn URI scheme. | observations on the use of the ipn URI scheme, particularly in regard | |||
to interoperability with implementations that pre-date this | ||||
specification. | ||||
7.1. Scheme Compatibility | 7.1. Scheme Compatibility | |||
The ipn scheme update that has been presented in this document | The ipn scheme update that has been presented in this document | |||
preserves backwards compatibility with any ipn URI scheme going back | preserves backwards compatibility with any ipn URI scheme going back | |||
to the provisional definition of the ipn scheme in the experimental | to the provisional definition of the ipn scheme in the experimental | |||
Compressed Bundle Header Encoding [RFC6260] specification in 2011. | Compressed Bundle Header Encoding [RFC6260] specification in 2011. | |||
This means that any ipn URI that was valid prior to the publication | This means that any ipn URI that was valid prior to the publication | |||
of this update remains a valid ipn URI. | of this update remains a valid ipn URI. | |||
Similarly, the two-element scheme-specific encoding (Section 6.1.1) | Similarly, the two-element scheme-specific encoding (Section 6.1.1) | |||
is also backwards compatible with the encoding of ipn URIs provided | is also backwards-compatible with the encoding of ipn URIs provided | |||
in [RFC9171]. Any existing BPv7-compliant implementation will | in [RFC9171]. Any existing RFC9171-compliant implementation will | |||
produce an ipn URI encoding in compliance with this specification. | produce an ipn URI encoding in compliance with this specification. | |||
The introduction of optional non-default Allocator Identifiers and a | The introduction of optional non-default Allocator Identifiers and a | |||
three-element scheme-specific encoding make this ipn URI scheme | three-element scheme-specific encoding does not make this ipn URI | |||
update not forwards compatible. Existing software for which support | scheme update forwards-compatible. Existing implementations for | |||
of this update is desired MUST be updated to be able to process non- | which support of this update is desired MUST be updated to be able to | |||
default Allocator Identifiers and three-element scheme-specific | process non-default Allocator Identifiers and three-element scheme- | |||
encodings. It is RECOMMENDED that BP implementations upgrade to | specific encodings. It is RECOMMENDED that BPv7 implementations | |||
process these new features to benefit from the scalability provided | upgrade to process these new features to benefit from the scalability | |||
by Allocator Identifiers and the encoding efficiencies provided by | provided by Allocator Identifiers and the encoding efficiencies | |||
the three-element encoding. | provided by the three-element encoding. | |||
7.2. Late Binding | 7.2. CBOR Representation Interoperability | |||
[RFC9171] mandates the concept of "late binding" of an EID, where-by | Care must be taken when deploying implementations that default to | |||
using the three-element encoding in networks that include | ||||
implementations that only support the two-element [RFC9171] encoding. | ||||
Because the existing implementations will reject bundles that use the | ||||
three-element encoding as malformed, correct forwarding of | ||||
semantically valid bundles will fail. The used mitigation for this | ||||
issue depends on the nature of the interoperability required by the | ||||
deployment. Techniques can include: | ||||
* A configuration option indicating when an implementation must use | ||||
the two-element encoding for all ipn EIDs when processing bundles | ||||
destined to a given endpoint: This would be suitable when adding a | ||||
newer implementation to a network of existing implementations. | ||||
* Selective bundle encapsulation, whereby bundles that are known to | ||||
originate from implementations that do not support the three- | ||||
element encoding are tunnelled across regions of the network that | ||||
require the three-element encoding: This would utilize specially | ||||
configured 'gateway nodes' to perform the tunnel encapsulation and | ||||
decapsulation, and would be suitable when joining an existing | ||||
network to a larger network. | ||||
Techniques that do not mitigate the problem include: | ||||
* Heuristic determination of the correct encoding to use when | ||||
responding to a bundle by examining the incoming bundle: It is not | ||||
possible to determine whether the two-element encoding is required | ||||
by the destination when composing a new bundle in response to the | ||||
receipt of a bundle, such as a status report, because ipn EIDs | ||||
assigned by the Default Allocator use the two-element encoding, | ||||
whether the implementation supports the three-element encoding or | ||||
not. | ||||
* Transcoding bundles at intermediate nodes: [RFC9171] requires the | ||||
bundle primary block be immutable, and even if ipn EIDs in the | ||||
primary block do not require rewriting, other blocks including the | ||||
payload block may include ipn EIDs of which the transcoding node | ||||
is unaware. Additionally, bundle blocks may be covered by | ||||
[RFC9172] bundle security blocks or bundle integrity blocks, | ||||
making them immutable. | ||||
7.3. Text Representation Compatibility | ||||
The textual representation of ipn URIs is not forwards-compatible | ||||
with [RFC9171], therefore care must be taken when deploying | ||||
implementations or tooling that use the textural representation of | ||||
ipn URIs and support for non-default Allocator Identifiers is | ||||
required. For example Section 4.6 of [RFC9174] specifies that the | ||||
Session Initialization message "...SHALL contain the UTF-8 encoded | ||||
node ID of the entity that sent the SESS_INIT message." In such | ||||
cases the considerations that apply to the use of the 3-element CBOR | ||||
encoding also apply to the text representation when a non-default | ||||
Allocator Identifier is present. | ||||
7.4. Bundle Protocol Version 6 Compatibility | ||||
This document updates the use of ipn EIDs for BPv7, however the ipn | ||||
URI scheme was originally defined for use with version 6 of the | ||||
Bundle Protocol (BPv6). This document does not update any of the | ||||
behaviors, wire-formats or mechanisms of BPv6. Therefore, ipn EIDs | ||||
with non-default Allocator Identifiers MUST NOT be used with BPv6, | ||||
and the Allocator Identifier prefix MUST be omitted from any textural | ||||
representation. It should be noted that BPv6 has no concept of | ||||
LocalNode EIDs, and will therefore treat such EIDs as routable. | ||||
7.5. Late Binding | ||||
[RFC9171] mandates the concept of "late binding" of an EID, whereby | ||||
the address of the destination of a bundle is resolved from its | the address of the destination of a bundle is resolved from its | |||
identifier hop by hop as it transits a DTN. This per-hop binding of | identifier hop-by-hop as it transits a BPv7 network. This per-hop | |||
identifiers to addresses underlines the fact that EIDs are purely | binding of identifiers to addresses underlines the fact that EIDs are | |||
names, and should not carry any implicit or explicit information | purely names, and should not carry any implicit or explicit | |||
concerning the current location or reachability of an identified node | information concerning the current location or reachability of an | |||
and service. This removes the need to rename a node as its location | identified node and service. This removes the need to rename a node | |||
changes. | as its location changes. | |||
The concept of "late binding" is preserved in this ipn URI scheme. | The concept of "late binding" is preserved in this ipn URI scheme. | |||
Elements of an ipn URI SHOULD NOT be regarded as carrying information | Elements of an ipn URI MUST NOT be regarded as carrying information | |||
relating to location, reachability, or other addressing/routing | relating to location, reachability, or other addressing/routing | |||
concern. | concern. | |||
An example of incorrect behaviour would be to assume that a given | An example of incorrect behavior would be to assume that a given | |||
Allocator assigns Node Numbers derived from link-layer addresses and | Allocator assigns Node Numbers derived from link-layer addresses and | |||
to interpret the Node Number component of an ipn URI directly as a | to interpret the Node Number component of an ipn URI directly as a | |||
link-layer address. No matter the mechanism an Allocator uses for | link-layer address. No matter the mechanism an Allocator uses for | |||
the assignment of Node Numbers, they remain just numbers, without | the assignment of Node Numbers, they remain just numbers, without | |||
additional meaning. | additional meaning. | |||
8. Security Considerations | 8. Security Considerations | |||
This section updates the security considerations from | This section updates the security considerations from | |||
Section 4.2.5.1.2 of [RFC9171] to account for the inclusion of | Section 4.2.5.1.2 of [RFC9171] to account for the inclusion of | |||
Allocator Identifiers in the ipn URI scheme. | Allocator Identifiers in the ipn URI scheme when used with BPv7. | |||
8.1. Reliability and consistency | 8.1. Reliability and consistency | |||
None of the BP endpoints identified by ipn EIDs are guaranteed to be | None of the BPv7 endpoints identified by ipn EIDs are guaranteed to | |||
reachable at any time, and the identity of the processing entities | be reachable at any time, and the identity of the processing entities | |||
operating on those endpoints is never guaranteed by the Bundle | operating on those endpoints is never guaranteed by the Bundle | |||
Protocol itself. Verification of the signature provided by the Block | Protocol itself. Verification of the signature provided by the Block | |||
Integrity Block targeting the bundle's primary block, as defined by | Integrity Block targeting the bundle's primary block, as defined by | |||
Bundle Protocol Security [RFC9172], is required for this purpose. | Bundle Protocol Security [RFC9172], is required for this purpose. | |||
8.2. Malicious construction | 8.2. Malicious construction | |||
Malicious construction of a conformant ipn URI is limited to the | Malicious construction of a conformant ipn URI is limited to the | |||
malicious selection of Allocator Identifiers, Node Numbers, and | malicious selection of Allocator Identifiers, Node Numbers, and | |||
Service Numbers. That is, a maliciously constructed ipn EID could be | Service Numbers. That is, a maliciously constructed ipn EID could be | |||
used to direct a bundle to an endpoint that might be damaged by the | used to direct a bundle to an endpoint that might be damaged by the | |||
arrival of that bundle or, alternatively, to declare a false source | arrival of that bundle or, alternatively, to declare a false source | |||
for a bundle and thereby cause incorrect processing at a node that | for a bundle and thereby cause incorrect processing at a node that | |||
receives the bundle. In both cases (and indeed in all bundle | receives the bundle. In both cases (and indeed in all bundle | |||
processing), the node that receives a bundle should verify its | processing), the node that receives a bundle should verify its | |||
authenticity and validity before operating on it in any way. | authenticity and validity before operating on it in any way, such as | |||
the use of BPSec [RFC9172], and TCPCLv4 with TLS [RFC9174]. | ||||
8.3. Back-end transcoding | 8.3. Back-end transcoding | |||
The limited expressiveness of URIs of the ipn scheme effectively | The limited expressiveness of URIs of the ipn scheme effectively | |||
eliminates the possibility of threat due to errors in back-end | eliminates the possibility of threat due to errors in back-end | |||
transcoding. | transcoding. | |||
8.4. Rare IP address formats | 8.4. Local and Private Use ipn EIDs | |||
Not relevant, as IP addresses do not appear anywhere in conformant | Both LocalNode (Section 3.4.2) and Private Use (Section 3.4.3) ipn | |||
ipn URIs. | URIs present a risk to the stability of deployed BPv7 networks. If | |||
either type of ipn URI are allowed to propagate beyond the domain in | ||||
which they are valid, then the required uniqueness of ipn URIs no | ||||
longer holds, and this fact can be abused by a malicious node to | ||||
prevent the correct functioning of the network as a whole. | ||||
See LocalNode ipn EIDs (Section 5.4) and Private Use ipn EIDs | ||||
(Section 5.5) for required behaviors to mitigate against this form of | ||||
abuse. | ||||
8.5. Sensitive information | 8.5. Sensitive information | |||
Because ipn URIs are used only to represent the numeric identities of | Because ipn URIs are used only to represent the numeric identities of | |||
resources, the risk of disclosure of sensitive information due to | resources, the risk of disclosure of sensitive information due to | |||
interception of these URIs is minimal. Examination of ipn EIDs could | interception of these URIs is minimal. Examination of ipn URIs could | |||
be used to support traffic analysis; where traffic analysis is a | be used to support traffic analysis; where traffic analysis is a | |||
plausible danger, bundles should be conveyed by secure convergence- | plausible danger, bundles should be conveyed by secure convergence- | |||
layer protocols that do not expose endpoint IDs. | layer protocols that do not expose endpoint IDs, such as TCPCLv4 | |||
[RFC9174]. | ||||
8.6. Semantic attacks | 8.6. Semantic attacks | |||
The simplicity of ipn URI scheme syntax minimizes the possibility of | The simplicity of ipn URI scheme syntax minimizes the possibility of | |||
misinterpretation of a URI by a human user. | misinterpretation of a URI by a human user. | |||
9. IANA Considerations | 9. IANA Considerations | |||
The following sections detail requests to IANA for the creation of | The following sections detail requests to IANA for the creation of | |||
two new registries, and the renaming of an existing registry. | two new registries, and the renaming of an existing registry. | |||
IANA is requested to update the reference to the 'ipn' scheme in the | ||||
"Uniform Resource Identifier (URI) Schemes" registry to this | ||||
document. | ||||
IANA is requested to add the new registries, and relocate the | ||||
existing registries under the "Uniform Resource Identifier (URI) | ||||
Schemes" protocol registry. | ||||
9.1. 'ipn' Scheme URI Allocator Identifiers registry | 9.1. 'ipn' Scheme URI Allocator Identifiers registry | |||
IANA is requested to create a new registry entitled "'ipn' Scheme URI | IANA is requested to create a new registry entitled "'ipn' Scheme URI | |||
Allocator Identifiers". The registration policy for this registry, | Allocator Identifiers". The registration policy for this registry, | |||
using terms defined in [RFC8126], is: | using terms defined in [RFC8126], is: | |||
+================+==================================================+ | +========================+============================+ | |||
| Range | Registration Policy | | | Range | Registration Policy | | |||
+================+==================================================+ | +========================+============================+ | |||
| 0 .. 2^16-1 | Expert Review, Single Allocator Identifiers only | | | 0..0xFFFF | Expert Review, Single | | |||
+----------------+--------------------------------------------------+ | | | Allocator Identifiers only | | |||
| 2^16 .. | Expert Review | | +------------------------+----------------------------+ | |||
| 2^30-1 | | | | 0x10000..0x3FFFFFFF | Expert Review | | |||
+----------------+--------------------------------------------------+ | +------------------------+----------------------------+ | |||
| 2^30 .. | Experimental Use | | | 0x40000000..0x7FFFFFFF | Experimental Use | | |||
| 2^31-1 | | | +------------------------+----------------------------+ | |||
+----------------+--------------------------------------------------+ | | 0x80000000..0xFFFFFFFF | Reserved, Future Expansion | | |||
| 2^31 .. | Reserved, Future Expansion | | +------------------------+----------------------------+ | |||
| 2^32-1 | | | | >= 2^32 | Reserved | | |||
+----------------+--------------------------------------------------+ | +------------------------+----------------------------+ | |||
| >= 2^32 | Reserved | | ||||
+----------------+--------------------------------------------------+ | ||||
Table 2: 'ipn' Scheme URI Numbering Allocator Identifiers | Table 2: 'ipn' Scheme URI Numbering Allocator | |||
registration policies | Identifiers registration policies | |||
Each entry in this registry associates one or more Allocator | Each entry in this registry associates one or more Allocator | |||
Identifiers with a single organization. Within the registry, the | Identifiers with a single organization. Within the registry, the | |||
organization is identified using the "Name" and "Point of Contact" | organization is identified using the "Name" and "Point of Contact" | |||
fields. It is expected that each identified organization publishes | fields. It is expected that each identified organization publishes | |||
some listing of allocated node numbers - the pointer to which is | some listing of allocated node numbers - the pointer to which is | |||
listed in the "Reference" field of the registry. | listed in the "Reference" field of the registry. | |||
Note that the “Single Allocator Identifiers only” language in | Note that the “Single Allocator Identifiers only” language in | |||
Registration Policy for this registry indicates that, within the | Registration Policy for this registry indicates that, within the | |||
indicated range, the allocation of a sequence of consecutive | indicated range, the allocation of a sequence of consecutive | |||
Allocator identifiers to a single organization is prohibited. | Allocator identifiers to a single organization is prohibited. IANA | |||
is requested to note this in the registration policy for this | ||||
registry. | ||||
The initial values for the registry are: | The initial values for the registry are: | |||
+=================+========+=========+========+===========+=========+ | +=================+========+=========+========+===========+=========+ | |||
| Name | Range | Range | Range | Reference | Point | | | Name | Range | Range | Range | Reference | Point | | |||
| | (dec) | (hex) | Length | | of | | | | (dec) | (hex) | Length | | of | | |||
| | | | (Bits) | | Contact | | | | | | (Bits) | | Contact | | |||
+=================+========+=========+========+===========+=========+ | +=================+========+=========+========+===========+=========+ | |||
| Default | 0 | 0x0 | 0 | This | IANA | | | Default | 0 | 0x0 | 0 | This | IANA | | |||
| Allocator | | | | document | | | | Allocator | | | | document | | | |||
| (Section | | | | | | | | (Section | | | | | | | |||
| 3.2.2) | | | | | | | | 3.2.2) | | | | | | | |||
+-----------------+--------+---------+--------+-----------+---------+ | +-----------------+--------+---------+--------+-----------+---------+ | |||
| Example | 974848 | 0xEE000 | 12 | This | IANA | | | Example | 974848 | 0xEE000 | 12 | This | IANA | | |||
| Range | .. | .. | bits | document | | | | Range | .. | .. | bits | document | | | |||
| | 978943 | 0xEEFFF | | | | | | | 978943 | 0xEEFFF | | | | | |||
+-----------------+--------+---------+--------+-----------+---------+ | +-----------------+--------+---------+--------+-----------+---------+ | |||
Table 3: 'ipn' Scheme URI Allocator Identifiers initial values | Table 3: 'ipn' Scheme URI Allocator Identifiers initial values | |||
The "Example Range" is assigned for use in examples in documentation. | The "Example Range" is assigned for use in examples in documentation | |||
and sample code. | ||||
9.1.1. Guidance for Designated Experts | 9.1.1. Guidance for Designated Experts | |||
Due to the nature of the CBOR encoding used for Allocator Identifiers | Due to the nature of the CBOR encoding of unsigned integers used for | |||
with BPv7, Allocator Identifiers with a low value number are encoded | Allocator Identifiers with BPv7, Allocator Identifiers with a low | |||
more efficiently than larger numbers. This makes low value Allocator | value number are encoded more efficiently than larger numbers. This | |||
Identifiers more desirable than larger Allocator Identifiers, and | makes low value Allocator Identifiers more desirable than larger | |||
therefore care must be taken when assigning Allocator Identifier | Allocator Identifiers, and therefore care must be taken when | |||
ranges to ensure that a single applicant is not granted a large | assigning Allocator Identifier ranges to ensure that a single | |||
swathe of highly desirable numbers at the expense of other | applicant is not granted a large swathe of highly desirable numbers | |||
applicants. To this end, Designated Experts are strongly recommended | at the expense of other applicants. To this end, Designated Experts | |||
to familiarize themselves with the CBOR encoding of unsigned integers | are strongly recommended to familiarize themselves with the CBOR | |||
in [RFC8949]. | encoding of unsigned integers in [RFC8949]. | |||
9.2. 'ipn' Scheme URI Default Allocator Node Numbers registry | 9.2. 'ipn' Scheme URI Default Allocator Node Numbers registry | |||
IANA is requested to rename the "CBHE Node Numbers" registry defined | IANA is requested to rename the "CBHE Node Numbers" registry defined | |||
in Section 3.2.1 of [RFC7116] to the "'ipn' Scheme URI Default | in Section 3.2.1 of [RFC7116] to the "'ipn' Scheme URI Default | |||
Allocator Node Numbers" registry. | Allocator Node Numbers" registry. | |||
The registration policy for this registry, using terms defined in | The registration policy for this registry, using terms defined in | |||
[RFC8126], is updated to be: | [RFC8126], is updated to be: | |||
+================+=================================================+ | +====================+=============================================+ | |||
| Range | Registration Policy | | | Range | Registration Policy | | |||
+================+=================================================+ | +====================+=============================================+ | |||
| 0 | Reserved for the Null ipn URI (Section 3.1) | | | 0 | Reserved for the Null ipn URI (Section 3.1) | | |||
+----------------+-------------------------------------------------+ | +--------------------+---------------------------------------------+ | |||
| 1 .. 2^14-1 | Private Use | | | 1..0x3FFF | Private Use | | |||
+----------------+-------------------------------------------------+ | +--------------------+---------------------------------------------+ | |||
| 2^14 .. 2^32-2 | Expert Review | | | 0x4000..0xFFFFFFFE | Expert Review | | |||
+----------------+-------------------------------------------------+ | +--------------------+---------------------------------------------+ | |||
| 2^32-1 | Reserved for LocalNode ipn URIs (Section 3.4.2) | | | 0xFFFFFFFF | Reserved for LocalNode ipn URIs | | |||
+----------------+-------------------------------------------------+ | | | (Section 3.4.2) | | |||
| >= 2^32 | Invalid | | +--------------------+---------------------------------------------+ | |||
+----------------+-------------------------------------------------+ | | >= 2^32 | Invalid | | |||
+--------------------+---------------------------------------------+ | ||||
Table 4: 'ipn' Scheme URI Default Allocator Node Numbers | Table 4: 'ipn' Scheme URI Default Allocator Node Numbers | |||
registration policies | registration policies | |||
As IANA is requested to only rename the registry, all existing | As IANA is requested to only rename the registry, all existing | |||
registrations will remain. | registrations will remain. | |||
9.3. 'ipn' Scheme URI Well-known Service Numbers for BPv7 registry | 9.3. 'ipn' Scheme URI Well-known Service Numbers for BPv7 registry | |||
IANA is requested to create a new registry entitled "'ipn' Scheme URI | IANA is requested to create a new registry entitled "'ipn' Scheme URI | |||
Well-known Service Numbers for BPv7" registry. The registration | Well-known Service Numbers for BPv7" registry. The registration | |||
policy for this registry, using terms defined in [RFC8126], is: | policy for this registry, using terms defined in [RFC8126], is: | |||
+===========+=================================+ | +=====================+=================================+ | |||
| Range | Registration Policy | | | Range | Registration Policy | | |||
+===========+=================================+ | +=====================+=================================+ | |||
| 0 | Reserved for the Administrative | | | 0 | Reserved for the Administrative | | |||
| | Endpoint (Section 5.7) | | | | Endpoint (Section 5.7) | | |||
+-----------+---------------------------------+ | +---------------------+---------------------------------+ | |||
| 1..127 | Private Use | | | 1..127 | Private Use | | |||
+-----------+---------------------------------+ | +---------------------+---------------------------------+ | |||
| 128..255 | Standards Action | | | 128..255 | Standards Action | | |||
+-----------+---------------------------------+ | +---------------------+---------------------------------+ | |||
| 0x0100 .. | Private Use | | | 0x0100..0x7FFF | Private Use | | |||
| 0x7FFF | | | +---------------------+---------------------------------+ | |||
+-----------+---------------------------------+ | | 0x8000..0xFFFF | Specification Required | | |||
| 0x8000 .. | Specification Required | | +---------------------+---------------------------------+ | |||
| 0xFFFF | | | | 0x10000..0xFFFFFFFF | Private Use | | |||
+-----------+---------------------------------+ | +---------------------+---------------------------------+ | |||
| 2^16 .. | Private Use | | | >= 2^32 | Reserved for future expansion | | |||
| 2^32-1 | | | +---------------------+---------------------------------+ | |||
+-----------+---------------------------------+ | ||||
| >= 2^32 | Reserved for future expansion | | ||||
+-----------+---------------------------------+ | ||||
Table 5: 'ipn' Scheme URI Well-known | Table 5: 'ipn' Scheme URI Well-known Service Numbers | |||
Service Numbers for BPv7 registration | for BPv7 registration policies | |||
policies | ||||
The initial values for the registry are: | The initial values for the registry are: | |||
+===========+========================+===============+ | +===========+========================+===============+ | |||
| Value | Description | Reference | | | Value | Description | Reference | | |||
+===========+========================+===============+ | +===========+========================+===============+ | |||
| 0 | The Administrative | [RFC9171], | | | 0 | The Administrative | [RFC9171], | | |||
| | Endpoint (Section 5.7) | This document | | | | Endpoint (Section 5.7) | This document | | |||
+-----------+------------------------+---------------+ | +-----------+------------------------+---------------+ | |||
| 0xEEE0 .. | Example Range | This document | | | 0xEEE0 .. | Example Range | This document | | |||
| 0xEEEF | | | | | 0xEEEF | | | | |||
+-----------+------------------------+---------------+ | +-----------+------------------------+---------------+ | |||
Table 6: 'ipn' Scheme URI Well-known Service | Table 6: 'ipn' Scheme URI Well-known Service | |||
Numbers for BPb7 initial values | Numbers for BPv7 initial values | |||
The "Example Range" is assigned for use in examples in documentation. | The "Example Range" is assigned for use in examples in documentation | |||
and sample code. | ||||
9.3.1. Guidance for Designated Experts | 9.3.1. Guidance for Designated Experts | |||
This registry is intended to record the default Service Numbers for | This registry is intended to record the default Service Numbers for | |||
well-known, interoperable services available and of use to the entire | well-known, interoperable services available and of use to the entire | |||
BPv7 community, hence all ranges not marked for Private Use MUST have | BPv7 community, hence all ranges not marked for Private Use MUST have | |||
a corresponding publicly available specification describing how one | a corresponding publicly available specification describing how one | |||
interfaces with the service. | interfaces with the service. | |||
Services that are specific to a particular deployment or co-operation | Services that are specific to a particular deployment or co-operation | |||
skipping to change at page 23, line 31 ¶ | skipping to change at page 27, line 23 ¶ | |||
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | |||
Requirement Levels", BCP 14, RFC 2119, | Requirement Levels", BCP 14, RFC 2119, | |||
DOI 10.17487/RFC2119, March 1997, | DOI 10.17487/RFC2119, March 1997, | |||
<https://www.rfc-editor.org/rfc/rfc2119>. | <https://www.rfc-editor.org/rfc/rfc2119>. | |||
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax | [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax | |||
Specifications: ABNF", STD 68, RFC 5234, | Specifications: ABNF", STD 68, RFC 5234, | |||
DOI 10.17487/RFC5234, January 2008, | DOI 10.17487/RFC5234, January 2008, | |||
<https://www.rfc-editor.org/rfc/rfc5234>. | <https://www.rfc-editor.org/rfc/rfc5234>. | |||
[RFC6260] Burleigh, S., "Compressed Bundle Header Encoding (CBHE)", | ||||
RFC 6260, DOI 10.17487/RFC6260, May 2011, | ||||
<https://www.rfc-editor.org/rfc/rfc6260>. | ||||
[RFC7116] Scott, K. and M. Blanchet, "Licklider Transmission | ||||
Protocol (LTP), Compressed Bundle Header Encoding (CBHE), | ||||
and Bundle Protocol IANA Registries", RFC 7116, | ||||
DOI 10.17487/RFC7116, February 2014, | ||||
<https://www.rfc-editor.org/rfc/rfc7116>. | ||||
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for | [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for | |||
Writing an IANA Considerations Section in RFCs", BCP 26, | Writing an IANA Considerations Section in RFCs", BCP 26, | |||
RFC 8126, DOI 10.17487/RFC8126, June 2017, | RFC 8126, DOI 10.17487/RFC8126, June 2017, | |||
<https://www.rfc-editor.org/rfc/rfc8126>. | <https://www.rfc-editor.org/rfc/rfc8126>. | |||
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC | [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC | |||
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, | 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, | |||
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>. | May 2017, <https://www.rfc-editor.org/rfc/rfc8174>. | |||
[RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data | [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data | |||
skipping to change at page 24, line 30 ¶ | skipping to change at page 28, line 30 ¶ | |||
[RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing | [RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing | |||
(CIDR): The Internet Address Assignment and Aggregation | (CIDR): The Internet Address Assignment and Aggregation | |||
Plan", BCP 122, RFC 4632, DOI 10.17487/RFC4632, August | Plan", BCP 122, RFC 4632, DOI 10.17487/RFC4632, August | |||
2006, <https://www.rfc-editor.org/rfc/rfc4632>. | 2006, <https://www.rfc-editor.org/rfc/rfc4632>. | |||
[RFC5050] Scott, K. and S. Burleigh, "Bundle Protocol | [RFC5050] Scott, K. and S. Burleigh, "Bundle Protocol | |||
Specification", RFC 5050, DOI 10.17487/RFC5050, November | Specification", RFC 5050, DOI 10.17487/RFC5050, November | |||
2007, <https://www.rfc-editor.org/rfc/rfc5050>. | 2007, <https://www.rfc-editor.org/rfc/rfc5050>. | |||
[RFC6260] Burleigh, S., "Compressed Bundle Header Encoding (CBHE)", | ||||
RFC 6260, DOI 10.17487/RFC6260, May 2011, | ||||
<https://www.rfc-editor.org/rfc/rfc6260>. | ||||
[RFC7116] Scott, K. and M. Blanchet, "Licklider Transmission | ||||
Protocol (LTP), Compressed Bundle Header Encoding (CBHE), | ||||
and Bundle Protocol IANA Registries", RFC 7116, | ||||
DOI 10.17487/RFC7116, February 2014, | ||||
<https://www.rfc-editor.org/rfc/rfc7116>. | ||||
[RFC9172] Birrane, III, E. and K. McKeever, "Bundle Protocol | [RFC9172] Birrane, III, E. and K. McKeever, "Bundle Protocol | |||
Security (BPSec)", RFC 9172, DOI 10.17487/RFC9172, January | Security (BPSec)", RFC 9172, DOI 10.17487/RFC9172, January | |||
2022, <https://www.rfc-editor.org/rfc/rfc9172>. | 2022, <https://www.rfc-editor.org/rfc/rfc9172>. | |||
Appendix A. ipn URI Scheme Text Syntax | [RFC9174] Sipos, B., Demmer, M., Ott, J., and S. Perreault, "Delay- | |||
Tolerant Networking TCP Convergence-Layer Protocol Version | ||||
The text syntax of an ipn URI MUST comply with the following ABNF | 4", RFC 9174, DOI 10.17487/RFC9174, January 2022, | |||
[RFC5234] syntax, including the core ABNF syntax rule for DIGIT | <https://www.rfc-editor.org/rfc/rfc9174>. | |||
defined by that specification: | ||||
ipn-uri = "ipn:" ipn-hier-part | ||||
ipn-hier-part = fqnn "." service-number | ||||
fqnn = "!" / allocator-part | ||||
allocator-part = [allocator-identifier "."] node-number | ||||
allocator-identifier = non-zero-number | ||||
node-number = number | ||||
service-number = number | ||||
number = "0" / non-zero-number | ||||
non-zero-number = (%x31-39 *DIGIT) | ||||
Appendix B. ipn URI Scheme Text Representation Examples | Appendix A. ipn URI Scheme Text Representation Examples | |||
This section provides some example ipn URIs in their textual | This section provides some example ipn URIs in their textual | |||
representation. | representation. | |||
B.1. Using the Default Allocator | A.1. Using the Default Allocator | |||
Consider the ipn URI identifying Service Number 2 on Node Number 1 | Consider the ipn URI identifying Service Number 2 on Node Number 1 | |||
allocated by the Default Allocator (Section 3.2.2) (0). | allocated by the Default Allocator (Section 3.2.2) (0). | |||
The complete seven character representation of this URI would be as | The recommended seven character representation of this URI would be | |||
follows: | as follows: | |||
ipn:1.2 | ipn:1.2 | |||
The nine character representation of this URI, with explicit the | ||||
Allocator Identifier, would be as follows: | ||||
B.2. Using a non-default Allocator | ipn:0.1.2 | |||
Consider the ipn URI identifying Service Number 1 on Node Number 1 | A.2. Using a non-default Allocator | |||
Consider the ipn URI identifying Service Number 3 on Node Number 1 | ||||
allocated by Allocator 977000. | allocated by Allocator 977000. | |||
The complete 14 character representation of this URI would be as | The 14 character representation of this URI would be as follows: | |||
follows: | ||||
ipn:977000.1.2 | ipn:977000.1.3 | |||
B.3. The Null ipn URI | A.3. The Null ipn URI | |||
The Null ipn URI (Section 3.1) is represented as: | The Null ipn URI (Section 3.1) is represented as: | |||
ipn:0.0 | ipn:0.0 | |||
B.4. A LocalNode ipn URI | A.4. A LocalNode ipn URI | |||
Consider the ipn URI identifying Service Number 7 on the local node. | Consider the ipn URI identifying Service Number 7 on the local node. | |||
The complete seven character representation of this URI would be as | The recommended seven character representation of this URI would be | |||
follows: | as follows: | |||
ipn:!.7 | ipn:!.7 | |||
Appendix C. ipn URI Scheme CBOR Encoding | The numeric 16 character representation of this URI would be as | |||
follows: | ||||
A BPv7 endpoint identified by an ipn URI, when encoded in Concise | ||||
Binary Object Representation (CBOR) [RFC8949], MUST comply with the | ||||
following Concise Data Definition Language (CDDL) [RFC8610] | ||||
specification: | ||||
eid = $eid .within eid-structure | ||||
eid-structure = [ | ||||
uri-code: uint, | ||||
SSP: any | ||||
] | ||||
; ... Syntax for other uri-code values defined in RFC9171 ... | ||||
$eid /= [ | ||||
uri-code: 2, | ||||
SSP: ipn-ssp2 / ipn-ssp3 | ||||
] | ||||
ipn-ssp2 = [ | ||||
fqnn: uint, ; packed value | ||||
service-number: uint | ||||
] | ||||
ipn-ssp3 = [ | ||||
authority-number: uint .lt 4294967296, | ||||
node-number: uint .lt 4294967296, | ||||
service-number: uint | ||||
] | ||||
Note: The node-number component will be the numeric representation of | ipn:4294967295.7 | |||
the concatenation of the Allocator Identifier and Node Number when | ||||
the 2-element encoding scheme has been used. | ||||
Appendix D. ipn URI Scheme CBOR Encoding Examples | Appendix B. ipn URI Scheme CBOR Encoding Examples | |||
This section provides some example CBOR encodings of ipn EIDs. | This section provides some example CBOR encodings of ipn EIDs. | |||
D.1. Using the Default Allocator | B.1. Using the Default Allocator | |||
Consider the ipn EID ipn:1.1. This textual representation of an ipn | Consider the ipn EID ipn:1.1. This textual representation of an ipn | |||
EID identifies Service Number 1 on Node Number 1 allocated by the | EID identifies Service Number 1 on Node Number 1 allocated by the | |||
Default Allocator (Section 3.2.2) (0). | Default Allocator (Section 3.2.2) (0). | |||
The complete five octet encoding of this EID using the two-element | The recommended five octet encoding of this EID using the two-element | |||
scheme-specific encoding would be as follows: | scheme-specific encoding would be as follows: | |||
82 # 2-Element Endpoint Encoding | 82 # 2-Element Endpoint Encoding | |||
02 # uri-code: 2 (IPN URI scheme) | 02 # uri-code: 2 (IPN URI scheme) | |||
82 # 2 Element ipn EID scheme-specific encoding | 82 # 2 Element ipn EID scheme-specific encoding | |||
01 # Node Number | 01 # Node Number | |||
01 # Service Number | 01 # Service Number | |||
The complete six octet encoding of this EID using the three-element | The six octet encoding of this EID using the three-element scheme- | |||
scheme-specific encoding would be as follows: | specific encoding would be as follows: | |||
82 # 2-Element Endpoint Encoding | 82 # 2-Element Endpoint Encoding | |||
02 # uri-code: 2 (IPN URI scheme) | 02 # uri-code: 2 (IPN URI scheme) | |||
83 # 3 Element ipn EID scheme-specific encoding | 83 # 3 Element ipn EID scheme-specific encoding | |||
00 # Default Allocator | 00 # Default Allocator | |||
01 # Node Number | 01 # Node Number | |||
01 # Service Number | 01 # Service Number | |||
D.2. Using a non-default Allocator | B.2. Using a non-default Allocator | |||
Consider the ipn EID ipn:977000.1.1. This textual representation of | Consider the ipn EID ipn:977000.1.1. This textual representation of | |||
an ipn EID identifies Service Number 1 on Node Number 1 allocated by | an ipn EID identifies Service Number 1 on Node Number 1 allocated by | |||
Allocator 977000. | Allocator 977000. | |||
The complete thirteen octet encoding of this EID using the two- | The recommended 10 octet encoding of this EID using the three-element | |||
element scheme-specific encoding would be as follows: | ||||
82 # 2-Element Endpoint Encoding | ||||
02 # uri-code: 2 (IPN URI scheme) | ||||
82 # 2 Element ipn EID scheme-specific encoding | ||||
1B 000EE86800000001 # Fully-qualified Node Number | ||||
01 # Service Number | ||||
The complete ten octet encoding of this EID using the three-element | ||||
scheme-specific encoding would be as follows: | scheme-specific encoding would be as follows: | |||
82 # 2-Element Endpoint Encoding | 82 # 2-Element Endpoint Encoding | |||
02 # uri-code: 2 (IPN URI scheme) | 02 # uri-code: 2 (IPN URI scheme) | |||
83 # 3 Element ipn EID scheme-specific encoding | 83 # 3 Element ipn EID scheme-specific encoding | |||
1A 000EE868 # Allocator Identifier | 1A 000EE868 # Allocator Identifier | |||
01 # Node Number | 01 # Node Number | |||
01 # Service Number | 01 # Service Number | |||
D.3. The 'null' Endpoint | The 13 octet encoding of this EID using the two-element scheme- | |||
specific encoding would be as follows: | ||||
82 # 2-Element Endpoint Encoding | ||||
02 # uri-code: 2 (IPN URI scheme) | ||||
82 # 2 Element ipn EID scheme-specific encoding | ||||
1B 000EE86800000001 # Fully-qualified Node Number | ||||
01 # Service Number | ||||
B.3. The 'null' Endpoint | ||||
The 'null' EID of ipn:0.0 can be encoded in the following ways: | The 'null' EID of ipn:0.0 can be encoded in the following ways: | |||
The complete five octet encoding of the 'null' ipn EID using the two- | The recommended five octet encoding of the 'null' ipn EID using the | |||
element scheme-specific encoding would be as follows: | two-element scheme-specific encoding would be as follows: | |||
82 # 2-Element Endpoint Encoding | 82 # 2-Element Endpoint Encoding | |||
02 # uri-code: 2 (IPN URI scheme) | 02 # uri-code: 2 (IPN URI scheme) | |||
82 # 2 Element ipn EID scheme-specific encoding | 82 # 2 Element ipn EID scheme-specific encoding | |||
00 # Node Number | 00 # Node Number | |||
00 # Service Number | 00 # Service Number | |||
The complete six octet encoding of the 'null'' ipn EID using the | The six octet encoding of the 'null' ipn EID using the three-element | |||
three-element scheme-specific encoding would be as follows: | scheme-specific encoding would be as follows: | |||
82 # 2-Element Endpoint Encoding | 82 # 2-Element Endpoint Encoding | |||
02 # uri-code: 2 (IPN URI scheme) | 02 # uri-code: 2 (IPN URI scheme) | |||
83 # 3 Element ipn EID scheme-specific encoding | 83 # 3 Element ipn EID scheme-specific encoding | |||
00 # Default Allocator | 00 # Default Allocator | |||
00 # Node Number | 00 # Node Number | |||
00 # Service Number | 00 # Service Number | |||
Acknowledgments | Acknowledgments | |||
skipping to change at page 28, line 51 ¶ | skipping to change at page 31, line 37 ¶ | |||
Electronics, and Ran Atkinson. | Electronics, and Ran Atkinson. | |||
Additionally, the authors wish to thank members of the CCSDS SIS-DTN | Additionally, the authors wish to thank members of the CCSDS SIS-DTN | |||
working group at large who provided useful review and commentary on | working group at large who provided useful review and commentary on | |||
this document and its implications for the future of networked space | this document and its implications for the future of networked space | |||
exploration. | exploration. | |||
Authors' Addresses | Authors' Addresses | |||
Rick Taylor | Rick Taylor | |||
Ori Industries | High Frontier Ltd | |||
Email: rick.taylor@ori.co | Email: rick.taylor@highfrontier.co.uk | |||
Ed Birrane | Ed Birrane | |||
JHU/APL | JHU/APL | |||
Email: Edward.Birrane@jhuapl.edu | Email: Edward.Birrane@jhuapl.edu | |||
End of changes. 108 change blocks. | ||||
378 lines changed or deleted | 518 lines changed or added | |||
This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |