Updates to the 'ipn' URI Scheme
updates
Extracted elements (32)
Allocator Identifier ranges enable hierarchical delegation of Node Number assignment to sub-organizations, inspired by CIDR. Ranges must be power-of-2 sized (2^N) with the least-significant N bits of the first identifier all zero, allowing bitwise prefix matching to associate identifiers with an organization.
The late binding principle from RFC 9171 is preserved: elements of an ipn URI MUST NOT be regarded as carrying location, reachability, or routing information. Interpreting a Node Number as a link-layer address or other topological quantity (regardless of how an Allocator assigns numbers) would be incorrect.
ipn EIDs with non-default Allocator Identifiers MUST NOT be used with BPv6, and the Allocator Identifier prefix MUST be omitted from any textual representation used with BPv6. BPv6 has no concept of LocalNode EIDs and will treat such EIDs as routable.
RFC 9171-only implementations will reject three-element-encoded bundles as malformed. Valid mitigations include per-destination encoding configuration or selective encapsulation via gateway nodes. Heuristic encoding inference and intermediate transcoding are explicitly identified as non-viable: the primary block is immutable and blocks may be integrity-protected.
The textual representation of ipn URIs is not forwards compatible with RFC 9171 when non-default Allocator Identifiers are present. The same interoperability constraints that apply to the three-element CBOR encoding also apply to the text representation in contexts such as the TCPCLv4 session initialization message.
The two-element CBOR encoding and the omission of non-default Allocator Identifiers maintain full backwards compatibility back to RFC 6260. However, the three-element encoding and non-default Allocator Identifiers are not forwards compatible with RFC 9171; existing implementations MUST be updated to process them.
A LocalNode ipn EID MUST be considered non-routable. Bundles using it as source or destination MUST NOT leave the local node; externally received bundles with LocalNode EIDs MUST be discarded. LocalNode EIDs MUST NOT appear in node directories, peer discovery, or as BPSec security sources for transmitted bundles.
All Node Number assignments by all Allocators MUST be in the range 0 to 2^(32-1). A single Node Number assigned by a single Allocator MUST refer to a single node. Node Number zero (0) is RECOMMENDED not to be assigned by Allocators to avoid confusion with the Null ipn URI.
An ipn EID used in BPv7 MUST identify a singleton endpoint whose sole member is the node identified by the FQNN. All ipn EIDs sharing any single FQNN MUST refer to the same bundle processing node.
Bundles using Private Use ipn EIDs as source or destination MUST NOT cross administrative domain boundaries. Gateway implementations MUST be sufficiently configurable to enforce this, and operators MUST ensure correct configuration.
Every ipn URI, regardless of representation, MUST be considered as a tuple of three components: the Allocator Identifier, the Node Number, and the Service Number. The combination uniquely identifies a single resource.
ipn EID matching MUST be performed on the decoded EID information itself. Different CBOR encodings of the same ipn EID (two-element vs. three-element) MUST be treated as equivalent for all EID-specific functions.
Service Number zero (0) MUST be interpreted as the Administrative Endpoint of the node as defined in RFC 9171 Section 3.2. Non-zero Service Numbers MUST NOT be used to identify the Administrative Endpoint of a bundle node in an ipn EID.
The Allocator Identifier MUST be the sole mechanism used to identify the Allocator in an ipn URI. A given Allocator Identifier MUST only be associated with a single Allocator, though an Allocator may hold multiple identifiers. Identifiers are unsigned integers in the range 0 to 2^(32-1).
Examination of ipn URIs, while revealing only numeric identities, could support traffic analysis. Where traffic analysis is a plausible threat, bundles should be conveyed by secure convergence-layer protocols that do not expose endpoint IDs, such as TCPCLv4 (RFC 9174).
A Fully Qualified Node Number (FQNN) is the combination of the Allocator Identifier and Node Number components of an ipn URI and uniquely identifies a particular node. The term FQNN MUST be used when referring to a node identifier to avoid confusion with the raw Node Number component alone.
IANA is designated the Default Allocator with Allocator Identifier zero (0). Any encoded ipn URI that does not explicitly include an Allocator Identifier MUST be assumed to have its Node Number allocated by the Default Allocator, preserving backwards compatibility with pre-existing ipn URI assignments.
The CBOR decoder disambiguates encodings by array length: a 3-element array maps fields directly to allocator_identifier, node_number, service_number; a 2-element array extracts allocator_identifier as enc_eid[0]>>32 and node_number as enc_eid[0]&(2^32-1), with service_number as enc_eid[1].
The Default Allocator provides a range of Node Numbers reserved for Private Use (1–0x3FFF per the registry). ipn URIs using these numbers are not guaranteed unique beyond a single administrative domain, functionally analogous to RFC 1918 private IPv4 addresses.
The Default Allocator reserves Node Number 4294967295 (0xFFFFFFFF) for LocalNode ipn URIs, which identify services on the local node rather than any specific remote node. The shorthand '!' MAY be used in text representation instead of the full decimal value.
The Null ipn URI has all three components set to zero (0). No resource identified by it exists; any destination identified by it is unreachable. It represents the BPv7 Null endpoint and is equivalent to dtn:none, ipn:0.0, and ipn:0.0.0.
IANA created the ''ipn' Scheme URI Allocator Identifiers' registry. Ranges 0–0xFFFF and 0x10000–0x3FFFFFFF require Expert Review; 0x40000000–0x7FFFFFFF is Experimental Use; 0x80000000–0xFFFFFFFF is Reserved. Initial entries are Default Allocator (ID 0, IANA) and Example Range (974848–978943, 12-bit range).
IANA created the ''ipn' Scheme URI Well-Known Service Numbers for BPv7' registry. Standards Action governs 128–255; Specification Required governs 0x8000–0xFFFF; other ranges are Private Use or Reserved. Initial entries: Service Number 0 (Administrative Endpoint) and Example Range 0xEEE0–0xEEEF.
IANA renamed the 'CBHE Node Numbers' registry to ''ipn' Scheme URI Default Allocator Node Numbers' and moved it under the URI Schemes registry group. Range 1–0x3FFF is Private Use; 0x4000–0xFFFFFFFE requires Expert Review. New entries: 0 (Null ipn URI) and 4294967295 (LocalNode ipn URIs).
A conformant but maliciously constructed ipn EID can direct bundles to harmful endpoints or declare a false source, causing incorrect processing. Receiving nodes should verify bundle authenticity using BPSec (RFC 9172) and TCPCLv4 with TLS (RFC 9174) before acting on any bundle.
BPv7 endpoints identified by ipn EIDs are not guaranteed reachable, and their identity is not guaranteed by the Bundle Protocol itself. Verification of the Block Integrity Block (BIB) targeting the bundle's primary block via BPSec (RFC 9172) is required to authenticate the processing entity.
LocalNode and Private Use ipn URIs, if propagated beyond their valid domain, break ipn URI uniqueness, enabling a malicious node to disrupt correct network functioning. Sections 5.4 and 5.5 define the required behaviors to prevent this.
In the three-element encoding, the array contains [Allocator Identifier, Node Number, Service Number] as separate CBOR unsigned integers, each constrained to values less than 2^32. Implementations are RECOMMENDED to use this encoding unless mitigating interoperability issues, except when the Default Allocator is in use (two-element is then more concise).
In the two-element encoding, the first element is a packed 64-bit FQNN where the most-significant 32 bits are the Allocator Identifier and the least-significant 32 bits are the Node Number; the second element is the Service Number. This encoding is backwards compatible with RFC 9171.
The CDDL formal syntax defines ipn-ssp2 as [fqnn: uint, service-number: uint] and ipn-ssp3 as [allocator-identifier: uint .lt 4294967296, node-number: uint .lt 4294967296, service-number: uint]. Both forms share uri-code 2 in the outer BPv7 endpoint encoding.
The textual representation of an ipn URI is 'ipn:[<allocator-identifier>.]<node-number>.<service-number>'. Leading zeros MUST be omitted; the allocator-identifier and preceding '.' MAY be omitted when zero. The '!' shorthand SHOULD replace 4294967295 for LocalNode URIs. ABNF grammar is normatively specified.
When encoding ipn EIDs for BPv7, the scheme-specific part MUST be represented as a CBOR array of either two (2) or three (3) elements, each encoded as a CBOR unsigned integer. Both encodings represent the same logical tuple of (Allocator Identifier, Node Number, Service Number).