Summary

  • The IETF Internet Area group's 28 September revision 06 of its ICMP Node Identification draft adds an explicit receiver rule for an unrecognized Address Family Identifier, or AFI. It remains an Internet-Draft at IESG Evaluation, not an RFC.
  • AFI 1 and 2 give the receiver known IPv4 and IPv6 address lengths. With any other value, the proposed rule requires processing of the Node Identification Object to stop and the packet to be handled as though that object were absent.
  • The same paragraph preserves the possibility of handling later ICMP Extension messages using the outer length defined by RFC 4884. It does not instruct a receiver to discard the whole packet.

The length that cannot be guessed

The proposed Node Identification Object helps a responding node identify itself in selected ICMP errors where its source address may be inadequate, including a path involving IPv6-only nodes and IPv4 probes. It can carry an IP address, a name, or both. That is useful diagnostic information, not cryptographic authentication of the sender.

Its address sub-object has a variable length. Revision 06 defines AFI 1 as a 32-bit IPv4 address and AFI 2 as a 128-bit IPv6 address. If the value is neither, a reader cannot determine how many bytes belong to the address or where a following name begins. Treating the unknown field as a familiar length would invent information the packet did not provide.

The new text resolves that ambiguity at the narrowest stated scope: stop interpreting the Node Identification Object and handle the packet as if that object were not present. This is more precise than either accepting a guessed identity or throwing away the entire ICMP message. RFC 4884 gives the enclosing extension structure length information, so a receiver may still skip the partly handled message and process later extensions. The draft also links future changes to supported AFI values and meaning to RFC 5837 §4.2; an arbitrary number in an address-family registry does not, on its own, make an unfamiliar Node ID safe to parse.

A review comment became a parser rule

This is a genuine difference from revision 05, not merely a new date. The revision's change log credits transport and security directorate reviews. The security review specifically asked what a receiver should do when AFI is unrecognized, because it cannot know the expected length. That question is now answered in proposed normative text. The review did not document an exploit or a defective deployed product.

The prior Daniel Kade report on revision 05 examined the separate choice to enable identity disclosure at all and the conditional requirement to send it. Revision 06 addresses what a receiver can safely read. A configured emitter, a validly delimited object and a trustworthy assertion of node identity are three different facts.

Sources