draft-ietf-dtn-ipn-update-11.txt   draft-ietf-dtn-ipn-update-13.txt 
Delay/Disruption Tolerant Networking R. Taylor Delay/Disruption Tolerant Networking R. Taylor
Internet-Draft High Frontier Ltd 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 December 2024 4 June 2024 Expires: 4 January 2025 3 July 2024
Update to the ipn URI scheme Update to the ipn URI scheme
draft-ietf-dtn-ipn-update-11 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 clarify the when used as an Endpoint Identifier (EID) in Bundle Protocol Version
structure and behavior of the ipn URI scheme, define encodings of ipn 7 (BPv7) as defined in RFC 9171. These updates clarify the structure
and behavior of the ipn URI scheme, define new encodings of ipn
scheme URIs, and establish the registries necessary to manage this scheme URIs, and establish the registries necessary to manage this
scheme. 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
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 December 2024. This Internet-Draft will expire on 4 January 2025.
Copyright Notice Copyright Notice
Copyright (c) 2024 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 ipn EIDs . . . . . . . . . . . . . . . . . . 12 5.4. LocalNode ipn EIDs . . . . . . . . . . . . . . . . . . . 13
5.6. Well-known Service Numbers . . . . . . . . . . . . . . . 13 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 . . . . . . . . . . . . . . . . . . 14 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. Encoding Interoperability . . . . . . . . . . . . . . . . 17 7. Special Considerations . . . . . . . . . . . . . . . . . . . 19
7.3. Late Binding . . . . . . . . . . . . . . . . . . . . . . 18 7.1. Scheme Compatibility . . . . . . . . . . . . . . . . . . 19
8. Security Considerations . . . . . . . . . . . . . . . . . . . 18 7.2. CBOR Representation Interoperability . . . . . . . . . . 19
8.1. Reliability and consistency . . . . . . . . . . . . . . . 19 7.3. Text Representation Compatibility . . . . . . . . . . . . 20
8.2. Malicious construction . . . . . . . . . . . . . . . . . 19 7.4. Bundle Protocol Version 6 Compatibility . . . . . . . . . 21
8.3. Back-end transcoding . . . . . . . . . . . . . . . . . . 19 7.5. Late Binding . . . . . . . . . . . . . . . . . . . . . . 21
8.4. Local and Private Use ipn EIDs . . . . . . . . . . . . . 19 8. Security Considerations . . . . . . . . . . . . . . . . . . . 21
8.5. Sensitive information . . . . . . . . . . . . . . . . . . 19 8.1. Reliability and consistency . . . . . . . . . . . . . . . 21
8.6. Semantic attacks . . . . . . . . . . . . . . . . . . . . 20 8.2. Malicious construction . . . . . . . . . . . . . . . . . 22
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 8.3. Back-end transcoding . . . . . . . . . . . . . . . . . . 22
9.1. 'ipn' Scheme URI Allocator Identifiers registry . . . . . 20 8.4. Local and Private Use ipn EIDs . . . . . . . . . . . . . 22
9.1.1. Guidance for Designated Experts . . . . . . . . . . . 21 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 . . . . . . . . . . . . . . . . . . . . . . . . 22 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 . . . . . . . . . . . . . . . . . . . . . . . . 22 registry . . . . . . . . . . . . . . . . . . . . . . . . 25
9.3.1. Guidance for Designated Experts . . . . . . . . . . . 24 9.3.1. Guidance for Designated Experts . . . . . . . . . . . 26
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 27
10.1. Normative References . . . . . . . . . . . . . . . . . . 24 10.1. Normative References . . . . . . . . . . . . . . . . . . 27
10.2. Informative References . . . . . . . . . . . . . . . . . 25 10.2. Informative References . . . . . . . . . . . . . . . . . 28
Appendix A. ipn URI Scheme Text Syntax . . . . . . . . . . . . . 25 Appendix A. ipn URI Scheme Text Representation Examples . . . . 28
Appendix B. ipn URI Scheme Text Representation Examples . . . . 26 A.1. Using the Default Allocator . . . . . . . . . . . . . . . 28
B.1. Using the Default Allocator . . . . . . . . . . . . . . . 26 A.2. Using a non-default Allocator . . . . . . . . . . . . . . 29
B.2. Using a non-default Allocator . . . . . . . . . . . . . . 26 A.3. The Null ipn URI . . . . . . . . . . . . . . . . . . . . 29
B.3. The Null ipn URI . . . . . . . . . . . . . . . . . . . . 27 A.4. A LocalNode ipn URI . . . . . . . . . . . . . . . . . . . 29
B.4. A LocalNode ipn URI . . . . . . . . . . . . . . . . . . . 27 Appendix B. ipn URI Scheme CBOR Encoding Examples . . . . . . . 29
Appendix C. ipn URI Scheme CBOR Encoding . . . . . . . . . . . . 27 B.1. Using the Default Allocator . . . . . . . . . . . . . . . 29
Appendix D. ipn URI Scheme CBOR Encoding Examples . . . . . . . 28 B.2. Using a non-default Allocator . . . . . . . . . . . . . . 30
D.1. Using the Default Allocator . . . . . . . . . . . . . . . 28 B.3. The 'null' Endpoint . . . . . . . . . . . . . . . . . . . 30
D.2. Using a non-default Allocator . . . . . . . . . . . . . . 28 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 31
D.3. The 'null' Endpoint . . . . . . . . . . . . . . . . . . . 29 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29
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.
By updating [RFC7116] and [RFC9171], this document updates the By updating [RFC7116] and [RFC9171], this document updates the
specification of the ipn URI scheme, in a backwards-compatible way, specification of the ipn URI scheme, in a backwards-compatible way,
to provide needed improvements both in the scheme itself and its to provide needed improvements both in the scheme itself and its
usage to specify EIDs with BPv7. Specifically, this document usage to specify EIDs with BPv7. Specifically, this document
introduces a hierarchical structure for the assignment of ipn scheme introduces a hierarchical structure for the assignment of ipn scheme
URIs, clarifies the behavior and interpretation of ipn scheme URIs, URIs, clarifies the behavior and interpretation of ipn scheme URIs,
defines efficient encodings of ipn scheme URIs, and updates/defines defines efficient encodings of ipn scheme URIs, and updates/defines
the registries associated for this scheme. the registries associated for this scheme.
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 8, line 10 skipping to change at page 8, line 27
| 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.
skipping to change at page 8, line 34 skipping to change at page 9, line 7
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 by assigning 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) to the 'ipn' Scheme URI Allocator Identifiers registry (Section 9.1) to the
Default Allocator. In any case where an encoded ipn URI does not Default Allocator. In any case where an encoded ipn URI does not
explicitly include an Allocator Identifier, an implementation MUST explicitly include an Allocator Identifier, an implementation MUST
assume that the Node Number has been allocated by the Default assume that the Node Number has been allocated by the Default
Allocator. 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 10, line 20 skipping to change at page 10, line 40
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 Because of this lack of uniqueness, any implementation of a protocol
using ipn URIs that resides on the border between administrative using ipn URIs that resides on the border between administrative
domains must have suitable mechanisms in place to prevent protocol domains MUST have suitable mechanisms in place to prevent protocol
units using such "Private Use" Node Numbers to cross between units using such "Private Use" Node Numbers to cross between
different administrative domains. 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 '.' MAY 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 a 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 BPv6 experimental specification termed the logical bundle. The IRTF BPv6 experimental specification termed the logical
source or destination of a bundle as an "Endpoint" identified by an source or destination of a bundle as an "Endpoint" identified by an
"Endpoint Identifier" (EID). BPv6 EIDs are formatted as URIs. This "Endpoint Identifier" (EID). BPv6 EIDs are formatted as URIs. This
definition and representation of EIDs was carried forward from the definition and representation of EIDs was carried forward from the
IRTF BPv6 specification to the IETF BPv7 specification. BPv7 IRTF BPv6 specification to the IETF BPv7 specification. BPv7
skipping to change at page 11, line 51 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.
Equally, all externally received bundles featuring LocalNode EIDs as Equally, all externally received bundles featuring LocalNode EIDs as
a bundle source or bundle destination MUST be discarded as invalid. a bundle source or bundle destination MUST be discarded as invalid.
LocalNode ipn EIDs SHOULD NOT be present in any other part of a LocalNode ipn EIDs MUST NOT be present in any other part of a bundle
bundle that is transmitted off of the local node. For example, a that is transmitted off of the local node. For example, a LocalNode
LocalNode ipn EID SHOULD NOT be used as a Bundle Protocol Security ipn EID MUST NOT be used as a Bundle Protocol Security [RFC9172]
[RFC9172] security source EID for a bundle transmitted from the local security source for a bundle transmitted from the local bundle node,
bundle node, because such a source EID would have no meaning at a because such a source EID would have no meaning at a downstream
downstream bundle node. 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 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) are not universally unique, and the Default Allocator (Section 3.2.2) are not universally unique, and
therefore are only valid within the scope of the current therefore are only valid within the scope of the current
administrative domain. This means that any bundle using a Private administrative domain. This means that any bundle using a Private
Use ipn EID as a bundle source or bundle destination MUST NOT be Use ipn EID as a bundle source or bundle destination MUST NOT be
allowed to cross administrative domains. All implementations that allowed to cross administrative domains. All implementations that
could be deployed as a gateway between administrative domains MUST be could be deployed as a gateway between administrative domains MUST be
sufficiently configurable to ensure that this is enforced, and sufficiently configurable to ensure that this is enforced, and
operators MUST ensure correct configuration. operators MUST ensure correct configuration.
Private Use ipn EIDs SHOULD NOT be present in any other part of a Private Use ipn EIDs MUST NOT be present in any other part of a
bundle that is destined for another administrative domain when the bundle that is destined for another administrative domain when the
lack of uniqueness prevents correct operation. For example, a lack of uniqueness prevents correct operation. For example, a
Private Use ipn EID SHOULD NOT be used as a Bundle Protocol Security Private Use ipn EID MUST NOT be used as a Bundle Protocol Security
[RFC9172] security source EID for a bundle, when the bundle is [RFC9172] security source for a bundle, when the bundle is destined
destined for a different administrative domain. 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 be 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
skipping to change at page 13, line 41 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 encoded with CBOR [RFC8949]. To meet this requirement, URI scheme is encoded with CBOR [RFC8949]. To meet this requirement,
this section describes the CBOR encoding and decoding approach for this section describes the CBOR encoding and decoding approach for
ipn EIDs. The formal definition of these encodings is presented in ipn EIDs. The formal definition of the CBOR representation is
Appendix C (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.
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 18 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 RFC9171-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 does not make this ipn URI three-element scheme-specific encoding does not make this ipn URI
scheme update forwards compatible. Existing software for which scheme update forwards-compatible. Existing implementations for
support of this update is desired MUST be updated to be able to which support of this update is desired MUST be updated to be able to
process non-default Allocator Identifiers and three-element scheme- process non-default Allocator Identifiers and three-element scheme-
specific encodings. It is RECOMMENDED that BPv7 implementations specific encodings. It is RECOMMENDED that BPv7 implementations
upgrade to process these new features to benefit from the scalability upgrade to process these new features to benefit from the scalability
provided by Allocator Identifiers and the encoding efficiencies provided by Allocator Identifiers and the encoding efficiencies
provided by the three-element encoding. provided by the three-element encoding.
7.2. Encoding Interoperability 7.2. CBOR Representation Interoperability
Care must be taken when deploying implementations that default to Care must be taken when deploying implementations that default to
using the three-element encoding in networks that include using the three-element encoding in networks that include
implementations that only support the two-element [RFC9171] encoding. implementations that only support the two-element [RFC9171] encoding.
Because the existing implementations will reject bundles that use the Because the existing implementations will reject bundles that use the
three-element encoding as malformed, correct forwarding of three-element encoding as malformed, correct forwarding of
semantically valid bundles will fail. Mitigation for this issue semantically valid bundles will fail. The used mitigation for this
depends on the nature of the interoperability required by the issue depends on the nature of the interoperability required by the
deployment. Techniques can include: deployment. Techniques can include:
* A configuration option indicating when an implementation must use * A configuration option indicating when an implementation must use
the two-element encoding for all ipn EIDs when processing bundles the two-element encoding for all ipn EIDs when processing bundles
destined to a given endpoint: This would be suitable when adding a destined to a given endpoint: This would be suitable when adding a
newer implementation to a network of existing implementations. newer implementation to a network of existing implementations.
* Selective bundle encapsulation, whereby bundles that are known to * Selective bundle encapsulation, whereby bundles that are known to
originate from implementations that do not support the three- originate from implementations that do not support the three-
element encoding are tunnelled across regions of the network that element encoding are tunnelled across regions of the network that
skipping to change at page 18, line 22 skipping to change at page 20, line 37
not. not.
* Transcoding bundles at intermediate nodes: [RFC9171] requires the * Transcoding bundles at intermediate nodes: [RFC9171] requires the
bundle primary block be immutable, and even if ipn EIDs in the bundle primary block be immutable, and even if ipn EIDs in the
primary block do not require rewriting, other blocks including the primary block do not require rewriting, other blocks including the
payload block may include ipn EIDs of which the transcoding node payload block may include ipn EIDs of which the transcoding node
is unaware. Additionally, bundle blocks may be covered by is unaware. Additionally, bundle blocks may be covered by
[RFC9172] bundle security blocks or bundle integrity blocks, [RFC9172] bundle security blocks or bundle integrity blocks,
making them immutable. making them immutable.
7.3. Late Binding 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 [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
skipping to change at page 19, line 24 skipping to change at page 22, line 15
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. Local and Private Use ipn EIDs 8.4. Local and Private Use ipn EIDs
Both LocalNode (Section 3.4.2) and Private Use (Section 3.4.3) ipn Both LocalNode (Section 3.4.2) and Private Use (Section 3.4.3) ipn
URIs present a risk to the stability of deployed BPv7 networks. If 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 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 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 longer holds, and this fact can be abused by a malicious node to
prevent the correct functioning of the network as a whole. prevent the correct functioning of the network as a whole.
See LocalNode ipn EIDs (Section 5.4) and Private Use ipn EIDs See LocalNode ipn EIDs (Section 5.4) and Private Use ipn EIDs
(Section 5.5) for required behaviours to mitigate against this form (Section 5.5) for required behaviors to mitigate against this form of
of abuse. 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 URIs 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 is the IANA is requested to update the reference to the 'ipn' scheme in the
"Uniform Resource Identifier (URI) Schemes" registry to this "Uniform Resource Identifier (URI) Schemes" registry to this
document. document.
IANA is requested to add the new registries, and relocate the IANA is requested to add the new registries, and relocate the
existing registries under the "Uniform Resource Identifier (URI) existing registries under the "Uniform Resource Identifier (URI)
Schemes" protocol registry. 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
skipping to change at page 21, line 43 skipping to change at page 24, line 36
| | 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. 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 |
skipping to change at page 24, 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 25, 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, and reiterates 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 = number
node-number = number
service-number = number
number = "0" / non-zero-number
non-zero-number = (%x31-39 *DIGIT)
DIGIT = %x30-39
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
A.2. Using a non-default Allocator
Consider the ipn URI identifying Service Number 3 on Node Number 1 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.3 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 = [
allocator-identifier: 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
 End of changes. 82 change blocks. 
317 lines changed or deleted 372 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/