<?xml version='1.0' encoding='utf-8'?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" ipr="trust200902" docName="draft-ietf-dtn-ipn-update-14" number="9758" category="std" consensus="true" submissionType="IETF" updates="6260, 7116, 9171" obsoletes="" tocInclude="true" sortRefs="true" symRefs="true" xml:lang="en" prepTime="2025-05-23T14:42:11" indexInclude="true" scripts="Common,Latin" tocDepth="3">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-dtn-ipn-update-14" rel="prev"/>
  <link href="https://dx.doi.org/10.17487/rfc9758" rel="alternate"/>
  <link href="urn:issn:2070-1721" rel="alternate"/>
  <front>
    <title abbrev="ipn Update">Updates to the 'ipn' URI Scheme</title>
    <seriesInfo name="RFC" value="9758" stream="IETF"/>
    <author fullname="Rick Taylor">
      <organization showOnFrontPage="true">Aalyria Technologies</organization>
      <address>
        <email>rtaylor@aalyria.com</email>
      </address>
    </author>
    <author initials="E." surname="Birrane, III" fullname="Edward J. Birrane, III">
      <organization abbrev="JHU/APL" showOnFrontPage="true">The Johns Hopkins University Applied Physics Laboratory</organization>
      <address>
        <email>Edward.Birrane@jhuapl.edu</email>
      </address>
    </author>
    <date month="05" year="2025"/>
    <area>INT</area>
    <workgroup>dtn</workgroup>
    <keyword>DTN</keyword>
    <keyword>ipn</keyword>
    <keyword>BPv7</keyword>
    <keyword>CBHE</keyword>
    <keyword>Bundle Protocol</keyword>
    <abstract pn="section-abstract">
      <t indent="0" pn="section-abstract-1">This document updates the specification of the 'ipn' URI scheme
      previously defined in RFC 6260 and the IANA registries established in RFC
      7116. It also updates the rules for the encoding and decoding of these URIs when
      used as an Endpoint Identifier (EID) in the Bundle Protocol version 7 (BPv7)
      as defined in RFC 9171. These updates clarify the structure and behavior
      of the 'ipn' URI scheme, define new encodings of 'ipn' scheme URIs, and
      establish the registries necessary to manage this scheme.</t>
    </abstract>
    <boilerplate>
      <section anchor="status-of-memo" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.1">
        <name slugifiedName="name-status-of-this-memo">Status of This Memo</name>
        <t indent="0" pn="section-boilerplate.1-1">
            This is an Internet Standards Track document.
        </t>
        <t indent="0" pn="section-boilerplate.1-2">
            This document is a product of the Internet Engineering Task Force
            (IETF).  It represents the consensus of the IETF community.  It has
            received public review and has been approved for publication by
            the Internet Engineering Steering Group (IESG).  Further
            information on Internet Standards is available in Section 2 of 
            RFC 7841.
        </t>
        <t indent="0" pn="section-boilerplate.1-3">
            Information about the current status of this document, any
            errata, and how to provide feedback on it may be obtained at
            <eref target="https://www.rfc-editor.org/info/rfc9758" brackets="none"/>.
        </t>
      </section>
      <section anchor="copyright" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.2">
        <name slugifiedName="name-copyright-notice">Copyright Notice</name>
        <t indent="0" pn="section-boilerplate.2-1">
            Copyright (c) 2025 IETF Trust and the persons identified as the
            document authors. All rights reserved.
        </t>
        <t indent="0" pn="section-boilerplate.2-2">
            This document is subject to BCP 78 and the IETF Trust's Legal
            Provisions Relating to IETF Documents
            (<eref target="https://trustee.ietf.org/license-info" brackets="none"/>) in effect on the date of
            publication of this document. Please review these documents
            carefully, as they describe your rights and restrictions with
            respect to this document. Code Components extracted from this
            document must include Revised BSD License text as described in
            Section 4.e of the Trust Legal Provisions and are provided without
            warranty as described in the Revised BSD License.
        </t>
      </section>
    </boilerplate>
    <toc>
      <section anchor="toc" numbered="false" removeInRFC="false" toc="exclude" pn="section-toc.1">
        <name slugifiedName="name-table-of-contents">Table of Contents</name>
        <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1">
          <li pn="section-toc.1-1.1">
            <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.1"><xref derivedContent="1" format="counter" sectionFormat="of" target="section-1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-introduction">Introduction</xref></t>
          </li>
          <li pn="section-toc.1-1.2">
            <t indent="0" keepWithNext="true" pn="section-toc.1-1.2.1"><xref derivedContent="2" format="counter" sectionFormat="of" target="section-2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-conventions-and-definitions">Conventions and Definitions</xref></t>
          </li>
          <li pn="section-toc.1-1.3">
            <t indent="0" pn="section-toc.1-1.3.1"><xref derivedContent="3" format="counter" sectionFormat="of" target="section-3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-core-concepts">Core Concepts</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.3.2">
              <li pn="section-toc.1-1.3.2.1">
                <t indent="0" keepWithNext="true" pn="section-toc.1-1.3.2.1.1"><xref derivedContent="3.1" format="counter" sectionFormat="of" target="section-3.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-the-null-ipn-uri">The Null ipn URI</xref></t>
              </li>
              <li pn="section-toc.1-1.3.2.2">
                <t indent="0" pn="section-toc.1-1.3.2.2.1"><xref derivedContent="3.2" format="counter" sectionFormat="of" target="section-3.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-allocator-identifiers">Allocator Identifiers</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.3.2.2.2">
                  <li pn="section-toc.1-1.3.2.2.2.1">
                    <t indent="0" pn="section-toc.1-1.3.2.2.2.1.1"><xref derivedContent="3.2.1" format="counter" sectionFormat="of" target="section-3.2.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-allocator-identifier-ranges">Allocator Identifier Ranges</xref></t>
                  </li>
                  <li pn="section-toc.1-1.3.2.2.2.2">
                    <t indent="0" pn="section-toc.1-1.3.2.2.2.2.1"><xref derivedContent="3.2.2" format="counter" sectionFormat="of" target="section-3.2.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-the-default-allocator">The Default Allocator</xref></t>
                  </li>
                </ul>
              </li>
              <li pn="section-toc.1-1.3.2.3">
                <t indent="0" pn="section-toc.1-1.3.2.3.1"><xref derivedContent="3.3" format="counter" sectionFormat="of" target="section-3.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-node-numbers">Node Numbers</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.3.2.3.2">
                  <li pn="section-toc.1-1.3.2.3.2.1">
                    <t indent="0" pn="section-toc.1-1.3.2.3.2.1.1"><xref derivedContent="3.3.1" format="counter" sectionFormat="of" target="section-3.3.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-fully-qualified-node-number">Fully Qualified Node Numbers</xref></t>
                  </li>
                </ul>
              </li>
              <li pn="section-toc.1-1.3.2.4">
                <t indent="0" pn="section-toc.1-1.3.2.4.1"><xref derivedContent="3.4" format="counter" sectionFormat="of" target="section-3.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-special-node-numbers">Special Node Numbers</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.3.2.4.2">
                  <li pn="section-toc.1-1.3.2.4.2.1">
                    <t indent="0" pn="section-toc.1-1.3.2.4.2.1.1"><xref derivedContent="3.4.1" format="counter" sectionFormat="of" target="section-3.4.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-the-zero-node-number">The Zero Node Number</xref></t>
                  </li>
                  <li pn="section-toc.1-1.3.2.4.2.2">
                    <t indent="0" pn="section-toc.1-1.3.2.4.2.2.1"><xref derivedContent="3.4.2" format="counter" sectionFormat="of" target="section-3.4.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-localnode-ipn-uris">LocalNode ipn URIs</xref></t>
                  </li>
                  <li pn="section-toc.1-1.3.2.4.2.3">
                    <t indent="0" pn="section-toc.1-1.3.2.4.2.3.1"><xref derivedContent="3.4.3" format="counter" sectionFormat="of" target="section-3.4.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-private-use-node-numbers">Private Use Node Numbers</xref></t>
                  </li>
                </ul>
              </li>
              <li pn="section-toc.1-1.3.2.5">
                <t indent="0" pn="section-toc.1-1.3.2.5.1"><xref derivedContent="3.5" format="counter" sectionFormat="of" target="section-3.5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-service-numbers">Service Numbers</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.4">
            <t indent="0" pn="section-toc.1-1.4.1"><xref derivedContent="4" format="counter" sectionFormat="of" target="section-4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-textual-representation-of-i">Textual Representation of ipn URIs</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.4.2">
              <li pn="section-toc.1-1.4.2.1">
                <t indent="0" pn="section-toc.1-1.4.2.1.1"><xref derivedContent="4.1" format="counter" sectionFormat="of" target="section-4.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-ipn-uri-scheme-text-syntax">'ipn' URI Scheme Text Syntax</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.5">
            <t indent="0" pn="section-toc.1-1.5.1"><xref derivedContent="5" format="counter" sectionFormat="of" target="section-5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-usage-of-ipn-uris-with-bpv7">Usage of ipn URIs with BPv7</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.5.2">
              <li pn="section-toc.1-1.5.2.1">
                <t indent="0" pn="section-toc.1-1.5.2.1.1"><xref derivedContent="5.1" format="counter" sectionFormat="of" target="section-5.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-uniqueness-constraints">Uniqueness Constraints</xref></t>
              </li>
              <li pn="section-toc.1-1.5.2.2">
                <t indent="0" pn="section-toc.1-1.5.2.2.1"><xref derivedContent="5.2" format="counter" sectionFormat="of" target="section-5.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-the-null-endpoint">The Null Endpoint</xref></t>
              </li>
              <li pn="section-toc.1-1.5.2.3">
                <t indent="0" pn="section-toc.1-1.5.2.3.1"><xref derivedContent="5.3" format="counter" sectionFormat="of" target="section-5.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-bpv7-node-id">BPv7 Node ID</xref></t>
              </li>
              <li pn="section-toc.1-1.5.2.4">
                <t indent="0" pn="section-toc.1-1.5.2.4.1"><xref derivedContent="5.4" format="counter" sectionFormat="of" target="section-5.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-localnode-ipn-eids">LocalNode ipn EIDs</xref></t>
              </li>
              <li pn="section-toc.1-1.5.2.5">
                <t indent="0" pn="section-toc.1-1.5.2.5.1"><xref derivedContent="5.5" format="counter" sectionFormat="of" target="section-5.5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-private-use-ipn-eids">Private Use ipn EIDs</xref></t>
              </li>
              <li pn="section-toc.1-1.5.2.6">
                <t indent="0" pn="section-toc.1-1.5.2.6.1"><xref derivedContent="5.6" format="counter" sectionFormat="of" target="section-5.6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-well-known-service-numbers">Well-Known Service Numbers</xref></t>
              </li>
              <li pn="section-toc.1-1.5.2.7">
                <t indent="0" pn="section-toc.1-1.5.2.7.1"><xref derivedContent="5.7" format="counter" sectionFormat="of" target="section-5.7"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-administrative-endpoints">Administrative Endpoints</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.6">
            <t indent="0" pn="section-toc.1-1.6.1"><xref derivedContent="6" format="counter" sectionFormat="of" target="section-6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-cbor-representation-of-ipn-">CBOR Representation of ipn URIs with BPv7</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.6.2">
              <li pn="section-toc.1-1.6.2.1">
                <t indent="0" pn="section-toc.1-1.6.2.1.1"><xref derivedContent="6.1" format="counter" sectionFormat="of" target="section-6.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-ipn-eid-cbor-encoding">ipn EID CBOR Encoding</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.6.2.1.2">
                  <li pn="section-toc.1-1.6.2.1.2.1">
                    <t indent="0" pn="section-toc.1-1.6.2.1.2.1.1"><xref derivedContent="6.1.1" format="counter" sectionFormat="of" target="section-6.1.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-two-element-scheme-specific">Two-Element Scheme-Specific Encoding</xref></t>
                  </li>
                  <li pn="section-toc.1-1.6.2.1.2.2">
                    <t indent="0" pn="section-toc.1-1.6.2.1.2.2.1"><xref derivedContent="6.1.2" format="counter" sectionFormat="of" target="section-6.1.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-three-element-scheme-specif">Three-Element Scheme-Specific Encoding</xref></t>
                  </li>
                </ul>
              </li>
              <li pn="section-toc.1-1.6.2.2">
                <t indent="0" pn="section-toc.1-1.6.2.2.1"><xref derivedContent="6.2" format="counter" sectionFormat="of" target="section-6.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-ipn-eid-cbor-decoding">ipn EID CBOR Decoding</xref></t>
              </li>
              <li pn="section-toc.1-1.6.2.3">
                <t indent="0" pn="section-toc.1-1.6.2.3.1"><xref derivedContent="6.3" format="counter" sectionFormat="of" target="section-6.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-ipn-uri-scheme-cbor-syntax">'ipn' URI Scheme CBOR Syntax</xref></t>
              </li>
              <li pn="section-toc.1-1.6.2.4">
                <t indent="0" pn="section-toc.1-1.6.2.4.1"><xref derivedContent="6.4" format="counter" sectionFormat="of" target="section-6.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-ipn-eid-matching">ipn EID Matching</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.7">
            <t indent="0" pn="section-toc.1-1.7.1"><xref derivedContent="7" format="counter" sectionFormat="of" target="section-7"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-special-considerations">Special Considerations</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.7.2">
              <li pn="section-toc.1-1.7.2.1">
                <t indent="0" pn="section-toc.1-1.7.2.1.1"><xref derivedContent="7.1" format="counter" sectionFormat="of" target="section-7.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-scheme-compatibility">Scheme Compatibility</xref></t>
              </li>
              <li pn="section-toc.1-1.7.2.2">
                <t indent="0" pn="section-toc.1-1.7.2.2.1"><xref derivedContent="7.2" format="counter" sectionFormat="of" target="section-7.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-cbor-representation-interop">CBOR Representation Interoperability</xref></t>
              </li>
              <li pn="section-toc.1-1.7.2.3">
                <t indent="0" pn="section-toc.1-1.7.2.3.1"><xref derivedContent="7.3" format="counter" sectionFormat="of" target="section-7.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-text-representation-compati">Text Representation Compatibility</xref></t>
              </li>
              <li pn="section-toc.1-1.7.2.4">
                <t indent="0" pn="section-toc.1-1.7.2.4.1"><xref derivedContent="7.4" format="counter" sectionFormat="of" target="section-7.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-bundle-protocol-version-6-c">Bundle Protocol Version 6 Compatibility</xref></t>
              </li>
              <li pn="section-toc.1-1.7.2.5">
                <t indent="0" pn="section-toc.1-1.7.2.5.1"><xref derivedContent="7.5" format="counter" sectionFormat="of" target="section-7.5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-late-binding">Late Binding</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.8">
            <t indent="0" pn="section-toc.1-1.8.1"><xref derivedContent="8" format="counter" sectionFormat="of" target="section-8"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-security-considerations">Security Considerations</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.8.2">
              <li pn="section-toc.1-1.8.2.1">
                <t indent="0" pn="section-toc.1-1.8.2.1.1"><xref derivedContent="8.1" format="counter" sectionFormat="of" target="section-8.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-reliability-and-consistency">Reliability and Consistency</xref></t>
              </li>
              <li pn="section-toc.1-1.8.2.2">
                <t indent="0" pn="section-toc.1-1.8.2.2.1"><xref derivedContent="8.2" format="counter" sectionFormat="of" target="section-8.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-malicious-construction">Malicious Construction</xref></t>
              </li>
              <li pn="section-toc.1-1.8.2.3">
                <t indent="0" pn="section-toc.1-1.8.2.3.1"><xref derivedContent="8.3" format="counter" sectionFormat="of" target="section-8.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-back-end-transcoding">Back-End Transcoding</xref></t>
              </li>
              <li pn="section-toc.1-1.8.2.4">
                <t indent="0" pn="section-toc.1-1.8.2.4.1"><xref derivedContent="8.4" format="counter" sectionFormat="of" target="section-8.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-local-and-private-use-ipn-e">Local and Private Use ipn EIDs</xref></t>
              </li>
              <li pn="section-toc.1-1.8.2.5">
                <t indent="0" pn="section-toc.1-1.8.2.5.1"><xref derivedContent="8.5" format="counter" sectionFormat="of" target="section-8.5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-sensitive-information">Sensitive Information</xref></t>
              </li>
              <li pn="section-toc.1-1.8.2.6">
                <t indent="0" pn="section-toc.1-1.8.2.6.1"><xref derivedContent="8.6" format="counter" sectionFormat="of" target="section-8.6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-semantic-attacks">Semantic Attacks</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.9">
            <t indent="0" pn="section-toc.1-1.9.1"><xref derivedContent="9" format="counter" sectionFormat="of" target="section-9"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-iana-considerations">IANA Considerations</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.9.2">
              <li pn="section-toc.1-1.9.2.1">
                <t indent="0" pn="section-toc.1-1.9.2.1.1"><xref derivedContent="9.1" format="counter" sectionFormat="of" target="section-9.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-ipn-scheme-uri-allocator-id">'ipn' Scheme URI Allocator Identifiers Registry</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.9.2.1.2">
                  <li pn="section-toc.1-1.9.2.1.2.1">
                    <t indent="0" pn="section-toc.1-1.9.2.1.2.1.1"><xref derivedContent="9.1.1" format="counter" sectionFormat="of" target="section-9.1.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-guidance-for-designated-exp">Guidance for Designated Experts</xref></t>
                  </li>
                </ul>
              </li>
              <li pn="section-toc.1-1.9.2.2">
                <t indent="0" pn="section-toc.1-1.9.2.2.1"><xref derivedContent="9.2" format="counter" sectionFormat="of" target="section-9.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-ipn-scheme-uri-default-allo">'ipn' Scheme URI Default Allocator Node Numbers Registry</xref></t>
              </li>
              <li pn="section-toc.1-1.9.2.3">
                <t indent="0" pn="section-toc.1-1.9.2.3.1"><xref derivedContent="9.3" format="counter" sectionFormat="of" target="section-9.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-ipn-scheme-uri-well-known-s">'ipn' Scheme URI Well-Known Service Numbers for BPv7 Registry</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.9.2.3.2">
                  <li pn="section-toc.1-1.9.2.3.2.1">
                    <t indent="0" pn="section-toc.1-1.9.2.3.2.1.1"><xref derivedContent="9.3.1" format="counter" sectionFormat="of" target="section-9.3.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-guidance-for-designated-expe">Guidance for Designated Experts</xref></t>
                  </li>
                </ul>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.10">
            <t indent="0" pn="section-toc.1-1.10.1"><xref derivedContent="10" format="counter" sectionFormat="of" target="section-10"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-references">References</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.10.2">
              <li pn="section-toc.1-1.10.2.1">
                <t indent="0" pn="section-toc.1-1.10.2.1.1"><xref derivedContent="10.1" format="counter" sectionFormat="of" target="section-10.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-normative-references">Normative References</xref></t>
              </li>
              <li pn="section-toc.1-1.10.2.2">
                <t indent="0" pn="section-toc.1-1.10.2.2.1"><xref derivedContent="10.2" format="counter" sectionFormat="of" target="section-10.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-informative-references">Informative References</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.11">
            <t indent="0" pn="section-toc.1-1.11.1"><xref derivedContent="Appendix A" format="default" sectionFormat="of" target="section-appendix.a"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-ipn-uri-scheme-text-represe">'ipn' URI Scheme Text Representation Examples</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.11.2">
              <li pn="section-toc.1-1.11.2.1">
                <t indent="0" pn="section-toc.1-1.11.2.1.1"><xref derivedContent="A.1" format="counter" sectionFormat="of" target="section-appendix.a.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-using-the-default-allocator">Using the Default Allocator</xref></t>
              </li>
              <li pn="section-toc.1-1.11.2.2">
                <t indent="0" pn="section-toc.1-1.11.2.2.1"><xref derivedContent="A.2" format="counter" sectionFormat="of" target="section-appendix.a.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-using-a-non-default-allocat">Using a Non-Default Allocator</xref></t>
              </li>
              <li pn="section-toc.1-1.11.2.3">
                <t indent="0" pn="section-toc.1-1.11.2.3.1"><xref derivedContent="A.3" format="counter" sectionFormat="of" target="section-appendix.a.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-the-null-ipn-uri-2">The Null ipn URI</xref></t>
              </li>
              <li pn="section-toc.1-1.11.2.4">
                <t indent="0" pn="section-toc.1-1.11.2.4.1"><xref derivedContent="A.4" format="counter" sectionFormat="of" target="section-appendix.a.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-the-localnode-ipn-uri">The LocalNode ipn URI</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.12">
            <t indent="0" pn="section-toc.1-1.12.1"><xref derivedContent="Appendix B" format="default" sectionFormat="of" target="section-appendix.b"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-ipn-uri-scheme-cbor-encodin">'ipn' URI Scheme CBOR Encoding Examples</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.12.2">
              <li pn="section-toc.1-1.12.2.1">
                <t indent="0" pn="section-toc.1-1.12.2.1.1"><xref derivedContent="B.1" format="counter" sectionFormat="of" target="section-appendix.b.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-using-the-default-allocator-2">Using the Default Allocator</xref></t>
              </li>
              <li pn="section-toc.1-1.12.2.2">
                <t indent="0" pn="section-toc.1-1.12.2.2.1"><xref derivedContent="B.2" format="counter" sectionFormat="of" target="section-appendix.b.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-using-a-non-default-allocato">Using a Non-Default Allocator</xref></t>
              </li>
              <li pn="section-toc.1-1.12.2.3">
                <t indent="0" pn="section-toc.1-1.12.2.3.1"><xref derivedContent="B.3" format="counter" sectionFormat="of" target="section-appendix.b.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-the-null-endpoint-2">The Null Endpoint</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.13">
            <t indent="0" pn="section-toc.1-1.13.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.c"/><xref derivedContent="" format="title" sectionFormat="of" target="name-acknowledgments">Acknowledgments</xref></t>
          </li>
          <li pn="section-toc.1-1.14">
            <t indent="0" pn="section-toc.1-1.14.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.d"/><xref derivedContent="" format="title" sectionFormat="of" target="name-authors-addresses">Authors' Addresses</xref></t>
          </li>
        </ul>
      </section>
    </toc>
  </front>
  <middle>
    <section anchor="introduction" numbered="true" removeInRFC="false" toc="include" pn="section-1">
      <name slugifiedName="name-introduction">Introduction</name>
      <t indent="0" pn="section-1-1">The 'ipn' URI scheme was originally defined in <xref target="RFC6260" format="default" sectionFormat="of" derivedContent="RFC6260"/>
      and <xref target="RFC7116" format="default" sectionFormat="of" derivedContent="RFC7116"/> as a way to identify network nodes and node
      services using concisely encoded integers that can be processed faster
      and with fewer resources than other verbose identifier schemes. The
      scheme was designed for use with the experimental Bundle Protocol
      version 6 (BPv6) <xref target="RFC5050" format="default" sectionFormat="of" derivedContent="RFC5050"/>, and "IPN" was defined as an
      acronym for the term "InterPlanetary Network" in reference to its
      intended use for deep-space networking. Since then, the efficiency
      benefits of integer identifiers make 'ipn' scheme URIs useful for any
      network operating with limited power, bandwidth, and/or compute
      budget. Therefore, the term "IPN" is now used as a non-acronymous
      name.</t>
      <t indent="0" pn="section-1-2">Similar to the experimental BPv6, the standardized Bundle Protocol
      version 7 (BPv7) <xref target="RFC9171" format="default" sectionFormat="of" derivedContent="RFC9171"/> codifies support for the use
      of the 'ipn' URI scheme for the specification of bundle Endpoint
      Identifiers (EIDs). The publication of BPv7 has resulted in operational
      deployments of BPv7 nodes for both terrestrial and non-terrestrial use
      cases. This includes BPv7 networks operating over the terrestrial
      Internet and BPv7 networks operating in self-contained environments
      behind a shared administrative domain. The growth in the number and
      scale of deployments of BPv7 has been accompanied by a growth in the
      usage of the 'ipn' URI scheme, which has highlighted areas to improve the
      structure, moderation, and management of this scheme.</t>
      <t indent="0" pn="section-1-3">By updating <xref target="RFC7116" format="default" sectionFormat="of" derivedContent="RFC7116"/> and <xref target="RFC9171" format="default" sectionFormat="of" derivedContent="RFC9171"/>,
      this document updates the specification of the 'ipn' URI scheme in a
      backwards-compatible way, in order to provide needed improvements both in the
      scheme itself and in its usage to specify EIDs with BPv7. Specifically,
      this document:</t>
      <ul bare="false" empty="false" indent="3" spacing="normal" pn="section-1-4">
        <li pn="section-1-4.1">introduces a hierarchical structure for the assignment of 'ipn' scheme URIs,</li>
        <li pn="section-1-4.2">clarifies the behavior and interpretation of 'ipn' scheme URIs,</li>
        <li pn="section-1-4.3">defines efficient encodings of 'ipn' scheme URIs, and</li>
        <li pn="section-1-4.4">updates/defines the registries associated with this scheme.</li>
      </ul>
      <t indent="0" pn="section-1-5">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 indent="0" pn="section-1-6">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 not
      include any topological information describing how to route messages to
      that resource.</t>
    </section>
    <section anchor="conventions-and-definitions" numbered="true" removeInRFC="false" toc="include" pn="section-2">
      <name slugifiedName="name-conventions-and-definitions">Conventions and Definitions</name>
      <t indent="0" pn="section-2-1">
    The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
    "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>",
    "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
    "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
    "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be
    interpreted as described in BCP 14 <xref target="RFC2119" format="default" sectionFormat="of" derivedContent="RFC2119"/> <xref target="RFC8174" format="default" sectionFormat="of" derivedContent="RFC8174"/> when, and only when, they appear in all capitals, as
    shown here.
      </t>
      <t indent="0" pn="section-2-2">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 anchor="core-concepts" numbered="true" removeInRFC="false" toc="include" pn="section-3">
      <name slugifiedName="name-core-concepts">Core Concepts</name>
      <t indent="0" pn="section-3-1">Every ipn URI, no matter whether it is expressed with a textual
      representation or a binary encoding, <bcp14>MUST</bcp14> be considered
      as a tuple of the following three components:</t>
      <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-3-2">
        <li pn="section-3-2.1">
          <t indent="0" pn="section-3-2.1.1">The Allocator Identifier</t>
        </li>
        <li pn="section-3-2.2">
          <t indent="0" pn="section-3-2.2.1">The Node Number</t>
        </li>
        <li pn="section-3-2.3">
          <t indent="0" pn="section-3-2.3.1">The Service Number</t>
        </li>
      </ul>
      <t indent="0" pn="section-3-3">The Allocator Identifier indicates the entity responsible for
      assigning Node Numbers to individual resource nodes, maintaining
      uniqueness whilst avoiding the need for a single registry for all
      assigned Node Numbers. See <xref target="allocator-identifiers" format="default" sectionFormat="of" derivedContent="Section 3.2"/>.</t>
      <t indent="0" pn="section-3-4">The Node Number is a shared identifier assigned to all ipn URIs for
      resources co-located on a single node. See <xref target="node-numbers" format="default" sectionFormat="of" derivedContent="Section 3.3"/>.</t>
      <t indent="0" pn="section-3-5">The Service Number is an identifier to distinguish between resources
      on a given node. See <xref target="service-numbers" format="default" sectionFormat="of" derivedContent="Section 3.5"/>.</t>
      <t indent="0" pn="section-3-6">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" format="default" sectionFormat="of" derivedContent="Section 3.3.1"/>.</t>
      <section anchor="null-uri" numbered="true" removeInRFC="false" toc="include" pn="section-3.1">
        <name slugifiedName="name-the-null-ipn-uri">The Null ipn URI</name>
        <t indent="0" pn="section-3.1-1">It has been found that there is value in defining a unique Null
        ipn URI to indicate "nowhere".  This ipn URI is termed the "Null ipn
        URI" and has all three components (the Allocator Identifier, Node Number,
        and Service Number) set to the value zero (0).  No resource identified
        by the Null ipn URI exists, and any destination identified by such a
        resource is therefore by definition unreachable.</t>
      </section>
      <section anchor="allocator-identifiers" numbered="true" removeInRFC="false" toc="include" pn="section-3.2">
        <name slugifiedName="name-allocator-identifiers">Allocator Identifiers</name>
        <t indent="0" pn="section-3.2-1">An Allocator is any organization that wishes to assign Node Numbers
        for use with the 'ipn' URI scheme and has the facilities and governance
        to manage a public registry of assigned Node Numbers. The
        authorization to assign these numbers is provided through the
        assignment of an Allocator Identifier by IANA.  Regardless of other
        attributes of an Allocator (such as a name, point of contact, or other
        identifying information), Allocators are identified by Allocator
        Identifiers: unique, unsigned integers in the range 0 to
        2<sup>32-1</sup>.</t>
        <t indent="0" pn="section-3.2-2">The Allocator Identifier <bcp14>MUST</bcp14> be the sole mechanism
        used to identify the Allocator that has assigned the Node Number in an
        ipn URI. An Allocator may have multiple assigned Allocator
        Identifiers, but a given Allocator Identifier <bcp14>MUST</bcp14> only
        be associated with a single Allocator.</t>
        <t indent="0" pn="section-3.2-3">A new IANA registry, "'ipn' Scheme URI Allocator Identifiers", is
        defined for the registration of Allocator Identifiers; see <xref target="iana-allocator-identifiers" format="default" sectionFormat="of" derivedContent="Section 9.1"/>.  Although the uniqueness of Allocator
        Identifiers is required to enforce the uniqueness of ipn URIs, some
        identifiers are explicitly reserved for experimentation or future
        use.</t>
        <t indent="0" pn="section-3.2-4">Each Allocator assigns Node Numbers according to its own policies,
        without risk of creating an identical ipn URI, as permitted by the
        rules in <xref target="node-numbers" format="default" sectionFormat="of" derivedContent="Section 3.3"/>.
	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 indent="0" pn="section-3.2-5">If a system does not require interoperable deployment of 'ipn' scheme
        URIs, then the Private Use Node
        Numbers range (<xref target="private-use" format="default" sectionFormat="of" derivedContent="Section 3.4.3"/>), reserved by the Default
	Allocator (<xref target="default-allocator" format="default" sectionFormat="of" derivedContent="Section 3.2.2"/>) for this purpose,
        is to be used.</t>
        <section anchor="allocator-identifier-ranges" numbered="true" removeInRFC="false" toc="include" pn="section-3.2.1">
          <name slugifiedName="name-allocator-identifier-ranges">Allocator Identifier Ranges</name>
          <t indent="0" pn="section-3.2.1-1">Some organizations with internal hierarchies may wish to delegate
          the allocation of Node Numbers to one or more of their
          sub-organizations.  Rather than assigning unique Allocator
          Identifiers to each sub-organization on a first-come, first-served
          basis, there are operational benefits in assigning Allocator
          Identifiers to such an organization in a structured way.  This allows
          an external observer to detect that a group of Allocator Identifiers
          is organizationally associated.</t>
          <t indent="0" pn="section-3.2.1-2">An Allocator Identifier range is a set of consecutive Allocator
          Identifiers associated with the same Allocator. Each individual
          Allocator Identifier in a given range <bcp14>SHOULD</bcp14> be
          assigned to a distinct sub-organization of the Allocator. Assigning
          identifiers in this way allows external observers to both associate
          individual Allocator Identifiers with a single organization and
          usefully differentiate amongst sub-organizations.</t>
          <t indent="0" pn="section-3.2.1-3">The practice of associating a consecutive range of numbers with a
          single organization is inspired by the Classless Inter-Domain
          Routing (CIDR) assignment of Internet addresses described in <xref target="RFC4632" format="default" sectionFormat="of" derivedContent="RFC4632"/>. In that assignment scheme, an organization (such
          as an Internet Service Provider (ISP)) is assigned a network prefix such
          that all addresses sharing that same prefix are considered to be
          associated with that organization.</t>
          <t indent="0" pn="section-3.2.1-4">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 indent="0" pn="section-3.2.1-5">Allocator Identifier ranges differ from CIDR addresses in two important ways:</t>
          <ol spacing="normal" type="1" indent="adaptive" start="1" pn="section-3.2.1-6">
	    <li pn="section-3.2.1-6.1" derivedCounter="1.">
              <t indent="0" pn="section-3.2.1-6.1.1">Allocator Identifiers are used to identify organizations and are not, themselves, addresses.</t>
            </li>
            <li pn="section-3.2.1-6.2" derivedCounter="2.">
              <t indent="0" pn="section-3.2.1-6.2.1">Allocator Identifiers may be less than 32 bits in length.</t>
            </li>
          </ol>
          <t indent="0" pn="section-3.2.1-7">In order to differentiate between Allocator Identifier ranges
          using efficient bitwise operations, all ranges <bcp14>MUST</bcp14>
          be of a size S that is a power of 2, and for a given range of length
          N bits, with S = 2<sup>N</sup>, the least-significant N bits of the
          first Allocator Identifier <bcp14>MUST</bcp14> be all 0.</t>
          <t indent="0" pn="section-3.2.1-8">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" pn="table-1">
            <name slugifiedName="name-allocator-identifier-range-">Allocator Identifier Range Assignment Example</name>
            <thead>
              <tr>
                <th align="left" colspan="1" rowspan="1">Organization</th>
                <th align="left" colspan="1" rowspan="1">Range (dec)</th>
                <th align="left" colspan="1" rowspan="1">Range (hex)</th>
                <th align="left" colspan="1" rowspan="1">Range Length (Bits)</th>
              </tr>
            </thead>
            <tbody>
              <tr>
                <td align="left" colspan="1" rowspan="1">Org A</td>
                <td align="left" colspan="1" rowspan="1">974848 .. 974975</td>
                <td align="left" colspan="1" rowspan="1">0xEE000 .. 0xEE07F</td>
                <td align="left" colspan="1" rowspan="1">7 bits</td>
              </tr>
              <tr>
                <td align="left" colspan="1" rowspan="1">Org B</td>
                <td align="left" colspan="1" rowspan="1">974976 .. 974991</td>
                <td align="left" colspan="1" rowspan="1">0xEE080 .. 0xEE08F</td>
                <td align="left" colspan="1" rowspan="1">4 bits</td>
              </tr>
              <tr>
                <td align="left" colspan="1" rowspan="1">Org C</td>
                <td align="left" colspan="1" rowspan="1">974992 .. 974993</td>
                <td align="left" colspan="1" rowspan="1">0xEE090 .. 0xEE091</td>
                <td align="left" colspan="1" rowspan="1">1 bit</td>
              </tr>
              <tr>
                <td align="left" colspan="1" rowspan="1">Org D</td>
                <td align="left" colspan="1" rowspan="1">974994</td>
                <td align="left" colspan="1" rowspan="1">0xEE092</td>
                <td align="left" colspan="1" rowspan="1">0 bits</td>
              </tr>
            </tbody>
          </table>
          <t indent="0" pn="section-3.2.1-10">With these assignments, any Allocator Identifier whose
          most-significant 25 bits match 0xEE000 belong to organization
          A. Similarly, any Allocator Identifier whose most-significant 28
          bits match 0xEE080 belong to organization B, and any Allocator
          Identifier whose most-significant 31 bits are 0xEE090 belong to
          organization C.  Organization D has a single Allocator Identifier,
          and hence a range of bit-length 0.</t>
        </section>
        <section anchor="default-allocator" numbered="true" removeInRFC="false" toc="include" pn="section-3.2.2">
          <name slugifiedName="name-the-default-allocator">The Default Allocator</name>
          <t indent="0" pn="section-3.2.2-1">As of the publication of <xref target="RFC7116" format="default" sectionFormat="of" derivedContent="RFC7116"/>, the only
          organization permitted to assign Node Numbers was the Internet
          Assigned Numbers Authority (IANA), which assigned Node Numbers via
          the "CBHE Node Numbers" registry. This means that all ipn URIs
          created prior to the addition of Allocator Identifiers are assumed
          to have Node Number allocations that comply with the "CBHE Node
          Numbers" registry.</t>
          <t indent="0" pn="section-3.2.2-2">The presumption that Node Numbers
          are allocated by IANA from a specific registry, unless otherwise specified, 
          is formalized in this
          update to the 'ipn' URI scheme by designating IANA as the Default
          Allocator and by assigning the Allocator Identifier zero (0) in the
          "'ipn' Scheme URI Allocator Identifiers" registry
	  (<xref target="iana-allocator-identifiers" format="default" sectionFormat="of" derivedContent="Section 9.1"/>) to the Default Allocator.
	  In any case
          where an encoded ipn URI does not explicitly include an Allocator
          Identifier, an implementation <bcp14>MUST</bcp14> assume that the
          Node Number has been allocated by the Default Allocator.</t>
          <t indent="0" pn="section-3.2.2-3">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" format="default" sectionFormat="of" derivedContent="Section 3.4"/>
          below.</t>
        </section>
      </section>
      <section anchor="node-numbers" numbered="true" removeInRFC="false" toc="include" pn="section-3.3">
        <name slugifiedName="name-node-numbers">Node Numbers</name>
        <t indent="0" pn="section-3.3-1">A Node Number identifies a node that hosts a resource in the
        context of an Allocator. A Node Number is an unsigned integer. A
        single Node Number assigned by a single Allocator <bcp14>MUST</bcp14>
        refer to a single node.</t>
        <t indent="0" pn="section-3.3-2">All Node Number assignments, by all Allocators, <bcp14>MUST</bcp14>
        be in the range 0 to 2<sup>32-1</sup>.</t>
        <t indent="0" pn="section-3.3-3">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" format="default" sectionFormat="of" derivedContent="Section 3.1"/>).</t>
        <section anchor="fqnn" numbered="true" removeInRFC="false" toc="include" pn="section-3.3.1">
          <name slugifiedName="name-fully-qualified-node-number">Fully Qualified Node Numbers</name>
          <t indent="0" pn="section-3.3.1-1">One of the advantages of ipn URIs is the ability to easily split
          the identity of a particular service from the node upon which the
          service exists.  For example, a message received from one particular
          ipn URI may require a response to be sent to a different service on
          the same node that sent the original message.  Historically, the
          identifier of the sending node has been colloquially referred to as
          the "node number" or "node identifier".</t>
          <t indent="0" pn="section-3.3.1-2">To avoid future confusion, when referring to the identifier of a
          particular 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 Identifier component of an ipn URI
          that uniquely identifies a particular node.  In other words, an FQNN
          is the unique identifier of a particular node that supports services
          identified by ipn URIs.</t>
          <t indent="0" pn="section-3.3.1-3">In the examples in this document, FQNNs are written as (Allocator
          Identifier, Node Number). For example, <tt>(977000,100)</tt> is the FQNN
          for a node assigned Node Number 100 by an Allocator with Allocator
          Identifier 977000.</t>
        </section>
      </section>
      <section anchor="special-node-numbers" numbered="true" removeInRFC="false" toc="include" pn="section-3.4">
        <name slugifiedName="name-special-node-numbers">Special Node Numbers</name>
        <t indent="0" pn="section-3.4-1">Some special-case Node Numbers are defined by the Default
        Allocator; see <xref target="iana-node-numbers" format="default" sectionFormat="of" derivedContent="Section 9.2"/>.</t>
        <section anchor="the-zero-node-number" numbered="true" removeInRFC="false" toc="include" pn="section-3.4.1">
          <name slugifiedName="name-the-zero-node-number">The Zero Node Number</name>
          <t indent="0" pn="section-3.4.1-1">The Default Allocator assigns the use of Node Number zero (0)
          solely for identifying the Null ipn
          URI (<xref target="null-uri" format="default" sectionFormat="of" derivedContent="Section 3.1"/>).</t>
          <t indent="0" pn="section-3.4.1-2">This means that any ipn URI with a zero (0) Allocator Identifier
          and a zero (0) Node Number, but a non-zero Service Number component,
          is 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 anchor="localnode-uri" numbered="true" removeInRFC="false" toc="include" pn="section-3.4.2">
          <name slugifiedName="name-localnode-ipn-uris">LocalNode ipn URIs</name>
          <t indent="0" pn="section-3.4.2-1">The Default Allocator reserves Node Number 2<sup>32-1</sup>
          (0xFFFFFFFFF) to specify resources on the local node, rather than on
          any specific individual node.</t>
          <t indent="0" pn="section-3.4.2-2">This means that any ipn URI with a zero (0) Allocator Identifier
          and a Node Number of 2<sup>32-1</sup> refers to a service on the
          local bundle node. This form of ipn URI is termed a "LocalNode ipn
          URI".</t>
        </section>
        <section anchor="private-use" numbered="true" removeInRFC="false" toc="include" pn="section-3.4.3">
          <name slugifiedName="name-private-use-node-numbers">Private Use Node Numbers</name>
          <t indent="0" pn="section-3.4.3-1">The Default Allocator provides a range of Node Numbers that are
          reserved for Private Use, as defined in <xref target="RFC8126" format="default" sectionFormat="of" derivedContent="RFC8126"/>.</t>
          <t indent="0" pn="section-3.4.3-2">Any ipn URI with a zero (0) Allocator Identifier and a Node
          Number reserved for Private Use is not guaranteed to be unique
          beyond a single administrative domain.  An administrative domain, as
          used here, is defined as the set of nodes that share a unique
          allocation of FQNNs from the Private Use range.  These FQNNs can
          be considered to be functionally similar to private address space
          IPv4 addresses, as defined in <xref target="RFC1918" format="default" sectionFormat="of" derivedContent="RFC1918"/>.</t>
          <t indent="0" pn="section-3.4.3-3">Because of this lack of uniqueness, any implementation of a
          protocol using ipn URIs that resides on the border between
          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 anchor="service-numbers" numbered="true" removeInRFC="false" toc="include" pn="section-3.5">
        <name slugifiedName="name-service-numbers">Service Numbers</name>
        <t indent="0" pn="section-3.5-1">A Service Number is an unsigned integer that identifies a
        particular service operating on a node.  A service in this case is
        some logical function that requires its own resource identifier to
        distinguish it from other functions operating on the same node.</t>
      </section>
    </section>
    <section anchor="textual-representation-of-ipn-uris" numbered="true" removeInRFC="false" toc="include" pn="section-4">
      <name slugifiedName="name-textual-representation-of-i">Textual Representation of ipn URIs</name>
      <t indent="0" pn="section-4-1">All 'ipn' scheme URIs comply with <xref target="RFC3986" format="default" sectionFormat="of" derivedContent="RFC3986"/> and are
      therefore represented by a scheme identifier and a scheme-specific part.
      The scheme identifier is <tt>ipn</tt>, and the scheme-specific parts
      are represented as a sequence of numeric components separated with the
      '<tt>.</tt>' character.  A formal definition is provided below (see
      <xref target="text-syntax" format="default" sectionFormat="of" derivedContent="Section 4.1"/>) and can be
      informally considered as:</t>
      <artwork align="left" pn="section-4-2">
ipn:[&lt;allocator-identifier&gt;.]&lt;node-number&gt;.&lt;service-number&gt;
</artwork>
      <t indent="0" pn="section-4-3">To keep the text representation concise, the following rules apply:</t>
      <ol spacing="normal" type="1" indent="adaptive" start="1" pn="section-4-4">
	<li pn="section-4-4.1" derivedCounter="1.">
          <t indent="0" pn="section-4-4.1.1">All leading '<tt>0</tt>' characters <bcp14>MUST</bcp14> be
          omitted. A single '<tt>0</tt>' is valid.</t>
        </li>
        <li pn="section-4-4.2" derivedCounter="2.">
          <t indent="0" pn="section-4-4.2.1">If the Allocator Identifier is zero (0), then the
          <tt>&lt;allocator-identifier&gt;</tt> and '<tt>.</tt>'
          <bcp14>MAY</bcp14> be omitted.</t>
        </li>
        <li pn="section-4-4.3" derivedCounter="3.">
          <t indent="0" pn="section-4-4.3.1">If the Allocator Identifier is zero (0), and the Node Number is
          2<sup>32-1</sup> (i.e., the URI is a LocalNode ipn URI (<xref target="localnode-uri" format="default" sectionFormat="of" derivedContent="Section 3.4.2"/>)), then the character
          '<tt>!</tt>' <bcp14>SHOULD</bcp14> be used instead of the digits
          <tt>4294967295</tt>, although both forms are valid encodings.</t>
        </li>
      </ol>
      <t indent="0" pn="section-4-5">Examples of the textual representation of ipn URIs can be found in
      <xref target="text-examples" format="default" sectionFormat="of" derivedContent="Appendix A"/>.</t>
      <section anchor="text-syntax" numbered="true" removeInRFC="false" toc="include" pn="section-4.1">
        <name slugifiedName="name-ipn-uri-scheme-text-syntax">'ipn' URI Scheme Text Syntax</name>
        <t indent="0" pn="section-4.1-1">The text syntax of an ipn URI <bcp14>MUST</bcp14> comply with the
        following ABNF syntax from <xref target="RFC5234" format="default" sectionFormat="of" derivedContent="RFC5234"/> and repeats the
        core ABNF syntax rule for DIGIT defined by that specification:</t>
        <sourcecode type="abnf" markers="false" pn="section-4.1-2">
ipn-uri = "ipn:" ipn-hier-part

ipn-hier-part = fqnn "." service-number

fqnn = "!" / allocator-part

allocator-part = [allocator-identifier "."] node-number

allocator-identifier = number

node-number = number

service-number = number

number = "0" / non-zero-number

non-zero-number = (%x31-39 *DIGIT)

DIGIT = %x30-39
</sourcecode>
      </section>
    </section>
    <section anchor="usage-of-ipn-uris-with-bpv7" numbered="true" removeInRFC="false" toc="include" pn="section-5">
      <name slugifiedName="name-usage-of-ipn-uris-with-bpv7">Usage of ipn URIs with BPv7</name>
      <t indent="0" pn="section-5-1">From the earliest days of experimentation with the Bundle Protocol,
      there has been a need to identify the source and destination of a
      bundle.  The IRTF BPv6 experimental specification <xref target="RFC5050" format="default" sectionFormat="of" derivedContent="RFC5050"/> termed the logical
      source or destination of a bundle as an "Endpoint" identified by an
      "Endpoint Identifier" (EID). BPv6 EIDs are formatted as URIs. This
      definition and representation of EIDs was carried forward from the IRTF
      BPv6 specification <xref target="RFC5050" format="default" sectionFormat="of" derivedContent="RFC5050"/> to the IETF BPv7 specification <xref target="RFC9171" format="default" sectionFormat="of" derivedContent="RFC9171"/>. <xref target="RFC9171" format="default" sectionFormat="of" derivedContent="RFC9171"/> additionally
      defined an IANA registry called the "Bundle Protocol URI Scheme Types"
      registry, which identifies those URI schemes that might be used to
      represent EIDs.  The 'ipn' URI scheme is one such URI scheme.</t>
      <t indent="0" pn="section-5-2">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" numbered="true" removeInRFC="false" toc="include" pn="section-5.1">
        <name slugifiedName="name-uniqueness-constraints">Uniqueness Constraints</name>
        <t indent="0" pn="section-5.1-1">An ipn EID <bcp14>MUST</bcp14> identify a singleton endpoint. The
        bundle processing node that is the sole member of that endpoint
        <bcp14>MUST</bcp14> be the node identified by the FQNN (<xref target="fqnn" format="default" sectionFormat="of" derivedContent="Section 3.3.1"/>) of the node.</t>
        <t indent="0" pn="section-5.1-2">A single bundle processing node <bcp14>MAY</bcp14> have multiple
        ipn EIDs associated with it. However, all ipn EIDs that share any
        single FQNN <bcp14>MUST</bcp14> refer to the same bundle processing
        node.</t>
        <t indent="0" pn="section-5.1-3">For example, <tt>ipn:977000.100.1</tt>, <tt>ipn:977000.100.2</tt>,
        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 anchor="the-null-endpoint" numbered="true" removeInRFC="false" toc="include" pn="section-5.2">
        <name slugifiedName="name-the-null-endpoint">The Null Endpoint</name>
        <t indent="0" pn="section-5.2-1"><xref section="3.2" sectionFormat="of" target="RFC9171" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9171#section-3.2" derivedContent="RFC9171"/> defines
        the concept of the Null endpoint, which is an endpoint that has no
        members and is identified by a special Null EID.</t>
        <t indent="0" pn="section-5.2-2">Within the 'ipn' URI scheme, the Null EID is represented by the
       Null ipn URI (<xref target="null-uri" format="default" sectionFormat="of" derivedContent="Section 3.1"/>).  This means that the URIs
        <tt>dtn:none</tt> (<xref section="4.2.5.1.1" sectionFormat="of" target="RFC9171" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9171#section-4.2.5.1.1" derivedContent="RFC9171"/>), <tt>ipn:0.0</tt>, and <tt>ipn:0.0.0</tt> all
        refer to the BPv7 Null endpoint.</t>
      </section>
      <section anchor="bpv7-node-id" numbered="true" removeInRFC="false" toc="include" pn="section-5.3">
        <name slugifiedName="name-bpv7-node-id">BPv7 Node ID</name>
        <t indent="0" pn="section-5.3-1"><xref section="4.2.5.2" sectionFormat="of" target="RFC9171" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9171#section-4.2.5.2" derivedContent="RFC9171"/>
        introduces the concept of a "Node ID" that has the same format as an
        EID and uniquely identifies a bundle processing node.</t>
        <t indent="0" pn="section-5.3-2">Any ipn EID can serve as a "Node ID" for the bundle processing node
        identified by its FQNN (<xref target="fqnn" format="default" sectionFormat="of" derivedContent="Section 3.3.1"/>). That is, any ipn EID of the form <tt>ipn:A.B.C</tt> may be used
        as the Source Node ID of any bundle created by the bundle processing
        node identified by the FQNN <tt>(A,B)</tt>.</t>
      </section>
      <section anchor="localnode-ipn-eids" numbered="true" removeInRFC="false" toc="include" pn="section-5.4">
        <name slugifiedName="name-localnode-ipn-eids">LocalNode ipn EIDs</name>
        <t indent="0" pn="section-5.4-1">When a LocalNode ipn URI (<xref target="localnode-uri" format="default" sectionFormat="of" derivedContent="Section 3.4.2"/>) is
        used as a BPv6 or BPv7 EID, it is termed a "LocalNode ipn EID".</t>
        <t indent="0" pn="section-5.4-2">Because a LocalNode ipn EID only has meaning on the local bundle
        node, 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 <bcp14>MUST NOT</bcp14> be
        allowed to leave the local node.  Equally, all externally received
        bundles featuring LocalNode EIDs as a bundle source or bundle
        destination <bcp14>MUST</bcp14> be discarded as invalid.</t>
        <t indent="0" pn="section-5.4-3">LocalNode ipn EIDs <bcp14>MUST NOT</bcp14> be present in any other
        part of a bundle that is transmitted off of the local node. For
        example, a LocalNode ipn EID <bcp14>MUST NOT</bcp14> be used as a
        Bundle Protocol Security (BPSec) <xref target="RFC9172" format="default" sectionFormat="of" derivedContent="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
        node.</t>
        <t indent="0" pn="section-5.4-4">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" format="default" sectionFormat="of" derivedContent="RFC9174"/>.</t>
      </section>
      <section anchor="private-use-ipn-eids" numbered="true" removeInRFC="false" toc="include" pn="section-5.5">
        <name slugifiedName="name-private-use-ipn-eids">Private Use ipn EIDs</name>
        <t indent="0" pn="section-5.5-1">Bundles destined for EIDs that use an ipn URI with an FQNN (<xref target="fqnn" format="default" sectionFormat="of" derivedContent="Section 3.3.1"/>) that is within the
        Private Use range of the Default Allocator (<xref target="default-allocator" format="default" sectionFormat="of" derivedContent="Section 3.2.2"/>) are not universally unique; therefore, they are only
        valid within the scope of the current administrative domain.  This
        means that any bundle using a Private Use ipn EID as a bundle source
        or bundle destination <bcp14>MUST NOT</bcp14> be allowed to cross
        administrative domains.  All implementations that could be deployed as
        a gateway between administrative domains <bcp14>MUST</bcp14> be
        sufficiently configurable to ensure that this is enforced, and
        operators <bcp14>MUST</bcp14> ensure correct configuration.</t>
        <t indent="0" pn="section-5.5-2">Private Use ipn EIDs <bcp14>MUST NOT</bcp14> be present in any
        other part of a bundle that is destined for another administrative
        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" format="default" sectionFormat="of" derivedContent="RFC9172"/> security source for
        a bundle when the bundle is destined for a different administrative
        domain.</t>
      </section>
      <section anchor="well-known-service-numbers" numbered="true" removeInRFC="false" toc="include" pn="section-5.6">
        <name slugifiedName="name-well-known-service-numbers">Well-Known Service Numbers</name>
        <t indent="0" pn="section-5.6-1">It is convenient for BPv7 services that have a public specification
        and wide adoption to be identified by a pre-agreed default Service
        Number, so that unless overridden by explicit configuration, such services
        can be sensibly assumed to be operating on the well-known Service
        Number on a particular node.</t>
        <t indent="0" pn="section-5.6-2">If a different service uses the number, or the service uses a
        different number, BPv7 will continue to operate, but some
        configuration may be required to make the individual service
        operational.</t>
        <t indent="0" pn="section-5.6-3">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" format="default" sectionFormat="of" derivedContent="Section 9.3"/>.  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 anchor="administrative-endpoints" numbered="true" removeInRFC="false" toc="include" pn="section-5.7">
        <name slugifiedName="name-administrative-endpoints">Administrative Endpoints</name>
        <t indent="0" pn="section-5.7-1">The service identified by a Service Number of zero (0)
        <bcp14>MUST</bcp14> be interpreted as the Administrative Endpoint of
        the node, as defined in <xref section="3.2" sectionFormat="of" target="RFC9171" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9171#section-3.2" derivedContent="RFC9171"/>.</t>
        <t indent="0" pn="section-5.7-2">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 anchor="cbor-representation-of-ipn-uris-with-bpv7" numbered="true" removeInRFC="false" toc="include" pn="section-6">
      <name slugifiedName="name-cbor-representation-of-ipn-">CBOR Representation of ipn URIs with BPv7</name>
      <t indent="0" pn="section-6-1"><xref section="4.2.5.1" sectionFormat="of" target="RFC9171" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9171#section-4.2.5.1" derivedContent="RFC9171"/>
      requires that any URI scheme used to represent BPv7 EIDs
      <bcp14>MUST</bcp14> define how the scheme-specific part of the URI
      scheme is encoded with Concise Binary Object Representation (CBOR) <xref target="RFC8949" format="default" sectionFormat="of" derivedContent="RFC8949"/>. To meet this
      requirement, this section describes the CBOR encoding and decoding
      approach for ipn EIDs. The formal definition of the CBOR representation
      is specified; see <xref target="cbor-encoding" format="default" sectionFormat="of" derivedContent="Section 6.3"/>.</t>
      <section anchor="ipn-eid-cbor-encoding" numbered="true" removeInRFC="false" toc="include" pn="section-6.1">
        <name slugifiedName="name-ipn-eid-cbor-encoding">ipn EID CBOR Encoding</name>
        <t indent="0" pn="section-6.1-1">Generic URI approaches to encoding ipn EIDs are unlikely to be
        efficient because they do not consider the underlying structure of the
        'ipn' URI scheme. Since the creation of the 'ipn' URI scheme was motivated
        by the need for concise identification and rapid processing, the
        encoding of ipn EIDs maintains these properties.</t>
        <t indent="0" pn="section-6.1-2">Fundamentally, ipn EIDs from <xref target="RFC9171" format="default" sectionFormat="of" derivedContent="RFC9171"/> are represented as
        a sequence of identifiers. In the text syntax, the numbers are
        separated with the '<tt>.</tt>' delimiter; in CBOR, this ordered
        series of numbers can be represented by an array. Therefore, when
        encoding ipn EIDs for use with BPv7, the scheme-specific part of an
        ipn URI <bcp14>MUST</bcp14> be represented as a CBOR array of either
        two (2) or three (3) elements. Each element of the array
        <bcp14>MUST</bcp14> be encoded as a single CBOR unsigned integer.</t>
        <t indent="0" pn="section-6.1-3">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" format="default" sectionFormat="of" derivedContent="Appendix B"/>.</t>
        <section anchor="two-encode" numbered="true" removeInRFC="false" toc="include" pn="section-6.1.1">
          <name slugifiedName="name-two-element-scheme-specific">Two-Element Scheme-Specific Encoding</name>
          <t indent="0" pn="section-6.1.1-1">In the two-element scheme-specific encoding of an ipn EID, the
          first element of the array is an encoding of the FQNN (<xref target="fqnn" format="default" sectionFormat="of" derivedContent="Section 3.3.1"/>), and the second
          element of the array is the ipn EID Service Number.</t>
          <t indent="0" pn="section-6.1.1-2">The FQNN encoding <bcp14>MUST</bcp14> be a 64-bit unsigned
          integer constructed in the following way:</t>
          <ol spacing="normal" type="1" indent="adaptive" start="1" pn="section-6.1.1-3"><li pn="section-6.1.1-3.1" derivedCounter="1.">
              <t indent="0" pn="section-6.1.1-3.1.1">The least significant 32 bits <bcp14>MUST</bcp14> represent
              the Node Number associated with the ipn EID.</t>
            </li>
            <li pn="section-6.1.1-3.2" derivedCounter="2.">
              <t indent="0" pn="section-6.1.1-3.2.1">The most significant 32 bits <bcp14>MUST</bcp14> represent
              the Allocator Identifier associated with the ipn EID.</t>
            </li>
          </ol>
          <t indent="0" pn="section-6.1.1-4">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 resulting two-element array
          <tt>[0xEE868_00000064, 0x01]</tt> would be encoded in CBOR as the
          following 11-octet sequence:</t>
          <sourcecode type="cbor" markers="false" pn="section-6.1.1-5">
82                        # 2-Element Endpoint Encoding
   02                     # uri-code: 2 ('ipn' URI scheme)
   82                     # 2-Element ipn EID encoding
      1B 000EE86800000064 # Fully Qualified Node Number
      01                  # Service Number
</sourcecode>
          <t indent="0" pn="section-6.1.1-6">The two-element scheme-specific encoding provides backwards
          compatibility with the encoding provided in <xref section="4.2.5.1.2" sectionFormat="of" target="RFC9171" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9171#section-4.2.5.1.2" derivedContent="RFC9171"/>. When used
          in this way, the encoding of the FQNN replaces the use of the Node
          Number that was specified in <xref target="RFC9171" format="default" sectionFormat="of" derivedContent="RFC9171"/>. When the
          Node Number is allocated by the Default Allocator (<xref target="default-allocator" format="default" sectionFormat="of" derivedContent="Section 3.2.2"/>), the encoding of
          the FQNN and the encoding of the Node Number from <xref target="RFC9171" format="default" sectionFormat="of" derivedContent="RFC9171"/> are identical.</t>
        </section>
        <section anchor="three-encode" numbered="true" removeInRFC="false" toc="include" pn="section-6.1.2">
          <name slugifiedName="name-three-element-scheme-specif">Three-Element Scheme-Specific Encoding</name>
          <t indent="0" pn="section-6.1.2-1">In the three-element scheme-specific encoding of an ipn EID:</t>
          <ol indent="adaptive" spacing="normal" start="1" type="1" pn="section-6.1.2-2">
	    <li pn="section-6.1.2-2.1" derivedCounter="1.">the first element of the array is the Allocator Identifier,</li>
            <li pn="section-6.1.2-2.2" derivedCounter="2.">the second element of the array is the Node Number, and</li>
            <li pn="section-6.1.2-2.3" derivedCounter="3.">the third element of the array is the Service Number.</li>
          </ol>
          <t indent="0" pn="section-6.1.2-3">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" markers="false" pn="section-6.1.2-4">
82                # 2-Element Endpoint Encoding
   02             # uri-code: 2 ('ipn' URI scheme)
   83             # 3-Element ipn EID encoding
      1A 000EE868 # Allocator Identifier
      64          # Node Number
      01          # Service Number
</sourcecode>
          <t indent="0" pn="section-6.1.2-5">The three-element scheme-specific encoding allows for a more
          efficient representation of ipn EIDs using smaller Allocator
          Identifiers, and implementations are <bcp14>RECOMMENDED</bcp14> to
          use this encoding scheme unless explicitly mitigating for
          interoperability issues; see <xref target="compatibility" format="default" sectionFormat="of" derivedContent="Section 7.1"/>.</t>
          <t indent="0" pn="section-6.1.2-6">When encoding an ipn EID using the Default Allocator (<xref target="default-allocator" format="default" sectionFormat="of" derivedContent="Section 3.2.2"/>) with this
          encoding scheme, the first element of the array is the value zero
          (0).  In this case, using the equivalent two-element scheme-specific
	  encoding (<xref target="two-encode" format="default" sectionFormat="of" derivedContent="Section 6.1.1"/>) will
          result in a more concise CBOR representation; therefore, it is
          <bcp14>RECOMMENDED</bcp14> that implementations use that encoding
          instead.</t>
        </section>
      </section>
      <section anchor="ipn-eid-cbor-decoding" numbered="true" removeInRFC="false" toc="include" pn="section-6.2">
        <name slugifiedName="name-ipn-eid-cbor-decoding">ipn EID CBOR Decoding</name>
        <t indent="0" pn="section-6.2-1">The presence of different scheme-specific encodings does not
        introduce any decoding ambiguity.</t>
        <t indent="0" pn="section-6.2-2">An ipn EID CBOR decoder can reconstruct an ipn EID using the
        following logic. In this description, the term <tt>enc_eid</tt> refers
        to the CBOR-encoded ipn EID, and the term <tt>ipn_eid</tt> refers to
        the decoded ipn EID.</t>
        <sourcecode type="pseudocode" markers="false" pn="section-6.2-3">
if enc_eid.len() == 3
{
  ipn_eid.allocator_identifier := enc_eid[0];
  ipn_eid.node_number := enc_eid[1];
  ipn_eid.service_number := enc_eid[2];
}
else if enc_eid.len() == 2
{
  ipn_eid.allocator_identifier := enc_eid[0] &gt;&gt; 32;
  ipn_eid.node_number := enc_eid[0] &amp; (2^(32-1));
  ipn_eid.service_number := enc_eid[1];
}
</sourcecode>
      </section>
      <section anchor="cbor-encoding" numbered="true" removeInRFC="false" toc="include" pn="section-6.3">
        <name slugifiedName="name-ipn-uri-scheme-cbor-syntax">'ipn' URI Scheme CBOR Syntax</name>
        <t indent="0" pn="section-6.3-1">When encoded in CBOR <xref target="RFC8949" format="default" sectionFormat="of" derivedContent="RFC8949"/>, a BPv7 endpoint identified by an ipn URI
        <bcp14>MUST</bcp14> comply with the following Concise Data Definition
        Language (CDDL) <xref target="RFC8610" format="default" sectionFormat="of" derivedContent="RFC8610"/> specification:</t>
        <sourcecode type="cddl" markers="false" pn="section-6.3-2">
eid = $eid .within eid-structure

eid-structure = [
  uri-code: uint,
  SSP: any
]

; ... Syntax for other uri-code values defined in RFC 9171 ...

$eid /= [
  uri-code: 2,
  SSP: ipn-ssp2 / ipn-ssp3
]
ipn-ssp2 = [
  fqnn: uint,  ; packed value
  service-number: uint
]
ipn-ssp3 = [
  allocator-identifier: uint .lt 4294967296,
  node-number: uint .lt 4294967296,
  service-number: uint
]
</sourcecode>
        <t indent="0" pn="section-6.3-3">Note: The <tt>node-number</tt> component will be the numeric
        representation of the concatenation of the Allocator Identifier and
        Node Number when the two-element encoding scheme has been used.</t>
      </section>
      <section anchor="ipn-eid-matching" numbered="true" removeInRFC="false" toc="include" pn="section-6.4">
        <name slugifiedName="name-ipn-eid-matching">ipn EID Matching</name>
        <t indent="0" pn="section-6.4-1">Regardless of whether the two-element or three-element
        scheme-specific encoding is used, ipn EID matching <bcp14>MUST</bcp14>
        be performed on the decoded EID information itself. Different
        encodings of the same ipn EID <bcp14>MUST</bcp14> be treated as
        equivalent when performing EID-specific functions.</t>
        <t indent="0" pn="section-6.4-2">For example, the ipn EID of <tt>ipn:977000.100.1</tt> can be
        represented as either the two-element encoding of
        <tt>0x821B000EE8680000006401</tt> or the three-element encoding of
        <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 anchor="special-considerations" numbered="true" removeInRFC="false" toc="include" pn="section-7">
      <name slugifiedName="name-special-considerations">Special Considerations</name>
      <t indent="0" pn="section-7-1">The 'ipn' URI scheme provides a compact and hierarchical mechanism for
      identifying services on network nodes. There is a significant amount of
      utility in the 'ipn' URI scheme approach to identification. However,
      implementers should take into consideration the following observations
      on the use of the 'ipn' URI scheme, particularly in regard to
      interoperability with implementations that pre-date this
      specification.</t>
      <section anchor="compatibility" numbered="true" removeInRFC="false" toc="include" pn="section-7.1">
        <name slugifiedName="name-scheme-compatibility">Scheme Compatibility</name>
        <t indent="0" pn="section-7.1-1">The 'ipn' URI scheme update that has been presented in this document
        preserves backwards compatibility with any 'ipn' URI scheme going back
        to the provisional definition of the 'ipn' scheme in the experimental
        specification "Compressed Bundle Header Encoding (CBHE)" <xref target="RFC6260" format="default" sectionFormat="of" derivedContent="RFC6260"/> in 2011. This means that any ipn URI that was valid
        prior to the publication of this update remains a valid ipn URI.</t>
        <t indent="0" pn="section-7.1-2">Similarly, the two-element
        scheme-specific encoding (<xref target="two-encode" format="default" sectionFormat="of" derivedContent="Section 6.1.1"/>) is also
	backwards compatible with the
        encoding of ipn URIs provided in <xref target="RFC9171" format="default" sectionFormat="of" derivedContent="RFC9171"/>. Any
        existing implementation compliant with <xref target="RFC9171" format="default" sectionFormat="of" derivedContent="RFC9171"/> will
        produce an ipn URI encoding in compliance with this specification.</t>
        <t indent="0" pn="section-7.1-3">The introduction of optional non-default Allocator Identifiers and
        a three-element scheme-specific encoding does not make this ipn URI
        scheme update forwards compatible. Existing implementations for which
        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 anchor="cbor-representation-interoperability" numbered="true" removeInRFC="false" toc="include" pn="section-7.2">
        <name slugifiedName="name-cbor-representation-interop">CBOR Representation Interoperability</name>
        <t indent="0" pn="section-7.2-1">Care must be taken when deploying implementations that default to
        using the three-element encoding in networks that include
        implementations that only support the two-element encoding <xref target="RFC9171" format="default" sectionFormat="of" derivedContent="RFC9171"/>. Because the existing implementations will reject
        bundles that use the three-element encoding as malformed, correct
        forwarding of semantically valid bundles will fail.  The used
        mitigation for this issue depends on the nature of the
        interoperability required by the deployment. Techniques can
        include:</t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-7.2-2">
          <li pn="section-7.2-2.1">
            <t indent="0" pn="section-7.2-2.1.1">A configuration option indicating when an implementation must
            use the two-element encoding for all ipn EIDs when processing
            bundles destined to a given endpoint. This would be suitable when
            adding a newer implementation to a network of existing
            implementations.</t>
          </li>
          <li pn="section-7.2-2.2">
            <t indent="0" pn="section-7.2-2.2.1">Selective bundle encapsulation, whereby bundles that are known
            to originate from implementations that do not support the
            three-element encoding are tunneled across regions of the network
            that require the three-element encoding. This would utilize
            specially configured "gateway nodes" to perform the tunnel
            encapsulation and decapsulation and would be suitable when
            joining an existing network to a larger network.</t>
          </li>
        </ul>
        <t indent="0" pn="section-7.2-3">Techniques that do not mitigate the problem include:</t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-7.2-4">
          <li pn="section-7.2-4.1">
            <t indent="0" pn="section-7.2-4.1.1">Heuristic determination of the correct encoding to use when
            responding to a bundle by examining the incoming bundle. It is not
            possible to determine whether the two-element encoding is required
            by the destination when composing a new bundle in response to the
            receipt of a bundle, such as a status report, because ipn EIDs
            assigned by the Default Allocator use the two-element encoding,
            whether or not the implementation supports the three-element encoding.</t>
          </li>
          <li pn="section-7.2-4.2">
            <t indent="0" pn="section-7.2-4.2.1">Transcoding bundles at intermediate nodes. <xref target="RFC9171" format="default" sectionFormat="of" derivedContent="RFC9171"/> requires the bundle primary block to be immutable,
            and even if ipn EIDs in the primary block do not require
            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" format="default" sectionFormat="of" derivedContent="RFC9172"/>, making them
            immutable.</t>
          </li>
        </ul>
      </section>
      <section anchor="text-representation-compatibility" numbered="true" removeInRFC="false" toc="include" pn="section-7.3">
        <name slugifiedName="name-text-representation-compati">Text Representation Compatibility</name>
        <t indent="0" pn="section-7.3-1">The textual representation of ipn URIs is not forwards compatible
        with <xref target="RFC9171" format="default" sectionFormat="of" derivedContent="RFC9171"/>. Therefore, care must be taken when
        deploying implementations or tooling that use the textural
        representation of ipn URIs and support for non-default Allocator
        Identifiers is required.  For example, <xref section="4.6" sectionFormat="of" target="RFC9174" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9174#section-4.6" derivedContent="RFC9174"/> specifies that the session
        initialization message "...<bcp14>SHALL</bcp14> contain the UTF-8
        encoded node ID of the entity that sent the SESS_INIT message."  In
        such cases, the considerations that apply to the use of the three-element
        CBOR encoding also apply to the text representation when a non-default
        Allocator Identifier is present.</t>
      </section>
      <section anchor="bundle-protocol-version-6-compatibility" numbered="true" removeInRFC="false" toc="include" pn="section-7.4">
        <name slugifiedName="name-bundle-protocol-version-6-c">Bundle Protocol Version 6 Compatibility</name>
        <t indent="0" pn="section-7.4-1">This document updates the use of ipn EIDs for BPv7; however, the 'ipn'
        URI scheme was originally defined for use with BPv6.  This document does not update any of the behaviors,
        wire-formats, or mechanisms of BPv6.  Therefore, ipn EIDs with
        non-default Allocator Identifiers <bcp14>MUST NOT</bcp14> be used with
        BPv6, and the Allocator Identifier prefix <bcp14>MUST</bcp14> be
        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 anchor="late-binding" numbered="true" removeInRFC="false" toc="include" pn="section-7.5">
        <name slugifiedName="name-late-binding">Late Binding</name>
        <t indent="0" pn="section-7.5-1"><xref target="RFC9171" format="default" sectionFormat="of" derivedContent="RFC9171"/> mandates the concept of the "late binding" of
        an EID, whereby the address of the destination of a bundle is resolved
        from its identifier hop-by-hop as it transits a BPv7 network.  This
        per-hop binding of identifiers to addresses underlines the fact that
        EIDs are purely names and should not carry any implicit or explicit
        information concerning the current location or reachability of an
        identified node and service.  This removes the need to rename a node
        as its location changes.</t>
        <t indent="0" pn="section-7.5-2">The concept of late binding is preserved in this 'ipn' URI
        scheme. Elements of an ipn URI <bcp14>MUST NOT</bcp14> be regarded as
        carrying information relating to location, reachability, or other
        addressing/routing concerns.</t>
        <t indent="0" pn="section-7.5-3">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 anchor="security-considerations" numbered="true" removeInRFC="false" toc="include" pn="section-8">
      <name slugifiedName="name-security-considerations">Security Considerations</name>
      <t indent="0" pn="section-8-1">This section updates the security considerations from <xref section="4.2.5.1.2" sectionFormat="of" target="RFC9171" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9171#section-4.2.5.1.2" derivedContent="RFC9171"/> to account for
      the inclusion of Allocator Identifiers in the 'ipn' URI scheme when used
      with BPv7.</t>
      <section anchor="reliability-and-consistency" numbered="true" removeInRFC="false" toc="include" pn="section-8.1">
        <name slugifiedName="name-reliability-and-consistency">Reliability and Consistency</name>
        <t indent="0" pn="section-8.1-1">None of the BPv7 endpoints identified by ipn EIDs are guaranteed to
        be reachable at any time, and the identity of the processing entities
        operating on those endpoints is never guaranteed by the Bundle
        Protocol itself. Verification of the signature provided by the Block
        Integrity Block (BIB) targeting the bundle's primary block, as defined by
       "Bundle Protocol Security (BPSec)" <xref target="RFC9172" format="default" sectionFormat="of" derivedContent="RFC9172"/>, is required for
        this purpose.</t>
      </section>
      <section anchor="malicious-construction" numbered="true" removeInRFC="false" toc="include" pn="section-8.2">
        <name slugifiedName="name-malicious-construction">Malicious Construction</name>
        <t indent="0" pn="section-8.2-1">Malicious construction of a conformant ipn URI is limited to the
        malicious selection of Allocator Identifiers, Node Numbers, and
        Service Numbers. That is, a maliciously constructed ipn EID could be
        used to direct a bundle to an endpoint that might be damaged by the
        arrival of that bundle or, alternatively, to declare a false source
        for a bundle and thereby cause incorrect processing at a node that
        receives the bundle. 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 <xref target="RFC9172" format="default" sectionFormat="of" derivedContent="RFC9172"/> and TCP Convergence Layer version 4 (TCPCLv4) with TLS <xref target="RFC9174" format="default" sectionFormat="of" derivedContent="RFC9174"/>.</t>
      </section>
      <section anchor="back-end-transcoding" numbered="true" removeInRFC="false" toc="include" pn="section-8.3">
        <name slugifiedName="name-back-end-transcoding">Back-End Transcoding</name>
        <t indent="0" pn="section-8.3-1">The limited expressiveness of URIs of the 'ipn' scheme effectively
        eliminates the possibility of threats due to errors in back-end
        transcoding.</t>
      </section>
      <section anchor="local-and-private-use-ipn-eids" numbered="true" removeInRFC="false" toc="include" pn="section-8.4">
        <name slugifiedName="name-local-and-private-use-ipn-e">Local and Private Use ipn EIDs</name>
        <t indent="0" pn="section-8.4-1">Both LocalNode (<xref target="localnode-uri" format="default" sectionFormat="of" derivedContent="Section 3.4.2"/>) and Private Use (<xref target="private-use" format="default" sectionFormat="of" derivedContent="Section 3.4.3"/>) ipn URIs present a risk to the
        stability of deployed BPv7 networks.  If either type of ipn URI is
        allowed to propagate beyond the domain in which they are valid, then
        the required uniqueness of ipn URIs no longer holds, and this fact can
        be abused by a malicious node to prevent the correct functioning of
        the network as a whole.</t>
        <t indent="0" pn="section-8.4-2">See Sections <xref target="localnode-ipn-eids" format="counter" sectionFormat="of" derivedContent="5.4"/> and
        <xref target="private-use-ipn-eids" format="counter" sectionFormat="of" derivedContent="5.5"/> for
        required behaviors to mitigate against this form of abuse.</t>
      </section>
      <section anchor="sensitive-information" numbered="true" removeInRFC="false" toc="include" pn="section-8.5">
        <name slugifiedName="name-sensitive-information">Sensitive Information</name>
        <t indent="0" pn="section-8.5-1">Because ipn URIs are used only to represent the numeric identities
        of resources, the risk of disclosure of sensitive information due to
        interception of these URIs is minimal. Examination of ipn URIs could
        be used to support traffic analysis; where traffic analysis is a
        plausible danger, bundles should be conveyed by secure
        convergence-layer protocols that do not expose endpoint IDs, such as
        TCPCLv4 <xref target="RFC9174" format="default" sectionFormat="of" derivedContent="RFC9174"/>.</t>
      </section>
      <section anchor="semantic-attacks" numbered="true" removeInRFC="false" toc="include" pn="section-8.6">
        <name slugifiedName="name-semantic-attacks">Semantic Attacks</name>
        <t indent="0" pn="section-8.6-1">The simplicity of the 'ipn' URI scheme syntax minimizes the possibility
        of misinterpretation of a URI by a human user.</t>
      </section>
    </section>
    <section anchor="iana" numbered="true" removeInRFC="false" toc="include" pn="section-9">
      <name slugifiedName="name-iana-considerations">IANA Considerations</name>
      <t indent="0" pn="section-9-1">The following sections detail the creation of
      two new IANA registries and the renaming of an existing IANA registry under the "Uniform Resource Identifier (URI) Schemes" registry group.</t>
      <t indent="0" pn="section-9-2">IANA has also updated the reference for the 'ipn' scheme to this document in the
      "Uniform Resource Identifier (URI) Schemes" registry.</t>
      <section anchor="iana-allocator-identifiers" numbered="true" removeInRFC="false" toc="include" pn="section-9.1">
        <name slugifiedName="name-ipn-scheme-uri-allocator-id">'ipn' Scheme URI Allocator Identifiers Registry</name>
        <t indent="0" pn="section-9.1-1">IANA has created a new registry titled "'ipn' Scheme
        URI Allocator Identifiers".  Using terms defined in <xref target="RFC8126" format="default" sectionFormat="of" derivedContent="RFC8126"/>, the registration procedures for this registry are:</t>
        <table align="center" anchor="tab-ipn-allocator-identifiers-reg" pn="table-2">
          <name slugifiedName="name-registration-procedures-for">Registration Procedures for the 'ipn' Scheme URI Allocator Identifiers Registry</name>
          <thead>
            <tr>
              <th align="left" colspan="1" rowspan="1">Range</th>
              <th align="left" colspan="1" rowspan="1">Registration Procedures</th>
              <th align="left" colspan="1" rowspan="1">Note</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left" colspan="1" rowspan="1">0..0xFFFF</td>
              <td align="left" colspan="1" rowspan="1">Expert Review</td>
              <td align="left" colspan="1" rowspan="1">Single Allocator Identifiers only</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">0x10000..0x3FFFFFFF</td>
              <td align="left" colspan="1" rowspan="1">Expert Review</td>
              <td align="left" colspan="1" rowspan="1"/>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">0x40000000..0x7FFFFFFF</td>
              <td align="left" colspan="1" rowspan="1">Experimental Use</td>
              <td align="left" colspan="1" rowspan="1"/>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">0x80000000..0xFFFFFFFF</td>
              <td align="left" colspan="1" rowspan="1">Reserved</td>
              <td align="left" colspan="1" rowspan="1"> Future Expansion</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">&gt;=0x100000000</td>
              <td align="left" colspan="1" rowspan="1">Reserved</td>
              <td align="left" colspan="1" rowspan="1"/>
            </tr>
          </tbody>
        </table>
        <t indent="0" pn="section-9.1-3">Each entry in this registry associates one or more Allocator
        Identifiers with a single organization. Within the registry, the
        organization is identified using the "Name" and "Change Controller"
        fields. It is expected that each identified organization will publish
        some listing of allocated Node Numbers, the pointer to which is
        listed in the "Reference" field of the registry.</t>
        <t indent="0" pn="section-9.1-4">Note that the "Single Allocator Identifiers only" language in
        the registration procedure for this registry indicates that, within the
        indicated range, the allocation of a sequence of consecutive Allocator
        Identifiers to a single organization is prohibited.</t>
        <t indent="0" pn="section-9.1-5">The initial values in the registry are:</t>
        <table align="center" anchor="tab-ipn-allocator-identifiers-vals" pn="table-3">
          <name slugifiedName="name-initial-values-in-the-ipn-s">Initial Values in the 'ipn' Scheme URI Allocator Identifiers Registry</name>
          <thead>
            <tr>
              <th align="left" colspan="1" rowspan="1">Name</th>
              <th align="left" colspan="1" rowspan="1">Range (dec)</th>
              <th align="left" colspan="1" rowspan="1">Range (hex)</th>
              <th align="left" colspan="1" rowspan="1">Range Length (Bits)</th>
              <th align="left" colspan="1" rowspan="1">Reference</th>
              <th align="left" colspan="1" rowspan="1">Change Controller</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left" colspan="1" rowspan="1">Default Allocator</td>
              <td align="left" colspan="1" rowspan="1">0</td>
              <td align="left" colspan="1" rowspan="1">0x0</td>
              <td align="left" colspan="1" rowspan="1">0</td>
              <td align="left" colspan="1" rowspan="1">RFC 9758, <xref target="default-allocator" format="default" sectionFormat="of" derivedContent="Section 3.2.2"/></td>
              <td align="left" colspan="1" rowspan="1">IETF</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">Example Range</td>
              <td align="left" colspan="1" rowspan="1">974848-978943</td>
              <td align="left" colspan="1" rowspan="1">0xEE000-0xEEFFF</td>
              <td align="left" colspan="1" rowspan="1">12 bits</td>
              <td align="left" colspan="1" rowspan="1">RFC 9758</td>
              <td align="left" colspan="1" rowspan="1">IETF</td>
            </tr>
          </tbody>
        </table>
        <t indent="0" pn="section-9.1-7">The "Example Range" is assigned for use in examples in
        documentation and sample code.</t>
        <section anchor="guidance-for-designated-experts" numbered="true" removeInRFC="false" toc="include" pn="section-9.1.1">
          <name slugifiedName="name-guidance-for-designated-exp">Guidance for Designated Experts</name>
          <t indent="0" pn="section-9.1.1-1">Due to the nature of the CBOR encoding of unsigned integers used
          for Allocator Identifiers with BPv7, Allocator Identifiers with a
          low value number are encoded more efficiently than larger numbers.
          This makes low value Allocator Identifiers more desirable than
          larger Allocator Identifiers; therefore, care must be taken when
          assigning Allocator Identifier ranges to ensure that a single
          applicant is not granted a large swathe of highly desirable numbers
          at the expense of other applicants.  To this end, designated experts
          are strongly recommended to familiarize themselves with the CBOR
          encoding of unsigned integers in <xref target="RFC8949" format="default" sectionFormat="of" derivedContent="RFC8949"/>.</t>
        </section>
      </section>
      <section anchor="iana-node-numbers" numbered="true" removeInRFC="false" toc="include" pn="section-9.2">
        <name slugifiedName="name-ipn-scheme-uri-default-allo">'ipn' Scheme URI Default Allocator Node Numbers Registry</name>
        <t indent="0" pn="section-9.2-1">IANA has renamed the "CBHE Node Numbers" registry
        (defined in <xref section="3.2.1" sectionFormat="of" target="RFC7116" format="default" derivedLink="https://rfc-editor.org/rfc/rfc7116#section-3.2.1" derivedContent="RFC7116"/>)
        to the "'ipn' Scheme URI Default Allocator Node Numbers" registry and moved it to the "Uniform Resource Identifier (URI) Schemes" registry group. IANA has added the following note to the "CBHE Node Numbers" registry:</t>
        <blockquote pn="section-9.2-2">
Note: Renamed "CBHE Node Numbers" as "'ipn' Scheme URI Default Allocator Node Numbers" and moved it to &lt;<eref target="https://www.iana.org/assignments/uri-schemes" brackets="none"/>&gt; per RFC 9758.
</blockquote>
        <t indent="0" pn="section-9.2-3">Using terms defined in <xref target="RFC8126" format="default" sectionFormat="of" derivedContent="RFC8126"/>, the registration procedures for this registry are:</t>
        <table align="center" anchor="tab-ipn-node-numbers-reg" pn="table-4">
          <name slugifiedName="name-registration-procedures-for-">Registration Procedures for the 'ipn' Scheme URI Default Allocator Node Numbers Registry</name>
          <thead>
            <tr>
              <th align="left" colspan="1" rowspan="1">Range</th>
              <th align="left" colspan="1" rowspan="1">Registration Procedures</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left" colspan="1" rowspan="1">1..0x3FFF</td>
              <td align="left" colspan="1" rowspan="1">Private Use</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">0x4000..0xFFFFFFFE</td>
              <td align="left" colspan="1" rowspan="1">Expert Review</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">&gt;=0x100000000</td>
              <td align="left" colspan="1" rowspan="1">Invalid</td>
            </tr>
          </tbody>
        </table>
        <t indent="0" pn="section-9.2-5">IANA has registered the following values in the "'ipn' Scheme URI Default Allocator Node Numbers" registry:</t>
        <table align="center" anchor="tab-ipn-scheme-uri-DA-identifiers" pn="table-5">
          <name slugifiedName="name-new-values-in-the-ipn-schem">New Values in the 'ipn' Scheme URI Default Allocator Node Numbers Registry</name>
          <thead>
            <tr>
              <th align="left" colspan="1" rowspan="1">Value</th>
              <th align="left" colspan="1" rowspan="1">Description</th>
              <th align="left" colspan="1" rowspan="1">Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left" colspan="1" rowspan="1">0</td>
              <td align="left" colspan="1" rowspan="1">Reserved for the Null ipn URI</td>
              <td align="left" colspan="1" rowspan="1">
                <xref target="RFC7116" format="default" sectionFormat="of" derivedContent="RFC7116"/> and RFC 9758, <xref target="null-uri" format="default" sectionFormat="of" derivedContent="Section 3.1"/></td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">4294967295</td>
              <td align="left" colspan="1" rowspan="1">Reserved for LocalNode ipn URIs</td>
              <td align="left" colspan="1" rowspan="1">RFC 9758, <xref target="localnode-uri" format="default" sectionFormat="of" derivedContent="Section 3.4.2"/></td>
            </tr>
          </tbody>
        </table>
        <t indent="0" pn="section-9.2-7">As IANA has only renamed the registry, all existing
        registrations will remain.</t>
      </section>
      <section anchor="iana-service-numbers" numbered="true" removeInRFC="false" toc="include" pn="section-9.3">
        <name slugifiedName="name-ipn-scheme-uri-well-known-s">'ipn' Scheme URI Well-Known Service Numbers for BPv7 Registry</name>
        <t indent="0" pn="section-9.3-1">IANA has created a new registry titled "'ipn' Scheme
        URI Well-Known Service Numbers for BPv7".  Using terms defined in
        <xref target="RFC8126" format="default" sectionFormat="of" derivedContent="RFC8126"/>, the registration procedures for this registry are:</t>
        <table align="center" anchor="tab-ipn-service-numbers-reg" pn="table-6">
          <name slugifiedName="name-registration-procedures-for-t">Registration Procedures for the 'ipn' Scheme URI Well-Known Service Numbers for BPv7 Registry</name>
          <thead>
            <tr>
              <th align="left" colspan="1" rowspan="1">Range</th>
              <th align="left" colspan="1" rowspan="1">Registration Procedures</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left" colspan="1" rowspan="1">1..127</td>
              <td align="left" colspan="1" rowspan="1">Private Use</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">128..255</td>
              <td align="left" colspan="1" rowspan="1">Standards Action</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">0x0100..0x7FFF</td>
              <td align="left" colspan="1" rowspan="1">Private Use</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">0x8000..0xFFFF</td>
              <td align="left" colspan="1" rowspan="1">Specification Required</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">0x10000..0xFFFFFFFF</td>
              <td align="left" colspan="1" rowspan="1">Private Use</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">&gt;=0x100000000</td>
              <td align="left" colspan="1" rowspan="1">Reserved for future expansion</td>
            </tr>
          </tbody>
        </table>
        <t indent="0" pn="section-9.3-3">The initial values in the registry are:</t>
        <table align="center" anchor="tab-ipn-service-numbers-vals" pn="table-7">
          <name slugifiedName="name-initial-values-in-the-ipn-sc">Initial Values in the 'ipn' Scheme URI Well-Known Service Numbers for BPv7 Registry</name>
          <thead>
            <tr>
              <th align="left" colspan="1" rowspan="1">Value</th>
              <th align="left" colspan="1" rowspan="1">Description</th>
              <th align="left" colspan="1" rowspan="1">Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left" colspan="1" rowspan="1">0</td>
              <td align="left" colspan="1" rowspan="1">The Administrative Endpoint</td>
              <td align="left" colspan="1" rowspan="1">
                <xref target="RFC9171" format="default" sectionFormat="of" derivedContent="RFC9171"/> and RFC 9758, <xref target="administrative-endpoints" format="default" sectionFormat="of" derivedContent="Section 5.7"/></td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">0xEEE0..0xEEEF</td>
              <td align="left" colspan="1" rowspan="1">Example Range</td>
              <td align="left" colspan="1" rowspan="1">RFC 9758</td>
            </tr>
          </tbody>
        </table>
        <t indent="0" pn="section-9.3-5">The "Example Range" is assigned for use in examples in
        documentation and sample code.</t>
        <section anchor="guidance-for-designated-experts-1" numbered="true" removeInRFC="false" toc="include" pn="section-9.3.1">
          <name slugifiedName="name-guidance-for-designated-expe">Guidance for Designated Experts</name>
          <t indent="0" pn="section-9.3.1-1">This registry is intended to record the default Service Numbers
          for well-known, interoperable services that are available and of use to the
          entire BPv7 community; hence, all ranges not marked for Private Use
          <bcp14>MUST</bcp14> have a corresponding publicly available
          specification describing how one interfaces with the service.</t>
          <t indent="0" pn="section-9.3.1-2">Services that are specific to a particular deployment or
          co-operation may require a registry to reduce administrative burden,
          but do not require an entry in this registry.</t>
        </section>
      </section>
    </section>
  </middle>
  <back>
    <references pn="section-10">
      <name slugifiedName="name-references">References</name>
      <references anchor="sec-normative-references" pn="section-10.1">
        <name slugifiedName="name-normative-references">Normative References</name>
        <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119" quoteTitle="true" derivedAnchor="RFC2119">
          <front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <author fullname="S. Bradner" initials="S." surname="Bradner"/>
            <date month="March" year="1997"/>
            <abstract>
              <t indent="0">In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. 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="14"/>
          <seriesInfo name="RFC" value="2119"/>
          <seriesInfo name="DOI" value="10.17487/RFC2119"/>
        </reference>
        <reference anchor="RFC5234" target="https://www.rfc-editor.org/info/rfc5234" quoteTitle="true" derivedAnchor="RFC5234">
          <front>
            <title>Augmented BNF for Syntax Specifications: ABNF</title>
            <author fullname="D. Crocker" initials="D." role="editor" surname="Crocker"/>
            <author fullname="P. Overell" initials="P." surname="Overell"/>
            <date month="January" year="2008"/>
            <abstract>
              <t indent="0">Internet technical specifications often need to define a formal syntax. Over the years, a modified version of Backus-Naur Form (BNF), called Augmented BNF (ABNF), has been popular among many Internet specifications. The current specification documents ABNF. It balances compactness and simplicity with reasonable representational power. The differences between standard BNF and ABNF involve naming rules, repetition, alternatives, order-independence, and value ranges. This specification also supplies additional rule definitions and encoding for a core lexical analyzer of the type common to several Internet specifications. [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="RFC6260" target="https://www.rfc-editor.org/info/rfc6260" quoteTitle="true" derivedAnchor="RFC6260">
          <front>
            <title>Compressed Bundle Header Encoding (CBHE)</title>
            <author fullname="S. Burleigh" initials="S." surname="Burleigh"/>
            <date month="May" year="2011"/>
            <abstract>
              <t indent="0">This document describes a convention by which Delay-Tolerant Networking (DTN) Bundle Protocol (BP) "convergence-layer" adapters may represent endpoint identifiers in a compressed form within the primary blocks of bundles, provided those endpoint identifiers conform to the structure prescribed by this convention.</t>
              <t indent="0">Compressed Bundle Header Encoding (CBHE) compression is a convergence-layer adaptation. It is opaque to bundle processing. Therefore, it has no impact on the interoperability of different Bundle Protocol implementations, but instead affects only the interoperability of different convergence-layer adaptation implementations.</t>
              <t indent="0">This document is a product of the Delay-Tolerant Networking Research Group and has been reviewed by that group. No objections to its publication 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" target="https://www.rfc-editor.org/info/rfc7116" quoteTitle="true" derivedAnchor="RFC7116">
          <front>
            <title>Licklider Transmission Protocol (LTP), Compressed Bundle Header 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 indent="0">The DTNRG Research Group has defined the experimental Licklider Transmission Protocol (LTP) and the Compressed Bundle Header Encoding (CBHE) mechanism for the InterPlanetary Network ('ipn' URI scheme). Moreover, RFC 5050 defines values for the Bundle Protocol administrative record type. All of these fields 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 multiple interoperable implementations, the group would like to hand off the registries to IANA for official management. This document describes the necessary IANA actions.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7116"/>
          <seriesInfo name="DOI" value="10.17487/RFC7116"/>
        </reference>
        <reference anchor="RFC8126" target="https://www.rfc-editor.org/info/rfc8126" quoteTitle="true" derivedAnchor="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 indent="0">Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA).</t>
              <t indent="0">To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when 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 Considerations is clear and addresses the various issues that are likely in the operation of a registry.</t>
              <t indent="0">This is the third edition of this document; it obsoletes RFC 5226.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="26"/>
          <seriesInfo name="RFC" value="8126"/>
          <seriesInfo name="DOI" value="10.17487/RFC8126"/>
        </reference>
        <reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8174" quoteTitle="true" derivedAnchor="RFC8174">
          <front>
            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <author fullname="B. Leiba" initials="B." surname="Leiba"/>
            <date month="May" year="2017"/>
            <abstract>
              <t indent="0">RFC 2119 specifies common key words that may be used in protocol 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="RFC8610" target="https://www.rfc-editor.org/info/rfc8610" quoteTitle="true" derivedAnchor="RFC8610">
          <front>
            <title>Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures</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 indent="0">This document proposes a notational convention to express Concise Binary Object Representation (CBOR) data structures (RFC 7049). Its main goal is to provide an easy and unambiguous way to express structures for protocol messages and data formats that use CBOR or JSON.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8610"/>
          <seriesInfo name="DOI" value="10.17487/RFC8610"/>
        </reference>
        <reference anchor="RFC8949" target="https://www.rfc-editor.org/info/rfc8949" quoteTitle="true" derivedAnchor="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 indent="0">The Concise Binary Object Representation (CBOR) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. These design goals make it different from earlier binary serializations such as ASN.1 and MessagePack.</t>
              <t indent="0">This document obsoletes RFC 7049, providing editorial improvements, new details, and errata fixes while keeping full compatibility with the interchange 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="RFC9171" target="https://www.rfc-editor.org/info/rfc9171" quoteTitle="true" derivedAnchor="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, III"/>
            <date month="January" year="2022"/>
            <abstract>
              <t indent="0">This document presents a specification for the Bundle Protocol, adapted from the experimental Bundle Protocol specification developed by the Delay-Tolerant Networking Research Group of the Internet Research Task Force and documented in RFC 5050.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9171"/>
          <seriesInfo name="DOI" value="10.17487/RFC9171"/>
        </reference>
      </references>
      <references anchor="sec-informative-references" pn="section-10.2">
        <name slugifiedName="name-informative-references">Informative References</name>
        <reference anchor="RFC1918" target="https://www.rfc-editor.org/info/rfc1918" quoteTitle="true" derivedAnchor="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 indent="0">This document describes address allocation for private internets. 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="5"/>
          <seriesInfo name="RFC" value="1918"/>
          <seriesInfo name="DOI" value="10.17487/RFC1918"/>
        </reference>
        <reference anchor="RFC3986" target="https://www.rfc-editor.org/info/rfc3986" quoteTitle="true" derivedAnchor="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 indent="0">A Uniform Resource Identifier (URI) is a compact sequence of characters that identifies an abstract or physical resource. This specification defines the generic URI syntax and a process for resolving URI references that might be in relative form, along with guidelines and security considerations for the use of URIs on the Internet. The URI syntax defines a grammar that is a superset of all valid URIs, allowing an implementation to parse the common components of a URI reference without knowing the scheme-specific requirements of every possible identifier. This specification does not define a generative grammar for URIs; 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="RFC4632" target="https://www.rfc-editor.org/info/rfc4632" quoteTitle="true" derivedAnchor="RFC4632">
          <front>
            <title>Classless Inter-domain Routing (CIDR): The Internet Address Assignment 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 indent="0">This memo discusses the strategy for address assignment of the existing 32-bit IPv4 address space with a view toward conserving the address space and limiting the growth rate of global routing state. This document obsoletes the original Classless Inter-domain Routing (CIDR) spec in RFC 1519, with changes made both to clarify the concepts it introduced and, after more than twelve years, to update the Internet community on the results of deploying the technology 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="RFC5050" target="https://www.rfc-editor.org/info/rfc5050" quoteTitle="true" derivedAnchor="RFC5050">
          <front>
            <title>Bundle Protocol Specification</title>
            <author fullname="K. Scott" initials="K." surname="Scott"/>
            <author fullname="S. Burleigh" initials="S." surname="Burleigh"/>
            <date month="November" year="2007"/>
            <abstract>
              <t indent="0">This document describes the end-to-end protocol, block formats, and abstract service description for the exchange of messages (bundles) in Delay Tolerant Networking (DTN).</t>
              <t indent="0">This document was produced within the IRTF's Delay Tolerant Networking Research Group (DTNRG) and represents the consensus of all of the active 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="RFC9172" target="https://www.rfc-editor.org/info/rfc9172" quoteTitle="true" derivedAnchor="RFC9172">
          <front>
            <title>Bundle Protocol Security (BPSec)</title>
            <author fullname="E. Birrane, III" initials="E." surname="Birrane, III"/>
            <author fullname="K. McKeever" initials="K." surname="McKeever"/>
            <date month="January" year="2022"/>
            <abstract>
              <t indent="0">This document defines a security protocol providing data integrity 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" target="https://www.rfc-editor.org/info/rfc9174" quoteTitle="true" derivedAnchor="RFC9174">
          <front>
            <title>Delay-Tolerant Networking TCP Convergence-Layer Protocol Version 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 indent="0">This document describes a TCP convergence layer (TCPCL) for Delay-Tolerant Networking (DTN). This version of the TCPCL protocol resolves implementation issues in the earlier TCPCL version 3 as defined in RFC 7242 and provides updates to the Bundle Protocol (BP) contents, encodings, and convergence-layer requirements in BP version 7 (BPv7). Specifically, TCPCLv4 uses BPv7 bundles encoded by the Concise Binary Object Representation (CBOR) as its service data unit being transported and provides a reliable transport of such bundles. This TCPCL 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>
    <section anchor="text-examples" numbered="true" removeInRFC="false" toc="include" pn="section-appendix.a">
      <name slugifiedName="name-ipn-uri-scheme-text-represe">'ipn' URI Scheme Text Representation Examples</name>
      <t indent="0" pn="section-appendix.a-1">This section provides some example ipn URIs in their textual representation.</t>
      <section anchor="using-the-default-allocator" numbered="true" removeInRFC="false" toc="include" pn="section-appendix.a.1">
        <name slugifiedName="name-using-the-default-allocator">Using the Default Allocator</name>
        <t indent="0" pn="section-appendix.a.1-1">Consider the ipn URI identifying Service Number 2 on Node Number 1
        allocated by the Default Allocator (0) (<xref target="default-allocator" format="default" sectionFormat="of" derivedContent="Section 3.2.2"/>).</t>
        <t indent="0" pn="section-appendix.a.1-2">The recommended seven-character representation of this URI would be
        as follows:</t>
        <artwork align="left" pn="section-appendix.a.1-3">
ipn:1.2
</artwork>
        <t indent="0" pn="section-appendix.a.1-4">The nine-character representation of this URI, with the explicit Allocator Identifier, would be as follows:</t>
        <artwork align="left" pn="section-appendix.a.1-5">
ipn:0.1.2
</artwork>
      </section>
      <section anchor="using-a-non-default-allocator" numbered="true" removeInRFC="false" toc="include" pn="section-appendix.a.2">
        <name slugifiedName="name-using-a-non-default-allocat">Using a Non-Default Allocator</name>
        <t indent="0" pn="section-appendix.a.2-1">Consider the ipn URI identifying Service Number 3 on Node Number 1 allocated by Allocator 977000.</t>
        <t indent="0" pn="section-appendix.a.2-2">The 14-character representation of this URI would be as follows:</t>
        <artwork align="left" pn="section-appendix.a.2-3">
ipn:977000.1.3
</artwork>
      </section>
      <section anchor="the-null-ipn-uri" numbered="true" removeInRFC="false" toc="include" pn="section-appendix.a.3">
        <name slugifiedName="name-the-null-ipn-uri-2">The Null ipn URI</name>
        <t indent="0" pn="section-appendix.a.3-1">The Null ipn URI (<xref target="null-uri" format="default" sectionFormat="of" derivedContent="Section 3.1"/>) is represented as:</t>
        <artwork align="left" pn="section-appendix.a.3-2">
ipn:0.0
</artwork>
      </section>
      <section anchor="a-localnode-ipn-uri" numbered="true" removeInRFC="false" toc="include" pn="section-appendix.a.4">
        <name slugifiedName="name-the-localnode-ipn-uri">The LocalNode ipn URI</name>
        <t indent="0" pn="section-appendix.a.4-1">Consider the ipn URI identifying Service Number 7 on the local
        node.</t>
        <t indent="0" pn="section-appendix.a.4-2">The recommended seven-character representation of this URI would be
        as follows:</t>
        <artwork align="left" pn="section-appendix.a.4-3">
ipn:!.7
</artwork>
        <t indent="0" pn="section-appendix.a.4-4">The numeric 16-character representation of this URI would be as follows:</t>
        <artwork align="left" pn="section-appendix.a.4-5">
ipn:4294967295.7
</artwork>
      </section>
    </section>
    <section anchor="cbor-examples" numbered="true" removeInRFC="false" toc="include" pn="section-appendix.b">
      <name slugifiedName="name-ipn-uri-scheme-cbor-encodin">'ipn' URI Scheme CBOR Encoding Examples</name>
      <t indent="0" pn="section-appendix.b-1">This section provides some example CBOR encodings of ipn EIDs.</t>
      <section anchor="using-the-default-allocator-1" numbered="true" removeInRFC="false" toc="include" pn="section-appendix.b.1">
        <name slugifiedName="name-using-the-default-allocator-2">Using the Default Allocator</name>
        <t indent="0" pn="section-appendix.b.1-1">Consider the ipn EID <tt>ipn:1.1</tt>. This textual representation
        of an ipn EID identifies Service Number 1 on Node Number 1 allocated
        by the Default Allocator (0) (<xref target="default-allocator" format="default" sectionFormat="of" derivedContent="Section 3.2.2"/>).
        </t>
        <t indent="0" pn="section-appendix.b.1-2">The recommended five-octet encoding of this EID using the
        two-element scheme-specific encoding would be as follows:</t>
        <sourcecode type="cbor" markers="false" pn="section-appendix.b.1-3">
82       # 2-Element Endpoint Encoding
   02    # uri-code: 2 ('ipn' URI scheme)
   82    # 2-Element ipn EID encoding
      01 # Node Number
      01 # Service Number
</sourcecode>
        <t indent="0" pn="section-appendix.b.1-4">The six-octet encoding of this EID using the three-element
        scheme-specific encoding would be as follows:</t>
        <sourcecode type="cbor" markers="false" pn="section-appendix.b.1-5">
82       # 2-Element Endpoint Encoding
   02    # uri-code: 2 ('ipn' URI scheme)
   83    # 3-Element ipn EID encoding
      00 # Default Allocator
      01 # Node Number
      01 # Service Number
</sourcecode>
      </section>
      <section anchor="using-a-non-default-allocator-1" numbered="true" removeInRFC="false" toc="include" pn="section-appendix.b.2">
        <name slugifiedName="name-using-a-non-default-allocato">Using a Non-Default Allocator</name>
        <t indent="0" pn="section-appendix.b.2-1">Consider the ipn EID <tt>ipn:977000.1.1</tt>.  This textual
        representation of an ipn EID identifies Service Number 1 on Node
        Number 1 allocated by Allocator 977000.</t>
        <t indent="0" pn="section-appendix.b.2-2">The recommended 10-octet encoding of this EID using the
        three-element scheme-specific encoding would be as follows:</t>
        <sourcecode type="cbor" markers="false" pn="section-appendix.b.2-3">
82                # 2-Element Endpoint Encoding
   02             # uri-code: 2 ('ipn' URI scheme)
   83             # 3-Element ipn EID encoding
      1A 000EE868 # Allocator Identifier
      01          # Node Number
      01          # Service Number
</sourcecode>
        <t indent="0" pn="section-appendix.b.2-4">The 13-octet encoding of this EID using the two-element
        scheme-specific encoding would be as follows:</t>
        <sourcecode type="cbor" markers="false" pn="section-appendix.b.2-5">
82                        # 2-Element Endpoint Encoding
   02                     # uri-code: 2 ('ipn' URI scheme)
   82                     # 2-Element ipn EID encoding
      1B 000EE86800000001 # Fully Qualified Node Number
      01                  # Service Number
</sourcecode>
      </section>
      <section anchor="the-null-endpoint-1" numbered="true" removeInRFC="false" toc="include" pn="section-appendix.b.3">
        <name slugifiedName="name-the-null-endpoint-2">The Null Endpoint</name>
        <t indent="0" pn="section-appendix.b.3-1">The Null EID of <tt>ipn:0.0</tt> can be encoded in the following
        ways:</t>
        <t indent="0" pn="section-appendix.b.3-2">The recommended five-octet encoding of the Null ipn EID using the
        two-element scheme-specific encoding would be as follows:</t>
        <sourcecode type="cbor" markers="false" pn="section-appendix.b.3-3">
82       # 2-Element Endpoint Encoding
   02    # uri-code: 2 ('ipn' URI scheme)
   82    # 2-Element ipn EID encoding
      00 # Node Number
      00 # Service Number
</sourcecode>
        <t indent="0" pn="section-appendix.b.3-4">The six-octet encoding of the Null ipn EID using the
        three-element scheme-specific encoding would be as follows:</t>
        <sourcecode type="cbor" markers="false" pn="section-appendix.b.3-5">
82       # 2-Element Endpoint Encoding
   02    # uri-code: 2 ('ipn' URI scheme)
   83    # 3-Element ipn EID encoding
      00 # Default Allocator
      00 # Node Number
      00 # Service Number
</sourcecode>
      </section>
    </section>
    <section numbered="false" anchor="acknowledgments" removeInRFC="false" toc="include" pn="section-appendix.c">
      <name slugifiedName="name-acknowledgments">Acknowledgments</name>
      <t indent="0" pn="section-appendix.c-1">The following DTN Working Group participants contributed technical material, use
      cases, and critical technical reviews for this URI scheme update:
      <contact fullname="Scott Burleigh"/> of the IPNGROUP, <contact fullname="Keith Scott"/>, <contact fullname="Brian Sipos"/> of the Johns
      Hopkins University Applied Physics Laboratory, <contact fullname="Jorge       Amodio"/> of LJCV Electronics, and <contact fullname="Ran       Atkinson"/>.</t>
      <t indent="0" pn="section-appendix.c-2">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 anchor="authors-addresses" numbered="false" removeInRFC="false" toc="include" pn="section-appendix.d">
      <name slugifiedName="name-authors-addresses">Authors' Addresses</name>
      <author fullname="Rick Taylor">
        <organization showOnFrontPage="true">Aalyria Technologies</organization>
        <address>
          <email>rtaylor@aalyria.com</email>
        </address>
      </author>
      <author initials="E." surname="Birrane, III" fullname="Edward J. Birrane, III">
        <organization abbrev="JHU/APL" showOnFrontPage="true">The Johns Hopkins University Applied Physics Laboratory</organization>
        <address>
          <email>Edward.Birrane@jhuapl.edu</email>
        </address>
      </author>
    </section>
  </back>
</rfc>
