Traceroute Extension Block for Bundle Protocol Version 7
draft-koo-dtn-traceroute-eb-02
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | CHEOL HEA KOO | ||
| Last updated | 2026-10-06 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-koo-dtn-traceroute-eb-02
Delay-Tolerant Networking Cheol H. Koo
Internet-Draft Korea Aerospace Research Institute
Intended status: Experimental 6 October 2026
Expires: 9 April 2027
Traceroute Extension Block for Bundle Protocol Version 7
draft-koo-dtn-traceroute-eb-02
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 node it
received the bundle from, 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. Each forwarding
report returns one hop-record, and the delivery 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.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 9 April 2027.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
Koo Expires 9 April 2027 [Page 1]
Internet-Draft BPv7 TREB October 2026
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Scope and Design Goals . . . . . . . . . . . . . . . . . 4
1.2. Relationship to Other Mechanisms . . . . . . . . . . . . 5
2. Conventions and Definitions . . . . . . . . . . . . . . . . . 6
3. Extension Block Specification . . . . . . . . . . . . . . . . 7
3.1. Block Type Code . . . . . . . . . . . . . . . . . . . . . 7
3.2. CDDL Definition . . . . . . . . . . . . . . . . . . . . . 7
3.3. Field Semantics . . . . . . . . . . . . . . . . . . . . . 8
3.4. Block Processing Control Flags . . . . . . . . . . . . . 12
4. Processing Rules . . . . . . . . . . . . . . . . . . . . . . 12
4.1. Operation Overview . . . . . . . . . . . . . . . . . . . 12
4.2. At the Departure Node . . . . . . . . . . . . . . . . . . 16
4.2.1. Traceroute Carrier Bundle . . . . . . . . . . . . . . 16
4.3. Appending a Hop-Record . . . . . . . . . . . . . . . . . 17
4.4. At Intermediate Nodes . . . . . . . . . . . . . . . . . . 18
4.5. At the Destination Node . . . . . . . . . . . . . . . . . 18
4.6. On Bundle Deletion . . . . . . . . . . . . . . . . . . . 19
4.7. Status Reports . . . . . . . . . . . . . . . . . . . . . 19
4.8. Path Reconstruction and Completion . . . . . . . . . . . 20
4.8.1. Successful Completion . . . . . . . . . . . . . . . . 23
4.8.2. Unsuccessful Completion . . . . . . . . . . . . . . . 23
4.8.3. Interpreting Gaps . . . . . . . . . . . . . . . . . . 23
4.9. Fragmentation . . . . . . . . . . . . . . . . . . . . . . 24
4.10. Bundle-in-Bundle Encapsulation . . . . . . . . . . . . . 25
4.11. Privacy and Policy Considerations . . . . . . . . . . . . 25
5. Management Information Base (MIB) Considerations . . . . . . 25
6. Implementation Status . . . . . . . . . . . . . . . . . . . . 26
7. Security Considerations . . . . . . . . . . . . . . . . . . . 27
7.1. Information Disclosure . . . . . . . . . . . . . . . . . 27
7.2. Integrity and BPSec . . . . . . . . . . . . . . . . . . . 27
7.3. Report Amplification . . . . . . . . . . . . . . . . . . 28
7.4. Resource Exhaustion . . . . . . . . . . . . . . . . . . . 28
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
8.1. Bundle Block Type . . . . . . . . . . . . . . . . . . . . 28
8.2. TREB Event Type Codes . . . . . . . . . . . . . . . . . . 29
8.3. TREB Link Type Codes . . . . . . . . . . . . . . . . . . 29
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 30
Koo Expires 9 April 2027 [Page 2]
Internet-Draft BPv7 TREB October 2026
9.1. Normative References . . . . . . . . . . . . . . . . . . 30
9.2. Informative References . . . . . . . . . . . . . . . . . 31
Appendix A. CBOR Encoding Examples . . . . . . . . . . . . . . . 32
A.1. Lunar Scenario: Traced Bundle and Status Reports . . . . 32
A.1.1. At the Departure Node . . . . . . . . . . . . . . . . 32
A.1.2. At the Intermediate Node . . . . . . . . . . . . . . 33
A.1.3. At the Destination Node . . . . . . . . . . . . . . . 34
A.1.4. On the Return Path . . . . . . . . . . . . . . . . . 35
A.2. Path Reconstruction Example . . . . . . . . . . . . . . . 36
A.2.1. Growth of the TREB in the Traced Bundle . . . . . . . 36
A.2.2. Report Copies . . . . . . . . . . . . . . . . . . . . 37
A.2.3. Reconstruction . . . . . . . . . . . . . . . . . . . 37
A.2.4. Distinguishing Gaps . . . . . . . . . . . . . . . . . 38
A.2.5. Overflow . . . . . . . . . . . . . . . . . . . . . . 38
A.3. Distance Encoding Widths . . . . . . . . . . . . . . . . 39
Appendix B. Size Analysis . . . . . . . . . . . . . . . . . . . 39
B.1. Block Size . . . . . . . . . . . . . . . . . . . . . . . 39
B.2. Report Traffic . . . . . . . . . . . . . . . . . . . . . 40
Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 41
C.1. Changes from -01 . . . . . . . . . . . . . . . . . . . . 41
C.2. Changes from -00 . . . . . . . . . . . . . . . . . . . . 42
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 45
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 45
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
Koo Expires 9 April 2027 [Page 3]
Internet-Draft BPv7 TREB October 2026
identifies only the reporting node, and the reports carry no link
detail. The mechanism defined here records the path in the bundle
itself. The delivery report (or a deletion report) returns the full
recorded path and records its own return path, giving a round-trip
trace; each forwarding report carries only the reporting node's own
hop-record, so total report volume grows linearly with path length.
Appendix B quantifies the report volume.
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).
* Bundle protocol agent first: the values in a hop-record are
primarily those available to the bundle protocol agent, for
example from its contact plan. Whether and how further
information, such as that held by convergence layer adapters, is
used is implementation-specific. The precision of the recorded
times and link characteristics is limited accordingly.
* 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).
Koo Expires 9 April 2027 [Page 4]
Internet-Draft BPv7 TREB October 2026
1.2. Relationship to Other Mechanisms
The TREB is independent of the extension blocks defined in [RFC9171];
it neither requires nor replaces them. Those blocks travel with the
bundle toward its destination, whereas the TREB returns per-hop
information to the departure node. 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; each
record also keeps the node from which the bundle was received
(prev-node-id), which may be taken from this block.
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.
Custody transfer: Custody transfer is not part of [RFC9171]; it is
provided by separate mechanisms such as [CCSDS734.6]. When such a
mechanism retransmits a traced bundle, this specification treats
the retransmission as a re-queuing: the custodian replaces its
hop-record (Section 4.3) and may generate another forwarding
report, and nodes that receive the bundle again may report again.
The departure node handles the resulting records as specified in
Section 4.8: a repeated record is a duplicate, which it may ignore
or retain for diagnosis, and a record with a different next hop is
a branch. The additional reports are limited to the number of
retransmissions, and each is bounded in size (Section 7.3), so
custody transfer does not lead to excessive reporting. Where
Koo Expires 9 April 2027 [Page 5]
Internet-Draft BPv7 TREB October 2026
custody transfer is in use, a deletion report may be followed by a
delivery report after a retransmission; a departure node MAY then
keep the traceroute open until treb-completion-timeout
(Section 5). The TREB does not record custody status or the
number of retransmissions.
Compressed status reporting: [CCSDS734.6] defines compressed
reporting, 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.
2. 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 [RFC2119] [RFC8174] 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 [RFC9171]. CDDL [RFC8610] is
used to describe CBOR [RFC8949] structures; the rules "eid" and "dtn-
time" are those of Appendix B of [RFC9171].
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 (Section 4.7).
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.
Koo Expires 9 April 2027 [Page 6]
Internet-Draft BPv7 TREB October 2026
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 (Section 4.4).
Return record: A hop-record that follows the turnaround record in a
delivery or deletion report copy: the reporting node's record for
queuing the report bundle (event-type 0, Section 4.7) and the
records appended by nodes on its way to the report-to endpoint
(event-type 1, Section 4.4).
Traceroute carrier bundle: A bundle created specifically to carry a
TREB (Section 4.2.1).
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:
Koo Expires 9 April 2027 [Page 7]
Internet-Draft BPv7 TREB October 2026
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
prev-node-id: eid, ; node the bundle was received from;
; dtn:none = unknown or none
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
Koo Expires 9 April 2027 [Page 8]
Internet-Draft BPv7 TREB October 2026
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 that has lost its
traceroute state, for example after a restart, chooses its next
traceroute-id in the same way as the first. 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.
Koo Expires 9 April 2027 [Page 9]
Internet-Draft BPv7 TREB October 2026
self-node-id, prev-node-id, next-node-id: Node IDs (Section 4.2.5.2
of [RFC9171]). With the "ipn" scheme these are administrative
endpoints ([RFC9758]). prev-node-id is the node from which the
recording node received the bundle. It is taken from the Previous
Node Block (Section 4.4.1 of [RFC9171]) if the received bundle has
one. Otherwise it MAY be determined by implementation-specific
means, for example from a scheduled contact plan; if it cannot be
determined reliably, it is the null endpoint (dtn:none). In the
departure node's record, prev-node-id is the null endpoint
(dtn:none), because the departure node is the source of the
bundle. For the same reason, it is dtn:none in the return record
that the node generating a delivery or deletion report appends
when it queues the report bundle (event-type 0, Section 4.7),
since that node is the source of the report bundle; the node from
which it received the traced bundle is given in its delivery or
deletion record. It is also dtn:none if withheld (Section 4.11).
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 (or the
reporting node queues a delivery or deletion report bundle,
Section 4.7); 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. A hop-record whose event-type is not
recognized SHALL NOT be treated as an error; in path
reconstruction (Section 4.8) it is handled like a forwarding
record and is not a turnaround record.
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 the reporting node asserted that it forwarded the bundle 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
Koo Expires 9 April 2027 [Page 10]
Internet-Draft BPv7 TREB October 2026
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. A type value that is not recognized SHALL NOT be
treated as an error; its interpretation is implementation-
specific.
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-
Koo Expires 9 April 2027 [Page 11]
Internet-Draft BPv7 TREB October 2026
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 a node that does not support this specification
generates a bundle reception status report with reason code "Block
unsupported" (Section 5.6 of [RFC9171]), identifying itself. 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.
Koo Expires 9 April 2027 [Page 12]
Internet-Draft BPv7 TREB October 2026
hr = hop-record; RC = report copy; rv = report-value
hr3 = return record by C (event-type 0), hr4 by B (Sections 4.4, 4.7)
delivery BSR, rv = 2 (RC extended on its return path)
<== RC [hr0 ... hr4] =========+<== RC [hr0 ... hr3] =======+
| |
<= fwd BSR: RC [hr1], rv = 1 =+ |
| |
TREB [hr0] | TREB [hr0, hr1] |
+-------+ +-------+ +-------+
| A |-------------------->| B |------------------->| C |
+-------+ +-------+ +-------+
hr0 hr1, hr4 hr2, hr3
departure intermediate destination
Figure 1: Traced Bundle and Status Reports on a Three-Node Path
Koo Expires 9 April 2027 [Page 13]
Internet-Draft BPv7 TREB October 2026
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
Koo Expires 9 April 2027 [Page 14]
Internet-Draft BPv7 TREB October 2026
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 | on queuing the
V | report, append own
Append record | return record
| | (event-type 0)
+<------------------------+
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; on queuing the report, append own return
record (event-type 0).
Koo Expires 9 April 2027 [Page 15]
Internet-Draft BPv7 TREB October 2026
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 forwarding" flag (bit 16), the
"request reporting of bundle delivery" flag (bit 17), and the
"request reporting of bundle deletion" flag (bit 18) of the bundle
processing control flags SHALL be set (Section 4.2.3 of
[RFC9171]). Forwarding reports return each node's hop-record with
its position and show how far the bundle progressed if it is lost;
the delivery report returns the full path; a deletion report
identifies the node that deleted the bundle and the reason.
Setting the flags requests reports; it does not oblige any node to
generate them (Section 4.7).
* The "status time requested in reports" flag (bit 6) SHOULD be set,
so that each report gives the time at which the reported status
was asserted (Section 6.1.1 of [RFC9171]); together with radiate-
time, this indicates whether transmission took place as planned.
* 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.
Koo Expires 9 April 2027 [Page 16]
Internet-Draft BPv7 TREB October 2026
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, whether a traced bundle or a report 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 of the bundle 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).
Koo Expires 9 April 2027 [Page 17]
Internet-Draft BPv7 TREB October 2026
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, after
the reporting node's own return record (Section 4.7); 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.
Koo Expires 9 April 2027 [Page 18]
Internet-Draft BPv7 TREB October 2026
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
| Note: Generation of status reports is governed by [RFC9171]. A
| status report is generated only if the corresponding request
| flag is set in the bundle's primary block and status reporting
| is enabled at the node (Section 5.4 of [RFC9171] and
| Section 5.10 of [RFC9171]); even then, the decision is left to
| the discretion of the BPA (Section 5.1 of [RFC9171]).
| Consequently, an intermediate or destination node may decline
| to generate a status report for a traced bundle, and this
| specification does not override that discretion. The absence
| of a status report from a given node therefore does not by
| itself indicate bundle loss or deletion at that node
| (Section 4.8.3).
Nodes supporting this specification SHOULD enable status reporting
for traced bundles, subject to local policy. This does not change
the default of Section 5.1 of [RFC9171]: enabling remains an operator
decision, and the bounded size of report copies (Section 7.3) is
intended to make the risk of excessive traffic acceptable for traced
bundles.
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
Koo Expires 9 April 2027 [Page 19]
Internet-Draft BPv7 TREB October 2026
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 node that generates a delivery or deletion report copy SHALL, when
it queues the report bundle for transmission to its next hop, create
a hop-record with event-type 0 describing that queuing, as a
departure node does for a traced bundle, and append it to the report
copy as specified in Section 4.3. This record is the first return
record; it describes the first hop of the return path, which would
otherwise not be recorded. No such record is created if the report
is delivered locally.
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. Consecutive
records are linked by next-node-id and the following record's self-
node-id, and by prev-node-id and the preceding record's self-node-id.
None of this requires synchronized clocks.
Traceroutes are independent of one another. A node may be the
departure node of several traceroutes at the same time, and may
forward a traced bundle of another departure node while its own
traceroutes are in progress. Every report copy carries the
traceroute-id and is checked against the subject bundle
identification, so report copies of different traceroutes are never
confused. This also holds when a traced bundle is carried inside
another traced bundle (Section 4.10): the two TREBs belong to
Koo Expires 9 April 2027 [Page 20]
Internet-Draft BPv7 TREB October 2026
different bundles and are processed and reported separately. A
report copy that matches no traceroute in progress, for example one
received after the departure node has restarted, SHALL be ignored.
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.
Koo Expires 9 April 2027 [Page 21]
Internet-Draft BPv7 TREB October 2026
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, the
last slot[k+1].prev-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
Koo Expires 9 April 2027 [Page 22]
Internet-Draft BPv7 TREB October 2026
More than one record for a position: The departure node can receive
more than one record for the same position.
* A record from the same node with the same next-node-id as a record
already held is a duplicate, for example after a custody
retransmission to the same next hop (Section 1.2). The departure
node MAY ignore it or MAY retain it for more detailed diagnosis,
for example of retransmission times; this is implementation-
specific and does not change the reconstructed path.
* Any other record shows that copies of the bundle took different
paths, after replication or after a retransmission toward a
different next hop. The departure node keeps all such records and
reconstructs a tree by chaining. Each reported forwarding is a
branch, whether or not an earlier copy reached its next hop; a
branch without further records shows a forwarding whose outcome is
unknown. Each delivery or deletion report contains one branch.
Completion occurs at the first delivery or deletion report
(Section 5); a departure node that expects reports from several
branches MAY instead keep the traceroute open until treb-completion-
timeout.
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
Koo Expires 9 April 2027 [Page 23]
Internet-Draft BPv7 TREB October 2026
forwarding report was not received (lost, or not generated). The
node is named by the next-node-id of the record before the gap and
by the prev-node-id of the record after it.
Adjacent positions whose records do not chain: record k's next-node-
id differs from record k+1's self-node-id, or record k+1's prev-
node-id differs from record k's self-node-id. A prev-node-id of
dtn:none is not compared. At least one transparent node lies
between them (or, if bit 1 was set per Section 3.4, may have
reported "Block unsupported").
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 (record k's next-node-id) and, where prev-node-id
is known, its last node (record k+1's prev-node-id), 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.
Only the fragment that carries the TREB is a traced bundle; the trace
describes the path of that fragment, and other fragments may take
other paths. A status report for a fragment without a TREB contains
no report copy and is not used in path reconstruction (Section 4.8).
Delivery takes place after reassembly, in the bundle that holds the
fragment with offset zero and therefore the TREB (Section 5.9 of
[RFC9171]). If reassembly does not complete, no delivery report is
generated, and the traceroute ends by deletion or timeout
(Section 4.8.2).
Koo Expires 9 April 2027 [Page 24]
Internet-Draft BPv7 TREB October 2026
4.10. Bundle-in-Bundle Encapsulation
The purpose of the TREB is to show whether a bundle reached its
destination and, if not, where along the path it stopped. Bundle-in-
Bundle Encapsulation (BIBE) [I-D.ietf-dtn-bibe] acts as a convergence
layer that tunnels a bundle between an encapsulator and a
decapsulator as the payload of an encapsulating bundle. Nodes inside
the tunnel process only the encapsulating bundle, so the TREB of the
encapsulated bundle is processed only at the encapsulator and the
decapsulator, and the tunnel appears in the trace as a single hop:
the encapsulator's hop-record names the decapsulator as next-node-id,
with link-info describing the tunnel as a whole. As on any single
hop, the hop count of the encapsulated bundle advances once across
the tunnel, so the chaining and hop count tests (Section 4.8.3)
remain consistent, and nodes inside the tunnel are not counted as
transparent nodes.
If the encapsulated bundle does not emerge from the tunnel, the
departure node learns from the encapsulator's forwarding report that
the bundle entered the tunnel toward the decapsulator. Diagnosing
the tunnel is the responsibility of the encapsulator and is out of
scope of this document. If the encapsulator eventually deletes the
encapsulated bundle, its deletion report reaches the departure node
as usual (Section 4.6). No change to BIBE is required.
4.11. Privacy and Policy Considerations
A participating node MAY withhold prev-node-id by using the null
endpoint, and 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).
5. 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.
Koo Expires 9 April 2027 [Page 25]
Internet-Draft BPv7 TREB October 2026
+=========================+========================+==============+
| Parameter | Description | Units |
+=========================+========================+==============+
| treb-completion-timeout | Maximum time, measured | milliseconds |
| | by the departure node | |
| | from when it queues | |
| | the traced bundle | |
| | (Section 4.2), during | |
| | which it processes | |
| | report copies for that | |
| | bundle. | |
+-------------------------+------------------------+--------------+
Table 1
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 (Section 4.8) 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 (Section 4.8),
unless the departure node keeps it open until the timeout as
permitted for custody transfer (Section 1.2) and for bundles that
took several paths (Section 4.8); report copies for that traceroute
received after completion are ignored. See Figure 2.
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.
6. 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 [RFC7942].
The description of implementations in this section is intended to
Koo Expires 9 April 2027 [Page 26]
Internet-Draft BPv7 TREB October 2026
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 [RFC7942], "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.
7. Security Considerations
7.1. 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 (Section 4.11). Confidentiality can be provided by a Block
Confidentiality Block (BCB) [RFC9172]: 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 (Section 7.2).
7.2. Integrity and BPSec
Like the Previous Node, Hop Count, and Bundle Age blocks [RFC9171],
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. A Block Integrity Block
(BIB) or BCB targeting the TREB can protect it only until it is next
modified: the security operation has to be accepted, according to
security policy, at or before the next participating node [RFC9172].
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.
Koo Expires 9 April 2027 [Page 27]
Internet-Draft BPv7 TREB October 2026
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 (Section 4.4); the reporting node MAY add a BIB or BCB
targeting it, for example using the security contexts of [RFC9173].
prev-node-id allows the next hop claimed by one node to be compared
with the previous node observed by the following node. A mismatch
that is not explained by transparent nodes indicates an error or
tampering, but it does not show which of the two nodes is
responsible, and prev-node-id is itself unauthenticated. Conversely,
a consistent chain does not prove that the recorded nodes forwarded
the bundle: an on-path node can forge records that are consistent
with one another.
7.3. Report Amplification
The TREB does not by itself cause additional bundles to be generated;
reports are generated only as requested and permitted under
[RFC9171]. 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
(Section 4.7).
7.4. Resource Exhaustion
TREB growth is bounded by record-limit. Implementations SHOULD rate-
limit TREB processing and MAY decline to process TREBs under resource
pressure.
8. IANA Considerations
8.1. Bundle Block Type
IANA is requested to register the following in the "Bundle Block
Types" registry, from the range currently unassigned below 192:
Koo Expires 9 April 2027 [Page 28]
Internet-Draft BPv7 TREB October 2026
+=========================+=======+=================+===========+
| Bundle Protocol Version | Value | Description | Reference |
+=========================+=======+=================+===========+
| 7 | TBD1 | Traceroute | This |
| | | Extension Block | document |
+-------------------------+-------+-----------------+-----------+
Table 2
8.2. 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 [RFC8126]: 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 |
+---------+-----------------------------+---------------+
Table 3
8.3. 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 [RFC8126]: 0-191
Specification Required; 192-255 Private or Experimental Use. Initial
values:
Koo Expires 9 April 2027 [Page 29]
Internet-Draft BPv7 TREB October 2026
+=========+=============================+===============+
| 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 |
+---------+-----------------------------+---------------+
Table 4
No registry is created for convergence layer types (Section 3.3) or
for congestion, which is a numeric value.
9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data
Definition Language (CDDL): A Notational Convention to
Express Concise Binary Object Representation (CBOR) and
JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610,
June 2019, <https://www.rfc-editor.org/info/rfc8610>.
[RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object
Representation (CBOR)", STD 94, RFC 8949,
DOI 10.17487/RFC8949, December 2020,
<https://www.rfc-editor.org/info/rfc8949>.
Koo Expires 9 April 2027 [Page 30]
Internet-Draft BPv7 TREB October 2026
[RFC9171] Burleigh, S., Fall, K., and E. Birrane, III, "Bundle
Protocol Version 7", RFC 9171, DOI 10.17487/RFC9171,
January 2022, <https://www.rfc-editor.org/info/rfc9171>.
[RFC9172] Birrane, III, E. and K. McKeever, "Bundle Protocol
Security (BPSec)", RFC 9172, DOI 10.17487/RFC9172, January
2022, <https://www.rfc-editor.org/info/rfc9172>.
9.2. Informative References
[CCSDS734.6]
Consultative Committee for Space Data Systems, "Custody
Transfer and Compressed Bundle Status Reporting",
CCSDS 734.6-O-1, June 2026.
[I-D.ietf-dtn-bibe]
Taylor, R., Ed. and A. Montilla, Ed., "Bundle-in-Bundle
Encapsulation", Work in Progress, Internet-Draft, draft-
ietf-dtn-bibe-00, 7 September 2026,
<https://datatracker.ietf.org/doc/draft-ietf-dtn-bibe/>.
[I-D.ietf-dtn-bp-sand]
Sipos, B. and J. Deaton, "Bundle Protocol (BP) Secure
Advertisement and Neighborhood Discovery (SAND)", Work in
Progress, Internet-Draft, draft-ietf-dtn-bp-sand-04, 8
September 2026, <https://datatracker.ietf.org/doc/draft-
ietf-dtn-bp-sand/>.
[RFC5326] Ramadas, M., Burleigh, S., and S. Farrell, "Licklider
Transmission Protocol - Specification", RFC 5326,
DOI 10.17487/RFC5326, September 2008,
<https://www.rfc-editor.org/info/rfc5326>.
[RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running
Code: The Implementation Status Section", BCP 205,
RFC 7942, DOI 10.17487/RFC7942, July 2016,
<https://www.rfc-editor.org/info/rfc7942>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
[RFC9173] Birrane, III, E., White, A., and S. Heiner, "Default
Security Contexts for Bundle Protocol Security (BPSec)",
RFC 9173, DOI 10.17487/RFC9173, January 2022,
<https://www.rfc-editor.org/info/rfc9173>.
Koo Expires 9 April 2027 [Page 31]
Internet-Draft BPv7 TREB October 2026
[RFC9197] Brockners, F., Ed., Bhandari, S., Ed., and T. Mizrahi,
Ed., "Data Fields for In Situ Operations, Administration,
and Maintenance (IOAM)", RFC 9197, DOI 10.17487/RFC9197,
May 2022, <https://www.rfc-editor.org/info/rfc9197>.
[RFC9758] Taylor, R. and E. Birrane, III, "Updates to the 'ipn' URI
Scheme", RFC 9758, DOI 10.17487/RFC9758, May 2025,
<https://www.rfc-editor.org/info/rfc9758>.
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" value for LTP; 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 (172 bytes):
Koo Expires 9 April 2027 [Page 32]
Internet-Draft BPv7 TREB October 2026
[_
; 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, dtn:none, 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 (217 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, dtn:none, ipn:2.0, 0, 841307664484,
841307664484, [1, 2000, 385000, 3, 12]],
[ipn:2.0, ipn:1.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 (142 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:
Koo Expires 9 April 2027 [Page 33]
Internet-Draft BPv7 TREB October 2026
[_
; 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:1.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 (250 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, dtn:none, ipn:2.0, 0, 841307664484,
841307664484, [1, 2000, 385000, 3, 12]],
[ipn:2.0, ipn:1.0, ipn:3.0, 1, 841307665784,
841308265784, [1, 256, 250, -1, 47]],
[ipn:3.0, ipn:2.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 as queued by the lander for ipn:2.0 (261 bytes; 83
bytes without the report copy). When queuing the report bundle, the
lander appends its own return record (event-type 0), describing the
first hop of the return path (Section 4.7):
Koo Expires 9 April 2027 [Page 34]
Internet-Draft BPv7 TREB October 2026
[_
; 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, dtn:none, ipn:2.0, 0, 841307664484,
841307664484, [1, 2000, 385000, 3, 12]],
[ipn:2.0, ipn:1.0, ipn:3.0, 1, 841307665784,
841308265784, [1, 256, 250, -1, 47]],
[ipn:3.0, ipn:2.0, ipn:3.0, 2, 841308265804, 0,
[0, 0, 0, 0, 0]],
[ipn:3.0, dtn:none, ipn:2.0, 0, 841308265809,
841308265809, [1, 128, 250, -1, 3]]
], 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 lost or not
generated.
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 one return record, fewer
than record-limit (32), so the orbiter appends a second 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 (309 bytes; only the TREB has changed):
Koo Expires 9 April 2027 [Page 35]
Internet-Draft BPv7 TREB October 2026
[_
; 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 two return records, report-value 2)
[194, 2, 0, 0, << [17, 32, [
[ipn:1.0, dtn:none, ipn:2.0, 0, 841307664484,
841307664484, [1, 2000, 385000, 3, 12]],
[ipn:2.0, ipn:1.0, ipn:3.0, 1, 841307665784,
841308265784, [1, 256, 250, -1, 47]],
[ipn:3.0, ipn:2.0, ipn:3.0, 2, 841308265804, 0,
[0, 0, 0, 0, 0]],
[ipn:3.0, dtn:none, ipn:2.0, 0, 841308265809,
841308265809, [1, 128, 250, -1, 3]],
[ipn:2.0, ipn:3.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 and fifth records are
return records: the report returned via ipn:3.0 -> ipn:2.0 ->
ipn:1.0, with link information for both hops, and because the next-
node-id of the last one 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.
Koo Expires 9 April 2027 [Page 36]
Internet-Draft BPv7 TREB October 2026
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). D appends its own
return record D->C when queuing the report, and C and B append theirs
on the way back; 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 (return records by D, C, B):
[A->B, B->C, C->D, D->D,
D->C, 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: D->C, C->B, B->A
Result: A->B B->C C->D D->D
Return path: D -> C -> B -> A
Koo Expires 9 April 2027 [Page 37]
Internet-Draft BPv7 TREB October 2026
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 and from C's prev-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 (return records by D and C):
[A->B, B->C, D->D,
D->C, C->B]
Koo Expires 9 April 2027 [Page 38]
Internet-Draft BPv7 TREB October 2026
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 D and C still append their return records D->C and C->B. B
does not append, because the report copy already holds record-limit
return records; since the next-node-id of the last return record
(C->B) is not A, the departure node knows that the return path was
only partly traced.
A.3. 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 | 13 |
| | 8D 00 00 0A | |
+--------------------------+----------------------------+-------+
Table 5
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.
Appendix B. Size Analysis
B.1. Block Size
With small "ipn" node numbers, a hop-record is typically 41-48 bytes,
depending on the encoded values, of which 18 bytes are event-time and
radiate-time (9 bytes each); a delivery or deletion record is about
33 bytes. Using 47 bytes as a representative record size, a TREB
with N hop-records occupies approximately 13 + 47N bytes including
the canonical block header. For comparison, the TREB of
Appendix A.1.3 is 136 bytes: 13 bytes of block header and array
overhead, two records of 45 bytes, and a delivery record of 33 bytes.
A report copy adds report-value (1 byte for positions up to 23).
Koo Expires 9 April 2027 [Page 39]
Internet-Draft BPv7 TREB October 2026
B.2. 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 Appendix A.1 (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 47
bytes per hop-record. On a symmetric path, the delivery report also
collects N - 1 return records (Section 4.4), which are included in
the last two columns. All columns use the record size of this
document, and each of the first three columns counts N - 1 forwarding
reports and one delivery report.
+=====+==============+==================+============+===========+
| N | Plain BSRs: | -00 (accumulated | This | Of which: |
| | forwarding + | trace in each | document: | the |
| | delivery (no | forwarding | forwarding | delivery |
| | path detail) | report) | + delivery | report |
+=====+==============+==================+============+===========+
| 2 | 166 | 335 | 382 | 238 |
+-----+--------------+------------------+------------+-----------+
| 3 | 249 | 573 | 620 | 332 |
+-----+--------------+------------------+------------+-----------+
| 5 | 415 | 1,190 | 1,096 | 520 |
+-----+--------------+------------------+------------+-----------+
| 8 | 664 | 2,468 | 1,810 | 802 |
+-----+--------------+------------------+------------+-----------+
| 16 | 1,328 | 7,944 | 3,714 | 1,554 |
+-----+--------------+------------------+------------+-----------+
| 32 | 2,656 | 27,920 | 7,522 | 3,058 |
+-----+--------------+------------------+------------+-----------+
| 255 | 21,165 | 1,558,815 | 60,596 | 24,020 |
+-----+--------------+------------------+------------+-----------+
Table 6
N = 255 is the largest hop limit of the Hop Count Block
(Section 4.4.3 of [RFC9171]) and the largest record-limit
(Section 3.2), 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). The delivery report, which carries
the whole path in both directions, accounts for about 40% of the
Koo Expires 9 April 2027 [Page 40]
Internet-Draft BPv7 TREB October 2026
total for N of 8 or more. Forwarding reports add about 61 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.
Appendix C. Change Log
[RFC Editor: please remove this section before publication.]
C.1. Changes from -01
* The node that generates a delivery or deletion report copy now
appends its own return record (event-type 0) when queuing the
report bundle, so that the first hop of the return path is
recorded (Section 4.7). Definitions, Figures 1 and 3, the
examples in Appendix A, and the size analysis in Appendix B were
updated accordingly.
* Added prev-node-id to hop-record: the node from which the
recording node received the bundle, taken from the Previous Node
Block if present and otherwise determined by implementation-
specific means, or dtn:none. It identifies the last node of a
segment of transparent nodes and the node at an empty position,
and allows a node's next-node-id to be compared with what the next
node observed. Examples and size analysis recomputed.
* Traceroute carrier bundles now request forwarding, delivery, and
deletion reports (all SHALL) and should also request status times;
the description of a delivery-only mode is removed from the
Abstract, Section 1, and Appendix B.
* Section 4.7: the recommendation to enable status reporting for
traced bundles is related to the default of Section 5.1 of RFC
9171; the reference for BPA discretion in generating reports is
corrected to Section 5.1 of RFC 9171.
* Added the relationship to custody transfer (Section 1.2):
retransmissions are re-queuings, duplicate records may be ignored
or retained by the departure node, and a traceroute may be kept
open after a deletion report.
* Added handling of Bundle-in-Bundle Encapsulation (Section 4.10): a
BIBE tunnel appears as a single hop, and diagnosing the tunnel is
the responsibility of the encapsulator. Traceroutes are
independent of one another (Section 4.8).
Koo Expires 9 April 2027 [Page 41]
Internet-Draft BPv7 TREB October 2026
* Added the design goal that hop-record values are primarily those
available to the bundle protocol agent (Section 1.1), and
described the status time of a report as the time at which the
status was asserted, in the terms of Section 6.1.1 of [RFC9171].
* Described the handling of fragments (Section 4.9): only the
fragment carrying the TREB is a traced bundle, reports for other
fragments carry no report copy, and delivery is reported after
reassembly.
* Corrected the reason code reported by a node that does not support
the TREB to "Block unsupported" (Section 3.4).
* Defined the handling of event-type and link type values that are
not recognized (Section 3.3).
* Defined the behavior of a departure node that has lost its
traceroute state, for example after a restart (Section 3.3,
Section 4.8).
* The handling of more than one record for a position is described
in one place (Section 4.8): a repeated record is a duplicate, and
any other record is a branch of a tree, after replication or after
a retransmission toward a different next hop. Completion occurs
at the first delivery or deletion report, and a departure node may
keep the traceroute open until treb-completion-timeout
(Section 5).
* Security Considerations (Section 7.2): a BIB or BCB targeting the
TREB protects it until the next participating node, according to
security policy; a consistent chain of records does not prove that
the recorded nodes forwarded the bundle.
* Appendix B: the range of hop-record sizes is corrected to 41-48
bytes, the block size of Appendix A.1.3 is explained, and the
first column of the report traffic table is renamed (values
unchanged).
* IANA: Bundle Protocol Version added to the block type request
(Section 8.1).
* Editorial clarifications in Section 1.2, Section 4.3,
Section 4.10, and Appendix A.1.
C.2. Changes from -00
* Intended status changed to Experimental; Implementation Status
section added (Section 6).
Koo Expires 9 April 2027 [Page 42]
Internet-Draft BPv7 TREB October 2026
* 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).
Koo Expires 9 April 2027 [Page 43]
Internet-Draft BPv7 TREB October 2026
* 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).
Koo Expires 9 April 2027 [Page 44]
Internet-Draft BPv7 TREB October 2026
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.
Author's Address
Cheol Hea Koo
Korea Aerospace Research Institute
Republic of Korea
Email: chkoo@kari.re.kr
Koo Expires 9 April 2027 [Page 45]