Custody Transfer for Bundle Protocol Version 7

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 29 April 2027.¶

Copyright Notice

Copyright (c) 2026 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 (https://trustee.ietf.org/license-info) 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

1. Introduction

BPv7, as defined in [RFC9171], does not include the custody-transfer mechanism defined for BPv6. Building on the corresponding CCSDS experimental specification [CCSDS-734.6-O-1], this document defines a BPv7 custody-transfer extension in which a Custody Transfer Extension Block (CTEB) requests transfer of retransmission responsibility and a Compressed Custody Signal (CCS) reports acceptance or rejection for multiple bundles.¶

This document depends on the sequence-identification framework in [I-D.flentge-dtn-bundle-sequence-identification].¶

2. Conventions and 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

Block Source Administrative Endpoint ID (AEID) : An endpoint ID of the administrative element of the BP agent that assigns a Bundle Sequence Number and inserts the corresponding Custody Transfer Extension Block.¶

Compressed Custody Signal (CCS): An administrative record sent to the current custodian of a bundle to indicate acceptance or rejection of custody.¶

Current Custodian: A node retaining a bundle after requesting onward custody.¶

Prospective Custodian: A node deciding whether to accept custody.¶

Custody Transfer (CT): Transfer of responsibility for retaining and reliable transmission of a bundle from one BP node to another. Typically this is achieved through keeping a copy of the bundle and re-transmitting the bundle in case no custody acceptance signal is received. It can also be achieved if the use of reliable convergence layers can be guaranteed to the next custodian of destination node. Still, custody transfer may fail and it does not guarantee end-to-end reliability. It is rather an efficiency mechanism as it allows re-transmission from an intermediate node and may be used together with end-to-end reliability mechanisms, such as delivery reporting, where required.¶

Custody Transfer Extension Block (CTEB): A BPv7 extension block which requests forwarding bundle nodes to take custody of a bundle.¶

3. Applicability Statement

This mechanism is intended primarily for relatively small, well-managed DTNs in which participants, routing expectations, storage policies, and operational responsibilities are known. It does not prescribe the use of custody timers or solve re-forwarding time estimation for large-scale open DTNs. Nodes can forward a CTEB without implementing this specification according to BPv7 extension-block processing, but gaps in support can reduce efficiency or prevent transfer of custody.¶

4. Protocol Overview

A node requests custody by inserting a CTEB. A downstream node accepts or rejects custody and reports the disposition in a CCS addressed to the block source AEID. An accepting custodian retains the bundle and, unless reliable delivery to the destination is otherwise assured, requests custody from a downstream node. The current custodian releases its custody state only after an accepting CCS or bundle expiration.¶

5. Custody Transfer Extension Block (CTEB)

Custody Transfer is requested by adding a Custody Transfer Extension Block (CTEB). The CTEB MUST use the BPv7 canonical block format according to [RFC9171]. Block Type 13 as assigned by IANA for the CTEB MUST be used. A bundle MUST NOT contain more than one CTEB.¶

Using CBOR as defined by [RFC8949], the block-type-specific data MUST be a definite-length CBOR byte string containing a definite-length CBOR array with the following three elements:¶

• The first item SHALL be a Bundle Sequence Number (BSN), a CBOR unsigned integer, as specified in [I-D.flentge-dtn-bundle-sequence-identification].¶

• The second item SHALL be a Bundle Sequence ID (BSID), a CBOR unsigned integer, as specified in [I-D.flentge-dtn-bundle-sequence-identification].¶

• The third item SHALL be the block source AEID, a CBOR encoded endpoint ID, as specified in [I-D.flentge-dtn-bundle-sequence-identification].¶

The BSID '0' SHALL be used to indicate that the BSN is qualified by the destination EID in the primary header.¶

A node that cannot parse the array, encounters additional or missing elements, or finds an invalid EID MUST treat the block as malformed and apply the block processing control flags as specified by BPv7.¶

6. Compressed Custody Signal (CCS)

The Compressed Custody Signal (CCS) is used to inform the current custodian about custody acceptance or refusal. A CCS MUST be a BPv7 administrative record. Administrative Record Type 13 as assigned by IANA for the CCS MUST be used.¶

The content of the CCS administrative record MUST be a CBOR map with the following key/value pairs:¶

• Disposition Codes as keys¶

  • 1 - Custody Acceptance (no further information); an unsigned CBOR integer; values above 1 are reserved for future use and may provide additional information for acceptance.¶

  • -1 - Custody Rejection (no further information); a negative CBOR integer; values below -1 are reserved for future use and may provide additional information for rejection.¶

• A receiver MUST use the sign of the disposition code to determine whether custody was accepted or rejected. A positive value indicates acceptance and a negative value indicates rejection.¶

• Bundle Sequence Collections as specified in [I-D.flentge-dtn-bundle-sequence-identification] as values.¶

Bundle sequences in a CCS MUST NOT contain block source AEIDs. The CCS destination is the block source AEID from the CTEB which will be the destination EID in the primary block of the bundle, making that AEID implicit.¶

7. Custody Procedures

8. Interaction with End-to-End Reliability

Custody transfer localizes recovery between custodians but does not guarantee end-to-end delivery, because a custodian may delete bundles or lose state information. Delivery and deletion reporting can complement custody. A source node can then retransmit a bundle in case custodial transfer fails.¶

9. Fragmentation

A bundle containing a CTEB MUST NOT be fragmented. A CTEB MUST NOT be added to or processed in a fragment. Sources SHOULD set the Bundle Must Not be Fragmented flag.¶

10. CDDL

The following CDDL uses the CDDL notation of [RFC8610] and the rules defined by [RFC9171].¶

;CTEB
$extension-block /= extension-block-use<13, embedded-cbor<cteb-data>>

cteb-data = [seq-num: uint, seq-id: uint, blk-source: eid]

;CCS
$admin-record /= [13, custody-signal-content]

custody-signal-content = {
  + uint .gt 0 => seq-collection, ; custody accepted
  + nint => seq-collection        ; custody rejected
}

11. IANA Considerations

IANA has assigned Bundle Block Type 13 to the Custody Transfer Extension Block and Bundle Administrative Record Type 13 to the Compressed Custody Signal, with CCSDS 734.6-O-1 as the current reference. IANA is requested to add this document as a reference for both registrations upon publication as an RFC.¶

12. Security Considerations

A forged acceptance can cause premature deletion of retained bundles, while forged rejection can cause unnecessary re-forwarding. Unauthorized CTEBs can consume storage and communications resources, and a malicious custodian can accept and silently discard bundles.¶

It is RECOMMENDED to use BPSec [RFC9172] integrity protection to authenticate CTEBs and CCS administrative records where these threats are relevant.¶

13. Operational and Manageability Considerations

Implementations SHOULD expose retained-custody volume, pending acceptance and rejection information, signal aggregation timers and thresholds, re-forward counts, expirations, malformed blocks and signals, authorization failures, and storage-related rejections. Operators SHOULD document acceptance and re-forwarding policy.¶

14. Implementation Status

This section records implementation experience in accordance with [RFC7942] and is intended to be removed before publication as an RFC.¶

The European Space Agency Bundle Protocol implementation supports CTEB and CCS encoding and processing, acceptance and rejection policy, custody retention constraints, timer- and signal-triggered re-forwarding, duplicate handling, and compressed signal aggregation. It has been exercised in simulations including a lunar relay, rover, ground station, and control centers.¶

NASA Goddard Space Flight Center BPNode Build 7.0.5 implemented the custody-transfer features and was tested aboard the CAPSTONE spacecraft during multiple uplink and downlink passes at lunar distances. The implementation information reflects the status reported in June 2026.¶

15. References

Appendix A. Acknowledgements

The author would like to acknowledge the substantial technical contributions of Aida Manole, Alice LeBihan, and Yanik Jeck to the development, review, discussion, and refinement of the mechanisms specified in this document. Their contributions to the corresponding CCSDS work significantly influenced the design and maturation of this specification.¶

Author's Address