<?xml version='1.0' encoding='utf-8'?> version="1.0" encoding="UTF-8"?>

<!-- [CS] updated by Chris 04/13/21 -->

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- <!ENTITY I-D.ietf-dtn-bpsec SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.draft-ietf-dtn-bpsec.xml"> -->
<!ENTITY I-D.ietf-dtn-bpsec SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-dtn-bpsec.xml">
<!ENTITY RFC2119 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC4960 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4960.xml">
<!ENTITY RFC5234 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5234.xml">
<!ENTITY RFC8174 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml">
<!ENTITY RFC8949 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8949.xml">
<!-- <!ENTITY I-D.ietf-dtn-tcpclv4 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.draft-ietf-dtn-tcpclv4.xml"> -->
<!ENTITY I-D.ietf-dtn-tcpclv4 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-dtn-tcpclv4.xml">
<!ENTITY RFC3986 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3986.xml">
<!ENTITY RFC7595 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7595.xml">
<!-- <!ENTITY I-D.ietf-dtn-bibect SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.draft-ietf-dtn-bibect.xml"> -->
 <!ENTITY I-D.ietf-dtn-bibect SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-dtn-bibect.xml"> nbsp    "&#160;">
 <!ENTITY RFC3987 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3987.xml"> zwsp   "&#8203;">
 <!ENTITY RFC5050 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5050.xml"> nbhy   "&#8209;">
 <!ENTITY RFC6255 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6255.xml">
<!ENTITY RFC6257 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6257.xml">
<!ENTITY RFC6258 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6258.xml">
<!ENTITY RFC6259 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6259.xml">
<!ENTITY RFC6260 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6260.xml">
<!ENTITY RFC7143 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7143.xml"> wj     "&#8288;">
]>

<rfc submissionType="IETF" xmlns:xi="http://www.w3.org/2001/XInclude" docName="draft-ietf-dtn-bpbis-31" number="9171"
submissionType="IETF" category="std" ipr="trust200902"> consensus="true" ipr="trust200902" obsoletes="" updates="" xml:lang="en" symRefs="true" sortRefs="true" tocInclude="true" tocDepth="5" version="3">

  <!-- xml2rfc v2v3 conversion 3.7.0 -->
  <!-- Generated by id2xml 1.5.0 on 2021-04-05T23:37:33Z -->
	<?rfc strict="yes"?>
	<?rfc compact="yes"?>
	<?rfc subcompact="no"?>
	<?rfc symrefs="yes"?>
	<?rfc sortrefs="yes"?>
	<?rfc text-list-symbols="*o+-"?>
	<?rfc toc="yes"?>
	<?rfc tocDepth="5"?>
        <front>
    <title>Bundle Protocol Version 7</title>
    <seriesInfo name="RFC" value="9171"/>
    <author initials="S." surname="Burleigh" fullname="Scott Burleigh">
	<organization abbrev="JPL, Calif. Inst. Of Technology">Jet Propulsion Laboratory, California Institute of Technology</organization>
	<address><postal><street>4800 Oak Grove Dr.</street>
	<city>Pasadena</city><region>CA</region><code>91109-8099</code>
      <organization>IPNGROUP</organization>
      <address>
        <postal>
          <street>1435 Woodhurst Blvd.</street>
          <city>McLean</city>
          <region>VA</region>
          <code>22102</code>
          <country>United States of America</country>
        </postal>
	<phone>+1 818 393 3353</phone>
	<email>Scott.C.Burleigh@jpl.nasa.gov</email>
        <email>sburleig.sb@gmail.com</email>
      </address>
    </author>
    <author initials="K." surname="Fall" fullname="Kevin Fall">
      <organization>Roland Computing Services</organization>
	<address><postal><street>3871
      <address>
        <postal>
          <street>3871 Piedmont Ave. Suite 8</street>
	<city>Oakland</city><region>CA</region><code>94611</code>
          <city>Oakland</city>
          <region>CA</region>
          <code>94611</code>
          <country>United States of America</country>
        </postal>
        <email>kfall+rcs@kfall.com</email>
      </address>
    </author>
    <author initials="E." surname="Birrane" surname="Birrane, III" fullname="Edward J. Birrane"> Birrane, III">
      <organization abbrev="APL, Johns Hopkins University">Johns Hopkins University Applied Physics Laboratory</organization>
	<address><postal><street>11100
      <address>
        <postal>
          <street>11100 Johns Hopkins Rd</street>
	<city>Laurel</city><region>MD</region><code>20723</code>
          <city>Laurel</city>
          <region>MD</region>
          <code>20723</code>
          <country>United States of America</country>
        </postal>
        <phone>+1 443 778 7423</phone>
        <email>Edward.Birrane@jhuapl.edu

<!-- draft-ietf-dtn-bpbis-31-manual.txt(3160): Warning: This author is listed in the
   Authors' Addresses section, but was not found  on the first page: US
   --></email>
        </email>
      </address>
    </author>
    <date year="2021" month="April"/> year="2022" month="January"/>
    <workgroup>Networking Working Group</workgroup>

<!-- [rfced] Please insert any keywords (beyond those that appear in
the title) for use on https://www.rfc-editor.org/search. -->

<keyword>example</keyword>

	<abstract><t>

<keyword>Delay-tolerant networking</keyword>
<keyword>disruption-tolerant networking</keyword>

    <abstract>
      <t>
   This Internet Draft document presents a specification for the Bundle
   Protocol, adapted from the experimental Bundle Protocol
   specification developed by the Delay-Tolerant Networking Research
   group
   Group of the Internet Research Task Force and documented in RFC
   5050.</t>
   5050.

</t>
    </abstract>
  </front>
  <middle>
    <section title="Introduction" anchor="sect-1"><t> anchor="sect-1" numbered="true" toc="default">
      <name>Introduction</name>
      <t>
   Since the publication of the Bundle Protocol Specification specification
   (Experimental RFC 5050 <xref target="RFC5050"/>) target="RFC5050" format="default"/>) in 2007, the Delay-Tolerant
   Networking (DTN) Bundle Protocol (BP) has been implemented in multiple
   programming languages and deployed to a wide variety of computing
   platforms.  This implementation and deployment experience has
   identified opportunities for making the protocol simpler, more
   capable, and easier to use.  The present document, standardizing the
   Bundle Protocol (BP), Protocol, is adapted from RFC 5050 in that context,
   reflecting lessons learned.  Significant changes from the Bundle
   Protocol specification defined in RFC 5050 are listed in section 13.</t> <xref target="app-a"/>.</t>
      <t>
   This document describes BP version 7 of BP.</t> (BPv7).</t>
      <t>
   Delay Tolerant
   Delay-Tolerant Networking is a network architecture providing
   communications in and/or through highly stressed environments.
   Stressed networking environments include those with intermittent
   connectivity, large and/or variable delays, and high bit error
   rates.  To provide its services, BP may be viewed as sitting at the
   application layer of some number of constituent networks, forming a
   store-carry-forward overlay network.  Key capabilities of BP
   include:

   <list style="symbols">

   	<t>Ability

      </t>
      <ul spacing="normal">
        <li>Ability to use physical motility for the movement of data</t>

	<t>Ability data.</li>
        <li>Ability to move the responsibility for error control from one
            node to another</t>

	<t>Ability another.</li>
        <li>Ability to cope with intermittent connectivity, including cases
           where the sender and receiver are not concurrently present in
           the network</t>

	<t>Ability network.</li>
        <li>Ability to take advantage of scheduled, predicted, and
           opportunistic connectivity, whether bidirectional or
           unidirectional, in addition to continuous connectivity</t>

	<t>Late connectivity.</li>
        <li>Late binding of overlay network overlay-network endpoint identifiers to
           underlying constituent network addresses</t>

	</list>
	</t> addresses.</li>
      </ul>
      <t>
   For descriptions of these capabilities and the rationale for the DTN
   architecture, see [ARCH] <xref target="RFC4838"/> and [SIGC].</t> <xref target="SIGC"/>.</t>
      <t>
   BP's location within the standard protocol stack is as shown in Figure 1. <xref target="fig-1"/>.
   BP uses underlying "native" "integrated" transport and/or network protocols for
   communications within a given constituent network.  The layer at which
   those underlying protocols are located is here termed the "convergence
   layer"
   layer", and the interface between the bundle protocol Bundle Protocol and a specific
   underlying protocol is termed a "convergence layer "convergence-layer adapter".</t>
      <t>
   Figure 1
   <xref target="fig-1"/> shows three distinct transport and network protocols
   (denoted T1/N1, T2/N2, and T3/N3).</t>
      <figure title="The anchor="fig-1">
        <name>The Bundle Protocol in the Protocol Stack Model" anchor="fig-1"><artwork><![CDATA[ Model</name>
        <artwork name="" type="ascii-art" align="left" alt=""><![CDATA[
+-----------+                                         +-----------+
|   BP app  |                                         |   BP app  |
+---------v-|   +->>>>>>>>>>v-+     +->>>>>>>>>>v-+   +-^---------+
|   BP    v |   | ^    BP   v |     | ^   BP    v |   | ^   BP    |
+---------v-+   +-^---------v-+     +-^---------v-+   +-^---------+
| T1      v |   + ^  T1/T2  v |     + ^  T2/T3  v |   | ^ T3      |
+---------v-+   +-^---------v-+     +-^---------v +   +-^---------+
| N1      v |   | ^  N1/N2  v |     | ^  N2/N3  v |   | ^ N3      |
+---------v-+   +-^---------v +     +-^---------v-+   +-^---------+
|         >>>>>>>>^         >>>>>>>>>>^         >>>>>>>>^         |
+-----------+   +-------------+     +-------------+   +-----------+
|                     |                     |                     |
|<---- A network ---->|                     |<---- A network ---->|
|                     |                     |                     |
]]></artwork>
      </figure>
      <t>
   This document describes the format of the protocol data units (PDUs)
   (called "bundles") passed between entities participating in BP
   communications.</t>
      <t>
   The entities are referred to as "bundle nodes". This document does
   not address:

   <list style="symbols">

	<t>Operations

      </t>
      <ul spacing="normal">
        <li>Operations in the convergence layer convergence-layer adapters that bundle nodes use
        to transport data through specific types of internets.  (However, the
        document does discuss the services that must be provided by each
        adapter at the convergence layer.)</t>

	<t>The layer.)</li>
        <li>The bundle route computation algorithm.</t>

	<t>Mechanisms algorithm.</li>
        <li>Mechanisms for populating the routing or forwarding information
           bases of bundle nodes.</t>

	<t>The nodes.</li>
        <li>The mechanisms for securing bundles en route.</t>

	<t> route.</li>
        <li> The mechanisms for managing bundle nodes.</t>

   </list></t> nodes.</li>
      </ul>
      <t>
   Note that implementations of the specification presented in this
   document will not be interoperable with implementations of RFC 5050.</t>
    </section>
    <section title="Conventions used anchor="sect-2" numbered="true" toc="default">
      <name>Conventions Used in this document" anchor="sect-2"><t>
	The This Document</name>
       <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", "<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
	"OPTIONAL" "<bcp14>OPTIONAL</bcp14>" in this document
       are to be interpreted as described in BCP
	14 BCP&nbsp;14
       <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only
       when, they appear in all capitals, as shown here.</t>
    </section>
    <section title="Service Description" anchor="sect-3"><section title="Definitions" anchor="sect-3.1"><t>
   Bundle - A anchor="sect-3" numbered="true" toc="default">
      <name>Service Description</name>
      <section anchor="sect-3.1" numbered="true" toc="default">
        <name>Definitions</name>

          <dl>
  <dt>Bundle:</dt>
   <dd>A bundle is a protocol data unit PDU of BP, so named because
   negotiation of the parameters of a data exchange may be impractical
   in a delay-tolerant network: it is often better practice to "bundle"
   with a unit of application data all metadata that might be needed in
   order to make the data immediately usable when delivered to the
   application. Each bundle comprises a sequence of two or more
   "blocks" of protocol data, which serve various purposes.</t>

	<t>
   Block - A bundle protocol purposes.</dd>

   <dt>Block:</dt>
   <dd>A Bundle Protocol block is one of the protocol data
   structures that together constitute a well-formed bundle.</t>

	<t>
   Application bundle.</dd>

   <dt>Application Data Unit (ADU) - An Unit:</dt>
   <dd>An application data unit (ADU) is the unit
   of data whose conveyance to the bundle's destination is the purpose
   for the transmission of some bundle that is not a fragment (as
   defined below).</t>

	<t>
   Bundle payload - A below).</dd>

   <dt>Bundle payload:</dt>
   <dd>A bundle payload (or simply "payload") is the
   content of the bundle's payload block. The terms "bundle content",
   "bundle payload", and "payload" are used interchangeably in this
   document.  For a bundle that is not a fragment (as defined below),
   the payload is an application data unit.</t>

	<t>
   Partial payload - A ADU.</dd>

   <dt>Partial payload:</dt>
   <dd>A partial payload is a payload that comprises
   either the first N bytes or the last N bytes of some other payload
   of length M, such that 0 &lt; N &lt; M.  Note that every partial payload is a payload and therefore can be further subdivided into partial payloads.</t>

	<t>
   Fragment - A payloads.</dd>

   <dt>Fragment:</dt>
   <dd>A fragment, a.k.a. "fragmentary bundle", is a bundle
   whose payload block contains a partial payload.</t>

	<t>
   Bundle node - A payload.</dd>

   <dt>Bundle node:</dt>
   <dd>A bundle node (or, in the context of this document,
   simply a "node") is any entity that can send and/or receive bundles.
   Each bundle node has three conceptual components, defined below, as
   shown in Figure 2: <xref target="fig-2"/>: a "bundle protocol agent", "Bundle Protocol Agent", a set of zero or more
   "convergence layer
   "convergence-layer adapters", and an "application agent".
 ("CL1 PDUs" are the PDUs of the convergence-layer protocol used in network
   1.)</t> 1.)</dd>
 </dl>

        <figure title="Components anchor="fig-2">
          <name>Components of a Bundle Node" anchor="fig-2"><artwork><![CDATA[ Node</name>
          <artwork name="" type="ascii-art" align="left" alt=""><![CDATA[
+-----------------------------------------------------------+
|Node                                                       |
|                                                           |
| +-------------------------------------------------------+ |
| |Application Agent                                      | |
| |                                                       | |
| | +--------------------------+ +----------------------+ | |
| | |Administrative element    | |Application-specific  | | |
| | |                          | |element               | | |
| | |                          | |                      | | |
| | +--------------------------+ +----------------------+ | |
| |                ^                          ^           | |
| |           Admin|records        Application|data       | |
| |                |                          |           | |
| +----------------v--------------------------v-----------+ |
|                               ^                           |
|                               | ADUs                      |
|                               |                           |
| +-----------------------------v-------------------------+ |
| |Bundle Protocol Agent                                  | |
| |                                                       | |
| |                                                       | |
| +-------------------------------------------------------+ |
|        ^                 ^                        ^       |
|        | Bundles         | Bundles        Bundles |       |
|        |                 |                        |       |
| +------v-----+     +-----v------+           +-----v-----+ |
| |CLA 1       |     |CLA 2       |           |CLA n      | |
| |            |     |            |   . . .   |           | |
| |            |     |            |           |           | |
+-+------------+-----+------------+-----------+-----------+-+
         ^                 ^                        ^
      CL1|PDUs          CL2|PDUs                 CLn|PDUs
         |                 |                        |
  +------v-----+     +-----v------+           +-----v-----+
   Network 1          Network 2                Network n
]]></artwork>
        </figure>
	<t>
        <dl>
        <dt>Bundle Protocol Agent:</dt>
   <dd>The Bundle protocol agent - The bundle protocol agent Protocol Agent (BPA) of a node is
   the node component that offers the BP services and executes the
   procedures of the bundle protocol.</t>

	<t>
   Convergence layer adapter - A convergence layer Bundle Protocol.</dd>
        <dt>Convergence-layer adapter:</dt>
   <dd>A convergence-layer adapter (CLA) is a
   node component that sends and receives bundles on behalf of the BPA,
   utilizing the services of some 'native' "integrated" protocol stack that is
   supported in one of the networks within which the node is
   functionally located.</t>

	<t>
   Application agent - The located.</dd>
        <dt>Application agent:</dt>
   <dd>The application agent (AA) of a node is the node
   component that utilizes the BP services to effect communication for
   some user purpose. The application agent in turn has two elements, elements:
   an administrative element and an application-specific element.</t>

	<t>
   Application-specific element - The element.</dd>
        <dt>Application-specific element:</dt>
   <dd>The application-specific element of
   an AA is the node component that constructs, requests transmission
   of, accepts delivery of, and processes units of user application
   data.</t>

	<t>
   Administrative element - The
   data.</dd>
        <dt>Administrative element:</dt>
   <dd>The administrative element of an AA is the
   node component that constructs and requests transmission of
   administrative records (defined below), including status reports,
   and accepts delivery of and processes any administrative records
   that the node receives.</t>

	<t>
   Administrative record - A receives.</dd>
        <dt>Administrative record:</dt>
   <dd>A BP administrative record is an application
   data unit ADU that is exchanged between the administrative elements of
   nodes' application agents for some BP administrative purpose.  The
   only administrative record defined in this specification is the
   status report, discussed later.</t>

	<t>
   Bundle endpoint - A later.</dd>
   <dt>Bundle endpoint:</dt>
   <dd>A bundle endpoint (or simply "endpoint") is a set
   of zero or more bundle nodes that all identify themselves for BP
   purposes by some common identifier, called a "bundle endpoint ID"
   (or, in this document, simply "endpoint ID"; ID"); endpoint IDs are
   described in detail in Section 4.5.5.1 below.</t>

	<t>
   Singleton endpoint - A <xref target="sect-4.2.5.1"/>.</dd>
        <dt>Singleton endpoint:</dt>
   <dd>A singleton endpoint is an endpoint that always
   contains exactly one member.</t>

	<t>
   Registration - A member.</dd>
        <dt>Registration:</dt>
   <dd>A registration is the state machine characterizing a
   given node's membership in a given endpoint.  Any single
   registration has an associated delivery failure action as defined
   below and must at any time be in one of two states: Active or
   Passive.  Registrations are local; information about a node's
   registrations is not expected to be available at other nodes, and
   the Bundle Protocol does not include a mechanism for distributing
   information about registrations.</t>

	<t>
   Delivery - A registrations.</dd>
        <dt>Delivery:</dt>
   <dd>A bundle is considered to have been delivered at a node
   subject to a registration as soon as the application data unit ADU that
   is the payload of the bundle, together with any relevant metadata
   (an implementation matter), has been presented to the node's
   application agent in a manner consistent with the state of that
   registration.</t>

	<t>
   Deliverability - A
   registration.</dd>
        <dt>Deliverability:</dt>
   <dd>A bundle is considered "deliverable" subject to a
   registration if and only if (a) the bundle's destination endpoint is
   the endpoint with which the registration is associated, (b) the
   bundle has not yet been delivered subject to this registration, and
   (c) the bundle has not yet been "abandoned" (as defined below)
   subject to this registration.</t>

	<t>
   Abandonment - To registration.</dd>
        <dt>Abandonment:</dt>
   <dd>To abandon a bundle subject to some registration is to
   assert that the bundle is not deliverable subject to that
   registration.</t>

	<t>
   Delivery
   registration.</dd>
        <dt>Delivery failure action - The action:</dt>
   <dd>The delivery failure action of a
   registration is the action that is to be taken when a bundle that is
   "deliverable" subject to that registration is received at a time
   when the registration is in the Passive state.</t>

	<t>
   Destination - The state.</dd>
        <dt>Destination:</dt>
   <dd>The destination of a bundle is the endpoint comprising
   the node(s) at which the bundle is to be delivered (as defined
   above).</t>

	<t>
   Transmission - A
   above).</dd>
        <dt>Transmission:</dt>
   <dd>A transmission is an attempt by a node's BPA to cause
   copies of a bundle to be delivered to one or more of the nodes that
   are members of some endpoint (the bundle's destination) in response
   to a transmission request issued by the node's application agent.</t>

	<t>
   Forwarding - To agent.</dd>
        <dt>Forwarding:</dt>
   <dd>To forward a bundle to a node is to invoke the services
   of one or more CLAs in a sustained effort to cause a copy of the
   bundle to be received by that node.</t>

	<t>
   Discarding - To node.</dd>
        <dt>Discarding:</dt>
   <dd>To discard a bundle is to cease all operations on the
   bundle and functionally erase all references to it.  The specific
   procedures by which this is accomplished are an implementation
   matter.</t>

	<t>
   Retention constraint - A
   matter.</dd>
        <dt>Retention constraint:</dt>
   <dd>A retention constraint is an element of the
   state of a bundle that prevents the bundle from being discarded.
   That is, a bundle cannot be discarded while it has any retention
   constraints.</t>

	<t>
   Deletion - To
   constraints.</dd>
        <dt>Deletion:</dt>
   <dd>To delete a bundle is to remove unconditionally all of
   the bundle's retention constraints, enabling the bundle to be
   discarded.</t>
   discarded.</dd>
 </dl>
      </section>
      <section title="Discussion anchor="sect-3.2" numbered="true" toc="default">
        <name>Discussion of BP concepts" anchor="sect-3.2"><t> Concepts</name>
        <t>
   Multiple instances of the same bundle (the same unit of DTN protocol
   data) might exist concurrently in different parts of a network --
   possibly differing in some blocks -- in the memory local to one or
   more bundle nodes and/or in transit between nodes. In the context of
   the operation of a bundle node, a bundle is an instance (copy), in
   that node's local memory, of some bundle that is in the network.</t>
        <t>
   The payload for a bundle forwarded in response to a bundle
   transmission request is the application data unit ADU whose location is
   provided as a parameter to that request. The payload for a bundle
   forwarded in response to reception of a bundle is the payload of the
   received bundle.</t>
        <t>
   In the most familiar case, a bundle node is instantiated as a single
   process running on a general-purpose computer, but in general the
   definition is meant to be broader: a bundle node might alternatively
   be a thread, an object in an object-oriented operating system, a
   special-purpose hardware device, etc.</t>
        <t>
   The manner in which the functions of the BPA are performed is wholly
   an implementation matter. For example, BPA functionality might be
   coded into each node individually; it might be implemented as a
   shared library that is used in common by any number of bundle nodes
   on a single computer; it might be implemented as a daemon whose
   services are invoked via inter-process or network communication by
   any number of bundle nodes on one or more computers; it might be
   implemented in hardware.</t>
        <t>
   Every CLA implements its own thin layer of protocol, interposed
   between BP and the (usually "top") protocol(s) of the underlying
   native
   integrated protocol stack; this "CL protocol" may only serve to
   multiplex and de-multiplex demultiplex bundles to and from the underlying native integrated
   protocol, or it may offer additional CL-specific functionality. The
   manner in which a CLA sends and receives bundles, as well as the
   definitions of CLAs and CL protocols, are beyond the scope of this
   specification.</t>
        <t>
   Note that the administrative element of a node's application agent
   may itself, in some cases, function as a convergence-layer adapter. CLA.
   That is, outgoing bundles may be "tunneled" through encapsulating
   bundles:

	<list style="symbols">

	  <t>An

        </t>
        <ul spacing="normal">
          <li>An outgoing bundle constitutes a byte array. This byte array may,
          like any other, be presented to the bundle protocol agent BPA as an
	  application data unit
          ADU that is to be transmitted to some endpoint.</t>

	  <t>The endpoint.</li>
          <li>The original bundle thus forms the payload of an encapsulating
          bundle that is forwarded using some other convergence-layer
	  protocol(s).</t>

	  <t>When
          protocol(s).</li>
          <li>When the encapsulating bundle is received, its payload is
          delivered to the peer application agent administrative element,
          which then instructs the bundle protocol agent BPA to dispatch that
          original bundle in the usual way.</t>

	</list>
	</t> way.</li>
        </ul>
        <t>
   The purposes for which this technique may be useful (such as cross-domain
   security) are beyond the scope of this specification.</t>
        <t>
   The only interface between the BPA and the application-specific
   element of the AA is the BP service interface. But between the BPA
   and the administrative element of the AA there is a (conceptual)
   private control interface in addition to the BP service interface.
   This private control interface enables the BPA and the
   administrative element of the AA to direct each other to take action
   under specific circumstances.</t>
        <t>
   In the case of a node that serves simply as a BP "router", the AA may have
   no application-specific element at all. The application-specific elements
   of other nodes' AAs may perform arbitrarily complex application functions,
   perhaps even offering multiplexed DTN communication services to a number of
   other applications. As with the BPA, the manner in which the AA performs
   its functions is wholly an implementation matter.</t>
        <t>
   Singletons are the most familiar sort of endpoint, but in general
   the endpoint notion is meant to be broader. For example, the nodes
   in a sensor network might constitute a set of bundle nodes that are
   all registered in a single common endpoint and will all receive any
   data delivered at that endpoint. *Note* <strong>Note</strong> too that any given bundle
   node might be registered in multiple bundle endpoints and receive
   all data delivered at each of those endpoints.</t> endpoints.
</t>
   <t>

   Recall that every node, by definition, includes an application agent agent, which
   in turn includes an administrative element, which exchanges administrative
   records with the administrative elements of other nodes.  As such, every
   node is permanently, structurally registered in the singleton endpoint at
   which administrative records received from other nodes are delivered.
   Registration in no other endpoint can ever be assumed to be permanent.
   This endpoint, termed the node's "administrative endpoint", is therefore
   uniquely and permanently associated with the node, and for this reason the
   ID of a node's administrative endpoint additionally serves may always serve as the "node ID"
   (see 4.1.5.2 below) <xref target="sect-4.2.5.2"/>) of the node.</t> node.
</t>
        <t>
   The destination of every bundle is an endpoint, which may or may not
   be singleton.  The source of every bundle is a node, identified by
   node ID.  Note, though, that the source node ID asserted in a given
   bundle may be the null endpoint ID (as described later) rather than
   the ID of the source node; bundles for which the asserted source
   node ID is the null endpoint ID are termed "anonymous" bundles.</t>
        <t>
   Any number of transmissions may be concurrently undertaken by the
   bundle protocol agent
   BPA of a given node.</t>

	<t>
   When

   <t>When the bundle protocol agent BPA of a node determines that a bundle it must be forwarded to forward a node (either bundle either
   to a node that is a member of the bundle's destination endpoint or to
   some intermediate forwarding
   node) in the course of completing the successful transmission of
   that bundle, node, the bundle protocol agent BPA invokes the services of one
   or more CLAs in a sustained effort to cause a copy of the bundle to be
   received by that node.</t>

	<t>
   Upon

   <t>Upon reception, the processing of a bundle that has been received by
   a given node depends on whether or not
   the receiving node is registered in the bundle's destination endpoint.
 If it is, and if
   the payload of the bundle is non-fragmentary (possibly as a result
   of successful payload reassembly from fragmentary payloads,
   including the original payload of the newly received bundle), then
   the bundle is normally delivered to the node's application agent
   subject to the registration characterizing the node's membership in
   the destination endpoint.</t>
        <t>
   The bundle protocol Bundle Protocol itself does not natively ensure delivery of a bundle to
   its destination.  Data loss along the path to the destination node
   can be minimized by utilizing reliable convergence-layer protocols
   between neighbors on all segments of the end-to-end path, but path; however, for
   end-to-end bundle delivery assurance it will be necessary to develop
   extensions to the bundle protocol Bundle Protocol and/or application-layer
   mechanisms.</t>
        <t>
   The bundle protocol Bundle Protocol is designed for extensibility.  Bundle protocol Protocol
   extensions, documented elsewhere, may extend this specification by:

	<list style="symbols">

   	<t>defining additional blocks;</t>

	<t>defining additional administrative records;</t>

	<t>defining additional bundle by
   defining additional:

        </t>
        <ul spacing="normal">
          <li>blocks</li>
          <li>administrative records</li>
          <li>bundle processing flags;</t>

	<t>defining additional block control flags</li>
          <li>block processing flags;</t>

	<t>defining additional types control flags</li>
          <li>types of bundle status reports;</t>

	<t>defining additional bundle reports</li>
          <li>bundle status report reason codes;</t>

	<t>defining additional mandates codes</li>
          <li>mandates and constraints on processing that
        conformant bundle protocol agents BPAs must perform at specified points in
        the inbound and outbound bundle processing cycles.</t>

	</list>
	</t> cycles</li>
        </ul>
      </section>
      <section title="Services anchor="sect-3.3" numbered="true" toc="default">
        <name>Services Offered by Bundle Protocol Agents" anchor="sect-3.3"><t> Agents</name>
        <t>
   The BPA of each node is expected to provide the following services
   to the node's application agent:

	<list style="symbols">

	<t>commencing

        </t>
        <ul spacing="normal">
          <li>commencing a registration (registering the node in an endpoint);</t>

	<t>terminating endpoint).</li>
          <li>terminating a registration;</t>

	<t>switching registration.</li>
          <li>switching a registration between Active and Passive states;</t>

	<t>transmitting states.</li>
          <li>transmitting a bundle to an identified bundle endpoint;</t>

	<t>canceling endpoint.</li>
          <li>canceling a transmission;</t>

	<t>polling transmission.</li>
          <li>polling a registration that is in the Passive state;</t>

	<t>delivering state.</li>
          <li>delivering a received bundle.</t>

	</list>
      </t> bundle.</li>
        </ul>
        <t>   Note that the details of registration functionality are an
   implementation matter and are beyond the scope of this
   specification.</t>
      </section>
    </section>
    <section title="Bundle Format" anchor="sect-4"><section title="Bundle Structure" anchor="sect-4.1"><t> anchor="sect-4" numbered="true" toc="default">
      <name>Bundle Format</name>
      <section anchor="sect-4.1" numbered="true" toc="default">
        <name>Bundle Structure</name>
        <t>
   The format of bundles SHALL <bcp14>SHALL</bcp14> conform to the Concise Binary Object
   Representation (CBOR (CBOR) <xref target="RFC8949"/>).</t> target="RFC8949" format="default"/>.</t>
        <t>
   Cryptographic verification of a block is possible only if the
   sequence of octets on which the verifying node computes its hash - --
   the canonicalized representation of the block - -- is identical to the
   sequence of octets on which the hash declared for that block was
   computed.  To ensure that blocks are always in canonical
   representation when they are transmitted and received, the CBOR
   representations
   encodings of the values of all fields in all blocks must <bcp14>MUST</bcp14>
   conform to the rules for Canonical CBOR core deterministic encoding requirements as specified in <xref target="RFC8949"/>.</t> target="RFC8949" format="default"/>, except that indefinite-length items are not prohibited.</t>
        <t>
   Each bundle SHALL <bcp14>SHALL</bcp14> be a concatenated sequence of at least two blocks,
   represented as a CBOR indefinite-length array.  The first block in
   the sequence (the first item of the array) MUST <bcp14>MUST</bcp14> be a primary bundle
   block in CBOR representation encoding as described below; the bundle MUST <bcp14>MUST</bcp14>
   have exactly one primary bundle block. The primary block MUST <bcp14>MUST</bcp14> be
   followed by one or more canonical bundle blocks (additional array
   items) in CBOR representation encoding as described in 4.3.2 below. <xref target="sect-4.3.2"/>.  Every
   block following the primary block SHALL <bcp14>SHALL</bcp14> be the CBOR representation encoding
   of a canonical block.  The last such block MUST <bcp14>MUST</bcp14> be a payload block;
   the bundle MUST <bcp14>MUST</bcp14> have exactly one payload block.  The payload block
   SHALL
   <bcp14>SHALL</bcp14> be followed by a CBOR "break" stop code, terminating the
   array.</t>

	<t>
   <aside><t>
   (Note that, while CBOR permits considerable flexibility in the
   encoding of bundles, this flexibility must not be interpreted as
   inviting increased complexity in protocol data unit structure.)</t> PDU structure.)</t></aside>
        <t>
   Associated with each block of a bundle is a block number.  The block
   number uniquely identifies the block within the bundle, enabling
   blocks (notably bundle security protocol Bundle Protocol Security blocks) to reference other
   blocks in the same bundle without ambiguity.  The block number of
   the primary block is implicitly zero; the block numbers of all other
   blocks are explicitly stated in block headers as noted below. Block
   numbering is unrelated to the order in which blocks are sequenced in
   the bundle. The block number of the payload block is always 1.</t>
        <t>
   An implementation of the Bundle Protocol MAY <bcp14>MAY</bcp14> discard any sequence of
   bytes that does not conform to the Bundle Protocol specification.</t>
        <t>
   An implementation of the Bundle Protocol MAY <bcp14>MAY</bcp14> accept a sequence of
   bytes that does not conform to the Bundle Protocol specification
   (e.g., one that represents data elements in fixed-length arrays
   rather than indefinite-length arrays) and transform it into
   conformant BP structure before processing it.  Procedures for
   accomplishing such a transformation are beyond the scope of this
   specification.</t>
      </section>
      <section title="BP anchor="sect-4.2" numbered="true" toc="default">
        <name>BP Fundamental Data Structures" anchor="sect-4.2"><section title="CRC Type" anchor="sect-4.2.1"><t> Structures</name>
        <section anchor="sect-4.2.1" numbered="true" toc="default">
          <name>CRC Type</name>
          <t>
   CRC type is an unsigned integer type code for which the following
   values (and no others) are valid:

	<list style="symbols">

	<t>0

          </t>
          <ul spacing="normal">
            <li>0 indicates "no CRC Cyclic Redundancy Check (CRC) is present."</t>

	<t>1 present."</li>
            <li>1 indicates "a standard X-25 CRC-16 is present." [CRC16]</t>

	<t>2 <xref target="CRC16"/></li>
            <li>2 indicates "a standard CRC32C (Castagnoli) CRC-32 is present."
        <xref target="RFC4960"/></t>

	</list>
	</t> target="RFC4960" format="default"/></li>
          </ul>
          <t>
   CRC type SHALL <bcp14>SHALL</bcp14> be represented as a CBOR unsigned integer.</t>
          <t>
   For examples of CRC32C CRCs, see Appendix A.4 of <xref target="RFC7143"/>.</t> target="RFC7143" sectionFormat="of" section="A.4"/>.</t>
          <t>
   Note that more robust protection of BP data integrity, as needed,
   may be provided by means of Block Integrity Blocks (BIBs) as defined in the
   Bundle Security Protocol Security specification <xref target="I-D.ietf-dtn-bpsec"/>).</t> target="RFC9172"/>.
          </t>
        </section>
        <section title="CRC" anchor="sect-4.2.2"><t> anchor="sect-4.2.2" numbered="true" toc="default">
          <name>CRC</name>
          <t>
   The CRC SHALL <bcp14>SHALL</bcp14> be omitted from a block if and only if the block's CRC
   type code is zero.</t>
          <t>
   When not omitted, the CRC SHALL <bcp14>SHALL</bcp14> be represented as a CBOR byte string
   of two bytes (that is, CBOR additional information 2, if CRC type is
   1) or of four bytes (that is, CBOR additional information 4, if CRC
   type is 2); in each case case, the sequence of bytes SHALL <bcp14>SHALL</bcp14> constitute an
   unsigned integer value (of 16 or 32 bits, respectively) in network
   byte order.</t>
        </section>
        <section title="Bundle anchor="sect-4.2.3" numbered="true" toc="default">
          <name>Bundle Processing Control Flags" anchor="sect-4.2.3"><t> Flags</name>
          <t>
   Bundle processing control flags assert properties of the bundle as a
   whole rather than of any particular block of the bundle.  They are
   conveyed in the primary block of the bundle.</t>
          <t>
   The following properties are asserted by the bundle processing
   control flags:

	<list style="symbols">

	<t>The

          </t>
          <ul spacing="normal">
            <li>The bundle is a fragment.  (Boolean)</t>

	<t>The  (Boolean)</li>
            <li>The bundle's payload is an administrative record.  (Boolean)</t>

	<t>The  (Boolean)</li>
            <li>The bundle must not be fragmented.  (Boolean)</t>

	<t>Acknowledgment  (Boolean)</li>
            <li>Acknowledgment by the user application is requested.  (Boolean)</t>

	<t>Status  (Boolean)</li>
            <li>Status time is requested in all status reports.  (Boolean)</t>  (Boolean)</li>
            <li>
              <t>Flags requesting types of status reports (all Boolean):

	   <list style="symbols">

	     <t>Request

              </t>
              <ul spacing="normal">
                <li>Request reporting of bundle reception.</t>

	     <t>Request reception.</li>
                <li>Request reporting of bundle forwarding.</t>

	     <t>Request forwarding.</li>
                <li>Request reporting of bundle delivery.</t>

	     <t>Request delivery.</li>
                <li>Request reporting of bundle deletion.</t>

	</list>
	</t>

	</list>
	</t> deletion.</li>
              </ul>
            </li>
          </ul>
          <t>
   If the bundle processing control flags indicate that the bundle's
   application data unit
   ADU is an administrative record, then all status
   report request flag values MUST <bcp14>MUST</bcp14> be zero.</t>
          <t>
   If the bundle's source node is omitted (i.e., the source node ID is the ID
   of the null endpoint, which has no members as discussed below; this option
   enables anonymous bundle transmission), then the bundle is not uniquely
   identifiable and all bundle protocol Bundle Protocol features that rely on bundle identity
   must therefore be disabled: the "Bundle must not be fragmented" flag value
   MUST
   <bcp14>MUST</bcp14> be 1 1, and all status report request flag values MUST <bcp14>MUST</bcp14> be zero.</t>
          <t>
   Bundle processing control flags that are unrecognized MUST <bcp14>MUST</bcp14> be
   ignored, as future definitions of additional flags might not be
   integrated simultaneously into the Bundle Protocol implementations
   operating at all nodes.</t>
          <t>
   The bundle processing control flags SHALL <bcp14>SHALL</bcp14> be represented as a CBOR
   unsigned integer item, the value of which SHALL <bcp14>SHALL</bcp14> be processed as a
   bit field indicating the control flag values as follows (note that
   bit numbering in this instance is reversed from the usual practice,
   beginning with the low-order bit instead of the high-order bit, in
   recognition of the potential definition of additional control flag
   values in the future):

   <list style="symbols">

	<t>Bit

          </t>
          <dl spacing="normal">
            <dt>Bit 0 (the low-order bit, 0x000001): bundle 0x000001):</dt>
            <dd>Bundle is a fragment.</t>

	<t>Bit fragment.</dd>
            <dt>Bit 1 (0x000002): payload (0x000002):</dt>
            <dd>ADU is an administrative record.</t>

	<t>Bit record.</dd>
            <dt>Bit 2 (0x000004): bundle (0x000004):</dt>
            <dd>Bundle must not be fragmented.</t>

	<t>Bit fragmented.</dd>
            <dt>Bit 3 (0x000008): reserved.</t>

	<t>Bit (0x000008):</dt>
            <dd>Reserved.</dd>
            <dt>Bit 4 (0x000010): reserved.</t>

	<t>Bit (0x000010):</dt>
            <dd>Reserved.</dd>
            <dt>Bit 5 (0x000020): user (0x000020):</dt>
            <dd>Acknowledgement by application acknowledgement is requested.</t>

	<t>Bit requested.</dd>
            <dt>Bit 6 (0x000040): status (0x000040):</dt>
            <dd>Status time is requested in all status reports.</t>

	<t>Bit reports.</dd>
            <dt>Bit 7 (0x000080): reserved.</t>

	<t>Bit (0x000080):</dt>
            <dd>Reserved.</dd>
            <dt>Bit 8 (0x000100): reserved.</t>

	<t>Bit (0x000100):</dt>
            <dd>Reserved.</dd>
            <dt>Bit 9 (0x000200): reserved.</t>

	<t>Bit 10(0x000400): reserved.</t>

	<t>Bit 11(0x000800): reserved.</t>

	<t>Bit 12(0x001000): reserved.</t>

	<t>Bit 13(0x002000): reserved.</t>

	<t>Bit 14(0x004000): (0x000200):</dt>
            <dd>Reserved.</dd>
            <dt>Bit 10 (0x000400):</dt>
            <dd>Reserved.</dd>
            <dt>Bit 11 (0x000800):</dt>
            <dd>Reserved.</dd>
            <dt>Bit 12 (0x001000):</dt>
            <dd>Reserved.</dd>
            <dt>Bit 13 (0x002000):</dt>
            <dd>Reserved.</dd>
            <dt>Bit 14 (0x004000):</dt>
            <dd>Request reporting of bundle reception status reports are requested.</t>

	<t>Bit 15(0x008000): reserved.</t>

	<t>Bit 16(0x010000): reception.</dd>
            <dt>Bit 15 (0x008000):</dt>
            <dd>Reserved.</dd>
            <dt>Bit 16 (0x010000):</dt>
            <dd>Request reporting of bundle forwarding status reports are requested.</t>

	<t>Bit 17(0x020000): forwarding.</dd>
            <dt>Bit 17 (0x020000):</dt>
            <dd>Request reporting of bundle delivery status reports are requested.</t>

	<t>Bit 18(0x040000): delivery.</dd>
            <dt>Bit 18 (0x040000):</dt>
            <dd>Request reporting of bundle deletion status reports are requested.</t>

	<t>Bits 19-20 are reserved.</t>

	<t>Bits 21-63 are unassigned.</t>

   </list></t> deletion.</dd>
            <dt>Bits 19-20:</dt>
            <dd>Reserved.</dd>
            <dt>Bits 21-63:</dt>
            <dd>Unassigned.</dd>
          </dl>
        </section>
        <section title="Block anchor="sect-4.2.4" numbered="true" toc="default">
          <name>Block Processing Control Flags" anchor="sect-4.2.4"><t> Flags</name>
          <t>
   The block processing control flags assert properties of canonical
   bundle blocks.  They are conveyed in the header of the block to
   which they pertain.</t>
          <t>
   Block processing control flags that are unrecognized MUST <bcp14>MUST</bcp14> be
   ignored, as future definitions of additional flags might not be
   integrated simultaneously into the Bundle Protocol implementations
   operating at all nodes.</t>
          <t>
   The block processing control flags SHALL <bcp14>SHALL</bcp14> be represented as a CBOR
   unsigned integer item, the value of which SHALL <bcp14>SHALL</bcp14> be processed as a
   bit field indicating the control flag values as follows (note that
   bit numbering in this instance is reversed from the usual practice,
   beginning with the low-order bit instead of the high-order bit, for
   agreement with the bit numbering of the bundle processing control
   flags):

      <list style="symbols">

	  <t>Bit 0(the
   flags):</t>
          <dl spacing="normal">
          <dt>Bit 0 (the low-order bit, 0x01): block 0x01):</dt>
           <dd>Block must be replicated in every
	  fragment.</t>

	  <t>Bit 1(0x02): transmission of a fragment.</dd>
          <dt>Bit 1 (0x02):</dt>
           <dd>Transmit status report is requested if block can't be processed.</t>

	  <t>Bit 2(0x04): processed.</dd>
          <dt>Bit 2 (0x04):</dt>
           <dd>Delete bundle must be deleted if block can't be processed.</t>

	  <t>Bit 3(0x08): reserved.</t>

	  <t>Bit 4(0x10): processed.</dd>
          <dt>Bit 3 (0x08):</dt>
           <dd>Reserved.</dd>
          <dt>Bit 4 (0x10):</dt>
           <dd>Discard block must be removed from bundle if it can't be
	  processed.</t>

	  <t>Bit 5(0x20): reserved.</t>

	  <t>Bit processed.</dd>
          <dt>Bit 5 (0x20):</dt>
           <dd>Reserved.</dd>
          <dt>Bit 6 (0x40): reserved.</t>

	  <t>Bits 7-63 are unassigned.</t>

      </list></t> (0x40):</dt>
           <dd>Reserved.</dd>
          <dt>Bits 7-63:</dt>
           <dd>Unassigned.</dd>
          </dl>
          <t>
   For each bundle whose bundle processing control flags indicate that
   the bundle's application data unit ADU is an administrative record, or
   whose source node ID is the null endpoint ID as defined below, the
   value of the "Transmit status report if block can't be processed"
   flag in every canonical block of the bundle MUST <bcp14>MUST</bcp14> be zero.</t>
        </section>
        <section title="Identifiers" anchor="sect-4.2.5"><section title="Endpoint ID" anchor="sect-4.2.5.1"><t> anchor="sect-4.2.5" numbered="true" toc="default">
          <name>Identifiers</name>
          <section anchor="sect-4.2.5.1" numbered="true" toc="default">
            <name>Endpoint ID</name>
            <t>
   The destinations of bundles are bundle endpoints, identified by text
   strings termed "endpoint IDs" (see <xref target="sect-3.1"/>). target="sect-3.1" format="default"/>). Each endpoint ID
   (EID) is a Uniform Resource Identifier (URI; <xref target="URI"/>). target="RFC3986" format="default"/>. As such, each
   endpoint ID can be characterized as having this general structure:</t>
            <t>
   &lt; scheme name &gt; : &lt; scheme-specific part, or "SSP" &gt;</t>
            <t>
   The scheme identified by the &lt; scheme name &gt; in an endpoint ID is a
   set of syntactic and semantic rules that fully explain how to parse
   and interpret the SSP. scheme-specific part (SSP). Each scheme that may be used to form a BP
   endpoint ID must be added to the registry of URI scheme code numbers
   for Bundle "Bundle Protocol URI Scheme Types" registry,
   maintained by IANA as described in <xref target="sect-10"/>; target="sect-9.6" format="default"/>;
   association of a unique URI scheme code number with each scheme name
   in this registry helps to enable compact representation of endpoint
   IDs in bundle blocks.  Note that the set of allowable schemes is
   effectively unlimited. Any scheme conforming to <xref target="URIREG"/> target="RFC7595" format="default"/> may be
   added to the registry of URI scheme code number registry numbers and thereupon used in a
   bundle protocol
   Bundle Protocol endpoint ID.</t>
            <t>
   Each entry in the registry of URI scheme code number registry MUST numbers <bcp14>MUST</bcp14> contain a
   reference to a scheme code number definition document, which defines
   the manner in which the scheme-specific part of any URI formed in
   that scheme is parsed and interpreted and MUST <bcp14>MUST</bcp14> be encoded, in CBOR
   representation, encoded for transmission as a BP endpoint ID.  The scheme
   code number definition document may also contain information as to
   (a) which convergence-layer protocol(s) may be used to forward a
   bundle to a BP destination endpoint identified by such an ID, ID and
   (b) how the ID of the convergence-layer protocol endpoint to use for
   that purpose can be inferred from that destination endpoint ID.</t>
            <t>
   Note that, although endpoint IDs are URIs, implementations of the BP
   service interface may support expression of endpoint IDs in some
   internationalized manner (e.g., Internationalized Resource
   Identifiers (IRIs); see <xref target="RFC3987"/>).</t> target="RFC3987" format="default"/>).</t>
            <t>
   Each BP endpoint ID (EID) SHALL <bcp14>SHALL</bcp14> be represented as a CBOR array
   comprising two items.</t>
            <t>
   The first item of the array SHALL <bcp14>SHALL</bcp14> be the code number identifying the
   endpoint ID's URI scheme, as defined in the registry of URI scheme
   code numbers for the Bundle Protocol.  Each URI scheme code number SHALL <bcp14>SHALL</bcp14>
   be represented as a CBOR unsigned integer.</t>
            <t>
   The second item of the array SHALL <bcp14>SHALL</bcp14> be the applicable CBOR
   representation
   encoding of the scheme-specific part (SSP) of the EID, defined
   as noted in the references(s) for the URI scheme code number
   registry entry for the EID's URI scheme.</t>
            <section title="The &quot;dtn&quot; anchor="sect-4.2.5.1.1" numbered="true" toc="default">
              <name>The dtn URI scheme" anchor="sect-4.2.5.1.1"><t> Scheme</name>
              <t>
   The "dtn" scheme supports the identification of BP endpoints by
   arbitrarily expressive character strings.  It is specified as
   follows:</t>

	<t>
   Scheme syntax: This
              <dl>
  <dt>Scheme syntax:</dt>
   <dd>This specification uses the Augmented Backus-Naur
  Form (ABNF) notation of <xref target="RFC5234"/>.</t>

	<figure><artwork><![CDATA[ target="RFC5234" format="default"/>.</dd>
              </dl>
              <sourcecode type="abnf"><![CDATA[
dtn-uri = "dtn:" ("none" / dtn-hier-part)

dtn-hier-part = "//" node-name name-delim demux ; a path-rootless

node-name = 1*(ALPHA/DIGIT/"-"/"."/"_") reg-name

name-delim = "/"

demux = *VCHAR
]]></artwork>
	</figure>
	<t>
   Scheme semantics: URIs
]]></sourcecode>
              <dl>
   <dt>Scheme semantics:</dt>
   <dd>URIs of the dtn scheme are used as endpoint
   identifiers in the Delay-Tolerant Networking (DTN) Bundle Protocol
   (BP) as described in the present document.</t> document.</dd>
              </dl>
              <t>
   The endpoint ID "dtn:none" identifies the "null endpoint", the
   endpoint that by definition never has any members.</t>
              <t>
   All BP endpoints identified by all other dtn-scheme endpoint IDs for which
   the first character of demux is a character other than '~' (tilde) are
   singleton endpoints. All BP endpoints identified by dtn-scheme endpoint IDs
   for which the first character *is* <strong>is</strong> '~' (tilde) are *not* <strong>not</strong> singleton
   endpoints.</t>
              <t>
   A dtn-scheme endpoint ID for which the demux is of length zero MAY <bcp14>MAY</bcp14>
   identify the administrative endpoint for the node identified by
   node-name, and as such may serve as a node ID.  No dtn-scheme
   endpoint ID for which the demux is of non-zero length may do so.</t>
              <t>
   Note that these syntactic rules impose constraints on dtn-scheme
   endpoint IDs that were not imposed by the original specification of
   the dtn scheme as provided in <xref target="RFC5050"/>. target="RFC5050" format="default"/>.  It is believed that the
   dtn-scheme endpoint IDs employed by BP applications conforming to
   <xref target="RFC5050"/> target="RFC5050" format="default"/> are in most cases unlikely to be in violation of these
   rules, but the developers of such applications are advised of the
   potential for compromised interoperation.</t>

	<t>
   Encoding considerations: For
  <dl>
   <dt>Encoding considerations:</dt>
   <dd>For transmission as a BP endpoint ID, the
   scheme-specific part of a URI of the dtn scheme SHALL <bcp14>SHALL</bcp14> be represented
   as a CBOR text string unless the EID's SSP is "none", in which case
   the SSP SHALL <bcp14>SHALL</bcp14> be represented as a CBOR unsigned integer with the
   value zero.  For all other purposes, URIs of the dtn scheme are
   encoded exclusively in US-ASCII characters.</t>

	<t>
   Interoperability considerations: none.</t>

	<t>
   Security considerations:</t>

   <t>Reliability characters.</dd>
   <dt>Interoperability considerations:</dt>
   <dd>None.</dd>
     <dt>Security considerations:</dt>
     <dd>
     <t><br/></t>
       <dl>
        <dt>Reliability and consistency: none consistency:</dt>
   <dd>None of the BP endpoints identified by the
   URIs of the dtn scheme 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. Bundle authentication Verification of the signature provided by the Block Integrity Block targeting the bundle's primary block, as defined by the Bundle Security Protocol Security <xref target="RFC9172"/>, is required for this purpose.</t>

   <t>Malicious construction: malicious purpose.</dd>
              <dt>Malicious construction:</dt>
   <dd>Malicious construction of a conformant
   dtn-scheme URI is limited to the malicious selection of node names and the
   malicious selection of demux strings.  That is, a maliciously constructed
   dtn-scheme URI 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.</t>

   <t>Back-end transcoding: the way.</dd>
              <dt>Back-end transcoding:</dt>
   <dd>The limited expressiveness of URIs of the dtn
   scheme effectively eliminates the possibility of threat due to errors in
   back-end transcoding.</t>

   <t>Rare transcoding.</dd>
              <dt>Rare IP address formats: not formats:</dt>
   <dd>Not relevant, as IP addresses do not appear
   anywhere in conformant dtn-scheme URIs.</t>

   <t>Sensitive information: because URIs.</dd>
              <dt>Sensitive information:</dt>
   <dd>Because dtn-scheme URIs are used only to
   represent the identities of Bundle Protocol endpoints, the risk of
   disclosure of sensitive information due to interception of these URIs is
   minimal.  Examination of dtn-scheme 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.</t>

   <t>Semantic attacks: the
   IDs.</dd>
              <dt>Semantic attacks:</dt>
   <dd>The simplicity of dtn-scheme URI syntax minimizes the
   possibility of misinterpretation of a URI by a human user.</t> user.</dd>
       </dl>
     </dd>
   </dl>
            </section>
            <section title="The &quot;ipn&quot; anchor="sect-4.2.5.1.2" numbered="true" toc="default">
              <name>The ipn URI scheme" anchor="sect-4.2.5.1.2"><t> Scheme</name>
              <t>
   The "ipn" scheme supports the identification of BP endpoints by
   pairs of unsigned integers, for compact representation in bundle
   blocks.  It is specified as follows:</t>

	<t>
   Scheme syntax: This
              <dl>
   <dt>Scheme syntax:</dt>
   <dd>This specification uses the Augmented Backus-Naur
   Form (ABNF) notation of <xref target="RFC5234"/>, target="RFC5234" format="default"/>, including the core ABNF syntax
   rule for DIGIT defined by that specification.</t>

	<figure><artwork><![CDATA[ specification.</dd>
              </dl>
              <sourcecode type="abnf"><![CDATA[
ipn-uri = "ipn:" ipn-hier-part

ipn-hier-part = node-nbr nbr-delim service-nbr ; a path-rootless

node-nbr = 1*DIGIT

nbr-delim = "."

service-nbr = 1*DIGIT
]]></artwork>
	</figure>
	<t>
   Scheme semantics: URIs
]]></sourcecode>
              <dl>
  <dt>Scheme semantics:</dt>
   <dd>URIs of the ipn scheme are used as endpoint
   identifiers in the Delay-Tolerant Networking (DTN) Bundle Protocol
   (BP) as described in the present document.</t> document.</dd>
              </dl>
              <t>
   All BP endpoints identified by ipn-scheme endpoint IDs are singleton
   endpoints.</t>
              <t>
   An ipn-scheme endpoint ID for which service-nbr is zero MAY <bcp14>MAY</bcp14> identify
   the administrative endpoint for the node identified by node-nbr, and
   as such may serve as a node ID.  No ipn-scheme endpoint ID for which
   service-nbr is non-zero may do so.</t>

	<t>
   Encoding considerations: For
   <dl>
   <dt>Encoding considerations:</dt>
   <dd>For transmission as a BP endpoint ID, the
   scheme-specific part of a URI of the ipn scheme the SSP SHALL <bcp14>SHALL</bcp14> be
   represented as a CBOR array comprising two items.  The first item of
   this array SHALL <bcp14>SHALL</bcp14> be the EID's node number (a number that identifies
   the node) represented as a CBOR unsigned integer.  The second item
   of this array SHALL <bcp14>SHALL</bcp14> be the EID's service number (a number that
   identifies some application service) represented as a CBOR unsigned
   integer.  For all other purposes, URIs of the ipn scheme are encoded
   exclusively in US-ASCII characters.</t>

	<t>
   Interoperability considerations: none.</t>

	<t>
   Security considerations:</t>

   <t>Reliability characters.</dd>
   <dt>Interoperability considerations:</dt>
   <dd>None.</dd>
     <dt>Security considerations:</dt>
     <dd>
       <t><br/></t>
     <dl>
     <dt>Reliability and consistency: none consistency:</dt>
   <dd>None of the BP endpoints identified by the
   URIs of the ipn scheme 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. Bundle authentication Verification of the signature provided by the Block Integrity Block targeting the bundle's primary block, as defined by the Bundle Security Protocol Security <xref target="I-D.ietf-dtn-bpsec"/> target="RFC9172" format="default"/>, is
   required for this purpose.</t>

   <t>Malicious construction: malicious purpose.</dd>
              <dt>Malicious construction:</dt>
   <dd>Malicious construction of a conformant
   ipn-scheme URI is limited to the malicious selection of node numbers and
   the malicious selection of service numbers.  That is, a maliciously
   constructed ipn-scheme URI 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.</t>

   <t>Back-end transcoding: the way.</dd>
              <dt>Back-end transcoding:</dt>
   <dd>The limited expressiveness of URIs of the ipn
   scheme effectively eliminates the possibility of threat due to errors in
   back-end transcoding.</t>

   <t>Rare transcoding.</dd>
              <dt>Rare IP address formats: not formats:</dt>
   <dd>Not relevant, as IP addresses do not appear
   anywhere in conformant ipn-scheme URIs.</t>

   <t>Sensitive information: because URIs.</dd>
              <dt>Sensitive information:</dt>
   <dd>Because ipn-scheme URIs are used only to
   represent the identities of Bundle Protocol endpoints, the risk of
   disclosure of sensitive information due to interception of these URIs is
   minimal.  Examination of ipn-scheme 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.</t>

   <t>Semantic attacks: the
   IDs.</dd>
              <dt>Semantic attacks:</dt>
   <dd>The simplicity of ipn-scheme URI syntax minimizes the
   possibility of misinterpretation of a URI by a human user.
	</t>
 </dd>
</dl>
</dd>
</dl>
            </section>
          </section>
          <section title="Node ID" anchor="sect-4.2.5.2"><t> anchor="sect-4.2.5.2" numbered="true" toc="default">
            <name>Node ID</name>
            <t>
   For many purposes of the Bundle Protocol Protocol, it is important to identify
   the node that is operative in some context.</t>
            <t>
   As discussed in 3.1 above, <xref target="sect-3.1"/>, nodes are distinct from endpoints;
   specifically, an endpoint is a set of zero or more nodes.  But
   rather than define a separate namespace for node identifiers, we
   instead use endpoint identifiers to identify nodes as discussed in
   3.2 above.  Formally:

	<list style="symbols">

	  <t>Every
   <xref target="sect-3.2"/>. Formally:</t>

   <ul spacing="normal">
    <li>Every node is, by definition, permanently registered in the
    singleton endpoint at which administrative records are delivered
    to its application agent's administrative element, termed the
    node's "administrative endpoint".</t>

	  <t>As endpoint".</li>
    <li>As such, the EID of a node's administrative endpoint SHALL <bcp14>SHALL</bcp14>
    uniquely identify that node.</t>

	  <t>A &quot;node ID&quot; is an node.</li>
    <li>The EID of any singleton endpoint is allowed to serve as a "node ID"
   identifying the node that identifies is the
	  administrative endpoint sole member of a node.</t>

	</list>
	</t> that endpoint.</li>
   </ul>

          </section>
        </section>
        <section title="DTN Time" anchor="sect-4.2.6"><t> anchor="sect-4.2.6" numbered="true" toc="default">
          <name>DTN Time</name>
          <t>
   A DTN time is an unsigned integer indicating the number of
   milliseconds that have elapsed since the DTN Epoch, 2000-01-01
   00:00:00 +0000 (UTC).  DTN time is not affected by leap seconds.</t>
          <t>
   Each DTN time SHALL <bcp14>SHALL</bcp14> be represented as a CBOR unsigned integer item.
   Implementers need to be aware that DTN time values conveyed in CBOR
   representation
   encoding in bundles will nearly always exceed (2**32 (2<sup>32</sup> - 1); the
   manner in which a DTN time value is represented in memory is an
   implementation matter.  The DTN time value zero indicates that the
   time is unknown.</t>
        </section>
        <section title="Creation Timestamp" anchor="sect-4.2.7"><t> anchor="sect-4.2.7" numbered="true" toc="default">
          <name>Creation Timestamp</name>
          <t>
   Each bundle's creation timestamp SHALL <bcp14>SHALL</bcp14> be represented as a CBOR
   array comprising two items.</t>
          <t>
   The first item of the array, termed "bundle creation time", SHALL <bcp14>SHALL</bcp14> be
   the DTN time at which the transmission request was received that
   resulted in the creation of the bundle, represented as a CBOR
   unsigned integer.</t>
          <t>
   The second item of the array, termed the creation timestamp's
   "sequence number", SHALL <bcp14>SHALL</bcp14> be the latest value (as of the time at
   which the transmission request was received) of a monotonically
   increasing positive integer counter managed by the source node's
   bundle protocol agent,
   BPA, represented as a CBOR unsigned integer.  The
   sequence counter MAY <bcp14>MAY</bcp14> be reset to zero whenever the current time
   advances by one millisecond.</t>
          <t>
   For nodes that lack accurate clocks, it is recommended that bundle
   creation time be set to zero and that the counter used as the source
   of the bundle sequence count never be reset to zero.</t>
          <t>
   Note that, in general, the creation of two distinct bundles with the
   same source node ID and bundle creation timestamp may result in
   unexpected network behavior and/or suboptimal performance. The
   combination of source node ID and bundle creation timestamp serves
   to identify a single transmission request, enabling it to be
   acknowledged by the receiving application (provided the source node
   ID is not the null endpoint ID).</t>
        </section>
        <section title="Block-type-specific Data" anchor="sect-4.2.8"><t> anchor="sect-4.2.8" numbered="true" toc="default">
          <name>Block-Type-Specific Data</name>
          <t>
   Block-type-specific data in each block (other than the primary
   block) SHALL <bcp14>SHALL</bcp14> be the applicable CBOR representation encoding of the content of
   the block.  Details of this representation are included in the
   specification defining the block type.</t>
        </section>
      </section>
      <section title="Block Structures" anchor="sect-4.3"><t> anchor="sect-4.3" numbered="true" toc="default">
        <name>Block Structures</name>
        <t>
   This section describes the primary block in detail and non-primary
   blocks in general. Rules for processing these blocks appear in
   Section 5 of this document.</t>
   <xref target="sect-5"/>.</t>
        <t>
   Note that supplementary DTN protocol specifications (including, but
   not restricted to, the Bundle Security Protocol Security <xref target="I-D.ietf-dtn-bpsec"/>) target="RFC9172" format="default"/>) may require
   that BP implementations conforming to those protocols construct and
   process additional blocks.</t>
        <section title="Primary anchor="sect-4.3.1" numbered="true" toc="default">
          <name>Primary Bundle Block" anchor="sect-4.3.1"><t> Block</name>
          <t>
   The primary bundle block contains the basic information needed to
   forward bundles to their destinations.</t>
          <t>
   Each primary block SHALL <bcp14>SHALL</bcp14> be represented as a CBOR array; the number
   of elements in the array SHALL <bcp14>SHALL</bcp14> be 8 (if the bundle is not a fragment
   and the block has no CRC), 9 (if the block has a CRC and the bundle
   is not a fragment), 10 (if the bundle is a fragment and the block
   has no CRC), or 11 (if the bundle is a fragment and the block has a
   CRC).</t>
          <t>
   The primary block of each bundle SHALL <bcp14>SHALL</bcp14> be immutable.  The CBOR-encoded CBOR-
   encoded values of all fields in the primary block MUST <bcp14>MUST</bcp14> remain
   unchanged from the time the block is created to the time it is
   delivered.</t>
          <t>
   The fields of the primary bundle block SHALL <bcp14>SHALL</bcp14> be as follows, listed
          in the order in which they MUST <bcp14>MUST</bcp14> appear:</t>

	<t>
   Version: An

          <dl>
          <dt>Version:</dt>
   <dd>An unsigned integer value indicating the version of the
   bundle protocol
   Bundle Protocol that constructed this block. The present document
   describes BPv7. This version 7 of the bundle protocol. Version number SHALL <bcp14>SHALL</bcp14> be
   represented as a CBOR unsigned integer item.</t>

	<t>
   Bundle Processing Control Flags: The Bundle item.</dd>
          <dt>Bundle Processing Control Flags Flags:</dt>
   <dd>The bundle processing control flags
   are discussed in <xref target="sect-4.2.3"/>. above.</t>

	<t>
   CRC Type: CRC Type target="sect-4.2.3" format="default"/>.</dd>
          <dt>CRC Type:</dt>
   <dd>CRC type codes are discussed in <xref target="sect-4.2.1"/>. above. target="sect-4.2.1" format="default"/>.  The
   CRC Type type code for the primary block MAY <bcp14>MAY</bcp14> be zero if the bundle
   contains a BPsec <xref target="I-D.ietf-dtn-bpsec"/> BPSec Block Integrity Block <xref target="RFC9172" format="default"/>
   whose target is the
   primary block; otherwise otherwise, the CRC Type type code for the primary block
   MUST
   <bcp14>MUST</bcp14> be non-zero.</t>

	<t>
   Destination EID: The non-zero.</dd>
          <dt>Destination EID:</dt>
   <dd>The Destination EID field identifies the bundle
   endpoint that is the bundle's destination, i.e., the endpoint that
   contains the node(s) at which the bundle is to be delivered.</t>

	<t>
   Source delivered.</dd>
          <dt>Source node ID: The ID:</dt>
   <dd>The Source node ID field identifies the bundle node
   at which the bundle was initially transmitted, except that Source source
   node ID may be the null endpoint ID in the event that the bundle's
   source chooses to remain anonymous.</t>

	<t>
   Report-to EID: The anonymous.</dd>
          <dt>Report-to EID:</dt>
   <dd>The Report-to EID field identifies the bundle
   endpoint to which status reports pertaining to the forwarding and
   delivery of this bundle are to be transmitted.</t>

	<t>
   Creation Timestamp: The transmitted.</dd>
          <dt>Creation Timestamp:</dt>
   <dd>The creation timestamp comprises two unsigned
   integers that, together with the source node ID and (if the bundle
   is a fragment) the fragment offset and payload length, serve to
   identify the bundle. See 4.2.7 above <xref target="sect-4.2.7"/> for the definition of this
   field.</t>

	<t>
   Lifetime: The lifetime
   field.</dd>
          <dt>Lifetime:</dt>
   <dd>
         <t>The Lifetime field is an unsigned integer that indicates
   the time at which the bundle's payload will no longer be useful,
   encoded as a number of milliseconds past the creation time. (For
   high-rate deployments with very brief disruptions, fine-grained
   expression of bundle lifetime may be useful.)  When a bundle's age
   exceeds its lifetime, bundle nodes need no longer retain or forward
   the bundle; the bundle SHOULD <bcp14>SHOULD</bcp14> be deleted from the network.</t>
          <t>
   If the asserted lifetime for a received bundle is so lengthy that
   retention of the bundle until its expiration time might degrade
   operation of the node at which the bundle is received, or if the
   bundle protocol agent
   BPA of that node determines that the bundle must
   be deleted in order to prevent network performance degradation
   (e.g., the bundle appears to be part of a denial-of-service attack),
   then that bundle protocol agent MAY BPA <bcp14>MAY</bcp14> impose a temporary overriding
   lifetime of shorter duration; such an overriding lifetime SHALL NOT <bcp14>SHALL NOT</bcp14>
   replace the lifetime asserted in the bundle but SHALL <bcp14>SHALL</bcp14> serve as the
   bundle's effective lifetime while the bundle resides at that node.
   Procedures for imposing lifetime overrides are beyond the scope of
   this specification.</t>
          <t>
   For bundles originating at nodes that lack accurate clocks, it is
   recommended that bundle age be obtained from the Bundle Age
   extension block (see 4.4.2 below) <xref target="sect-4.4.2"/>) rather than from the difference
   between current time and bundle creation time.  Bundle lifetime
   SHALL
   <bcp14>SHALL</bcp14> be represented as a CBOR unsigned integer item.</t>

	<t>
   Fragment offset: If
   </dd>
  <dt>Fragment offset:</dt>
   <dd>If and only if the Bundle Processing Control Flags bundle processing control flags
   of this Primary primary block indicate that the bundle is a fragment,
   fragment offset SHALL <bcp14>SHALL</bcp14> be present in the primary block. Fragment
   offset SHALL <bcp14>SHALL</bcp14> be represented as a CBOR unsigned integer indicating
   the offset from the start of the original application data unit ADU at
   which the bytes comprising the payload of this bundle were located.</t>

	<t>
   Total located.</dd>

   <dt>Total Application Data Unit Length: If Length:</dt>
   <dd>If and only if the Bundle
   Processing Control Flags bundle
   processing control flags of this Primary primary block indicate that the
   bundle is a fragment, total application data unit length SHALL <bcp14>SHALL</bcp14> be
   present in the primary block. Total application data unit length
   SHALL
   <bcp14>SHALL</bcp14> be represented as a CBOR unsigned integer indicating the total
   length of the original application data unit ADU of which this bundle's
   payload is a part.</t>

	<t>
   CRC: A part.</dd>

   <dt>CRC:</dt>
   <dd>A CRC SHALL <bcp14>SHALL</bcp14> be present in the primary block unless the bundle includes
   a BPsec <xref target="I-D.ietf-dtn-bpsec"/> BPSec Block Integrity Block <xref target="RFC9172" format="default"/> whose
   target is the primary block, in which case a CRC MAY <bcp14>MAY</bcp14> be present in the
   primary block.  The length and nature of the CRC SHALL <bcp14>SHALL</bcp14> be as indicated by
   the CRC type.  The CRC SHALL <bcp14>SHALL</bcp14> be computed over the concatenation of all
   bytes (including CBOR "break" characters) of the primary block including
   the CRC field itself, which which, for this purpose SHALL purpose, <bcp14>SHALL</bcp14> be temporarily populated
   with all bytes set to zero.</t> zero.</dd>
 </dl>

        </section>
        <section title="Canonical anchor="sect-4.3.2" numbered="true" toc="default">
          <name>Canonical Bundle Block Format" anchor="sect-4.3.2"><t> Format</name>
          <t>
   Every block other than the primary block (all such blocks are termed
   "canonical" blocks) SHALL <bcp14>SHALL</bcp14> be represented as a CBOR array; the number
   of elements in the array SHALL <bcp14>SHALL</bcp14> be 5 (if CRC type is zero) or 6
   (otherwise).</t>
          <t>
   The fields of every canonical block SHALL <bcp14>SHALL</bcp14> be as follows, listed in
   the order in which they MUST appear:

      <list style="symbols">

	<t>Block <bcp14>MUST</bcp14> appear:</t>
          <dl>
           <dt>Block type code, an code:</dt><dd>An unsigned integer. Bundle block type code 1
        indicates that the block is a bundle payload block. Block Bundle Payload Block. Other block type codes 2
	through 9
        are explicitly reserved as noted later described in this
	specification. <xref target="sect-9.1" format="default"/>.
        Block type codes 192 through 255 are not reserved and
        are available for private and/or experimental use.  All other block
        type code values are reserved for future use.</t>

	<t>Block number, an use.</dd>
           <dt>Block number:</dt><dd>An unsigned integer as discussed in 4.1 above.  Block <xref target="sect-4.1"/>.  The block
        number SHALL <bcp14>SHALL</bcp14> be represented as a CBOR unsigned integer.</t>

	<t>Block integer.</dd>
           <dt>Block processing control flags as flags:</dt><dd>As discussed in Section 4.2.4
	above.</t>

	<t>CRC type as <xref target="sect-4.2.4"/>.</dd>
           <dt>CRC type:</dt><dd>As discussed in <xref target="sect-4.2.1"/> above.</t>

	<t>Block-type-specific data represented target="sect-4.2.1" format="default"/>.</dd>
           <dt>Block-type-specific data:</dt><dd>Represented as a single definite-length
        CBOR byte string, i.e., a CBOR byte string that is not of indefinite
        length.  For each type of block, the block-type- specific block-type-specific data byte
        string is the serialization, in a block- type-specific block-type-specific manner, of the
        data conveyed by that type of block; definitions of blocks are
        required to define the manner in which block-type-specific data are
        serialized within the block-type-specific data field. For the Bundle Payload
        Block in particular (block type 1), the block-type-specific data
        field, termed the "payload", SHALL <bcp14>SHALL</bcp14> be an application data unit, ADU, or
        some contiguous extent thereof, represented as a definite- length definite-length CBOR
        byte string.
	</t>

	<t>If string.</dd>
           <dt>If and only if the value of the CRC type field of this block is
	non-zero, a
        non-zero:</dt><dd>A CRC. If present, the length and nature of the CRC SHALL <bcp14>SHALL</bcp14> be
        as indicated by the CRC type and the CRC SHALL <bcp14>SHALL</bcp14> be computed over the
        concatenation of all bytes of the block (including CBOR "break"
        characters) including the CRC field itself, which which, for this purpose
	SHALL purpose,
        <bcp14>SHALL</bcp14> be temporarily populated with all bytes set to zero.</t>

	</list>
	</t> zero.</dd>
       </dl>
        </section>
      </section>
      <section title="Extension Blocks" anchor="sect-4.4"><t>
   "Extension anchor="sect-4.4" numbered="true" toc="default">
        <name>Extension Blocks</name>
        <t>"Extension blocks" are all blocks other than the primary and payload
   blocks. Three types of extension blocks are defined below.  All
   implementations of the Bundle Protocol specification (the present
   document) MUST <bcp14>MUST</bcp14> include procedures for recognizing, parsing, and
   acting on, but not necessarily producing, these types of extension
   blocks.</t>
        <t>
   The specifications for additional types of extension blocks must
   indicate whether or not BP implementations conforming to those
   specifications must recognize, parse, act on, and/or produce blocks
   of those types.  As not all nodes will necessarily instantiate BP
   implementations that conform to those additional specifications, it
   is possible for a node to receive a bundle that includes extension
   blocks that the node cannot process. The values of the block
   processing control flags indicate the action to be taken by the
   bundle protocol agent
   BPA when this is the case.</t>
        <t>
   No mandated procedure in this specification is unconditionally
   dependent on the absence or presence of any extension block.
   Therefore
   Therefore, any bundle protocol agent MAY BPA <bcp14>MAY</bcp14> insert or remove any
   extension block in any bundle, subject to all mandates in the Bundle
   Protocol specification and all extension block specifications to
   which the node's BP implementation conforms.  Note that removal of
   an extension block will probably disable one or more elements of
   bundle processing that were intended by the BPA that inserted that
   block.  In particular, note that removal of an extension block that
   is one of the targets of a BPsec BPSec security block may render the
   bundle unverifiable.</t>
        <t>
   The following extension blocks are defined in the current document.</t>
        <section title="Previous Node" anchor="sect-4.4.1"><t> anchor="sect-4.4.1" numbered="true" toc="default">
          <name>Previous Node</name>
          <t>
   The Previous Node block, Block, block type 6, identifies the node that
   forwarded this bundle to the local node (i.e., to the node at which
   the bundle currently resides); its block-type-specific data is the
   node ID of that forwarder node which SHALL take the form of a node.  That node ID represented as described in <bcp14>SHALL</bcp14> conform to <xref target="sect-4.2.5.2"/>. above. target="sect-4.2.5.2" format="default"/>.
   If the local
   node is the source of the bundle, then the bundle MUST NOT <bcp14>MUST NOT</bcp14> contain
   any Previous Node block.  Otherwise Block.  Otherwise, the bundle SHOULD <bcp14>SHOULD</bcp14> contain one
   (1) occurrence of this type of block and MUST NOT <bcp14>MUST NOT</bcp14> contain more than
   one.</t>
        </section>
        <section title="Bundle Age" anchor="sect-4.4.2"><t> anchor="sect-4.4.2" numbered="true" toc="default">
          <name>Bundle Age</name>
          <t>
   The Bundle Age block, Block, block type 7, contains the number of
   milliseconds that have elapsed between the time the bundle was
   created and the time at which it was most recently forwarded.  It is
   intended for use by nodes lacking access to an accurate clock, to
   aid in determining the time at which a bundle's lifetime expires.
   The block-type-specific data of this block is an unsigned integer
   containing the age of the bundle in milliseconds, which SHALL <bcp14>SHALL</bcp14> be
   represented as a CBOR unsigned integer item. (The age of the bundle
   is the sum of all known intervals of the bundle's residence at
   forwarding nodes, up to the time at which the bundle was most
   recently forwarded, plus the summation of signal propagation time
   over all episodes of transmission between forwarding nodes.
   Determination of these values is an implementation matter.) If the
   bundle's creation time is zero, then the bundle MUST <bcp14>MUST</bcp14> contain exactly
   one (1) occurrence of this type of block; otherwise, the bundle MAY <bcp14>MAY</bcp14>
   contain at most one (1) occurrence of this type of block.  A bundle
   MUST NOT
   <bcp14>MUST NOT</bcp14> contain multiple occurrences of the bundle age block, Bundle Age Block, as
   this could result in processing anomalies.</t>
        </section>
        <section title="Hop Count" anchor="sect-4.4.3"><t> anchor="sect-4.4.3" numbered="true" toc="default">
          <name>Hop Count</name>
          <t>
   The Hop Count block, Block, block type 10, contains two unsigned integers, integers:
   hop limit and hop count.  A "hop" is here defined as an occasion on
   which a bundle was forwarded from one node to another node.  Hop  The hop
   limit MUST <bcp14>MUST</bcp14> be in the range 1 through 255. The hop limit value SHOULD
   NOT <bcp14>SHOULD
   NOT</bcp14> be changed at any time after creation of the Hop Count block; Block;
   the hop count value SHOULD <bcp14>SHOULD</bcp14> initially be zero and SHOULD <bcp14>SHOULD</bcp14> be increased
   by 1 on each hop.</t>
          <t>
   The hop count block Hop Count Block is mainly intended as a safety mechanism, a
   means of identifying bundles for removal from the network that can
   never be delivered due to a persistent forwarding error.  Hop  The hop count
   is particularly valuable as a defense against routing anomalies that
   might cause a bundle to be forwarded in a cyclical "ping-pong"
   fashion between two nodes.  When a bundle's hop count exceeds its
   hop limit, the bundle SHOULD <bcp14>SHOULD</bcp14> be deleted for the reason "hop "Hop limit exceeded", following the bundle deletion Bundle Deletion procedure defined in
   <xref target="sect-5.10"/>.</t> target="sect-5.10" format="default"/>.</t>
          <t>
   Procedures for determining the appropriate hop limit for a bundle
   are beyond the scope of this specification.</t>
          <t>
   The block-type-specific data in a hop count block SHALL Hop Count Block <bcp14>SHALL</bcp14> be
   represented as a CBOR array comprising two items.  The first item of
   this array SHALL <bcp14>SHALL</bcp14> be the bundle's hop limit, represented as a CBOR
   unsigned integer.  The second item of this array SHALL <bcp14>SHALL</bcp14> be the
   bundle's hop count, represented as a CBOR unsigned integer. A bundle
   MAY
   <bcp14>MAY</bcp14> contain one occurrence of this type of block but MUST NOT <bcp14>MUST NOT</bcp14>
   contain more than one.</t>
        </section>
      </section>
    </section>
    <section title="Bundle Processing" anchor="sect-5"><t> anchor="sect-5" numbered="true" toc="default">
      <name>Bundle Processing</name>
      <t>
   The bundle processing bundle-processing procedures mandated in this section and in
   <xref target="sect-6"/> target="sect-6" format="default"/> govern the operation of the Bundle Protocol Agent BPA and the
   Application Agent
   application agent administrative element of each bundle node. They
   are neither exhaustive nor exclusive. Supplementary DTN protocol
   specifications (including, but not restricted to, the Bundle
   Security Protocol
   Security <xref target="I-D.ietf-dtn-bpsec"/>) target="RFC9172" format="default"/>) may augment, override, or supersede the
   mandates of this document.</t>
      <section title="Generation anchor="sect-5.1" numbered="true" toc="default">
        <name>Generation of Administrative Records" anchor="sect-5.1"><t> Records</name>
        <t>
   All transmission of bundles is in response to bundle transmission
   requests presented by nodes' application agents. When required to
   "generate" an administrative record (such as a bundle status
   report), the bundle protocol agent BPA itself is responsible for causing
   a new bundle to be transmitted, conveying that record. In concept,
   the bundle protocol agent BPA discharges this responsibility by
   directing the administrative element of the node's application agent
   to construct the record and request its transmission as detailed in
   <xref target="sect-6"/> below. target="sect-6" format="default"/>. In practice, the manner in which administrative
   record generation is accomplished is an implementation matter,
   provided the constraints noted in <xref target="sect-6"/> target="sect-6" format="default"/> are observed.</t>
        <t>
   Status reports are relatively small bundles.  Moreover, even when
   the generation of status reports is enabled enabled, the decision on whether
   or not to generate a requested status report is left to the
   discretion of the bundle protocol agent. BPA.  Nonetheless, note that
   requesting status reports for any single bundle might easily result
   in the generation of (1 + (2 *(N-1))) status report bundles, where N
   is the number of nodes on the path from the bundle's source to its
   destination, inclusive.  That is, the requesting of status reports
   for large numbers of bundles could result in an unacceptable
   increase in the bundle traffic in the network. For this reason, the
   generation of status reports MUST <bcp14>MUST</bcp14> be disabled by default and enabled
   only when the risk of excessive network traffic is deemed
   acceptable.  Mechanisms that could assist in assessing and
   mitigating this risk, such as pre-placed agreements authorizing the
   generation of status reports under specified circumstances, are
   beyond the scope of this specification.</t>

	<t>
   Notes

   <t>Notes on administrative record terminology:

	<list style="symbol">

	  <t>A terminology:</t>
        <ul spacing="normal">
          <li>A "bundle reception status report report" is a bundle status report with
          the "reporting "Reporting node received bundle" flag set to 1.</t>

	  <t>A 1.</li>
          <li>A "bundle forwarding status report" is a bundle status report
          with the "reporting "Reporting node forwarded the bundle" flag set to 1.</t>

	  <t>A 1.</li>
          <li>A "bundle delivery status report" is a bundle status report with
          the "reporting "Reporting node delivered the bundle" flag set to 1.</t>

	  <t>A 1.</li>
          <li>A "bundle deletion status report" is a bundle status report with
          the "reporting "Reporting node deleted the bundle" flag set to 1.</t>

	</list>
	</t> 1.</li>
        </ul>
      </section>
      <section title="Bundle Transmission" anchor="sect-5.2"><t> anchor="sect-5.2" numbered="true" toc="default">
        <name>Bundle Transmission</name>
        <t>
        The steps in processing a bundle transmission request are:</t>

	<t>
   Step 1: are as follows:</t>
        <ol type="Step %d:" indent="9">
        <li>
   Transmission of the bundle is initiated. An outbound bundle
   MUST
   <bcp14>MUST</bcp14> be created per the parameters of the bundle transmission
   request, with the retention constraint "Dispatch pending". The
   source node ID of the bundle MUST <bcp14>MUST</bcp14> be either (a) the null endpoint ID,
   indicating that the source of the bundle is anonymous, anonymous or else (b) the
   EID of a singleton endpoint whose only member is the node of which
   the BPA is a component.</t>

	<t>
   Step 2: component.</li>

  <li> Processing proceeds from Step 1 of <xref target="sect-5.4"/>.</t> target="sect-5.4" format="default"/>.</li>
        </ol>

      </section>
      <section title="Bundle Dispatching" anchor="sect-5.3"><t> anchor="sect-5.3" numbered="true" toc="default">
        <name>Bundle Dispatching</name>
        <t>
   (Note that this procedure is initiated only following completion of
   Step 4 of <xref target="sect-5.6"/>.)</t> target="sect-5.6" format="default"/>.)</t>
        <t>
        The steps in dispatching a bundle are:</t>

	<t>
   Step 1: are as follows:</t>
        <ol type="Step %d:" indent="9">
        <li>
  If the bundle's destination endpoint is an endpoint of which
   the node is a member, the bundle delivery Bundle Delivery procedure defined in
   <xref target="sect-5.7"/> MUST target="sect-5.7" format="default"/> <bcp14>MUST</bcp14> be followed and and, for the purposes of all subsequent
   processing of this bundle at this node node, the node's membership in the
   bundle's destination endpoint SHALL <bcp14>SHALL</bcp14> be disavowed; specifically, even
   though the node is a member of the bundle's destination endpoint,
   the node SHALL NOT <bcp14>SHALL NOT</bcp14> undertake to forward the bundle to itself in the
   course of performing the procedure described in <xref target="sect-5.4"/>.</t>

	<t>
   Step 2: target="sect-5.4" format="default"/>.</li>

          <li> Processing proceeds from Step 1 of <xref target="sect-5.4"/>.</t> target="sect-5.4" format="default"/>.</li>
        </ol>

      </section>
      <section title="Bundle Forwarding" anchor="sect-5.4"><t> anchor="sect-5.4" numbered="true" toc="default">
        <name>Bundle Forwarding</name>
        <t>
        The steps in forwarding a bundle are:</t>

	<t>
   Step 1: The are as follows:</t>
        <ol type="Step %d:" indent="9">

  <li>The retention constraint "Forward pending" MUST <bcp14>MUST</bcp14> be added to
   the bundle, and the bundle's "Dispatch pending" retention constraint
   MUST
   <bcp14>MUST</bcp14> be removed.</t>

	<t>
   Step 2: The bundle protocol agent MUST removed.</li>
   <li><t>The BPA <bcp14>MUST</bcp14> determine whether or not
   forwarding is contraindicated (that is, rendered inadvisable) for
   any of the reasons listed in the IANA registry of Bundle "Bundle Status Report Reason Codes Codes" registry
   (see section 10.5 below), <xref target="sect-9.5"/>), whose initial contents
   are listed in Figure 4.  <xref target="tab-1"/>. In particular:

	<list style="symbols">

	  <t>The bundle protocol agent MAY particular:</t>

        <ul spacing="normal">
          <li>The BPA <bcp14>MAY</bcp14> choose either to either forward the bundle
          directly to its destination node(s) (if possible) or to forward the
          bundle to some other node(s) for further forwarding. The manner in
          which this decision is made may depend on the scheme name in the
          destination endpoint ID and/or on other state but in any case is
          beyond the scope of this document; one possible mechanism is
          described in [SABR]. <xref target="SABR"/>. If the BPA elects to forward the bundle to some
          other node(s) for further forwarding but finds it impossible to
          select any node(s) to forward the bundle to, then forwarding is
	  contraindicated.</t>

	  <t>Provided
          contraindicated.</li>
          <li>Provided the bundle protocol agent BPA succeeded in selecting the
	  node(s)
          node or nodes to forward the bundle to, the bundle protocol agent MUST BPA <bcp14>MUST</bcp14>
          subsequently select the convergence layer adapter(s) CLA(s) whose services
          will enable the node to send the bundle to those nodes.  The manner
          in which specific appropriate convergence layer adapters CLAs are
          selected is beyond the scope of this document; the TCP
	  convergence-layer adapter
          CLA <xref target="I-D.ietf-dtn-tcpclv4"/> MUST target="RFC9174" format="default"/> <bcp14>MUST</bcp14>
          be implemented when some or all of the bundles forwarded by the
	  bundle protocol agent
          BPA must be forwarded via the Internet but may not
          be appropriate for the forwarding of any particular bundle. If the
          agent finds it impossible to select any appropriate convergence
	  layer adapter(s) CLA(s) to use in forwarding this bundle, then forwarding
          is contraindicated.</t>

	</list>
	</t>

	<t>
   Step 3: contraindicated.</li>
        </ul>
        </li>

        <li>
   If forwarding of the bundle is determined to be
   contraindicated for any of the reasons listed in the IANA registry
   of Bundle "Bundle Status Report
   Reason Codes Codes" registry (see section 10.5 below), <xref target="sect-9.5"/>), then
   the Forwarding Contraindicated procedure defined in <xref target="sect-5.4.1"/>
   MUST target="sect-5.4.1" format="default"/>
   <bcp14>MUST</bcp14> be followed; the remaining steps of <xref target="sect-5.4"/> this Bundle Forwarding procedure are skipped at this time.</t>

	<t>
   Step 4: For time.</li>

  <li><t>For each node selected for forwarding, the bundle protocol
   agent MUST BPA <bcp14>MUST</bcp14> invoke the services of the selected convergence layer
   adapter(s) CLA(s) in order to effect the sending of the bundle to that
   node. Determining the time at which the bundle protocol agent BPA
   invokes convergence layer adapter CLA services is a BPA implementation
   matter.  Determining the time at which each convergence layer
   adapter CLA subsequently responds to this service invocation by sending
   the bundle is a convergence-layer adapter CLA implementation matter.
  Note that:

	<list style="symbols">

	  <t>If that:</t>

        <ul spacing="normal">
          <li>If the bundle has a Previous Node block, Block, as defined in 4.4.1
	  above, <xref target="sect-4.4.1"/>,
          then that block MUST <bcp14>MUST</bcp14> be removed from the bundle before the
          bundle is forwarded.</t>

	  <t>If forwarded.</li>
          <li>If the bundle protocol agent BPA is configured to attach Previous
          Node blocks Blocks to forwarded bundles, then a Previous Node block Block
          containing the node ID of the forwarding node MUST <bcp14>MUST</bcp14> be inserted into
          the bundle before the bundle is forwarded.</t>

	  <t>If forwarded.</li>
          <li>If the bundle has a bundle age block, Bundle Age Block, as defined in 4.4.2.
	  above, <xref target="sect-4.4.2"/>,
          then at the last possible moment before the CLA initiates
          conveyance of the bundle via the CL protocol the bundle age value
	  MUST
          <bcp14>MUST</bcp14> be increased by the difference between the current time and the
          time at which the bundle was received (or, if the local node is the
          source of the bundle, created).</t>

	</list>
	</t>

	<t>
   Step 5: created).</li>
        </ul>
        </li>
        <li>
   When all selected convergence layer adapters CLAs have informed
   the bundle protocol agent BPA that they have concluded their data
   sending data-sending procedures
   with regard to this bundle, processing may depend on the results of those procedures.</t>
   procedures.</li>
        </ol>
       <t>
   If completion of the data sending data-sending procedures by all selected
   convergence layer adapters
   CLAs has not resulted in successful forwarding
   of the bundle (an implementation-specific determination that is
   beyond the scope of this specification), then the bundle protocol
   agent MAY BPA <bcp14>MAY</bcp14> choose (in an implementation-specific manner, again beyond
   the scope of this specification) to initiate another attempt to
   forward the bundle.  In that event, processing proceeds from Step 4.
   The minimum number of times a given node will initiate another
   forwarding attempt for any single bundle in this event (a number
   which
   that may be zero) is a node configuration parameter that must be
   exposed to other nodes in the network to the extent that this is
   required by the operating environment.</t>
        <t>
   If completion of the data sending data-sending procedures by all selected
   convergence layer adapters HAS
   CLAs <strong>HAS</strong> resulted in successful forwarding of
   the bundle, or if it has not but the bundle protocol agent BPA does not
   choose to initiate another attempt to forward the bundle, then:

	<list style="symbols">

	  <t>If
        </t>
        <ul spacing="normal">
          <li>If the "request reporting of bundle forwarding" flag in the
          bundle's status report request field is set to 1, 1 and status
          reporting is enabled, then a bundle forwarding status report SHOULD <bcp14>SHOULD</bcp14>
          be generated, destined for the bundle's report-to endpoint ID. The
          reason code on this bundle forwarding status report MUST <bcp14>MUST</bcp14> be "no
          additional information".</t>

	  <t>If information".</li>
          <li>If any applicable bundle protocol Bundle Protocol extensions mandate generation
          of status reports upon conclusion of convergence-layer data sending data-sending
          procedures, all such status reports SHOULD <bcp14>SHOULD</bcp14> be generated with
          extension-mandated reason codes.</t>

	  <t>The codes.</li>
          <li>The bundle's "Forward pending" retention constraint MUST <bcp14>MUST</bcp14> be
	  removed.</t>

	</list>
	</t>
          removed.</li>
        </ul>
        <section title="Forwarding Contraindicated" anchor="sect-5.4.1"><t> anchor="sect-5.4.1" numbered="true" toc="default">
          <name>Forwarding Contraindicated</name>
          <t>
   The steps in responding to contraindication of forwarding are:</t>

	<t>
   Step 1: The bundle protocol agent MUST are as follows:</t>

     <ol type="Step %d:" indent="9">
  <li>The BPA <bcp14>MUST</bcp14> determine whether or not to
   declare failure in forwarding the bundle. Note: this This decision is
   likely to be influenced by the reason for which forwarding is
   contraindicated.</t>

	<t>
   Step 2:
   contraindicated.</li>
          <li>
   If forwarding failure is declared, then the Forwarding
          Failed procedure defined in <xref target="sect-5.4.2"/> MUST target="sect-5.4.2" format="default"/> <bcp14>MUST</bcp14> be followed.</t> followed.</li>
     </ol>
          <t>
   Otherwise, when - -- at some future time - -- the forwarding of this
   bundle ceases to be contraindicated, processing proceeds from Step 4
          of <xref target="sect-5.4"/>.</t> target="sect-5.4" format="default"/>.</t>

        </section>
        <section title="Forwarding Failed" anchor="sect-5.4.2"><t> anchor="sect-5.4.2" numbered="true" toc="default">
          <name>Forwarding Failed</name>
          <t>
   The steps in responding to a declaration of forwarding failure are:</t>

	<t>
   Step 1: The bundle protocol agent MAY are as follows:</t>

     <ol type="Step %d:" indent="9">
   <li>The BPA <bcp14>MAY</bcp14> forward the bundle back to the
   node that sent it, as identified by the Previous Node block, Block, if
   present.  This forwarding, if performed, SHALL <bcp14>SHALL</bcp14> be accomplished by
   performing Step 4 and Step 5 of section 5.4 <xref target="sect-5.4"/> where the sole node
   selected for forwarding SHALL <bcp14>SHALL</bcp14> be the node that sent the bundle.</t>

	<t>
   Step 2: bundle.</li>
          <li>
   If the bundle's destination endpoint is an endpoint of which
   the node is a member, then the bundle's "Forward pending" retention
   constraint MUST <bcp14>MUST</bcp14> be removed. Otherwise, the bundle MUST <bcp14>MUST</bcp14> be deleted:
   the bundle deletion Bundle Deletion procedure defined in <xref target="sect-5.10"/> MUST target="sect-5.10" format="default"/> <bcp14>MUST</bcp14> be
   followed, citing the reason for which forwarding was determined to
          be contraindicated.</t> contraindicated.</li>
     </ol>
        </section>
      </section>
      <section title="Bundle Expiration" anchor="sect-5.5"><t> anchor="sect-5.5" numbered="true" toc="default">
        <name>Bundle Expiration</name>
        <t>
   A bundle expires when the bundle's age exceeds its lifetime as
   specified in the primary bundle block or as overridden by the bundle
   protocol agent. BPA. Bundle age MAY <bcp14>MAY</bcp14> be determined by subtracting the
   bundle's creation timestamp time from the current time if (a) that
   timestamp time is not zero and (b) the local node's clock is known
   to be accurate; otherwise otherwise, bundle age MUST <bcp14>MUST</bcp14> be obtained from the
   Bundle Age extension block.  Bundle expiration MAY <bcp14>MAY</bcp14> occur at any
   point in the processing of a bundle. When a bundle expires, the
   bundle protocol agent MUST
   BPA <bcp14>MUST</bcp14> delete the bundle for the reason
   "lifetime
   "Lifetime expired" (when the expired lifetime is the lifetime as
   specified in the primary block) or "traffic "Traffic pared" (when the expired
   lifetime is a lifetime override as imposed by the bundle protocol
   agent): BPA): the bundle deletion Bundle Deletion procedure defined in <xref target="sect-5.10"/> MUST target="sect-5.10" format="default"/> <bcp14>MUST</bcp14>
   be followed.</t>
      </section>
      <section title="Bundle Reception" anchor="sect-5.6"><t> anchor="sect-5.6" numbered="true" toc="default">
        <name>Bundle Reception</name>
        <t>
   The steps in processing a bundle that has been received from another
   node are:</t>

	<t>
   Step 1: The are as follows:</t>
        <ol type="Step %d:" indent="9">
   <li>The retention constraint "Dispatch pending" MUST <bcp14>MUST</bcp14> be added to
   the bundle.</t>

	<t>
   Step 2: bundle.</li>
        <li>
   If the "request reporting of bundle reception" flag in the
   bundle's status report request field is set to 1, 1 and status
   reporting is enabled, then a bundle reception status report with
   reason code "No additional information" SHOULD <bcp14>SHOULD</bcp14> be generated,
   destined for the bundle's report-to endpoint ID.</t>

	<t>
   Step 3: ID.</li>
        <li>
   CRCs SHOULD <bcp14>SHOULD</bcp14> be computed for every block of the bundle that
   has an attached CRC.  If any block of the bundle is malformed
   according to this specification (including syntactically invalid
   CBOR), or if any block has an attached CRC and the CRC computed for
   this block upon reception differs from that attached CRC, then the
   bundle protocol agent MUST
   BPA <bcp14>MUST</bcp14> delete the bundle for the reason "Block unintelligible".  The bundle deletion Bundle Deletion procedure defined in <xref target="sect-5.10"/> MUST target="sect-5.10" format="default"/> <bcp14>MUST</bcp14> be followed followed, and all remaining steps of the bundle
   reception Bundle
   Reception procedure MUST <bcp14>MUST</bcp14> be skipped.</t>

	<t>
   Step 4: For skipped.</li>
        <li>
   <t>For each block in the bundle that is an extension block that
   the bundle protocol agent BPA cannot process:

	<list style="symbols">

	  <t>If process:</t>

        <ul spacing="normal">
          <li>If the block processing control flags in that block indicate that a
          status report is requested in this event, event and if status reporting is
          enabled, then a bundle reception status report with reason code
          "Block unsupported" SHOULD <bcp14>SHOULD</bcp14> be generated, destined for the bundle's
          report-to endpoint ID.</t>

	  <t>If ID.</li>
          <li>If the block processing control flags in that block indicate that the
          bundle must be deleted in this event, then the bundle protocol agent
	  MUST BPA
          <bcp14>MUST</bcp14> delete the bundle for the reason "Block unsupported"; the
	  bundle deletion
          Bundle Deletion procedure defined in <xref target="sect-5.10"/> MUST target="sect-5.10" format="default"/> <bcp14>MUST</bcp14>
          be followed followed, and all remaining steps of the bundle reception Bundle Reception
          procedure MUST <bcp14>MUST</bcp14> be skipped.</t>

	  <t>If skipped.</li>
          <li>If the block processing control flags in that block do NOT <strong>NOT</strong> indicate that
          the bundle must be deleted in this event but do indicate that the
          block must be discarded, then the bundle protocol agent MUST BPA <bcp14>MUST</bcp14> remove
          this block from the bundle.</t>

	  <t>If bundle.</li>
          <li>If the block processing control flags in that block indicate neither indicate that
          the bundle must be deleted nor that indicate that the block must be
          discarded, then processing continues with the next extension block
          that the bundle protocol agent BPA cannot process, if any; otherwise,
          processing proceeds from step 5.</t>

	</list>
	</t>

	<t> Step 5: 5.</li>
        </ul>
        </li>

        <li>
        Processing proceeds from Step 1 of <xref target="sect-5.3"/>.</t> target="sect-5.3" format="default"/>.</li>
        </ol>

      </section>
      <section title="Local anchor="sect-5.7" numbered="true" toc="default">
        <name>Local Bundle Delivery" anchor="sect-5.7"><t> Delivery</name>
        <t>
   The steps in processing a bundle that is destined for an endpoint of
        which this node is a member are:</t>

	<t>
   Step 1: are as follows:</t>
        <ol type="Step %d:" indent="9">
        <li>
   If the received bundle is a fragment, the application data
   unit reassembly ADU Reassembly procedure described in <xref target="sect-5.9"/> MUST target="sect-5.9" format="default"/> <bcp14>MUST</bcp14> be followed.
   If this procedure results in reassembly of the entire original
   application data unit,
   ADU, processing of the fragmentary bundle whose
   payload has been replaced by the reassembled application data unit ADU
   (whether this bundle or a previously received fragment) proceeds
   from Step 2; otherwise, the retention constraint "Reassembly pending" MUST <bcp14>MUST</bcp14> be added to the bundle bundle, and all remaining steps of this
   procedure MUST <bcp14>MUST</bcp14> be skipped.</t>

	<t>
   Step 2: Delivery skipped.</li>
        <li>
   <t>Delivery depends on the state of the registration whose
   endpoint ID matches that of the destination of the bundle:

        <list style="symbols">

	  <t>An bundle:</t>

        <ul spacing="normal">
          <li>An additional implementation-specific delivery deferral procedure
	  MAY
          <bcp14>MAY</bcp14> optionally be associated with the registration.</t>

	  <t>If registration.</li>
          <li>If the registration is in the Active state, then the bundle MUST <bcp14>MUST</bcp14>
          be delivered automatically as soon as it is the next bundle that is
          due for delivery according to the BPA's bundle delivery scheduling
	  policy, an
          policy (an implementation matter.</t> matter).</li>
          <li>
            <t>If the registration is in the Passive state, or if delivery of
          the bundle fails for some implementation-specific reason, then the
          registration's delivery failure action MUST <bcp14>MUST</bcp14> be taken. Delivery The
          delivery failure action MUST <bcp14>MUST</bcp14> be one of the following:

	     <list style="symbols">

	       <t>defer
            </t>
            <ul spacing="normal">
              <li>Defer delivery of the bundle subject to this registration
               until (a) this bundle is the least recently received of all
               bundles currently deliverable subject to this registration and
               (b) either the registration is polled or else the registration
               is in the Active state, and also perform any additional
               delivery deferral procedure associated with the registration;
	       or</t>

	       <t>abandon registration,
               or</li>
              <li>Abandon delivery of the bundle subject to this registration
               (as defined in 3.1. ).</t>

	</list>
	</t>

	</list>
	</t>

	<t>
   Step 3: <xref target="sect-3.1"/>).</li>
            </ul>
          </li>
        </ul>
        </li>

        <li>
   As soon as the bundle has been delivered, if the "request reporting of bundle delivery" flag in the bundle's status report
   request field is set to 1 and bundle status reporting is enabled,
   then a bundle delivery status report SHOULD <bcp14>SHOULD</bcp14> be generated, destined
   for the bundle's report-to endpoint ID. Note that this status report
   only states that the payload has been delivered to the application
        agent, not that the application agent has processed that payload.</t> payload.</li>
      </ol>

      </section>
      <section title="Bundle Fragmentation" anchor="sect-5.8"><t> anchor="sect-5.8" numbered="true" toc="default">
        <name>Bundle Fragmentation</name>
        <t>
   It may at times be advantageous for bundle protocol agents BPAs to reduce
   the sizes of bundles in order to forward them. This might be the
   case, for example, if a node to which a bundle is to be forwarded is
   accessible only via intermittent contacts and no upcoming contact is
   long enough to enable the forwarding of the entire bundle.</t>
        <t>
   The size of a bundle can be reduced by "fragmenting" the bundle. To
   fragment a bundle whose payload is of size M is to replace it with
   two "fragments" - -- new bundles with the same source node ID and
   creation timestamp as the original bundle - -- whose payloads MUST <bcp14>MUST</bcp14> be
   the first N and the last (M - N) bytes of the original bundle's
   payload, where 0 &lt; N &lt; M.</t>
        <t>
   Note that fragments are bundles and therefore may themselves be
   fragmented, so multiple episodes of fragmentation may in effect
   replace the original bundle with more than two fragments. (However,
   there is only one 'level' "level" of fragmentation, as in IP fragmentation.)</t>
        <t>
   Any bundle whose primary block's bundle processing control flags do NOT <strong>NOT</strong>
   indicate that it must not be fragmented MAY <bcp14>MAY</bcp14> be fragmented at any
   time, for any purpose, at the discretion of the bundle protocol
   agent.  NOTE, BPA.  <strong>NOTE</strong>, however, that some combinations of bundle
   fragmentation, replication, and routing might result in unexpected
   traffic patterns.</t>
        <t>
   Fragmentation SHALL <bcp14>SHALL</bcp14> be constrained as follows:

        <list style="symbols">

	  <t>The

        </t>
        <ul spacing="normal">
          <li>The concatenation of the payloads of all fragments produced by
          fragmentation MUST <bcp14>MUST</bcp14> always be identical to the payload of the
          fragmented bundle (that is, the bundle that is being
          fragmented). Note that the payloads of fragments resulting from
          different fragmentation episodes, in different parts of the network,
          may be overlapping subsets of the fragmented bundle's payload.</t>

	  <t>The payload.</li>
          <li>The primary block of each fragment MUST <bcp14>MUST</bcp14> differ from that of the
          fragmented bundle, in that the bundle processing control flags of the
          fragment MUST <bcp14>MUST</bcp14> indicate that the bundle is a fragment and both
          fragment offset and total application data unit length must be
          provided.  Additionally, the CRC of the primary block of the
          fragmented bundle, if any, MUST <bcp14>MUST</bcp14> be replaced in each fragment by a
          new CRC computed for the primary block of that fragment.</t>

	  <t>The fragment.</li>
          <li>The payload blocks of fragments will differ from that of the
          fragmented bundle as noted above.</t>

	  <t>If above.</li>
          <li>If the fragmented bundle is not a fragment or is the fragment
          with offset zero, then all extension blocks of the fragmented bundle
	  MUST
          <bcp14>MUST</bcp14> be replicated in the fragment whose offset is zero.</t>

	  <t>Each zero.</li>
          <li>Each of the fragmented bundle's extension blocks whose "Block
          must be replicated in every fragment" flag is set to 1 MUST <bcp14>MUST</bcp14> be
          replicated in every fragment. </t>

	  <t>Beyond </li>
          <li>Beyond these rules, rules for the replication of extension blocks
          in the fragments must be defined in the specifications for those
          extension block types.</t>

	</list>
	</t> types.</li>
        </ul>
      </section>
      <section title="Application anchor="sect-5.9" numbered="true" toc="default">
        <name>Application Data Unit Reassembly" anchor="sect-5.9"><t> Reassembly</name>
        <t>
   Note that the bundle fragmentation Bundle Fragmentation procedure described in 5.8 above <xref target="sect-5.8"/>
   may result in the replacement of a single original bundle with an
   arbitrarily large number of fragmentary bundles.  In order to be
   delivered at a destination node, the original bundle's payload must
   be reassembled from the payloads of those fragments.</t>
        <t>
   The "material extents" of a received fragment's payload are all
   continuous sequences of bytes in that payload that do not overlap
   with the material extents of the payloads of any previously received
   fragments with the same source node ID and creation timestamp.  If
   the concatenation - -- as informed by fragment offsets and payload
   lengths - -- of the material extents of the payloads of this fragment
   and all previously received fragments with the same source node ID
   and creation timestamp as this fragment forms a continuous byte
   array whose length is equal to the total application data unit
   length noted in the fragment's primary block, then:

	<list style="symbols">

	  <t>This

        </t>
        <ul spacing="normal">
          <li>This byte array -- the reassembled application data unit ADU --
	  MUST
          <bcp14>MUST</bcp14> replace the payload of that fragment whose material extents
          include the extent at offset zero.  Note that this will enable
          delivery of the reconstituted original bundle as described in Step 1
          of 5.7.</t>

	  <t>The <xref target="sect-5.7"/>.</li>
          <li>The "Reassembly pending" retention constraint MUST <bcp14>MUST</bcp14> be removed
          from every other fragment with the same source node ID and creation
          timestamp as this fragment.</t>

	</list>
	</t> fragment.</li>
        </ul>
        <t>
   Note: reassembly Reassembly of application data units ADUs from fragments occurs at
   the nodes that are members of destination endpoints as necessary; an
   application data unit MAY
   ADU <bcp14>MAY</bcp14> also be reassembled at some other node on
   the path to the destination.</t>
      </section>
      <section title="Bundle Deletion" anchor="sect-5.10"><t> anchor="sect-5.10" numbered="true" toc="default">
        <name>Bundle Deletion</name>
        <t>
        The steps in deleting a bundle are:</t>

	<t>
   Step 1: are as follows:</t>
        <ol type="Step %d:" indent="9">
        <li>
   If the "request reporting of bundle deletion" flag in the
   bundle's status report request field is set to 1, 1 and if status
   reporting is enabled, then a bundle deletion status report citing
   the reason for deletion SHOULD <bcp14>SHOULD</bcp14> be generated, destined for the
   bundle's report-to endpoint ID.</t>

	<t>
   Step 2: ID.</li>
        <li>
        All of the bundle's retention constraints MUST <bcp14>MUST</bcp14> be removed.</t> removed.</li>
        </ol>
      </section>
      <section title="Discarding anchor="sect-5.11" numbered="true" toc="default">
        <name>Discarding a Bundle" anchor="sect-5.11"><t> Bundle</name>
        <t>
   As soon as a bundle has no remaining retention constraints constraints, it MAY <bcp14>MAY</bcp14> be
   discarded, thereby releasing any persistent storage that may have
   been allocated to it.</t>
      </section>
      <section title="Canceling anchor="sect-5.12" numbered="true" toc="default">
        <name>Canceling a Transmission" anchor="sect-5.12"><t> Transmission</name>
        <t>
   When requested to cancel a specified transmission, where the bundle
   created upon initiation of the indicated transmission has not yet
   been discarded, the bundle protocol agent MUST BPA <bcp14>MUST</bcp14> delete that bundle
   for the reason "transmission cancelled". "Transmission canceled". For this purpose, the
   procedure defined in <xref target="sect-5.10"/> MUST target="sect-5.10" format="default"/> <bcp14>MUST</bcp14> be followed.</t>
      </section>
    </section>
    <section title="Administrative anchor="sect-6" numbered="true" toc="default">
      <name>Administrative Record Processing" anchor="sect-6"><section title="Administrative Records" anchor="sect-6.1"><t> Processing</name>
      <section anchor="sect-6.1" numbered="true" toc="default">
        <name>Administrative Records</name>
        <t>
   Administrative records are standard application data units ADUs that are
   used in providing some of the features of the Bundle Protocol. One
   type
   Bundle Protocol administrative record types are registered in the
   IANA "Bundle Administrative Record Types" registry <xref target="RFC5050"/>;
   of these, only administrative record has been defined to date: bundle type 1, "Bundle status reports. report", is defined
   for BPv7 at this time. Note that additional types of administrative
   records may be defined by supplementary DTN protocol specification
   documents.</t>
        <t>
   Every administrative record consists of:

	<list style="symbols">

	  <t>Record

        </t>
        <ul spacing="normal">
          <li>A record type code (an unsigned integer for which valid values are
          as defined below).</t>

	  <t>Record below).</li>
          <li>Record content in type-specific format.</t>

	</list>
	</t>

	<t>
   Valid administrative record type codes are defined as follows:</t>

<figure title="Administrative Record Type Codes" anchor="fig-3">
<artwork><![CDATA[

+---------+--------------------------------------------+

|  Value  |                   Meaning                  |

+=========+============================================+

|     1   | Bundle status report.                      |

+---------+--------------------------------------------+

| (other) | Reserved for future use.                   |

+---------+--------------------------------------------+
]]></artwork>
	</figure> format.</li>
        </ul>
        <t>
   Each BP administrative record SHALL <bcp14>SHALL</bcp14> be represented as a CBOR array
   comprising two items.</t>
        <t>
   The first item of the array SHALL <bcp14>SHALL</bcp14> be a record type code, which SHALL <bcp14>SHALL</bcp14>
   be represented as a CBOR unsigned integer.</t>
        <t>
   The second element of this array SHALL <bcp14>SHALL</bcp14> be the applicable CBOR
   representation
   encoding of the content of the record.  Details of the CBOR
   representation
   encoding of administrative record type 1 are provided below.
   Details of the CBOR representation encoding of other types of administrative
   record type
   records are included in the specifications defining those
   records.</t>
        <section title="Bundle anchor="sect-6.1.1" numbered="true" toc="default">
          <name>Bundle Status Reports" anchor="sect-6.1.1"><t> Reports</name>
          <t>
   The transmission of "bundle status reports" under specified
   conditions is an option that can be invoked when transmission of a
   bundle is requested. These reports are intended to provide
   information about how bundles are progressing through the system,
   including notices of receipt, forwarding, final delivery, and
   deletion. They are transmitted to the Report-to report-to endpoints of
   bundles.</t>
          <t>
   Each bundle status report SHALL <bcp14>SHALL</bcp14> be represented as a CBOR array.  The
   number of elements in the array SHALL <bcp14>SHALL</bcp14> be either 6 (if the subject
   bundle is a fragment) or 4 (otherwise).</t>
          <t>
   The first item element of the bundle status report array SHALL <bcp14>SHALL</bcp14> be bundle
   status information represented as a CBOR array of at least 4 four
   elements.  The first four items elements of the bundle status information
   array
   shall provide information on the following four status
   assertions, in this order:

	<list style="symbols">

	  <t>Reporting

          </t>
          <ul spacing="normal">
            <li>Reporting node received bundle.</t>

	  <t>Reporting bundle.</li>
            <li>Reporting node forwarded the bundle.</t>

	  <t>Reporting bundle.</li>
            <li>Reporting node delivered the bundle.</t>

	  <t>Reporting bundle.</li>
            <li>Reporting node deleted the bundle.</t>

	</list>
	</t> bundle.</li>
          </ul>
          <t>
   Each item element of the bundle status information array SHALL <bcp14>SHALL</bcp14> be a bundle
   status item represented encoded as a CBOR array; the array.</t>
   <t>The number of elements in
   each such array SHALL bundle status item <bcp14>SHALL</bcp14> be either 2 (if the value of the first item element of
   this
   the bundle status item is 1 AND the "Report status time" flag was
   set to 1 in the bundle processing control flags of the bundle whose status
   is being reported) or 1 (otherwise).  The (otherwise).</t>
   <t>The first item element of the each bundle status item array SHALL <bcp14>SHALL</bcp14>
   be a status indicator, a Boolean value indicating whether or not the
   corresponding bundle status is asserted, represented encoded as a CBOR Boolean value.  The
   If present, the second item element of
   the each bundle status item array, if present, SHALL
   <bcp14>SHALL</bcp14> indicate the time (as reported by the local system clock, clock;
   this is an implementation matter) at which the indicated status was asserted for
   this bundle, represented as a DTN time as described in <xref target="sect-4.2.6"/>. above.</t> target="sect-4.2.6" format="default"/>.</t>
          <t>
   The second item element of the bundle status report array SHALL <bcp14>SHALL</bcp14> be the
   bundle status report reason code explaining the value of the status
   indicator, represented as a CBOR unsigned integer. Valid status
   report reason codes are registered in the IANA Bundle "Bundle Status Report
   Reason Codes registry Codes" subregistry in the Bundle Protocol Namespace "Bundle Protocol" registry (see 10.5
   below). <xref target="sect-9.5"/>).  The initial contents of that registry are listed in Figure
   4 below <xref target="tab-1"/>, but the list of status report reason codes provided here is
   neither exhaustive nor exclusive; supplementary DTN protocol
   specifications (including, but not restricted to, the Bundle
   Security Protocol
   Security <xref target="I-D.ietf-dtn-bpsec"/>) target="RFC9172" format="default"/>) may define additional reason codes.</t>

<figure title="Status
          <table anchor="tab-1" align="left">
            <name>Status Report Reason Codes" anchor="fig-4"><artwork><![CDATA[

+---------+--------------------------------------------+

| Value   |                  Meaning                   |

+=========+============================================+

|    0    | No Codes</name>
            <thead>
              <tr>
                <th>Value</th>
                <th>Meaning</th>
              </tr>
              </thead>
            <tbody>
              <tr>
              <td>0</td>
              <td>No additional information.                 |

+---------+--------------------------------------------+

|    1    | Lifetime expired.                          |

+---------+--------------------------------------------+

|    2    | Forwarded information.</td>
              </tr>
          <tr>
            <td>1</td>
            <td>Lifetime expired.</td>
          </tr>
          <tr>
            <td>2</td>
            <td>Forwarded over unidirectional link.        |

+---------+--------------------------------------------+

|    3    | Transmission canceled.                     |

+---------+--------------------------------------------+

|    4    | Depleted storage.                          |

+---------+--------------------------------------------+

|    5    | Destination link.</td>
          </tr>
          <tr>
            <td>3</td>
            <td>Transmission canceled.</td>
          </tr>
          <tr>
            <td>4</td>
            <td>Depleted storage.</td>
          </tr>
          <tr>
            <td>5</td>
            <td>Destination endpoint ID unavailable.       |

+---------+--------------------------------------------+

|    6    | No unavailable.</td>
          </tr>
          <tr>
            <td>6</td>
            <td>No known route to destination from here.   |

+---------+--------------------------------------------+

|    7    | No here.</td>
          </tr>
          <tr>
            <td>7</td>
            <td>No timely contact with next node on route. |

+---------+--------------------------------------------+

|    8    | Block unintelligible.                      |

+---------+--------------------------------------------+

|    9    | Hop route.</td>
          </tr>
          <tr>
            <td>8</td>
            <td>Block unintelligible.</td>
          </tr>
          <tr>
            <td>9</td>
            <td>Hop limit exceeded.                        |

+---------+--------------------------------------------+

|    10   | Traffic exceeded.</td>
          </tr>
          <tr>
            <td>10</td>
            <td>Traffic pared (e.g., status reports).      |

+---------+--------------------------------------------+

|    11   | Block unsupported.                         |

+---------+--------------------------------------------+

| (other) | Reserved for future use.                   |

+---------+--------------------------------------------+
]]></artwork>
	</figure> reports).</td>
          </tr>
          <tr>
            <td>11</td>
            <td>Block unsupported.</td>
          </tr>
          <tr>
           <td>17-254</td>
           <td>Unassigned</td>
          </tr>
          <tr>
            <td>255</td>
            <td>Reserved</td>
          </tr>
            </tbody>
          </table>

          <t>
   The third item element of the bundle status report array SHALL <bcp14>SHALL</bcp14> be the source
   node ID identifying the source of the bundle whose status is being
   reported, represented as described in <xref target="sect-4.2.5.1.1"/>. above.</t> target="sect-4.2.5.1.1" format="default"/>.</t>
          <t>
   The fourth item element of the bundle status report array SHALL <bcp14>SHALL</bcp14> be the
   creation timestamp of the bundle whose status is being reported,
   represented as described in <xref target="sect-4.2.7"/>. above.</t> target="sect-4.2.7" format="default"/>.</t>
          <t>
   The fifth item element of the bundle status report array SHALL <bcp14>SHALL</bcp14> be present if
   and only if the bundle whose status is being reported contained a
   fragment offset.  If present, it SHALL <bcp14>SHALL</bcp14> be the subject bundle's
   fragment offset represented as a CBOR unsigned integer item.</t>
          <t>
   The sixth item element of the bundle status report array SHALL <bcp14>SHALL</bcp14> be present if
   and only if the bundle whose status is being reported contained a
   fragment offset.  If present, it SHALL <bcp14>SHALL</bcp14> be the length of the subject
   bundle's payload represented as a CBOR unsigned integer item.</t>
          <t>
   Note that the forwarding parameters (such as lifetime, applicable
   security measures, etc.) of the bundle whose status is being
   reported MAY <bcp14>MAY</bcp14> be reflected in the parameters governing the forwarding
   of the bundle that conveys a status report, but this is an
   implementation matter.  Bundle protocol Protocol deployment experience to
   date has not been sufficient to suggest any clear guidance on this
   topic.</t>
        </section>
      </section>
      <section title="Generation anchor="sect-6.2" numbered="true" toc="default">
        <name>Generation of Administrative Records" anchor="sect-6.2"><t> Records</name>
        <t>
   Whenever the application agent's administrative element is directed
   by the bundle protocol agent BPA to generate an administrative record,
        the following procedure must be followed:</t>

	<t>
   Step 1:
        <ol type="Step %d:" indent="9">
        <li>
   The administrative record must be constructed. If the
   administrative record references a bundle and the referenced bundle
   is a fragment, the administrative record MUST <bcp14>MUST</bcp14> contain the fragment
   offset and fragment length.</t>

	<t>
   Step 2: length.</li>
        <li>
   A request for transmission of a bundle whose payload is this
   administrative record MUST <bcp14>MUST</bcp14> be presented to the bundle protocol
   agent.</t> BPA.</li>
        </ol>
      </section>
    </section>
    <section title="Services anchor="sect-7" numbered="true" toc="default">
      <name>Services Required of the Convergence Layer" anchor="sect-7"><section title="The Layer</name>
      <section anchor="sect-7.1" numbered="true" toc="default">
        <name>The Convergence Layer" anchor="sect-7.1"><t> Layer</name>
        <t>
   The successful operation of the end-to-end bundle protocol Bundle Protocol depends
   on the operation of underlying protocols at what is termed the
   "convergence layer"; these protocols accomplish communication
   between nodes. A wide variety of protocols may serve this purpose,
   so long as each convergence layer protocol adapter CLA provides a
   defined minimal set of services to the bundle protocol agent. BPA. This
   convergence layer
   convergence-layer service specification enumerates those services.</t>
      </section>
      <section title="Summary anchor="sect-7.2" numbered="true" toc="default">
        <name>Summary of Convergence Layer Services" anchor="sect-7.2"><t> Convergence-Layer Services</name>
        <t>
   Each convergence layer protocol adapter CLA is expected to provide the
   following services to the bundle protocol agent:

	<list style="symbols">

	  <t>sending BPA:

        </t>
        <ul spacing="normal">
          <li>sending a bundle to a bundle node that is reachable via the
	  convergence layer protocol;</t>

	  <t>notifying
          convergence-layer protocol.</li>
          <li>notifying the bundle protocol agent BPA of the disposition of its
	  data sending
          data-sending procedures with regard to a bundle, upon concluding
          those procedures;</t>

	  <t>delivering procedures.</li>
          <li>delivering to the bundle protocol agent BPA a bundle that was sent by
          a bundle node via the convergence layer protocol.</t>

	</list>
	</t> convergence-layer protocol.</li>
        </ul>
        <t>
   The convergence layer convergence-layer service interface specified here is neither
   exhaustive nor exclusive. That is, supplementary DTN protocol
   specifications (including, but not restricted to, the Bundle
   Security Protocol
   Security <xref target="I-D.ietf-dtn-bpsec"/>) target="RFC9172" format="default"/>) may expect convergence layer adapters CLAs
   that serve BP implementations conforming to those protocols to
   provide additional services such as reporting on the transmission
   and/or reception progress of individual bundles (at completion
   and/or incrementally), retransmitting data that were lost in
   transit, discarding bundle-conveying data units that the convergence
   layer
   convergence-layer protocol determines are corrupt or inauthentic, or reporting
   on the integrity and/or authenticity of delivered bundles.</t>
        <t>
   In addition, bundle protocol the Bundle Protocol relies on the capabilities of protocols at the
   convergence layer to minimize congestion in the store-carry-forward overlay
   network.  The potentially long round-trip times characterizing
   delay-tolerant networks are incompatible with end-to- end end-to-end, reactive
   congestion control
   congestion-control mechanisms, so convergence-layer protocols MUST <bcp14>MUST</bcp14> provide
   rate limiting or congestion control.</t>
      </section>
    </section>
    <section title="Implementation Status" anchor="sect-8"><t>
   [NOTE to the RFC Editor: please remove this section before publication, as well as the reference to RFC 7942.]</t>

	<t>
   This section records the status of known implementations of the
   protocol defined by this specification at the time of posting of
   this Internet-Draft, and is based on a proposal described in RFC
   7942.  The description of implementations in this section is
   intended to assist the IETF in its decision processes in progressing
   drafts to RFCs.  Please note that the listing of any individual
   implementation here does not imply endorsement by the IETF.
   Furthermore, no effort has been spent to verify the information
   presented here that was supplied by IETF contributors.  This is not
   intended as, and must not be construed to be, a catalog of available
   implementations or their features.  Readers are advised to note that
   other implementations may exist.</t>

	<t>
   According to RFC 7942, "this will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature.  It is up to the individual working groups to use this information as they see fit".</t>

	<t>
   At the time of this writing, there are six known implementations of
   the current document.</t>

	<t>
   The first known implementation is microPCN (<eref target="https://upcn.eu/"/>).
   According to the developers:</t> anchor="sect-8" numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>
   The Micro Planetary Communication Network (uPCN) is a free software project
   intended to offer an implementation of Delay-tolerant Networking protocols
   for POSIX operating systems (well, and for Linux) plus for the ARM Cortex
   STM32F4 microcontroller series. More precisely it currently provides an
   implementation of

   <list style="symbols">

	<t>the Bundle Protocol (BP, RFC 5050),</t>

	<t>version 6 of the Bundle Protocol version 7 specification draft,</t>

	<t>the DTN IP Neighbor Discovery (IPND) protocol, and</t>

	<t>a routing approach optimized for message-ferry micro LEO
	satellites.</t>

	</list>
	</t>

	<t>
   uPCN is written in C and is built upon the real-time operating
   system FreeRTOS. The source code of uPCN is released under the
   "BSD 3-Clause License".</t>

	<t>
   The project depends on an execution environment offering link
   layer protocols such as AX.25. The source code uses the USB
   subsystem to interact with the environment.</t>

	<t>
   The second known implementation is PyDTN, developed by X-works,
   s.r.o (<eref target="https://x-works.sk/"/>).  The final third of the implementation
   was developed during the IETF 101 Hackathon.  According to the
   developers, PyDTN implements bundle coding/decoding and neighbor
   discovery.  PyDTN is written in Python and has been shown to be
   interoperable with uPCN.</t>

	<t>
   The third known implementation is "Terra"
   (<eref target="https://github.com/RightMesh/Terra/"/>), a Java implementation
   developed in the context of terrestrial DTN. It includes an
   implementation of a "minimal TCP" convergence layer adapter.</t>

	<t>
   The fourth and fifth known implementations are products of
   cooperating groups at two German universities:

	<list style="symbols">

	  <t>An implementation written in Go, licensed under GPLv3, is focused
	  on being easily extensible suitable for research.  It is maintained
	  at the University of Marburg and can be accessed from <eref
	  target="https://github.com/dtn7/dtn7-go."/> </t>

	  <t>An implementation written in Rust, licensed under the MIT/Apache
	  license, is intended for environments with limited resources or
	  demanding safety and/or performance requirements.  It is maintained
	  at the Technical University of Darmstadt and can be accessed at
	  <eref target="https://github.com/dtn7/dtn7-rs/."/> </t>

	</list>
	</t>

	<t>
   The sixth known implementation is the "bpv7" module in version 4.0.0
   of the Interplanetary Overlay Network (ION) software maintained at
   the Jet Propulsion Laboratory, California Institute of Technology,
   for the U.S. National Aeronautics and Space Administration (NASA).</t>

	</section>

	<section title="Security Considerations" anchor="sect-9"><t>
   The bundle protocol security architecture and the available security
   services are specified in an accompanying document, the Bundle
   Security Protocol (BPsec) Security
   (BPSec) specification <xref target="I-D.ietf-dtn-bpsec"/>. target="RFC9172" format="default"/>.  Whenever Bundle
   Protocol security services (as opposed to the security services
   provided by overlying application protocols or underlying
   convergence-layer protocols) are required, those services SHALL <bcp14>SHALL</bcp14> be
   provided by BPsec BPSec rather than by some other mechanism with the same
   or similar scope.</t>
      <t>
   A Bundle Protocol Agent (BPA) which that sources, cryptographically
   verifies, and/or accepts a bundle MUST <bcp14>MUST</bcp14> implement support for BPsec. BPSec.
   Use of BPsec BPSec for a particular Bundle Protocol session any single bundle is optional.</t>
      <t>
   The BPsec BPSec extensions to the Bundle Protocol enable each block of a
   bundle (other than a BPsec BPSec extension block) to be individually
   authenticated by a signature block (Block Integrity Block, or BIB)
   and also enable each block of a bundle other than the primary block
   (and the BPsec BPSec extension blocks themselves) to be individually
   encrypted by a Block Confidentiality Block (BCB).</t>
      <t>
   Because the security mechanisms are extension blocks that are
   themselves inserted into the bundle, the protections they afford
   apply while the bundle is at rest, awaiting transmission at the next
   forwarding opportunity, as well as in transit.</t>
      <t>
   Additionally, convergence-layer protocols that ensure authenticity
   of communication between adjacent nodes in a BP network topology
   SHOULD
   <bcp14>SHOULD</bcp14> be used where available, to minimize the ability of
   unauthenticated nodes to introduce inauthentic traffic into the
   network.  Convergence-layer protocols that ensure confidentiality of
   communication between adjacent nodes in a BP network topology SHOULD <bcp14>SHOULD</bcp14>
   also be used where available, to minimize exposure of the bundle's
   primary block and other clear-text cleartext blocks, thereby offering some
   defense against traffic analysis.</t>
      <t>
   In order to provide authenticity and/or confidentiality of
   communication between BP nodes, the convergence-layer protocol
   requires as input the name(s) name or names of the expected communication peer(s).
   These must be supplied by the convergence-layer adapter. CLA. Details of
   the means by which the CLA determines which CL endpoint name(s) must
   be provided to the CL protocol are out of scope for this
   specification. Note, though, that when the CL endpoint names are a
   function of BP endpoint IDs, the correctness and authenticity of
   that mapping will be vital to the overall security properties that
   the CL provides to the system.</t>
      <t>
   Note that, while the primary block must remain in the clear for
   routing purposes, the Bundle Protocol could be protected against
   traffic analysis to some extent by using bundle-in-bundle
   encapsulation <xref target="I-D.ietf-dtn-bibect"/> target="I-D.ietf-dtn-bibect" format="default"/> to tunnel bundles to a safe forward
   distribution point: the encapsulated bundle could form the payload
   of an encapsulating bundle, and that payload block could be
   encrypted by a BCB.</t>
      <t>
   Note that the generation of bundle status reports is disabled by
   default because malicious initiation of bundle status reporting
   could result in the transmission of extremely large numbers of
   bundles, effecting a denial of service denial-of-service attack.  Imposing bundle
   lifetime overrides would constitute one defense against such an
   attack.</t>
      <t>
   Note also that the reception of large numbers of fragmentary bundles
   with very long lifetimes could constitute a denial of service denial-of-service
   attack, occupying storage while pending reassembly that will never
   occur.  Imposing bundle lifetime overrides would, again, constitute
   one defense against such an attack.</t>
      <t>
   This protocol makes use of absolute timestamps for several purposes.
   Provisions are included for nodes without accurate clocks to retain
   most of the protocol functionality, but nodes that are unaware that
   their clock is inaccurate may exhibit unexpected behavior.</t>
    </section>
    <section title="IANA Considerations" anchor="sect-10"><t> anchor="sect-9" numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>
   The Bundle Protocol includes fields requiring registries managed by
   IANA.</t>
      <section title="Bundle anchor="sect-9.1" numbered="true" toc="default">
        <name>Bundle Block Types" anchor="sect-10.1"><t> Types</name>
        <t>
   The current Bundle "Bundle Block Types registry Types" subregistry in the Bundle Protocol
   Namespace is "Bundle Protocol"
   registry has been augmented by adding a column identifying the version of
   the Bundle protocol Protocol (Bundle Protocol Version) that applies to the
   new
   values.  IANA is requested to add has added the following values, as
   described in section 4.3.1, <xref target="sect-4.3.1"/>, to the Bundle "Bundle Block Types registry. The
   current values in Types" registry
   with a value of "7" for the Bundle Block Types registry should have Protocol Version. IANA
   has set the Bundle Protocol Version set to "6" or "6,7" for
   preexisting values in the value "6", "Bundle Block Types" registry,
   as shown below.</t>

	<figure><artwork><![CDATA[
   +----------+-------+-----------------------------+---------------+

   | Bundle   | Value | Description                 | Reference     |

   |
   <table align="left">
    <name>"Bundle Block Types" Registry</name>
     <thead>
       <tr>
         <th>Bundle Protocol |       |                             |               |

   | Version  |       |                             |               |

   +----------+-------+-----------------------------+---------------+

   |     none |     0 | Reserved                    | [RFC6255]     |

   |     6,7  |     1 | Bundle Version</th>
         <th>Value</th>
         <th>Description</th>
         <th>Reference</th>
       </tr>
     </thead>
     <tbody>
       <tr>
           <td>none</td>
         <td>0</td>
         <td>Reserved</td>
         <td><xref target="RFC6255"/></td>
       </tr>
       <tr>

         <td>6,7</td>
         <td>1</td>
           <td>Bundle Payload Block        | [RFC5050]     |

   |          |       |                             | RFC-to-be     |

   |     6    |     2 | Bundle Block</td>
           <td><xref target="RFC5050"/> [RFC9171]</td>
       </tr>
       <tr>

         <td>6</td>
         <td>2</td>
         <td>Bundle Authentication Block | [RFC6257]     |

   |     6    |     3 | Payload Block</td>
         <td><xref target="RFC6257"/></td>
       </tr>
       <tr>

         <td>6</td>
         <td>3</td>
         <td>Payload Integrity Block     | [RFC6257]     |

   |     6    |     4 | Payload Block</td>
         <td><xref target="RFC6257"/></td>
       </tr>
       <tr>

         <td>6</td><td>4</td>
         <td>Payload Confidentiality     | [RFC6257]     |

   |          |       |    Block                    |               |

   |     6    |     5 | Previous-Hop Block</td>
         <td><xref target="RFC6257"/></td>
       </tr>
         <tr>

           <td>6</td>
           <td>5</td>
           <td>Previous-Hop Insertion Block| [RFC6259]     |

   |     7    |     6 | Previous Block</td>
           <td><xref target="RFC6259"/></td>
         </tr>
         <tr>

           <td>7</td>
           <td>6</td>
           <td>Previous node (proximate    | RFC-to-be     |

   |          |       |    sender)                  |               |

   |     7    |     7 | Bundle sender)</td>
           <td>[RFC9171]</td>
         </tr>
         <tr>

           <td>7</td>
           <td>7</td>
           <td>Bundle age (in milliseconds)| RFC-to-be     |

   |     6    |     8 | Metadata Extension Block    | [RFC6258]     |

   |     6    |     9 | milliseconds)</td>
           <td>[RFC9171]</td>
         </tr>
         <tr>

           <td>6</td>
           <td>8</td>
           <td>Metadata Extension Block</td>
           <td><xref target="RFC6258"/></td>
         </tr>
         <tr>

           <td>6</td>
           <td>9</td>
           <td>Extension Security Block    | [RFC6257]     |

   |     7    |    10 | Hop Block</td>
           <td><xref target="RFC6257"/></td>
         </tr>
         <tr>

           <td>7</td>
           <td>10</td>
           <td>Hop count (#prior xmit      | RFC-to-be     |

   |          |       |    attempts)                |               |

   |     7    | 11-191| Unassigned                  |               |

   |     6,7  |192-255| Reserved attempts)</td>
           <td>[RFC9171]</td>
         </tr>
         <tr>
           <td>7</td>
           <td>11-191</td>
           <td>Unassigned</td>
           <td></td>
         </tr>
         <tr>

           <td>6,7</td>
           <td>192-255</td>
           <td>Reserved for Private and/or | [RFC5050],    |

   |          |       | Experimental Use         | RFC-to-be     |

   +----------+-------+-----------------------------+---------------+

]]></artwork>
	</figure> Use</td>
           <td><xref target="RFC5050"/> [RFC9171]</td>
         </tr>

     </tbody>
</table>
      </section>
      <section title="Primary anchor="sect-9.2" numbered="true" toc="default">
        <name>Primary Bundle Protocol Version" anchor="sect-10.2"><t> Version</name>
        <t>
   IANA is requested to add has added the following value to the Primary "Primary Bundle
   Protocol Version registry Version" subregistry in the "Bundle Protocol" registry.</t>
   <table align="left">
    <name>"Primary Bundle Protocol Namespace.</t>

	<figure><artwork><![CDATA[

                  +-------+-------------+---------------+

                  | Value | Description | Reference     |

                  +-------+-------------+---------------+

                  |     7 | Assigned    | RFC-to-be     |

                  +-------+-------------+---------------+

]]></artwork>
	</figure> Version" Registry</name>
     <thead>
       <tr>
         <th>Value</th>
         <th>Description</th>
         <th>Reference</th>
       </tr>
     </thead>
     <tbody>
       <tr>
         <td>7</td>
         <td>Assigned</td>
         <td>[RFC9171]</td>
       </tr>
     </tbody>
   </table>
        <t> Values 8-255 (rather than 7-255) are now Unassigned.</t>
      </section>
      <section title="Bundle anchor="sect-9.3" numbered="true" toc="default">
        <name>Bundle Processing Control Flags" anchor="sect-10.3"><t> Flags</name>
        <t>
   The current Bundle "Bundle Processing Control Flags registry Flags" subregistry in the Bundle
   Protocol Namespace is "Bundle
   Protocol" registry has been augmented by adding a column identifying the
   version of the Bundle protocol Protocol (Bundle Protocol Version) that
   applies to the new values.  IANA is requested to add has added the following
   values, as described in section 4.1.3, <xref target="sect-4.2.3"/>, to the Bundle "Bundle Processing
   Control Flags registry. The current values in Flags" registry with a value of "7" for the Bundle Processing
   Control Flags registry should have Protocol Version.
 IANA has set the Bundle Protocol Version set to the value 6 "6" or "6, 7", "6,7" for preexisting values in the "Bundle Processing
   Control Flags" registry, as shown below.</t>

<figure title="Bundle
        <table align="left">
          <name>"Bundle Processing Control Flags Registry">

<artwork><![CDATA[
   +--------------------+----------------------------------+----------+

   | Bundle  |      Bit | Description                      | Reference|

   | Protocol| Flags" Registry</name>
          <thead>
            <tr>
              <th>Bundle Protocol Version</th>
              <th>Bit Position |                                  |          |

   | Version | (right |                                  |          |

   |         | to left) |                                  |          |

   +--------------------+----------------------------------+----------+

   |    6,7  |        0 | Bundle left)</th>
              <th>Description</th>
              <th>Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td>6,7</td>
              <td>0</td>
              <td>Bundle is a fragment             |[RFC5050],|

   |         |          |                                  |RFC-to-be |

   |    6,7  |        1 | Application data unit fragment</td>
              <td><xref target="RFC5050"/> [RFC9171]</td>
              </tr><tr>
              <td>6,7</td>
              <td>1</td>
              <td>ADU is an      |[RFC5050],|

   |         |          | administrative record          |RFC-to-be |

   |    6,7  |        2 | Bundle record</td>
              <td><xref target="RFC5050"/> [RFC9171]</td>
              </tr><tr>
              <td>6,7</td>
              <td>2</td>
              <td>Bundle must not be fragmented    |[RFC5050],|

   |         |          |                                  |RFC-to-be |

   |    6    |        3 | Custody fragmented</td>
              <td><xref target="RFC5050"/> [RFC9171]</td>
              </tr><tr>
              <td>6</td>
              <td>3</td>
              <td>Custody transfer is requested    |[RFC5050] |

   |    6    |        4 | Destination requested</td>
              <td><xref target="RFC5050"/></td>
              </tr><tr>
              <td>6</td>
              <td>4</td>
              <td>Destination endpoint is singleton|[RFC5050] |

   |    6,7  |        5 | Acknowledgement a singleton</td>
              <td><xref target="RFC5050"/></td>
              </tr><tr>
              <td>6,7</td>
              <td>5</td>
              <td>Acknowledgement by application   |[RFC5050],|

   |         |          | is requested                   |RFC-to-be |

   |    7    |        6 | Status requested</td>
              <td><xref target="RFC5050"/> [RFC9171]</td>
              </tr><tr>
              <td>7</td>
              <td>6</td>
              <td>Status time requested in reports |RFC-to-be |

   |    6    |        7 | Class of service, priority       |[RFC5050] |

   |    6    |        8 | Class of service, priority       |[RFC5050] |

   |    6    |        9 | Class of service, reserved       |[RFC5050] |

   |    6    |       10 | Class of service, reserved       |[RFC5050] |

   |    6    |       11 | Class of service, reserved       |[RFC5050] |

   |    6    |       12 | Class of service, reserved       |[RFC5050] |

   |    6    |       13 | Class of service, reserved       |[RFC5050] |

   |    6,7  |       14 | Request reports</td>
              <td>[RFC9171]</td>
              </tr><tr>
              <td>6</td>
              <td>7-8</td>
              <td>Class of service: priority</td>
              <td><xref target="RFC5050"/></td>
              </tr><tr>
              <td>6</td>
              <td>9-13</td>
              <td>Class of service: reserved</td>
              <td><xref target="RFC5050"/></td>
              </tr><tr>
              <td>6,7</td>
              <td>14</td>
              <td>Request reporting of bundle      |[RFC5050],|

   |         |          |   reception                      |RFC-to-be |

   |    6    |       15 | Request reception</td>
              <td><xref target="RFC5050"/> [RFC9171]</td>
              </tr><tr>
              <td>6</td>
              <td>15</td>
              <td>Request reporting of custody     |[RFC5050] |

   |         |          |   acceptance                     |          |

   |    6,7  |       16 | Request acceptance</td>
              <td><xref target="RFC5050"/></td>
              </tr><tr>
              <td>6,7</td>
              <td>16</td>
              <td>Request reporting of bundle      |[RFC5050],|

   |         |          |   forwarding                     |RFC-to-be |

   |    6,7  |       17 | Request forwarding</td>
              <td><xref target="RFC5050"/> [RFC9171]</td>
              </tr><tr>
              <td>6,7</td>
              <td>17</td>
              <td>Request reporting of bundle      |[RFC5050],|

   |         |          |   delivery                       |RFC-to-be |

   |    6,7  |       18 | Request delivery</td>
              <td><xref target="RFC5050"/> [RFC9171]</td>
              </tr><tr>
              <td>6,7</td>
              <td>18</td>
              <td>Request reporting of bundle      |[RFC5050],|

   |         |          |   deletion                       |RFC-to-be |

   |    6,7  |       19 | Reserved                         |[RFC5050],|

   |         |          |                                  |RFC-to-be |

   |    6,7  |       20 | Reserved                         |[RFC5050],|

   |         |          |                                  |RFC-to-be |

   |         |    21-63 | Unassigned                       |          |

   +--------------------+----------------------------------+----------+

]]></artwork>
	</figure> deletion</td>
              <td><xref target="RFC5050"/> [RFC9171]</td>
              </tr><tr>
              <td>6,7</td>
              <td>19</td>
              <td>Reserved</td>
              <td><xref target="RFC5050"/> [RFC9171]</td>
              </tr><tr>
              <td>6,7</td>
              <td>20</td>
              <td>Reserved</td>
              <td><xref target="RFC5050"/> [RFC9171]</td>
              </tr><tr>
              <td></td>
              <td>21-63</td>
              <td>Unassigned</td>
              <td></td>
            </tr>
 </tbody>
        </table>
      </section>
      <section title="Block anchor="sect-9.4" numbered="true" toc="default">
        <name>Block Processing Control Flags" anchor="sect-10.4"><t> Flags</name>
        <t>
   The current Block "Block Processing Control Flags registry Flags" subregistry in the Bundle
   Protocol Namespace is "Bundle
   Protocol" registry has been augmented by adding a column identifying the
   version of the Bundle protocol Protocol (Bundle Protocol Version) that
   applies to the related BP version. The current values in the Block
   Processing Control Flags registry should have  IANA has set the Bundle Protocol
   Version set to the value 6 "6" or "6, 7", "6,7" for preexisting values in the "Bundle Processing
   Control Flags" registry, as shown below.</t>

<figure title="Block

   <table align="left">
          <name>"Block Processing Control Flags Registry">
<artwork><![CDATA[

   +--------------------+----------------------------------+----------+

   | Bundle  |      Bit | Description                      | Reference|

   | Protocol| Flags" Registry</name>
          <thead>
            <tr>
              <th>Bundle Protocol Version</th>
              <th><t>Bit Position |                                  |          |

   | Version | (right |                                  |          |

   |         | to left) |                                  |          |

   +--------------------+----------------------------------+----------+

   |     6,7 |        0 | Block left)</t></th>
              <th>Description</th>
              <th>Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>

              <td>6,7</td>
              <td>0</td>
              <td>Block must be replicated in      |[RFC5050],|

   |         |          | every fragment                 |RFC-to-be |

   |     6,7 |        1 | Transmit fragment</td>
              <td><xref target="RFC5050"/> [RFC9171]</td>
              </tr><tr>

              <td>6,7</td>
              <td>1</td>
              <td>Transmit status report if block  |[RFC5050],|

   |         |          |  can't be processed             |RFC-to-be |

   |     6,7 |        2 | Delete processed</td>
              <td><xref target="RFC5050"/> [RFC9171]</td>
              </tr><tr>

              <td>6,7</td>
              <td>2</td>
              <td>Delete bundle if block can't be  |[RFC5050],|

   |         |          |   processed                      |RFC-to-be |

   |     6   |        3 | Last block                       |[RFC5050] |

   |     6,7 |        4 | Discard processed</td>
              <td><xref target="RFC5050"/> [RFC9171]</td>
              </tr><tr>

              <td>6</td>
              <td>3</td>
              <td>Last block</td>
              <td><xref target="RFC5050"/></td>
              </tr><tr>

              <td>6,7</td>
              <td>4</td>
              <td>Discard block if it can't be     |[RFC5050],|

   |         |          |   processed                      |RFC-to-be |

   |     6   |        5 | Block processed</td>
              <td><xref target="RFC5050"/> [RFC9171]</td>
              </tr><tr>

              <td>6</td>
              <td>5</td>
              <td>Block was forwarded without      |[RFC5050] |

   |         |          | being processed                |          |

   |     6   |        6 | Block processed</td>
              <td><xref target="RFC5050"/></td>
              </tr><tr>

              <td>6</td>
              <td>6</td>
              <td>Block contains an EID reference  |[RFC5050] |

   |         |          |   field                          |          |

   |         |     7-63 | Unassigned                       |          |

   +--------------------+----------------------------------+----------+

]]></artwork>
	</figure> EID-reference field</td>
              <td><xref target="RFC5050"/></td>
              </tr><tr>

              <td></td>
              <td>7-63</td>
              <td>Unassigned</td>
              <td></td>
            </tr>
          </tbody>

        </table>
      </section>
      <section title="Bundle anchor="sect-9.5" numbered="true" toc="default">
        <name>Bundle Status Report Reason Codes" anchor="sect-10.5"><t> Codes</name>
        <t>
   The current Bundle "Bundle Status Report Reason Codes registry Codes" subregistry in the Bundle
   Protocol Namespace is "Bundle
   Protocol" registry has been augmented by adding a column identifying the
   version of the Bundle protocol Protocol (Bundle Protocol Version) that
   applies to the new values.  IANA is requested to add has added the following
   values, as described in section 6.1.1, <xref target="sect-6.1.1"/>, to the Bundle "Bundle Status Report
   Reason Codes registry. The current values in Codes" registry with a value of "7" for the Bundle Status
   Report Reason Codes registry should have Protocol Version.  IANA has set the Bundle Protocol
   Version
   set to the value 6 or 7 or "6, 7", "6,7" for preexisting values in the "Bundle Status
   Report Reason Codes" registry, as shown below.</t>

<figure title="Bundle
        <table align="left">
          <name>"Bundle Status Report Reason Codes Registry">
<artwork><![CDATA[

   +--------------------+----------------------------------+----------+

   | Bundle  |    Value | Description                      | Reference|

   | Protocol|          |                                  |          |

   | Version |          |                                  |          |

   |         |          |                                  |          |

   +--------------------+----------------------------------+----------+

   |     6,7 |        0 | No Codes" Registry</name>
          <thead>
            <tr>
              <th>Bundle Protocol Version</th>
              <th>Value</th>
              <th>Description</th>
              <th>Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td>6,7</td>
              <td>0</td>
              <td>No additional information        |[RFC5050],|

   |         |          |                                  |RFC-to-be |

   |     6,7 |        1 | Lifetime expired                 |[RFC5050],|

   |         |          |                                  |RFC-to-be |

   |     6,7 |        2 | Forwarded information</td>
              <td><xref target="RFC5050"/> [RFC9171]</td>
              </tr><tr>

              <td>6,7</td>
              <td>1</td>
              <td>Lifetime expired</td>
              <td><xref target="RFC5050"/> [RFC9171]</td>
              </tr><tr>

              <td>6,7</td>
              <td>2</td>
              <td>Forwarded over unidirectional    |[RFC5050],|

   |         |          |    link                          |RFC-to-be |

   |     6,7 |        3 | Transmission canceled            |[RFC5050],|

   |         |          |                                  |RFC-to-be |

   |     6,7 |        4 | Depleted storage                 |[RFC5050],|

   |         |          |                                  |RFC-to-be |

   |     6,7 |        5 | Destination link</td>
              <td><xref target="RFC5050"/> [RFC9171]</td>
              </tr><tr>

              <td>6,7</td>
              <td>3</td>
              <td>Transmission canceled</td>
              <td><xref target="RFC5050"/> [RFC9171]</td>
              </tr><tr>

              <td>6,7</td>
              <td>4</td>
              <td>Depleted storage</td>
              <td><xref target="RFC5050"/> [RFC9171]</td>
              </tr><tr>

              <td>6,7</td>
              <td>5</td>
              <td>Destination endpoint ID          |[RFC5050],|

   |         |          |    unavailable                   |RFC-to-be |

   |     6,7 |        6 | No unavailable</td>
              <td><xref target="RFC5050"/> [RFC9171]</td>
              </tr><tr>

              <td>6,7</td>
              <td>6</td>
              <td>No known route to destination    |[RFC5050],|

   |         |          | from here                     |RFC-to-be |

   |     6,7 |        7 | No here</td>
              <td><xref target="RFC5050"/> [RFC9171]</td>
              </tr><tr>

              <td>6,7</td>
              <td>7</td>
              <td>No timely contact with next node |[RFC5050],|

   |         |          | on route                      |RFC-to-be |

   |     6,7 |        8 | Block unintelligible             |[RFC5050],|

   |         |          |                                  |RFC-to-be |

   |       7 |        9 | Hop route</td>
              <td><xref target="RFC5050"/> [RFC9171]</td>
              </tr><tr>

              <td>6,7</td>
              <td>8</td>
              <td>Block unintelligible</td>
              <td><xref target="RFC5050"/> [RFC9171]</td>
              </tr><tr>

              <td>7</td>
              <td>9</td>
              <td>Hop limit exceeded               |RFC-to-be |

   |       7 |       10 | Traffic pared                    |RFC-to-be |

   |       7 |       11 | Block unsupported                |RFC-to-be |

   |         |   12-254 | Unassigned                       |          |

   |     6,7 |      255 | Reserved                         |[RFC6255],|

   |         |          |                                  |RFC-to-be |

   +-------+-----------------------------------------------+----------+

]]></artwork>
	</figure> exceeded</td>
              <td>[RFC9171]</td>
              </tr><tr>

              <td>7</td>
              <td>10</td>
              <td>Traffic pared</td>
              <td>[RFC9171]</td>
              </tr><tr>

              <td>7</td>
              <td>11</td>
              <td>Block unsupported</td>
              <td>[RFC9171]</td>
              </tr><tr>

              <td></td>
              <td>17-254</td>
              <td>Unassigned</td>
              <td></td>
              </tr><tr>

              <td>6,7</td>
              <td>255</td>
              <td>Reserved</td>
              <td><xref target="RFC6255"/> [RFC9171]</td>
              </tr>
          </tbody>
        </table>
      </section>
      <section title="Bundle anchor="sect-9.6" numbered="true" toc="default">
        <name>Bundle Protocol URI scheme types" anchor="sect-10.6"><t> Scheme Types</name>
        <t>
   The Bundle Protocol has a URI scheme type field - -- an unsigned
   integer of indefinite length - -- for which IANA is requested to create has created,
   and maintain will maintain, a new "Bundle Protocol URI Scheme Type" registry Types" subregistry in the
   Bundle Protocol Namespace.
   "Bundle Protocol" registry.  The "Bundle Protocol URI Scheme Type" Types"
   registry governs an a namespace of unsigned integer namespace. integers.  Initial values for
   the Bundle "Bundle Protocol URI Scheme Type Types" registry are given below.</t>
        <t>
   The registration policy for this registry is: is Standards Action. Action <xref target="RFC8126"/>. The
   allocation should only be granted for a standards-track Standards Track RFC approved
   by the IESG.</t>
        <t>
   The value range is: of values is provided as unsigned integer.</t> integers.</t>
        <t>
   Each assignment consists of a URI scheme type name and its
   associated description, a reference to the document that defines the
   URI scheme, and a reference to the document that defines the use of
   this URI scheme in BP endpoint IDs (including the CBOR
   representation
   encoding of those endpoint IDs in transmitted bundles).</t>

<figure title="Bundle
        <table align="left">
          <name>"Bundle Protocol URI Scheme Type Registry">
<artwork><![CDATA[

    +---------+-------------+----------------+------------------+

    |         |             | BP Types" Registry</name>
          <thead>
            <tr>
              <th>Value</th>
              <th>Description</th>
              <th>BP Utilization | URI Reference</th>
              <th>URI Definition   |

    |   Value | Description | Reference      | Reference        |

    +---------+-------------+----------------+------------------+

    |       0 | Reserved    |      n/a       |                  |

    |       1 | dtn         |    RFC-to-be   |   RFC-to-be      |

    |       2 | ipn         |    RFC-to-be   |   [RFC6260],     |

    |         |             |                |    RFC-to-be     |

    |   3-254 | Unassigned  |      n/a       |                  |

    |255-65535| reserved    |      n/a       |                  |

    |  >65535 | open Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td>0</td>
              <td>Reserved</td>
              <td>n/a</td>
              <td></td>
              </tr>
            <tr>
              <td>1</td>
              <td>dtn</td>
              <td>[RFC9171]</td>
              <td>[RFC9171]</td>
              </tr>
            <tr>
              <td>2</td>
              <td>ipn</td>
              <td>[RFC9171]</td>
              <td><xref target="RFC6260"/> [RFC9171]</td>
              </tr>
            <tr>
              <td>3-254</td>
              <td>Unassigned</td>
              <td>n/a</td>
              <td></td>
              </tr>
            <tr>
              <td>255-65535</td>
              <td>Reserved</td>
              <td>n/a</td>
              <td></td>
              </tr>
            <tr>
              <td>&gt;65535</td>
              <td>Reserved for    |      n/a       |                  |

    |         | private use |      n/a       |                  |

    +---------+-------------+----------------+------------------+

]]></artwork>
	</figure> Private Use</td>
              <td>n/a</td>
              <td></td>
              </tr>
          </tbody>
        </table>
      </section>
      <section title="URI scheme &quot;dtn&quot;" anchor="sect-10.7"><t> anchor="sect-9.7" numbered="true" toc="default">
        <name>dtn URI Scheme</name>
        <t>
   In the Uniform "Uniform Resource Identifier (URI) Schemes Schemes" (uri-schemes)
   registry, IANA is requested to update has updated the registration of the URI
   scheme with the string "dtn" as the scheme name, as follows:</t>

	<t>
   URI
        <dl>
        <dt>URI scheme name: "dtn"</t>

	<t>
   Status: permanent</t>

	<t>
   Applications name:</dt>
          <dd>"dtn"</dd>
        <dt>Status:</dt>
          <dd>Permanent</dd>
        <dt>Applications and/or protocols that use this URI scheme name: the name:</dt>
          <dd>The Delay-Tolerant Networking (DTN) Bundle Protocol (BP).</t>

   <t>Contact:

	<list>
	  <t>Scott Burleigh</t>

	  <t>Jet Propulsion Laboratory,</t>

	  <t>California Institute of Technology</t>

	  <t>scott.c.burleigh@jpl.nasa.gov</t>

	  <t>+1 (800) 393-3353</t>
	</list>
	</t>

	<t>Change controller:

	<list>
	  <t>IETF, iesg@ietf.org</t>

	</list>
	</t> (BP).</dd>
        <dt>Contact:</dt>
          <dd><t><contact fullname="Scott Burleigh"/>
          &lt;sburleig.sb@gmail.com&gt;</t>
          </dd>
        <dt>Change controller:</dt>
          <dd>IETF (iesg@ietf.org)</dd>
        <dt>Reference:</dt>
          <dd>[RFC9171]</dd>
        </dl>

      </section>
      <section title="URI scheme &quot;ipn&quot;" anchor="sect-10.8"><t> anchor="sect-9.8" numbered="true" toc="default">
        <name>ipn URI Scheme</name>
        <t>
   In the Uniform "Uniform Resource Identifier (URI) Schemes Schemes" (uri-schemes)
   registry, IANA is requested to update has updated the registration of the URI
   scheme with the string "ipn" as the scheme name, originally
   documented in RFC 6260 <xref target="RFC6260"/>, target="RFC6260" format="default"/>, as follows.</t>

	<t>
   URI
        <dl>
        <dt>URI scheme name: "ipn"</t>

	<t>
   Status: permanent</t>

	<t>
   Applications name:</dt>
          <dd>"ipn"</dd>
        <dt>Status:</dt>
          <dd>Permanent</dd>
        <dt>Applications and/or protocols that use this URI scheme name: the name:</dt>
          <dd>The Delay-Tolerant Networking (DTN) Bundle Protocol (BP).</t>

	<t>Contact:

	<list>
	  <t>Scott Burleigh</t>

	  <t>Jet Propulsion Laboratory,</t>

	  <t>California Institute of Technology</t>

	  <t>scott.c.burleigh@jpl.nasa.gov</t>

	  <t>+1 (800) 393-3353</t>

	</list>
	</t>

	<t>Change controller:

	<list>
	  <t>IETF, iesg@ietf.org</t>
	</list>
	</t> (BP).</dd>
        <dt>Contact:</dt>
          <dd><t><contact fullname="Scott Burleigh"/>
          &lt;sburleig.sb@gmail.com&gt;</t>
          </dd>
        <dt>Change controller:</dt>
          <dd>IETF (iesg@ietf.org)</dd>
        <dt>Reference:</dt>
          <dd>[RFC9171]</dd>
        </dl>
      </section>
    </section>
  </middle>
  <back>
	<references title="Normative References">
	&I-D.ietf-dtn-bpsec;
<!--	<reference><front> -->
	<!--
   draft-ietf-dtn-bpbis-31-manual.txt(2665): Warning: Failed parsing a reference.
   Are all elements separated by commas (not periods, not just spaces)?:
   [CRC16] ITU-T Recommendation X.25, p. 9, section 2.2.7.4,
   International Telecommunications Union, October 1996.
   -->
<!-- </front> -->

<!--	</reference> -->
	&RFC2119;
	&RFC4960;
	&RFC5234;
	&RFC8174;
	&RFC8949;
<!--	<reference><front> -->

<displayreference target="RFC3986" to="URI"/>
<displayreference target="RFC4838" to="ARCH"/>
<displayreference target="RFC7595" to="URIREG"/>
<displayreference target="RFC9172" to="BPSEC"/>
<displayreference target="RFC9174" to="TCPCL"/>
<displayreference target="I-D.ietf-dtn-bibect" to="BIBE"/>

 <references>
      <name>References</name>
      <references>
        <name>Normative References</name>

<!--
   draft-ietf-dtn-bpbis-31-manual.txt(2683): Warning: Failed parsing a reference.
   Are all elements separated by commas (not periods, not just spaces)?:
   [SABR] "Schedule-Aware Bundle Routing", CCSDS Recommended Standard
   734.3-B-1, Consultative Committee for Space Data Systems, July 2019.
   -->

<!-- </front> -->

<!--	</reference> draft-ietf-dtn-bpsec ([BPSEC] per orig.; RFC 9172) -->
	&I-D.ietf-dtn-tcpclv4;
<reference anchor="URI"><front>
	<title>Uniform Resource Identifier (URI): Generic Syntax</title>
	<author initials="T." surname="Berners-Lee" fullname="T. Berners-Lee">
	</author> anchor='RFC9172' target="https://www.rfc-editor.org/info/rfc9172">
   <front>
      <title>Bundle Protocol Security (BPSec)</title>
      <author initials="R." surname="Fielding" fullname="R. Fielding"> initials='E' surname='Birrane, III' fullname='Edward J. Birrane, III'>
         <organization />
      </author>
      <author initials="L." surname="Masinter" fullname="L. Masinter"> initials='K' surname='McKeever' fullname='Kenneth McKeever'>
         <organization />
      </author>
      <date month="January" year="2005"/> month='January' year='2022' />
   </front>
   <seriesInfo name="RFC" value="3986"/> value="9172"/>
   <seriesInfo name="STD" value="66"/> name="DOI" value="10.17487/RFC9172"/>
</reference>

<reference anchor="URIREG"><front>
	<title>Guidelines anchor="CRC16" target="https://www.itu.int/rec/T-REC-X.25-199610-I/">
   <front>
   <title>X.25: Interface between Data Terminal Equipment (DTE) and Registration Procedures Data Circuit-terminating Equipment (DCE) for URI Schemes</title> terminals operating in the packet mode and connected to public data networks by dedicated circuit</title>
      <author>
          <organization>ITU-T</organization>
      </author>
      <date month="October" year="1996"/>
   </front>
   <seriesInfo name="ITU-T Recommendation" value="X.25"/>
   <refcontent>p. 9, Section 2.2.7.4</refcontent>
</reference>

        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4960.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5234.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8949.xml"/>

<reference anchor="SABR" target="https://public.ccsds.org/Pubs/734x3b1.pdf">
   <front>
      <title>Schedule-Aware Bundle Routing</title>
      <author>
          <organization>Consultative Committee for Space Data Systems</organization>
      </author>
      <date month="July" year="2019"/>
   </front>
   <seriesInfo name="CCSDS Recommended Standard" value="734.3-B-1"/>
</reference>

<!-- draft-ietf-dtn-tcpclv4 ([TCPCL] per orig.; RFC 9174) -->
<reference anchor='RFC9174' target="https://www.rfc-editor.org/info/rfc9174">
   <front>
      <title>Delay-Tolerant Networking TCP Convergence-Layer Protocol Version 4</title>
      <author initials="D." surname="Thaler" fullname="D. Thaler"> initials='B' surname='Sipos' fullname='Brian Sipos'>
         <organization />
      </author>
      <author initials="T." surname="Hansen" fullname="T. Hansen"> initials='M' surname='Demmer' fullname='Michael Demmer'>
         <organization />
      </author>
      <author initials='J' surname='Ott' fullname='Jörg Ott'>
         <organization />
      </author>
      <author initials="T." surname="Hardie" fullname="T. Hardie"> initials='S' surname='Perreault' fullname='Simon Perreault'>
         <organization />
      </author>
      <date month="June" year="2015"/> month='January' year='2022' />
   </front>
   <seriesInfo name="RFC" value="7595"/> value="9174"/>
   <seriesInfo name="BCP" value="35"/> name="DOI" value="10.17487/RFC9174"/>
</reference>

        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3986.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7595.xml"/>
      </references>
	<references title="Informative References">
      <references>
        <name>Informative References</name>

<!-- 	<reference><front> draft-ietf-dtn-bibect ([BIBE]; Expired) -->
	<!--
   draft-ietf-dtn-bpbis-31-manual.txt(2700): Warning: Failed parsing a reference.
   Are all elements separated by commas (not periods, not just spaces)?:
   [ARCH] V. Cerf et al., "Delay-Tolerant Network Architecture", RFC
   4838, April 2007.
   -->

<!-- </front> -->

<!--	</reference> -->
	&I-D.ietf-dtn-bibect;
	&RFC3987;
	&RFC5050;
	&RFC6255;
	&RFC6257;
	&RFC6258;
	&RFC6259;
	&RFC6260;
	&RFC7143;
<!--	<reference><front> -->
	<!--
   draft-ietf-dtn-bpbis-31-manual.txt(2731): Warning: Failed parsing a reference.
   Are all elements separated by commas (not periods, not just spaces)?:
   [SIGC] Fall, K., "A
        <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-dtn-bibect.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3987.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4838.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5050.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6255.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6257.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6258.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6259.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6260.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7143.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8126.xml"/>

<reference anchor="SIGC" target="https://dl.acm.org/doi/10.1145/863955.863960">
    <front>
        <title>A Delay-Tolerant Network Architecture for Challenged Internets", SIGCOMM 2003.
   -->

<!-- Internets</title>
        <author initials="K" surname="Fall" fullname="Kevin Fall">
            <organization></organization>
        </author>
        <date month="August" year="2003"/>
    </front> -->

<!--
    <seriesInfo name="DOI" value="10.1145/863955.863960"/>
    <refcontent>SIGCOMM 2003</refcontent>
</reference> -->

        </references>
    </references>
    <section title="Acknowledgments" anchor="sect-12"><t>
   This work is freely adapted anchor="app-a" numbered="true" toc="default">
      <name>Significant Changes from RFC 5050, which was an effort of
   the Delay Tolerant Networking Research Group. The following DTNRG
   participants contributed significant technical material and/or
   inputs to that document: Dr. Vinton Cerf of Google, Scott Burleigh,
   Adrian Hooke, and Leigh Torgerson of the Jet Propulsion Laboratory,
   Michael Demmer of the University of California at Berkeley, Robert
   Durst, Keith Scott, and Susan Symington of The MITRE Corporation,
   Kevin Fall of Carnegie Mellon University, Stephen Farrell of Trinity
   College Dublin, Howard Weiss and Peter Lovell of SPARTA, Inc., and
   Manikantan Ramadas of Ohio University.</t> 5050</name>
      <t>
This document was prepared using 2-Word-v2.0.template.dot.</t>

	</section>

	<section title="Significant Changes from RFC 5050" anchor="sect-13"><t>
   Points on which this draft significantly differs makes the following significant changes from RFC 5050
   include the following:

   	<list style="symbols">

	  <t>Clarify 5050:
      </t>
      <ul spacing="normal">
        <li>Clarifies the difference between transmission and forwarding.</t>

	  <t>Migrate forwarding.</li>
        <li>Migrates custody transfer to the bundle-in-bundle encapsulation
          specification <xref target="I-D.ietf-dtn-bibect"/>.</t>

	  <t>Introduce target="I-D.ietf-dtn-bibect" format="default"/>.</li>
        <li>Introduces the concept of "node ID" as functionally distinct from
          endpoint ID, while having the same syntax.</t>

	  <t>Restructure syntax.</li>
        <li>Restructures primary block, making it immutable.  Add  Adds optional
	  CRC.</t>

	  <t>Add
          CRC.</li>
        <li>Adds optional CRCs to non-primary blocks.</t>

	  <t>Add blocks.</li>
        <li>Adds block ID number to canonical block format (to support
	  BPsec).</t>

	  <t>Add
          BPSec).</li>
        <li>Adds definition of bundle age Bundle Age extension block.</t>

	  <t>Add block.</li>
        <li>Adds definition of previous node Previous Node extension block.</t>

	  <t>Add block.</li>
        <li>Adds definition of hop count Hop Count extension block.</t>

	  <t>Remove block.</li>
        <li>Removes Quality of Service markings.</t>

	  <t>Change markings.</li>
        <li>Changes from SDNVs Self-Delimiting Numeric Values (SDNVs) to CBOR representation.</t>

	  <t>Add encoding.</li>
        <li>Adds lifetime overrides.</t>

	  <t>Time overrides.</li>
        <li>Clarifies that time values are denominated in milliseconds, not seconds.</t>
	</list>
      </t> seconds.</li>
      </ul>
    </section>
    <section title="For More Information" anchor="sect-a"><t>
   Copyright (c) 2021 IETF Trust and the persons identified as authors
   of the code. All rights reserved.</t> anchor="app-c" numbered="true" toc="default">
      <name>CDDL Expression</name>
      <t>
   Redistribution and use in source and binary forms, with or without
   modification, is permitted pursuant to, and subject to the license
   terms contained in, the Simplified BSD License set forth in Section
   4.c of the IETF Trust's Legal Provisions Relating to IETF Documents
   (<eref target="http://trustee.ietf.org/license-info"/>).</t>

	</section>

	<section title="CDDL expression" anchor="sect-b"><t>
   For informational purposes, Carsten Bormann and Brian Sipos have
   kindly provided an expression of the Bundle Protocol specification
   in the Concise Data Definition Language (CDDL).  That CDDL
   expression is presented below.  Note that wherever the CDDL
   expression is in disagreement with the textual representation of the
   BP specification presented in the earlier sections of this document,
   the textual representation rules.</t>

	<figure><artwork><![CDATA[
      <sourcecode type="cddl"><![CDATA[
   bpv7_start = bundle / #6.55799(bundle)

   ; Times before 2000 are invalid

   dtn-time = uint

   ; CRC enumerated type

   crc-type = &(

     crc-none: 0,

     crc-16bit: 1,

     crc-32bit: 2

   )

   ; Either 16-bit or 32-bit

   crc-value = (bstr .size 2) / (bstr .size 4)

   creation-timestamp = [

     dtn-time, ; absolute time of creation

     sequence: uint ; sequence within the time

   ]

   eid = $eid .within eid-structure

   eid-structure = [

     uri-code: uint,

     SSP: any

   ]

   $eid /= [

     uri-code: 1,

     SSP: (tstr / 0)

   ]

   $eid /= [

     uri-code: 2,

     SSP: [

       nodenum: uint,

       servicenum: uint

     ]

   ]

   ; The root bundle array

   bundle = [primary-block, *extension-block, payload-block]

   primary-block = [

     version: 7,

     bundle-control-flags,

     crc-type,

     destination: eid,

     source-node: eid,

     report-to: eid,

     creation-timestamp,

     lifetime: uint,

     ? (

       fragment-offset: uint,

       total-application-data-length: uint

     ),

     ? crc-value,

   ]

   bundle-control-flags = uint .bits bundleflagbits

   bundleflagbits = &(

     reserved: 21,

     reserved: 20,

     reserved: 19,

     bundle-deletion-status-reports-are-requested: 18,

     bundle-delivery-status-reports-are-requested: 17,

     bundle-forwarding-status-reports-are-requested: 16,

     reserved: 15,

     bundle-reception-status-reports-are-requested: 14,

     reserved: 13,

     reserved: 12,

     reserved: 11,

     reserved: 10,

     reserved: 9,

     reserved: 8,

     reserved: 7,

     status-time-is-requested-in-all-status-reports: 6,

     user-application-acknowledgement-is-requested: 5,

     reserved: 4,

     reserved: 3,

     bundle-must-not-be-fragmented: 2,

     payload-is-an-administrative-record: 1,

     bundle-is-a-fragment: 0

   )

   ; Abstract shared structure of all non-primary blocks

   canonical-block-structure = [

     block-type-code: uint,

     block-number: uint,

     block-control-flags,

     crc-type,

     ; Each block type defines the content within the bytestring byte string

     block-type-specific-data,

     ? crc-value

   ]

   block-control-flags = uint .bits blockflagbits

   blockflagbits = &(

     reserved: 7,

     reserved: 6,

     reserved: 5,

     block-must-be-removed-from-bundle-if-it-cannot-be-processed: 4,

     reserved: 3,

     bundle-must-be-deleted-if-block-cannot-be-processed: 2,

     status-report-must-be-transmitted-if-block-cannot-be-processed:
     1,

     block-must-be-replicated-in-every-fragment: 0

   )

   block-type-specific-data = bstr / #6.24(bstr)

   ; Actual CBOR data embedded in a bytestring, byte string, with optional tag to
   indicate so.

   ; Additional plain bstr allows ciphertext data.

   embedded-cbor<Item> = (bstr .cbor Item) / #6.24(bstr .cbor Item) /
   bstr

   ; Extension block type, which does not specialize other than the
   code/number

   extension-block =
   $extension-block .within canonical-block-structure

   ; Generic shared structure of all non-primary blocks

   extension-block-use<CodeValue, BlockData> = [

     block-type-code: CodeValue,

     block-number: (uint .gt 1),

     block-control-flags,

     crc-type,

     BlockData,

     ? crc-value

   ]

   ; Payload block type

   payload-block = payload-block-structure .within canonical-block-
   structure

   payload-block-structure = [

     block-type-code: 1,

     block-number: 1,

     block-control-flags,

     crc-type,

     $payload-block-data,

     ? crc-value

   ]

   ; Arbitrary payload data, including non-CBOR bytestring byte string

   $payload-block-data /= block-type-specific-data

   ; Administrative record as a payload data specialization

   $payload-block-data /= embedded-cbor<admin-record>

   admin-record = $admin-record .within admin-record-structure

   admin-record-structure = [

     record-type-code: uint,

     record-content: any

   ]

   ; Only one defined record type

   $admin-record /= [1, status-record-content]

   status-record-content = [

     bundle-status-information,

     status-report-reason-code: uint,

     source-node-eid: eid,

     subject-creation-timestamp: creation-timestamp,

     ? (

       subject-payload-offset: uint,

       subject-payload-length: uint

     )

   ]

   bundle-status-information = [

     reporting-node-received-bundle: status-info-content,

     reporting-node-forwarded-bundle: status-info-content,

     reporting-node-delivered-bundle: status-info-content,

     reporting-node-deleted-bundle: status-info-content

   ]

   status-info-content = [

     status-indicator: bool,

     ? timestamp: dtn-time

   ]

   ; Previous Node extension block

   $extension-block /=

     extension-block-use<6, embedded-cbor<ext-data-previous-node>>

   ext-data-previous-node = eid

   ; Bundle Age extension block

   $extension-block /=

     extension-block-use<7, embedded-cbor<ext-data-bundle-age>>

   ext-data-bundle-age = uint

   ; Hop Count extension block

   $extension-block /=

     extension-block-use<10, embedded-cbor<ext-data-hop-count>>

   ext-data-hop-count = [

     hop-limit: uint,

     hop-count: uint

   ]

]]></artwork>
	</figure>
]]></sourcecode>
    </section>

    <section anchor="acks-section" numbered="false" toc="default">
      <name>Acknowledgments</name>
      <t>
   This work is freely adapted from RFC 5050, which was an effort of
   the Delay-Tolerant Networking Research Group. The following DTNRG
   participants contributed significant technical material and/or
   inputs to that document: <contact fullname="Dr. Vinton Cerf"/> of Google;
   <contact fullname="Scott Burleigh"/>, <contact fullname="Adrian Hooke"/>, and
   <contact fullname="Leigh Torgerson"/> of the Jet Propulsion Laboratory;
   <contact fullname="Michael Demmer"/> of the University of California at Berkeley;
   <contact fullname="Robert Durst"/>, <contact fullname="Keith Scott"/>, and
   <contact fullname="Susan Symington"/> of The MITRE Corporation;
   <contact fullname="Kevin Fall"/> of Carnegie Mellon University;
   <contact fullname="Stephen Farrell"/> of Trinity College Dublin;
   <contact fullname="Howard Weiss"/> and <contact fullname="Peter Lovell"/> of
   SPARTA, Inc.;
   and <contact fullname="Manikantan Ramadas"/> of Ohio University.</t>
   <t>Scott Burleigh would like to thank the Jet Propulsion Laboratory, California Institute of Technology, for its generous and sustained support of this work.</t>
    </section>
  </back>
</rfc>