| Internet-Draft | icmpext-xlat-source | October 2026 |
| Lamparter & Linkova | Expires 1 May 2027 | [Page] |
This document suggests that when a source IPv6 address of an ICMPv6 message can not be translated to an IPv4 address, and the protocol translator does not have any public IPv4 addresses available to source the translated packet from, the translator uses the dummy IPv4 address (192.0.0.8) to translate the IPv6 source address. This document updates RFC6791, Stateless Source Address Mapping for ICMPv6 Packets, and RFC7915, IP/ICMP Translation Algorithm, by proposing to utilize the ICMP extension for Node Identification (draft-ietf-intarea-extended-icmp-nodeid) to carry the original IPv6 source address of ICMPv6 messages.¶
This note is to be removed before publishing as an RFC.¶
Source, version control history, and issue tracker for this draft can be found at https://github.com/eqvinox/icmpext-clat-source.¶
(Note the draft was renamed (from "clat" to "xlat") prior to submission but changing the repository name on github breaks too many things to be worth the effort.)¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 1 May 2027.¶
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
To allow communication between IPv6-only and IPv4-only devices, IPv4/IPv6 translators translate IPv6 and IPv4 packet headers according to the IP/ICMP Translation Algorithm defined in [RFC7915]. For example, 464XLAT ([RFC6877]) defines an architecture for providing IPv4 connectivity across an IPv6-only network. The solution contains two key elements: provider-side translator (PLAT, usually in a form of stateful NAT64, [RFC6146])) and customer-side translator (CLAT). CLAT implementations translate private IPv4 addresses to global IPv6 addresses, and vice versa, as defined in [RFC7915]. Another common scenario is IPv6-only data centers using Stateless IP/ICMP Translation Algorithm (SIIT [RFC7755]) to provide connectivity between IPv6-only servers and IPv4-only clients.¶
To map IPv4 addresses to IPv6 ones the translators use the translation prefix (either a well-known or a network-specific one, see [RFC6052]). The resulting IPv6 addresses can be statelessly translated back to IPv4. However, this is not the case for arbitrary global IPv6 addresses; those addresses can only be translated to IPv4 by stateful translators and only if a corresponding translation rule exists.¶
The most common scenario involves translating ICMPv6 messages sent by IPv6-only routers to IPv4-only destinations. For example, in IPv6-only data centers using SIIT, an intermediate router might need to return an ICMPv6 error to the IPv4 host (e.g., if the host runs a traceroute or sends packets exceeding the router's interface MTU). As per Section 4.8 of [RFC7755] the translator typically drops these ICMPv6 error packets because IPv6-only infrastructure routers rarely have IPv6 addresses that can be statelessly translated to IPv4. This behavior complicates troubleshooting, confuses users, and increases operational costs when users report network packet loss based on incomplete traceroute results.¶
[RFC6791] discusses this issue in more details and recommends that translators use a single (or small pool of) public IPv4 address as the source address of the translated ICMP message. However that approach assumes that the translator is configured with at least one public IPv4 address, which is often not the case for CLAT: CLAT instances running on endpoints (mobile phones, laptops etc) are normally using a single non-global IPv4 address from 192.0.0.0/29 range ([I-D.ietf-v6ops-claton]).¶
In addition to translating ICMPv6 messages, it is desirable to preserve the original IPv6 source address and make it available to applications. For example, tools like traceroute would be able to display it to the user. [RFC6791] suggests using an ICMP extenstion defined in [RFC5837] to carry the source IPv6 addresses of the original ICMPv6. Hwoever that approach has some drawbacks, as discussed in the following sections. This document recommens using the Node Identification Object dnd an IP Address Sub-Object defined in [I-D.ietf-intarea-extended-icmp-nodeid] instead.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
Translator: a device performing translation between IPv6 and IPv4 packet headers according to the IP/ICMP Translation Algorithm defined in [RFC7915]. Translators can be stateless ([RFC7915]) or stateful ([RFC6146]).¶
Translatable IPv6 address: an IPv6 address which matches the NAT64 prefix known to the translator, or for which the translator has a stateful entry, mapping that IPv6 address to an IPv4 one.¶
Untranslatable IPv6 address: an IPv6 address which does not match the NAT64 prefix(es) configured on the translator, and for which the translator does not have a stateful entry, mapping this IPv6 address to an IPv4 one.¶
Whenever a translator translates an ICMPv6 Destination Unreachable, ICMPv6 Time Exceeded or ICMPv6 Packet Too Big ([RFC4443]) to the corresponding ICMPv4 ([RFC0792]) message, and the IPv6 source address in the outermost IPv6 header is untranslatable, the translator MUST use the following logic to select the IPv4 source address for the translated packet:¶
If the translator has a public IPv4 address (or a pool of such addresses) available, it SHOULD use a public IPv4 address, following recommendations in Section 3.2 and Section 5 of [RFC6791].¶
In all other cases the translator MUST use the dummy IPv4 address (192.0.0.8).¶
To preserve the original IPv6 source address of the packet, the translator SHOULD append a Node Identification Object ([I-D.ietf-intarea-extended-icmp-nodeid]) with an IP Address Sub-Object containing the IPv6 source address of the original ICMPv6 packet.¶
The translator MUST NOT use 192.0.0.8/32 to translate the source IPv6 address and MUST NOT add the extension if the packet's IPv6 source address is translatable.¶
A Node Identification Extension Object SHOULD be added when translating:¶
ICMPv6 Destination Unreachable to ICMPv4 Destination Unreachable¶
ICMPv6 Time Exceeded to ICMPv4 Time Exceeded.¶
ICMPv6 Packet Too Big to ICMPv4 Destination Unreachable.¶
and the IPv6 source address in the outermost IPv6 header is untranslatable.¶
When adding the Node Identification Extension Object, the translator MUST include the IP Address Sub-Object containing the original IPv6 source address of the packet.¶
This document doesn't prescribe the exact procedure for adding the Node Identification Extension Object when translating ICMPv6 messages to ICMPv4. Section 12.1 describes one possible approach, but the choice is left to implementors, as long as the following requirements are met:¶
The resulting ICMPv4 message contains the Node Identification Extension Object with the IP Address Sub-Object.¶
The checksum field of the Extension Header (Section 7 of [RFC4884]) is updated accordingly.¶
This specification does not prescribe whether the Node Identification Extension Object is added before or after translating an ICMPv6 message to ICMPv4. This choice is up to the implementation. However ICMP Extensions can not be added to ICMPv6 Packet Too Big messages (see Section 4.6 of [RFC4884]). Therefore in order to be able to add the Node Identification Extension Object and preserve the original untranslatable IPv6 address, the translator needs to add the object to the resulting ICMPv4 packet after it's been translated from ICMPv6. The translator MAY choose to not append the Node Identification Extension Object when translating an ICMPv6 Packet Too Big to an ICMPv4 Destination Unreachable. Such implementations SHOULD still translate ICMPv6 Packet Too Big from untranslatable sources using 192.0.0.8 as an IPv4 source address and SHOULD NOT drop those packets.¶
[RFC6791] proposes using the Interface Information Object and Interface IP Address Sub-Object defined in [RFC5837] to preserve information about untranslatable IPv6 addresses. However Section 4.2 of [RFC5837] suggests that an IPv4 packet MUST only contain an IP Interface Sub-Object representing an IPv4 address. Therefore using the mechanism described in [RFC6791] requires updating [RFC5837].¶
More importantly, Section 3.2 of [RFC6791] recommends using a single (or small pool of) public IPv4 address as the source address of the translated ICMP message. As discussed earlier, this approach works only if the translator has a pubic IPv4 address available, and therefore is often not feasible for translators performing CLAT functions.¶
The solution proposed in this document has a number of benefits:¶
It does not require public IPv4 addresses configured on the translator.¶
No changes to processing of the Interface Information Object are required.¶
Using a dedicated IPV4 dummy address 192.0.0.8 indicates to the user that it's not an actual IPv4 address of the intermediate node.¶
Therefore this document makes the following changes to [RFC6791].¶
If the translator has no public IPv4 available, it MUST use a dummy IPv4 address 192.0.0.8 as a source of the translated ICMP packets.¶
Instead of using the ICMP extension defined in [RFC5837], the translator SHOULD use a Node Identification Object ([I-D.ietf-intarea-extended-icmp-nodeid]) with an IP Address Sub-Object, as described in Section 4 of this document.¶
This document makes the following changes to Section 5.1 ("Translating IPv6 Headers into IPv4 Headers") of [RFC7915]:¶
OLD TEXT¶
Source Address: Mapped to an IPv4 address based on the algorithms presented in Section 6.¶
NEW TEXT¶
Source Address: Mapped to an IPv4 address based on the algorithms presented in Section 6. When translating ICMPv6 error messages to ICMPv4 error messages and the valid IPv6 source address in the outermost IPv6 header can not be mapped to an IPv4 address (the address does not match the prefix used in algorithmic mapping and there are no static or stateful entries for that address), the translator SHOULD follow the recommendations in draft-ietf-v6ops-icmpext-xlat-v6only-source.¶
This document also updates the very last paragraph of Section 5.2 of [RFC7915] ("Error payload:") as follows:¶
OLD TEXT:¶
For extensions not defined in [RFC4884], the translator passes the extensions as opaque bit strings and any IPv6 address literals contained therein will not be translated to IPv4 address literals; this may cause problems with processing of those ICMP extensions.¶
NEW TEXT:¶
For extensions not defined in [RFC4884], the translator passes the extensions as opaque bit strings and any IPv6 address literals contained therein will not be translated to IPv4 address literals; this may cause problems with processing of those ICMP extensions. If the valid IPv6 source address in the outermost IPv6 header of the ICMPv6 messages cannot be mapped to an IPv4 address (the address does not match the prefix used in algorithmic mapping and there are no static or stateful entries for that address), the translator SHOULD follow the recommendations in draft-equinox-intarea-icmpext-xlat-source.¶
The mechanism described in this document necessitates that the translator distinguishes between ICMPv6 packets originating from untranslatable addresses requiring translation (triggered by an IPv4 packet translated to IPv6) and native IPv6 traffic that does not. When the translator employs dedicated IPv6 address(es) for IPv4 translation (e.g., a CLAT instance acquiring dedicated address(es) or a dedicated /64), this differentiation is straightforward.¶
However, if the same IPv6 address is used for both IPv4 translation and native IPv6 traffic, the translator may require more complex techniques to differentiate. These techniques could include maintaining state and/or analyzing the invoking packet header within the ICMPv6 message body to determine if the invoking packet was translated¶
There are no new operations or manageability requirements introduced by this document. The changes proposed by this document are likely to simplify troubleshooting and improve manageability of networks that provide connectivity between IPv6-only and IPv4-only devices. To fully benefit from the proposed approach network administrators need to use tools (such as traceroute) which are able interpret and display the additional information contained in a Node Identification Extension Object and an IP Address Sub-Object.¶
In scenarios when CLAT function is performed not by a host but by a router (such as a CPE providing IPv4 connectivity downstream via an IPv6-only uplink), packets with source address set to 192.0.0.8 can be sent by the CPE downstream.¶
This document does not introduce new security considerations.¶
This document does not introduce any privacy considerations.¶
This memo includes no request to IANA.¶
If the original ICMPv6 message does not contain an ICMP Extension Structure (as defined in Section 7 of [RFC4884]), the translator SHOULD append a new ICMP Extension Structure to the ICMP message. When adding the new Extension Structure, the translator MUST:¶
Create a new ICMP Extension Structure, containing one Extension Header and one Node Identification Extension object. The Node Identification Extension object MUST contain an IP Address Sub-Object, carrying the IPv6 source address of the ICMPv6 message being translated.¶
Append that Extension Structure to the ICMP message.¶
If the resulting packet size exceeds the minimum IPv6 MTU: truncate the embedded invoking packet by removing the trailing 28 octets (to accommodate for 4 octets of the extension header and 24 octets of the extension object).¶
Set the length field of the ICMP message to the length of the padded "original datagram" field, measured in 32-bit words.¶
If the original ICMPv6 message already contains an ICMP Extension Structure, the translator SHOULD append a Node Identification Extension object containing the IP Address Sub-Object to that structure. When appending the object, the translator MUST:¶
Create a Node Identification Extension object containing an IP Address Sub-Object. The IP Address Sub-Object MUST contain the original source IPv6 address of the ICMPv6 message being translated.¶
Append a Node Identification Extension object to the Extension Structure.¶
Update the checksum field of the Extension Header accordingly.¶
If the resulting packet size exceeds the minimum IPv6 MTU: truncate the embedded invoking packet by removing the trailing 24 octets (to accommodate for 24 octets of the extension object) and update the length field of the ICMP message¶
This document is the result of discussions with Thomas Jensen. The authors would like to thank Mohamed Boucadair, Ondřej Caletka, Lorenzo Colitti, Darren Dukes, Bill Fenner, Tobias Fiebig, and Jordi Palet Martínez for their feedback, comments and guidance. The authors would like to particularly thank Tore Anderson for pointing out the existence and relevance of [RFC6791].¶