The Johns Hopkins University Applied Physics Laboratory

11100 Johns Hopkins Rd. Laurel MD 20723 United States of America brian.sipos+ietf@gmail.com

INT dtn DTN This document updates RFC 9171 to clarify that Bundle Protocol Version 7 agents are expected to use the IANA "Bundle Administrative Record Types" registry to identify and document administrative record types. This document also designates code points for Private and Experimental Use.

Status of This Memo This is an Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at .

Copyright Notice Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents () in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.

Table of Contents

• .  Introduction
  • .  Scope
  • .  Terminology
• .  Administrative Record Types Registry
• .  Security Considerations
• .  IANA Considerations
  • .  Bundle Administrative Record Types
• .  References
  • .  Normative References
  • .  Informative References
• Author's Address

Introduction An earlier specification defined an IANA registry for administrative record type code points for use with the Bundle Protocol (BP) Version 6 (BPv6) . When Bundle Protocol Version 7 (BPv7) was published in , it identified the IANA registry for administrative record types but did not update the table to be explicit about which entries applied to which Bundle Protocol version(s). The BPv7 specification also did not discriminate between code point reservations and unassigned ranges for administrative record types. This document updates BPv7 to explicitly use the IANA "Bundle Administrative Record Types" registry as described in . This document makes a reservation of the zero value for consistency with BPv6. This document also makes a reservation of high-valued code points for Private Use and Experimental Use in accordance with to avoid collisions with assigned code points.

Scope This document describes updates to the IANA "Bundle Administrative Record Types" registry and how a BPv7 agent is supposed to use that registry to identify administrative record types. This document does not specify how BPv6 and BPv7 can interoperate when both use the same code points or how a specific code point is to be interpreted either similarly or differently by Bundle Protocol versions. The specification for each administrative record type is to define how the administrative record type relates to each BP version.

Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Administrative Record Types Registry This document updates the requirements in to specify use of an existing IANA registry and updates that registry as described in . The code point allocated in Annex D of was never added to the IANA registry. To avoid a collision, this document adds that allocation to the registry. Instead of using the list of types in , a BPv7 administrative element SHALL determine which administrative record type code values can be used by the "7" noted in the Bundle Protocol Version column of the IANA "Bundle Administrative Record Types" registry . If an administrative element receives a not-well-formed application data unit (ADU) or an administrative record type code that is not able to be processed by the element, the record SHALL be ignored by the element. The processing of a received administrative record ADU does not affect the fact that the bundle itself was delivered to the administrative element or any related bundle protocol agent processing of (e.g., status reports on) the enveloping bundle.

Security Considerations This document does not define any requirements or structures that introduce new security considerations. The existing security considerations of still apply when using the IANA "Bundle Administrative Record Types" registry.

IANA Considerations This specification modifies a BPv6 registry by extending it for BPv7.

Bundle Administrative Record Types Within the "Bundle Protocol" registry group , the "Bundle Administrative Record Types" registry has been updated to include a leftmost "Bundle Protocol Version" column. New entries have been added and existing entries have been updated to include BP versions as in . This document makes no changes to the registration procedures for this registry. Bundle Administrative Record Types

Bundle Protocol Version	Value	Description	Reference
6,7	0	Reserved	RFC 9713
6,7	1	Bundle status report
6	2	Custody signal
	3	Unassigned
6	4	Aggregate Custody Signal
	5 - 15	Unassigned
7	16 - 64383	Unassigned
7	64384 - 64511	Reserved for Experimental Use	RFC 9713
7	64512 - 65535	Reserved for Private Use	RFC 9713

References Normative References IANA In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This document presents a specification for the Bundle Protocol, adapted from the experimental Bundle Protocol specification developed by the Delay-Tolerant Networking Research Group of the Internet Research Task Force and documented in RFC 5050. Informative References Consultative Committee for Space Data Systems CCSDS Recommended Standard This document describes the end-to-end protocol, block formats, and abstract service description for the exchange of messages (bundles) in Delay Tolerant Networking (DTN). This document was produced within the IRTF's Delay Tolerant Networking Research Group (DTNRG) and represents the consensus of all of the active contributors to this group. See http://www.dtnrg.org for more information. This memo defines an Experimental Protocol for the Internet community. The DTNRG Research Group has defined the experimental Licklider Transmission Protocol (LTP) and the Compressed Bundle Header Encoding (CBHE) mechanism for the InterPlanetary Network ('ipn' URI scheme). Moreover, RFC 5050 defines values for the Bundle Protocol administrative record type. All of these fields are subject to a registry. For the purpose of its research work, the group has created ad hoc registries. As the specifications are stable and have multiple interoperable implementations, the group would like to hand off the registries to IANA for official management. This document describes the necessary IANA actions. Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA). To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry. This is the third edition of this document; it obsoletes RFC 5226.

Author's Address The Johns Hopkins University Applied Physics Laboratory

11100 Johns Hopkins Rd. Laurel MD 20723 United States of America brian.sipos+ietf@gmail.com