rfc9758v1.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
	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
	these URIs when used as an Endpoint Identifier (EID) in the Bundle		these URIs when used as an Endpoint Identifier (EID) in the Bundle
	Protocol version 7 (BPv7) as defined in RFC 9171. These updates		Protocol version 7 (BPv7) as defined in RFC 9171. These updates
	clarify the structure and behavior of the ipn URI scheme, define new		clarify the structure and behavior of the 'ipn' URI scheme, define
	encodings of ipn scheme URIs, and establish the registries necessary		new encodings of 'ipn' scheme URIs, and establish the registries
	to manage this scheme.		necessary to manage this scheme.
	Status of This Memo		Status of This Memo
	This is an Internet Standards Track document.		This is an Internet Standards Track document.
	This document is a product of the Internet Engineering Task Force		This document is a product of the Internet Engineering Task Force
	(IETF). It represents the consensus of the IETF community. It has		(IETF). It represents the consensus of the IETF community. It has
	received public review and has been approved for publication by the		received public review and has been approved for publication by the
	Internet Engineering Steering Group (IESG). Further information on		Internet Engineering Steering Group (IESG). Further information on
	Internet Standards is available in Section 2 of RFC 7841.		Internet Standards is available in Section 2 of RFC 7841.
	skipping to change at line 60 ¶		skipping to change at line 60 ¶
	Table of Contents		Table of Contents
	1. Introduction		1. Introduction
	2. Conventions and Definitions		2. Conventions and Definitions
	3. Core Concepts		3. Core Concepts
	3.1. The Null ipn URI		3.1. The Null ipn URI
	3.2. Allocator Identifiers		3.2. Allocator Identifiers
	3.2.1. Allocator Identifier Ranges		3.2.1. Allocator Identifier Ranges
	3.2.2. The Default Allocator		3.2.2. The Default Allocator
	3.3. Node Numbers		3.3. Node Numbers
	3.3.1. Fully-Qualified Node Numbers		3.3.1. Fully Qualified Node Numbers
	3.4. Special Node Numbers		3.4. Special Node Numbers
	3.4.1. The Zero Node Number		3.4.1. The Zero Node Number
	3.4.2. LocalNode ipn URIs		3.4.2. LocalNode ipn URIs
	3.4.3. Private Use Node Numbers		3.4.3. Private Use Node Numbers
	3.5. Service Numbers		3.5. Service Numbers
	4. Textual Representation of ipn URIs		4. Textual Representation of ipn URIs
	4.1. ipn URI Scheme Text Syntax		4.1. 'ipn' URI Scheme Text Syntax
	5. Usage of ipn URIs with BPv7		5. Usage of ipn URIs with BPv7
	5.1. Uniqueness Constraints		5.1. Uniqueness Constraints
	5.2. The Null Endpoint		5.2. The Null Endpoint
	5.3. BPv7 Node ID		5.3. BPv7 Node ID
	5.4. LocalNode ipn EIDs		5.4. LocalNode ipn EIDs
	5.5. Private Use ipn EIDs		5.5. Private Use ipn EIDs
	5.6. Well-Known Service Numbers		5.6. Well-Known Service Numbers
	5.7. Administrative Endpoints		5.7. Administrative Endpoints
	6. CBOR Representation of ipn URIs with BPv7		6. CBOR Representation of ipn URIs with BPv7
	6.1. ipn EID CBOR Encoding		6.1. ipn EID CBOR Encoding
	6.1.1. Two-Element Scheme-Specific Encoding		6.1.1. Two-Element Scheme-Specific Encoding
	6.1.2. Three-Element Scheme-Specific Encoding		6.1.2. Three-Element Scheme-Specific Encoding
	6.2. ipn EID CBOR Decoding		6.2. ipn EID CBOR Decoding
	6.3. ipn URI Scheme CBOR Syntax		6.3. 'ipn' URI Scheme CBOR Syntax
	6.4. ipn EID Matching		6.4. ipn EID Matching
	7. Special Considerations		7. Special Considerations
	7.1. Scheme Compatibility		7.1. Scheme Compatibility
	7.2. CBOR Representation Interoperability		7.2. CBOR Representation Interoperability
	7.3. Text Representation Compatibility		7.3. Text Representation Compatibility
	7.4. Bundle Protocol Version 6 Compatibility		7.4. Bundle Protocol Version 6 Compatibility
	7.5. Late Binding		7.5. Late Binding
	8. Security Considerations		8. Security Considerations
	8.1. Reliability and Consistency		8.1. Reliability and Consistency
	8.2. Malicious Construction		8.2. Malicious Construction
	skipping to change at line 106 ¶		skipping to change at line 106 ¶
	9. IANA Considerations		9. IANA Considerations
	9.1. 'ipn' Scheme URI Allocator Identifiers Registry		9.1. 'ipn' Scheme URI Allocator Identifiers Registry
	9.1.1. Guidance for Designated Experts		9.1.1. Guidance for Designated Experts
	9.2. 'ipn' Scheme URI Default Allocator Node Numbers Registry		9.2. 'ipn' Scheme URI Default Allocator Node Numbers Registry
	9.3. 'ipn' Scheme URI Well-Known Service Numbers for BPv7		9.3. 'ipn' Scheme URI Well-Known Service Numbers for BPv7
	Registry		Registry
	9.3.1. Guidance for Designated Experts		9.3.1. Guidance for Designated Experts
	10. References		10. References
	10.1. Normative References		10.1. Normative References
	10.2. Informative References		10.2. Informative References
	Appendix A. ipn URI Scheme Text Representation Examples		Appendix A. 'ipn' URI Scheme Text Representation Examples
	A.1. Using the Default Allocator		A.1. Using the Default Allocator
	A.2. Using a Non-Default Allocator		A.2. Using a Non-Default Allocator
	A.3. The Null ipn URI		A.3. The Null ipn URI
	A.4. The LocalNode ipn URI		A.4. The LocalNode ipn URI
	Appendix B. ipn URI Scheme CBOR Encoding Examples		Appendix B. 'ipn' URI Scheme CBOR Encoding Examples
	B.1. Using the Default Allocator		B.1. Using the Default Allocator
	B.2. Using a Non-Default Allocator		B.2. Using a Non-Default Allocator
	B.3. The 'null' Endpoint		B.3. The Null Endpoint
	Acknowledgments		Acknowledgments
	Authors' Addresses		Authors' Addresses
	1. Introduction		1. Introduction
	The ipn URI scheme was originally defined in [RFC6260] and [RFC7116]		The 'ipn' URI scheme was originally defined in [RFC6260] and
	as a way to identify network nodes and node services using concisely		[RFC7116] as a way to identify network nodes and node services using
	encoded integers that can be processed faster and with fewer		concisely encoded integers that can be processed faster and with
	resources than other verbose identifier schemes. The scheme was		fewer resources than other verbose identifier schemes. The scheme
	designed for use with the experimental Bundle Protocol version 6		was designed for use with the experimental Bundle Protocol version 6
	(BPv6) [RFC5050], and "IPN" was defined as an acronym for the term		(BPv6) [RFC5050], and "IPN" was defined as an acronym for the term
	"InterPlanetary Network" in reference to its intended use for deep-		"InterPlanetary Network" in reference to its intended use for deep-
	space networking. Since then, the efficiency benefits of integer		space networking. Since then, the efficiency benefits of integer
	identifiers make ipn scheme URIs useful for any network operating		identifiers make 'ipn' scheme URIs useful for any network operating
	with limited power, bandwidth, and/or compute budget. Therefore, the		with limited power, bandwidth, and/or compute budget. Therefore, the
	term "IPN" is now used as a non-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 has been accompanied by a		the number and scale of deployments of BPv7 has been accompanied 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 to improve the structure, moderation, and management of this		areas 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, in		specification of the 'ipn' URI scheme in a backwards-compatible way,
	order to provide needed improvements both in the scheme itself and in		in order to provide needed improvements both in the scheme itself and
	its usage to specify EIDs with BPv7. Specifically, this document:		in its usage to specify EIDs with BPv7. Specifically, this document:
	* introduces a hierarchical structure for the assignment of ipn		* introduces a hierarchical structure for the assignment of 'ipn'
	scheme URIs,		scheme URIs,
	* clarifies the behavior and interpretation of ipn scheme URIs,		* clarifies the behavior and interpretation of 'ipn' scheme URIs,
	* defines efficient encodings of ipn scheme URIs, and		* defines efficient encodings of 'ipn' scheme URIs, and
	* updates/defines the registries associated with this scheme.		* updates/defines the registries associated with this scheme.
	Although originally developed by the deep-space community for use		Although originally developed by the deep-space community for use
	with the Bundle Protocol, the ipn URI scheme is sufficiently generic		with the Bundle Protocol, the 'ipn' URI scheme is sufficiently
	to be used in other environments where a concise unique		generic to be used in other environments where a concise unique
	representation of a resource on a particular node is required.		representation of a resource on a particular node is required.
	It is important to remember that, like most other URI schemes, the		It is important to remember that, like most other URI schemes, the
	ipn URI scheme defines a unique identifier of a resource, and it does		'ipn' URI scheme defines a unique identifier of a resource, and it
	not include any topological information describing how to route		does not include any topological information describing how to route
	messages to that resource.		messages to that resource.
	2. Conventions and Definitions		2. Conventions and Definitions
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in		"OPTIONAL" in this document are to be interpreted as described in
	BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all		BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
	capitals, as shown here.		capitals, as shown here.
	For the remainder of this document, the term "ipn URI" is used to		For the remainder of this document, the term "ipn URI" is used to
	refer to a URI that uses the ipn scheme.		refer to a URI that uses the 'ipn' URI scheme.
	3. Core Concepts		3. Core Concepts
	Every ipn URI, no matter whether it is expressed with a textual		Every ipn URI, no matter whether it is expressed with a textual
	representation or a binary encoding, MUST be considered as a tuple of		representation or a binary encoding, MUST be considered as a tuple of
	the following three components:		the following three components:
	* The Allocator Identifier		* The Allocator Identifier
	* The Node Number		* The Node Number
	* The Service Number		* The Service Number
	The Allocator Identifier indicates the entity responsible for		The Allocator Identifier indicates the entity responsible for
	assigning Node Numbers to individual resource nodes, maintaining		assigning Node Numbers to individual resource nodes, maintaining
	uniqueness whilst avoiding the need for a single registry for all		uniqueness whilst avoiding the need for a single registry for all
	assigned Node Numbers. See "Allocator Identifiers" (Section 3.2).		assigned Node Numbers. See Section 3.2.
	The Node Number is a shared identifier assigned to all ipn URIs for		The Node Number is a shared identifier assigned to all ipn URIs for
	resources co-located on a single node. See "Node Numbers"		resources co-located on a single node. See Section 3.3.
	(Section 3.3).
	The Service Number is an identifier to distinguish between resources		The Service Number is an identifier to distinguish between resources
	on a given node. See "Service Numbers" (Section 3.5).		on a given node. See Section 3.5.
	The combination of these three components guarantees that every		The combination of these three components guarantees that every
	correctly constructed ipn URI uniquely identifies a single resource.		correctly constructed ipn URI uniquely identifies a single resource.
	Additionally, the combination of the Allocator Identifier and the		Additionally, the combination of the Allocator Identifier and the
	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 Section 3.3.1.
	"Fully-Qualified Node Numbers" (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"		URI to indicate "nowhere". This ipn URI is termed the "Null ipn URI"
	and has all three components (the Allocator Identifier, Node Number,		and has all three components (the Allocator Identifier, Node Number,
	and Service Number) set to the value zero (0). No resource		and Service Number) set to the value zero (0). No resource
	identified by the Null ipn URI exists, and any destination identified		identified by the Null ipn URI exists, and any destination identified
	by such a resource is therefore by definition unreachable.		by 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 governance		for use with the 'ipn' URI scheme and has the facilities and
	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		other identifying information), Allocators are identified by
	Allocator Identifiers: unique, unsigned integers in the range 0 to		Allocator Identifiers: unique, unsigned integers in the range 0 to
	2^(32-1).		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 registry, "'ipn' Scheme URI Allocator Identifiers", is		A new IANA registry, "'ipn' Scheme URI Allocator Identifiers", is
	defined for the registration of Allocator Identifiers; see "'ipn'		defined for the registration of Allocator Identifiers; see
	Scheme URI Allocator Identifiers Registry" (Section 9.1). Although		Section 9.1. Although the uniqueness of Allocator Identifiers is
	the uniqueness of Allocator Identifiers is required to enforce the		required to enforce the uniqueness of ipn URIs, some identifiers are
	uniqueness of ipn URIs, some identifiers are explicitly reserved for		explicitly reserved for 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 "Node Numbers" (Section 3.3). Other than ensuring that any		rules in Section 3.3. Other than ensuring that any Node Numbers it
	Node Numbers it allocates are unique amongst all Node Numbers it		allocates are unique amongst all Node Numbers it assigns, an
	assigns, an Allocator does not need to coordinate its allocations		Allocator does not need to coordinate its allocations with other
	with other Allocators.		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 Numbers (Section 3.4.3) range,		URIs, then the Private Use Node Numbers range (Section 3.4.3),
	reserved by the Default Allocator (Section 3.2.2) for this purpose,		reserved by the Default Allocator (Section 3.2.2) for this purpose,
	are to be used.		is 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. This allows an external observer		organization in a structured way. This allows an external observer
	to detect that a group of Allocator Identifiers is organizationally		to detect that a group of Allocator Identifiers is organizationally
	skipping to change at line 341 ¶		skipping to change at line 338 ¶
	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 "CBHE Node Numbers"		(IANA), which assigned Node Numbers via the "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 "CBHE Node Numbers" registry.		that comply with the "CBHE Node Numbers" registry.
	The presumption that Node Numbers are allocated by IANA from a		The presumption that Node Numbers are allocated by IANA from a
	specific registry, unless otherwise specified, is formalized in this		specific registry, unless otherwise specified, is formalized in this
	update to the ipn URI scheme by designating IANA as the Default		update to the 'ipn' URI scheme by designating IANA as the Default
	Allocator and 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		"'ipn' Scheme URI Allocator Identifiers" registry (Section 9.1) to
	the Default Allocator. In any case where an encoded ipn URI does not		the 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 registry, "'ipn' Scheme URI Default Allocator Node		A new IANA registry, "'ipn' Scheme URI Default Allocator Node
	Numbers", is defined to control the allocation of Node Number values		Numbers", is defined to control the allocation of Node Number values
	by the Default Allocator. This new registry inherits behaviors and		by the Default Allocator. This new registry inherits behaviors and
	existing assignments from the "CBHE Node Numbers" registry, and it		existing assignments from the "CBHE Node Numbers" registry, and it
	reserves some other values as defined in "Special Node Numbers"		reserves some other values as defined in Section 3.4 below.
	(Section 3.4) 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
	0 to 2^(32-1).		0 to 2^(32-1).
	It is RECOMMENDED that Node Number zero (0) not be assigned by an		It is RECOMMENDED that Node Number zero (0) not be assigned by an
	Allocator to avoid confusion with the Null ipn URI (Section 3.1).		Allocator to avoid confusion with the Null ipn URI (Section 3.1).
	3.3.1. Fully-Qualified Node Numbers		3.3.1. Fully Qualified Node Numbers
	One of the advantages of ipn URIs is the ability to easily split the		One of the advantages of ipn URIs is the ability to easily split the
	identity of a particular service from the node upon which the service		identity of a particular service from the node upon which the service
	exists. For example, a message received from one particular ipn URI		exists. For example, a message received from one particular ipn URI
	may require a response to be sent to a different service on the same		may require a response to be sent to a different service on the same
	node that sent the original message. Historically, the identifier of		node that sent the original message. Historically, the identifier of
	the sending node has been colloquially referred to as the "node		the sending node has been colloquially referred to as the "node
	number" or "node identifier".		number" or "node identifier".
	To avoid future confusion, when referring to the identifier of a		To avoid future confusion, when referring to the identifier of a
	particular node, the term "Fully-Qualified Node Number" (FQNN) MUST		particular node, the term "Fully Qualified Node Number" (FQNN) MUST
	be used to refer to the combination of the Node Number component and		be used to refer to the combination of the Node Number component and
	Allocator Identifier component of an ipn URI that uniquely identifies		Allocator Identifier component of an ipn URI that uniquely identifies
	a particular node. In other words, an FQNN is the unique identifier		a particular node. In other words, an FQNN is the unique identifier
	of a particular node that supports services identified by ipn URIs.		of a particular node that supports services identified by ipn URIs.
	In the examples in this document, FQNNs are written as (Allocator		In the examples in this document, FQNNs are written as (Allocator
	Identifier, Node Number). For example, (977000,100) is the FQNN for		Identifier, Node Number). For example, (977000,100) is the FQNN for
	a node assigned Node Number 100 by an Allocator with Allocator		a node assigned Node Number 100 by an Allocator with Allocator
	Identifier 977000.		Identifier 977000.
	3.4. Special Node Numbers		3.4. Special Node Numbers
	Some special-case Node Numbers are defined by the Default Allocator;		Some special-case Node Numbers are defined by the Default Allocator;
	see "'ipn' Scheme URI Default Allocator Node Numbers Registry"		see Section 9.2.
	(Section 9.2).
	3.4.1. The Zero Node Number		3.4.1. The Zero Node Number
	The Default Allocator assigns the use of Node Number zero (0) solely		The Default Allocator assigns the use of Node Number zero (0) solely
	for identifying the Null ipn URI (Section 3.1).		for identifying the Null ipn URI (Section 3.1).
	This means that any ipn URI with a zero (0) Allocator Identifier and		This means that any ipn URI with a zero (0) Allocator Identifier and
	a zero (0) Node Number, but a non-zero Service Number component, is		a zero (0) Node Number, but a non-zero Service Number component, is
	invalid. Such ipn URIs MUST NOT be composed, and processors of such		invalid. Such ipn URIs MUST NOT be composed, and processors of such
	ipn URIs MUST consider them as the Null ipn URI.		ipn URIs MUST consider them as the Null ipn URI.
	skipping to change at line 445 ¶		skipping to change at line 440 ¶
	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 Representation 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 a scheme identifier and a scheme-specific part. The		represented by a 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. A formal definition is provided below (see "ipn URI		'.' character. A formal definition is provided below (see
	Scheme Text Syntax" (Section 4.1)) and can be informally considered		Section 4.1) and can be informally considered as:
	as:
	ipn:[<allocator-identifier>.]<node-number>.<service-number>		ipn:[<allocator-identifier>.]<node-number>.<service-number>
	To keep the text representation concise, the following 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 '!' SHOULD 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 A.		Appendix A.
	4.1. ipn URI Scheme Text Syntax		4.1. 'ipn' URI Scheme Text Syntax
	The text syntax of an ipn URI MUST comply with the following ABNF		The text syntax of an ipn URI MUST comply with the following ABNF
	syntax from [RFC5234] and reiterate the core ABNF syntax rule for		syntax from [RFC5234] and repeats the core ABNF syntax rule for DIGIT
	DIGIT defined by that specification:		defined by that specification:
	ipn-uri = "ipn:" ipn-hier-part		ipn-uri = "ipn:" ipn-hier-part
	ipn-hier-part = fqnn "." service-number		ipn-hier-part = fqnn "." service-number
	fqnn = "!" / allocator-part		fqnn = "!" / allocator-part
	allocator-part = [allocator-identifier "."] node-number		allocator-part = [allocator-identifier "."] node-number
	allocator-identifier = number		allocator-identifier = number
	skipping to change at line 500 ¶		skipping to change at line 495 ¶
	number = "0" / non-zero-number		number = "0" / non-zero-number
	non-zero-number = (%x31-39 *DIGIT)		non-zero-number = (%x31-39 *DIGIT)
	DIGIT = %x30-39		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 [RFC5050] termed
	source or destination of a bundle as an "Endpoint" identified by an		the logical source or destination of a bundle as an "Endpoint"
	"Endpoint Identifier" (EID). BPv6 EIDs are formatted as URIs. This		identified by an "Endpoint Identifier" (EID). BPv6 EIDs are
	definition and representation of EIDs was carried forward from the		formatted as URIs. This definition and representation of EIDs was
	IRTF BPv6 specification to the IETF BPv7 specification. BPv7		carried forward from the IRTF BPv6 specification [RFC5050] to the
	additionally defined an IANA registry called the "Bundle Protocol URI		IETF BPv7 specification [RFC9171]. [RFC9171] additionally defined an
	Scheme Types" registry, which identifies those URI schemes that might		IANA registry called the "Bundle Protocol URI Scheme Types" registry,
	be used to represent EIDs. The ipn URI scheme is one such URI		which identifies those URI schemes that might be used to represent
	scheme.		EIDs. The 'ipn' URI scheme is one such URI scheme.
	This section identifies the behavior and interpretation of ipn scheme		This section identifies the behavior and interpretation of 'ipn'
	URIs that MUST be followed when using this URI scheme to represent		scheme URIs that MUST be followed when using this URI scheme to
	EIDs in BPv7. An ipn URI used as a BPv7 or BPv6 EID is termed an		represent EIDs in BPv7. An ipn URI used as a BPv7 or BPv6 EID is
	"ipn EID".		termed an "ipn EID".
	5.1. Uniqueness Constraints		5.1. Uniqueness Constraints
	An ipn EID MUST identify a singleton endpoint. The bundle processing		An ipn EID MUST identify a singleton endpoint. The bundle processing
	node that is the sole member of that endpoint MUST be the node		node that is the sole member of that endpoint MUST be the node
	identified by the Fully-Qualified Node Number (Section 3.3.1) of the		identified by the FQNN (Section 3.3.1) of the node.
	node.
	A single bundle processing node MAY have multiple ipn EIDs associated		A single bundle processing node MAY have multiple ipn EIDs associated
	with it. However, all ipn EIDs that share any single FQNN MUST refer		with it. However, all ipn EIDs that share any single FQNN MUST refer
	to the same bundle processing node.		to the same bundle processing node.
	For example, ipn:977000.100.1, ipn:977000.100.2, and ipn:977000.100.3		For example, ipn:977000.100.1, ipn:977000.100.2, and ipn:977000.100.3
	MUST all refer to services registered on the bundle processing node		MUST all refer to services registered on the bundle processing node
	identified with FQNN (977000,100). None of these EIDs could be		identified with FQNN (977000,100). None of these EIDs could be
	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 is identified by a		which is an endpoint that has no members and 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]), ipn:0.0, and ipn:0.0.0 all refer to		(Section 4.2.5.1.1 of [RFC9171]), ipn:0.0, and ipn:0.0.0 all refer to
	the BPv7 '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 uniquely identifies a bundle		that has the same format as an EID and uniquely identifies a bundle
	processing node.		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 FQNN (Section 3.3.1). That is, any ipn EID of the
	is, any ipn EID of the form ipn:A.B.C may be used as the Source Node		form ipn:A.B.C may be used as the Source Node ID of any bundle
	ID of any bundle created by the bundle processing node identified by		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 BPv6 or BPv7		When a LocalNode ipn URI (Section 3.4.2) is used as a BPv6 or BPv7
	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-routable. This means that		node, any such EID MUST be considered non-routable. This means that
	any bundle using a LocalNode ipn EID as a bundle source or bundle		any bundle using a LocalNode ipn EID as a bundle source or bundle
	destination MUST NOT be allowed to leave the local node. Equally,		destination MUST NOT be allowed to leave the local node. Equally,
	skipping to change at line 581 ¶		skipping to change at line 574 ¶
	downstream bundle node.		downstream bundle node.
	LocalNode ipn EIDs MUST NOT be published in any node identification		LocalNode ipn EIDs MUST NOT be published in any node identification
	directory (such as a DNS registration) or presented as part of		directory (such as a DNS registration) or presented as part of
	dynamic peer discovery, as the EID has no valid meaning for other		dynamic peer discovery, as the EID has no valid meaning for other
	nodes. For example, a LocalNode ipn EID MUST NOT be advertised as		nodes. For example, a LocalNode ipn EID MUST NOT be advertised as
	the peer Node ID during session negotiation in [RFC9174].		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 an FQNN
	Node Number (Section 3.3.1) that is within the Private Use range of		(Section 3.3.1) that is within the Private Use range of the Default
	the Default Allocator (Section 3.2.2) are not universally unique;		Allocator (Section 3.2.2) are not universally unique; therefore, they
	therefore, they are only valid within the scope of the current		are only valid within the scope of the current administrative domain.
	administrative domain. This means that any bundle using a Private		This means that any bundle using a Private Use ipn EID as a bundle
	Use ipn EID as a bundle source or bundle destination MUST NOT be		source or bundle destination MUST NOT be allowed to cross
	allowed to cross administrative domains. All implementations that		administrative domains. All implementations that could be deployed
	could be deployed as a gateway between administrative domains MUST be		as a gateway between administrative domains MUST be sufficiently
	sufficiently configurable to ensure that this is enforced, and		configurable to ensure that this is enforced, and operators MUST
	operators MUST ensure correct configuration.		ensure correct configuration.
	Private Use ipn EIDs MUST 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 MUST NOT be used as a BPSec [RFC9172] security		Private Use ipn EID MUST NOT be used as a BPSec [RFC9172] security
	source for a bundle when the bundle is destined for a different		source for a bundle when the bundle is destined for a different
	administrative domain.		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 configurations are applied, such		Number, so that unless overridden by explicit configuration, such
	services can be sensibly assumed to be operating on the well-known		services can be sensibly assumed to be operating on the well-known
	Service Number on a particular node.		Service Number on a particular node.
	If a different service uses the number, or the service uses a		If a different service uses the number, or the service uses a
	different number, BPv7 will continue to operate, but some		different number, BPv7 will continue to operate, but some
	configuration may be required to make the individual service		configuration may be required to make the individual service
	operational.		operational.
	A new IANA registry, "'ipn' Scheme URI Well-Known Service Numbers for		A new IANA registry, "'ipn' Scheme URI Well-Known Service Numbers for
	BPv7", is defined for the registration of well-known BPv7 Service		BPv7", is defined for the registration of well-known BPv7 Service
	Numbers; see "'ipn' Scheme URI Well-Known Service Numbers for BPv7		Numbers; see Section 9.3. This registry records the assignments of
	Registry" (Section 9.3). This registry records the assignments of
	Service Numbers for well-known services and also explicitly reserves		Service Numbers for well-known services and also explicitly reserves
	ranges for both experimentation and Private Use.		ranges for both experimentation and Private Use.
	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. CBOR Representation of 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 Concise Binary Object Representation		URI scheme is encoded with Concise Binary Object Representation
	(CBOR) [RFC8949]. To meet this requirement, this section describes		(CBOR) [RFC8949]. To meet this requirement, this section describes
	the CBOR encoding and decoding approach for ipn EIDs. The formal		the CBOR encoding and decoding approach for ipn EIDs. The formal
	definition of the CBOR representation is specified; see "ipn URI		definition of the CBOR representation is specified; see Section 6.3.
	Scheme CBOR Syntax" (Section 6.3).
	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, ipn EIDs from [RFC9171] are represented as a sequence		Fundamentally, ipn EIDs from [RFC9171] are represented as a sequence
	of identifiers. In the text syntax, the numbers are separated with		of identifiers. In the text syntax, the numbers are separated with
	the '.' delimiter; in CBOR, this ordered series of numbers can be		the '.' 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 B.		encodings are provided in 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 FQNN (Section 3.3.1), and
	Number (Section 3.3.1), and the second element of the array is the		the second element of the array is the ipn EID Service Number.
	ipn 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 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 scheme-specific 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 709 ¶		skipping to change at line 699 ¶
	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 scheme-specific 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
	"Scheme Compatibility" (Section 7.1).		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 is the		with this encoding scheme, the first element of the array is the
	value zero (0). In this case, using the equivalent two-element		value zero (0). In this case, using the equivalent two-element
	scheme-specific encoding (Section 6.1.1) will result in a more		scheme-specific encoding (Section 6.1.1) will result in a more
	concise CBOR representation; therefore, it is RECOMMENDED that		concise CBOR representation; therefore, it is RECOMMENDED that
	implementations use that encoding instead.		implementations use that encoding instead.
	6.2. ipn EID CBOR Decoding		6.2. ipn EID CBOR Decoding
	skipping to change at line 747 ¶		skipping to change at line 737 ¶
	if enc_eid.len() == 3		if enc_eid.len() == 3
	{		{
	ipn_eid.allocator_identifier := enc_eid[0];		ipn_eid.allocator_identifier := enc_eid[0];
	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 URI Scheme CBOR Syntax		6.3. 'ipn' URI Scheme CBOR Syntax
	When encoded in CBOR [RFC8949], a BPv7 endpoint identified by an ipn		When encoded in CBOR [RFC8949], a BPv7 endpoint identified by an ipn
	URI MUST comply with the following Concise Data Definition Language		URI MUST comply with the following Concise Data Definition Language
	(CDDL) [RFC8610] specification:		(CDDL) [RFC8610] specification:
	eid = $eid .within eid-structure		eid = $eid .within eid-structure
	eid-structure = [		eid-structure = [
	uri-code: uint,		uri-code: uint,
	SSP: any		SSP: any
	skipping to change at line 801 ¶		skipping to change at line 791 ¶
	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
	identifying services on network nodes. There is a significant amount		for identifying services on network nodes. There is a significant
	of utility in the ipn URI scheme approach to identification.		amount 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, particularly in regard		observations on the use of the 'ipn' URI scheme, particularly in
	to interoperability with implementations that pre-date this		regard to interoperability with implementations that pre-date this
	specification.		specification.
	7.1. Scheme Compatibility		7.1. Scheme Compatibility
	The ipn scheme update that has been presented in this document		The 'ipn' URI 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
	to the provisional definition of the ipn scheme in the experimental		back to the provisional definition of the 'ipn' scheme in the
	specification "Compressed Bundle Header Encoding (CBHE)" [RFC6260] in		experimental specification "Compressed Bundle Header Encoding (CBHE)"
	2011. This means that any ipn URI that was valid prior to the		[RFC6260] in 2011. This means that any ipn URI that was valid prior
	publication of this update remains a valid ipn URI.		to the publication 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 implementation compliant with [RFC9171]		in [RFC9171]. Any existing implementation compliant with [RFC9171]
	will produce an ipn URI encoding in compliance with this		will produce an ipn URI encoding in compliance with this
	specification.		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 implementations for		scheme update forwards compatible. Existing implementations for
	skipping to change at line 892 ¶		skipping to change at line 882 ¶
	ipn URIs and support for non-default Allocator Identifiers is		ipn URIs and support for non-default Allocator Identifiers is
	required. For example, Section 4.6 of [RFC9174] specifies that the		required. For example, Section 4.6 of [RFC9174] specifies that the
	session initialization message "...SHALL contain the UTF-8 encoded		session initialization message "...SHALL contain the UTF-8 encoded
	node ID of the entity that sent the SESS_INIT message." In such		node ID of the entity that sent the SESS_INIT message." In such
	cases, the considerations that apply to the use of the three-element		cases, the considerations that apply to the use of the three-element
	CBOR encoding also apply to the text representation when a non-		CBOR encoding also apply to the text representation when a non-
	default Allocator Identifier is present.		default Allocator Identifier is present.
	7.4. Bundle Protocol Version 6 Compatibility		7.4. Bundle Protocol Version 6 Compatibility
	This document updates the use of ipn EIDs for BPv7; however, the ipn		This document updates the use of ipn EIDs for BPv7; however, the
	URI scheme was originally defined for use with BPv6. This document		'ipn' URI scheme was originally defined for use with BPv6. This
	does not update any of the behaviors, wire-formats, or mechanisms of		document does not update any of the behaviors, wire-formats, or
	BPv6. Therefore, ipn EIDs with non-default Allocator Identifiers		mechanisms of BPv6. Therefore, ipn EIDs with non-default Allocator
	MUST NOT be used with BPv6, and the Allocator Identifier prefix MUST		Identifiers MUST NOT be used with BPv6, and the Allocator Identifier
	be omitted from any textural representation. It should be noted that		prefix MUST be omitted from any textural representation. It should
	BPv6 has no concept of LocalNode EIDs and will therefore treat such		be noted that BPv6 has no concept of LocalNode EIDs and will
	EIDs as routable.		therefore treat such EIDs as routable.
	7.5. Late Binding		7.5. Late Binding
	[RFC9171] mandates the concept of the "late binding" of an EID,		[RFC9171] mandates the concept of the "late binding" of an EID,
	whereby the address of the destination of a bundle is resolved from		whereby the address of the destination of a bundle is resolved from
	its hop-by-hop identifier as it transits a BPv7 network. This per-		its identifier hop-by-hop as it transits a BPv7 network. This per-
	hop binding of identifiers to addresses underlines the fact that EIDs		hop binding of identifiers to addresses underlines the fact that EIDs
	are purely names and should not carry any implicit or explicit		are purely names and should not carry any implicit or explicit
	information concerning the current location or reachability of an		information concerning the current location or reachability of an
	identified node and service. This removes the need to rename a node		identified node and service. This removes the need to rename a node
	as its location 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 MUST 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
	concerns.		concerns.
	An example of incorrect behavior would be to assume that a given		An example of incorrect behavior would be to assume that a given
	Allocator assigns Node Numbers derived from link-layer addresses and		Allocator assigns Node Numbers derived from link-layer addresses and
	to interpret the Node Number component of an ipn URI directly as a		to interpret the Node Number component of an ipn URI directly as a
	link-layer address. No matter the mechanism an Allocator uses for		link-layer address. No matter the mechanism an Allocator uses for
	the assignment of Node Numbers, they remain just numbers, without		the assignment of Node Numbers, they remain just numbers, without
	additional meaning.		additional meaning.
	8. Security Considerations		8. Security Considerations
	This section updates the security considerations from		This section updates the security considerations from
	Section 4.2.5.1.2 of [RFC9171] to account for the inclusion of		Section 4.2.5.1.2 of [RFC9171] to account for the inclusion of
	Allocator Identifiers in the ipn URI scheme when used with BPv7.		Allocator Identifiers in the 'ipn' URI scheme when used with BPv7.
	8.1. Reliability and Consistency		8.1. Reliability and Consistency
	None of the BPv7 endpoints identified by ipn EIDs are guaranteed to		None of the BPv7 endpoints identified by ipn EIDs are guaranteed to
	be reachable at any time, and the identity of the processing entities		be reachable at any time, and the identity of the processing entities
	operating on those endpoints is never guaranteed by the Bundle		operating on those endpoints is never guaranteed by the Bundle
	Protocol itself. Verification of the signature provided by the Block		Protocol itself. Verification of the signature provided by the Block
	Integrity Block (BIB) targeting the bundle's primary block, as		Integrity Block (BIB) targeting the bundle's primary block, as
	defined by "Bundle Protocol Security (BPSec)" [RFC9172], is required		defined by "Bundle Protocol Security (BPSec)" [RFC9172], is required
	for this purpose.		for this purpose.
	skipping to change at line 956 ¶		skipping to change at line 946 ¶
	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		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
	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 is allowed to propagate beyond the domain in		either type of ipn URI is 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 Sections 5.4 and 5.5 for required behaviors to mitigate against
	(Section 5.5) for required behaviors to mitigate against this form of		this form 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, such as TCPCLv4		layer protocols that do not expose endpoint IDs, such as TCPCLv4
	[RFC9174].		[RFC9174].
	8.6. Semantic Attacks		8.6. Semantic Attacks
	The simplicity of the ipn URI scheme syntax minimizes the possibility		The simplicity of the 'ipn' URI scheme syntax minimizes the
	of misinterpretation of a URI by a human user.		possibility of misinterpretation of a URI by a human user.
	9. IANA Considerations		9. IANA Considerations
	The following sections detail the creation of two new IANA registries		The following sections detail the creation of two new IANA registries
	and the renaming of an existing IANA registry under the "Uniform		and the renaming of an existing IANA registry under the "Uniform
	Resource Identifier (URI) Schemes" registry group.		Resource Identifier (URI) Schemes" registry group.
	IANA has also updated the reference for the 'ipn' scheme to this		IANA has also updated the reference for the 'ipn' scheme to this
	document in the "Uniform Resource Identifier (URI) Schemes" registry.		document in the "Uniform Resource Identifier (URI) Schemes" registry.
	9.1. 'ipn' Scheme URI Allocator Identifiers Registry		9.1. 'ipn' Scheme URI Allocator Identifiers Registry
	IANA has created a new registry titled "'ipn' Scheme URI Allocator		IANA has created a new registry titled "'ipn' Scheme URI Allocator
	Identifiers". Using terms defined in [RFC8126], the registration		Identifiers". Using terms defined in [RFC8126], the registration
	policies for this registry are:		procedures for this registry are:
	+========================+==============+==================+		+========================+==============+==================+
	| Range | Registration | Note |		| Range | Registration | Note |
	| | Procedures | |		| | Procedures | |
	+========================+==============+==================+		+========================+==============+==================+
	| 0..0xFFFF | Expert | Single Allocator |		| 0..0xFFFF | Expert | Single Allocator |
	| | 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 | |		| >= 2^32 | Reserved | |
	+------------------------+--------------+------------------+		+------------------------+--------------+------------------+
	Table 2: Registration Policies for the 'ipn' Scheme URI		Table 2: Registration Procedures for the 'ipn' Scheme
	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
	is listed in the "Reference" field of the registry.		is listed in the "Reference" field of the registry.
	Note that the "Single Allocator Identifiers only" language in the		Note that the "Single Allocator Identifiers only" language in the
	registration policy for this registry indicates that, within the		registration procedure for this registry indicates that, within the
	indicated range, the allocation of a sequence of consecutive		indicated range, the allocation of a sequence of consecutive
	Allocator Identifiers to a single organization is prohibited.		Allocator Identifiers to a single organization is prohibited.
	The initial values in the registry are:		The initial values in the registry are:
	+=========+=============+===============+======+=========+==========+		+=========+=============+===============+======+=========+==========+
	|Name |Range (dec) |Range (hex) |Range |Reference|Change |		|Name |Range (dec) |Range (hex) |Range |Reference|Change |
	| | | |Length| |Controller|		| | | |Length| |Controller|
	| | | |(Bits)| | |		| | | |(Bits)| | |
	+=========+=============+===============+======+=========+==========+		+=========+=============+===============+======+=========+==========+
	skipping to change at line 1082 ¶		skipping to change at line 1071 ¶
	IANA has renamed the "CBHE Node Numbers" registry (defined in		IANA has renamed the "CBHE Node Numbers" registry (defined in
	Section 3.2.1 of [RFC7116]) to the "'ipn' Scheme URI Default		Section 3.2.1 of [RFC7116]) to the "'ipn' Scheme URI Default
	Allocator Node Numbers" registry and moved it to the "Uniform		Allocator Node Numbers" registry and moved it to the "Uniform
	Resource Identifier (URI) Schemes" registry group. IANA has added		Resource Identifier (URI) Schemes" registry group. IANA has added
	the following note to the "CBHE Node Numbers" registry:		the following note to the "CBHE Node Numbers" registry:
	| Note: Renamed "CBHE Node Numbers" as "'ipn' Scheme URI Default		| Note: Renamed "CBHE Node Numbers" as "'ipn' Scheme URI Default
	| Allocator Node Numbers" and moved it to		| Allocator Node Numbers" and moved it to
	| <https://www.iana.org/assignments/uri-schemes> per RFC 9758.		| <https://www.iana.org/assignments/uri-schemes> per RFC 9758.
	Using terms defined in [RFC8126], the registration policies for this		Using terms defined in [RFC8126], the registration procedures for
	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 |		| >= 2^32 | Invalid |
	+--------------------+-------------------------+		+--------------------+-------------------------+
	Table 4: Registration Policies for the 'ipn'		Table 4: Registration Procedures for the
	Scheme URI Default Allocator Node Numbers		'ipn' Scheme URI Default Allocator Node
	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:
	+==============+===============================+===================+		+============+===============================+===================+
	| Value | Description | Reference |		| Value | Description | Reference |
	+==============+===============================+===================+		+============+===============================+===================+
	| 0 | Reserved for the Null ipn URI | [RFC7116] and RFC |		| 0 | Reserved for the Null ipn URI | [RFC7116] and RFC |
	| | | 9758, Section 3.1 |		| | | 9758, Section 3.1 |
	+--------------+-------------------------------+-------------------+		+------------+-------------------------------+-------------------+
	| 4294967295 | Reserved for LocalNode ipn | RFC 9758, |		| 4294967295 | Reserved for LocalNode ipn | RFC 9758, |
	| | URIs | Section 3.4.2 |		| | URIs | Section 3.4.2 |
	+--------------+-------------------------------+-------------------+		+------------+-------------------------------+-------------------+
	| >=4294967296 | Invalid | RFC 9758 |
	+--------------+-------------------------------+-------------------+
	Table 5: New Values in the 'ipn' Scheme URI Default Allocator		Table 5: New Values in the 'ipn' Scheme URI Default Allocator
	Node Numbers Registry		Node Numbers Registry
	As IANA has only renamed the registry, all existing registrations		As IANA has only renamed the registry, all existing registrations
	will remain.		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 has created a new registry titled "'ipn' Scheme URI Well-Known		IANA has created a new registry titled "'ipn' Scheme URI Well-Known
	Service Numbers for BPv7". Using terms defined in [RFC8126], the		Service Numbers for BPv7". Using terms defined in [RFC8126], the
	registration policies for this registry are:		registration procedures for this registry are:
	+=====================+===============================+		+=====================+===============================+
	| Range | Registration Procedures |		| Range | Registration Procedures |
	+=====================+===============================+		+=====================+===============================+
	| 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 |		| >= 2^32 | Reserved for future expansion |
	+---------------------+-------------------------------+		+---------------------+-------------------------------+
	Table 6: Registration Policies for the 'ipn' Scheme		Table 6: Registration Procedures for the 'ipn'
	URI Well-Known Service Numbers for BPv7 Registry		Scheme URI Well-Known Service Numbers for BPv7
			Registry
	The initial values for the registry are:		The initial values in the registry are:
	+=====================+====================+===================+		+================+=============================+===================+
	| Value | Description | Reference |		| Value | Description | Reference |
	+=====================+====================+===================+		+================+=============================+===================+
	| 0 | The Administrative | [RFC9171] and RFC |		| 0 | The Administrative Endpoint | [RFC9171] and RFC |
	| | Endpoint | 9758, Section 5.7 |		| | | 9758, Section 5.7 |
	+---------------------+--------------------+-------------------+		+----------------+-----------------------------+-------------------+
	| 1..27 | Reserved for | RFC 9758 |		| 0xEEE0..0xEEEF | Example Range | RFC 9758 |
	| | Private Use | |		+----------------+-----------------------------+-------------------+
	+---------------------+--------------------+-------------------+
	| 0x0100..0x7FFF | Reserved for | RFC 9758 |
	| | Private Use | |
	+---------------------+--------------------+-------------------+
	| 0xEEE0..0xEEEF | Example Range | RFC 9758 |
	+---------------------+--------------------+-------------------+
	| 0x10000..0xFFFFFFFF | Reserved for | RFC 9758 |
	| | Private Use | |
	+---------------------+--------------------+-------------------+
	| >= 2^32 | Reserved for | RFC 9758 |
	| | future expansion | |
	+---------------------+--------------------+-------------------+
	Table 7: Initial Values in the 'ipn' Scheme URI Well-Known		Table 7: Initial Values in the 'ipn' Scheme URI Well-Known
	Service Numbers for BPv7 Registry		Service Numbers for BPv7 Registry
	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.3.1. Guidance for Designated Experts		9.3.1. Guidance for Designated Experts
	This registry is intended to record the default Service Numbers for		This registry is intended to record the default Service Numbers for
	skipping to change at line 1264 ¶		skipping to change at line 1240 ¶
	[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/info/rfc9172>.		2022, <https://www.rfc-editor.org/info/rfc9172>.
	[RFC9174] Sipos, B., Demmer, M., Ott, J., and S. Perreault, "Delay-		[RFC9174] Sipos, B., Demmer, M., Ott, J., and S. Perreault, "Delay-
	Tolerant Networking TCP Convergence-Layer Protocol Version		Tolerant Networking TCP Convergence-Layer Protocol Version
	4", RFC 9174, DOI 10.17487/RFC9174, January 2022,		4", RFC 9174, DOI 10.17487/RFC9174, January 2022,
	<https://www.rfc-editor.org/info/rfc9174>.		<https://www.rfc-editor.org/info/rfc9174>.
	Appendix A. 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.
	A.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 (0) (Section 3.2.2).		allocated by the Default Allocator (0) (Section 3.2.2).
	The recommended seven-character representation of this URI would be		The recommended seven-character representation of this URI would be
	skipping to change at line 1313 ¶		skipping to change at line 1289 ¶
	The recommended seven-character representation of this URI would be		The recommended seven-character representation of this URI would be
	as follows:		as follows:
	ipn:!.7		ipn:!.7
	The numeric 16-character representation of this URI would be as		The numeric 16-character representation of this URI would be as
	follows:		follows:
	ipn:4294967295.7		ipn:4294967295.7
	Appendix B. 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.
	B.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 (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 scheme-specific 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 scheme-specific 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 scheme-specific 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 scheme-specific 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 scheme-specific 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 scheme-specific 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,
End of changes. 91 change blocks.
	205 lines changed or deleted		181 lines changed or added
This html diff was produced by rfcdiff 1.48.