rfc9758v3.txt   rfc9758.txt 
Internet Engineering Task Force (IETF) R. Taylor Internet Engineering Task Force (IETF) R. Taylor
Request for Comments: 9758 Aalyria Technologies Request for Comments: 9758 Aalyria Technologies
Updates: 6260, 7116, 9171 E. Birrane Updates: 6260, 7116, 9171 E. Birrane, III
Category: Standards Track JHU/APL Category: Standards Track JHU/APL
ISSN: 2070-1721 March 2025 ISSN: 2070-1721 March 2025
Updates to the 'ipn' URI Scheme Updates to the 'ipn' URI Scheme
Abstract Abstract
This document updates the specification of the 'ipn' URI scheme This document updates the specification of the 'ipn' URI scheme
previously defined in RFC 6260 and the IANA registries established in previously defined in RFC 6260 and the IANA registries established in
RFC 7116. It also updates the rules for the encoding and decoding of RFC 7116. It also updates the rules for the encoding and decoding of
skipping to change at line 672 skipping to change at line 672
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 0xEE868_00000064. The (977000,100), which would be encoded as 0xEE868_00000064. The
resulting two-element array [0xEE868_00000064, 0x01] would be encoded resulting two-element array [0xEE868_00000064, 0x01] would be encoded
in CBOR as the following 11-octet sequence: in CBOR as the following 11-octet sequence:
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 encoding
1B 000EE86800000064 # Fully Qualified Node Number 1B 000EE86800000064 # Fully Qualified Node Number
01 # Service Number 01 # Service Number
The two-element scheme-specific encoding provides backwards The two-element scheme-specific encoding provides 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 encoding of the Node Number from the encoding of the FQNN and the encoding of the Node Number from
[RFC9171] are identical. [RFC9171] are identical.
skipping to change at line 700 skipping to change at line 700
2. the second element of the array is the Node Number, and 2. the second element of the array is the Node Number, and
3. the third element of the array is the Service Number. 3. the third element of the 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 following 9-octet sequence: as the following 9-octet sequence:
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 encoding
1A 000EE868 # Allocator Identifier 1A 000EE868 # Allocator Identifier
64 # Node Number 64 # Node Number
01 # Service 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, and implementations are RECOMMENDED to use this encoding Identifiers, and implementations are RECOMMENDED to use this encoding
scheme unless explicitly mitigating for interoperability issues; see scheme unless explicitly mitigating for interoperability issues; see
Section 7.1. Section 7.1.
skipping to change at line 941 skipping to change at line 941
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, such as authenticity and validity before operating on it in any way, such as
the use of BPSec [RFC9172] and TCP Convergence Layer version 4 with the use of BPSec [RFC9172] and TCP Convergence Layer version 4
(TCPCLv4) with TLS [RFC9174]. (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 threats due to errors in back-end eliminates the possibility of threats due to errors in back-end
transcoding. transcoding.
8.4. Local and Private Use ipn EIDs 8.4. Local and Private Use ipn EIDs
skipping to change at line 1007 skipping to change at line 1007
| | Review | Identifiers only | | | Review | Identifiers only |
+------------------------+--------------+------------------+ +------------------------+--------------+------------------+
| 0x10000..0x3FFFFFFF | Expert | | | 0x10000..0x3FFFFFFF | Expert | |
| | Review | | | | Review | |
+------------------------+--------------+------------------+ +------------------------+--------------+------------------+
| 0x40000000..0x7FFFFFFF | Experimental | | | 0x40000000..0x7FFFFFFF | Experimental | |
| | Use | | | | Use | |
+------------------------+--------------+------------------+ +------------------------+--------------+------------------+
| 0x80000000..0xFFFFFFFF | Reserved | Future Expansion | | 0x80000000..0xFFFFFFFF | Reserved | Future Expansion |
+------------------------+--------------+------------------+ +------------------------+--------------+------------------+
| >= 2^32 | Reserved | | | >=0x100000000 | Reserved | |
+------------------------+--------------+------------------+ +------------------------+--------------+------------------+
Table 2: Registration Procedures for the 'ipn' Scheme Table 2: Registration Procedures for the 'ipn' Scheme
URI Allocator Identifiers Registry URI Allocator Identifiers Registry
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 "Change Controller" organization is identified using the "Name" and "Change Controller"
fields. It is expected that each identified organization will fields. It is expected that each identified organization will
publish some listing of allocated Node Numbers, the pointer to which publish some listing of allocated Node Numbers, the pointer to which
skipping to change at line 1081 skipping to change at line 1081
Using terms defined in [RFC8126], the registration procedures for Using terms defined in [RFC8126], the registration procedures for
this registry are: this registry are:
+====================+=========================+ +====================+=========================+
| Range | Registration Procedures | | Range | Registration Procedures |
+====================+=========================+ +====================+=========================+
| 1..0x3FFF | Private Use | | 1..0x3FFF | Private Use |
+--------------------+-------------------------+ +--------------------+-------------------------+
| 0x4000..0xFFFFFFFE | Expert Review | | 0x4000..0xFFFFFFFE | Expert Review |
+--------------------+-------------------------+ +--------------------+-------------------------+
| >= 2^32 | Invalid | | >=0x100000000 | Invalid |
+--------------------+-------------------------+ +--------------------+-------------------------+
Table 4: Registration Procedures for the Table 4: Registration Procedures for the
'ipn' Scheme URI Default Allocator Node 'ipn' Scheme URI Default Allocator Node
Numbers Registry Numbers Registry
IANA has registered the following values in the "'ipn' Scheme URI IANA has registered the following values in the "'ipn' Scheme URI
Default Allocator Node Numbers" registry: Default Allocator Node Numbers" registry:
+============+===============================+===================+ +============+===============================+===================+
skipping to change at line 1126 skipping to change at line 1126
| 1..127 | Private Use | | 1..127 | Private Use |
+---------------------+-------------------------------+ +---------------------+-------------------------------+
| 128..255 | Standards Action | | 128..255 | Standards Action |
+---------------------+-------------------------------+ +---------------------+-------------------------------+
| 0x0100..0x7FFF | Private Use | | 0x0100..0x7FFF | Private Use |
+---------------------+-------------------------------+ +---------------------+-------------------------------+
| 0x8000..0xFFFF | Specification Required | | 0x8000..0xFFFF | Specification Required |
+---------------------+-------------------------------+ +---------------------+-------------------------------+
| 0x10000..0xFFFFFFFF | Private Use | | 0x10000..0xFFFFFFFF | Private Use |
+---------------------+-------------------------------+ +---------------------+-------------------------------+
| >= 2^32 | Reserved for future expansion | | >=0x100000000 | Reserved for future expansion |
+---------------------+-------------------------------+ +---------------------+-------------------------------+
Table 6: Registration Procedures for the 'ipn' Table 6: Registration Procedures for the 'ipn'
Scheme URI Well-Known Service Numbers for BPv7 Scheme URI Well-Known Service Numbers for BPv7
Registry Registry
The initial values in the registry are: The initial values in the registry are:
+================+=============================+===================+ +================+=============================+===================+
| Value | Description | Reference | | Value | Description | Reference |
skipping to change at line 1304 skipping to change at line 1304
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 (0) (Section 3.2.2). Default Allocator (0) (Section 3.2.2).
The recommended 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 encoding
01 # Node Number 01 # Node Number
01 # Service Number 01 # Service Number
The six-octet encoding of this EID using the three-element scheme- The six-octet encoding of this EID using the three-element 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 encoding
00 # Default Allocator 00 # Default Allocator
01 # Node Number 01 # Node Number
01 # Service Number 01 # Service Number
B.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 recommended 10-octet encoding of this EID using the three-element The recommended 10-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 encoding
1A 000EE868 # Allocator Identifier 1A 000EE868 # Allocator Identifier
01 # Node Number 01 # Node Number
01 # Service Number 01 # Service Number
The 13-octet encoding of this EID using the two-element scheme- The 13-octet encoding of this EID using the two-element 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)
82 # 2-Element ipn EID scheme-specific encoding 82 # 2-Element ipn EID encoding
1B 000EE86800000001 # Fully Qualified Node Number 1B 000EE86800000001 # Fully Qualified Node Number
01 # Service Number 01 # Service Number
B.3. The Null Endpoint 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 recommended five-octet encoding of the Null ipn EID using the The recommended five-octet encoding of the Null ipn EID using the
two-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 encoding
00 # Node Number 00 # Node Number
00 # Service Number 00 # Service Number
The six-octet encoding of the Null ipn EID using the three-element The six-octet encoding of the Null ipn 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 encoding
00 # Default Allocator 00 # Default Allocator
00 # Node Number 00 # Node Number
00 # Service Number 00 # Service Number
Acknowledgments Acknowledgments
The following DTN Working Group participants contributed technical The following DTN Working Group participants contributed technical
material, use cases, and critical technical reviews for this URI material, use cases, and critical technical reviews for this URI
scheme update: Scott Burleigh of the IPNGROUP, Keith Scott, Brian scheme update: Scott Burleigh of the IPNGROUP, Keith Scott, Brian
Sipos of the Johns Hopkins University Applied Physics Laboratory, Sipos of the Johns Hopkins University Applied Physics Laboratory,
skipping to change at line 1385 skipping to change at line 1385
Working Group at large who provided useful reviews and commentary on Working Group at large who provided useful reviews 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
Aalyria Technologies Aalyria Technologies
Email: rtaylor@aalyria.com Email: rtaylor@aalyria.com
Ed Birrane Edward J. Birrane, III
JHU/APL The Johns Hopkins University Applied Physics Laboratory
Email: Edward.Birrane@jhuapl.edu Email: Edward.Birrane@jhuapl.edu
 End of changes. 14 change blocks. 
15 lines changed or deleted 15 lines changed or added

This html diff was produced by rfcdiff 1.48.