Summary

  • RFC 9507 adapts traceroute to CCNx and NDN, where Interests follow names rather than unique destination addresses and Data returns through hop-by-hop Pending Interest Table state.
  • A nonce keeps each diagnostic Interest distinct; four reply codes separate a forwarder hop from an administrative-name match, local application or cached object; a Path Label can steer later requests along one observed branch.
  • The result is bounded route evidence. The same name can lead to other paths, producers or cached copies, and a signed forwarder reply does not prove content origin, ordinary application behavior or service outcome.

The trace looked conclusive. Six forwarders answered in order. Each response carried a name, a round-trip time and a path value. The last response arrived from a cache close to the client. On the screen, the sequence resembled the familiar route to a host: a line of infrastructure ending at a destination.

But there was no unique destination. The next Interest for the same name could reach another cached copy, a producer application or a different branch selected by the forwarding strategy. The final responder had proved that it could answer the diagnostic condition. It had not proved that it was the origin of the content, that every ordinary request would reach it, or that the retrieved object was the one the application needed.

RFC 9507 was written for that unfamiliar geometry. Published in March 2024 as Experimental work on the IRTF stream, it defines an ICN Traceroute for Content-Centric Networking and Named Data Networking. It is explicitly not an IETF Standards Track specification. Its contribution is a disciplined way to observe routes in a system where the network forwards Interests by name and can satisfy them from several places.

A name is not an address in disguise

Traditional IP traceroute relies on an expanding sequence of TTL values. A router where the TTL expires sends an ICMP Time Exceeded message toward the packet's source address. The technique has many qualifications, but its basic coordinate is a destination address.

ICN changes that coordinate. An Interest names data. It carries no source address, and returned Data follows the reverse state left in forwarders' Pending Interest Tables. A name can be served by an application, by more than one producer or by a Content Store holding a cached copy. Consecutive Interests can take different paths and reach different data sources even when the requested name does not change.

Ordinary same-name Interests may also be aggregated into one PIT entry. That is useful forwarding behavior, but it is hostile to a diagnostic that expects each request to travel and return as its own experiment. Aggregation can shorten an apparent exchange because one Interest joins state created by another. A stable load does not guarantee a stable observed round trip.

RFC 9507 therefore appends a nonce-bearing name component. In CCNx it is a 64-bit typed segment; the NDN form combines the target, a nonce and a traceroute suffix. The nonce makes each probe unique for PIT treatment and lets the client match a reply to the request. It is ignored during Content Store matching, so a cached object can still terminate the trace. That small asymmetry is the heart of the instrument: unique experiment, unchanged target test.

Four answers that must not be flattened into “reached”

A session begins with HopLimit 1 and sends successive requests with larger limits. At each step a forwarder checks and decrements the value. If the request continues, the forwarder applies Content Store lookup, PIT creation, Longest Name Prefix Match and any supplied steering value. If no valid next hop exists, CCNx returns “No Route” or NDN returns a network NACK.

When the limit reaches zero, the current forwarder returns a reply identifying itself. That is reply code 4: the probe reached the distance selected by the client. It is not the same as reaching a semantic destination.

Three other conditions make the reply final. Code 1 means the target matched an administrative name served by the forwarder's management application. Code 2 means a longest-prefix FIB match points to a local application. Code 3 means the target exactly matched a Content Object in the local Content Store, unless the client chose to ignore cache hits. Those are three different answering surfaces. One identifies a managed forwarder, one locates an application namespace, and one finds a particular cached object.

A monitoring system that stores only success=true destroys the most important evidence. The reply code says why the session stopped. A cache answer can be excellent news for latency and poor evidence of producer reachability. A local-application answer says the forwarder can hand the Interest to a local face; it does not say that useful application work completed. HopLimit zero reports one hop boundary, not content reachability.

The Path Label can repeat a branch, not certify the topology

Multipath creates a second problem. Increasing HopLimit does not help if each new request chooses a different branch. The sequence could splice together forwarders that never formed one path.

RFC 9507 uses the Path Steering mechanism specified in RFC 9531. A reply begins with a null Path Label at its origin. Each forwarder on the reverse path updates the label to encode its next-hop choice. The client can copy the returned label into the next request and ask the forwarding plane to follow the same branch. It can omit the label in a later session to explore alternatives.

This makes a coherent trace possible, but it does not transform the label into a permanent route ID. It records choices made during one traversal under one state of the FIB, caches, forwarding strategy and topology. Reusing it tests whether that branch can be followed again. Omitting it creates an opportunity—not a guarantee—to find another route. A failure to discover alternatives does not prove that none exist.

The evidence statement should therefore be narrow: this nonce-bound session, using this target and Path Label at this time, elicited these replies and terminated for this code. “The path to the content is X” asserts far more.

Identity signatures stop one attack, not every substitution

The reply includes the sender's administrative name. That lets the operator contact the forwarder for richer management information, perhaps through CCNinfo. It also creates a reflection risk: a malicious responder could name a victim and cause subsequent management traffic to be directed there.

For CCNx, the replying forwarder must sign the name in the payload. The client is expected to fetch the corresponding public key and verify it. This binds the included name to the key used by the responder and blocks the simple victim-name substitution.

The protection has a precise edge. A compromised on-path forwarder can replace both the previous name and its signature with its own valid pair. Signing the complete reply can prevent that modification, but signing every message costs computation and can expose the forwarder to a different denial-of-service pressure. The RFC recommends handling requests and replies in a separate local management application so diagnostic load does not consume the main forwarding path.

The audit record must say what was signed, which key was trusted, whether the whole message was protected and whether key retrieval succeeded. “Signed trace” is too vague to support a security decision.

Local names reveal the routing scaffold

A locally scoped name may not be routable from the client's network. RFC 9507 describes two bridges. One attaches a signed NDN Link Object containing routable prefixes until the Interest reaches the region where the local name works. The document deliberately leaves acquisition of that Link Object out of scope.

The other prepends a routable prefix. A border forwarder removes the prefix when the Interest enters the local region and restores the necessary routing context on the reply. That border now maintains extra state. Under load, the mechanism can amplify Interest-flooding pressure.

If an operations system records only the final local name, it hides the scaffold that made the trace possible. The Link Object reference, routable prefix, border rewrite and region transition belong beside the hop sequence. Otherwise a trace that appears to follow one namespace actually crosses an unrecorded authority and transformation boundary.

RFC 9507 is valuable because it does not pretend that name-based routing makes diagnostics impossible. It gives operators concrete probes, terminal conditions, identities and steering state. Its restraint is just as valuable. One trace demonstrates one observed answering route. Content provenance, complete topology, application success and durable service still need their own receipts.

Sources