rfc9758.original.xml   rfc9758.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE rfc [ <!DOCTYPE rfc [
<!ENTITY nbsp "&#160;"> <!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;"> <!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;"> <!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;"> <!ENTITY wj "&#8288;">
]> ]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.17 (Ruby 3.2. -ietf-dtn-ipn-update-14" number="9758" category="std" consensus="true" submissio
3) --> nType="IETF" updates="6260, 7116, 9171" obsoletes="" tocInclude="true" sortRefs=
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft "true" symRefs="true" version="3" xml:lang="en">
-ietf-dtn-ipn-update-14" category="std" consensus="true" submissionType="IETF" u
pdates="[9171, 7116, 6260]" tocInclude="true" sortRefs="true" symRefs="true" ver
sion="3">
<!-- xml2rfc v2v3 conversion 3.21.0 -->
<front> <front>
<title abbrev="ipn-update">Update to the ipn URI scheme</title> <title abbrev="ipn Update">Updates to the 'ipn' URI Scheme</title>
<seriesInfo name="Internet-Draft" value="draft-ietf-dtn-ipn-update-14"/> <seriesInfo name="RFC" value="9758"/>
<author fullname="Rick Taylor"> <author fullname="Rick Taylor">
<organization>Aalyria Technologies</organization> <organization>Aalyria Technologies</organization>
<address> <address>
<email>rtaylor@aalyria.com</email> <email>rtaylor@aalyria.com</email>
</address> </address>
</author> </author>
<!--[rfced] Edward, we understand that in other RFCs (RFCs 9171, 9172,
and 9173), your preference was to list your name as "E. Birrane, III"
on the first page and "Edward J. Birrane, III" in the Authors'
Addresses section. Please let us know if you would you like to do the
same in this document for consistency.
-->
<author fullname="Ed Birrane"> <author fullname="Ed Birrane">
<organization>JHU/APL</organization> <organization>JHU/APL</organization>
<address> <address>
<email>Edward.Birrane@jhuapl.edu</email> <email>Edward.Birrane@jhuapl.edu</email>
</address> </address>
</author> </author>
<date year="2024" month="September" day="27"/> <date year="2025" month="March"/>
<area>Transport</area> <area>INT</area>
<workgroup>Delay/Disruption Tolerant Networking</workgroup> <workgroup>dtn</workgroup>
<keyword>DTN</keyword> <keyword>DTN</keyword>
<keyword>ipn</keyword> <keyword>ipn</keyword>
<keyword>BPv7</keyword> <keyword>BPv7</keyword>
<keyword>CBHE</keyword> <keyword>CBHE</keyword>
<keyword>Bundle Protocol</keyword> <keyword>Bundle Protocol</keyword>
<abstract> <abstract>
<?line 46?> <t>This document updates the specification of the 'ipn' URI scheme
previously defined in RFC 6260 and the IANA registries established in RFC
<t>This document updates the specification of the ipn URI scheme previously defi 7116. It also updates the rules for the encoding and decoding of these URI
ned in RFC 6260, the IANA registries established in RFC 7116, and the rules for s when
the encoding and decoding of these URIs when used as an Endpoint Identifier (EID used as an Endpoint Identifier (EID) in the Bundle Protocol version 7 (BPv
) in Bundle Protocol Version 7 (BPv7) as defined in RFC 9171. These updates clar 7)
ify the structure and behavior of the ipn URI scheme, define new encodings of ip as defined in RFC 9171. These updates clarify the structure and behavior
n scheme URIs, and establish the registries necessary to manage this scheme.</t> of the 'ipn' URI scheme, define new encodings of 'ipn' scheme URIs, and
establish the registries necessary to manage this scheme.</t>
</abstract> </abstract>
<note removeInRFC="true">
<name>About This Document</name>
<t>
The latest revision of this draft can be found at <eref target="https://
ricktaylor.github.io/ipn2/draft-taylor-dtn-ipn-update.html"/>.
Status information for this document may be found at <eref target="https
://datatracker.ietf.org/doc/draft-ietf-dtn-ipn-update/"/>.
</t>
<t>
Discussion of this document takes place on the
Delay/Disruption Tolerant Networking Working Group mailing list (<eref t
arget="mailto:dtn@ietf.org"/>),
which is archived at <eref target="https://mailarchive.ietf.org/arch/bro
wse/dtn/"/>.
Subscribe at <eref target="https://www.ietf.org/mailman/listinfo/dtn/"/>
.
</t>
<t>Source for this draft and an issue tracker can be found at
<eref target="https://github.com/ricktaylor/ipn2"/>.</t>
</note>
</front> </front>
<middle> <middle>
<?line 50?>
<section anchor="introduction"> <section anchor="introduction">
<name>Introduction</name> <name>Introduction</name>
<t>The ipn URI scheme was originally defined in <xref target="RFC6260"/> a
nd <xref target="RFC7116"/> as a way to identify network nodes and node services <t>The 'ipn' URI scheme was originally defined in <xref target="RFC6260"/>
using concisely-encoded integers that can be processed faster and with fewer re and <xref target="RFC7116"/> as a way to identify network nodes and node
sources than other verbose identifier schemes. The scheme was designed for use w services using concisely encoded integers that can be processed faster
ith the experimental Bundle Protocol version 6 (BPv6, <xref target="RFC5050"/>) and with fewer resources than other verbose identifier schemes. The
and IPN was defined as an acronym for the term "InterPlanetary Network" in refer scheme was designed for use with the experimental Bundle Protocol
ence to its intended use for deep-space networking. Since then, the efficiency b version 6 (BPv6) <xref target="RFC5050"/>, and "IPN" was defined as an
enefit of integer identifiers makes ipn scheme URIs useful for any networks oper acronym for the term "InterPlanetary Network" in reference to its
ating with limited power, bandwidth, and/or compute budget. Therefore, the term intended use for deep-space networking. Since then, the efficiency
IPN is now used as a non-acronymous name.</t> benefits of integer identifiers make 'ipn' scheme URIs useful for any
<t>Similar to the experimental BPv6, the standardized Bundle Protocol vers network operating with limited power, bandwidth, and/or compute
ion 7 (BPv7, <xref target="RFC9171"/>) codifies support for the use of the ipn U budget. Therefore, the term "IPN" is now used as a non-acronymous
RI scheme for the specification of bundle Endpoint Identifiers (EIDs). The publi name.</t>
cation of BPv7 has resulted in operational deployments of BPv7 nodes for both te
rrestrial and non-terrestrial use cases. This includes BPv7 networks operating o <t>Similar to the experimental BPv6, the standardized Bundle Protocol
ver the terrestrial Internet and BPv7 networks operating in self-contained envir version 7 (BPv7) <xref target="RFC9171"/> codifies support for the use
onments behind a shared administrative domain. The growth in the number and scal of the 'ipn' URI scheme for the specification of bundle Endpoint
e of deployments of BPv7 has been accompanied by a growth in the usage of the ip Identifiers (EIDs). The publication of BPv7 has resulted in operational
n URI scheme which has highlighted areas to improve the structure, moderation, a deployments of BPv7 nodes for both terrestrial and non-terrestrial use
nd management of this scheme.</t> cases. This includes BPv7 networks operating over the terrestrial
<t>By updating <xref target="RFC7116"/> and <xref target="RFC9171"/>, this Internet and BPv7 networks operating in self-contained environments
document updates the specification of the ipn URI scheme, in a backwards-compat behind a shared administrative domain. The growth in the number and
ible way, to provide needed improvements both in the scheme itself and its usage scale of deployments of BPv7 has been accompanied by a growth in the
to specify EIDs with BPv7. Specifically, this document introduces a hierarchica usage of the 'ipn' URI scheme, which has highlighted areas to improve the
l structure for the assignment of ipn scheme URIs, clarifies the behavior and in structure, moderation, and management of this scheme.</t>
terpretation of ipn scheme URIs, defines efficient encodings of ipn scheme URIs,
and updates/defines the registries associated for this scheme.</t> <t>By updating <xref target="RFC7116"/> and <xref target="RFC9171"/>,
<t>Although originally developed by the deep space community for use with this document updates the specification of the 'ipn' URI scheme in a
Bundle Protocol, the ipn URI scheme is sufficiently generic to be used in other backwards-compatible way, in order to provide needed improvements both in
environments where a concise unique representation of a resource on a particular the
node is required.</t> scheme itself and in its usage to specify EIDs with BPv7. Specifically,
<t>It is important to remember that, like most other URI schemes, the ipn this document:</t>
URI scheme defines a unique identifier of a resource, and does not include any t <ul>
opological information describing how to route messages to that resource.</t> <li>introduces a hierarchical structure for the assignment of 'ipn' schem
e URIs,</li>
<li>clarifies the behavior and interpretation of 'ipn' scheme URIs,</li>
<li>defines efficient encodings of 'ipn' scheme URIs, and</li>
<li>updates/defines the registries associated with this scheme.</li>
</ul>
<t>Although originally developed by the deep-space community for use
with the Bundle Protocol, the 'ipn' URI scheme is sufficiently generic to
be
used in other environments where a concise unique representation of a
resource on a particular node is required.</t>
<t>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 no
t
include any topological information describing how to route messages to
that resource.</t>
</section> </section>
<section anchor="conventions-and-definitions"> <section anchor="conventions-and-definitions">
<name>Conventions and Definitions</name> <name>Conventions and Definitions</name>
<t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14 <t>
>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECO "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>
MMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", ",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be i "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
nterpreted as "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
only when, they be
appear in all capitals, as shown here.</t> interpreted as described in BCP&nbsp;14 <xref target="RFC2119"/> <xref
<?line -18?> target="RFC8174"/> when, and only when, they appear in all capitals, as
shown here.
</t>
<t>For the remainder of this document, the term "ipn URI" is used to refer to a URI that uses the ipn scheme.</t> <t>For the remainder of this document, the term "ipn URI" is used to refer to a URI that uses the 'ipn' URI scheme.</t>
</section> </section>
<section anchor="core-concepts"> <section anchor="core-concepts">
<name>Core Concepts</name> <name>Core Concepts</name>
<t>Every ipn URI, no matter whether it is expressed with the textual repre <t>Every ipn URI, no matter whether it is expressed with a textual
sentation or a binary encoding, <bcp14>MUST</bcp14> be considered as a tuple of representation or a binary encoding, <bcp14>MUST</bcp14> be considered
the following three components:</t> as a tuple of the following three components:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>The Allocator Identifier</t> <t>The Allocator Identifier</t>
</li> </li>
<li> <li>
<t>The Node Number</t> <t>The Node Number</t>
</li> </li>
<li> <li>
<t>The Service Number</t> <t>The Service Number</t>
</li> </li>
</ul> </ul>
<t>The Allocator Identifier indicates the entity responsible for assigning
Node Numbers to individual resource nodes, maintaining uniqueness whilst avoidi <t>The Allocator Identifier indicates the entity responsible for
ng the need for a single registry for all assigned Node Numbers. See <xref targe assigning Node Numbers to individual resource nodes, maintaining
t="allocator-identifiers">Allocator Identifiers</xref>.</t> uniqueness whilst avoiding the need for a single registry for all
<t>The Node Number is a shared identifier assigned to all ipn URIs for res assigned Node Numbers. See <xref
ources co-located on a single node. See <xref target="node-numbers">Node Numbers target="allocator-identifiers"/>.</t>
</xref>.</t>
<t>The Service Number is an identifier to distinguish between resources on <t>The Node Number is a shared identifier assigned to all ipn URIs for
a given node. See <xref target="service-numbers">Service Numbers</xref>.</t> resources co-located on a single node. See <xref
<t>The combination of these three components guarantees that every correct target="node-numbers"/>.</t>
ly constructed ipn URI uniquely identifies a single resource. Additionally, the
combination of the Allocator Identifier and the Node Number provides a mechanis <t>The Service Number is an identifier to distinguish between resources
m to uniquely identify the node on which a particular resource is expected to ex on a given node. See <xref target="service-numbers"/>.</t>
ist. See <xref target="fqnn">Fully-qualified Node Number</xref>.</t>
<t>The combination of these three components guarantees that every
correctly constructed ipn URI uniquely identifies a single resource.
Additionally, the combination of the Allocator Identifier and the Node
Number provides a mechanism to uniquely identify the node on which a
particular resource is expected to exist. See <xref
target="fqnn"/>.</t>
<section anchor="null-uri"> <section anchor="null-uri">
<name>The Null ipn URI</name> <name>The Null ipn URI</name>
<t>It has been found that there is value in defining a unique 'null' ipn <t>It has been found that there is value in defining a unique Null
URI to indicate "nowhere". This ipn URI is termed the "Null ipn URI", and has ipn URI to indicate "nowhere". This ipn URI is termed the "Null ipn
all three components: Allocator Identifier, Node Number, and Service Number, set URI" and has all three components (the Allocator Identifier, Node Number
to the value zero (0). No resource identified by Null ipn URI exists, and any ,
destination identified by such a resource is therefore by definition unreachable and Service Number) set to the value zero (0). No resource identified
.</t> by the Null ipn URI exists, and any destination identified by such a
resource is therefore by definition unreachable.</t>
</section> </section>
<section anchor="allocator-identifiers"> <section anchor="allocator-identifiers">
<name>Allocator Identifiers</name> <name>Allocator Identifiers</name>
<t>An Allocator is any organization that wishes to assign Node Numbers f <t>An Allocator is any organization that wishes to assign Node Numbers
or use with the ipn URI scheme, and has the facilities and governance to manage for use with the 'ipn' URI scheme and has the facilities and governance
a public registry of assigned Node Numbers. The authorization to assign these nu to manage a public registry of assigned Node Numbers. The
mbers is provided through the assignment of an Allocator Identifier by IANA. Re authorization to assign these numbers is provided through the
gardless of other attributes of an Allocator, such as a name, point of contact, assignment of an Allocator Identifier by IANA. Regardless of other
or other identifying information, Allocators are identified by Allocator Identif attributes of an Allocator (such as a name, point of contact, or other
iers: a unique, unsigned integer, in the range 0 to 2^32-1.</t> identifying information), Allocators are identified by Allocator
<t>The Allocator Identifier <bcp14>MUST</bcp14> be the sole mechanism us Identifiers: unique, unsigned integers in the range 0 to
ed to identify the Allocator that has assigned the Node Number in an ipn URI. An 2<sup>32-1</sup>.</t>
Allocator may have multiple assigned Allocator Identifiers, but a given Allocat
or Identifier <bcp14>MUST</bcp14> only be associated with a single Allocator.</t <t>The Allocator Identifier <bcp14>MUST</bcp14> be the sole mechanism
> used to identify the Allocator that has assigned the Node Number in an
<t>A new IANA "'ipn' Scheme URI Allocator Identifiers" registry is defin ipn URI. An Allocator may have multiple assigned Allocator
ed for the registration of Allocator Identifiers, see <xref target="iana-allocat Identifiers, but a given Allocator Identifier <bcp14>MUST</bcp14> only
or-identifiers">'ipn' Scheme URI Allocator Identifiers registry</xref>. Althoug be associated with a single Allocator.</t>
h the uniqueness of Allocator Identifiers is required to enforce uniqueness of i
pn URIs, some identifiers are explicitly reserved for experimentation or future <t>A new IANA registry, "'ipn' Scheme URI Allocator Identifiers", is
use.</t> defined for the registration of Allocator Identifiers; see <xref
<t>Each Allocator assigns Node Numbers according to its own policies, wi target="iana-allocator-identifiers"/>. Although the uniqueness of Alloc
thout risk of creating an identical ipn URI, as permitted by the rules in the <x ator
ref target="node-numbers">Node Numbers</xref> section of this document. Other t Identifiers is required to enforce the uniqueness of ipn URIs, some
han ensuring that any Node Numbers it allocates are unique amongst all Node Numb identifiers are explicitly reserved for experimentation or future
ers it assigns, an Allocator does not need to coordinate its allocations with ot use.</t>
her Allocators.</t>
<t>If a system does not require interoperable deployment of ipn scheme U <t>Each Allocator assigns Node Numbers according to its own policies,
RIs, then the <xref target="private-use">Private Use Node Numbers</xref> range, without risk of creating an identical ipn URI, as permitted by the
reserved by the <xref target="default-allocator">Default Allocator</xref> for th rules in <xref target="node-numbers"/>.
is purpose, are to be used.</t> Other than ensuring that any Node Numbers it
allocates are unique amongst all Node Numbers it assigns, an Allocator
does not need to coordinate its allocations with other Allocators.</t>
<t>If a system does not require interoperable deployment of 'ipn' scheme
URIs, then the Private Use Node
Numbers range (<xref target="private-use"/>), reserved by the Default
Allocator (<xref target="default-allocator"/>) for this purpose,
is to be used.</t>
<section anchor="allocator-identifier-ranges"> <section anchor="allocator-identifier-ranges">
<name>Allocator Identifier Ranges</name> <name>Allocator Identifier Ranges</name>
<t>Some organizations with internal hierarchies may wish to delegate t
he allocation of Node Numbers to one or more of their sub-organizations. Rather <t>Some organizations with internal hierarchies may wish to delegate
than assigning unique Allocator Identifiers to each sub-organization on a first the allocation of Node Numbers to one or more of their
-come first-served basis, there are operational benefits in assigning Allocator sub-organizations. Rather than assigning unique Allocator
Identifiers to such an organization in a structured way so that an external obse Identifiers to each sub-organization on a first-come, first-served
rver can detect that a group of Allocator Identifiers are organizationally assoc basis, there are operational benefits in assigning Allocator
iated.</t> Identifiers to such an organization in a structured way. This allows
<t>An Allocator Identifier range is a set of consecutive Allocator Ide an external observer to detect that a group of Allocator Identifiers
ntifiers associated with the same Allocator. Each individual Allocator Identifie is organizationally associated.</t>
r in a given range <bcp14>SHOULD</bcp14> be assigned to a distinct sub-organizat
ion of the Allocator. Assigning identifiers in this way allows external observer <t>An Allocator Identifier range is a set of consecutive Allocator
s both to associate individual Allocator Identifiers with a single organization Identifiers associated with the same Allocator. Each individual
and to usefully differentiate amongst sub-organizations.</t> Allocator Identifier in a given range <bcp14>SHOULD</bcp14> be
<t>The practice of associating a consecutive range of numbers with a s assigned to a distinct sub-organization of the Allocator. Assigning
ingle organization is inspired by the Classless Inter-domain Routing assignment identifiers in this way allows external observers to both associate
of Internet Addresses described in <xref target="RFC4632"/>. In that assignment individual Allocator Identifiers with a single organization and
scheme, an organization (such as an Internet Service Provider) is assigned a net usefully differentiate amongst sub-organizations.</t>
work prefix such that all addresses sharing that same prefix are considered to b
e associated with that organization.</t> <t>The practice of associating a consecutive range of numbers with a
<t>Each Allocator Identifier range is identified by the first Allocato single organization is inspired by the Classless Inter-Domain
r Identifier in the range and the number of consecutive identifiers in the range Routing (CIDR) assignment of Internet addresses described in <xref
.</t> target="RFC4632"/>. In that assignment scheme, an organization (such
<t>Allocator Identifier ranges differ from CIDR addresses in two impor as an Internet Service Provider (ISP)) is assigned a network prefix su
tant ways.</t> ch
<ol spacing="normal" type="1"><li> that all addresses sharing that same prefix are considered to be
associated with that organization.</t>
<t>Each Allocator Identifier range is identified by the first
Allocator Identifier in the range and the number of consecutive
identifiers in the range.</t>
<t>Allocator Identifier ranges differ from CIDR addresses in two impor
tant ways:</t>
<ol spacing="normal" type="1">
<li>
<t>Allocator Identifiers are used to identify organizations and ar e not, themselves, addresses.</t> <t>Allocator Identifiers are used to identify organizations and ar e not, themselves, addresses.</t>
</li> </li>
<li> <li>
<t>Allocator Identifiers may be less than 32 bits in length.</t> <t>Allocator Identifiers may be less than 32 bits in length.</t>
</li> </li>
</ol> </ol>
<t>In order to differentiate between Allocator Identifier ranges using
efficient bitwise operations, all ranges <bcp14>MUST</bcp14> be of a size S tha <t>In order to differentiate between Allocator Identifier ranges
t is a power of 2, and for a given range of length N bits, with S = 2^N, the lea using efficient bitwise operations, all ranges <bcp14>MUST</bcp14>
st-significant N bits of the first Allocator Identifier <bcp14>MUST</bcp14> be a be of a size S that is a power of 2, and for a given range of length
ll 0.</t> N bits, with S = 2<sup>N</sup>, the least-significant N bits of the
<t>An example of the use of Allocator Identifier ranges for four organ first Allocator Identifier <bcp14>MUST</bcp14> be all 0.</t>
izations (A, B, C, and D) is as follows:</t>
<table align="left" anchor="tab-air-example"> <t>An example of the use of Allocator Identifier ranges for four
organizations (A, B, C, and D) is as follows:</t>
<table align="center" anchor="tab-air-example">
<name>Allocator Identifier Range Assignment Example</name> <name>Allocator Identifier Range Assignment Example</name>
<thead> <thead>
<tr> <tr>
<th align="left">Organization</th> <th align="left">Organization</th>
<th align="center">Range (dec)</th> <th align="left">Range (dec)</th>
<th align="center">Range (hex)</th> <th align="left">Range (hex)</th>
<th align="center">Range Length (Bits)</th> <th align="left">Range Length (Bits)</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left">Org A</td> <td align="left">Org A</td>
<td align="center">974848 .. 974975</td> <td align="left">974848 .. 974975</td>
<td align="center">0xEE000 .. 0xEE07F</td> <td align="left">0xEE000 .. 0xEE07F</td>
<td align="center">7 bits</td> <td align="left">7 bits</td>
</tr> </tr>
<tr> <tr>
<td align="left">Org B</td> <td align="left">Org B</td>
<td align="center">974976 .. 974991</td> <td align="left">974976 .. 974991</td>
<td align="center">0xEE080 .. 0xEE08F</td> <td align="left">0xEE080 .. 0xEE08F</td>
<td align="center">4 bits</td> <td align="left">4 bits</td>
</tr> </tr>
<tr> <tr>
<td align="left">Org C</td> <td align="left">Org C</td>
<td align="center">974992 .. 974993</td> <td align="left">974992 .. 974993</td>
<td align="center">0xEE090 .. 0xEE091</td> <td align="left">0xEE090 .. 0xEE091</td>
<td align="center">1 bit</td> <td align="left">1 bit</td>
</tr> </tr>
<tr> <tr>
<td align="left">Org D</td> <td align="left">Org D</td>
<td align="center">974994</td> <td align="left">974994</td>
<td align="center">0xEE092</td> <td align="left">0xEE092</td>
<td align="center">0 bits</td> <td align="left">0 bits</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
<t>With these assignments, any Allocator Identifier whose most-signifi <t>With these assignments, any Allocator Identifier whose
cant 25 bits match 0xEE000 belong to organization A. Similarly, any Allocator Id most-significant 25 bits match 0xEE000 belong to organization
entifier whose most-significant 28 bits match 0xEE080 belong to organization B, A. Similarly, any Allocator Identifier whose most-significant 28
and any Allocator Identifier whose most-significant 31 bits are 0xEE090 belong t bits match 0xEE080 belong to organization B, and any Allocator
o organization C. Organization D has a single Allocator Identifier, and hence a Identifier whose most-significant 31 bits are 0xEE090 belong to
range of bit-length 0.</t> organization C. Organization D has a single Allocator Identifier,
and hence a range of bit-length 0.</t>
</section> </section>
<section anchor="default-allocator"> <section anchor="default-allocator">
<name>The Default Allocator</name> <name>The Default Allocator</name>
<t>As of the publication of <xref target="RFC7116"/>, the only organiz
ation permitted to assign Node Numbers was the Internet Assigned Numbers Authori <t>As of the publication of <xref target="RFC7116"/>, the only
ty (IANA) which assigned Node Numbers via the IANA "CBHE Node Numbers" registry. organization permitted to assign Node Numbers was the Internet
This means that all ipn URIs created prior to the addition of Allocator Identif Assigned Numbers Authority (IANA), which assigned Node Numbers via
iers are assumed to have Node Number allocations that comply with the IANA "CBHE the "CBHE Node Numbers" registry. This means that all ipn URIs
Node Numbers" registry.</t> created prior to the addition of Allocator Identifiers are assumed
<t>The presumption that, unless otherwise specified, Node Numbers are to have Node Number allocations that comply with the "CBHE Node
allocated by IANA from a specific registry is formalized in this update to the i Numbers" registry.</t>
pn URI scheme by designating IANA as the Default Allocator, and by assigning the
Allocator Identifier zero (0) in the <xref target="iana-allocator-identifiers"> <t>The presumption that Node Numbers
'ipn' Scheme URI Allocator Identifiers registry</xref> to the Default Allocator. are allocated by IANA from a specific registry, unless otherwise speci
In any case where an encoded ipn URI does not explicitly include an Allocator fied,
Identifier, an implementation <bcp14>MUST</bcp14> assume that the Node Number ha is formalized in this
s been allocated by the Default Allocator.</t> update to the 'ipn' URI scheme by designating IANA as the Default
<t>A new IANA "'ipn' Scheme URI Default Allocator Node Numbers" regist Allocator and by assigning the Allocator Identifier zero (0) in the
ry is defined to control the allocation of Node Numbers values by the Default Al "'ipn' Scheme URI Allocator Identifiers" registry
locator. This new registry inherits behaviors and existing assignments from the (<xref target="iana-allocator-identifiers"/>) to the Default Allocator.
IANA "CBHE Node Numbers" registry, and reserves some other values as defined in In any case
the <xref target="special-node-numbers">Special Node Numbers</xref> section bel where an encoded ipn URI does not explicitly include an Allocator
ow.</t> Identifier, an implementation <bcp14>MUST</bcp14> assume that the
Node Number has been allocated by the Default Allocator.</t>
<t>A new IANA registry, "'ipn' Scheme URI Default Allocator Node
Numbers", is defined to control the allocation of Node Number
values by the Default Allocator. This new registry inherits
behaviors and existing assignments from the "CBHE Node Numbers"
registry, and it reserves some other values as defined in <xref
target="special-node-numbers"/>
below.</t>
</section> </section>
</section> </section>
<section anchor="node-numbers"> <section anchor="node-numbers">
<name>Node Numbers</name> <name>Node Numbers</name>
<t>A Node Number identifies a node that hosts a resource in the context <t>A Node Number identifies a node that hosts a resource in the
of an Allocator. A Node Number is an unsigned integer. A single Node Number assi context of an Allocator. A Node Number is an unsigned integer. A
gned by a single Allocator <bcp14>MUST</bcp14> refer to a single node.</t> single Node Number assigned by a single Allocator <bcp14>MUST</bcp14>
<t>All Node Number assignments, by all Allocators, <bcp14>MUST</bcp14> b refer to a single node.</t>
e in the range 0 to 2^32-1.</t>
<t>It is <bcp14>RECOMMENDED</bcp14> that Node Number zero (0) not be ass <t>All Node Number assignments, by all Allocators, <bcp14>MUST</bcp14>
igned by an Allocator to avoid confusion with the <xref target="null-uri">Null i be in the range 0 to 2<sup>32-1</sup>.</t>
pn URI</xref>.</t>
<t>It is <bcp14>RECOMMENDED</bcp14> that Node Number zero (0) not be
assigned by an Allocator to avoid confusion with the Null ipn URI (<xref
target="null-uri"/>).</t>
<section anchor="fqnn"> <section anchor="fqnn">
<name>Fully-qualified Node Numbers</name> <name>Fully Qualified Node Numbers</name>
<t>One of the advantages of ipn URIs is the ability to easily split th <t>One of the advantages of ipn URIs is the ability to easily split
e identity of a particular service from the node upon which the service exists. the identity of a particular service from the node upon which the
For example a message received from one particular ipn URI may require a respon service exists. For example, a message received from one particular
se to be sent to a different service on the same node that sent the original mes ipn URI may require a response to be sent to a different service on
sage. Historically the identifier of the sending node has been colloquially ref the same node that sent the original message. Historically, the
erred to as the "node number" or "node identifier".</t> identifier of the sending node has been colloquially referred to as
<t>To avoid future confusion, when referring to the identifier of a pa the "node number" or "node identifier".</t>
rticular node the term "Fully-qualified Node Number" (FQNN) <bcp14>MUST</bcp14>
be used to refer to the combination of the Node Number component and Allocator I <t>To avoid future confusion, when referring to the identifier of a
dentifier component of an ipn URI that uniquely identifies a particular node. I particular node, the term "Fully Qualified Node Number" (FQNN)
n other words, an FQNN is the unique identifier of a particular node that suppor <bcp14>MUST</bcp14> be used to refer to the combination of the Node
ts services identified by ipn URIs.</t> Number component and Allocator Identifier component of an ipn URI
<t>In the examples in this document, FQNNs are written as (Allocator I that uniquely identifies a particular node. In other words, an FQNN
dentifier, Node Number), e.g., <tt>(977000,100)</tt> is the FQNN for a node assi is the unique identifier of a particular node that supports services
gned Node Number 100 by an Allocator with Allocator Identifier 977000.</t> identified by ipn URIs.</t>
<t>In the examples in this document, FQNNs are written as (Allocator
Identifier, Node Number). For example, <tt>(977000,100)</tt> is the FQ
NN
for a node assigned Node Number 100 by an Allocator with Allocator
Identifier 977000.</t>
</section> </section>
</section> </section>
<section anchor="special-node-numbers"> <section anchor="special-node-numbers">
<name>Special Node Numbers</name> <name>Special Node Numbers</name>
<t>Some special-case Node Numbers are defined by the Default Allocator, <t>Some special-case Node Numbers are defined by the Default
see <xref target="iana-node-numbers">'ipn' Scheme URI Default Allocator Node Num Allocator; see <xref target="iana-node-numbers"/>.</t>
bers registry</xref>.</t>
<section anchor="the-zero-node-number"> <section anchor="the-zero-node-number">
<name>The Zero Node Number</name> <name>The Zero Node Number</name>
<t>The Default Allocator assigns the use of Node Number zero (0) solel <t>The Default Allocator assigns the use of Node Number zero (0)
y for identifying the <xref target="null-uri">Null ipn URI</xref>.</t> solely for identifying the Null ipn
<t>This means that any ipn URI with a zero (0) Allocator Identifier an URI (<xref target="null-uri"/>).</t>
d a zero (0) Node Number, but a non-zero Service Number component is invalid. S <t>This means that any ipn URI with a zero (0) Allocator Identifier
uch ipn URIs <bcp14>MUST NOT</bcp14> be composed, and processors of such ipn URI and a zero (0) Node Number, but a non-zero Service Number component,
s <bcp14>MUST</bcp14> consider them as the Null ipn URI.</t> is invalid. Such ipn URIs <bcp14>MUST NOT</bcp14> be composed, and
processors of such ipn URIs <bcp14>MUST</bcp14> consider them as the
Null ipn URI.</t>
</section> </section>
<section anchor="localnode-uri"> <section anchor="localnode-uri">
<name>LocalNode ipn URIs</name> <name>LocalNode ipn URIs</name>
<t>The Default Allocator reserves Node Number 2^32-1 (0xFFFFFFFFF) to <t>The Default Allocator reserves Node Number 2<sup>32-1</sup>
specify resources on the local node, rather than on any specific individual node (0xFFFFFFFFF) to specify resources on the local node, rather than on
.</t> any specific individual node.</t>
<t>This means that any ipn URI with a zero (0) Allocator Identifier an <t>This means that any ipn URI with a zero (0) Allocator Identifier
d a Node Number of 2^32-1 refers to a service on the local bundle node. This for and a Node Number of 2<sup>32-1</sup> refers to a service on the
m of ipn URI is termed a "LocalNode ipn URI".</t> local bundle node. This form of ipn URI is termed a "LocalNode ipn
URI".</t>
</section> </section>
<section anchor="private-use"> <section anchor="private-use">
<name>Private Use Node Numbers</name> <name>Private Use Node Numbers</name>
<t>The Default Allocator provides a range of Node Numbers that are res <t>The Default Allocator provides a range of Node Numbers that are
erved for "Private Use", as defined in <xref target="RFC8126"/>.</t> reserved for Private Use, as defined in <xref
<t>Any ipn URI with a zero (0) Allocator Identifier and a Node Number target="RFC8126"/>.</t>
reserved for "Private Use" is not guaranteed to be unique beyond a single admini <t>Any ipn URI with a zero (0) Allocator Identifier and a Node
strative domain. An administrative domain, as used here, is defined as the set Number reserved for Private Use is not guaranteed to be unique
of nodes that share a unique allocation of FQNNs from the "Private Use" range. beyond a single administrative domain. An administrative domain, as
These FQNNs can be considered to be functionally similar to "Private Address Spa used here, is defined as the set of nodes that share a unique
ce" IPv4 addresses, as defined in <xref target="RFC1918"/>.</t> allocation of FQNNs from the Private Use range. These FQNNs can
<t>Because of this lack of uniqueness, any implementation of a protoco be considered to be functionally similar to private address space
l using ipn URIs that resides on the border between administrative domains <bcp1 IPv4 addresses, as defined in <xref target="RFC1918"/>.</t>
4>MUST</bcp14> have suitable mechanisms in place to prevent protocol units using <t>Because of this lack of uniqueness, any implementation of a
such "Private Use" Node Numbers to cross between different administrative domai protocol using ipn URIs that resides on the border between
ns.</t> administrative domains <bcp14>MUST</bcp14> have suitable mechanisms
in place to prevent protocol units using such Private Use Node
Numbers to cross between different administrative domains.</t>
</section> </section>
</section> </section>
<section anchor="service-numbers"> <section anchor="service-numbers">
<name>Service Numbers</name> <name>Service Numbers</name>
<t>A Service Number is an unsigned integer that identifies a particular <t>A Service Number is an unsigned integer that identifies a
service operating on a node. A service in this case is some logical function th particular service operating on a node. A service in this case is
at requires its own resource identifier to distinguish it from other functions o some logical function that requires its own resource identifier to
perating on the same node.</t> distinguish it from other functions operating on the same node.</t>
</section> </section>
</section> </section>
<section anchor="textual-representation-of-ipn-uris"> <section anchor="textual-representation-of-ipn-uris">
<name>Textual Representation of ipn URIs</name> <name>Textual Representation of ipn URIs</name>
<t>All ipn scheme URIs comply with <xref target="RFC3986"/>, and are there
fore represented by scheme identifier, and a scheme-specific part. The scheme i <t>All 'ipn' scheme URIs comply with <xref target="RFC3986"/> and are
dentifier is: <tt>ipn</tt>, and the scheme-specific parts are represented as a s therefore represented by a scheme identifier and a scheme-specific part.
equence of numeric components separated with the '<tt>.</tt>' character. A form The scheme identifier is <tt>ipn</tt>, and the scheme-specific parts
al definition is provided below, see <xref target="text-syntax">ipn URI Scheme T are represented as a sequence of numeric components separated with the
ext Syntax</xref>, and can be informally considered as:</t> '<tt>.</tt>' character. A formal definition is provided below (see
<xref target="text-syntax"/>) and can be
informally considered as:</t>
<artwork><![CDATA[ <artwork><![CDATA[
ipn:[<allocator-identifier>.]<node-number>.<service-number> ipn:[<allocator-identifier>.]<node-number>.<service-number>
]]></artwork> ]]></artwork>
<t>To keep the text representation concise, the following rules apply:</t> <t>To keep the text representation concise, the following rules apply:</t>
<ol spacing="normal" type="1"><li> <ol spacing="normal" type="1">
<t>All leading <tt>0</tt> characters <bcp14>MUST</bcp14> be omitted. A <li>
single '<tt>0</tt>' is valid.</t> <t>All leading '<tt>0</tt>' characters <bcp14>MUST</bcp14> be
omitted. A single '<tt>0</tt>' is valid.</t>
</li> </li>
<li> <li>
<t>If the Allocator Identifier is zero (0), then the <tt>&lt;allocator <t>If the Allocator Identifier is zero (0), then the
-identifier&gt;</tt> and '<tt>.</tt>' <bcp14>MAY</bcp14> be omitted.</t> <tt>&lt;allocator-identifier&gt;</tt> and '<tt>.</tt>'
<bcp14>MAY</bcp14> be omitted.</t>
</li> </li>
<li> <li>
<t>If the Allocator Identifier is zero (0), and the Node Number is 2^3 <t>If the Allocator Identifier is zero (0), and the Node Number is
2-1, i.e., the URI is a <xref target="localnode-uri">LocalNode ipn URI</xref>, t 2<sup>32-1</sup> (i.e., the URI is a LocalNode ipn URI (<xref
hen the character '<tt>!</tt>' <bcp14>SHOULD</bcp14> be used instead of the digi target="localnode-uri"/>)), then the character
ts <tt>4294967295</tt>, although both forms are valid encodings.</t> '<tt>!</tt>' <bcp14>SHOULD</bcp14> be used instead of the digits
<tt>4294967295</tt>, although both forms are valid encodings.</t>
</li> </li>
</ol> </ol>
<t>Examples of the textual representation of ipn URIs can be found in <xre
f target="text-examples">Appendix A</xref>.</t> <t>Examples of the textual representation of ipn URIs can be found in
<xref target="text-examples"/>.</t>
<section anchor="text-syntax"> <section anchor="text-syntax">
<name>ipn URI Scheme Text Syntax</name> <name>'ipn' URI Scheme Text Syntax</name>
<t>The text syntax of an ipn URI <bcp14>MUST</bcp14> comply with the fol
lowing ABNF <xref target="RFC5234"/> syntax, and reiterates the core ABNF syntax <t>The text syntax of an ipn URI <bcp14>MUST</bcp14> comply with the
rule for DIGIT defined by that specification:</t> following ABNF syntax from <xref target="RFC5234"/> and repeats the
<artwork type="abnf" align="left"><![CDATA[ core ABNF syntax rule for DIGIT defined by that specification:</t>
<sourcecode type="abnf"><![CDATA[
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
node-number = number node-number = number
service-number = number service-number = number
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
]]></artwork> ]]></sourcecode>
</section> </section>
</section> </section>
<section anchor="usage-of-ipn-uris-with-bpv7"> <section anchor="usage-of-ipn-uris-with-bpv7">
<name>Usage of ipn URIs with BPv7</name> <name>Usage of ipn URIs with BPv7</name>
<t>From the earliest days of experimentation with the Bundle Protocol ther
e has been a need to identify the source and destination of a bundle. The IRTF <t>From the earliest days of experimentation with the Bundle Protocol,
BPv6 experimental specification termed the logical source or destination of a bu there has been a need to identify the source and destination of a
ndle as an "Endpoint" identified by an "Endpoint Identifier" (EID). BPv6 EIDs ar bundle. The IRTF BPv6 experimental specification <xref target="RFC5050"/>
e formatted as URIs. This definition and representation of EIDs was carried forw termed the logical
ard from the IRTF BPv6 specification to the IETF BPv7 specification. BPv7 additi source or destination of a bundle as an "Endpoint" identified by an
onally defined an IANA registry called the "Bundle Protocol URI Scheme Types" re "Endpoint Identifier" (EID). BPv6 EIDs are formatted as URIs. This
gistry which identifies those URI schemes than might be used to represent EIDs. definition and representation of EIDs was carried forward from the IRTF
The ipn URI scheme is one such URI scheme.</t> BPv6 specification <xref target="RFC5050"/> to the IETF BPv7 specification
<t>This section identifies the behavior and interpretation of ipn scheme U <xref target="RFC9171"/>. <xref target="RFC9171"/> additionally
RIs that <bcp14>MUST</bcp14> be followed when using this URI scheme to represent defined an IANA registry called the "Bundle Protocol URI Scheme Types"
EIDs in BPv7. An ipn URI used as a BPv7 or BPv6 EID is termed an "ipn EID".</t> registry, which identifies those URI schemes that might be used to
represent EIDs. The 'ipn' URI scheme is one such URI scheme.</t>
<t>This section identifies the behavior and interpretation of 'ipn' scheme
URIs that <bcp14>MUST</bcp14> be followed when using this URI scheme to
represent EIDs in BPv7. An ipn URI used as a BPv7 or BPv6 EID is termed
an "ipn EID".</t>
<section anchor="uniqueness-constraints"> <section anchor="uniqueness-constraints">
<name>Uniqueness Constraints</name> <name>Uniqueness Constraints</name>
<t>An ipn EID <bcp14>MUST</bcp14> identify a singleton endpoint. The bun <t>An ipn EID <bcp14>MUST</bcp14> identify a singleton endpoint. The
dle processing node that is the sole member of that endpoint <bcp14>MUST</bcp14> bundle processing node that is the sole member of that endpoint
be the node identified by the <xref target="fqnn">Fully-qualified Node Number</ <bcp14>MUST</bcp14> be the node identified by the FQNN (<xref
xref> of the node.</t> target="fqnn"/>) of the node.</t>
<t>A single bundle processing node <bcp14>MAY</bcp14> have multiple ipn <t>A single bundle processing node <bcp14>MAY</bcp14> have multiple
EIDs associated with it. However, all ipn EIDs that share any single FQNN <bcp14 ipn EIDs associated with it. However, all ipn EIDs that share any
>MUST</bcp14> refer to the same bundle processing node.</t> single FQNN <bcp14>MUST</bcp14> refer to the same bundle processing
<t>For example, <tt>ipn:977000.100.1</tt>, <tt>ipn:977000.100.2</tt>, an node.</t>
d <tt>ipn:977000.100.3</tt> <bcp14>MUST</bcp14> all refer to services registered
on the bundle processing node identified with FQNN <tt>(977000,100)</tt>. None <t>For example, <tt>ipn:977000.100.1</tt>, <tt>ipn:977000.100.2</tt>,
of these EIDs could be registered on any other bundle processing node.</t> and <tt>ipn:977000.100.3</tt> <bcp14>MUST</bcp14> all refer to
services registered on the bundle processing node identified with FQNN
<tt>(977000,100)</tt>. None of these EIDs could be registered on any
other bundle processing node.</t>
</section> </section>
<section anchor="the-null-endpoint"> <section anchor="the-null-endpoint">
<name>The Null Endpoint</name> <name>The Null Endpoint</name>
<t><xref section="3.2" sectionFormat="of" target="RFC9171"/> defines the <t><xref section="3.2" sectionFormat="of" target="RFC9171"/> defines
concept of the 'null' endpoint, which is an endpoint that has no members and wh the concept of the Null endpoint, which is an endpoint that has no
ich is identified by a special 'null' EID.</t> members and is identified by a special Null EID.</t>
<t>Within the ipn URI scheme, the 'null' EID is represented by the <xref <t>Within the 'ipn' URI scheme, the Null EID is represented by the
target="null-uri">Null ipn URI</xref>. This means that the URIs <tt>dtn:none</ Null ipn URI (<xref target="null-uri"/>). This means that the URIs
tt> (<xref section="4.2.5.1.1" sectionFormat="of" target="RFC9171"/>), <tt>ipn:0 <tt>dtn:none</tt> (<xref section="4.2.5.1.1" sectionFormat="of"
.0</tt>, and <tt>ipn:0.0.0</tt> all refer to the BPv7 'null' endpoint.</t> target="RFC9171"/>), <tt>ipn:0.0</tt>, and <tt>ipn:0.0.0</tt> all
refer to the BPv7 Null endpoint.</t>
</section> </section>
<section anchor="bpv7-node-id"> <section anchor="bpv7-node-id">
<name>BPv7 Node ID</name> <name>BPv7 Node ID</name>
<t><xref section="4.2.5.2" sectionFormat="of" target="RFC9171"/> introdu <t><xref section="4.2.5.2" sectionFormat="of" target="RFC9171"/>
ces the concept of a "Node ID" that has the same format as an EID and that uniqu introduces the concept of a "Node ID" that has the same format as an
ely identifies a bundle processing node.</t> EID and uniquely identifies a bundle processing node.</t>
<t>Any ipn EID can serve as a "Node ID" for the bundle processing node i <t>Any ipn EID can serve as a "Node ID" for the bundle processing node
dentified by its <xref target="fqnn">Fully-qualified Node Number</xref>. That is identified by its FQNN (<xref target="fqnn"/>). That is, any ipn EID of
, any ipn EID of the form ipn:A.B.C may be used as the Source Node ID of any bun the form <tt>ipn:A.B.C</tt> may be used
dle created by the bundle processing node identified by the FQNN <tt>(A,B)</tt>. as the Source Node ID of any bundle created by the bundle processing
</t> node identified by the FQNN <tt>(A,B)</tt>.</t>
</section> </section>
<section anchor="localnode-ipn-eids"> <section anchor="localnode-ipn-eids">
<name>LocalNode ipn EIDs</name> <name>LocalNode ipn EIDs</name>
<t>When a <xref target="localnode-uri">LocalNode ipn URI</xref> is used
as a BPv7 or BPv6 EID, it is termed a "LocalNode ipn EID".</t> <t>When a LocalNode ipn URI (<xref target="localnode-uri"/>) is
<t>Because a LocalNode ipn EID only has meaning on the local bundle node used as a BPv6 or BPv7 EID, it is termed a "LocalNode ipn EID".</t>
, any such EID <bcp14>MUST</bcp14> be considered 'non-routable'. This means that
any bundle using a LocalNode ipn EID as a bundle source or bundle destination < <t>Because a LocalNode ipn EID only has meaning on the local bundle
bcp14>MUST NOT</bcp14> be allowed to leave the local node. Equally, all externa node, any such EID <bcp14>MUST</bcp14> be considered
lly received bundles featuring LocalNode EIDs as a bundle source or bundle desti non-routable. This means that any bundle using a LocalNode ipn EID as
nation <bcp14>MUST</bcp14> be discarded as invalid.</t> a bundle source or bundle destination <bcp14>MUST NOT</bcp14> be
<t>LocalNode ipn EIDs <bcp14>MUST NOT</bcp14> be present in any other pa allowed to leave the local node. Equally, all externally received
rt of a bundle that is transmitted off of the local node. For example, a LocalNo bundles featuring LocalNode EIDs as a bundle source or bundle
de ipn EID <bcp14>MUST NOT</bcp14> be used as a Bundle Protocol Security <xref t destination <bcp14>MUST</bcp14> be discarded as invalid.</t>
arget="RFC9172"/> security source for a bundle transmitted from the local bundle
node, because such a source EID would have no meaning at a downstream bundle no <t>LocalNode ipn EIDs <bcp14>MUST NOT</bcp14> be present in any other
de.</t> part of a bundle that is transmitted off of the local node. For
<t>LocalNode ipn EIDs <bcp14>MUST NOT</bcp14> be published in any node i example, a LocalNode ipn EID <bcp14>MUST NOT</bcp14> be used as a
dentification directory, such as a DNS registration, or presented as part of dyn Bundle Protocol Security (BPSec) <xref target="RFC9172"/> security
amic peer discovery, as the EID has no valid meaning for other nodes. For examp source for a bundle transmitted from the local bundle node, because
le, a LocalNode ipn EID <bcp14>MUST NOT</bcp14> be advertised as the peer Node I such a source EID would have no meaning at a downstream bundle
D during session negotiation in <xref target="RFC9174"/>.</t> node.</t>
<t>LocalNode ipn EIDs <bcp14>MUST NOT</bcp14> be published in any node
identification directory (such as a DNS registration) or presented as
part of dynamic peer discovery, as the EID has no valid meaning for
other nodes. For example, a LocalNode ipn EID <bcp14>MUST NOT</bcp14>
be advertised as the peer Node ID during session negotiation in <xref
target="RFC9174"/>.</t>
</section> </section>
<section anchor="private-use-ipn-eids"> <section anchor="private-use-ipn-eids">
<name>Private Use ipn EIDs</name> <name>Private Use ipn EIDs</name>
<t>Bundles destined for EIDs that use an ipn URI with a <xref target="fq
nn">Fully-qualified Node Number</xref> that is within the "Private Use" range of <t>Bundles destined for EIDs that use an ipn URI with an FQNN (<xref
the <xref target="default-allocator">Default Allocator</xref> are not universal target="fqnn"/>) that is within the
ly unique, and therefore are only valid within the scope of the current administ Private Use range of the Default Allocator (<xref target="default-alloca
rative domain. This means that any bundle using a Private Use ipn EID as a bund tor"/>) are not universally unique; therefore, they are only
le source or bundle destination <bcp14>MUST NOT</bcp14> be allowed to cross admi valid within the scope of the current administrative domain. This
nistrative domains. All implementations that could be deployed as a gateway bet means that any bundle using a Private Use ipn EID as a bundle source
ween administrative domains <bcp14>MUST</bcp14> be sufficiently configurable to or bundle destination <bcp14>MUST NOT</bcp14> be allowed to cross
ensure that this is enforced, and operators <bcp14>MUST</bcp14> ensure correct c administrative domains. All implementations that could be deployed as
onfiguration.</t> a gateway between administrative domains <bcp14>MUST</bcp14> be
<t>Private Use ipn EIDs <bcp14>MUST NOT</bcp14> be present in any other sufficiently configurable to ensure that this is enforced, and
part of a bundle that is destined for another administrative domain when the lac operators <bcp14>MUST</bcp14> ensure correct configuration.</t>
k of uniqueness prevents correct operation. For example, a Private Use ipn EID <
bcp14>MUST NOT</bcp14> be used as a Bundle Protocol Security <xref target="RFC91 <t>Private Use ipn EIDs <bcp14>MUST NOT</bcp14> be present in any
72"/> security source for a bundle, when the bundle is destined for a different other part of a bundle that is destined for another administrative
administrative domain.</t> domain when the lack of uniqueness prevents correct operation. For
example, a Private Use ipn EID <bcp14>MUST NOT</bcp14> be used as a
BPSec <xref target="RFC9172"/> security source for
a bundle when the bundle is destined for a different administrative
domain.</t>
</section> </section>
<section anchor="well-known-service-numbers"> <section anchor="well-known-service-numbers">
<name>Well-known Service Numbers</name> <name>Well-Known Service Numbers</name>
<t>It is convenient for BPv7 services that have a public specification a
nd wide adoption to be identified by a pre-agreed default Service Number, so tha <t>It is convenient for BPv7 services that have a public specification
t unless extra configuration is applied, such services can be sensibly assumed t and wide adoption to be identified by a pre-agreed default Service
o be operating on the well-known Service Number on a particular node.</t> Number, so that unless overridden by explicit configuration, such servic
<t>If a different service uses the number, or the service uses a differe es
nt number, BPv7 will continue to operate, but some configuration may be required can be sensibly assumed to be operating on the well-known Service
to make the individual service operational.</t> Number on a particular node.</t>
<t>A new IANA "'ipn' Scheme URI Well-known Service Numbers for BPv7" reg
istry is defined for the registration of well-known BPv7 Service Numbers, see <x <t>If a different service uses the number, or the service uses a
ref target="iana-service-numbers">'ipn' Scheme URI Well-known Service Numbers fo different number, BPv7 will continue to operate, but some
r BPv7 registry</xref>. This registry records the assignments of Service Number configuration may be required to make the individual service
s for well-known services, and also explicitly reserves ranges for both experime operational.</t>
ntation and private use.</t>
<t>A new IANA registry, "'ipn' Scheme URI Well-Known Service Numbers
for BPv7", is defined for the registration of well-known BPv7 Service
Numbers; see <xref target="iana-service-numbers"/>. This registry
records the assignments of Service Numbers for well-known services
and also explicitly reserves ranges for both experimentation and
Private Use.</t>
</section> </section>
<section anchor="administrative-endpoints"> <section anchor="administrative-endpoints">
<name>Administrative Endpoints</name> <name>Administrative Endpoints</name>
<t>The service identified by a Service Number of zero (0) <bcp14>MUST</b
cp14> be interpreted as the Administrative Endpoint of the node, as defined in < <t>The service identified by a Service Number of zero (0)
xref section="3.2" sectionFormat="of" target="RFC9171"/>.</t> <bcp14>MUST</bcp14> be interpreted as the Administrative Endpoint of
<t>Non-zero Service Numbers <bcp14>MUST NOT</bcp14> be used to identify the node, as defined in <xref section="3.2" sectionFormat="of"
the Administrative Endpoint of a bundle node in an ipn EID.</t> target="RFC9171"/>.</t>
<t>Non-zero Service Numbers <bcp14>MUST NOT</bcp14> be used to
identify the Administrative Endpoint of a bundle node in an ipn
EID.</t>
</section> </section>
</section> </section>
<section anchor="cbor-representation-of-ipn-uris-with-bpv7"> <section anchor="cbor-representation-of-ipn-uris-with-bpv7">
<name>CBOR representation of ipn URIs with BPv7</name> <name>CBOR Representation of ipn URIs with BPv7</name>
<t><xref section="4.2.5.1" sectionFormat="of" target="RFC9171"/> requires <t><xref section="4.2.5.1" sectionFormat="of" target="RFC9171"/>
that any URI scheme used to represent BPv7 EIDs <bcp14>MUST</bcp14> define how t requires that any URI scheme used to represent BPv7 EIDs
he scheme-specific part of the URI scheme is encoded with CBOR <xref target="RFC <bcp14>MUST</bcp14> define how the scheme-specific part of the URI
8949"/>. To meet this requirement, this section describes the CBOR encoding and scheme is encoded with Concise Binary Object Representation (CBOR) <xref t
decoding approach for ipn EIDs. The formal definition of the CBOR representation arget="RFC8949"/>. To meet this
is specified, see <xref target="cbor-encoding">ipn URI Scheme CBOR syntax</xref requirement, this section describes the CBOR encoding and decoding
>.</t> approach for ipn EIDs. The formal definition of the CBOR representation
is specified; see <xref target="cbor-encoding"/>.</t>
<section anchor="ipn-eid-cbor-encoding"> <section anchor="ipn-eid-cbor-encoding">
<name>ipn EID CBOR Encoding</name> <name>ipn EID CBOR Encoding</name>
<t>Generic URI approaches to encoding ipn EIDs are unlikely to be effici <t>Generic URI approaches to encoding ipn EIDs are unlikely to be
ent because they do not consider the underlying structure of the ipn URI scheme. efficient because they do not consider the underlying structure of the
Since the creation of the ipn URI scheme was motivated by the need for concise 'ipn' URI scheme. Since the creation of the 'ipn' URI scheme was motivat
identification and rapid processing, the encoding of ipn EIDs maintains these pr ed
operties.</t> by the need for concise identification and rapid processing, the
<t>Fundamentally, <xref target="RFC9171"/> ipn EIDs are represented as a encoding of ipn EIDs maintains these properties.</t>
sequence of identifiers. In the text syntax, the numbers are separated with the <t>Fundamentally, ipn EIDs from <xref target="RFC9171"/> are represented
'<tt>.</tt>' delimiter; in CBOR, this ordered series of numbers can be represen as
ted by an array. Therefore, when encoding ipn EIDs for use with BPv7, the scheme a sequence of identifiers. In the text syntax, the numbers are
-specific part of an ipn URI <bcp14>MUST</bcp14> be represented as a CBOR array separated with the '<tt>.</tt>' delimiter; in CBOR, this ordered
of either two (2) or three (3) elements. Each element of the array <bcp14>MUST</ series of numbers can be represented by an array. Therefore, when
bcp14> be encoded as a single CBOR unsigned integer.</t> encoding ipn EIDs for use with BPv7, the scheme-specific part of an
<t>The structure and mechanisms of the two-element and three-element enc ipn URI <bcp14>MUST</bcp14> be represented as a CBOR array of either
odings are described below, and examples of the different encodings are provided two (2) or three (3) elements. Each element of the array
in <xref target="cbor-examples">Appendix B</xref>.</t> <bcp14>MUST</bcp14> be encoded as a single CBOR unsigned integer.</t>
<t>The structure and mechanisms of the two-element and three-element
encodings are described below, and examples of the different encodings
are provided in <xref target="cbor-examples"/>.</t>
<section anchor="two-encode"> <section anchor="two-encode">
<name>Two-Element Scheme-Specific Encoding</name> <name>Two-Element Scheme-Specific Encoding</name>
<t>In the two-element scheme-specific encoding of an ipn EID, the firs
t element of the array is an encoding of the <xref target="fqnn">Fully-qualified <t>In the two-element scheme-specific encoding of an ipn EID, the
Node Number</xref> and the second element of the array is the ipn EID Service N first element of the array is an encoding of the FQNN (<xref
umber.</t> target="fqnn"/>), and the second
<t>The FQNN encoding <bcp14>MUST</bcp14> be a 64-bit unsigned integer element of the array is the ipn EID Service Number.</t>
constructed in the following way:</t>
<t>The FQNN encoding <bcp14>MUST</bcp14> be a 64-bit unsigned
integer constructed in the following way:</t>
<ol spacing="normal" type="1"><li> <ol spacing="normal" type="1"><li>
<t>The least significant 32 bits <bcp14>MUST</bcp14> represent the <t>The least significant 32 bits <bcp14>MUST</bcp14> represent
Node Number associated with the ipn EID.</t> the Node Number associated with the ipn EID.</t>
</li> </li>
<li> <li>
<t>The most significant 32 bits <bcp14>MUST</bcp14> represent the <t>The most significant 32 bits <bcp14>MUST</bcp14> represent
Allocator Identifier associated with the ipn EID.</t> the Allocator Identifier associated with the ipn EID.</t>
</li> </li>
</ol> </ol>
<t>For example the ipn EID of <tt>ipn:977000.100.1</tt> has an FQNN of
<tt>(977000,100)</tt> which would be encoded as <tt>0xEE868_00000064</tt>. The <t>For example, the ipn EID of <tt>ipn:977000.100.1</tt> has an FQNN
resulting two-element array <tt>[0xEE868_00000064, 0x01]</tt> would be encoded of <tt>(977000,100)</tt>, which would be encoded as
in CBOR as the following 11 octet sequence:</t> <tt>0xEE868_00000064</tt>. The resulting two-element array
<artwork><![CDATA[ <tt>[0xEE868_00000064, 0x01]</tt> would be encoded in CBOR as the
following 11-octet sequence:</t>
<!--[rfced] In Section 6.1.1 and Appendix B.2, "# 2 Element ipn EID
scheme-specific encoding" is 1 character over the 72-character
limit. Please let us know how you would like to update the
spacing within the sourcecode figures.
Current
Section 6.1.1:
82 # 2-Element Endpoint Encoding
02 # uri-code: 2 (IPN URI scheme)
82 # 2 Element ipn EID scheme-specific encoding
1B 000EE86800000064 # Fully-Qualified Node Number
01 # Service Number
Appendix B.1:
82 # 2-Element Endpoint Encoding
02 # uri-code: 2 (IPN URI scheme)
82 # 2 Element ipn EID scheme-specific encoding
1B 000EE86800000001 # Fully-Qualified Node Number
01 # Service Number
[RT]: @Ed, are you happy to compress "2 Element ipn EID scheme-specific encoding
"
to "2 Element ipn EID encoding" to fit?
-->
<sourcecode type="cbor"><![CDATA[
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
]]></artwork> ]]></sourcecode>
<t>The two-element scheme-specific encoding provides for backwards-com
patibility with the encoding provided in <xref section="4.2.5.1.2" sectionFormat <t>The two-element scheme-specific encoding provides backwards
="of" target="RFC9171"/>. When used in this way, the encoding of the FQNN replac compatibility with the encoding provided in <xref
es the use of the "Node Number" that was specified in RFC9171. When the Node Num section="4.2.5.1.2" sectionFormat="of" target="RFC9171"/>. When used
ber is allocated by the <xref target="default-allocator">Default Allocator</xref in this way, the encoding of the FQNN replaces the use of the Node
>, the encoding of the FQNN and the RFC9171 encoding of the "Node Number" are id Number that was specified in <xref target="RFC9171"/>. When the
entical.</t> Node Number is allocated by the Default Allocator (<xref
target="default-allocator"/>), the encoding of
the FQNN and the encoding of the Node Number from <xref
target="RFC9171"/> are identical.</t>
</section> </section>
<section anchor="three-encode"> <section anchor="three-encode">
<name>Three-Element Scheme-Specific Encoding</name> <name>Three-Element Scheme-Specific Encoding</name>
<t>In the three-element scheme-specific encoding of an ipn EID, the fi <t>In the three-element scheme-specific encoding of an ipn EID:</t>
rst element of the array is the Allocator Identifier, the second element of the
array is the Node Number, and the third element of the array is the Service Numb <ol>
er.</t> <li>the first element of the array is the Allocator Identifier,</li>
<t>For example, the ipn EID of <tt>ipn:977000.100.1</tt> would result <li>the second element of the array is the Node Number, and</li>
in the three-element array of <tt>[977000,100,1]</tt> which would be encoded in <li>the third element of the array is the Service Number.</li>
CBOR as the following 9 octet sequence:</t> </ol>
<artwork><![CDATA[
<t>For example, the ipn EID of <tt>ipn:977000.100.1</tt> would
result in the three-element array of <tt>[977000,100,1]</tt>, which
would be encoded in CBOR as the following 9-octet sequence:</t>
<sourcecode type="cbor"><![CDATA[
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
]]></artwork> ]]></sourcecode>
<t>The three-element scheme-specific encoding allows for a more effici
ent representation of ipn EIDs using smaller Allocator Identifiers, and implemen <t>The three-element scheme-specific encoding allows for a more
tations are <bcp14>RECOMMENDED</bcp14> to use this encoding scheme, unless expli efficient representation of ipn EIDs using smaller Allocator
citly mitigating for interoperability issues, <xref target="compatibility">see S Identifiers, and implementations are <bcp14>RECOMMENDED</bcp14> to
cheme Compatibility</xref>.</t> use this encoding scheme unless explicitly mitigating for
<t>When encoding an ipn EID using the <xref target="default-allocator" interoperability issues; see <xref target="compatibility"/>.</t>
>Default Allocator</xref> with this encoding scheme, the first element of the ar
ray is the value zero (0). In this case using the equivalent <xref target="two- <t>When encoding an ipn EID using the Default Allocator (<xref
encode">Two-Element Scheme-Specific Encoding</xref> will result in a more concis target="default-allocator"/>) with this
e CBOR representation, and therefore it is <bcp14>RECOMMENDED</bcp14> that imple encoding scheme, the first element of the array is the value zero
mentations use that encoding instead.</t> (0). In this case, using the equivalent two-element scheme-specific
encoding (<xref target="two-encode"/>) will
result in a more concise CBOR representation; therefore, it is
<bcp14>RECOMMENDED</bcp14> that implementations use that encoding
instead.</t>
</section> </section>
</section> </section>
<section anchor="ipn-eid-cbor-decoding"> <section anchor="ipn-eid-cbor-decoding">
<name>ipn EID CBOR Decoding</name> <name>ipn EID CBOR Decoding</name>
<t>The presence of different scheme-specific encodings does not introduc
e any decoding ambiguity.</t> <t>The presence of different scheme-specific encodings does not
<t>An ipn EID CBOR decoder can reconstruct an ipn EID using the followin introduce any decoding ambiguity.</t>
g logic. In this description, the term <tt>enc_eid</tt> refers to the CBOR encod <t>An ipn EID CBOR decoder can reconstruct an ipn EID using the
ed ipn EID, and the term <tt>ipn_eid</tt> refers to the decoded ipn EID.</t> following logic. In this description, the term <tt>enc_eid</tt> refers
<artwork align="left" type="pseudocode"><![CDATA[ to the CBOR-encoded ipn EID, and the term <tt>ipn_eid</tt> refers to
the decoded ipn EID.</t>
<sourcecode type="pseudocode"><![CDATA[
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];
} }
]]></artwork> ]]></sourcecode>
</section> </section>
<section anchor="cbor-encoding"> <section anchor="cbor-encoding">
<name>ipn URI Scheme CBOR syntax</name> <name>'ipn' URI Scheme CBOR Syntax</name>
<t>A BPv7 endpoint identified by an ipn URI, when encoded in Concise Bin
ary Object Representation (CBOR) <xref target="RFC8949"/>, <bcp14>MUST</bcp14> c <t>When encoded in CBOR <xref
omply with the following Concise Data Definition Language (CDDL) <xref target="R target="RFC8949"/>, a BPv7 endpoint identified by an ipn URI
FC8610"/> specification:</t> <bcp14>MUST</bcp14> comply with the following Concise Data Definition
<artwork type="cddl" align="left"><![CDATA[ Language (CDDL) <xref target="RFC8610"/> specification:</t>
<sourcecode type="cddl"><![CDATA[
eid = $eid .within eid-structure eid = $eid .within eid-structure
eid-structure = [ eid-structure = [
uri-code: uint, uri-code: uint,
SSP: any SSP: any
] ]
; ... Syntax for other uri-code values defined in RFC9171 ... ; ... Syntax for other uri-code values defined in RFC 9171 ...
$eid /= [ $eid /= [
uri-code: 2, uri-code: 2,
SSP: ipn-ssp2 / ipn-ssp3 SSP: ipn-ssp2 / ipn-ssp3
] ]
ipn-ssp2 = [ ipn-ssp2 = [
fqnn: uint, ; packed value fqnn: uint, ; packed value
service-number: uint service-number: uint
] ]
ipn-ssp3 = [ ipn-ssp3 = [
allocator-identifier: uint .lt 4294967296, allocator-identifier: uint .lt 4294967296,
node-number: uint .lt 4294967296, node-number: uint .lt 4294967296,
service-number: uint service-number: uint
] ]
]]></artwork> ]]></sourcecode>
<t>Note: The <tt>node-number</tt> component will be the numeric represen
tation of the concatenation of the Allocator Identifier and Node Number when the <t>Note: The <tt>node-number</tt> component will be the numeric
2-element encoding scheme has been used.</t> representation of the concatenation of the Allocator Identifier and
Node Number when the two-element encoding scheme has been used.</t>
</section> </section>
<section anchor="ipn-eid-matching"> <section anchor="ipn-eid-matching">
<name>ipn EID Matching</name> <name>ipn EID Matching</name>
<t>Regardless of whether the two-element or three-element scheme-specifi <t>Regardless of whether the two-element or three-element
c encoding is used, ipn EID matching <bcp14>MUST</bcp14> be performed on the dec scheme-specific encoding is used, ipn EID matching <bcp14>MUST</bcp14>
oded EID information itself. Different encodings of the same ipn EID <bcp14>MUST be performed on the decoded EID information itself. Different
</bcp14> be treated as equivalent when performing EID-specific functions.</t> encodings of the same ipn EID <bcp14>MUST</bcp14> be treated as
<t>For example, the ipn EID of <tt>ipn:977000.100.1</tt> can be represen equivalent when performing EID-specific functions.</t>
ted as either the two-element encoding of <tt>0x821B000EE8680000006401</tt> or t
he three-element encoding of <tt>0x831A000EE868186401</tt>. While message integr <t>For example, the ipn EID of <tt>ipn:977000.100.1</tt> can be
ity and other syntax-based checks may treat these values differently, any EID-ba represented as either the two-element encoding of
sed comparisons <bcp14>MUST</bcp14> treat these values the same - as representin <tt>0x821B000EE8680000006401</tt> or the three-element encoding of
g the ipn EID <tt>ipn:977000.100.1</tt>.</t> <tt>0x831A000EE868186401</tt>. While message integrity and other
syntax-based checks may treat these values differently, any EID-based
comparisons <bcp14>MUST</bcp14> treat these values the same: as
representing the ipn EID <tt>ipn:977000.100.1</tt>.</t>
</section> </section>
</section> </section>
<section anchor="special-considerations"> <section anchor="special-considerations">
<name>Special Considerations</name> <name>Special Considerations</name>
<t>The ipn URI scheme provides a compact and hierarchical mechanism for id
entifying services on network nodes. There is a significant amount of utility in <t>The 'ipn' URI scheme provides a compact and hierarchical mechanism for
the ipn URI scheme approach to identification. However, implementers should tak identifying services on network nodes. There is a significant amount of
e into consideration the following observations on the use of the ipn URI scheme utility in the 'ipn' URI scheme approach to identification. However,
, particularly in regard to interoperability with implementations that pre-date implementers should take into consideration the following observations
this specification.</t> on the use of the 'ipn' URI scheme, particularly in regard to
interoperability with implementations that pre-date this
specification.</t>
<section anchor="compatibility"> <section anchor="compatibility">
<name>Scheme Compatibility</name> <name>Scheme Compatibility</name>
<t>The ipn scheme update that has been presented in this document preser
ves backwards compatibility with any ipn URI scheme going back to the provisiona <t>The 'ipn' URI scheme update that has been presented in this document
l definition of the ipn scheme in the experimental Compressed Bundle Header Enco preserves backwards compatibility with any 'ipn' URI scheme going back
ding <xref target="RFC6260"/> specification in 2011. This means that any ipn URI to the provisional definition of the 'ipn' scheme in the experimental
that was valid prior to the publication of this update remains a valid ipn URI. specification "Compressed Bundle Header Encoding (CBHE)" <xref
</t> target="RFC6260"/> in 2011. This means that any ipn URI that was valid
<t>Similarly, the <xref target="two-encode">two-element scheme-specific prior to the publication of this update remains a valid ipn URI.</t>
encoding</xref> is also backwards-compatible with the encoding of ipn URIs provi
ded in <xref target="RFC9171"/>. Any existing RFC9171-compliant implementation w <t>Similarly, the two-element
ill produce an ipn URI encoding in compliance with this specification.</t> scheme-specific encoding (<xref target="two-encode"/>) is also
<t>The introduction of optional non-default Allocator Identifiers and a backwards compatible with the
three-element scheme-specific encoding does not make this ipn URI scheme update encoding of ipn URIs provided in <xref target="RFC9171"/>. Any
forwards-compatible. Existing implementations for which support of this update i existing implementation compliant with <xref target="RFC9171"/> will
s desired <bcp14>MUST</bcp14> be updated to be able to process non-default Alloc produce an ipn URI encoding in compliance with this specification.</t>
ator Identifiers and three-element scheme-specific encodings. It is <bcp14>RECOM <t>The introduction of optional non-default Allocator Identifiers and
MENDED</bcp14> that BPv7 implementations upgrade to process these new features t a three-element scheme-specific encoding does not make this ipn URI
o benefit from the scalability provided by Allocator Identifiers and the encodin scheme update forwards compatible. Existing implementations for which
g efficiencies provided by the three-element encoding.</t> support of this update is desired <bcp14>MUST</bcp14> be updated to be
able to process non-default Allocator Identifiers and three-element
scheme-specific encodings. It is <bcp14>RECOMMENDED</bcp14> that BPv7
implementations upgrade to process these new features to benefit from
the scalability provided by Allocator Identifiers and the encoding
efficiencies provided by the three-element encoding.</t>
</section> </section>
<section anchor="cbor-representation-interoperability"> <section anchor="cbor-representation-interoperability">
<name>CBOR Representation Interoperability</name> <name>CBOR Representation Interoperability</name>
<t>Care must be taken when deploying implementations that default to usi <t>Care must be taken when deploying implementations that default to
ng the three-element encoding in networks that include implementations that only using the three-element encoding in networks that include
support the two-element <xref target="RFC9171"/> encoding. Because the existing implementations that only support the two-element encoding <xref
implementations will reject bundles that use the three-element encoding as malf target="RFC9171"/>. Because the existing implementations will reject
ormed, correct forwarding of semantically valid bundles will fail. The used mit bundles that use the three-element encoding as malformed, correct
igation for this issue depends on the nature of the interoperability required by forwarding of semantically valid bundles will fail. The used
the deployment. Techniques can include:</t> mitigation for this issue depends on the nature of the
interoperability required by the deployment. Techniques can
include:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>A configuration option indicating when an implementation must use <t>A configuration option indicating when an implementation must
the two-element encoding for all ipn EIDs when processing bundles destined to a use the two-element encoding for all ipn EIDs when processing
given endpoint: This would be suitable when adding a newer implementation to a bundles destined to a given endpoint. This would be suitable when
network of existing implementations.</t> adding a newer implementation to a network of existing
implementations.</t>
</li> </li>
<li> <li>
<t>Selective bundle encapsulation, whereby bundles that are known to <t>Selective bundle encapsulation, whereby bundles that are known
originate from implementations that do not support the three-element encoding a to originate from implementations that do not support the
re tunnelled across regions of the network that require the three-element encodi three-element encoding are tunneled across regions of the network
ng: This would utilize specially configured 'gateway nodes' to perform the tunn that require the three-element encoding. This would utilize
el encapsulation and decapsulation, and would be suitable when joining an existi specially configured "gateway nodes" to perform the tunnel
ng network to a larger network.</t> encapsulation and decapsulation and would be suitable when
joining an existing network to a larger network.</t>
</li> </li>
</ul> </ul>
<t>Techniques that do not mitigate the problem include:</t> <t>Techniques that do not mitigate the problem include:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>Heuristic determination of the correct encoding to use when respo <t>Heuristic determination of the correct encoding to use when
nding to a bundle by examining the incoming bundle: It is not possible to deter responding to a bundle by examining the incoming bundle. It is not
mine whether the two-element encoding is required by the destination when compos possible to determine whether the two-element encoding is required
ing a new bundle in response to the receipt of a bundle, such as a status report by the destination when composing a new bundle in response to the
, because ipn EIDs assigned by the Default Allocator use the two-element encodin receipt of a bundle, such as a status report, because ipn EIDs
g, whether the implementation supports the three-element encoding or not.</t> assigned by the Default Allocator use the two-element encoding,
whether or not the implementation supports the three-element encodin
g.</t>
</li> </li>
<li> <li>
<t>Transcoding bundles at intermediate nodes: <xref target="RFC9171"
/> requires the bundle primary block be immutable, and even if ipn EIDs in the p <t>Transcoding bundles at intermediate nodes. <xref
rimary block do not require rewriting, other blocks including the payload block target="RFC9171"/> requires the bundle primary block to be immutable
may include ipn EIDs of which the transcoding node is unaware. Additionally, bu ,
ndle blocks may be covered by <xref target="RFC9172"/> bundle security blocks or and even if ipn EIDs in the primary block do not require
bundle integrity blocks, making them immutable.</t> rewriting, other blocks including the payload block may include
ipn EIDs of which the transcoding node is unaware.
Additionally,
bundle blocks may be covered by bundle
security blocks or bundle integrity blocks <xref target="RFC9172"/>,
making them
immutable.</t>
</li> </li>
</ul> </ul>
</section> </section>
<section anchor="text-representation-compatibility"> <section anchor="text-representation-compatibility">
<name>Text Representation Compatibility</name> <name>Text Representation Compatibility</name>
<t>The textual representation of ipn URIs is not forwards-compatible wit <t>The textual representation of ipn URIs is not forwards compatible
h <xref target="RFC9171"/>, therefore care must be taken when deploying implemen with <xref target="RFC9171"/>. Therefore, care must be taken when
tations or tooling that use the textural representation of ipn URIs and support deploying implementations or tooling that use the textural
for non-default Allocator Identifiers is required. For example <xref section="4 representation of ipn URIs and support for non-default Allocator
.6" sectionFormat="of" target="RFC9174"/> specifies that the Session Initializat Identifiers is required. For example, <xref section="4.6"
ion message "...<bcp14>SHALL</bcp14> contain the UTF-8 encoded node ID of the en sectionFormat="of" target="RFC9174"/> specifies that the session
tity that sent the SESS_INIT message." In such cases the considerations that ap initialization message "...<bcp14>SHALL</bcp14> contain the UTF-8
ply to the use of the 3-element CBOR encoding also apply to the text representat encoded node ID of the entity that sent the SESS_INIT message." In
ion when a non-default Allocator Identifier is present.</t> such cases, the considerations that apply to the use of the three-elemen
t
CBOR encoding also apply to the text representation when a non-default
Allocator Identifier is present.</t>
</section> </section>
<section anchor="bundle-protocol-version-6-compatibility"> <section anchor="bundle-protocol-version-6-compatibility">
<name>Bundle Protocol Version 6 Compatibility</name> <name>Bundle Protocol Version 6 Compatibility</name>
<t>This document updates the use of ipn EIDs for BPv7, however the ipn U <t>This document updates the use of ipn EIDs for BPv7; however, the 'ipn
RI scheme was originally defined for use with version 6 of the Bundle Protocol ( '
BPv6). This document does not update any of the behaviors, wire-formats or mech URI scheme was originally defined for use with BPv6. This document does
anisms of BPv6. Therefore, ipn EIDs with non-default Allocator Identifiers <bcp not update any of the behaviors,
14>MUST NOT</bcp14> be used with BPv6, and the Allocator Identifier prefix <bcp1 wire-formats, or mechanisms of BPv6. Therefore, ipn EIDs with
4>MUST</bcp14> be omitted from any textural representation. It should be noted non-default Allocator Identifiers <bcp14>MUST NOT</bcp14> be used with
that BPv6 has no concept of LocalNode EIDs, and will therefore treat such EIDs a BPv6, and the Allocator Identifier prefix <bcp14>MUST</bcp14> be
s routable.</t> omitted from any textural representation. It should be noted that
BPv6 has no concept of LocalNode EIDs and will therefore treat such
EIDs as routable.</t>
</section> </section>
<section anchor="late-binding"> <section anchor="late-binding">
<name>Late Binding</name> <name>Late Binding</name>
<t><xref target="RFC9171"/> mandates the concept of "late binding" of an
EID, whereby the address of the destination of a bundle is resolved from its id <t><xref target="RFC9171"/> mandates the concept of the "late binding" o
entifier hop-by-hop as it transits a BPv7 network. This per-hop binding of iden f
tifiers to addresses underlines the fact that EIDs are purely names, and should an EID, whereby the address of the destination of a bundle is resolved
not carry any implicit or explicit information concerning the current location o from its identifier hop-by-hop as it transits a BPv7 network. This
r reachability of an identified node and service. This removes the need to rena per-hop binding of identifiers to addresses underlines the fact that
me a node as its location changes.</t> EIDs are purely names and should not carry any implicit or explicit
<t>The concept of "late binding" is preserved in this ipn URI scheme. El information concerning the current location or reachability of an
ements of an ipn URI <bcp14>MUST NOT</bcp14> be regarded as carrying information identified node and service. This removes the need to rename a node
relating to location, reachability, or other addressing/routing concern.</t> as its location changes.</t>
<t>An example of incorrect behavior would be to assume that a given Allo
cator assigns Node Numbers derived from link-layer addresses and to interpret th <t>The concept of late binding is preserved in this 'ipn' URI
e Node Number component of an ipn URI directly as a link-layer address. No matte scheme. Elements of an ipn URI <bcp14>MUST NOT</bcp14> be regarded as
r the mechanism an Allocator uses for the assignment of Node Numbers, they remai carrying information relating to location, reachability, or other
n just numbers, without additional meaning.</t> addressing/routing concerns.</t>
<t>An example of incorrect behavior would be to assume that a given
Allocator assigns Node Numbers derived from link-layer addresses and
to interpret the Node Number component of an ipn URI directly as a
link-layer address. No matter the mechanism an Allocator uses for the
assignment of Node Numbers, they remain just numbers, without
additional meaning.</t>
</section> </section>
</section> </section>
<section anchor="security-considerations"> <section anchor="security-considerations">
<name>Security Considerations</name> <name>Security Considerations</name>
<t>This section updates the security considerations from <xref section="4. <t>This section updates the security considerations from <xref
2.5.1.2" sectionFormat="of" target="RFC9171"/> to account for the inclusion of A section="4.2.5.1.2" sectionFormat="of" target="RFC9171"/> to account for
llocator Identifiers in the ipn URI scheme when used with BPv7.</t> the inclusion of Allocator Identifiers in the 'ipn' URI scheme when used
with BPv7.</t>
<section anchor="reliability-and-consistency"> <section anchor="reliability-and-consistency">
<name>Reliability and consistency</name> <name>Reliability and Consistency</name>
<t>None of the BPv7 endpoints identified by ipn EIDs are guaranteed to b <t>None of the BPv7 endpoints identified by ipn EIDs are guaranteed to
e reachable at any time, and the identity of the processing entities operating o be reachable at any time, and the identity of the processing entities
n those endpoints is never guaranteed by the Bundle Protocol itself. Verificatio operating on those endpoints is never guaranteed by the Bundle
n of the signature provided by the Block Integrity Block targeting the bundle's Protocol itself. Verification of the signature provided by the Block
primary block, as defined by Bundle Protocol Security <xref target="RFC9172"/>, Integrity Block (BIB) targeting the bundle's primary block, as defined b
is required for this purpose.</t> y
"Bundle Protocol Security (BPSec)" <xref target="RFC9172"/>, is required
for
this purpose.</t>
</section> </section>
<!-- [rfced] In the text below, should "such as the use of" read as "such as
with the use of"?
Original:
In both cases (and indeed in all bundle processing), the node that
receives a bundle should verify its authenticity and validity
before operating on it in any way, such as the use of BPSec
[RFC9172], and TCPCLv4 with TLS [RFC9174].
Perhaps:
In both cases (and indeed in all bundle processing), the node that
receives a bundle should verify its authenticity and validity
before operating on it in any way, such as with the use of BPSec
[RFC9172] and TCP Convergence Layer version 4 (TCPCLv4) with TLS
[RFC9174].
[RT]: I don't mind either way, the original is my personal preference,
but the meaning is kept intact. @Ed?
-->
<section anchor="malicious-construction"> <section anchor="malicious-construction">
<name>Malicious construction</name> <name>Malicious Construction</name>
<t>Malicious construction of a conformant ipn URI is limited to the mali <t>Malicious construction of a conformant ipn URI is limited to the
cious selection of Allocator Identifiers, Node Numbers, and Service Numbers. Tha malicious selection of Allocator Identifiers, Node Numbers, and
t is, a maliciously constructed ipn EID could be used to direct a bundle to an e Service Numbers. That is, a maliciously constructed ipn EID could be
ndpoint that might be damaged by the arrival of that bundle or, alternatively, t used to direct a bundle to an endpoint that might be damaged by the
o declare a false source for a bundle and thereby cause incorrect processing at arrival of that bundle or, alternatively, to declare a false source
a node that receives the bundle. In both cases (and indeed in all bundle process for a bundle and thereby cause incorrect processing at a node that
ing), the node that receives a bundle should verify its authenticity and validit receives the bundle. In both cases (and indeed in all bundle
y before operating on it in any way, such as the use of BPSec <xref target="RFC9 processing), the node that receives a bundle should verify its
172"/>, and TCPCLv4 with TLS <xref target="RFC9174"/>.</t> authenticity and validity before operating on it in any way, such as
the use of BPSec <xref target="RFC9172"/> and TCP Convergence Layer vers
ion 4 (TCPCLv4) with TLS <xref
target="RFC9174"/>.</t>
</section> </section>
<section anchor="back-end-transcoding"> <section anchor="back-end-transcoding">
<name>Back-end transcoding</name> <name>Back-End Transcoding</name>
<t>The limited expressiveness of URIs of the ipn scheme effectively elim <t>The limited expressiveness of URIs of the 'ipn' scheme effectively
inates the possibility of threat due to errors in back-end transcoding.</t> eliminates the possibility of threats due to errors in back-end
transcoding.</t>
</section> </section>
<section anchor="local-and-private-use-ipn-eids"> <section anchor="local-and-private-use-ipn-eids">
<name>Local and Private Use ipn EIDs</name> <name>Local and Private Use ipn EIDs</name>
<t>Both <xref target="localnode-uri">LocalNode</xref> and <xref target=" <t>Both LocalNode (<xref target="localnode-uri"/>) and Private Use (<xre
private-use">Private Use</xref> ipn URIs present a risk to the stability of depl f
oyed BPv7 networks. If either type of ipn URI are allowed to propagate beyond t target="private-use"/>) ipn URIs present a risk to the
he domain in which they are valid, then the required uniqueness of ipn URIs no l stability of deployed BPv7 networks. If either type of ipn URI is
onger holds, and this fact can be abused by a malicious node to prevent the corr allowed to propagate beyond the domain in which they are valid, then
ect functioning of the network as a whole.</t> the required uniqueness of ipn URIs no longer holds, and this fact can
<t>See <xref target="localnode-ipn-eids">LocalNode ipn EIDs</xref> and < be abused by a malicious node to prevent the correct functioning of
xref target="private-use-ipn-eids">Private Use ipn EIDs</xref> for required beha the network as a whole.</t>
viors to mitigate against this form of abuse.</t> <t>See Sections <xref target="localnode-ipn-eids" format="counter"/> and
<xref target="private-use-ipn-eids" format="counter"/> for
required behaviors to mitigate against this form of abuse.</t>
</section> </section>
<section anchor="sensitive-information"> <section anchor="sensitive-information">
<name>Sensitive information</name> <name>Sensitive Information</name>
<t>Because ipn URIs are used only to represent the numeric identities of <t>Because ipn URIs are used only to represent the numeric identities
resources, the risk of disclosure of sensitive information due to interception of resources, the risk of disclosure of sensitive information due to
of these URIs is minimal. Examination of ipn URIs could be used to support traff interception of these URIs is minimal. Examination of ipn URIs could
ic analysis; where traffic analysis is a plausible danger, bundles should be con be used to support traffic analysis; where traffic analysis is a
veyed by secure convergence-layer protocols that do not expose endpoint IDs, suc plausible danger, bundles should be conveyed by secure
h as TCPCLv4 <xref target="RFC9174"/>.</t> convergence-layer protocols that do not expose endpoint IDs, such as
TCPCLv4 <xref target="RFC9174"/>.</t>
</section> </section>
<section anchor="semantic-attacks"> <section anchor="semantic-attacks">
<name>Semantic attacks</name> <name>Semantic Attacks</name>
<t>The simplicity of ipn URI scheme syntax minimizes the possibility of <t>The simplicity of the 'ipn' URI scheme syntax minimizes the possibili
misinterpretation of a URI by a human user.</t> ty
of misinterpretation of a URI by a human user.</t>
</section> </section>
</section> </section>
<section anchor="iana"> <section anchor="iana">
<name>IANA Considerations</name> <name>IANA Considerations</name>
<t>The following sections detail requests to IANA for the creation of two
new registries, and the renaming of an existing registry.</t> <!-- [rfced] We have included some specific questions about the IANA
<t>IANA is requested to update the reference to the 'ipn' scheme in the "U text below. In addition to responding to those questions, please
niform Resource Identifier (URI) Schemes" registry to this document.</t> review all of the IANA-related updates carefully and let us know
<t>IANA is requested to add the new registries, and relocate the existing if any further updates are needed. Note that the registries can be
registries under the "Uniform Resource Identifier (URI) Schemes" protocol regist viewed at <https://www.iana.org/assignments/uri-schemes/>.
ry.</t>
b.) The registration procedures in Table 4 do not match the registration
procedures for the "'ipn' Scheme URI Default Allocator Node Numbers"
registry. We updated the reference entries accordingly (see Tables 4 and 5).
Please review and let us know if any further changes are needed.
[RT]:I think Table 4 and 5 are an improvement, but I would drop the duplicate
"Invalid" final row from Table 5.
*[rfced]: removed the "invalid" entry from Table 5.
c.) FYI: We have made "Well-Known" uppercase in the "'ipn' Scheme URI
Well-Known Service Numbers for BPv7" registry name, and we will ask
IANA to make this change prior to publication.
**IANA update needed
d.) We updated Tables 6 and 7 to match the "'ipn' Scheme URI
Well-Known Service Numbers for BPv7" registry. Please let us
know if any further changes are needed.
[RT]: I'm not sure I like the duplication of the "Reserved for..."
entries in Table 7. If the entries are reserved in table 6, why are
they 'initial' in Table 7?
*[rfced]: removed the entry in Table 7.
f.) In Tables 2, 4, 6, and 7, we assume that ">= 2^32" is the same as
">=0x100000000" in the IANA registries. Are any changes desired in
the document to make this consistent with the IANA registries, or will
this variance be clear to readers?
[RT]: We hope this is clear to readers. Happy with the change
**[rfced]: is action needed or is the current ok?
i.) We note the following variances in the IANA registries. Should
these be made consistent by replacing "greater than" with ">="?
In the "'ipn' Scheme URI Allocator Identifiers" and "'ipn' Scheme URI
Default Allocator Node Numbers" registries:
">=0x100000000"
In the "'ipn' Scheme URI Well-Known Service Numbers for BPv7"
registry:
"greater than 0x100000000"
[RT]: Happy with >= instead of "greater than or equal to".
** IANA update needed
ii.) FYI: In Table 5, we replaced ">= 2^32" with ">=4294967296"
("Invalid") to match the "'ipn' Scheme URI Default Allocator Node
Numbers" registry. Please let us know if this is not correct.
*[rfced]: removed this entry per the author to avoid redundancy.
-->
<t>The following sections detail the creation of
two new IANA registries and the renaming of an existing IANA registry unde
r the "Uniform Resource Identifier (URI) Schemes" registry group.</t>
<t>IANA has also updated the reference for the 'ipn' scheme to this docume
nt in the
"Uniform Resource Identifier (URI) Schemes" registry.</t>
<section anchor="iana-allocator-identifiers"> <section anchor="iana-allocator-identifiers">
<name>'ipn' Scheme URI Allocator Identifiers registry</name> <name>'ipn' Scheme URI Allocator Identifiers Registry</name>
<t>IANA is requested to create a new registry entitled "'ipn' Scheme URI <t>IANA has created a new registry titled "'ipn' Scheme
Allocator Identifiers". The registration policy for this registry, using terms URI Allocator Identifiers". Using terms defined in <xref
defined in <xref target="RFC8126"/>, is:</t> target="RFC8126"/>, the registration procedures for this registry are:</
<table align="left" anchor="tab-ipn-allocator-identifiers-reg"> t>
<name>'ipn' Scheme URI Numbering Allocator Identifiers registration po
licies</name> <table align="center" anchor="tab-ipn-allocator-identifiers-reg">
<name>Registration Procedures for the 'ipn' Scheme URI Allocator Ident
ifiers Registry</name>
<thead> <thead>
<tr> <tr>
<th align="center">Range</th> <th align="left">Range</th>
<th align="left">Registration Policy</th> <th align="left">Registration Procedures</th>
<th align="left">Note</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="center">0..0xFFFF</td> <td align="left">0..0xFFFF</td>
<td align="left">Expert Review, Single Allocator Identifiers only< <td align="left">Expert Review</td>
/td> <td>Single Allocator Identifiers only</td>
</tr> </tr>
<tr> <tr>
<td align="center">0x10000..0x3FFFFFFF</td> <td align="left">0x10000..0x3FFFFFFF</td>
<td align="left">Expert Review</td> <td align="left">Expert Review</td>
<td></td>
</tr> </tr>
<tr> <tr>
<td align="center">0x40000000..0x7FFFFFFF</td> <td align="left">0x40000000..0x7FFFFFFF</td>
<td align="left">Experimental Use</td> <td align="left">Experimental Use</td>
<td></td>
</tr> </tr>
<tr> <tr>
<td align="center">0x80000000..0xFFFFFFFF</td> <td align="left">0x80000000..0xFFFFFFFF</td>
<td align="left">Reserved, Future Expansion</td> <td align="left">Reserved</td>
<td> Future Expansion</td>
</tr> </tr>
<tr> <tr>
<td align="center">&gt;= 2^32</td> <td align="left">&gt;= 2<sup>32</sup></td>
<td align="left">Reserved</td> <td align="left">Reserved</td>
<td></td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
<t>Each entry in this registry associates one or more Allocator Identifi
ers with a single organization. Within the registry, the organization is identif <t>Each entry in this registry associates one or more Allocator
ied using the "Name" and "Point of Contact" fields. It is expected that each ide Identifiers with a single organization. Within the registry, the
ntified organization publishes some listing of allocated node numbers - the poin organization is identified using the "Name" and "Change Controller"
ter to which is listed in the "Reference" field of the registry.</t> fields. It is expected that each identified organization will publish
<t>Note that the “Single Allocator Identifiers only” language in Registr some listing of allocated Node Numbers, the pointer to which is
ation Policy for this registry indicates that, within the indicated range, the a listed in the "Reference" field of the registry.</t>
llocation of a sequence of consecutive Allocator identifiers to a single organiz
ation is prohibited. IANA is requested to note this in the registration policy <t>Note that the "Single Allocator Identifiers only" language in
for this registry.</t> the registration procedure for this registry indicates that, within the
<t>The initial values for the registry are:</t> indicated range, the allocation of a sequence of consecutive Allocator
<table align="left" anchor="tab-ipn-allocator-identifiers-vals"> Identifiers to a single organization is prohibited.</t>
<name>'ipn' Scheme URI Allocator Identifiers initial values</name>
<t>The initial values in the registry are:</t>
<table align="center" anchor="tab-ipn-allocator-identifiers-vals">
<name>Initial Values in the 'ipn' Scheme URI Allocator Identifiers Reg
istry</name>
<thead> <thead>
<tr> <tr>
<th align="left">Name</th> <th align="left">Name</th>
<th align="center">Range (dec)</th> <th align="left">Range (dec)</th>
<th align="center">Range (hex)</th> <th align="left">Range (hex)</th>
<th align="center">Range Length (Bits)</th> <th align="left">Range Length (Bits)</th>
<th align="center">Reference</th> <th align="left">Reference</th>
<th align="center">Point of Contact</th> <th align="left">Change Controller</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left"> <td align="left">Default Allocator</td>
<xref target="default-allocator">Default Allocator</xref></td> <td align="left">0</td>
<td align="center">0</td> <td align="left">0x0</td>
<td align="center">0x0</td> <td align="left">0</td>
<td align="center">0</td> <td align="left">RFC 9758, <xref target="default-allocator"/></td>
<td align="center">This document</td> <td align="left">IETF</td>
<td align="center">IANA</td>
</tr> </tr>
<tr> <tr>
<td align="left">Example Range</td> <td align="left">Example Range</td>
<td align="center">974848 .. 978943</td> <td align="left">974848-978943</td>
<td align="center">0xEE000 .. 0xEEFFF</td> <td align="left">0xEE000-0xEEFFF</td>
<td align="center">12 bits</td> <td align="left">12 bits</td>
<td align="center">This document</td> <td align="left">RFC 9758</td>
<td align="center">IANA</td> <td align="left">IETF</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
<t>The "Example Range" is assigned for use in examples in documentation <t>The "Example Range" is assigned for use in examples in
and sample code.</t> documentation and sample code.</t>
<section anchor="guidance-for-designated-experts"> <section anchor="guidance-for-designated-experts">
<name>Guidance for Designated Experts</name> <name>Guidance for Designated Experts</name>
<t>Due to the nature of the CBOR encoding of unsigned integers used fo <t>Due to the nature of the CBOR encoding of unsigned integers used
r Allocator Identifiers with BPv7, Allocator Identifiers with a low value number for Allocator Identifiers with BPv7, Allocator Identifiers with a
are encoded more efficiently than larger numbers. This makes low value Allocat low value number are encoded more efficiently than larger numbers.
or Identifiers more desirable than larger Allocator Identifiers, and therefore c This makes low value Allocator Identifiers more desirable than
are must be taken when assigning Allocator Identifier ranges to ensure that a si larger Allocator Identifiers; therefore, care must be taken when
ngle applicant is not granted a large swathe of highly desirable numbers at the assigning Allocator Identifier ranges to ensure that a single
expense of other applicants. To this end, Designated Experts are strongly recom applicant is not granted a large swathe of highly desirable numbers
mended to familiarize themselves with the CBOR encoding of unsigned integers in at the expense of other applicants. To this end, designated experts
<xref target="RFC8949"/>.</t> are strongly recommended to familiarize themselves with the CBOR
encoding of unsigned integers in <xref target="RFC8949"/>.</t>
</section> </section>
</section> </section>
<section anchor="iana-node-numbers"> <section anchor="iana-node-numbers">
<name>'ipn' Scheme URI Default Allocator Node Numbers registry</name> <name>'ipn' Scheme URI Default Allocator Node Numbers Registry</name>
<t>IANA is requested to rename the "CBHE Node Numbers" registry defined
in <xref section="3.2.1" sectionFormat="of" target="RFC7116"/> to the "'ipn' Sch <t>IANA has renamed the "CBHE Node Numbers" registry
eme URI Default Allocator Node Numbers" registry.</t> (defined in <xref section="3.2.1" sectionFormat="of" target="RFC7116"/>)
<t>The registration policy for this registry, using terms defined in <xr to the "'ipn' Scheme URI Default Allocator Node Numbers" registry and mo
ef target="RFC8126"/>, is updated to be:</t> ved it to the "Uniform Resource Identifier (URI) Schemes" registry group. IANA h
<table align="left" anchor="tab-ipn-node-numbers-reg"> as added the following note to the "CBHE Node Numbers" registry:</t>
<name>'ipn' Scheme URI Default Allocator Node Numbers registration pol
icies</name> <blockquote>
Note: Renamed "CBHE Node Numbers" as "'ipn' Scheme URI Default Allocator Node Nu
mbers" and moved it to &lt;<eref target="https://www.iana.org/assignments/uri-sc
hemes"/>&gt; per RFC 9758.
</blockquote>
<t>Using terms defined in <xref target="RFC8126"/>, the registration pro
cedures for this registry are:</t>
<table align="center" anchor="tab-ipn-node-numbers-reg">
<name>Registration Procedures for the 'ipn' Scheme URI Default Allocat
or Node Numbers Registry</name>
<thead> <thead>
<tr> <tr>
<th align="center">Range</th> <th align="left">Range</th>
<th align="left">Registration Policy</th> <th align="left">Registration Procedures</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="center">0</td> <td align="left">1..0x3FFF</td>
<td align="left">Reserved for the <xref target="null-uri">Null ipn
URI</xref></td>
</tr>
<tr>
<td align="center">1..0x3FFF</td>
<td align="left">Private Use</td> <td align="left">Private Use</td>
</tr> </tr>
<tr> <tr>
<td align="center">0x4000..0xFFFFFFFE</td> <td align="left">0x4000..0xFFFFFFFE</td>
<td align="left">Expert Review</td> <td align="left">Expert Review</td>
</tr>
<tr>
<td align="left">&gt;= 2<sup>32</sup></td>
<td align="left">Invalid</td>
</tr> </tr>
</tbody>
</table>
<t>IANA has registered the following values in the "'ipn' Scheme URI Defa
ult Allocator Node Numbers" registry:</t>
<table align="center" anchor="tab-ipn-scheme-uri-DA-identifiers">
<name>New Values in the 'ipn' Scheme URI Default Allocator Node Number
s Registry</name>
<thead>
<tr> <tr>
<td align="center">0xFFFFFFFF</td> <th align="left">Value</th>
<td align="left">Reserved for <xref target="localnode-uri">LocalNo <th align="left">Description</th>
de ipn URIs</xref></td> <th align="left">Reference</th>
</tr> </tr>
</thead>
<tbody>
<tr> <tr>
<td align="center">&gt;= 2^32</td> <td align="left">0</td>
<td align="left">Invalid</td> <td align="left">Reserved for the Null ipn URI</td>
<td align="left"><xref target="RFC7116"/> and RFC 9758, <xref targe
t="null-uri"/></td>
</tr> </tr>
<tr>
<td align="left">4294967295</td>
<td align="left">Reserved for LocalNode ipn URIs</td>
<td align="left">RFC 9758, <xref target="localnode-uri"/></td>
</tr>
</tbody> </tbody>
</table> </table>
<t>As IANA is requested to only rename the registry, all existing regist
rations will remain.</t> <t>As IANA has only renamed the registry, all existing
registrations will remain.</t>
</section> </section>
<section anchor="iana-service-numbers"> <section anchor="iana-service-numbers">
<name>'ipn' Scheme URI Well-known Service Numbers for BPv7 registry</nam <name>'ipn' Scheme URI Well-Known Service Numbers for BPv7 Registry</nam
e> e>
<t>IANA is requested to create a new registry entitled "'ipn' Scheme URI
Well-known Service Numbers for BPv7" registry. The registration policy for thi <t>IANA has created a new registry titled "'ipn' Scheme
s registry, using terms defined in <xref target="RFC8126"/>, is:</t> URI Well-Known Service Numbers for BPv7". Using terms defined in
<table align="left" anchor="tab-ipn-service-numbers-reg"> <xref target="RFC8126"/>, the registration procedures for this registry
<name>'ipn' Scheme URI Well-known Service Numbers for BPv7 registratio are:</t>
n policies</name>
<table align="center" anchor="tab-ipn-service-numbers-reg">
<name>Registration Procedures for the 'ipn' Scheme URI Well-Known Serv
ice Numbers for BPv7 Registry</name>
<thead> <thead>
<tr> <tr>
<th align="center">Range</th> <th align="left">Range</th>
<th align="left">Registration Policy</th> <th align="left">Registration Procedures</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="center">0</td> <td align="left">1..127</td>
<td align="left">Reserved for the <xref target="administrative-end
points">Administrative Endpoint</xref></td>
</tr>
<tr>
<td align="center">1..127</td>
<td align="left">Private Use</td> <td align="left">Private Use</td>
</tr> </tr>
<tr> <tr>
<td align="center">128..255</td> <td align="left">128..255</td>
<td align="left">Standards Action</td> <td align="left">Standards Action</td>
</tr> </tr>
<tr> <tr>
<td align="center">0x0100..0x7FFF</td> <td align="left">0x0100..0x7FFF</td>
<td align="left">Private Use</td> <td align="left">Private Use</td>
</tr> </tr>
<tr> <tr>
<td align="center">0x8000..0xFFFF</td> <td align="left">0x8000..0xFFFF</td>
<td align="left">Specification Required</td> <td align="left">Specification Required</td>
</tr> </tr>
<tr> <tr>
<td align="center">0x10000..0xFFFFFFFF</td> <td align="left">0x10000..0xFFFFFFFF</td>
<td align="left">Private Use</td> <td align="left">Private Use</td>
</tr> </tr>
<tr> <tr>
<td align="center">&gt;= 2^32</td> <td align="left">&gt;= 2<sup>32</sup></td>
<td align="left">Reserved for future expansion</td> <td align="left">Reserved for future expansion</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
<t>The initial values for the registry are:</t>
<table align="left" anchor="tab-ipn-service-numbers-vals"> <t>The initial values in the registry are:</t>
<name>'ipn' Scheme URI Well-known Service Numbers for BPv7 initial val
ues</name> <table align="center" anchor="tab-ipn-service-numbers-vals">
<name>Initial Values in the 'ipn' Scheme URI Well-Known Service Number
s for BPv7 Registry</name>
<thead> <thead>
<tr> <tr>
<th align="center">Value</th> <th align="left">Value</th>
<th align="left">Description</th> <th align="left">Description</th>
<th align="left">Reference</th> <th align="left">Reference</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="center">0</td> <td align="left">0</td>
<td align="left">The <xref target="administrative-endpoints">Admin <td align="left">The Administrative Endpoint</td>
istrative Endpoint</xref></td>
<td align="left"> <td align="left">
<xref target="RFC9171"/>, This document</td> <xref target="RFC9171"/> and RFC 9758, <xref target="administrat ive-endpoints"/></td>
</tr> </tr>
<tr> <tr>
<td align="center">0xEEE0 .. 0xEEEF</td> <td align="left">0xEEE0..0xEEEF</td>
<td align="left">Example Range</td> <td align="left">Example Range</td>
<td align="left">This document</td> <td align="left">RFC 9758</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
<t>The "Example Range" is assigned for use in examples in documentation <t>The "Example Range" is assigned for use in examples in
and sample code.</t> documentation and sample code.</t>
<section anchor="guidance-for-designated-experts-1"> <section anchor="guidance-for-designated-experts-1">
<name>Guidance for Designated Experts</name> <name>Guidance for Designated Experts</name>
<t>This registry is intended to record the default Service Numbers for <t>This registry is intended to record the default Service Numbers
well-known, interoperable services available and of use to the entire BPv7 comm for well-known, interoperable services that are available and of use t
unity, hence all ranges not marked for Private Use <bcp14>MUST</bcp14> have a co o the
rresponding publicly available specification describing how one interfaces with entire BPv7 community; hence, all ranges not marked for Private Use
the service.</t> <bcp14>MUST</bcp14> have a corresponding publicly available
<t>Services that are specific to a particular deployment or co-operati specification describing how one interfaces with the service.</t>
on may require a registry to reduce administrative burden, but do not require an <t>Services that are specific to a particular deployment or
entry in this registry.</t> co-operation may require a registry to reduce administrative burden,
but do not require an entry in this registry.</t>
</section> </section>
</section> </section>
</section> </section>
</middle> </middle>
<back> <back>
<references> <references>
<name>References</name> <name>References</name>
<references anchor="sec-normative-references"> <references anchor="sec-normative-references">
<name>Normative References</name> <name>Normative References</name>
<reference anchor="RFC6260"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
<front> 260.xml"/>
<title>Compressed Bundle Header Encoding (CBHE)</title> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
<author fullname="S. Burleigh" initials="S." surname="Burleigh"/> 116.xml"/>
<date month="May" year="2011"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
<abstract> 171.xml"/>
<t>This document describes a convention by which Delay-Tolerant Ne <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
tworking (DTN) Bundle Protocol (BP) "convergence-layer" adapters may represent e 119.xml"/>
ndpoint identifiers in a compressed form within the primary blocks of bundles, p <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
rovided those endpoint identifiers conform to the structure prescribed by this c 174.xml"/>
onvention.</t> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
<t>Compressed Bundle Header Encoding (CBHE) compression is a conve 126.xml"/>
rgence-layer adaptation. It is opaque to bundle processing. Therefore, it has no <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
impact on the interoperability of different Bundle Protocol implementations, bu 234.xml"/>
t instead affects only the interoperability of different convergence-layer adapt <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
ation implementations.</t> 949.xml"/>
<t>This document is a product of the Delay-Tolerant Networking Res <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
earch Group and has been reviewed by that group. No objections to its publicatio 610.xml"/>
n as an RFC were raised. This document defines an Experimental Protocol for the
Internet community.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6260"/>
<seriesInfo name="DOI" value="10.17487/RFC6260"/>
</reference>
<reference anchor="RFC7116">
<front>
<title>Licklider Transmission Protocol (LTP), Compressed Bundle Head
er Encoding (CBHE), and Bundle Protocol IANA Registries</title>
<author fullname="K. Scott" initials="K." surname="Scott"/>
<author fullname="M. Blanchet" initials="M." surname="Blanchet"/>
<date month="February" year="2014"/>
<abstract>
<t>The DTNRG Research Group has defined the experimental Licklider
Transmission Protocol (LTP) and the Compressed Bundle Header Encoding (CBHE) me
chanism for the InterPlanetary Network ('ipn' URI scheme). Moreover, RFC 5050 de
fines values for the Bundle Protocol administrative record type. All of these fi
elds are subject to a registry. For the purpose of its research work, the group
has created ad hoc registries. As the specifications are stable and have multipl
e interoperable implementations, the group would like to hand off the registries
to IANA for official management. This document describes the necessary IANA act
ions.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7116"/>
<seriesInfo name="DOI" value="10.17487/RFC7116"/>
</reference>
<reference anchor="RFC9171">
<front>
<title>Bundle Protocol Version 7</title>
<author fullname="S. Burleigh" initials="S." surname="Burleigh"/>
<author fullname="K. Fall" initials="K." surname="Fall"/>
<author fullname="E. Birrane, III" initials="E." surname="Birrane, I
II"/>
<date month="January" year="2022"/>
<abstract>
<t>This document presents a specification for the Bundle Protocol,
adapted from the experimental Bundle Protocol specification developed by the De
lay-Tolerant Networking Research Group of the Internet Research Task Force and d
ocumented in RFC 5050.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9171"/>
<seriesInfo name="DOI" value="10.17487/RFC9171"/>
</reference>
<reference anchor="RFC2119">
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</tit
le>
<author fullname="S. Bradner" initials="S." surname="Bradner"/>
<date month="March" year="1997"/>
<abstract>
<t>In many standards track documents several words are used to sig
nify the requirements in the specification. These words are often capitalized. T
his document defines these words as they should be interpreted in IETF documents
. This document specifies an Internet Best Current Practices for the Internet Co
mmunity, and requests discussion and suggestions for improvements.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="2119"/>
<seriesInfo name="DOI" value="10.17487/RFC2119"/>
</reference>
<reference anchor="RFC8174">
<front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</ti
tle>
<author fullname="B. Leiba" initials="B." surname="Leiba"/>
<date month="May" year="2017"/>
<abstract>
<t>RFC 2119 specifies common key words that may be used in protoco
l specifications. This document aims to reduce the ambiguity by clarifying that
only UPPERCASE usage of the key words have the defined special meanings.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="8174"/>
<seriesInfo name="DOI" value="10.17487/RFC8174"/>
</reference>
<reference anchor="RFC8126">
<front>
<title>Guidelines for Writing an IANA Considerations Section in RFCs
</title>
<author fullname="M. Cotton" initials="M." surname="Cotton"/>
<author fullname="B. Leiba" initials="B." surname="Leiba"/>
<author fullname="T. Narten" initials="T." surname="Narten"/>
<date month="June" year="2017"/>
<abstract>
<t>Many protocols make use of points of extensibility that use con
stants to identify various protocol parameters. To ensure that the values in the
se fields do not have conflicting uses and to promote interoperability, their al
locations are often coordinated by a central record keeper. For IETF protocols,
that role is filled by the Internet Assigned Numbers Authority (IANA).</t>
<t>To make assignments in a given registry prudently, guidance des
cribing the conditions under which new values should be assigned, as well as whe
n and how modifications to existing values can be made, is needed. This document
defines a framework for the documentation of these guidelines by specification
authors, in order to assure that the provided guidance for the IANA Consideratio
ns is clear and addresses the various issues that are likely in the operation of
a registry.</t>
<t>This is the third edition of this document; it obsoletes RFC 52
26.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="26"/>
<seriesInfo name="RFC" value="8126"/>
<seriesInfo name="DOI" value="10.17487/RFC8126"/>
</reference>
<reference anchor="RFC5234">
<front>
<title>Augmented BNF for Syntax Specifications: ABNF</title>
<author fullname="D. Crocker" initials="D." role="editor" surname="C
rocker"/>
<author fullname="P. Overell" initials="P." surname="Overell"/>
<date month="January" year="2008"/>
<abstract>
<t>Internet technical specifications often need to define a formal
syntax. Over the years, a modified version of Backus-Naur Form (BNF), called Au
gmented BNF (ABNF), has been popular among many Internet specifications. The cur
rent specification documents ABNF. It balances compactness and simplicity with r
easonable representational power. The differences between standard BNF and ABNF
involve naming rules, repetition, alternatives, order-independence, and value ra
nges. This specification also supplies additional rule definitions and encoding
for a core lexical analyzer of the type common to several Internet specification
s. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="STD" value="68"/>
<seriesInfo name="RFC" value="5234"/>
<seriesInfo name="DOI" value="10.17487/RFC5234"/>
</reference>
<reference anchor="RFC8949">
<front>
<title>Concise Binary Object Representation (CBOR)</title>
<author fullname="C. Bormann" initials="C." surname="Bormann"/>
<author fullname="P. Hoffman" initials="P." surname="Hoffman"/>
<date month="December" year="2020"/>
<abstract>
<t>The Concise Binary Object Representation (CBOR) is a data forma
t whose design goals include the possibility of extremely small code size, fairl
y small message size, and extensibility without the need for version negotiation
. These design goals make it different from earlier binary serializations such a
s ASN.1 and MessagePack.</t>
<t>This document obsoletes RFC 7049, providing editorial improveme
nts, new details, and errata fixes while keeping full compatibility with the int
erchange format of RFC 7049. It does not create a new version of the format.</t>
</abstract>
</front>
<seriesInfo name="STD" value="94"/>
<seriesInfo name="RFC" value="8949"/>
<seriesInfo name="DOI" value="10.17487/RFC8949"/>
</reference>
<reference anchor="RFC8610">
<front>
<title>Concise Data Definition Language (CDDL): A Notational Convent
ion to Express Concise Binary Object Representation (CBOR) and JSON Data Structu
res</title>
<author fullname="H. Birkholz" initials="H." surname="Birkholz"/>
<author fullname="C. Vigano" initials="C." surname="Vigano"/>
<author fullname="C. Bormann" initials="C." surname="Bormann"/>
<date month="June" year="2019"/>
<abstract>
<t>This document proposes a notational convention to express Conci
se Binary Object Representation (CBOR) data structures (RFC 7049). Its main goal
is to provide an easy and unambiguous way to express structures for protocol me
ssages and data formats that use CBOR or JSON.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8610"/>
<seriesInfo name="DOI" value="10.17487/RFC8610"/>
</reference>
</references> </references>
<references anchor="sec-informative-references"> <references anchor="sec-informative-references">
<name>Informative References</name> <name>Informative References</name>
<reference anchor="RFC5050"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
<front> 050.xml"/>
<title>Bundle Protocol Specification</title> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
<author fullname="K. Scott" initials="K." surname="Scott"/> 632.xml"/>
<author fullname="S. Burleigh" initials="S." surname="Burleigh"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1
<date month="November" year="2007"/> 918.xml"/>
<abstract> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
<t>This document describes the end-to-end protocol, block formats, 986.xml"/>
and abstract service description for the exchange of messages (bundles) in Dela <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
y Tolerant Networking (DTN).</t> 172.xml"/>
<t>This document was produced within the IRTF's Delay Tolerant Net <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
working Research Group (DTNRG) and represents the consensus of all of the active 174.xml"/>
contributors to this group. See http://www.dtnrg.org for more information. This
memo defines an Experimental Protocol for the Internet community.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5050"/>
<seriesInfo name="DOI" value="10.17487/RFC5050"/>
</reference>
<reference anchor="RFC4632">
<front>
<title>Classless Inter-domain Routing (CIDR): The Internet Address A
ssignment and Aggregation Plan</title>
<author fullname="V. Fuller" initials="V." surname="Fuller"/>
<author fullname="T. Li" initials="T." surname="Li"/>
<date month="August" year="2006"/>
<abstract>
<t>This memo discusses the strategy for address assignment of the
existing 32-bit IPv4 address space with a view toward conserving the address spa
ce and limiting the growth rate of global routing state. This document obsoletes
the original Classless Inter-domain Routing (CIDR) spec in RFC 1519, with chang
es made both to clarify the concepts it introduced and, after more than twelve y
ears, to update the Internet community on the results of deploying the technolog
y described. This document specifies an Internet Best Current Practices for the
Internet Community, and requests discussion and suggestions for improvements.</t
>
</abstract>
</front>
<seriesInfo name="BCP" value="122"/>
<seriesInfo name="RFC" value="4632"/>
<seriesInfo name="DOI" value="10.17487/RFC4632"/>
</reference>
<reference anchor="RFC1918">
<front>
<title>Address Allocation for Private Internets</title>
<author fullname="Y. Rekhter" initials="Y." surname="Rekhter"/>
<author fullname="B. Moskowitz" initials="B." surname="Moskowitz"/>
<author fullname="D. Karrenberg" initials="D." surname="Karrenberg"/
>
<author fullname="G. J. de Groot" initials="G. J." surname="de Groot
"/>
<author fullname="E. Lear" initials="E." surname="Lear"/>
<date month="February" year="1996"/>
<abstract>
<t>This document describes address allocation for private internet
s. This document specifies an Internet Best Current Practices for the Internet C
ommunity, and requests discussion and suggestions for improvements.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="5"/>
<seriesInfo name="RFC" value="1918"/>
<seriesInfo name="DOI" value="10.17487/RFC1918"/>
</reference>
<reference anchor="RFC3986">
<front>
<title>Uniform Resource Identifier (URI): Generic Syntax</title>
<author fullname="T. Berners-Lee" initials="T." surname="Berners-Lee
"/>
<author fullname="R. Fielding" initials="R." surname="Fielding"/>
<author fullname="L. Masinter" initials="L." surname="Masinter"/>
<date month="January" year="2005"/>
<abstract>
<t>A Uniform Resource Identifier (URI) is a compact sequence of ch
aracters that identifies an abstract or physical resource. This specification de
fines the generic URI syntax and a process for resolving URI references that mig
ht be in relative form, along with guidelines and security considerations for th
e use of URIs on the Internet. The URI syntax defines a grammar that is a supers
et of all valid URIs, allowing an implementation to parse the common components
of a URI reference without knowing the scheme-specific requirements of every pos
sible identifier. This specification does not define a generative grammar for UR
Is; that task is performed by the individual specifications of each URI scheme.
[STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="STD" value="66"/>
<seriesInfo name="RFC" value="3986"/>
<seriesInfo name="DOI" value="10.17487/RFC3986"/>
</reference>
<reference anchor="RFC9172">
<front>
<title>Bundle Protocol Security (BPSec)</title>
<author fullname="E. Birrane, III" initials="E." surname="Birrane, I
II"/>
<author fullname="K. McKeever" initials="K." surname="McKeever"/>
<date month="January" year="2022"/>
<abstract>
<t>This document defines a security protocol providing data integr
ity and confidentiality services for the Bundle Protocol (BP).</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9172"/>
<seriesInfo name="DOI" value="10.17487/RFC9172"/>
</reference>
<reference anchor="RFC9174">
<front>
<title>Delay-Tolerant Networking TCP Convergence-Layer Protocol Vers
ion 4</title>
<author fullname="B. Sipos" initials="B." surname="Sipos"/>
<author fullname="M. Demmer" initials="M." surname="Demmer"/>
<author fullname="J. Ott" initials="J." surname="Ott"/>
<author fullname="S. Perreault" initials="S." surname="Perreault"/>
<date month="January" year="2022"/>
<abstract>
<t>This document describes a TCP convergence layer (TCPCL) for Del
ay-Tolerant Networking (DTN). This version of the TCPCL protocol resolves implem
entation issues in the earlier TCPCL version 3 as defined in RFC 7242 and provid
es updates to the Bundle Protocol (BP) contents, encodings, and convergence-laye
r requirements in BP version 7 (BPv7). Specifically, TCPCLv4 uses BPv7 bundles e
ncoded by the Concise Binary Object Representation (CBOR) as its service data un
it being transported and provides a reliable transport of such bundles. This TCP
CL version also includes security and extensibility mechanisms.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9174"/>
<seriesInfo name="DOI" value="10.17487/RFC9174"/>
</reference>
</references> </references>
</references> </references>
<?line 574?>
<section anchor="text-examples"> <section anchor="text-examples">
<name>ipn URI Scheme Text Representation Examples</name> <name>'ipn' URI Scheme Text Representation Examples</name>
<t>This section provides some example ipn URIs in their textual representa tion.</t> <t>This section provides some example ipn URIs in their textual representa tion.</t>
<section anchor="using-the-default-allocator"> <section anchor="using-the-default-allocator">
<name>Using the Default Allocator</name> <name>Using the Default Allocator</name>
<t>Consider the ipn URI identifying Service Number 2 on Node Number 1 al
located by the <xref target="default-allocator">Default Allocator</xref> (0).</t <t>Consider the ipn URI identifying Service Number 2 on Node Number 1
> allocated by the Default Allocator (0) (<xref target="default-allocator"
<t>The recommended seven character representation of this URI would be a />).</t>
s follows:</t>
<t>The recommended seven-character representation of this URI would be
as follows:</t>
<artwork><![CDATA[ <artwork><![CDATA[
ipn:1.2 ipn:1.2
]]></artwork> ]]></artwork>
<t>The nine character representation of this URI, with explicit the Allo
cator Identifier, would be as follows:</t> <t>The nine-character representation of this URI, with the explicit Allo
cator Identifier, would be as follows:</t>
<artwork><![CDATA[ <artwork><![CDATA[
ipn:0.1.2 ipn:0.1.2
]]></artwork> ]]></artwork>
</section> </section>
<section anchor="using-a-non-default-allocator"> <section anchor="using-a-non-default-allocator">
<name>Using a non-default Allocator</name> <name>Using a Non-Default Allocator</name>
<t>Consider the ipn URI identifying Service Number 3 on Node Number 1 al located by Allocator 977000.</t> <t>Consider the ipn URI identifying Service Number 3 on Node Number 1 al located by Allocator 977000.</t>
<t>The 14 character representation of this URI would be as follows:</t> <t>The 14-character representation of this URI would be as follows:</t>
<artwork><![CDATA[ <artwork><![CDATA[
ipn:977000.1.3 ipn:977000.1.3
]]></artwork> ]]></artwork>
</section> </section>
<section anchor="the-null-ipn-uri"> <section anchor="the-null-ipn-uri">
<name>The Null ipn URI</name> <name>The Null ipn URI</name>
<t>The <xref target="null-uri">Null ipn URI</xref> is represented as:</t <t>The Null ipn URI (<xref target="null-uri"/>) is represented as:</t>
>
<artwork><![CDATA[ <artwork><![CDATA[
ipn:0.0 ipn:0.0
]]></artwork> ]]></artwork>
</section> </section>
<section anchor="a-localnode-ipn-uri"> <section anchor="a-localnode-ipn-uri">
<name>A LocalNode ipn URI</name> <name>The LocalNode ipn URI</name>
<t>Consider the ipn URI identifying Service Number 7 on the local node.<
/t> <t>Consider the ipn URI identifying Service Number 7 on the local
<t>The recommended seven character representation of this URI would be a node.</t>
s follows:</t>
<t>The recommended seven-character representation of this URI would be
as follows:</t>
<artwork><![CDATA[ <artwork><![CDATA[
ipn:!.7 ipn:!.7
]]></artwork> ]]></artwork>
<t>The numeric 16 character representation of this URI would be as follo
ws:</t> <t>The numeric 16-character representation of this URI would be as follo
ws:</t>
<artwork><![CDATA[ <artwork><![CDATA[
ipn:4294967295.7 ipn:4294967295.7
]]></artwork> ]]></artwork>
</section> </section>
</section> </section>
<section anchor="cbor-examples"> <section anchor="cbor-examples">
<name>ipn URI Scheme CBOR Encoding Examples</name> <name>'ipn' URI Scheme CBOR Encoding Examples</name>
<t>This section provides some example CBOR encodings of ipn EIDs.</t> <t>This section provides some example CBOR encodings of ipn EIDs.</t>
<section anchor="using-the-default-allocator-1"> <section anchor="using-the-default-allocator-1">
<name>Using the Default Allocator</name> <name>Using the Default Allocator</name>
<t>Consider the ipn EID <tt>ipn:1.1</tt>. This textual representation of <t>Consider the ipn EID <tt>ipn:1.1</tt>. This textual representation
an ipn EID identifies Service Number 1 on Node Number 1 allocated by the <xref of an ipn EID identifies Service Number 1 on Node Number 1 allocated
target="default-allocator">Default Allocator</xref> (0).</t> by the Default Allocator (0) (<xref target="default-allocator"/>).
<t>The recommended five octet encoding of this EID using the two-element </t>
scheme-specific encoding would be as follows:</t> <t>The recommended five-octet encoding of this EID using the
<artwork><![CDATA[ two-element scheme-specific encoding would be as follows:</t>
<sourcecode type="cbor"><![CDATA[
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
]]></artwork> ]]></sourcecode>
<t>The six octet encoding of this EID using the three-element scheme-spe
cific encoding would be as follows:</t> <t>The six-octet encoding of this EID using the three-element
<artwork><![CDATA[ scheme-specific encoding would be as follows:</t>
<sourcecode type="cbor"><![CDATA[
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
]]></artwork> ]]></sourcecode>
</section> </section>
<section anchor="using-a-non-default-allocator-1"> <section anchor="using-a-non-default-allocator-1">
<name>Using a non-default Allocator</name> <name>Using a Non-Default Allocator</name>
<t>Consider the ipn EID <tt>ipn:977000.1.1</tt>. This textual represent <t>Consider the ipn EID <tt>ipn:977000.1.1</tt>. This textual
ation of an ipn EID identifies Service Number 1 on Node Number 1 allocated by Al representation of an ipn EID identifies Service Number 1 on Node
locator 977000.</t> Number 1 allocated by Allocator 977000.</t>
<t>The recommended 10 octet encoding of this EID using the three-element
scheme-specific encoding would be as follows:</t> <t>The recommended 10-octet encoding of this EID using the
<artwork><![CDATA[ three-element scheme-specific encoding would be as follows:</t>
<sourcecode type="cbor"><![CDATA[
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
]]></artwork> ]]></sourcecode>
<t>The 13 octet encoding of this EID using the two-element scheme-specif
ic encoding would be as follows:</t> <t>The 13-octet encoding of this EID using the two-element
<artwork><![CDATA[ scheme-specific encoding would be as follows:</t>
<sourcecode type="cbor"><![CDATA[
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
]]></artwork> ]]></sourcecode>
</section> </section>
<section anchor="the-null-endpoint-1"> <section anchor="the-null-endpoint-1">
<name>The 'null' Endpoint</name> <name>The Null Endpoint</name>
<t>The 'null' EID of <tt>ipn:0.0</tt> can be encoded in the following wa <t>The Null EID of <tt>ipn:0.0</tt> can be encoded in the following
ys:</t> ways:</t>
<t>The recommended five octet encoding of the 'null' ipn EID using the t <t>The recommended five-octet encoding of the Null ipn EID using the
wo-element scheme-specific encoding would be as follows:</t> two-element scheme-specific encoding would be as follows:</t>
<artwork><![CDATA[
<sourcecode type="cbor"><![CDATA[
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
]]></artwork> ]]></sourcecode>
<t>The six octet encoding of the 'null' ipn EID using the three-element
scheme-specific encoding would be as follows:</t> <t>The six-octet encoding of the Null ipn EID using the
<artwork><![CDATA[ three-element scheme-specific encoding would be as follows:</t>
<sourcecode type="cbor"><![CDATA[
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
]]></artwork> ]]></sourcecode>
</section> </section>
</section> </section>
<section numbered="false" anchor="acknowledgments"> <section numbered="false" anchor="acknowledgments">
<name>Acknowledgments</name> <name>Acknowledgments</name>
<t>The following DTNWG participants contributed technical material, use ca <t>The following DTN Working Group participants contributed technical mate
ses, and critical technical review for this URI scheme update: Scott Burleigh of rial, use
the IPNGROUP, Keith Scott, Brian Sipos of the Johns Hopkins University Applied cases, and critical technical reviews for this URI scheme update:
Physics Laboratory, Jorge Amodio of LJCV Electronics, and Ran Atkinson.</t> <contact fullname="Scott Burleigh"/> of the IPNGROUP, <contact
<t>Additionally, the authors wish to thank members of the CCSDS SIS-DTN wo fullname="Keith Scott"/>, <contact fullname="Brian Sipos"/> of the Johns
rking group at large who provided useful review and commentary on this document Hopkins University Applied Physics Laboratory, <contact fullname="Jorge
and its implications for the future of networked space exploration.</t> Amodio"/> of LJCV Electronics, and <contact fullname="Ran
Atkinson"/>.</t>
<t>Additionally, the authors wish to thank members of the CCSDS SIS-DTN
Working Group at large who provided useful reviews and commentary on this
document and its implications for the future of networked space
exploration.</t>
</section> </section>
</back> </back>
<!-- ##markdown-source:
H4sIAAAAAAAAA+V9a3MbybXYd/yKNpREpAuACJKrB22tTYrULh2tpCtS3nJU
G3MADMixBjPwzIAUVivX/SFJVX5Lfsr9JTnPfsyDBNdrJ7l3q2wRwEz36dOn
z/ucHg6HvSqp0vjA9N8vZ1EVmyo31VVskmVm3r87NeX0Kl7E/V40mRTxNTwG
PwxX9Gi/N4X/v8yL9YEpq1mvN8unWbSAsWZFNK+GSVzNh7MqG7pXhuP9Xrma
LJKyTPKsWi/h4dOT85e9bLWYxMVBDx866E3zrIyzclUemKpYxT2Yd68XFXEE
858XUVYu86Lq927y4uNlka+W8PVxnEbrR8dJWayWFYxtzvM0hkcr8zqu8MEk
u+z3PsZr+Ht20DNDc3z+Gv8B4PCfo7fXT/DfF0ffntDnVTZLY/O2yKt8mqe9
3nWcrQA0Y+43ozG8yv73/I35Bl/H7xdRksL3gKDfI6ZGeUGPR8X0Cr6+qqpl
efDoET6FXyXX8Ugfe4RfPJoU+U0ZP4L3H+F7l0l1tZrAm0Uy/VhF6zQvHsHa
dvG3FLBaVt6o7pkRvzdKcnr6EW8d/1bbvNFVtUj7vR5/KgmJz8ZPxvjvk/H4
Mf77ePfxTi9aVVd5gb/D3MbMV2nKdPEOpjXnNDb9AmuJsuTHCNF3YA6jdF0k
kTmPp1dZnuaXSVzSYzGjqmCofh/xc6NpvmhOcTIzR0kB2xC3zPCHb98/Onz7
yh/0ZHYTFbORvPP7v1ytomU6imerXi/LiwW8eA27nmRz96E3HA5NNCmrIppW
vd75VVIaIP3VIoa9F+TQGSqX8TSZJ1Oa3eTzloNllnCqknxVpmszi+dJFs9M
kpl3L18QKgf0yunh60NTxJcJTAk4MbCX0SRNyiv3MOJ/YKJsRi8UqxQeA5Dp
U5xN8xmSHv48i+UDg1PGCExpbq7izKxKGDAq4Tlzks2WeQLrOZ3BqmARcWG2
Tk6Pt3HC2tkwf4wLPM7midnCY7SNY9QWg3QyMuc0oaJoCoSdzNeMKjjn02pV
xATkJL6KACtFO84GMrjJ4hu7uBKfxecEr7gqRojFFqPGoTGLp3FZRsUaed4i
yqJL4H64mTzEiDd6kcxgsb3eA3OaVUU+AzBhrbjtjb28gXXnRXKZZFEa7ufn
z78CLOCOfvlCQPEXuGv4BaAcXiY4Esb3GqAjJmKyfBaX9A7+Zcq4uE4Abtgs
3EXglNOkjNP1kBBBswFPhg2BpUSVmcJeTpDKclwr/DyPygr2Ese7gZNv5vEN
fCziMl8VU6JbeCMHTBXmOi4mOexX4kiAF1rSTvqrBhCTS1wr0hyQEY9NxPdp
GRcJHo0obRDOtRDOYyIcIODPn38HaPlq5yvA0zYBefr2tczAyGTyjKZFnq0X
lsRhSQvThw2Ki7cpnOMKd1XYcB83oIjncQEoIvmWVCWhKUN8IbQ4zCyOl8Ny
GU1jRT3gd2TOEnoJjgefxXgOBzqBkdaA1wyAqojwGOkeqkqgqI+AzxpJ4nTA
rGjGKLO7DHQDaAI+AVtKqEuTRVIBdMsctmdgJoCKm2RWXRFJP4KXgfktVyCu
J6vZZVzRhsAa8yIeOIQg7oCcs/zGHW34lA0FfcB2DHJNoPQzmA+Oo0r/cNdo
a/iUwuzALpMfYbSuzRQuMBAax5OPm4nHdI7HrlwtUXzbvcMNaOeN+kSDj054
6hYmVRKXKreZQpcrOPjuNQTLXAEWgNxXacVHUxCfw5kFGlim+RqXXdrn+fwh
KJMcaTou4G1gIPA4H8ps6H+Hq5lGJZ+RBOlsmq5wBB6sud054E23zI5ClAwP
0xRdbwLwcPLnQ+ABVUSHI86uE9hZXgAw0QTejkx5BaoT/DFbJBnyPhJjILFA
AGaMJ1BpbmBtMCACwroYTV1Oo5R2pw0ziMlJHONpRGoEOQuzTNYwYzjeqkTO
2r7FN1fJ9IpGukour1L4H24LqnolndQFcK7rOBQRA7OAPeFNYxbPzJvkL03j
8/CjNQscxNjnzx7TJS5sCXTAr/1cOT7AxUZwTqcfUZ8oh4SRKpmkyCDXA1wM
LgUYBGxlTIya1yablTt8CWqAS8HuEpzIsBiLMAxDszZI58wscDeAUymUIHvq
q0lEdKEkAUwD8lClhEc9waunLSqRlysyGyKVpXYiqLGSmsBEqgWFprKIarzN
bLy0bLTaQIDLVjzSd2tiHODNp0lUifQJd/8wBVV0dXkVyuXrOIVjRMSKgyHr
N8z6YdsWqyyp1qEkq/G6QRsp47QrXRZMcwniAfRs3LJJzAw4UdEaHNQbZN2w
LyLLDcz/1xUuEVBZIgtWbEZWTpscqW0ZFVUyXSHfJt0gQc7211UCpx2Wflrh
F0BlwGzRKgE4CoCTzjbqBgMQMh9jOEtlJVC5xZStK9QNiBRETzMIwON9m+Wo
ZOWV8kASeFW+JNUeac9q1bAaYJHTIpngKb0CeYXA5ijfFqiiXcYlSybQaHSO
EapkL/LsGkEAe5GmPEYIE/rMGhoYfAYtvtL0v3t/dt4f8L/m9Rv6+93Jv7w/
fXdyjH+ffXv46pX9oydPnH375v2rY/eXe/PFm+++O3l9zC/Dtyb4qtf/7vBP
fUZE/83b89M3rw9f9fmI+ycTWJ1QiD09JKl7ghCmmqMXb//3/xrvi0jdHY+f
AQfjD0/HT/bhww1pKDhbngHx3ajCsu5Fy2UMFIL8KU1BNi0TEOp4tIBeAdWZ
QfIDbP76A2LmhwPz28l0Od7/Wr7ABQdfKs6CLwlnzW8aLzMSW75qmcZiM/i+
hukQ3sM/BZ8V796Xv/1diqbDcPz0d1/3er2XwvQKNAdBHyysANEd8vSpvpyH
Ph4sOtB0puYx6U0RHRWiUfittAfI8iIkV9htoNlpvKyAQE9A9K/1kA3gqIAg
q1A7h92jA5nQEQZlrGDl3WrVVfypWsEJqvOIAmUQsDkYVvnqwNAuTpC3ZSWc
2EI1wWq1TK1cnudpmt/g8auuipgY4TLPkD+Bwftr0hIO4QmQgTCJ07fkp9fI
fl6T3iDfnLGdol/2ugYAupyhZBWE4dfAfGFRS4QWxSepyiSTEDpvJtYQ4HWQ
qowMYY6ksg3QwUKKEb7GDAuYF7LbJAWWF13nyYzXyyKZJzJoVqVWwLAcwIPD
IMBjPgQgdQFXH9oWVv6w9SDS74eeYbA9Ymx44+AuWz3NY6p2TiQvgEFIhdVR
Z7NN8yHNE89YLsgSEA0CoA8zwIW/DFnNs+CEG0YQZT4sAMIMMAJDr9CWnoA+
irqfg4KmvgTVMvNnDofFycWCrc8PBIeU66lYZdygRXO5itDFFsdi38Z0hKY5
qM5TFLpI46TRICJFevHew492NaW/zyJOjDmczRI2BFiBaoOpnYbV7+JvqWh7
ONUinoJVnZQLRGIdGlZBSH7DLKwPB6LdkjWzgpjWBgPFn2A7BMsvVwDz8K9w
ChCggEYB4/O/Zhmi+cEDPqwrR0rm84MMPg5XRfKFVAar1M/zFa0KkFyRggLT
X0cpSv2MNQFyKakq8BCHeWiHlZOJRGn6YIDiCH3AMdtE8hD8iXw1ZuT1fbhE
ciI0SPgNntS6DwN/3TxASH4DMJgqtXF5MT/GRW62dsBghJc9XOugpCQGGCO8
i2qKGg3scaVEEr5Wrmgv/Q2s1EzH32dWWwEsgskDVAIMjzeqlaWAPpt5v9AZ
XQc+Tt6wG/QNEntkDhJyzYaPpm7KKOZJLkTTJAUYxQd1ieZqFokjRZxmkRja
jmmiNtjOL5EA2T9sIbZQ8pkXvoCrkzOE9FGQFt+0T6Ks/UgCetFtCtv6Lr4E
iyxF1g/Ps6YLYhZ0qxVKndoYA9k1cpVEiA12McBjZGdPQSFAxyTLZznCbI1b
ZXbghitJwQvJonVrD+xRGsC/gjpxKw3UMgTWB+jeQZTt/ve93eF4dItgVbFP
JmWexh4bUt0lYEFuEKIhOnpW/tTlVUbSgelmZAKqXERreBmM9sUqrRJUMeww
rSsfGNgIKzq6l0J67ST27T2iYMvK7ato95FzmBzn/YcA50NzZs3KdjD6jnoT
526cW/3wUlwnLAo6VlIiM95sPjsdMOgEztGwQ1kAuaQ2LDlTnCLTBYZvB5Kg
QMqc1l9VXQKAzhdx4LlEkgVJAyc6QZmKGmZxLcjwPIOqcs5X5D8AogLEnwAX
88DirS9DBoT+ooJ1L3bGohUCZiGazgAP7irYfqZIyo907oA1Vhy/EDDJeFS1
GegUQFokVeUseg6AyKm5VfuBLZs6+e7p/YD4N3TIySOO0ciCtcWoIq4brAgU
ddm+mNEnUjFa5NllST82X2DUDEIWZo1mUkkBP9OccIWCFFEl05DFS+TPnMgx
HLT80RYv12UVL9x4QhFsZpITEZVr59drdb+g35tx+LZIrhGG92XACRCfS/5p
CASwzSxq4GhGNuQDWOYR8AMHKLw44+8c5W87D85yVSzzEoWRNZCRa5FwbJeO
5h1ODTLyDOnZF4qCKVo5unmtAywuiVvdUHAI9Ns4BVlRMct0iEbM1M0OUEOQ
9BcoyVkzTAqQHJNhMC9Kn8gRkbNihDzajy8eWTxF9eFYw54nRVmhezGWPxXR
UZnwjqEzCcHyHNsSqqAj4aDonJ5FYBZqFuTgtO7CGQWsylwPBDAGwW4+IYgK
ij3N4grOlzzEofNuvkVQe1OSt86x+1FN/fG2ngUjW1GxCms42StydXfMVpMj
JCdB4ntyxBA380zMDgvWSi+GQzwakzg04MR+AnQ0d7ZmXIBItbvkc2Z1HyHu
kUBvyibexZnMahWv8K4llDVJGsBGxk0ugSt0nyZziqVVNLJyuCbts2qyxCA5
auCsEhI8bDj4O8R4g0dU+bsFHgqqlEuSbsJdXqQwNGl4FDgZcmzDvAMpQnMF
GqONrYC9R36V0gS+No5B7j/e2/3yZQRPC/G6MZyaHAK2ZTXHzE2iBshbVmWB
xSWeXhXZMO8SzILkE588nhB9DhZC9A1Y8UNUKi/gmfEcO8wpm6QNb/mwNgV1
22EK1VayBpDjdJ4Cp6KqQSyhpNp5bFC0vEb++i6ASiE8My/yhXlxevzOQw+O
cpN7zm44IEiB49EtrKahBYcyg+y7Ak1z9gEuyji9Rv3ETjvqHh/FCmwE0STx
/r1dMxEGnMbZZXWFchoJaKa+Ff9UqXflNnRwAoALpMDwNxg+sHwfQQUiksfV
HCBHfZn8CGyK6YK4JsWZ8bddNv/YF+YzNfiNATevaSWsp8Egz8EWec3+kjSO
UCAh48JAFKZC8arVydhNPgoeQrzDnD7+FC08D6XEiW9DCUI9B1u7tpNbhwNz
NDAveGnHcgTF5Yn+zZ/MG/8g/8SqhNmaxdNt9+kq/rRt7MdXjIytI1gfPNT7
6WCI/xn5Tz4OD1o+0ceDn3hac2hfMc+e7D/df2pGI/zr2ZOv4KudTycnOzs7
+B39+eQlfPmEsSqvyThHwTjPnjzWcZ6NdZynbpynOM5+2zgvwnGe7dpx9nSc
Z24cGnyM45jaOMe1cfbt27v4lz81vPP5wDyooskwSoqhbnyUAiU976fxvOob
SlN83u/W/ERkEos+4RH6X3q970W2l77ngLTudkvc3Fxh0guGxQJK3v2KIQYT
HxinbsskTnO2YwJRcIiJI5RRga7Ee0/1tDHV086pjpwn6j5z7I15DuRwuqcd
M7xAU8j/4pidAw27O3DFkROJMm4ix0FgyqFwkR1R5VFJaBgH5nPTOIC9PLSc
pJbZ4QX2mRORsyBYhbMRO9xiN+LxcvqB9WDJE4fst6rWZgs9C9vqrW3zdJnr
JHLJe31MKw1+d+4GSRRZxFFWOtFvXf1k/WImUIFhdvFdRuKqvl2XBsBWC14w
OWR8D45vR3KmWA4nZu1U4bvhVgUvhlmW1vmI7it2tqEpQhJJ8ifi2aDmByis
mcUqBs1J8j2ySReBW4ZcbCmlH6kqvLolbZmdrLg7rHTS+LLNDZpjkp2sPQOp
0+GvXmPrYvhFfT66mAaIcBBPMzrqmGKkiQOZsbl/snpr9HteHBeE7zywqD+l
sfPtkExmIrKBgICIXAaQv4vtoN/hk2uygHaq851z5B3BzJb0LoudfP1lN3AS
mED43EQZoDfhRCrKcWGVkNz/oVVRMs1udGqYysQ9UrLvTdItGcYwd5aIizJ7
orTudyn562G7PwuZ+Q3HEgJUfA78X8hUQ8+uHyOjqBR7g0F+lEEsI5MIWYax
6LoXHdTiRnwza/i18SmRIQFrUn5KuWQNIUNU6UXd/WgnGRAtg4nMn5DV7DnL
XHD8Fg87J9J4OQeMEn8Wyw/w0Pl2P87oHziEGAPPiLj5ivIlLcf94IeZ0E8p
gbltkZS3BPlwWzHKB9v5JrMaczS7BlFP2TOew1fCUCaaYGBnze6mMgEWUQKz
4EPOVFBxIMcPRkrw1hE8kchqaUOX5EWRhzhSBofrJTmORanTlB7Yw2mckF8Z
B0OPmjeRsjI0pNR1GWlegHoEMfNBXStiPtnJ88x5dBwd8xuoIEg+mEIDUH4L
0MLXlEDnYUHTm3hlGfmtaUDL/aZoSACI9CJRZqFqBkc26XE+cX10G/IXbvg+
ylKlDHGnWwIZcHI+jytO8yZ0zWwwl7ZyC+H0zdbLf3n9etueg0ZaS0cc3Kd+
G5cl3tYqMN0jzClsnJjSZVoD9LX1sOxjVkkZXSSxEHgl6I6ktCZekA44Cbl0
+fShs0MPC1vpnBJN9Ot8cC5BCIFgbeamQBUTfaxgdN4Vod4emHh0ORqYi61n
T56ANTEY7+xsX+hyaGlshxPcbWqmGaMNUuMxxFBad4GnYaHQJlTEd66ChZSM
hsam0qlLmHZFwW6X8A3VqJ6jorbCf0NW6+cb9dotCI08ea6DVo6NodGU03z8
cO5dDLmhs2eWaNR5aafozBnxngkyFzggiqnl9HstNcedJXKFgt6QzOB0nKHr
0DJ5Td3jxK8FxlJmrHtILQjqM4CTsvmWuhPJ6aU8zEeF7MYrWFRKcNv3QQzh
UlPaPM4pad8dqwD5e8ISF9Dx6aX+t+1nPAe5RuRvwrnodAxAcrtAS85KsjUh
PPe3qAm/0Pb50KPzjBdAvLMU7SQURwyx1C8wWyNQ0LDxhLSXGhOZfgPRfdmB
rqAcbIMXlOvcBC9FyVroYaCLUFPEYQi4703bH9QUVk1K3QVTnNx4fzdeu+fm
4pbKJYWp/1skwSRe51wBwSpiRwUEpi+0/kRrI4GIhtbANz3kVEiwiWtEWLBc
kVVrA8CBTcKCwupO4WLYBW6kSI4flfKthoN/vsqmNkJWutodO6LENoDLR1MY
+/Tt9b7zWzf3DCMe42fjp7RnR/E0skU5sOY0mlIc3uUPsEurZi2ysNVqIPZO
W8agqdtEbnIWJuz8Vl936xYISyL3RblKKgpa20QWEsbLNOJsJCylRK7oYMi4
cAIhIT4XIrwe050WeVlacJxG2Q6YSNEwvREOXi29kQys1tzKujUk3vgOFcjy
EVc4lIlmgBRsf1fthGR3IgamJtwr2eh2kFpd2hSMZvZbI+0T7APW1onZ6nhl
CFagd1Pi87nkK79r1DQohbDlVq+W851STKV7z56Sk0+jMy6hzuZCS/KdVGXU
XJKR/DC0wgGRzMeu+Q5g8MBcAFQXrri27f1SuKSDgB2kMR6YqUY2qRzES2Yt
Y3g3DEA/vBhdPDRA3hg2RQsZtpadXn62oJ8aR3a+6FzKaUXrQqybszVg+xNo
L2inD0v6tM2rEe4imWuppM/aFPGDXu9vf/tbDwY9+PDbNk/V16MffuupaV+P
fhsS/9f0Plo2H7HCRhPX61nrUvfCjluXh845PNESCOBAI3kYYSID7GLnwmHJ
C26xi9dzLDyEJx9K7moy45Dg6S2pvPCkCigv/eWiff0XhEbes+8O/+RDcL+J
2hKI4QHWJ0DwjOIRo0d0g8h8aCgFsMWB7uXDb1EFwP4KgHUZClKXVFaAWLXt
ZmAaA3le7O8+23/2+Mnus6+Q/DULjbILkGKY6AmvrooLI8tqKclwXcUKnktC
KJFzjoGFfThcLtHU/mQOlXLV/pJE5m5SBx7skbooP0R3/E3NAhWVN3R+Oyo8
PHr9UpSar3b3sNKGR1E/XlIh45PqhSnyIXpDpkIaJr3l+PSb0/PQdEJlwS8s
5ONmokk271HThSIxz6nm5KCP0A4xbWmI3KbXCz7CU+j7Mf1R34QHsNejH2CU
X/XNI+NomEcJP8NjH9qoHMf9wXjn3H/Re+y50Z+9Z71vQ9D8x/WL/g5CqWbP
0A0XfAEPbv3nT3vj4d4z82vC63avx/h9buCHHfiBGM/nA8PyDJ3jwyCY6H2P
7Tme9xHrGC18AKqBVKta4rQ1lr3eS1Xd4qhIQUZXZhatidDreZGWlOpl0pyg
5TznNtEvSMYVQcwdG1x+OelYbD2IyDp9d/6SKrTDmu2wZNXLsldVQOsIi67x
JZGlr0XW/ZqHxP/N42t9bhMxYpioRjXi4lKqbSLBSI4Vtns8ocbnqc4iuMo1
QhZRFAlbAVhh67ncLQZqi2bfFbaX4Xrl4OcRfxd5NR9Ouc+ClhsYbUlTrVKo
76fPhICU/FAFe0Q9ja6iWKxXZsnm6gLLnkPnm6CBli873Sw3RZcp6bXuazVt
NQoQTH7fcl1mUipbmSeissK9QthLkpQ+UA3YqXiRypMPHct1zQhoDwAcJRbf
7s243g6+ZXPXvHf5yy+ozAfru7gmQh5kWO1BUsOvyjFExqTKFQhC4uIKsR5d
zYfxUubVtOdqI6V3P7c+9OW6jNcNanJUQmrsQpWWDvBQxQgz62XdzWTGBBb6
LezWNem9olnTk76Vij4SnpGcjWFkxWrx7dCMuHhSxPKAtOQDcTCO8X8Xze92
RY2uf793IbFGTFfS+a1nls8TKaVqObbjx9sEQgItKnSujmAbbIAEziKhZJqv
UlSkazNRbQ3ZOZ0Y8CuqlBn2ep8/n8nx2xvt4ly2y4Dxa9inXAiqRCAVVEpj
A2UfJUd4hfJsbQZWi8bilcVmLvpwjUurM1eHhwWPOClGIl714h8PFDmQNcPq
ds+oaWQziNoK+uSsyg5AmMcXZsuhaH+0O/pqNB6NA0RtC/HsjHZ8moGP8EVI
JyRkkY/UEMjbQ7/Q0Ts99neGp63tjtcmobZBkenLIH23BfaEsHTT1kmAtUhL
59pDG530pO4yHAN1YvJ8Mat082tNyt2nAAMZoMhvVB4I+0bMb2B9oQiErQ4u
FvjdweHoaPRCsxuVj+MTZ6xPCJCsY68VRM1hEerZCHAbArnYOhwcwcml7Qyt
Hjy9QMxXpEdtYBHZuu1W4TOQeusux6tIInWPRU1gOO0ISQPp3/OGNNy+jGUS
3lZuhY6+h6j2Yg8EdHk9bEkScuhlWdwGT+RRm9P45Atf8fPDBZHIeThbYG5L
9xXnaocjfoKkRJltcBA1AZ1inxLR5RlKM4d957oZB5vIq/sANkGbtAQNcMZ7
p0GPXq9JD8FSVBVJfG5Oxo6v6Vqxj60FJUksn8+V+P2lByKvDeP+7B6p1ZRG
4EIrSiRjpxawn120LPVbwQgH/xRIDzir+7bQ1UTIU4pPZSgE7YbEHCkQJDyY
QqkwY5bfoEIVR4sgNnE3fldeHzrqZ+UfZFHEZwkWZ+eY++JqK49fnwVFdVRV
GbjPdJtm6yxaoJ8thr1DMsAS1PVAGQ+uTOQhuyJ0YXNbpknu+TAN4e7Ni2Yw
TZV4LI4AUAY3Y7IuY+pkCUbcZY6p21IoY7d1nzzqtVCNY11Hck6Y4iXG4dQ0
YjNOb5YAykaapdL0jZP0LeEGJfFNy7MkHx7FGlaa0KHXqlXxYYk3lmp5kBvy
pnhgwAYu7cRA8N0+9hZlooXrtWD27+Z7HArocPwb8kSG0Q+bRCmaJNfV6fHH
orIbkpl3hzowrcVvI4R5IMnlisv1qJqzXBU2Hy+hdB6p8JQAL/vic3WLygvS
I8GNJ3UgbYT5d/DQgJKjTMqt29bLdiRxsUaASWM5pQXbVjU0eHDb/v+juPDA
AS3rbiz5rsARs4PvY1CYP2YYdamFkDTfbEqtjaiyY85KyhNnEokKeu3V3ofO
D+7viFkjs3yp7pBJXcfCeF08jC4LdEHJcW+2TMhVlaW0XhD3RRRSEdkoy2VK
Gb7E4i2g4tjFbr7JhKv5NCV5EjejRjddaGlteKWlrs3kL9uAJ5NFaCdB/3f/
RX2O0HyTYKOkHBCVrejMMZwxJ2ZQRC1cv+jDftE1dn9k+8rlHtRieOh1uist
tptOLFXcr3DdwzCttTZqV/LOBnA0MngajV6EnVtw4WBTay7KRvSyaQHMtkk8
0JW+JKaXlnlLwXrplwVR1KLupOV0GGYfXL6OtcXhqVWzHmO74YEeqqVZSpDB
xmBrh6xOynOXA+HST/3mXxw1aofD9xk1A/ldjgdY2uv2dKKyySwbnSG6IYl8
fdFrC8FuhgfmxdGbd7cFfjzfesMlENrmNlpt9QDP79h0nBJFOlkmHYOptVxH
DFcRG/pYNbWeAKXVSIbLs/1nWB96jpp0LKJYYNS2YZ4fVitMeWtpnPa2zMBH
ixxLMykhTeQxOy2bcWCBuA3JOLcru2iLDtNbpUaHp5O8GCpIXowNpSk9eSK/
9XrfSGNDHEvB5W4zdknOL0m9ELDRYLoWpu9VLIqpAmtYg3QkzdJPPoM34a+U
8vFcn8rW/pteo17pF9HZcRuDCQtQ1q99l4RtAKZNGGs2DAUnomUy87wW0hA4
cw217bK19VgpbsYldVzALjroNoVlRRynQRvaa0Ia4u3WdAKvXkSKlIMg58CT
fjxaZ7LBLOZmw8Vv8PziXgvtUnoOPA9sLeForo4nUr3mGMQOB0URrYNmxKQv
Neki7K5J7YJvO5f1eO2kBTtEpQQAxeMSTge8AT67u83yH3tIbe1tm5gV91Lq
++WjzZqnIXQaPf9+wRvN1ChmEBkQNDL3MpU0GH6TD3VCtpgAKvuNa4bKmbZa
li5JHlx/EkbXnQ4TvmwTRIJw+pE96kE4/YE5B7hOBApmEENtKGuPPkbWEXxC
yRebGe0vqb6B/ulwokFSPagauBX76vQOetVvZvjaNB3gqIiujuGVMSB/CwWi
bCT5Hi0EtjzZPN4fYrFrI3sr6DyX1bIIwPjjHBYcmaqkTVCMKcXhEoBRGVbP
CGnrWOGErYxO/Vw3HLw9A/PWWfxSDh+HgN9mBIjrRCVLH58IE905ZnGjNrN3
1C6wJPXp46d/3qH/Hu9fSBCUO3dT6NE/SLSrFx/qbw3Mzqed8Q8XzTmE06mu
5XZqDGoH7GFlma1kQT3dNR3/PTC79uRY1chKS3hgp/3VBwbMzCGCc2B2zRY2
a3dSahtf7JgTJjQ6oaK/69z1+JXxkQGEEHIUN+bWgiJ5b2fcNn2ttycneW3K
CGzSMWnljX7ZXJPkrg+ovVZTczV4VFN2zff2OguvY0pTXtsYAxwLzCINqgXI
ZRaUynBvvcjTrOR6C77d4nt1DdQr3+rFkRt6226BV5mczN14KITbtaCbksXJ
pRQodzbh+Cyg6jw/EFu/HNfv4kqDTXl6owMkQ5sUt7/WEAGBk+luRscMhrmT
sv8QR1YzufjgmOCAmFM7G+xkUc825VD35UwbcKS92gt79+ZEh5YTmfY+XvIg
cChvnttZ0y0saTM6lV5K7MCjpl7OSmm3XkmLldRyzJ31e7CFPQEp1abmLMYT
GRSUUn8l5lQWKI3IW8ebdXCAup5csuOMzETX0o3ZZ1KWK3SOfEC7T809n8Gi
Fuh/Ri3w+0BTd8fWpvpsHiYQ9t22mM1YQKM366mf1u4AQnsbnsVhPmyiwWIy
qdVgt9nR5w6tbL2agC1mdT3KkbSXBte3m/c2qjxDiDNuW+zs41jtbKRfnpxN
Ps/N2UHHpd9zX1IZpEetbutiklyuYMdHQd4UzUwPSd82dM2JPttOCo4dUUbh
yO4QGy1LxhZbpcXCXACIf46T2YVXHBV6QqR9AckJy7fpVfi67VUGd+bpppSt
Pjcy1QjIYmvbPH9u9nqfgWnIMCNLp3/2klcPnutrH3Z++I33NPq1/iyJp95D
4+Ahcfy1PLcLz33pxSl6FFog270nZObrr0Gf3wA+ePS/gOFL+ePbm4E6JlDv
mzi7LOPVLMcv+uZLW2a252YCbSJwM1FtDDnqbHpTI8fUtvl0jgSRjXJKj7jd
/ZvJXzBMVCsw2cLZt9nFwh67wV0J3zrucVRF3n0S5lWUXa4wNXjrxfHxq211
Az4e45VebYnc09ks7QFizXPzn/CfkcRA4e+h9RL0esFHzMGGzXJieIWZYPDN
2dnbAzzJvR96vd+Y0Wikye4uyq0vaSOJ8AY2UhPhvV6PgHlUn2jXzoK55WW5
3DWP9M89mNV+yy+irS3QGfMbswQ9HqaimeHX0PPPz7kx9mSMtixyftaMgCHb
6oPHCJqXU975TMe09yVp3DjMBX+dV4AY5MIX3uwXXv0tyQ9NA5X6nqa6oKlk
YAJs2EveNyBswHG34SVSj6ZNJrcdUl0gFFtIkTQJ22DrDRN1/436ye5WmSSV
amCnWshU1lcCCgm6rF3apnJsyiv07n7hm45G5rjFlaWNFzDNLojuItolrQyW
7ykChDCZG8GBNxz4tmLt/ip+i9MTJ05a8ehbQBc7n57ujo/qBvgOjClBunYn
oL67Nz7Ud8dP6T20NZPUXo7DPiiKWVP8nyBiljucRGgFwyZOP3JXQkKauKWV
UyjetVkZokxeRC2xSMpc0xNaXrf7MzSRly2qmoJitYlSihBpH4IX4viPvNt7
ap57r16Z4JqyCzW4z8o1Oa9X9NuYNKXreJcrir9a2sd6nrNoka9YQV1Voli3
5cy6mI0LnNkqA5uEbXVCVGHKK7L2KgwSw+blNuyhTfx9icSNXUWVzPVOtY5A
yMALklPXJwy3Yr0E3chQsxM4VbwtkQXzAriv1pWLJE01ZwQLX1usCpTv/ucv
bhc1TifNujSDlriWO0+N25GWNpRrPUWmxVPkV+/LTJc5og7fUn2RqKfUi/7q
MTQPyEQbfnj1NLhOuYRHski+BfUdjpnzlHx2N3yGuRgw3u7OeNyewhk0QkHf
EudLBd3eas3u/LZnfG8REi6/5zo0eP0HyXTbxDlXM4/Id1XmHbfaNVx0flw3
dNd5njnMcLYttOR7GjZN8MjVaspJwC6tIePu4HB2lNGXp7Fnd9YplujQu78V
geXEGErtzIazRneEoJseVQ5vKBmtDSY5IN6NJ+ExkFImH60jc6LIqZ9LSoEg
V5HeoFmjBTa+KAHFdvOhX2xbYEkhkxDmhuvebNUYhWw3hknBb1jEy8simgXQ
sEzBXBjOGuaQsl6yalNe8UpK5V+uCLrjVg1rSdrNsfe3YkjTf79bDjPDIzum
Zl6c1hhqr/cCPTuLVUnlXMjeJc2N8wHbtpVwpLtAfiAVnB1aQZK5y0DZ2yCd
/VpHphxMJZi6luKHnu1qzZELy7ujWh9cXCdkdGm2t81ZvQV6DL5HKeuFA5vd
JydBuEgJTI2d1TZ/VKegaedRkko8iHz86g7LM3d/ALnAEO1gWlqpmUVBBkFd
HNr8LXsvpF6OMOJLyTE9kaPfgnO6G+2wlg0mCXdy/xGF/6hCodFfkejE4qtN
e9TLx6zHkZVbVzgxqScQU9MZ7tusRvWB5F1ZD7NtpMFwzXhj8OhhwCKEkcZT
dYnqXNsJAi8QNGewgCnlCElWECwkWpagi1TayKyIJ+uQYPDEcFYXNZ6ltmyV
dJhrPyycKRIQdQexYaLsKstiKt+MOKsX089Ik5I8Klmb3xLjljFDZJJe+KPt
mOWl62IFh6b9kpb5kHgdmyU8PgEWokhzgXykUSpn+9b9JZdbuDK3L3Y9uHGg
AGBsWr5DOejI2MelnKBYFSWYYRHQ+LfxqsAJpnSjAxpWNfOWz7HFvDi0pXMd
Nu3Tr23G2GRN1ldiO63CfPnCETVgmiUKAriEnUtEfCkEcacV6xupzUPtsr8J
PO6OZY+ATexVwEvbXJbKW5ZB3ptf0lACla7IAAKydIUYfo2mbQqJwzUbMt3G
CwbBamun1Lazu82axKTZis7pOdaSyNd6FkmQcOkTtaAnoj0IRISXgucVcSUL
9L9NYA0fKZNxseCaJUlXQU6UeDET0a7D94QM9fgVMTbSo0VLASY+pZdpK70s
o3WaRzMZAm1bKwl1MvJ0aFvKyls1pyuCHpJFIHiat/8pjfK8kt9LlSe8f0HG
uBYaaOK4vOUqDpx9zj/h3ZQfZRkLhzEpKMUsrpqiEZhZrqPFHV015Oy0qJna
USe4/lqDGtN76zBkquRpohdUWDpGGIvbgaRrxr0r4e9WSr1DXest6icGPHYp
AfvOJFO+xzFfrt05RUsQu0qLVBanSn80GvEltnLBOr30/vzl8Kn1Q2eu3JG1
TGqaGnYaPTs5O/vz6evTc9tqtE/xLGIcdFW8egg9/4eIRmx+o9zHM/n37Omu
ZZKitRa81NZvh6X+nYjmLkP0npTS1son/gibgeM9bpJn0nGTuqwhSAPk7L8r
9pO0uVfQKg6u73YZ7jaF8NrCIiiqA7uFVZ42Bd0CZ201saGowoVHsG2f8aaL
Ih6yv5KIPUzrw5FZHdWkR6euIWx3U3QjA1vTIh+7WFjrFsklMLX2R9JCHW/b
bj+AIxKt4oSaUElXPLPW2mOtp/Pqn8PyTVFKkjT12AZ7BrWklUo8tXxVancR
wUdJxtFNX7CAuu9oxJu1n9JlKPxKX7JJKEKomiRFjqXXnSZEdvQzIbZR5qnt
OEzXsThcXuXL4WQ9hH+oxLRieUF3JLANq1qU0BDocvSwgFdLyiVVx95Pw4nM
tvJ/HumdWDbZdwkqIxA3Xjkp6JXtoaToqCjWtuceJgEYvoqP//Z96YS9wupU
Wl/nuhBiQ0W6aZRtHsnQcWE37jWbzdRf6qo2Fvm1VtXEmm6P8LoGtYRSOxWe
kctYL4Lq3lblM9TkUV2A9fRuiezrfZ1BNrCcHHZ0slueMMbWssMNYJjtMaxs
FigHATq8uz1l8+DxR4XcIyW4bdxOg4or67+2v4pV2PmyCdtBv3nNZesNiUAt
rjM20M3HYRqtHVByGau6dLFuxNQTz7o6LnM1LpVioYHQGBs7ZOg95Dimc6gH
TYapgkqLjMILtvyV8B304qY0f0GlItNf9J5H14NHa3c5MKDqVDMy4BVW+NLF
KmA1WUpYvCtpkHZqOiWPv66L9Mkyue2ejfaIwI3NP7QJ7swD38VpokePWvAh
pGUFEnxNFTpWxAdh8bbu1JZzNLqf2puEjfiYq2Th6nOD3u5i7qk3gX6gXP+w
MA+7Fnmw4EUJKKu9mYUV16WuRvZAVXD+cA3p0bUcKz9VXUchhf7UKs38uUJb
1kaVmKk/LENDIiiIgtE2qvgcBGZi/QZK3rfvImS1+ap0ed6wlF6v/XuWO+gK
QN4jyXHSuo+LLWaqoC3sACU7T24htkHtaDUvuC79Nh5u7JaL0anDiDIpLZ9i
3uAV9ebN3jO2WdUsWoAyazcN23Nd4zWE0itJhqB7VVLqEIGOIQpHoAk/TblP
7jzC3Ji2hgc202qCDbjIkrZ81qPZqAouqpAWFL6NSrlJVP/H2vYWN7+axdK2
IE2dMavDSvJty7iurpzl8zWSNvdZwXutKctWTzf5LsnsYxUpOFaJLamm3GT1
I3hq8tFboNcaqeKw5y/evnh1vc+85fzVmTXkbLeBo2j6EcsTfZuXxbCSHygP
JN6u7YXAZI01o2HxfM4+PSAiqhTKLL9lp4zVI9DvgC4lrpmNiyJn/jhpAcbr
5kJL6miPgJvm+ro0+7ngq/7VtPXbaL14FFc9RHyrsLa3qjw1yJbs+8oeVvuf
umqi9dJvDWgvMJKuAVjlFV3y/X3UeZrUUS52T7wLMtaucabXo9NyoPZ7mlEh
x+u5SFNNZ6UydGwejuqkpCdEEzrMVHfqeAvTsWuR7PvsNCXCSx9XHyKpCDcw
HXLBM6whbPYDCTYFM3ziZFY2d8Z/3tsi7405qabqrLN37mAttXonAbmYOCmr
lpbptGLtxowKO10x6dQ+17HH+Rz09keKjgR1o34qj0hKKX6z3eeZNejt1NiR
JM1LiSuUbRDokSBlDZVgJwXL2Lpq0BMKOzaiy+s8A8Y1Sa2za+sBLyKMagHO
o3QN6sRv5Gao+vdy1WMKyCAn0Az182JgXYDOIKTmA2umI9Kq5CuQwKACi8Ko
fbZDVzIwFl9dMGQuKnNTztVgWGcS8gF2XgG7kPyPUs2dtX/qhDFJTiGhLfmx
nSUtkrLZ5TCiUeiEXK0WESlqBamcVIQfqpvmMxWzSyqDS8oQ/RO1jSpKUqLc
GO9Ign3ha8xEhwyqUW9y/46pJC6dWka2lKuZsP5877o1Gld0FZiLicCmVMSc
H0vZwsLfuIw/TGvov88SOjrvtNu350/YAsxsS26H38mSxvP8Jl3AgCovDKS5
SLC+qAwmjCu6p9hIvjeMttu7hyggqHteyCbb3H4h25eO1XJbMwkb2JGIZ2C8
qdnNoRWGvi1t8zo1LHOg+7VTRt31YRIfjrH/clD6b69dQH2WLjXlazHhX3/k
tzyyvbD0wF5OSjd37oxGfP0GvHeCGTDoi75O4psBVlh3XfdYMielAT6NMb8N
h9mTSzzqQ8lz+5wJR48+qT2qeTcoOfjpp97TL93T78RxMDAv+d4keB3dNrBS
fO/r59RE23vQu2sUZU/rhg8B3a23jzZ2lNVu3JFb6cvbVKB0TC7lyuOML5oL
99hVYJbBPfP3vbl7ZLw2j46A8FPjQm1nXrr8g/7raBH36ez232rDhxfoC58C
RuBh0EI06wOTpabWiUjX13tjhhdxSs8wvZtAGAGyPVso512YVZqhcHbi5Hju
bK9LfNeV2/bfKf8T6FSd8TgD5vS6CMC//ev/uJOo/+1f/6dJNfcbc6lbDlPj
mGrwX8INA7//lf404/YkvCHhPSFhqX/7VfZ1X2PXXenAH69AIlJXfNPKxrJc
8/xCWrmdE9mkKgqeaC5ore0MabrEi5CWbr1YueNeZWM3Ff6uU6HyMPiP/zq4
9R8AY9MKJrygGLnOjvwVRg1+IkT2ftJ7hi2n9S9wfvpsf695gTNzrbHUZHcM
fDeDAnSXm3GoLreVv219UW/6wXr6wVX1Gm5JsuAqNAXdpS+UPMRUO+Q+MN+s
khnl51EnfLmPFfPASSiArne8sipLmKIThreoRVhYdi/9PHHgW9gjh5hu5Z+g
1knVmVTGoI2gYb6wIpBuBwQVTZMr1PMi+Z3Rx7j0huu4Hz7n/g6J9HXzxrul
jPDuGK27u/a2e9JrbeTcBUnYxItSn/VmJfLvzTSTxJQ3EYmPublKLq/StbcE
22ukEgVvGWfsxhB/uo5NmBJ9EqyEQQtFcMOSqgBzl7uK5gugsRmzqzmoyWkS
FZh3g/HzMk6v49Llo25AM1Zf4iY+7QrjhvfVqeZYu1W1ldNKvISE1S13xHa2
dLI9kfiqaz0zP/82XWHiv6jqGSadbqiIihbKup6vralA6ew4Ta+MVd1EIeE5
HZyi6amNJx36aItWSdM3GwuXTU9UqGyecoPamq7pk8jmKuZmdNjUMA/LdnFP
mrpHid7NxNTNNzTMwnRP18Dw7+oQp2emeVfWL2Nn3atr3v9F8yuketNK9x3N
14ACu7rR2SMx3n3Sch7Gu09Ho92vvoKfzioMvGNRxSHzGD4IO2NnlLUeqKfe
gcJhgnKHd+rDq1mD3vGqj9hipeH65Sbc2LPo/ONUo57NT9Q9SLV5rO6j9P6R
NICfUMJpTXSo0fpUMOR/lAOe/+zND/O6agpmjzXSE6uQnrDNHeqx9ZduQ/vm
qugmeP9/SzEN+1WShVRZRYTbV0rOSVvv1HrbyoGfcp7GriItuo6SlCO2GVmt
K5d0imyukHgw6kF4qSHwoSsiILoIgXU6LjgpPgpG/CPmrlCM2Otv83G5sgiT
ASwEYe2StCDDZ7F3IrojaA1z6pZjdS7NFcEogd+ilvQ4LRUhK9Vr4erS6w01
3hvavqiNW7+dGxIYC9UChQdjsipAyeX+rLVcUgpgtrlZAFg8dBidQt9vrWy9
LQvTXmz2ObyS7EstJ8HWKZKDQxNFXFomWdlJ0ZHCKZfdWDdMQ/73euqiDlIP
/FrHWsfRXYw3BtdG/+ymRNSPQ7VGp5eXlOfrrplrq4KWq4JsakxUij/dv2lw
PNp13VsyTPLeZFB2sLiMqK6EucEds++M7Px2DzoyJe+/C3t37IID2N7TjUgY
7/8SeNXC29GeXR4O7mvVPF23ol27CiYKEbdjxz1s3gx9f2Q9ad7x/I8ku1+N
nnhkJ/G/8eNfYmh3i6LO0eQ2QYdVn88EvRo34zOB/WtDyNRG9mdwFlu5PcaC
bVYMulPPvVYx3oU3ta0d/8O50RxlAjfJCjujAfBhG5uNWtZ176/tubVhq61N
e/79jBZ/O+OuNlnd3bHK5NOGaNqs8vWfiqi9n9mBbGcH3mqS/s/D4s+QEo1e
CHSw/iknq0PC+EdnvPPPpoh/H+3qwnZ0P7dd3Xjvn8u2Gv/9f9nMlE7nL9nM
VJQjvQbPXuznf+n1iaE76ST/yutQVV3VWgAj+jcWVXamZu+1f0dCa6f9sOz8
DKF1G8L+w4ive+ITNNHDKfom0nh2SfUVvc8H7NiJZ8/7lJzbb+Q+HZ+//v4b
seSTZcTX9ICNnYD5ja4RqjGmZjwgeIokSgfk0KDsW7l5Hss78Qn3bMGueOty
bbTLOABlOa8qc7Qq0ji5vNJdB+R+8+7N+7cD818xTZOfGpgjmDgzZ8kyt1mt
f8ivstJ8my8/YsuU93yHFWaKHfLlNebt1bpMpqV5FYHaHfGVZX/IMfB1uIA9
yKkS6g8v/oh7NsXwFDzMC3qHxREVjksGfFhMSgH+VXWVU7ixvGLXTpR9tDd4
arjzxdnxmTk7PRsCig2mYCK6L4t8tcS4Gsfgbq5ylzEPeJ2vLPK4omBBbq9i
zRaU78ijxGfM4Ke0Oq+vCLGqlUZeJf0T7atlNCUHbJrrhVH/BwIcdC4zwAAA
</rfc> </rfc>
 End of changes. 202 change blocks. 
1452 lines changed or deleted 1264 lines changed or added

This html diff was produced by rfcdiff 1.48.