Summary

  • TREB revision 01 lets participating BPv7 nodes append the next hop they selected, local timing and link characteristics, then return those records in bundle status reports.
  • A record is written when a node queues a bundle, not when transmission or reception is proven; nodes may decline, withhold fields, replace an earlier record or omit a report.
  • Mutable outward and return traces can be protected only hop by hop, so the draft treats hop-records as diagnostic data and expressly forbids using them for routing or access control.

A route made from statements

Ordinary traceroute depends on packets expiring at successively greater IP hop limits. That is not the geometry here. Delay-tolerant networks may hold a bundle for a scheduled contact, forward it across an intermittent link, and wait hours or days before a report returns. draft-koo-dtn-traceroute-eb-01 therefore proposes a Traceroute Extension Block, or TREB, that travels with a BPv7 bundle.

The departure node creates a tracing identifier and appends the first record. Each participating intermediate node adds its own Node ID, the next node it selected, the moment it queued the bundle, the planned start of transmission and a compact description of the link. At delivery or deletion, the last node adds a turnaround record. A delivery or deletion status-report bundle can then carry the accumulated outward records and append a second sequence as the report travels back.

That construction could answer questions that a conventional Bundle Status Report does not. It can show which participating node intended to use an RF, optical, terrestrial or inter-satellite link; what nominal rate and distance it believed applied; and whether its queued volume approached the capacity of the next contact. One returned report can expose both an outward chain and a separately observed return chain.

Revision 01 is still an individual Internet-Draft, posted on 28 September 2026 with an Experimental ambition and an expiry date of 1 April 2027. It requests an IANA block type; the registry has not thereby granted one. The implementation section lists no implementation and promises measurements only in a future revision. The design deserves analysis, not promotion into deployment fact.

The timestamp precedes the event operators want to prove

A forwarding hop-record is created after the node selects a next hop and queues the bundle. It does not say that the radio transmitted, the optical contact opened, the next node received the bytes or the destination application processed them. If the bundle is removed from the queue after a failed attempt or a changed next hop, the node replaces its previous record. The trace retained in the transmitted copy is a latest local account, not an immutable log of every attempt.

The two times require equal care. event-time is local queueing time. radiate-time is a planned transmission start and is never revised to the actual departure. Comparing clocks between nodes assumes synchronization that BPv7 does not require. The interval to the next record also mixes transmission and propagation delay, which this draft leaves unresolved.

Zero is not a measurement of zero. For time, speed, distance, convergence-layer code and congestion, it can mean unknown, inapplicable or deliberately withheld. A rounded congestion value of 100 says queued volume is expected to meet or exceed one contact's remaining volume under the reporting node's model; it does not establish a universal network congestion state.

Silence has several authors

Participation is voluntary. A node may forward the block unchanged because it distrusts the source, protects topology, lacks resources or simply follows local policy. It then becomes transparent to the TREB. A non-chaining pair of records reveals at least one such gap; it does not identify every hidden node.

The Hop Count Block can narrow that uncertainty. When every node updates it correctly, the returned hop count minus recorded forwarding events gives the number of transparent hops. But record-limit is only a cap on TREB growth, not loop protection. Once the block is full, later nodes keep forwarding and may report overflow separately. A neat list can therefore be incomplete because of policy, capacity or the chosen limit.

Reports add another ambiguity. BPv7 request flags request delivery, deletion or forwarding reports; they do not compel a Bundle Protocol Agent to generate one. A missing forwarding report might have been lost, withheld or never created. After a local completion timeout, the source freezes the view it has and ignores late reports even though bundles may remain in flight. “No further evidence arrived before my deadline” is the correct proposition. “The bundle died at the last visible node” is not.

The return path is a second experiment

Delivery and deletion report copies grow on their way back. Records before the delivery or deletion event describe the traced bundle's outward path. Records after that turnaround describe the report bundle's return path. They need not be symmetric, and transparent nodes or a full record limit can leave the return chain partial.

Forwarding reports work differently. Each carries only its reporter's own record and a position value, and it is not modified on return. The source assembles these pieces by tracing identifier, subject bundle identity, position and next-node chaining. Replication can create several records at the same position and a tree rather than one route.

The visual result may look authoritative because it is ordered. Its provenance is nevertheless plural: every participating node authored its own fields, each under local disclosure policy, and the source performed the final reconstruction. Ordering is not neutrality.

Integrity stops at the mutating hop

TREB reveals identities, topology, timing, link capacity and congestion. Yet the outward block and a delivery or deletion report copy change at every participating node. End-to-end integrity or confidentiality for those changing bytes is impossible under the proposed model. A BIB or BCB can protect the mutable block only hop by hop, with one forwarding node acting as security source and its next node as acceptor. An on-path participant can still forge the values it contributes.

An immutable forwarding-report copy can receive protection from its reporting node. That is stronger provenance for one statement, not a neutral attestation of the whole path. The draft consequently says hop-records are unauthenticated end to end, diagnostic only, and must not become input to routing or access-control decisions.

There is also a return-traffic incentive. BPv7 does not authenticate the report-to endpoint in the relevant sense, so a spoofed probe could direct enlarged reports at a third party. The record limit, report-copy size bound, rate limiting and permission to omit a copy reduce amplification. They do not make the source identity self-proving.