Summary

  • Revision 05 says a Node Identification Object must accompany specified ICMP errors when the response address may not sufficiently identify the originating node, unless local policy or security considerations supersede that behaviour.
  • The object can preserve an address or name that is meaningful inside the relevant scope, including at a translation boundary, but it is unauthenticated and spoofable. Presence is context, not proof; absence has several possible causes.
  • If the enlarged ICMP message would exceed the next-hop MTU, the object may displace bytes quoted from the original datagram. Diagnostic systems therefore need separate confidence records for node context and packet correlation.

An error has two witnesses

An ICMP error normally arrives with two kinds of clues. Its outer packet has a source address, and its body quotes part of the packet that provoked the error. Operators use the first clue to ask where the report came from and the second to associate the report with a flow, probe or transaction.

The two clues can fail in different ways. An interface address selected for the response may not be the address by which an operator knows the node. Across address-family translation, an address that was useful on one side may be absent or transformed on the other. At the same time, the quote is finite: an error packet cannot grow without regard to the path MTU.

Revision 05 of draft-ietf-intarea-extended-icmp-nodeid, posted on 7 September 2026, tries to improve the first clue by defining a Node Identification Object for selected ICMPv4 and ICMPv6 error messages. The Datatracker record lists the work as an active INTAREA working-group Internet-Draft intended for the standards track and in AD evaluation follow-up. It is not an RFC, an approval notice, an implementation report or evidence of deployment.

The revision is newsworthy because it sharpens obligation at the exact point where ambiguity is operationally costly. Where the ICMP response's source address may not sufficiently identify the node that originated the error, the sender now MUST include the object—unless local policy or security considerations take precedence. Revision 04 used SHOULD at that point. The new text also turns several internal handling recommendations into requirements, clarifies UTF-8 truncation and adds explicit behaviour when the object would make the message too large.

That is stronger specification language. It is not stronger identity assurance.

What the capsule may carry

The object can carry an address sub-object, a node-name sub-object, or both. Its C-Type bits announce which sub-objects are present and fix their order. An empty current bit set is now treated as no object rather than as a useful empty shell. Future bit assignments proceed from the left. If a receiver encounters an unsupported future sub-object and cannot know its length, later data cannot safely be found merely because a later bit is familiar; the draft tells the receiver to ignore the additional data.

This is a modest but important lesson in extensibility. A flag can say that something follows without supplying a boundary that allows an old parser to skip it. Forward compatibility is not created by reserving bits alone.

The address is intended to be meaningful in the relevant operational context. A local-scope address can be exactly what an administrator needs even when it is not globally reachable. RFC 4193 explains why a Unique Local IPv6 Address can be globally unique in construction while remaining intended for local communication; “not public” and “meaningless” are not synonyms. Conversely, an address copied out of its scope may be syntactically valid and operationally useless.

The node name is limited to 63 octets. Revision 05 specifies that, when a UTF-8 name must be shortened, truncation occurs on a character boundary before NUL padding. That avoids manufacturing malformed UTF-8 merely to satisfy the field size. It does not make the name globally unique or verified.

The object is available only on the error types named by the draft, not as an automatic identity envelope around every ICMP message. The default is disabled except for translator use, and an implementation may apply destination-based policy. Those limits matter because internal addressing and naming can disclose topology or operational conventions. The stronger MUST is therefore expressly conditional: local secrecy and security policy can defeat transmission.

The Area Director review pressed on the earlier recommendation language, address scope, UTF-8 handling and packet-size consequences. The author's response explains the move to requirements while retaining the policy exception. The exchange is useful evidence of why the text changed. It is not a record of IESG approval.

The translator's vantage point

Translation makes the diagnostic value easy to see. A translator may originate an ICMP error after observing a packet on one side of an address-family boundary. Its outer response address on the far side need not reveal the pre-translation address that an operator needs. The Node Identification Object can carry that context.

The draft's translation treatment sits beside established translation machinery. RFC 7915 specifies stateless IP/ICMP translation, including how ICMP messages and quoted packets are converted. The separate ICMP extensions for IPv6-only source addresses draft addresses a related case: when an IPv6 source cannot be translated into IPv4, the translator can use the reserved IPv4 dummy address 192.0.0.8 and carry the original IPv6 address in an extension. A placeholder source and an extension can jointly preserve more context than either field alone.

But that context remains a statement made by the sender. Revision 05 says the Node Identification Object provides no authentication and can be spoofed. Its intended use is administrative debugging and troubleshooting. A collector that silently promotes it to verified device identity would be adding a claim the draft does not supply.

This yields a practical evidence rule: keep “the sender asserted this node context” separate from “independent controls establish that this node produced the error.” The former can be very useful without becoming the latter.

Information has to fit

The draft also makes the cost visible. ICMP extensions are structured under RFC 4884, whose extended error format preserves at least 128 octets of the original datagram before extension objects. RFC 5837 already uses that framework to identify interfaces and their roles in the path. Node identification adds another diagnostic object, but the containing packet still has an MTU ceiling.

Revision 05 says that if adding the object would exceed the next-hop MTU, the sender should remove enough bytes from the quoted original datagram where possible, rounded to four-byte units for ICMPv4 and eight-byte units for ICMPv6. If the quote is already at the minimum permitted size, the object must not be added.

That is not merely a serialization detail. A probe collector may gain a better clue about the reporting node while losing transport headers or payload bytes it would otherwise use to match the error to a specific transaction. In another packet, the minimum quote may prevent the node object from appearing at all. Two observations with the same visible absence can therefore represent different realities: feature disabled, destination policy, secrecy rule, unsupported implementation, non-applicable error type, MTU pressure at the minimum quote, or simply no need because the source address was sufficient.

Presence is not proof, and absence is not a negative identity assertion.

Do not merge the confidence columns

A sound operational record should preserve at least two independent dimensions.

The first is node-context confidence: Was the object present? Which address or name did it assert? In what scope is that value meaningful? Was the path one where a translator could have inserted pre-translation context? Is the sender inside an administrative domain whose behaviour is otherwise trusted?

The second is correlation confidence: How many original-datagram bytes survived? Did the quote include enough header material to associate the error with the intended flow? Was any reduction attributable to the extension/MTU rule? Could several contemporaneous packets match the remaining quote?

Collapsing those dimensions into one “diagnostic quality” score conceals the precise trade the revision introduces. A message can have strong correlation and weak node attribution, or useful local node context and a thin quote. Automation should expose that shape rather than manufacture certainty.

The evidence boundary also protects the draft from being oversold. No implementation tests or quantified prevalence accompany the revision. We do not know from these sources how frequently MTU pressure will remove useful quoted bytes, how many operators will enable the object, or which products will implement revision 05. Those are observations to collect after implementations exist, not numbers to infer from normative language.

The draft improves the vocabulary of an error. It does not turn the error into a signed witness.