BPv7 Echo Service

3.1. Service Endpoint

An echo service registers to receive requests at one or more endpoint identifiers. The well-known endpoint is ipn-scheme service number TBD1 (Section 6) on any node; for example, ipn:2.TBD1 represents the echo service on node number 2. Implementations MAY also support service number 7 for backwards compatibility with existing deployments; service number 7 is in the Private Use range per [RFC9758] and cannot be reserved.¶

An echo service SHOULD support the well-known endpoint, so that clients can reach it without out-of-band configuration. It MAY also support private or alternative endpoints, which clients must learn of by other means.¶

3.2. Request Delivery

A request bundle is received and processed by the echo service node's BPA like any other bundle destined for one of the node's endpoints: the BPA processes its extension blocks, applies local security policy, reassembles it if it arrived as fragments, and delivers the request to the echo service ([RFC9171], Section 5.7).¶

The echo service therefore receives the request, together with delivery metadata from the request bundle ([RFC9171], Section 3.1): its source node ID and destination EID, and, as far as the BPA makes them available, its bundle processing control flags, lifetime, age, and report-to EID. The echo service uses this metadata only to decide whether to respond (Section 3.3.1) and to set the primary block of the response bundle (Section 3.3.2). It has no other use for the request bundle, and in particular none for its extension blocks.¶

3.3. The Response Bundle

When a request is delivered to an echo service, the echo service responds as specified in this section. When it responds (Section 3.3.1), it MUST request transmission of exactly one response bundle conforming to these rules ([RFC9171], Section 5.2), and MUST NOT emit more than one response per request.¶

The response bundle is a new bundle, sourced by the echo service node, whether the echo service runs as an application or is built into the BPA. It is constructed and processed under [RFC9171] (and, where security is applied, [RFC9172]) like any other bundle the node sources, and this document does not restate those rules. The rules in this section constrain only what the echo service supplies for that new bundle: the values of certain primary block fields, which it takes from the delivery metadata of the request (Section 3.2), and its payload, which is the response.¶

3.4. Client Considerations

While this specification focuses primarily on the echo service, certain requirements apply to clients to ensure correct operation. This section defines those normative requirements.¶

4.1. Enabling and Restricting the Echo Service

An implementation MUST provide a means for the operator to disable the echo service; to limit the responses it sends, both by restricting which requests it answers and by rate (Section 4.2); and, where the echo service propagates status-report settings onto response bundles (Section 3.3), to disable that propagation. These means can be provided by the echo service itself, by the BPA through which requests are delivered to it, or by both. A request that the echo service declines to answer is consumed without a response (Section 3.3.1).¶

Policy can be applied at different points and at different granularities, for example:¶

• by the BPA before delivery, so that unwanted requests never reach the echo service;¶

• by source node ID, or by a set of source EIDs (for example, expressed as EID patterns [I-D.ietf-dtn-eid-pattern]);¶

• by the presence on the request bundle of a BPSec [RFC9172] integrity block whose security source the node trusts;¶

• by the BPA before delivery, according to the extension blocks present on the request bundle, for example discarding request bundles that carry blocks of types the node does not expect;¶

• by the node from which the request bundle was received, where the convergence layer or a Previous Node Block identifies it; or¶

• by the echo service endpoint at which the request arrived.¶

Control over whether the echo service propagates the request bundle's report-to EID and status-report-request flags onto the response bundle matters because propagation lets a requester direct status reports from every node on the return path to an EID of its choosing.¶

Whether and how an operator applies these limits is a deployment decision. Answering every delivered request maximizes the diagnostic value of a well-known endpoint and simplifies interoperability testing, but exposes the node to the concerns described in Section 5. In a network whose bundle sources are not otherwise authenticated, restricting the echo service to requests whose source is authenticated or otherwise trusted is particularly effective against reflection, which relies on forged sources.¶

4.2. Rate Limiting

In this document, rate limiting means declining to respond to some requests, as described in Section 4.1, rather than delaying responses: a delayed response consumes storage at the echo service node, and to the client it is indistinguishable from a slow return path. An echo service sends no indication to the requester that a response was withheld, because any such indication would itself be a bundle directed at a possibly spoofed source.¶

The limit, and how it is measured, are matters of local policy. A limit applied per source node ID bounds the traffic the echo service can direct at any one destination; a limit applied per previous node bounds the load any one neighbor can impose. Where the BPA, rather than the echo service, discards request bundles before delivery, it deletes them as specified in [RFC9171], Section 5.10; any deletion status report it generates (for example, with reason code "Traffic pared") is subject to the node's status-reporting policy and raises the same reflection concern.¶

4.3. Missing and Multiple Responses

Because an echo service sends nothing when it declines a request, a client that receives fewer responses than it sent requests cannot tell, from the responses alone, whether a request or response was lost or expired in transit, whether a request was declined by policy or rate limiting, or whether no echo service is present at all. Loss figures reported by ping clients (Appendix A) therefore count unanswered requests, whatever the cause, not only path loss. Status reports can narrow the ambiguity where they are available: a delivery report for a request bundle with no corresponding response indicates that the request reached the echo service node, and that the response was then declined or lost on the return path.¶

Conversely, a client can receive more than one response to a single request, in two different ways:¶

• Distinct response bundles. Where a request is addressed to a non-singleton endpoint, each member that answers sends its own response in its own response bundle, with its own source and creation timestamp (Section 4.4). These are different bundles, so they are not removed by any duplicate suppression on the return path, and their sources identify the responders.¶

• Copies of one response bundle. The network can replicate a response bundle on the return path. The copies share its source node ID and creation timestamp, and the client's BPA might or might not suppress them.¶

Either way, every response is identical to its request, so a client matches responses to requests by content (Appendix A.3). A ping client typically takes the round-trip time from the first response to arrive, counts the request as answered once, and reports any further responses separately. A client that can see the source node ID and creation timestamp of each response bundle can also tell distinct response bundles apart from copies of the same one.¶

4.4. Non-Singleton Endpoints

Every ipn-scheme EID identifies a singleton endpoint ([RFC9758], Section 5.1), but other EIDs, such as dtn-scheme EIDs whose demux begins with '~' ([RFC9171], Section 4.2.5.1.1), can identify endpoints with many members. If an echo service is registered in such an endpoint, a single request elicits a response from every member that receives it. Each echo service still emits at most one response, but the number of responses in the network scales with the membership of the endpoint, reintroducing the count amplification that Section 5.1 otherwise rules out.¶

An echo service SHOULD NOT answer requests addressed to a non-singleton endpoint unless the operator has explicitly configured it to do so. When it does, the response bundle cannot be sourced from the non-singleton EID to which the request bundle was addressed, because the source of a bundle is a node ID ([RFC9171], Section 4.2.5.2). The echo service SHOULD instead use the EID of its node's administrative endpoint: for example ipn:2.0 ([RFC9758], Section 5.7) or dtn://node-name/ ([RFC9171], Section 4.2.5.1.1), preferably in the same URI scheme as the request's destination where the node has an administrative EID in that scheme. Every node is permanently registered in its administrative endpoint ([RFC9171], Section 4.2.5.2), so this choice needs no additional configuration; where the echo service runs as an application on a BPA that does not let applications source bundles from the administrative endpoint, the BPA can set the source on the echo service's behalf. This choice has three properties that a source shared by the members of the endpoint would lack:¶

• It contains reflection. Whatever answers a response addresses it to the response's source. Were that source the group's EID, each such answer would be delivered to every member, and two echo groups induced to answer one another, for example by a request to one group forged with the other group's EID as its source, would multiply the traffic by the size of the group at every exchange. A group EID is not normally recognizable as an echo service endpoint, so the rule in Section 3.3.1 would not stop this. An administrative endpoint is a single node that does not echo bundles, so any such exchange ends there.¶

• It keeps response bundles distinct. A bundle is identified by its source node ID and creation timestamp. Members that share a source assign creation timestamps independently and, answering the same request at about the same time, can easily assign the same one; duplicate suppression, fragment reassembly, and status reporting on the return path would then conflate response bundles from different members.¶

• It identifies the responder, which nothing else in the response bundle does: the response is identical to the request, and a Previous Node Block identifies only the last hop.¶

A client that addresses a non-singleton endpoint should therefore expect zero, one, or many responses to each request, each sourced from the administrative endpoint of the responding node rather than from the EID the client addressed. Such a client matches responses to requests by content (Appendix A.3), not by source.¶

4.5. Endpoint Configuration

The well-known service number requested in Section 6 is a default, not a requirement: as [RFC9758], Section 5.6 describes, it lets a client sensibly assume where the service is operating unless configuration says otherwise. Existing deployments answer echo requests on a variety of service numbers. Implementations SHOULD therefore allow the operator to configure the endpoints at which the echo service is registered, and ping clients SHOULD allow the target endpoint to be specified in full.¶

4.6. Client Source Endpoints

Ping clients need a distinct source endpoint for each concurrent session (Section 3.4.1), usually for the lifetime of that session only. This document does not reserve service numbers for such transient use; a BPA that supports transient registrations can allocate them from a Private Use range of [RFC9758]. Because responses can arrive long after a session has ended, it is good practice for a BPA not to reassign a recently released source endpoint to a different application promptly, and for a client to discard responses that do not match a request it sent.¶

5.1. Reflection and Amplification

Like any echo or reflection service, an echo service can be abused to direct traffic at a victim. Because the source of a bundle is not authenticated by default, an attacker can send requests whose source is set to a victim's endpoint, causing the echo service to send responses to that victim. The echo service thereby launders the attacker's traffic and conceals its origin.¶

The volume amplification factor is close to one: each response is identical to its request, and the requirement to emit at most one response per request (see Section 3.3) prevents count amplification. The principal risk is therefore reflection toward, and concentration of traffic on, a chosen victim rather than bandwidth amplification. Operators can mitigate this risk by:¶

• Rate-limiting responses, particularly to or from previously unseen endpoints (Section 4.2)¶

• Restricting responses to authenticated or otherwise trusted requesters, for example using Bundle Protocol Security [RFC9172] (Section 4.1)¶

• Monitoring for unusual traffic patterns that might indicate abuse¶

An echo service that propagates the request bundle's report-to EID and status-report-request flags onto the response bundle (see Section 3.3) extends this reflection surface to the status reports generated for the response bundle; the same mitigations apply, and an operator can also disable that propagation (Section 4.1).¶

Registering an echo service in a non-singleton endpoint reintroduces count amplification, since every member that receives a request answers it; see Section 4.4.¶

Because an echo service originates nothing but responses (Section 3.3.1), a bundle whose source is an echo service endpoint is only ever a response bundle. A receiver can use this to recognize reflected traffic: a bundle from an echo service endpoint that does not correspond to a request the destination application sent, for example one delivered to an application that is not a ping client, indicates that the destination's endpoint has been forged as the source of requests elsewhere. An application or BPA MAY discard such bundles, and a BPA MAY apply rate limits or other policy to bundles whose source is a well-known echo service endpoint. Echo services are themselves the most important such receiver, since answering a response would create a loop between two echo services; Section 3.3.1 therefore forbids it.¶

Responses to requests addressed to non-singleton endpoints are sourced from the responding node's administrative endpoint instead (Section 4.4), so an echo service cannot recognize them by their source. This does not reopen the loop: if such a response reaches another echo service, because the request's source was forged as that echo service's endpoint, the second echo service answers it, but its response is addressed to the administrative endpoint, which does not echo bundles, and the exchange ends there.¶

Source EIDs are not authenticated by default, so these checks help discard reflected traffic but do not authenticate genuine responses; see Section 3.4.2.¶

5.2. Information Disclosure

Echo responses inherently confirm the existence and reachability of the echo service endpoint. Additionally, round-trip time measurements might reveal information about network topology, path characteristics, and store-and-forward delays that could be useful to an adversary mapping a network.¶

Extension blocks on request bundles can also reveal how nodes on the forward path process bundles, and so which block types they support, how they apply security policy, and potentially which implementations they run (Appendix A.5.1). Most of this comes from status reports rather than from the echo service: a block that no node processes, marked "Transmit status report if block can't be processed", elicits a report from every node that receives it where status reporting is enabled, sent to a report-to EID of the requester's choosing. The same is true of a bundle sent to any destination, and the exposure is limited in the same way, by disabling status reporting as [RFC9171], Section 8 recommends by default, or by filtering bundles at the edge of the network. The echo service adds only whether a response returns, and none of the request bundle's extension blocks are carried into the response bundle (Section 3.3.4), so the return path is not exposed. Such probing is also a legitimate diagnostic, which this document does not prohibit.¶

In sensitive environments where this information disclosure is a concern, operators can:¶

• Restrict echo service access to authenticated endpoints using BPSec, or discard request bundles carrying unexpected extension blocks before delivery (Section 4.1)¶

• Disable the echo service entirely on nodes where diagnostics are not required (Section 4.1)¶

• Deploy the echo service only on designated diagnostic nodes rather than throughout the network¶

5.3. Resource Exhaustion

An attacker could attempt to exhaust echo service resources by sending a large volume of requests or very large requests. Since the echo service must construct and transmit a response for each request, this creates both memory and bandwidth pressure. The following protections are RECOMMENDED:¶

• Limiting the maximum size of request accepted¶

• Limiting the rate of requests answered (Section 4.2)¶

• Monitoring resource usage, and declining requests when under stress¶

These protections need not be implemented by the echo service itself. Where the echo service runs as an application on a BPA, the BPA can provide them before requests are delivered, for example by limiting the size of bundles it accepts, the rate at which bundles are delivered to the echo service endpoint, or the storage allotted to such bundles. What matters is that the deployment as a whole provides them, under the operator's control (Section 4.1).¶

6.1. Well-Known Service Registration

This document requests IANA to register the following entry in the "'ipn' Scheme URI Well-Known Service Numbers for BPv7" registry established by [RFC9758], assigning the next available value in the Standards Action range (128-255):¶

RFC Editor: please replace TBD1 throughout this document with the value assigned by IANA, and remove this note.¶

Note: Existing implementations do not agree on a service number for echo. Several use 7 by convention, mirroring the well-known UDP port for the Echo Protocol [RFC862], while others use different values (for example, 2047). All of these lie within ranges designated Private Use by [RFC9758] and so cannot be reserved. This document requests a value from the Standards Action range to provide a single registered value; see also Section 4.5.¶

7.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/rfc/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/rfc/rfc8174>.

[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/rfc/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/rfc/rfc9172>.

[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/rfc/rfc9758>.

7.2. Informative References

[I-D.ietf-dtn-eid-pattern]

Sipos, B., "Bundle Protocol Endpoint ID Patterns", Work in Progress, Internet-Draft, draft-ietf-dtn-eid-pattern-11, 23 September 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-dtn-eid-pattern-11>.

[RFC862]

Postel, J., "Echo Protocol", STD 20, RFC 862, DOI 10.17487/RFC862, May 1983, <https://www.rfc-editor.org/rfc/rfc862>.

[RFC8899]

Fairhurst, G., Jones, T., Tüxen, M., Rüngeler, I., and T. Völker, "Packetization Layer Path MTU Discovery for Datagram Transports", RFC 8899, DOI 10.17487/RFC8899, September 2020, <https://www.rfc-editor.org/rfc/rfc8899>.

[RFC9174]

Sipos, B., Demmer, M., Ott, J., and S. Perreault, "Delay-Tolerant Networking TCP Convergence-Layer Protocol Version 4", RFC 9174, DOI 10.17487/RFC9174, January 2022, <https://www.rfc-editor.org/rfc/rfc9174>.

A.1. Round-Trip Time Calculation

Accurate round-trip time (RTT) measurement is the primary purpose of most ping implementations. Ping clients should calculate RTT using locally stored timestamps rather than timestamps embedded in the request:¶

RTT = response_receive_time - request_sent_times[sequence_number]

This approach offers several advantages:¶

• Requires no clock synchronization between nodes¶

• Works correctly even if the response is corrupted¶

• Avoids serialization overhead in the timing path¶

The client should maintain a map from sequence number to sent timestamp. It should populate the map when each request is transmitted and consult it when each response arrives. Entries should be removed after a configurable timeout to prevent unbounded memory growth.¶

A.2. Endpoint Selection

As required by Section 3.4.1, multiple concurrent clients on the same node use distinct source endpoint identifiers.¶

For example, if two concurrent ping sessions on node ipn:1.0 target ipn:2.TBD1, they should use distinct source endpoints such as ipn:1.1001 and ipn:1.1002. The BPA then delivers each response to the correct session based on the destination of its response bundle.¶

A ping client must not use a well-known echo service endpoint (for example, service number TBD1) as its own source endpoint. Per Section 3.3.1, services other than the echo service do not source bundles from an echo service endpoint, and an echo service does not answer a request so sourced.¶

A.3. Request Format

Because each response is identical to its request, the format of requests is entirely at the discretion of the ping client; the echo service neither parses nor interprets them. This document defines no request format.¶

A client need only place a sequence number in each request, so that it can match each response to the request that produced it. Everything else a client needs is kept in local state, keyed by that sequence number:¶

• the time the request was sent, used for the round-trip time calculation of Appendix A.1 (timestamps need not be carried in the request); and¶

• optionally, whatever lets the client confirm that a response is an unmodified echo of its own request — for example, by retaining each request it sent and comparing it against the response.¶

Alongside the sequence number, a client should include a value that it does not reuse across sessions and that an off-path attacker cannot predict, such as a random nonce. This lets the client reject responses belonging to an earlier session that used the same source endpoint, and responses forged by an attacker able to guess sequence numbers; see also Section 4.3.¶

Because the whole request returns unchanged, a client can match and validate responses with no agreed wire format and without relying on Bundle Protocol Security in the network. Authenticating the responder itself is a separate matter, addressed by the echo service node's own BPSec policy on the response bundle (Section 3.4.2).¶

A client may also pad the request with additional bytes to reach a chosen request bundle size, for example to probe the largest bundle a path will carry (Appendix A.5.2).¶

A.4. Interpreting Status Reports

A client may request status reports on its request bundles in the usual way, by setting the relevant bundle processing control flags and a report-to EID. Such reports concern the request bundle's own progress toward the echo service and carry the client's endpoint as the source EID of the subject bundle.¶

By setting status-report-request flags and a report-to EID on its request bundle, a ping client asks to observe the exchange end-to-end. An echo service can honor this by propagating those settings onto the response bundle (see Section 3.3). Where it does, the designated observer receives status reports for both legs of the exchange and can attribute each report to its leg from the source EID of the report's subject bundle: the client's endpoint for the request bundle, and for the response bundle the echo service endpoint or, where the request was addressed to a non-singleton endpoint, the responding node's administrative endpoint (see Section 4.4). Because not every echo service does so, and status reporting is optional in any case, a client should not rely on receiving reports for the return leg. Note also that a client can tie a request-leg report to a specific request, because it knows that bundle's identifier, but cannot in general tie a response-leg report to a specific request: the response bundle's creation timestamp is assigned by the echo service and is not predictable by the client. Round-trip completion for a given request is instead confirmed by the response, which carries the sequence number (see Appendix A.1).¶

Status reports on the request bundle can still aid diagnosis. For example, a "Forwarded" report with no corresponding response suggests the request bundle was lost between an intermediate node and the echo service. Note that status reporting is optional per [RFC9171] and many BPA implementations disable it by default; clients should not rely on receiving status reports for correct operation.¶

A.5. Path Probing

A response confirms more than reachability: it shows that the request bundle, as the client constructed it, was carried to the echo service node and that a response bundle came back. By varying how it constructs request bundles, a ping client can use this to test how a path treats particular bundles before an application relies on them. This section describes two such probes: varying the extension blocks on request bundles, and varying their size.¶

A.6. Statistics

Ping clients should track and report standard statistics consistent with traditional IP ping:¶

• Requests transmitted¶

• Responses received¶

• Loss percentage¶

• RTT minimum, average, maximum, and standard deviation¶

These statistics provide a quick assessment of network health and help identify routing problems, congestion, or intermittent connectivity.¶

Example output format following ICMP ping conventions:¶

--- ipn:2.TBD1 ping statistics ---
5 requests transmitted, 4 received, 20% loss
rtt min/avg/max/stddev = 1.234/2.567/4.891/1.203 s