IP/ICMP Translation Algorithm
obsoletes
- rfc-6145 — IP/ICMP Translation Algorithm
Extracted elements (29)
IPv6 atomic fragment generation was deprecated in RFC 7915 (relative to RFC 6145) based on analysis in the 'Generation of IPv6 Atomic Fragments Considered Harmful' study. This change removes the algorithm that generated atomic fragments as part of IPv4-to-IPv6 translation, as atomic fragments were found to cause operational harm.
The translator sets the IPv4 DF flag based on packet size (≤1260 bytes → DF=0, otherwise DF=1) to accommodate the different minimum MTUs of IPv4 (68 bytes) and IPv6 (1280 bytes). This approach allows Path MTU Discovery to operate end-to-end for paths with MTU ≥1280 bytes (corresponding to 1260 in the IPv4 domain), while IPv4 routers handle fragmentation on links with MTU <1260.
Fragmented ICMP/ICMPv6 packets will not be translated by IP/ICMP translators. Additionally, the translator does not translate any IPv4 options and does not translate IPv6 extension headers except the Fragment Header.
IPv4 multicast addresses cannot be mapped to IPv6 multicast addresses based on the unicast mapping rule (RFC 6052), so multicast scenarios require separate consideration. ICMPv4 IGMP messages are single-hop messages and SHOULD be silently dropped by the translator.
Some translated protocols will fail at the receiver: IPsec Authentication Header (protocol 51) is known to fail when translated. Transport mode ESP will fail with IPv6-to-IPv4 translation unless checksum-neutral addresses are used; in both cases, IPsec ESP endpoints will normally detect the translator and encapsulate ESP in UDP (RFC 3948).
Studies indicate it is not unusual for networks to drop ICMPv6 Packet Too Big error messages. Such drops cause PMTUD black holes (RFC 2923) that can only be overcome with Packetization Layer Path MTU Discovery (PLPMTUD, RFC 4821). Implementations should account for this operational reality.
All ICMPv4 packets to be translated require ICMPv6 checksum recalculation since ICMPv6, unlike ICMPv4, uses a pseudo-header checksum like UDP and TCP. All ICMPv4 packets MUST have the Type translated, and for ICMPv4 error messages the included IP header also MUST be translated.
ICMP error messages containing the packet in error MUST be translated just like a normal IP packet (except TTL/Hop Limit of the inner packet). If translation of the inner 'packet in error' changes the datagram length, the Total Length field in the outer header MUST be updated. Translation MUST stop at the first embedded header and drop the packet if it contains more embedded headers.
If a Routing header with a non-zero Segments Left field is present in an IPv6 packet, the packet MUST NOT be translated; an ICMPv6 'parameter problem/erroneous header field encountered' (Type 4, Code 0) error message with the Pointer field indicating the first byte of the Segments Left field SHOULD be returned to the sender.
If an IPv6 packet that is ≤1280 bytes results (after translation) in an IPv4 packet that is larger than the MTU of the next-hop interface, the translator MUST perform IPv4 fragmentation on that packet so it can be transferred over the constricting link.
If any IPv4 options are present in the IPv4 packet, they MUST be ignored and the packet translated normally. However, if an unexpired source route option is present, the packet MUST instead be discarded, and an ICMPv4 'Destination Unreachable, Source Route Failed' (Type 3, Code 5) error message SHOULD be returned to the sender.
If the IP/ICMP translator also provides normal forwarding, and the destination address is reachable by a more specific route without translation, the translator MUST forward it without translating. When an IPv4 datagram is addressed to an IPv4 destination representing a host in the IPv6 domain, the packet MUST be translated to IPv6.
Implementations of this IPv4/IPv6 translation specification MUST support one or more address mapping algorithms as defined in Section 6. The translator MUST support the stateless address mapping algorithm defined in RFC 6052 as the default behavior.
The translator MUST behave as a router: it MUST send a Packet Too Big error message or fragment the packet when the packet size exceeds the MTU of the next-hop interface. Due to the 20-byte difference between IPv4 (20+ octets) and IPv6 (40 octets) headers, MTU handling is critical for correct operation.
Translators MUST update transport-layer checksums for TCP and ICMP packets and for UDP packets with a non-zero checksum, when using a non-checksum-neutral address mapping algorithm. For UDP packets with a zero checksum, the translator SHOULD either drop the packet (generating a management event) or calculate an IPv6 checksum before forwarding.
When the IPv4 sender does not set the DF bit, the translator MUST NOT include the Fragment Header for non-fragmented IPv6 packets. If the DF bit is set and the MTU of the next-hop interface is less than the total length of the IPv4 packet plus 20, the translator MUST send an ICMPv4 'Fragmentation Needed' error message to the IPv4 source address.
ICMPv4 Destination Unreachable (Type 3) is translated to ICMPv6 Type 1, with code mapping: Codes 0,1 → Code 0; Code 2 (Protocol Unreachable) → ICMPv6 Parameter Problem Type 4 Code 1; Code 3 → Code 4; Code 4 (Fragmentation Needed) → ICMPv6 Packet Too Big (Type 2) with MTU adjustment. The MTU field MUST be adjusted for IPv4/IPv6 header size difference but MUST NOT be set below 1280 bytes.
ICMPv4 query messages are translated as follows: Echo (Type 8) and Echo Reply (Type 0) are mapped to ICMPv6 Types 128 and 129 respectively. ICMPv4 Information Request/Reply (Types 15/16), Timestamp (Types 13/14), Address Mask (Types 17/18), Router Advertisement (Type 9), Router Solicitation (Type 10), IGMP, and unknown ICMPv4 types are all silently dropped.
ICMPv6 messages are translated to ICMPv4 as follows: Echo Request/Reply (Types 128/129) map to ICMPv4 Types 8/0. MLD messages (Types 130-132) and Neighbor Discovery messages (Types 133-137) are single-hop messages and are silently dropped. ICMPv6 Destination Unreachable (Type 1) maps to ICMPv4 Type 3 with code translation.
ICMPv6 Packet Too Big (Type 2) translates to ICMPv4 Destination Unreachable (Type 3) with Code 4. The MTU field MUST be adjusted for the difference between IPv4 and IPv6 header sizes: minimum((MTU in Packet Too Big)-20, MTU_of_IPv4_nexthop, (MTU_of_IPv6_nexthop)-20).
SIIT translates between IPv4 and IPv6 packet headers (including ICMP) by removing the original IP header and replacing it with a translated header; the data portion is left unchanged. The translator operates in either stateless mode (no session state, based solely on packet contents and configuration) or stateful mode (maintains dynamic translation table with IPv4/IPv6 address and Layer-4 identifier bindings).
The IPsec Authentication Header (RFC 4302) cannot be used for NAT44 or NAT64, as the AH covers the IP header fields that are modified by translation. Tunnel mode ESP can be translated since it does not depend on header fields prior to the ESP header.
The use of stateless IP/ICMP translators does not introduce new security issues beyond those already present in IPv4, IPv6, and the routing protocols used to route packets to the translator. However, potential issues arise from deriving IPv4 addresses from IPv6 addresses, particularly for addresses like broadcast, loopback, or non-IPv4-translatable addresses; RFC 6052 addresses these.
ICMPv4 Parameter Problem pointer values are translated to ICMPv6 using a defined mapping table: IPv4 pointer 0 (Version/IHL) → IPv6 pointer 0; pointer 1 (TOS) → pointer 1; pointers 2,3 (Total Length) → pointer 4; pointer 8 (TTL) → pointer 7; pointer 9 (Protocol) → pointer 6; pointers 12-15 (Source) → pointer 8; pointers 16-19 (Destination) → pointer 24. Unmapped pointer values result in the packet being silently dropped.
ICMPv6 Parameter Problem pointer values are translated to ICMPv4 using a defined mapping table: IPv6 pointer 0 (Version/TC) → IPv4 pointer 0; pointer 4-5 (Payload Length) → pointer 2; pointer 6 (Next Header) → pointer 9; pointer 7 (Hop Limit) → pointer 8; pointers 8-23 (Source) → pointer 12; pointers 24-39 (Destination) → pointer 16. Flow Label (pointers 2-3) maps to n/a (packet dropped).
When a Fragment Header is added during IPv4-to-IPv6 translation, the Fragment Header Identification field takes the low-order 16 bits from the IPv4 Identification field with the high-order 16 bits set to zero; Fragment Offset and M flag are copied from the IPv4 header. Next Header in the Fragment Header maps ICMPv4(1) to ICMPv6(58) or copies the protocol field.
When translating an IPv6 Fragment Header to IPv4, the IPv4 Identification field takes the low-order 16 bits from the IPv6 Fragment Header Identification field. The IPv4 MF flag is copied from the IPv6 M flag, and the IPv4 DF flag is cleared (set to zero), allowing further fragmentation by IPv4 routers.
When translating IPv4 headers to IPv6: Version=6, Flow Label=0, Next Header maps ICMPv4(1) to ICMPv6(58) or copies protocol field, Hop Limit derived from TTL, Source/Destination addresses mapped via Section 6 algorithms. Payload Length is IPv4 Total Length minus IPv4 header and options size.
When translating IPv6 headers to IPv4: Version=4, IHL=5 (no IPv4 options), TOS copied from IPv6 Traffic Class, Total Length = IPv6 Payload Length + IPv4 header size, TTL derived from Hop Limit. The DF flag is cleared if the translated IPv4 packet is ≤1260 bytes; otherwise it is set to one.