]> Korea Aerospace Research Institute

Republic of Korea chkoo@kari.re.kr

Internet Delay-Tolerant Networking DTN BPv7 traceroute This document defines a Traceroute Extension Block (TREB) for Bundle Protocol Version 7 (BPv7). Each participating node along a bundle's path appends a hop-record containing its Node ID, the next hop it selected, the time of the recorded event, and link characteristics. The same block, copied into bundle status reports, returns traceroute data to the source. The mechanism is opt-in and intended for designated diagnostic bundles on scheduled, bandwidth-constrained paths. In delivery-report-only operation a single status report returns the full recorded path and also records its own return path, giving a round-trip trace. Status report generation remains governed by RFC 9171.

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, and to which next hop each node forwarded it;
• Timing: when each node queued the bundle for forwarding, and when it planned to transmit it;
• Link characteristics: which link type, data rate, and convergence layer were used on each hop;
• Congestion awareness: which links had more traffic queued than their next contact could carry;
• Failure localization: where a bundle was deleted, as opposed to simply not being heard from.

Bundle Status Reports (BSRs) can provide some of this information, but path reconstruction from BSRs requires every intermediate node to generate a forwarding report, each report identifies only the reporting node, and the reports carry no link detail. The mechanism defined here records the path in the bundle itself. When only a delivery (and, if requested, a deletion) report is used, a single report returns the full recorded path, and records its own return path, giving a round-trip trace; when forwarding reports are also requested, each carries only the reporting node's own hop-record, so total report volume grows linearly with path length. quantifies both modes.

Scope and Design Goals

• Opt-in: the TREB is added only to bundles designated for DTN path troubleshooting and analysis (typically dedicated "traceroute carrier bundles", ).
• Simplicity and reuse: a single block format is used both in the bundle being traced and in the status reports that return its contents.
• Independence: the TREB does not depend on any other extension block and does not replace any ().
• Constant-size start: at departure the TREB has a fixed-size header and one hop-record.
• Tolerance of transparent nodes: nodes that do not understand or choose not to process the TREB forward it unchanged, and their presence is detectable ().
• Round-trip: delivery and deletion report copies record the return path; forwarding report copies are never modified, so report volume remains linear ().
• No change to RFC 9171 status report semantics or format.

radiate-time separates the time spent waiting for a contact; further separation of transmission and propagation delay is out of scope of this document ().

Relationship to Other Mechanisms The TREB is independent of the extension blocks defined in ; it neither requires nor replaces them. The relationships are as follows.

Previous Node Block (type 6):

Identifies only the node that forwarded the bundle to the local node and is replaced at every hop. The TREB accumulates one record per participating node.

Bundle Age Block (type 7):

Accumulates the bundle's age without requiring synchronized clocks. The TREB records the time of each node's event and does not compute age or delay. requires a Bundle Age Block when the creation time is zero; such a source will typically also report an event-time of zero.

Hop Count Block (type 10):

Counts hops, i.e., occasions on which the bundle was forwarded from one node to another, and enforces a hop limit (1 to 255) for loop protection (). The TREB record-limit follows the convention of the hop limit and takes a value in the same range (1 to 255). Unlike the hop limit, record-limit is not a loop-protection mechanism: it only caps the number of hop-records carried in the bundle, and a bundle SHALL NOT be deleted because its record-limit has been reached. Records beyond record-limit are reported as overflow (). As the hop limit applies to each bundle, and a status report is a new bundle, record-limit applies separately to each direction of a round-trip trace (). Delivery and deletion report copies carry the hop count (). Because transparent nodes do not append records, the number of hop-records never exceeds the number of nodes traversed. Traceroute carrier bundles SHOULD include a Hop Count Block.

Compressed status reporting:

defines compressed reporting (administrative record type 14), which aggregates per-event reports. The TREB instead accumulates a path in the bundle. The two are complementary; handling of TREBs in combination with compressed reporting is left for future work.

IOAM:

The approach is analogous to in-situ OAM trace options in IP networks , adapted to store-and-forward operation and to BPv7 status reporting.

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 the terms Bundle Protocol Agent (BPA), Endpoint Identifier (EID), Node ID, extension block, administrative record, and bundle status report as defined in . CDDL is used to describe CBOR structures; the rules "eid" and "dtn-time" are those of .

TREB:

Traceroute Extension Block.

Traced bundle:

A bundle that is not an administrative record and carries a TREB.

Report copy:

A TREB carried in a bundle whose payload is a bundle status report ().

Departure node:

The node that adds the TREB to a bundle; the source of the bundle.

Participating node:

A node that processes the TREB of a traced bundle, or of a delivery or deletion report copy on its return path, and appends a hop-record.

Turnaround record:

The first hop-record with event-type 2 (delivery) or 3 (deletion) in a report copy.

Transparent node:

A node that forwards a traced bundle, or a delivery or deletion report copy on its return path, without processing the TREB, because it does not support this specification or declines to participate. It forwards the TREB unchanged and appends no hop-record ().

Return record:

A hop-record that follows the turnaround record, appended to a delivery or deletion report copy on its way to the report-to endpoint ().

Traceroute carrier bundle:

A bundle created specifically to carry a TREB ().

Extension Block Specification

Block Type Code This document requests a block type code, TBD1, from the "Bundle Block Types" registry (). For experimentation before assignment, implementations MAY use a value from the range 192-255, which makes available for private and/or experimental use. The examples in this document use 194.

CDDL Definition The block-type-specific data of a TREB is a CBOR byte string containing:

Field Semantics

traceroute-id:

Identifies a traceroute at its departure node. The first traceroute-id used by a departure node SHOULD be chosen randomly; each subsequent traceroute-id SHALL be the previous traceroute-id plus 1, so that successive traceroutes can be related to one another. traceroute-id SHALL NOT be 0. This follows the assignment of report serial numbers in LTP (). A departure node SHALL NOT reuse a traceroute-id while a traceroute using it is in progress (). traceroute-id is copied into every report copy, so that report copies and treb-data returned by the destination application () can be matched to the traceroute without combining the source node ID and creation timestamp; the subject bundle identification in a bundle status report () provides an additional check.

record-limit:

Maximum number of hop-records in the TREB of a traced bundle, and, separately, the maximum number of return records in a report copy (). record-limit prevents the hop-records array from growing excessively in resource-constrained environments. When the TREB is full, participating nodes forward it unchanged but still report their own hop-records (, ). The departure node can determine from report-value in forwarding reports whether the limit was exceeded (overflow; ). See for its relationship to the Hop Count Block.

report-value:

report-value SHALL be present in a report copy and SHALL NOT be present in a traced bundle; a TREB is therefore encoded as a 3-element array in a traced bundle and as a 4-element array in a report copy (). Its meaning depends on the report type:

• Forwarding report (record-position): the position, within the complete trace, of the single contained hop-record. Because it is derived from the number of hop-records in the TREB, it ranges from 0 to record-limit; the value record-limit denotes the overflow position, i.e., the record was created after the TREB had become full ().
• Delivery or deletion report (hop-count): the hop count of the reported bundle's Hop Count Block at the reporting node, or 0 if the bundle has no Hop Count Block. The hop-records of these reports always start at position 0 and may be followed by return records ().

See for a worked example.

self-node-id, next-node-id:

Node IDs (). With the "ipn" scheme these are administrative endpoints (). next-node-id is the next hop for which the bundle was queued. For delivery and deletion records, next-node-id equals self-node-id.

event-type:

The event that the hop-record describes at the recording node: departure, when the departure node queues the bundle; forwarding, when an intermediate node queues the bundle for the next hop (including a report bundle on its return path); delivery, when the destination delivers the bundle; or deletion, when the node deletes the bundle. Code values are listed in .

event-time:

DTN time (), according to the recording node's clock, at which the node recorded the event: for departure and forwarding, the time at which the node, having selected the next hop, queues the bundle for transmission; for delivery and deletion, the time of delivery or deletion. 0 means unknown or withheld. The difference between a record's radiate-time and the event-time of the following record includes transmission and propagation delays, which this specification does not separate; the time at which a bundle was actually forwarded is given by the status time of a forwarding report (). Comparing times of different nodes assumes synchronized clocks, which does not require. Analysis of propagation delay is out of scope of this document.

radiate-time:

DTN time, according to the recording node's clock, at which the node plans to begin transmitting the bundle to next-node-id: equal to event-time if a contact with the next hop is in progress at event-time, and otherwise the start time of the next planned contact with it. It is set when the record is created and is not updated at actual transmission. For delivery and deletion records it is 0. 0 means unknown or withheld.

link-info:

Characteristics of the link toward next-node-id, as seen by the recording node. For delivery and deletion records, all elements of link-info are 0.

type:

Physical type of the link toward next-node-id, as seen by the recording node: RF, optical, terrestrial/Internet, or inter-satellite link (registry in ). 0 means unknown or withheld.

speed:

Nominal data rate of the link toward next-node-id, as known to the recording node when it creates the record, in kilobits per second (1000 bit/s), rounded up to the next integer; rates of 1 kbps or less are therefore encoded as 1. 0 means unknown or withheld.

distance:

Estimated distance to the next hop in kilometers, rounded up to the next integer; distances of 1 km or less are therefore encoded as 1. 0 means unknown or withheld.

cl:

Convergence layer used toward the next hop, identified by a value from the "SAND CL Types" registry defined by , so that a second convergence layer code space is not created. The range matches that registry (a 16-bit signed integer); negative values are for private and experimental convergence layers as defined there. The value 0, which that registry reserves, is used by this specification to mean unknown or withheld.

congestion:

Congestion of the link toward next-node-id at event-time, in percent: the volume of bundles queued for transmission to next-node-id, including this bundle, relative to the transmission volume (data rate times remaining duration) of the current or next planned contact with it, rounded up to the next integer and capped at 100. Values of 1% or less are therefore encoded as 1, and 100 indicates that the queued volume is expected to reach or exceed that contact. A node without contact volume information MAY use a locally defined approximation of the same ratio. 0 means unknown, not applicable, or withheld; for delivery and deletion records it is 0. Which values are considered significant is a matter of local policy.

Block Processing Control Flags The block processing control flags () of a TREB SHALL be set as follows:

• Bit 0 (block must be replicated in every fragment): 0.
• Bit 1 (transmit status report if block can't be processed): 0 by default. A departure node MAY set it to 1 on a traceroute carrier bundle, so that nodes that do not support this specification report "block unintelligible", identifying themselves. Such reports are subject to the same generation rules as any other status report () and add report traffic. In a report copy it SHALL be 0.
• Bit 2 (delete bundle if block can't be processed): 0.
• Bit 4 (discard block if it can't be processed): 0.

These settings ensure that nodes that do not support this specification forward the TREB unchanged.

Processing Rules

Operation Overview This section is informative. It summarizes the processing specified in the rest of ; in case of conflict, the text of those sections takes precedence.

Traced Bundle and Status Reports on a Three-Node Path | B |------------------->| C | +-------+ +-------+ +-------+ hr0 hr1, hr3 hr2 departure intermediate destination ]]>

Departure Node State Transitions

Processing at Intermediate and Destination Nodes delivery/deletion | RC: append return | record unless full | or declined; | forwarding RC: | forward unchanged | (Section 4.4) | no +-- Process TREB (local policy)? ------no---> forward TREB | unchanged | (transparent node) | yes +-- Destination? ----------------------yes--> create delivery | record; append if | TREB not full; | deliver | no | V V Select next hop; Delivery report? create forwarding record yes: RC = all | records (+ own if +-- TREB full? --yes--> leave TREB TREB full), | unchanged rv = hop count | no | V | Append record | | | +<------------------------+ V Queue for transmission <--- re-queued: replace own record | V Forwarded | V Forwarding report? yes: RC = [own record], rv = position (record-limit if TREB was full) At any time, if the bundle is deleted and a deletion report is generated: create deletion record; RC = all records + deletion record, rv = hop count. ]]>

At the Departure Node A departure node MAY add a TREB to any bundle it sources, other than a bundle whose payload is an administrative record. It SHALL set traceroute-id (), set record-limit (a value based on expected network diameter; 32 is suggested), and set hop-records to an empty array; report-value is absent. It SHALL append the first hop-record (event-type 0) when queuing the bundle for transmission, as specified in . hop-records[0] therefore always describes the departure node. The source node ID, destination, and report-to EID of a traced bundle SHALL NOT be the null endpoint ( and ).

Traceroute Carrier Bundle A traceroute carrier bundle is a bundle created specifically to gather path information. For a traceroute carrier bundle:

• The "request reporting of bundle delivery" flag SHALL be set, the "request reporting of bundle deletion" flag SHOULD be set, and the "request reporting of bundle forwarding" flag MAY be set (). Setting the flags requests reports; it does not oblige any node to generate them ().
• The destination SHOULD be an endpoint at which an application is registered, since delivery requires a registration ().
• The "bundle must not be fragmented" flag SHOULD be set.
• A Hop Count Block SHOULD be included. Note: The hop count, returned as report-value in delivery and deletion reports, lets the departure node determine how many hops were made by nodes that do not support or do not process the TREB, including consecutive ones that the trace alone cannot reveal ().
• The TREB SHOULD be the last extension block before the payload block, and the payload SHOULD be a short fixed value, such as "This bundle is the host of traceroute extension block." (as in ). The payload block can then be pre-encoded as a constant, and appending a hop-record displaces only that block, making the cost of appending independent of the number of extension blocks present.

Alternatively, the destination application MAY return the delivered treb-data to the departure node in the payload of an ordinary bundle (). This provides delivery results even where status reporting is disabled, but does not report deletions or intermediate progress.

Appending a Hop-Record A participating node creates its hop-record, and appends it to the TREB unless the TREB is full (see below), when the event it records occurs: for event-types 0 and 1, when the node has decided to process the TREB, has selected the next hop, and queues the bundle for transmission to it; for event-type 2, at delivery; for event-type 3, at deletion. If a bundle is removed from a transmission queue and queued again, for example after a failed transmission attempt or a change of next hop, the node SHALL replace the hop-record it appended for the earlier queuing with a new one. A node thus contributes at most one hop-record to each transmitted bundle. Before appending, the node SHALL compare with record-limit the number of hop-records in the TREB of a traced bundle, or the number of return records in a report copy (). If that number is equal to or greater than record-limit, the TREB is full: the node SHALL NOT modify the TREB and SHALL otherwise process and forward the bundle normally. The node still creates its hop-record, which it includes in any report copy it generates ().

At Intermediate Nodes An intermediate node MAY decline to process the TREB of a traced bundle (for example, due to policy, trust in the source, topology-disclosure restrictions, or resource constraints). A node that declines, i.e., a transparent node, SHALL forward the TREB unchanged and SHALL NOT remove it. A node that processes the TREB SHALL create a hop-record with event-type 1 and append it as specified in . A TREB in a bundle whose "ADU is an administrative record" bundle processing control flag is set is a report copy. Because the primary block is immutable (), every node can make this distinction. Report copies are handled as follows:

• A delivery or deletion report copy, i.e., one that contains a hop-record with event-type 2 or 3, records the return path. An intermediate node MAY decline to process it, as for a traced bundle. A node that processes it SHALL create a return record with event-type 1 when queuing the report bundle for its next hop and append it to hop-records as specified in ; report-value remains the last element. Up to record-limit return records are appended, independently of the number of records before the turnaround record, and the departure node obtains a round-trip trace.
• A forwarding report copy, which contains no such record, SHALL NOT be modified. It keeps exactly one hop-record, so that total report volume grows linearly with the path length ().

No node adds a TREB to a bundle whose payload is an administrative record (), and the node that delivers a report bundle does not append a record.

At the Destination Node When delivering a traced bundle, a participating node SHALL create a hop-record with event-type 2, with next-node-id equal to self-node-id, and append it as specified in . The BPA MAY make the resulting treb-data available to the application registered at the destination endpoint, so that it can be returned to the departure node (). The interface for doing so is implementation-specific.

On Bundle Deletion When a participating node deletes a traced bundle and generates a deletion status report for it, the node SHALL create a hop-record with event-type 3 and next-node-id equal to self-node-id and include it in the report copy (). The reason for deletion is conveyed by the status report's reason code.

Status Reports Nodes supporting this specification SHOULD enable status reporting for traced bundles, subject to local policy. When a participating node generates a bundle status report for a traced bundle, the report bundle SHALL carry exactly one TREB, the report copy, whose traceroute-id and record-limit are copied from the traced bundle's TREB, whose hop-records are set as follows, and to which report-value is added as the last element:

Forwarding report:

hop-records contains only the node's hop-record for the forwarding being reported, and report-value is its position: the number of hop-records the TREB contained before that record, i.e., record-limit if the TREB was full.

Delivery report:

hop-records contains all hop-records of the TREB followed, if not already among them because the TREB was full, by the node's delivery record; report-value is the hop count of the bundle's Hop Count Block, or 0 if the bundle has none.

Deletion report:

hop-records contains all hop-records of the TREB followed by the node's deletion record (); report-value is the hop count of the bundle's Hop Count Block, or 0 if the bundle has none.

Reception report:

No TREB.

A report copy therefore contains at most record-limit + 1 hop-records when generated. Up to record-limit return records may then be appended (), so a report copy contains at most 2 x record-limit + 1 hop-records when it arrives. A node MAY omit the report copy, for example when the report-to EID does not identify the bundle's source node, or under the mitigations in .

Path Reconstruction and Completion The departure node correlates report copies with the traceroute by traceroute-id, checked against the subject bundle identification in each status report (). It places the hop-record of a forwarding report at position report-value, and the hop-records of a delivery or deletion report at positions 0, 1, and so on, of the reconstructed trace, up to and including the first hop-record with event-type 2 or 3 (the turnaround record). The hop-records that follow the turnaround record are return records; in the order received, they describe the path of the report bundle toward the report-to endpoint and are not placed at positions. A record received more than once has identical content. Consecutive records are linked by next-node-id and the following record's self-node-id. None of this requires synchronized clocks. Positions 0 to record-limit - 1 are filled as above. A record whose position would be record-limit or higher was created after the TREB had become full (overflow). Overflow records are not ordered by position; the departure node orders them by chaining, starting from the next-node-id of the record at position record-limit - 1. A forwarding report with report-value equal to record-limit, or a delivery or deletion report whose turnaround record is at position record-limit, indicates that overflow occurred; a larger record-limit can then be used for subsequent probes. gives worked examples. summarizes this procedure; it is informative, and the text above takes precedence.

Path Reconstruction at the Departure Node slot[rv] := record V | for i = 0, 1, ... over the no (rv = L: overflow) records of the RC up to and | including the turnaround +----------> add record to OVF record (event-type 2 or 3): i < L ? --yes--> slot[i] := record | no +-------------> add record to OVF | records after the turnaround record --> add to RET, in order | rv > 0 ? --yes--> record Hr := rv | V ... repeat for each RC until completion (Figure 2) ... | V 1. Path := slot[0], slot[1], ... in order; then OVF records ordered by chaining from the next-node-id of the last record in slot[L-1] 2. Empty slot k before the -> report of the node at position k last filled slot missing (lost or not generated) 3. slot[k].next-node-id -> transparent node(s) after != slot[k+1].self-node-id slot[k]; the first is slot[k].next-node-id 4. OVF not empty or an -> overflow; use a larger RC with rv = L record-limit next time 5. Hr known: Hr - (number of records with event-type 0 or 1, including OVF, excluding RET) = hops made by transparent nodes 6. Return path := RET in order; if the last next-node-id is not this node, the return path was partly traced ]]>

Replicated bundles: If a node forwards copies of a traced bundle to several next hops, each copy carries its own record (), and records of different copies can have the same position. The departure node then keeps a set of records per position and reconstructs a tree by chaining; each delivery or deletion report contains one branch. Completion () occurs at the first delivery report; a departure node expecting several deliveries can instead complete at treb-completion-timeout ().

Successful Completion A traceroute completes successfully when the departure node receives a delivery report whose report copy contains a hop-record with event-type 2, or the destination application returns the treb-data.

Unsuccessful Completion

• Deletion: a deletion report with a report copy identifies the deleting node and the recorded path up to it.
• Timeout: no delivery or deletion report arrives before treb-completion-timeout expires (). Forwarding reports received so far, if any, bound the progress of the bundle, but because report generation is discretionary (), silence after a given node indicates neither loss nor deletion by itself.

Interpreting Gaps With forwarding reports, the departure node can distinguish two kinds of gap in the reconstructed trace:

Empty position:

A participating node appended a record, but its forwarding report was not received (lost, or not generated).

Adjacent positions whose records do not chain:

record k's next-node-id differs from record k+1's self-node-id. At least one transparent node lies between them (or, if bit 1 was set per , may have reported "block unintelligible").

A delivery or deletion report fills all empty positions up to the reporting node. Among overflow records and return records only the chaining test is available. If the next-node-id of the last return record is not the node that received the report, the return path was only partly traced (transparent nodes, or record-limit reached). The chaining test identifies the first node of a segment of transparent nodes but not how many nodes the segment contains. In a delivery or deletion report, report-value (the hop count) minus the number of records with event-type 0 or 1 in the reconstructed trace, including overflow records but excluding return records, gives the number of hops made by transparent nodes, provided every node updates the Hop Count Block as specified in . A delivery report whose report-value exceeds the hop limit set by the departure node indicates a node that did not enforce the hop limit.

Fragmentation With bit 0 of the block processing control flags set to 0 (), places the TREB only in the fragment whose offset is zero, so exactly one TREB survives reassembly and its hop-records remain a single ordered sequence. Hop-records are appended only to that fragment.

Privacy and Policy Considerations A participating node MAY withhold event-time, radiate-time, and any element of link-info by using the value 0; for example: A value of 0 in these fields SHALL NOT be treated as an error. This supports deployments spanning administrative domains with different disclosure policies. A node that must not disclose its identity declines to process the TREB ().

Management Information Base (MIB) Considerations The following managed parameter is part of the local configuration (Management Information Base) of a departure node. It does not appear in any bundle.

Parameter	Description	Units
treb-completion-timeout	Maximum time, measured by the departure node from when it queues the traced bundle (), during which it processes report copies for that bundle.	milliseconds

This interval requires only a local timer, not synchronized or absolute time, so it also applies to a departure node without an accurate clock (creation time 0); how the interval is measured is implementation-specific. When treb-completion-timeout expires, the departure node SHALL complete the traceroute () using only the report copies received up to that time, and SHALL ignore report copies for that bundle received afterwards. A traceroute also completes, before treb-completion-timeout expires, when a delivery or deletion report copy is received (); report copies for that traceroute received after completion are ignored. See . A bundle cannot be recalled once sent; a traced bundle may therefore remain in the network until its lifetime expires, and reports may still arrive after the timeout. To obtain a deletion report for a bundle whose lifetime expires, the departure node SHOULD set the bundle's lifetime so that it expires early enough for that report to arrive before treb-completion-timeout.

Implementation Status [RFC Editor: please remove this section before publication, as well as the reference to RFC 7942.] 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 . 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. According to , "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". No implementations are listed in this revision. Implementation reports, including measured overhead, will be added in a future revision.

Security Considerations

Information Disclosure The TREB reveals node identities, path, link characteristics, congestion, and timing. Operators SHOULD restrict TREB processing to authorized sources, and nodes MAY decline to participate or withhold fields (). Confidentiality can be provided by a Block Confidentiality Block (BCB) : hop by hop for the TREB of a traced bundle and of a delivery or deletion report copy, and by the reporting node for a forwarding report copy ().

Integrity and BPSec Like the Previous Node, Hop Count, and Bundle Age blocks , the TREB of a traced bundle, and of a delivery or deletion report copy on its return path, is modified at each participating node. It is therefore handled in the same way: end-to-end integrity or confidentiality of the TREB is not possible, and a Block Integrity Block (BIB) or BCB targeting it can only be applied hop by hop, with the forwarding node as security source and the next node as security acceptor . Appending a hop-record changes only the TREB; BIBs and BCBs targeting other blocks are unaffected. As with the values of those blocks, TREB field values, including traceroute-id (sequential after a random first value), are predictable and can be forged by an on-path node; the TREB relies on the same protection practice. Hop-records are unauthenticated end to end and SHALL be treated as diagnostic data only; they MUST NOT be used as input to routing or access-control decisions. A forwarding report copy is not modified after creation (); the reporting node MAY add a BIB or BCB targeting it, for example using the security contexts of .

Report Amplification The TREB does not by itself cause additional bundles to be generated; reports are generated only as requested and permitted under . However, report copies increase the size of reports. Because the report-to EID is not authenticated in BPv7, a spoofed diagnostic bundle could direct larger reports to a third party. This specification bounds the increase: a forwarding report carries exactly one hop-record, and a delivery or deletion report carries at most record-limit + 1 hop-records from the traced bundle and at most record-limit return records (at most 511 in total). Nodes SHOULD rate-limit report copy generation and MAY omit the report copy when the report-to EID does not identify the bundle's source node ().

Resource Exhaustion TREB growth is bounded by record-limit. Implementations SHOULD rate-limit TREB processing and MAY decline to process TREBs under resource pressure.

IANA Considerations

Bundle Block Type IANA is requested to register the following in the "Bundle Block Types" registry, from the range currently unassigned below 192:

Value	Description	Reference
TBD1	Traceroute Extension Block	This document

TREB Event Type Codes IANA is requested to create a registry titled "TREB Event Type Codes" in the "Bundle Protocol" registry group. Values are unsigned integers 0-255. Registration procedures : 0-191 Specification Required; 192-255 Private or Experimental Use. Initial values:

Value	Description	Reference
0	departure	This document
1	forwarding	This document
2	delivery	This document
3	deletion	This document
4-191	Unassigned
192-255	Private or Experimental Use	This document

TREB Link Type Codes IANA is requested to create a registry titled "TREB Link Type Codes" in the "Bundle Protocol" registry group. Values are unsigned integers 0-255. Registration procedures : 0-191 Specification Required; 192-255 Private or Experimental Use. Initial values:

Value	Description	Reference
0	unknown or withheld	This document
1	RF	This document
2	optical	This document
3	terrestrial / Internet	This document
4	inter-satellite link	This document
5-191	Unassigned
192-255	Private or Experimental Use	This document

No registry is created for convergence layer types () or for congestion, which is a numeric value.

References Normative References Informative References Consultative Committee for Space Data Systems

CBOR Encoding Examples Examples use the experimental block type value 194 and "ipn" Node IDs.

Lunar Scenario: Traced Bundle and Status Reports This example follows a traceroute carrier bundle over three nodes and shows, at each node, the complete bundle and the bundle status report (BSR) it generates. Forwarding, delivery, and deletion reports and status times are requested. The encodings were generated programmatically; sizes are of the complete encoded bundles. Times are DTN times in milliseconds. Notation: ipn:N.S stands for [2, [N, S]] and dtn:none for [1, 0]; << >> denotes CBOR-encoded data in a byte string. Primary-block flags 458820 (0x70044) = must not be fragmented, status time requested, and forwarding, delivery, and deletion reports requested; 2 = ADU is an administrative record. cl 3 is the SAND CL Types code point for LTP (CSID 5); cl -1 is a private value of that registry, used here to denote another convergence layer on the orbiter-lander link.

At the Departure Node Bundle as queued for ipn:2.0 (169 bytes): >], ; TREB (traced bundle: 3 elements, no report-value) [194, 2, 0, 0, << [17, 32, [ [ipn:1.0, ipn:2.0, 0, 841307664484, 841307664484, [1, 2000, 385000, 3, 12]] ]] >> ], ; payload block [1, 1, 0, 0, 'This bundle is the host of traceroute extension block.'] ] ]]>

At the Intermediate Node Bundle as queued for ipn:3.0 (209 bytes). Only the Hop Count Block and the TREB have changed: >], ; TREB (traced bundle: 3 elements, no report-value) [194, 2, 0, 0, << [17, 32, [ [ipn:1.0, ipn:2.0, 0, 841307664484, 841307664484, [1, 2000, 385000, 3, 12]], [ipn:2.0, ipn:3.0, 1, 841307665784, 841308265784, [1, 256, 250, -1, 47]] ]] >> ], ; payload block [1, 1, 0, 0, 'This bundle is the host of traceroute extension block.'] ] ]]> Forwarding report (137 bytes; 83 bytes without the report copy). The orbiter queued the bundle at 841307665784 (event-time), but its next contact with the lander was planned to begin 10 minutes later, which it records as radiate-time 841308265784. The BSR asserts forwarding at that time: > ], ; admin record payload block: bundle status report (forwarded) [1, 1, 0, 0, << [1, [ [[false], [true, 841308265784], [false], [false]], 0, ipn:1.1, [841307664384, 0]]] >>] ] ]]>

At the Destination Node Bundle as delivered (237 bytes): >], ; TREB (traced bundle: 3 elements, no report-value) [194, 2, 0, 0, << [17, 32, [ [ipn:1.0, ipn:2.0, 0, 841307664484, 841307664484, [1, 2000, 385000, 3, 12]], [ipn:2.0, ipn:3.0, 1, 841307665784, 841308265784, [1, 256, 250, -1, 47]], [ipn:3.0, ipn:3.0, 2, 841308265804, 0, [0, 0, 0, 0, 0]] ]] >> ], ; payload block [1, 1, 0, 0, 'This bundle is the host of traceroute extension block.'] ] ]]> Delivery report (207 bytes; 83 bytes without the report copy): > ], ; admin record payload block: bundle status report (delivered) [1, 1, 0, 0, << [1, [ [[false], [false], [true, 841308265804], [false]], 0, ipn:1.1, [841307664384, 0]]] >>] ] ]]> The delivery report carries the full trace (), so that the path is complete even when forwarding reports are not requested or not received.

On the Return Path The delivery report travels back through the orbiter. Its report copy contains a record with event-type 2 and no return records yet, fewer than record-limit (32), so the orbiter appends a return record when queuing the report bundle for ipn:1.0 (). The forwarding report above is not modified. Delivery report as queued by the orbiter for ipn:1.0 (250 bytes; only the TREB has changed): > ], ; admin record payload block: bundle status report (delivered) [1, 1, 0, 0, << [1, [ [[false], [false], [true, 841308265804], [false]], 0, ipn:1.1, [841307664384, 0]]] >>] ] ]]> The departure node places the forwarding report's record at position 1 (its report-value) and the delivery report's records at positions 0 to 2, up to the turnaround record, obtaining ipn:1.0 -> ipn:2.0 -> ipn:3.0. The delivery report's report-value 2 is the hop count; two records at these positions have event-type 0 or 1, so every hop was made by a participating node. The fourth record is a return record: the report returned via ipn:3.0 -> ipn:2.0 -> ipn:1.0, and because its next-node-id is the departure node, the return path is complete.

Path Reconstruction Example This example shows how report-value is set and how the departure node uses it. The path is A -> B -> C -> D. Forwarding, delivery, and deletion reports are requested. For brevity, a hop-record is written as its self-node-id and next-node-id only.

Growth of the TREB in the Traced Bundle The traced bundle carries no report-value; each participating node appends one record. B] Queued at B: [A->B, B->C] Queued at C: [A->B, B->C, C->D] Delivered at D: [A->B, B->C, C->D, D->D] ]]>

Report Copies Each forwarding report carries only the reporting node's record. Its report-value is the number of records the TREB held before that node appended its own, i.e., the position of that record. The delivery report carries the full trace; its report-value is the hop count (3: A, B, and C each forwarded the bundle once). The report returns via C and B, which append return records to it; the forwarding reports are not modified. C] C forwarding 2 (position) [C->D] D delivery 3 (hops) [A->B, B->C, C->D, D->D] D's report copy as received at A, after C and B: [A->B, B->C, C->D, D->D, C->B, B->A] ]]> Node A, the departure node, already holds its own record.

Reconstruction The departure node keeps a table of positions. It writes each forwarding report's record at report-value and the delivery report's records from position 0. The order in which reports arrive does not matter. Records after the turnaround record D->D are return records and are not placed at positions. Three records at positions have event-type 0 or 1 (A, B, C), equal to the hop count 3, so no hop was made by a transparent node. B From C: C->D From B: B->C From D: A->B B->C C->D D->D return: C->B, B->A Result: A->B B->C C->D D->D Return path: D -> C -> B -> A ]]>

Distinguishing Gaps Suppose the traced bundle is lost after C and no delivery report arrives. Case 1: B's forwarding report is lost (B participated). B -- C->D ]]> Position 1 is empty. Because C's record is at position 2, some node appended the record at position 1, but its report was not received (lost, or not generated). A->B indicates that this node was B. Case 2: B does not participate (transparent node). B, C->D] (C's record is at 1) C's forwarding report: report-value 1, [C->D] Position: 0 1 Result: A->B C->D ]]> A->B does not chain to C->D: B forwarded the bundle without participating. The departure node learns B's identity from A's next-node-id, but nothing else about B.

Overflow Now let record-limit be 2 on the same path A -> B -> C -> D. The TREB becomes full at B; C and D do not modify it. B] Queued at B: [A->B, B->C] (full) Queued at C: [A->B, B->C] (unchanged) Delivered at D: [A->B, B->C] (unchanged) Report from Type report-value hop-records ----------- ---------- ------------ ---------------------- B forwarding 1 (position) [B->C] C forwarding 2 (overflow) [C->D] D delivery 3 (hops) [A->B, B->C, D->D] D's report copy as received at A, after C and B: [A->B, B->C, D->D, C->B, B->A] ]]> Positions 0 and 1 hold A->B and B->C. C->D (report-value 2) and D->D (third record of D's report copy, position 2) are overflow records. Chaining from B->C gives C->D and then D->D: B B->C C->D D->D ]]> C's report-value equals record-limit, and the turnaround record of D's report copy is at position record-limit; either shows that overflow occurred. record-limit applies separately to the return path, so C and B still append their return records C->B and B->A to D's report copy.

Distance Encoding Widths

Distance (km)	link-info [1, d, 0, 10]	Bytes
400,000 (Moon)	84 01 1A 00 06 1A 80 00 0A	9
225,000,000 (Mars, mean)	84 01 1A 0D 69 3A 40 00 0A	9
4,500,000,000 (Neptune)	84 01 1B 00 00 00 01 0C 38 8D 00 00 0A	13

Distances up to 4,294,967,295 km use the same 5-byte CBOR unsigned integer encoding; only a link longer than that adds 4 bytes, and only to the hop-record describing that link.

Size Analysis

Block Size With small "ipn" node numbers, a hop-record is typically 40-43 bytes, of which 18 bytes are event-time and radiate-time (9 bytes each); a delivery or deletion record is about 28 bytes. A TREB with N hop-records occupies approximately 13 + 42N bytes including the canonical block header (Appendix A.1.3: 123 bytes for N = 3, including a delivery record). A report copy adds report-value (1 byte for positions up to 23).

Report Traffic Total status report bytes returned to the departure node for a path of N participating nodes. Each bundle status report bundle without a report copy is taken to be 83 bytes, the encoded size of the reports in (status time requested, DTN time available, CRC-16 on the primary block); it is 74 bytes without status time and 57 bytes for a source without a clock. About 27 of the 83 bytes are the three DTN time values (creation time, status time, and subject creation time), 9 bytes each. A report copy adds 14 bytes of overhead and 42 bytes per hop-record. On a symmetric path, the delivery report also collects N - 2 return records (), which are included in the last two columns. All columns use the record size of this document.

N	BSR forwarding reports only (no path detail)	-00 (accumulated trace in each forwarding report)	This document: forwarding + delivery	This document: delivery only
2	166	320	320	181
3	249	543	543	265
5	415	1,115	989	433
8	664	2,288	1,658	685
16	1,328	7,264	3,442	1,357
32	2,656	25,280	7,010	2,701
255	21,165	1,395,615	56,739	21,433

N = 255 is the largest hop limit of the Hop Count Block () and the largest record-limit (), so it bounds the path length for which reports are complete when the hop limit is enforced. Accumulating the trace in every forwarding report (as in -00) grows as O(N^2) (bounded by record-limit); single-record forwarding reports and return records grow as O(N). Delivery-only operation returns slightly more bytes than plain forwarding reports (at most 9% more, and less than 4% more for N of 8 or more), although its single report carries the whole path in both directions. Forwarding reports add about 56 bytes per hop compared with plain bundle status reports, in exchange for per-hop timing, link, and congestion information that bundle status reports do not carry.

Changes from -00 [RFC Editor: please remove this section before publication.]

• Intended status changed to Experimental; Implementation Status section added ().
• Added relationship to Previous Node, Bundle Age, and Hop Count blocks, compressed reporting, and IOAM. hop-limit renamed record-limit and defined as a record cap only; loop protection is left to the Hop Count Block. When the TREB is full, nodes forward it unchanged and report their records at the overflow position.
• Status reports: removed "SHALL generate"; added note on RFC 9171 report generation discretion; source-side flag requirements for carrier bundles; reinterpreted timeout.
• Report carriage defined: status reports carry a copy of the TREB (same block type and format). Only delivery and deletion report copies are extended on the return path, giving a round-trip trace; forwarding report copies are never modified, so report volume remains O(N) and they can be protected end to end with BPSec. record-limit applies separately to each direction.
• Added radiate-time (planned start of transmission) to hop-record and speed (kbps) to link-info; link-info elements renamed type, speed, distance, cl, and congestion.
• Term "transparent node" defined for nodes that forward the TREB without processing it.
• Path reconstruction extended to replicated bundles (a tree of records, one branch per delivery or deletion report).
• Added report-value, an optional last element present only in report copies. Forwarding reports carry only the reporter's own hop-record, with its position as report-value (O(N) instead of O(N^2)); delivery and deletion reports carry the full trace, with the Hop Count Block hop count as report-value, which also gives the number of hops made by transparent nodes. Gap interpretation and a path reconstruction example added ().
• Added Management Information Base (MIB) Considerations () with treb-completion-timeout, which bounds how long the departure node processes report copies.
• Appendix B report traffic recomputed from the encoded status report size of the lunar example (83 bytes) instead of an estimate; N = 255 related to the maximum hop limit.
• Added an informative Operation Overview with a path-level diagram of traced bundles and status reports, a departure-node state transition diagram, and a processing flow for intermediate and destination nodes ().
• The source node ID, destination, and report-to EID of a traced bundle must not be the null endpoint; the destination of a carrier bundle should have a registered application.
• Added a path reconstruction figure ().
• Appendix A replaced by a three-node lunar example showing the complete traced bundle at each node and the corresponding bundle status reports ().
• Hop-records appended once per node, when the bundle is queued for transmission to the selected next hop, and replaced on re-queuing; link-info describes the link toward next-node-id.
• Timing: dtn-timestamp renamed event-time and defined as the queuing time (or delivery/deletion time); radiate-time added for the planned start of transmission; separation of transmission and propagation delay declared out of scope; clock synchronization assumptions stated.
• BPSec: the TREB is handled like the Previous Node, Hop Count, and Bundle Age blocks (hop-by-hop protection only; other BPSec targets unaffected); hop-records are unauthenticated diagnostic data; report copies may carry BIB/BCB; removed "MAY protect with BPSec" from intermediate-node rules.
• Amplification section rewritten with an explicit bound.
• IANA: corrected block type range text; registries given RFC 8126 procedures and private and experimental ranges; congestion registry removed; CL type registry replaced by the SAND CL Types registry (cl is a 16-bit signed integer, 0 = unknown).
• congestion redefined as the queued volume toward the next hop relative to its next contact volume.
• Nits: congestion is a percentage 0..100, rounded up, with 0 meaning unknown; distance rounding defined; traceroute-id identifies a traceroute at its departure node (random first value, then incremented by 1, never 0, as for LTP report serial numbers); self-node-id is a Node ID; all flag bits specified; CDDL record-limit 1..255; examples and size analysis recomputed with block header; references added (RFC 8610, 8126, 7942, 9173, 9197, 9758, CCSDS 734.6, bp-sand).

Acknowledgments The author thanks the CCSDS SIS-DTN Working Group for input on DTN diagnostic requirements, and Nicholas Perry for a detailed review of -00.