Summary

  • draft-ietf-intarea-extended-icmp-nodeid-05 proposes attaching an IP address, a node name, or both to selected ICMP errors when the ordinary reply address does not identify the responding node.
  • The IETF Last Call ended on 22 September 2026, but the document remains an Internet-Draft under IESG evaluation, not an approved RFC or evidence of implementation.
  • The extra context may improve diagnosis, yet it is recommended off by default, can reveal topology, and has no authentication mechanism; operators therefore need separate receipts for disclosure, authenticity and operational value.

One hop, two possible nodes

A traceroute line looks decisive because it supplies an address and a delay. In a network where several forwarding nodes reply through the same IPv4 address, that apparent identity can be weaker than the display suggests. The address says where the ICMP error appeared to come from. It may not say which physical or logical node processed the expired packet.

That problem becomes sharper when IPv4 traffic crosses infrastructure whose interfaces and next hops are IPv6-only. The current node-identification draft describes this case alongside translation paths in which an intermediate IPv6-only router has no ordinary IPv4 address to place in an IPv4 traceroute reply. The proposed Node Identification Object can carry an address with useful scope, a human-readable name, or both.

The proposal does not replace the responding source address. It adds a second layer of evidence. The ordinary ICMP header still identifies the packet source as represented on the return path; the extension offers a claim about the originating node. That distinction is the mechanism’s value and its principal risk.

A proposed semantic contract, not a finished standard

The IESG opened Last Call on 8 September and requested comments by 22 September. A fresh Datatracker capture on 24 September records revision 05 as active, submitted to the IESG, waiting for AD go-ahead and requiring IANA action. The public page places it on the 8 October IESG telechat agenda.

Those are process receipts. They do not collapse into approval. Revision 05 still identifies itself as an Internet-Draft and expires on 11 March 2027 if it is not refreshed or replaced. A telechat can lead to approval, revision, deferral or another review step. Even an eventual Proposed Standard would describe an interoperable contract; it would not prove that routers implement it, that operators enable it, or that a named deployment obtains useful results.

The IANA ICMP registry already lists Class Value 5 as a Node Identification Object and points to an earlier individual draft. That allocation coordinates parsing. It is not a substitute for the IESG decision, publication, software evidence or packet observation.

What the object can say

The object follows the extension framework created by RFC 4884, which lets selected ICMP errors carry structured information after the quoted original datagram. Revision 05 permits the new object on ICMPv4 Time Exceeded, Destination Unreachable and Parameter Problem messages, and on ICMPv6 Time Exceeded and Destination Unreachable messages.

An address sub-object can contain IPv4 or IPv6 information of a scope appropriate to the context. The draft explicitly permits an address with only local meaning when a domain operator can interpret it. A name sub-object can contain up to 63 octets of a YANG sys:hostname or another human-meaningful name. The wire format fixes ordering and padding so a receiver can parse the fields consistently.

This differs from RFC 5837, which identifies interfaces and next hops. An interface label answers where a packet entered or would have left. A node identifier tries to answer which system originated the error. The questions are adjacent, but they are not interchangeable.

The motivating architecture is not hypothetical at the specification level. IPv4 routes with an IPv6 next hop can remove unique IPv4 interface identities from the forwarding interior. The companion XLAT draft proposes using a dummy IPv4 source together with node-identification information so an IPv4 diagnostic can preserve evidence about an IPv6-only translator or router. RFC 7915 and RFC 6877 supply the translation context; they do not prove the new object is deployed.

The name is useful because it is revealing

A hostname such as a city, facility, layer or role can turn a puzzling hop into an actionable clue. The same semantics can disclose the layout of a network to anyone who can elicit the corresponding ICMP error. Revision 05 therefore makes emission configurable and recommends it disabled by default, except for its specified translator case. It also permits destination-aware choice of fields and suggests ACLs to restrict recipients.

This is where a seemingly small extension becomes a policy surface. The relevant question is not simply “does this router support Class 5?” It is which message types can disclose which fields to which destinations. An internal monitoring system may need a stable node name. A customer-facing diagnostic may need a less specific address. An arbitrary Internet host may need neither.

The policy also needs a scope vocabulary. A unique-local IPv6 address may be meaningful inside one domain and meaningless outside it. A 63-octet truncation may preserve a distinguishing prefix in one naming scheme and remove the distinguishing suffix in another. A globally routed address may identify a management endpoint without identifying the forwarding instance that emitted the error. The draft gives operators encoding choices; it cannot decide what each naming plan reveals.

Parseable is not authentic

The security boundary is explicit: the draft specifies no authentication mechanism and warns that ICMP messages and their contents are easily spoofed. RFC 4884’s checksum can detect some corruption in the extension structure. It does not prove who generated the name or address.

A diagnostic system should therefore retain the raw response, observation time, vantage point, original probe, outer source address, extension fields and local disclosure expectation. It should mark whether the extension parsed correctly without upgrading that fact into identity proof. Corroboration can come from repeated probes, authenticated management telemetry, configuration records or a controlled test, but each of those is a separate receipt.

This restraint follows a broader operational rule. Running-code primacy demands evidence from the system that actually carries the consequence. Minimum initial specification and localized future decision explains why common wire syntax should remain narrow while disclosure remains with the operator. Reality layers warns against letting a well-formed record acquire powers belonging to deployment or outcome.

Class 5 can make an ICMP reply more descriptive. It cannot make the reply true.

Sources