]> Korea Aerospace Research Institute (KARI)

Republic of Korea chkoo@kari.re.kr

Transport Delay-Tolerant Networking DTN BPv7 traceroute diagnostics 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.

Introduction Network diagnostic tools are essential for operational networks. In DTN, particularly space communications, operators need visibility into:

• Path Discovery: Which nodes relayed the bundle?
• Delay Analysis: How long did each hop take?
• Link Performance: Which link type was used (RF, Laser, Internet)?
• Protocol Analysis: Which convergence layer protocol was employed?
• Congestion Awareness: Which nodes are experiencing resource constraints?

While Bundle Protocol Version 7 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.

Conventions and Definitions 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. This document uses terminology from :

Bundle Protocol Agent (BPA):

The software component that implements the Bundle Protocol.

Endpoint Identifier (EID):

A name for a BP endpoint, used as the source or destination of bundles.

Extension Block:

A block other than the primary block or payload block that extends the capabilities of the Bundle Protocol.

Extension Block Specification

Block Type Code 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)

CDDL Definition The block-type-specific-data is encoded as CBOR following Appendix B conventions:

Block Processing Control Flags The following block processing control flags MUST be set:

• Bit 0 (must-replicate): MUST be 0 by default
• Bit 2 (delete-if-not-processed): MUST be 0
• Bit 4 (discard-if-not-processed): MUST be 0

This ensures the traceroute block is preserved even by nodes that do not understand it.

Processing Rules

At the Departure Node 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:

1. 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.
2. The traceroute-id SHOULD be unique within the scope of the departure node (typically 0, incremented for retries).
3. 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.

Traceroute Carrier Bundle 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 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.

At Intermediate Nodes Any intermediate node in the bundle's path has the following options:

1. The node MAY ignore this extension block and forward it unchanged.
2. The node SHALL NOT remove this extension block.
3. The node MAY protect this extension block with BPSec 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:

1. 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.
2. 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.

At the Destination Node When a BPA delivers a bundle containing a Traceroute Extension Block:

1. 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.
2. The completed traceroute-data is delivered to the application.
3. 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.

On Bundle Deletion When a node deletes a bundle containing a Traceroute Extension Block (due to lifetime expiration, storage exhaustion, or other reasons):

1. The node SHOULD append a hop-record with event-type set to 3 (bundle-deletion) before generating any deletion status report.
2. 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).

Inclusion in Status Reports 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).

Forwarding Status Reports Intermediate nodes generating forwarding status reports:

1. SHALL generate bundle forwarding status reports as requested by bundle processing control flags.
2. 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.
3. 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.

Delivery Status Reports 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.

Deletion Status Reports 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.).

Traceroute Completion A traceroute operation completes when the departure node receives sufficient information to determine the outcome. The following conditions define traceroute completion:

Successful 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.

Unsuccessful Completion 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.

Partial Path Visibility Even in unsuccessful cases, the accumulated hop-records provide diagnostic value. Operators can analyze:

• The path traversed before failure
• Per-hop timing to identify delay sources
• Link characteristics at each hop
• Congestion status along the path

Fragmentation As required by 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 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.

Privacy and Policy Considerations 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.

Security Considerations

Information Disclosure The Traceroute Extension Block reveals network topology, node identities, link characteristics, and timing information. In sensitive environments, operators SHOULD:

• Use Bundle Protocol Security to encrypt traceroute data
• Configure nodes to withhold sensitive link-info fields
• Restrict traceroute processing to authorized bundles

Amplification Attacks 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.

Resource Exhaustion A malicious actor could send bundles with large hop-limit values. Implementations SHOULD:

• Enforce a maximum hop-limit (suggested: 255)
• Rate-limit traceroute block processing
• Monitor for unusual traceroute patterns

IANA Considerations

Bundle Block Type Registration This document requests IANA to register the following entry in the "Bundle Block Types" registry:

Value	Description	Reference
TBD1	Traceroute Extension Block	This document

Event Type Codes Registry 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

Link Type Codes Registry 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

CL Type Codes Registry 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

Congestion Status Codes Registry 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

References Normative References

CBOR Encoding Examples This appendix provides complete CBOR encoding examples for representative scenarios.

Cislunar Scenario Network topology: Complete CBOR encoding (89 bytes):

Outer Solar System Scenario (uint64 Required) For Neptune distances (4.5 billion km), link-distance exceeds uint32 maximum (4,294,967,295), requiring uint64 encoding: This validates the design decision to use unconstrained CBOR uint for link-distance.

Size Analysis

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

Acknowledgments The author thanks the CCSDS SIS-DTN Working Group for their input on DTN diagnostic requirements.