Summary

  • Revision 05 of the IETF's ICMP Node Identification draft was announced on 7 September 2026 after an Area Director review. Datatracker records Last Call Requested, not a completed Last Call or an RFC.
  • The new text says a Node Identification Object must be added when the response address may not identify the node, unless local policy or security supersedes. The security section still says addition should be disabled by default except for IP/ICMP translators.
  • The clauses govern different layers: whether a deployment enables disclosure, then what an enabled implementation does for a qualifying message. Neither clause makes a hostname authenticated evidence.
  • Daniel Kade proposes a versioned implementation decision table joining configuration, applicability, override, destination, MTU, emitted bytes and observed bytes. The table is analysis, not an IETF requirement.

One review changed one consequential word

The 7 September Internet-Draft announcement presents draft-ietf-intarea-extended-icmp-nodeid-05 as a 14-page work item of the Internet Area Working Group. The Datatracker record lists it as an active draft intended for Proposed Standard, submitted to the IESG for publication and in Last Call Requested. No telechat date is shown. The document remains work in progress.

Its news value lies less in the page count than in a small normative change. In October 2025, responsible Area Director Éric Vyncke asked the authors to explain when the Section 3 SHOULD could be bypassed. He also queried what domain meant, requested clearer future-bit processing, asked for basic MTU and fragmentation treatment and said the IANA sub-types registry needed to be requested explicitly.

The revision comparison shows the response. Revision 04 said the extension should be appended whenever required to identify a node and local policy or security did not supersede. Revision 05 now says it must be added whenever the responding IP address may not be sufficient to identify the node, unless local policy or security considerations supersede that requirement. It also changes domain to scope-aware language and permits unconditional inclusion.

The stronger verb matters. A SHOULD normally expects an implementer to understand when deviation is justified. The revised sentence instead defines a triggering condition and then names the authorities that may defeat it. That makes the decision more testable, but only if the conditions are kept separate.

What the object can say

The draft extends the multi-part message format created by RFC 4884. In selected ICMPv4 and ICMPv6 error messages, an Extension Object with Class 5 can include an IP Address sub-object, a Name sub-object or both. The bits announcing those fields deliberately align with RFC 5837, which added interface and next-hop information, so generation and parsing code can be reused.

The address needs to identify the node within the appropriate scope. It need not be globally meaningful. The draft explicitly permits an address with only local meaning, such as an IPv6 Unique Local Address, because the operator of that domain may be able to interpret it.

The name can contain up to 63 content octets within a padded sub-object no longer than 64 octets. It should use the sys:hostname from the YANG system model in RFC 7317 when suitable, or another human-meaningful name. Revision 05 adds an important encoding rule: truncation must stop on a UTF-8 character boundary rather than split a multi-octet character.

This is useful diagnostic material. In IPv4-over-IPv6 arrangements, an intermediate router may not have a distinctive IPv4 address with which to answer an IPv4 traceroute. An IP/ICMP translator may add the pre-translation source address, giving an operator a way to associate an error with the originating node rather than only with an address chosen for the reply.

But association is not authentication. The security section is explicit: the draft defines no authentication mechanism, and ICMP messages and their contents are easily spoofed. A string that resembles an inventory hostname is still a string carried in an unauthenticated message. A local address is meaningful only through an external mapping. The extension can improve a diagnostic join; it cannot certify the chassis, its operator, its authority over a route or its responsibility for an incident.

“MUST” and default-off belong to different decisions

The apparent tension sits between Sections 3 and 5. Section 3 addresses an eligible message. When the responding IP address may be insufficient, the object must be added unless policy or security overrides. Section 5 addresses exposure posture. Adding the information is configurable and should be disabled by default, except that IP/ICMP translators should add the IP Address sub-object. An implementation may use destination addresses and access-control lists to decide which objects to send to whom.

One defensible reading is a two-stage control. First, an operator or product decides whether the disclosure capability is enabled for a class of recipients and what security policy governs it. Second, for traffic admitted by that configuration, the implementation evaluates whether the ordinary response address is sufficient and applies the conditional requirement. The exception is not a secret third state. Policy and security are part of the stated rule.

That reading should not be presented as a binding IETF conformance judgment. The draft does not publish a decision algorithm, define sufficient as a machine-testable predicate or say which local role owns the override. It also does not put an omission reason on the wire. Two implementations can therefore produce the same empty observation after materially different decisions.

An absent object has no single explanation

Suppose a measurement collector receives an ICMP Time Exceeded message with no Node Identification Object. The ordinary response address may already have been judged sufficient. The feature may still be at its recommended default-off setting. A local policy or security rule may suppress it, perhaps only for that destination class. The implementation may not support the draft. An object may have been lost or rejected on the return path.

A translator has another bounded reason. Revision 05 says it should reduce the original-datagram field if adding the object would exceed the underlying MTU, while respecting the format's rounding and minimum constraints. If that operation is not possible, the translator must not add the object. No receiver-side absence test can distinguish that required omission from a policy choice.

The reverse inference is equally dangerous. Receiving a Name sub-object does not prove that the value came from sys:hostname, has not gone stale, maps uniquely in the observer's inventory or was sent by the device it appears to name. Receiving a local address does not make that address globally attributable. Class 5 tells a parser what grammar to apply; it does not appoint an identity authority.

The current IANA registry already lists Class 5 as Node Identification Object and points to an earlier individual draft. Revision 05 asks IANA to create a corresponding sub-types registry and reserves future bits to Standards Action, whose meaning is defined by RFC 8126. That gives future fields a controlled vocabulary. It does not solve the provenance of any value placed inside them.

Publish the decision table, not sensitive names

The missing artifact is not a demand for universal hostname disclosure. It is a versioned implementation decision table that vendors can ship with tests and operators can bind to local policy.

Each row should begin with the emitter role: originating node or translator. It should record the ICMP type and address-family context; the rule used to judge whether the normal response address is sufficient; the feature's configuration state; any policy or security override and its accountable owner; the destination or ACL class; and which address or name fields are eligible at that scope.

The next columns should cover packet reality. Did the object fit? Was the quoted original datagram reduced? Did a minimum-size constraint force omission? What exact bytes did the implementation emit? What did a collector observe, from which vantage and at what time? Finally, a separate authentication column should say none in this draft unless an independently evidenced mechanism applies.

The public version can use synthetic names, hashed fixtures and coarse recipient classes. Sensitive hostnames and ACL contents need not be exposed. The point is to preserve the branch logic: which rule was evaluated, which authority supplied an exception and which packet outcome followed.

That distinction protects both privacy and accountability. Operators retain control over disclosure. Implementers gain reproducible conformance cases. Researchers stop treating non-observation as one universal state. Incident teams can join a received label to inventory cautiously rather than allowing a convenient string to become an authenticated actor.

Sources