| Internet-Draft | BPv7 TREB | September 2026 |
| Koo | Expires 26 March 2027 | [Page] |
This document defines a Traceroute Extension Block for Bundle Protocol Version 7 (BPv7). The extension block provides path discovery and per-hop performance measurement capabilities for Delay-Tolerant Networks (DTNs). Each node along the bundle's path appends a hop record containing its endpoint identifier, timestamp, link characteristics, and convergence layer information. This enables comprehensive network diagnostics including path verification, delay analysis, link type identification, and congestion monitoring without requiring status reports from every intermediate node.¶
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 26 March 2027.¶
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.¶
Network diagnostic tools are essential for operational networks. In DTN, particularly space communications, operators need visibility into:¶
While Bundle Protocol Version 7 [RFC9171] provides Bundle Status Reports (BSRs) that can theoretically provide some path information, using BSRs for routine path tracking is inefficient. Enabling status reports for every bundle creates significant network overhead, as each intermediate node must generate and transmit a separate status report bundle back to the source. This approach is particularly problematic in bandwidth-constrained space networks.¶
This specification addresses these needs through a comprehensive yet selective traceroute mechanism that can be enabled on specific diagnostic bundles when path visibility is required.¶
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.¶
This document uses terminology from [RFC9171]:¶
This document requests IANA to assign a block type code for the Traceroute Extension Block from the "Bundle Block Types" registry.¶
Suggested value: TBD1 (recommended: 194 or higher, in the Specification Required range)¶
The block-type-specific-data is encoded as CBOR [RFC8949] following [RFC9171] Appendix B conventions:¶
; Traceroute Extension Block Data traceroute-data = [ traceroute-id: uint, ; Unique identifier hop-limit: uint .size 1, ; Max hop-records (1-255) hop-records: [* hop-record] ; Array of hop records ] hop-record = [ self-node-eid: eid, ; Current node next-node-eid: eid, ; Next hop node event-type: event-type-code, ; Event at this node dtn-timestamp: dtn-time, ; When event occurred link-info ; Link characteristics ] ; Link characteristics grouped for modularity link-info = [ link-type: link-type-code, link-distance: link-distance-km, cl-type: cl-type-code, congestion-status: congestion-status-code ] event-type-code = uint .size 1 ; 0 = bundle-creation ; 1 = bundle-forwarding ; 2 = bundle-delivery ; 3 = bundle-deletion ; 4-255 = reserved link-type-code = uint .size 1 ; 0 = unknown/not-applicable ; 1 = RF (Radio Frequency) ; 2 = optical/laser ; 3 = internet/terrestrial ; 4 = inter-satellite-link (ISL) ; 5-255 = reserved link-distance-km = uint ; 0 = unknown/withheld ; 1+ = distance in kilometers cl-type-code = uint .size 1 ; 0 = unknown/not-applicable ; 1 = LTP ; 2 = TCPCLv3 ; 3 = TCPCLv4 ; 4 = UDPCL ; 5-255 = reserved congestion-status-code = uint .size 1 ; 0 = unknown ; 1 = very low (0-10%) ; 2 = low (11-30%) ; 3 = medium (31-60%) ; 4 = high (61-80%) ; 5 = very high (81-100%) ; 6-100 = exact percentage ; 101-255 = reserved dtn-time = uint ; Milliseconds since DTN epoch¶
The following block processing control flags MUST be set:¶
This ensures the traceroute block is preserved even by nodes that do not understand it.¶
A departure node MAY add a Traceroute Extension Block to any bundle. The first hop-record (hop-records[0]) MUST always represent the departure node.¶
When creating a bundle with a Traceroute Extension Block:¶
The BPA MUST create an initial hop-record with: self-node-eid set to the local node's EID; next-node-eid set to the next hop's EID (from routing table); event-type set to 0 (bundle-creation); dtn-timestamp set to current DTN time in milliseconds; link-info set to [0, 0, 0, 0] or known values.¶
The traceroute-id SHOULD be unique within the scope of the departure node (typically 0, incremented for retries).¶
The hop-limit SHOULD be set to a reasonable value based on expected network diameter (suggested default: 32).¶
If the departure node wants to receive traceroute information via status reports, the bundle processing control flags for forwarding, delivery, and deletion reporting SHOULD be set accordingly.¶
A traceroute carrier bundle is a bundle specifically created for gathering path information. The Traceroute Extension Block SHOULD be placed as the last extension block (before the payload block) to enable efficient hop-record appending. Since [RFC9171] requires the payload block to be the last block of a bundle, appending a hop-record displaces only the payload block. Using a fixed payload such as "This bundle is the host of traceroute extension block." allows the payload block to be pre-encoded as a constant, making the cost of appending a hop-record independent of the number of extension blocks present.¶
When the traceroute carrier bundle reaches its destination, the destination node includes the accumulated Traceroute Extension Block in the delivery status report returned to the departure node. Similarly, if a bundle is deleted at any intermediate node, the deletion status report carries the accumulated traceroute data up to that point. This enables complete forward-path visibility and failure localization from a single diagnostic bundle.¶
Any intermediate node in the bundle's path has the following options:¶
The node MAY ignore this extension block and forward it unchanged.¶
The node SHALL NOT remove this extension block.¶
The node MAY protect this extension block with BPSec [RFC9172] if security context permits.¶
If processing the block, the node MUST first check the hop-limit. If the number of hop-records equals hop-limit, the BPA SHALL forward the bundle without appending a new hop-record.¶
Otherwise, the BPA MUST determine link-info elements and append a new hop-record:¶
Determine link-info: link-type from the interface that received the bundle (1=RF, 2=optical, 3=internet, 4=ISL, 0=unknown); link-distance as estimated distance in kilometers (0 if unknown); cl-type from the convergence layer that delivered the bundle; congestion-status from local resource utilization.¶
Append hop-record with: self-node-eid set to the local node's EID; next-node-eid set to the next hop's EID; event-type set to 1 (bundle-forwarding); dtn-timestamp set to current DTN time; link-info set to determined values.¶
Rationale for optional processing: nodes may not trust traceroute from unknown sources, classified missions may prohibit topology disclosure, or resource-constrained nodes may skip optional features.¶
When a BPA delivers a bundle containing a Traceroute Extension Block:¶
The BPA MUST append a final hop-record with: self-node-eid set to the local node's EID; next-node-eid set to the local node's EID (self-delivery); event-type set to 2 (bundle-delivery); dtn-timestamp set to current DTN time; link-info set to characteristics of the final link.¶
The completed traceroute-data is delivered to the application.¶
If bundle processing control flags request a delivery report, the node MUST include the complete Traceroute Extension Block (with all accumulated hop-records) in the delivery status report.¶
When a node deletes a bundle containing a Traceroute Extension Block (due to lifetime expiration, storage exhaustion, or other reasons):¶
The node SHOULD append a hop-record with event-type set to 3 (bundle-deletion) before generating any deletion status report.¶
If bundle processing control flags request deletion reports, the node MUST include the Traceroute Extension Block (with the deletion hop-record) in the deletion status report.¶
This enables the departure node to identify precise deletion locations and distinguish between network failures (no reports) and intentional deletion (deletion report received).¶
When a bundle contains a Traceroute Extension Block AND the bundle's processing control flags request reporting, nodes SHALL generate appropriate status reports with the Traceroute Extension Block included. This comprehensive reporting enables the departure node to distinguish between network failures (silence after last forwarding report) and intentional deletions (explicit deletion report with event-type=3).¶
Intermediate nodes generating forwarding status reports:¶
SHALL generate bundle forwarding status reports as requested by bundle processing control flags.¶
MUST append a new hop-record for this node's forwarding event with: self-node-eid set to this node's EID; next-node-eid set to the next hop EID (the node this bundle is being forwarded to); event-type set to 1 (bundle-forwarding); dtn-timestamp set to current time; link-info set to determined values.¶
MUST include the Traceroute Extension Block in the forwarding status report bundle, containing ALL previously accumulated hop-records (from bundle reception) PLUS the newly created hop-record from step 2.¶
By including the forwarding hop-record in the status report, the departure node can identify:¶
Last successful forwarding point: If forwarding fails, the last received status report shows which node forwarded to which next-hop.¶
Failure location: If bundle disappears after Node N's forwarding report, the failure occurred between Node N and its declared next-hop (or at the next-hop itself).¶
Complete forwarding chain: Each status report progressively builds the complete path topology.¶
The destination node MUST include the complete Traceroute Extension Block with all hop-records including the final delivery record (event-type=2) in the delivery status report. This confirms successful end-to-end delivery with full path visibility.¶
When a node deletes a bundle, it MUST include the Traceroute Extension Block with a deletion hop-record (event-type=3) appended in the deletion status report. This provides explicit notification of deletion location and reason (congestion, storage exhaustion, lifetime expiration, etc.).¶
A traceroute operation completes when the departure node receives sufficient information to determine the outcome. The following conditions define traceroute completion:¶
A traceroute completes successfully when the departure node receives a delivery status report from the destination node containing the Traceroute Extension Block with event-type=2 (bundle-delivery). The complete hop-records array provides full end-to-end path visibility.¶
A traceroute completes unsuccessfully under the following conditions:¶
Deletion: The departure node receives a deletion status report containing the Traceroute Extension Block with event-type=3 (bundle-deletion). The hop-records reveal the path up to the deletion point and the deleting node's identity.¶
Truncation: The number of hop-records reaches hop-limit before the bundle reaches its destination. The traceroute data is incomplete but still provides partial path information.¶
Timeout: No status report arrives within the expected time window. The last received forwarding status report (if any) indicates the last known successful hop. Silence after that point suggests failure between the last reporting node and its declared next-hop.¶
As required by [RFC9171] Section 5.8, this section defines rules for replication of the Traceroute Extension Block in bundle fragments.¶
A Traceroute Extension Block SHALL have its "Block must be replicated in every fragment" processing control flag (bit 0) set to 0. Under [RFC9171] Section 5.8, the block is then replicated only into the fragment whose offset is zero. Exactly one Traceroute Extension Block survives reassembly, and its hop-records remain an unambiguous ordered path.¶
A departure node creating a bundle specifically for traceroute diagnostics SHOULD set the "Bundle must not be fragmented" flag (bit 2) in the primary block to avoid fragmentation entirely.¶
Nodes MAY withhold sensitive information by setting link-info fields to their "unknown" values:¶
link-info = [0, 0, 0, 0] ; All fields withheld¶
A link-info array with any element set to 0 (unknown) SHALL NOT be treated as an error. This supports deployments where nodes in different administrative domains may have varying disclosure policies.¶
The Traceroute Extension Block reveals network topology, node identities, link characteristics, and timing information. In sensitive environments, operators SHOULD:¶
Unlike IP traceroute which generates ICMP responses, this mechanism does not generate additional bundles. The traceroute data travels with the original bundle, limiting amplification potential.¶
This document requests IANA to register the following entry in the "Bundle Block Types" registry:¶
| Value | Description | Reference |
|---|---|---|
| TBD1 | Traceroute Extension Block | This document |
This document requests IANA to create a new registry titled "Traceroute Extension Block Event Type Codes" with the following initial values:¶
| Value | Description | Reference |
|---|---|---|
| 0 | bundle-creation | This document |
| 1 | bundle-forwarding | This document |
| 2 | bundle-delivery | This document |
| 3 | bundle-deletion | This document |
| 4-255 | Unassigned |
This document requests IANA to create a new registry titled "Traceroute Extension Block Link Type Codes" with the following initial values:¶
| Value | Description | Reference |
|---|---|---|
| 0 | unknown/not-applicable | This document |
| 1 | RF (Radio Frequency) | This document |
| 2 | optical/laser | This document |
| 3 | internet/terrestrial | This document |
| 4 | inter-satellite-link | This document |
| 5-255 | Unassigned |
This document requests IANA to create a new registry titled "Traceroute Extension Block CL Type Codes" with the following initial values:¶
| Value | Description | Reference |
|---|---|---|
| 0 | unknown/not-applicable | This document |
| 1 | LTP | This document |
| 2 | TCPCLv3 | This document |
| 3 | TCPCLv4 | This document |
| 4 | UDPCL | This document |
| 5-255 | Unassigned |
This document requests IANA to create a new registry titled "Traceroute Extension Block Congestion Status Codes" with the following initial values:¶
| Value | Description | Reference |
|---|---|---|
| 0 | unknown | This document |
| 1 | very-low (0-10%) | This document |
| 2 | low (11-30%) | This document |
| 3 | medium (31-60%) | This document |
| 4 | high (61-80%) | This document |
| 5 | very-high (81-100%) | This document |
| 6-100 | exact percentage | This document |
| 101-255 | Reserved |
This appendix provides complete CBOR encoding examples for representative scenarios.¶
Network topology:¶
Earth Ground Station (ipn:1.0)
|
| RF link, 400,000 km, LTP
v
Lunar Relay Satellite (ipn:2.0)
|
| RF link, 2,000 km, LTP
v
Surface Rover (ipn:3.0)
¶
Complete CBOR encoding (89 bytes):¶
83 00 18 20 83 85 82 02 82 01 00 82 02 82 02 00 00 1B 00 00 00 C3 E1 D8 30 00 84 00 00 00 00 85 82 02 82 02 00 82 02 82 03 00 01 1B 00 00 00 C3 E1 D8 35 3C 84 01 1A 00 06 1A 80 01 00 85 82 02 82 03 00 82 02 82 03 00 02 1B 00 00 00 C3 E1 D8 35 46 84 01 19 07 D0 01 00¶
For Neptune distances (4.5 billion km), link-distance exceeds uint32 maximum (4,294,967,295), requiring uint64 encoding:¶
link-info = [1, 4500000000, 1, 3]
CBOR: 84 01 1B 00 00 00 01 0C 38 8D 00 01 03
^^ uint64 marker
¶
This validates the design decision to use unconstrained CBOR uint for link-distance.¶
| Scenario | Distance | Total Size | Size/Hop |
|---|---|---|---|
| Cislunar | 400,000 km | 89 bytes | ~28 bytes |
| Mars | 225,000,000 km | 93 bytes | ~29 bytes |
| Neptune | 4,500,000,000 km | 101 bytes | ~32 bytes |
Formula: TracerouteEB_size ~= 10 + (28-32 * hops) bytes¶
The author thanks the CCSDS SIS-DTN Working Group for their input on DTN diagnostic requirements.¶