Summary

  • The 28 October v6ops working-group draft, revision 02 says that when an ICMPv6 error has an untranslatable outer IPv6 source, a translator should use an available public IPv4 address for the ICMPv4 reply. Without one, it must use the dummy address 192.0.0.8. The previous revision did not spell out that priority branch.
  • The translator should append a Node Identification object carrying the original IPv6 source. An ICMPv6 Packet Too Big cannot carry the extension before translation; the draft permits omitting it there, while advising that the error still be translated rather than dropped. The IANA registry lists 192.0.0.8/32 as a dummy address, not a globally reachable destination.

The error has two addresses and only one source field

A diagnostic error is useful because it tells the sender what happened along a path. When IPv4 traffic crosses an IPv6-only segment, the device producing an ICMPv6 error may use an IPv6 source that cannot be mapped back to IPv4. It does not match the translator's configured prefix and has no stateful mapping. A plain ICMPv4 source field cannot carry that original 128-bit address. The translator must still construct a reply that the IPv4 side can receive and interpret.

The draft's Section 4.1 names the three relevant errors: Destination Unreachable, Time Exceeded and Packet Too Big. It now gives the translator a source-address order. If a public IPv4 address or pool is available, use one according to the earlier RFC 6791 approach. If none exists, use 192.0.0.8. Revision 01 said the translator should use the dummy address whenever it faced this untranslatable source. Revision 02 changes the policy from a single favored answer to a conditional one. That matters in the exact networks the document targets: a customer-side translator or IPv6-only service can have no spare public IPv4 source for its own diagnostic messages.

192.0.0.8 is a marker, not the node's identity. IANA's special-purpose registry calls the /32 an IPv4 dummy address and says it is not a valid destination, not forwardable as a destination and not globally reachable as a destination. It can be valid as a source under the registry's flags. A diagnostic display that treats that source as the real intermediate router produces a neat but false map. The address says why the translator could construct a packet without a public source. It does not answer which IPv6 node originated the error.

The proposed second channel is an ICMP Node Identification object carrying an IP Address sub-object with the original IPv6 source. The translator should append it when translating errors from untranslatable sources. If it does append the object, the IPv6 address must be present and the extension checksum must be updated. The draft also says not to use the dummy address or add the extension when the IPv6 source is translatable. A tool that knows the Node Identification draft can display the extra address; a tool that ignores the extension may show only 192.0.0.8. The visible result depends on two independent choices, packet construction and diagnostic presentation.

Packet Too Big exposes the price of a clean story

The most awkward case is Packet Too Big. An ICMPv6 PTB message cannot contain the ICMP extension structure in the way the new object needs. The translator must first turn the error into ICMPv4 and then append Node Identification. Revision 02 leaves the order of other implementation steps open, but it describes that PTB constraint explicitly. It also permits a translator to omit the identity extension on this path. The recommendation is still to translate the PTB using the dummy IPv4 source and not drop it.

That trade matters because a PTB error carries information needed to adjust packet size. Discarding it for lack of a public IPv4 source would sacrifice a useful network signal. Sending it from the dummy address without the Node Identification object preserves the error but weakens attribution. An operator can act on the size signal while seeing only the fallback marker as apparent source. That is a narrower, more honest claim than pretending every translated diagnostic comes with a fully identified origin.

The draft also narrows its applicability. The translator must distinguish errors arising from traffic it translated from native IPv6 traffic that does not need this treatment. Dedicated IPv6 addresses or a /64 for translation make the distinction easier. When the same IPv6 address serves both translated and native traffic, state or inspection of the invoking packet may be necessary. Choosing the wrong class would either attach an unnecessary dummy marker or fail to preserve an error the IPv4 side needs. The boundary is operational, not a property of the IANA number alone.

The document's own operational section says tools such as traceroute must interpret and display the Node Identification object to show the additional information. That is where a standards proposal meets a dashboard. The packet may carry the original address and the operator may still never see it. The earlier Daniel Kade Node Identification articles examined generic disclosure and unknown-AFI parsing. This draft asks a different question: what should an IPv6-to-IPv4 translator do when it has no public source address for a diagnostic error, and what evidence survives on the IPv4 side?

This is still a working-group Internet-Draft under AD evaluation, intended to update RFC 6791 and RFC 7915 if approved. The IANA registry already contains 192.0.0.8; the draft makes no new IANA request. No deployed translator trace or tool output is supplied. A paired trace with and without a public IPv4 source, plus a PTB case and a tool that renders the extension, would show whether the proposed split between delivery and identity holds in software.

Sources