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 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. 11 change blocks. | ||||
12 lines changed or deleted | 12 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. |