Traceroute Extension Block for Bundle Protocol Version 7

Internet-Draft	BPv7 TREB	September 2026
Koo	Expires 1 April 2027	[Page]

Abstract

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

1. 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) [RFC9171] 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. Appendix B quantifies both modes.¶

1.1. 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", Section 4.2.1).¶
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 (Section 1.2).¶
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 (Section 4.8.3).¶
Round-trip: delivery and deletion report copies record the return path; forwarding report copies are never modified, so report volume remains linear (Section 4.4).¶
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 (Section 3.3).¶

1.2. Relationship to Other Mechanisms

The TREB is independent of the extension blocks defined in [RFC9171]; 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. [RFC9171] 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 (Section 4.4.3 of [RFC9171]). 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 (Section 4.8). 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 (Section 4.4). Delivery and deletion report copies carry the hop count (Section 3.3). 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:: [CCSDS734.6] 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 [RFC9197], adapted to store-and-forward operation and to BPv7 status reporting.¶

3. Extension Block Specification

3.1. Block Type Code

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

3.2. CDDL Definition

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

treb-data = [
  traceroute-id:  uint .ge 1,    ; unique per departure node
  record-limit:   1..255,        ; max hop-records per direction
  hop-records:    [* hop-record],
  ? report-value: record-position / hop-count ; report copies only
]

record-position = uint           ; forwarding report: position of
                                 ; the record; 0..record-limit
hop-count       = uint           ; delivery/deletion report: hop
                                 ; count of the Hop Count Block;
                                 ; 0 if absent

hop-record = [
  self-node-id:   eid,           ; Node ID of the recording node
  next-node-id:   eid,           ; Node ID of the selected next hop
  event-type:     0..255,        ; Section 8.2
  event-time:     dtn-time,      ; 0 = unknown/withheld
  radiate-time:   dtn-time,      ; planned; 0 = unknown/withheld
  link-info                      ; Link characteristics
]

link-info = [
  type:        0..255,           ; Section 8.3
  speed:       uint,             ; kbps, rounded up; 0 = unknown
  distance:    uint,             ; km, rounded up; 0 = unknown
  cl:          -32768..32767,    ; SAND CL Type; 0 = unknown
  congestion:  0..100            ; percent, rounded up; 0 = unknown
]

3.3. 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 (Section 3.2.2 of [RFC5326]). A departure node SHALL NOT reuse a traceroute-id while a traceroute using it is in progress (Section 5). traceroute-id is copied into every report copy, so that report copies and treb-data returned by the destination application (Section 4.2.1) can be matched to the traceroute without combining the source node ID and creation timestamp; the subject bundle identification in a bundle status report (Section 6.1.1 of [RFC9171]) 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 (Section 4.4). 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 (Section 4.3, Section 4.7). The departure node can determine from report-value in forwarding reports whether the limit was exceeded (overflow; Section 4.8). See Section 1.2 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 (Section 4.7). 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 (Section 4.8).¶
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 (Section 4.4).¶

See Appendix A.2 for a worked example.¶

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

Node IDs (Section 4.2.5.2 of [RFC9171]). With the "ipn" scheme these are administrative endpoints ([RFC9758]). 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 Section 8.2.¶

event-time:

DTN time (Section 4.2.6 of [RFC9171]), 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 (Section 6.1.1 of [RFC9171]). Comparing times of different nodes assumes synchronized clocks, which [RFC9171] 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 Section 8.3). 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 [I-D.ietf-dtn-bp-sand], 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.¶

3.4. Block Processing Control Flags

The block processing control flags (Section 4.2.4 of [RFC9171]) 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 (Section 4.7) 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.¶

4. Processing Rules

4.1. Operation Overview

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

hr = hop-record;  RC = report copy;  rv = report-value
hr3 = return record created by B (Section 4.4)

     delivery BSR, rv = 2 (RC extended on its return path)
    <== RC [hr0, hr1, hr2, hr3] ==+<== RC [hr0, hr1, hr2] =====+
                                  |                            |
    <= fwd BSR: RC [hr1], rv = 1 =+                            |
                                  |                            |
              TREB [hr0]          |      TREB [hr0, hr1]       |
+-------+                     +-------+                    +-------+
|   A   |-------------------->|   B   |------------------->|   C   |
+-------+                     +-------+                    +-------+
   hr0                        hr1, hr3                       hr2
departure                  intermediate                  destination

Figure 1: Traced Bundle and Status Reports on a Three-Node Path

Legend: RC = report copy;  Tmr = treb-completion-timeout timer

                     +----------+
                     |   IDLE   |
                     +----+-----+
                          |  Start traceroute:
                          |   traceroute-id := previous + 1;
                          |   create TREB, append departure record;
                          |   queue carrier bundle; start Tmr
                          V
                     +----------+  Rcv forwarding RC:
                     |          |  place record at report-value
                     | WAIT_RPT |------------------------------+
                     |          |<-----------------------------+
                     +--+----+--+
                        |    |
 Rcv delivery or        |    |  Tmr expires
 deletion RC:        +--+    +------+
 place records from  |              |
 position 0;         |              |
 stop Tmr            |              |
                     V              V
               +----------+   +-----------+
               | COMPLETE |   | TIMED_OUT |
               +-----+----+   +-----+-----+
                     |              |
                     +------+-------+
                            |  Evaluate trace (Section 4.8):
                            |   gaps, overflow,
                            |   transparent nodes
                            V
                       +----------+  Rcv RC with this
                       |  CLOSED  |  traceroute-id: ignore
                       +----------+

Figure 2: Departure Node State Transitions

Legend: RC = report copy;  rv = report-value

 Bundle with TREB received
   |
   +-- ADU is an administrative record? --yes--> 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.

Figure 3: Processing at Intermediate and Destination Nodes

4.2. 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 (Section 3.3), 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 Section 4.3. 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 (Section 4.2.3 of [RFC9171] and Section 4.2.5.1.1 of [RFC9171]).¶

4.2.1. 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 (Section 4.2.3 of [RFC9171]). Setting the flags requests reports; it does not oblige any node to generate them (Section 4.7).¶
The destination SHOULD be an endpoint at which an application is registered, since delivery requires a registration (Section 5.7 of [RFC9171]).¶
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 (Section 4.8.3).¶
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 Appendix A.1). 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 (Section 4.5). This provides delivery results even where status reporting is disabled, but does not report deletions or intermediate progress.¶

4.3. 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 (Section 4.4). 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 (Section 4.7).¶

4.4. 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 Section 4.3.¶

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 (Section 4.3.1 of [RFC9171]), 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 Section 4.3; 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 (Section 7.3).¶

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

4.5. 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 Section 4.3. 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 (Section 4.2.1). The interface for doing so is implementation-specific.¶

4.6. 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 (Section 4.7). The reason for deletion is conveyed by the status report's reason code.¶

4.7. 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 (Section 4.6); 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 (Section 4.4), 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 Section 7.3.¶

4.8. 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 (Section 3.3). 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. Appendix A.2 gives worked examples.¶

Figure 4 summarizes this procedure; it is informative, and the text above takes precedence.¶

Legend: RC = report copy;  rv = report-value;  L = record-limit
        slot[0..L-1] = positions;  OVF = set of overflow records
        RET = return records (after the turnaround record)
        Hr = hop count reported in a delivery/deletion RC
             (local variable; no block is modified)

 Rcv RC (same traceroute-id; subject bundle matches)
   |
   +-- Forwarding report? ---yes--+
   |                              |
   | no (delivery or deletion)    V
   |                         rv < L ? --yes--> 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

Figure 4: Path Reconstruction at the Departure Node

Replicated bundles: If a node forwards copies of a traced bundle to several next hops, each copy carries its own record (Section 4.3), 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 (Section 4.8.1) occurs at the first delivery report; a departure node expecting several deliveries can instead complete at treb-completion-timeout (Section 5).¶

4.8.1. 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.¶

4.8.2. 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 (Section 5). Forwarding reports received so far, if any, bound the progress of the bundle, but because report generation is discretionary (Section 4.7), silence after a given node indicates neither loss nor deletion by itself.¶

4.8.3. 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 Section 3.4, 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 [RFC9171]. 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.¶

4.9. Fragmentation

With bit 0 of the block processing control flags set to 0 (Section 3.4), Section 5.8 of [RFC9171] 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.¶

4.10. 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:¶

link-info = [0, 0, 0, 0, 0]  ; All fields withheld

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 (Section 4.4).¶

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

Table 2
Value	Description	Reference
TBD1	Traceroute Extension Block	This document

Table 3
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

Table 4
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

Appendix A. CBOR Encoding Examples

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

A.1. 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.¶

Earth Ground Station (ipn:1.0)       departure
   |  RF, 2,000 kbps, 385,000 km, cl 3 (LTP), congestion 12%
   v
Lunar Orbiter (ipn:2.0)              intermediate
   |  RF, 256 kbps, 250 km, cl -1, congestion 47%
   v
Lunar Lander (ipn:3.0)               destination

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

A.1.1. At the Departure Node

Bundle as queued for ipn:2.0 (169 bytes):¶

[_
 ; primary block (identical at every hop): to ipn:3.1 from ipn:1.1
 [7, 458820, 1, ipn:3.1, ipn:1.1, ipn:1.0, [841307664384, 0],
  86400000, h'F419'],
 ; Hop Count Block: limit 16, count 0
 [10, 3, 0, 0, << [16, 0] >>],
 ; 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.']
]

A.1.2. At the Intermediate Node

Bundle as queued for ipn:3.0 (209 bytes). Only the Hop Count Block and the TREB have changed:¶

[_
 ; primary block (identical at every hop): to ipn:3.1 from ipn:1.1
 [7, 458820, 1, ipn:3.1, ipn:1.1, ipn:1.0, [841307664384, 0],
  86400000, h'F419'],
 ; Hop Count Block: limit 16, count 1
 [10, 3, 0, 0, << [16, 1] >>],
 ; 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:¶

[_
 ; primary block: admin record flag; (BSR) to ipn:1.0 from ipn:2.0
 [7, 2, 1, ipn:1.0, ipn:2.0, dtn:none, [841308265784, 0],
  86400000, h'6B60'],
 ; TREB (report copy: 4 elements, report-value 1)
 [194, 2, 0, 0, << [17, 32, [
     [ipn:2.0, ipn:3.0, 1, 841307665784, 841308265784,
      [1, 256, 250, -1, 47]]
   ], 1] >> ],
 ; admin record payload block: bundle status report (forwarded)
 [1, 1, 0, 0, << [1, [
     [[false], [true, 841308265784], [false], [false]],
     0, ipn:1.1, [841307664384, 0]]] >>]
]

A.1.3. At the Destination Node

Bundle as delivered (237 bytes):¶

[_
 ; primary block (identical at every hop): to ipn:3.1 from ipn:1.1
 [7, 458820, 1, ipn:3.1, ipn:1.1, ipn:1.0, [841307664384, 0],
  86400000, h'F419'],
 ; Hop Count Block: limit 16, count 2
 [10, 3, 0, 0, << [16, 2] >>],
 ; 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):¶

[_
 ; primary block: admin record flag; (BSR) to ipn:1.0 from ipn:3.0
 [7, 2, 1, ipn:1.0, ipn:3.0, dtn:none, [841308265804, 0],
  86400000, h'AF24'],
 ; TREB (report copy: 4 elements, report-value 2)
 [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]]
   ], 2] >> ],
 ; 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 (Section 4.7), so that the path is complete even when forwarding reports are not requested or not received.¶

A.1.4. 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 (Section 4.4). 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):¶

[_
 ; primary block (unchanged): (BSR) to ipn:1.0 from ipn:3.0
 [7, 2, 1, ipn:1.0, ipn:3.0, dtn:none, [841308265804, 0],
  86400000, h'AF24'],
 ; TREB (report copy with one return record, report-value 2)
 [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]],
     [ipn:2.0, ipn:1.0, 1, 841308265844, 841308265844,
      [1, 10000, 385000, 3, 46]]
   ], 2] >> ],
 ; 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.¶

A.2. 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.¶

A.2.1. Growth of the TREB in the Traced Bundle

The traced bundle carries no report-value; each participating node appends one record.¶

Queued at A:     [A->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]

A.2.2. 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.¶

Report from   Type         report-value   hop-records
-----------   ----------   ------------   ----------------------
B             forwarding   1 (position)   [B->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.¶

A.2.3. 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.¶

Position:     0      1      2      3
From A:      A->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

A.2.4. 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).¶

Position:     0      1      2
Result:      A->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).¶

Traced bundle after C:  [A->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.¶

A.2.5. 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.¶

Queued at A:     [A->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:¶

Position:     0      1      overflow (by chaining)
Result:      A->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.¶

A.3. Distance Encoding Widths

Table 5
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.¶

Table 6
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

Appendix C. Changes from -00

[RFC Editor: please remove this section before publication.]¶

Intended status changed to Experimental; Implementation Status section added (Section 6).¶
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 (Appendix A.2).¶
Added Management Information Base (MIB) Considerations (Section 5) 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 (Section 4.1).¶
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 (Figure 4).¶
Appendix A replaced by a three-node lunar example showing the complete traced bundle at each node and the corresponding bundle status reports (Appendix A.1).¶
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).¶