IP/ICMP Translation Algorithm
obsoleted by
- rfc-7915 — IP/ICMP Translation Algorithm
obsoletes
- rfc-2765 — Stateless IP/ICMP Translation Algorithm (SIIT)
updated by
Extracted elements (31)
For IPv6-to-IPv4 translation of packets without a Fragment Header, setting DF=1 is preferred over clearing it, because while DF=1 may create PMTUD black holes on IPv4 links smaller than 1260 bytes, clearing DF risks IPv4 reassembly errors (RFC 4963), which is considered the more dangerous failure.
Studies found only 43% of IPv6 hosts correctly handled ICMPv6 Packet Too Big with MTU < 1280 (vs. 95% for MTU=1280), attributed to firewalls violating RFC 4890. The translator SHOULD change MTU values < 1280 to 1280 in the IPv4-to-IPv6 direction, causing hosts to send packets with Fragment Headers that the translator can handle in the reverse direction.
The IPv6 Flow Label is set to zero during IPv4-to-IPv6 translation because there is no corresponding field in IPv4 from which to derive a meaningful value; the stateless algorithmic nature of SIIT does not maintain per-flow state needed to generate consistent flow labels.
When the IPv4 sender does not set the DF bit, the translator SHOULD include an IPv6 Fragment Header to signal that the sender allows fragmentation. This ensures that if the packet is later translated back to IPv4 the DF flag is not set, preserving correct fragmentation semantics end-to-end.
Fragmented ICMP/ICMPv6 packets will not be translated by the IP/ICMP translator. Fragmented IPv4 UDP packets with a zero checksum are also not translated unless the translator is explicitly configured to forward them without a UDP checksum.
ICMP extensions (RFC 4884) within error payloads must have their length attribute adjusted when the inner IP header translation changes packet length. Extensions not defined in RFC 4884 are passed as opaque bit strings; IPv4/IPv6 address literals within them will not be translated, potentially causing processing problems.
IPv4 multicast addresses (RFC 5771) cannot be mapped to IPv6 multicast addresses (RFC 3307) using the unicast mapping rule in RFC 6052, limiting the scope of multicast translation.
All ICMPv4 packets MUST have their Type translated and, for ICMPv4 error messages, the included IP header MUST also be translated. The ICMPv6 checksum field MUST be calculated as part of translation since ICMPv6 has a pseudo-header checksum.
For IPv4-to-IPv6 translation, the Next Header field MUST be copied from the IPv4 Protocol field except ICMPv4 (1) which becomes ICMPv6 (58). As part of decrementing TTL or Hop Limit, the translator MUST check for zero and send the appropriate ICMP error.
ICMP error messages containing a packet in error MUST be translated just like a normal IP packet. If translation changes the length, the Total Length in the outer IPv6 header MUST be updated. Translation MUST stop at the first embedded header; packets with more embedded headers are dropped.
If a non-checksum-neutral translation address is used, ICMPv6 messages MUST have their ICMPv4 checksum updated. In the IPv6-to-IPv4 direction, translators MUST recalculate checksums for TCP, UDP, and ICMP.
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' (Type 4, Code 0) with Pointer indicating the Segments Left field SHOULD be returned.
If a translated IPv6-to-IPv4 packet with DF=1 will be larger than the MTU of the next-hop interface, the translator MUST drop the packet and send ICMPv6 Packet Too Big (Type 2, Code 0) to the IPv6 host with an adjusted MTU.
If an ICMPv6 error is generated because the IPv6 source address is not IPv4-translatable and the translator is stateless, the message MUST have Type 1 Code 5 (Source address failed ingress/egress policy). In other discard cases it MUST have Type 1 Code 1.
If the address translation algorithm is not checksum neutral, translators MUST recalculate and update transport-layer headers for TCP, ICMP, and UDP packets with a non-zero UDP checksum. Other transport protocols (e.g., DCCP) are OPTIONAL to support but MUST be forwarded.
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 to the IPv4 source address.
If the translator also provides normal forwarding and the destination IPv4 address is reachable by a more specific route without translation, the translator MUST forward it without translating. Otherwise, when addressed to an IPv4 destination in the IPv6 domain, the packet MUST be translated.
Implementations of this IPv4/IPv6 translation specification MUST also support the address translation algorithms in RFC 6052. Implementations MAY also support stateful translation per RFC 6146.
IPv4 options MUST be ignored and the packet translated normally. However, if an unexpired source route option is present, the packet MUST be discarded and an ICMPv4 'Destination Unreachable, Source Route Failed' (Type 3, Code 5) SHOULD be returned.
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.
When translating ICMPv4 Code 4 (Fragmentation Needed) to ICMPv6 Packet Too Big, the MTU field MUST be set to minimum(advertised MTU+20, MTU_of_IPv6_nexthop, (MTU_of_IPv4_nexthop)+20). If the IPv4 router set MTU to zero, the translator MUST use RFC 1191 plateau values.
When translating ICMPv6 Packet Too Big (Type 2) to ICMPv4 Destination Unreachable (Type 3, Code 4), the MTU field MUST be adjusted: minimum(advertised MTU-20, MTU_of_IPv4_nexthop, (MTU_of_IPv6_nexthop)-20), accounting for whether the packet in error includes a Fragment Header.
ICMPv4-to-ICMPv6 type/code mappings: Echo/Echo Reply (8/0)→(128/129); Destination Unreachable (3) codes translated (e.g., Code 0,1→0, Code 4→PTB Type 2); Time Exceeded (11)→Type 3; Parameter Problem (12)→Type 4. Obsoleted, single-hop, and unknown types are silently dropped.
ICMPv6-to-ICMPv4 type/code mappings: Echo Request/Reply (128/129)→(8/0); Destination Unreachable (1) codes translated (Code 0→Code 1, Code 1→Code 10, Code 4→Code 3); Packet Too Big (2)→Type 3 Code 4; Time Exceeded (3)→Type 11; Parameter Problem (4)→Type 12 or 3. NDP/MLD and unknown messages silently dropped.
IPv4-to-IPv6 header field mapping: Version=6, Traffic Class copied from TOS (8 bits), Flow Label=0, Payload Length from IPv4 Total Length minus IPv4 header size, Next Header changed from ICMPv4(1) to ICMPv6(58) otherwise copied, Hop Limit derived from TTL, Source/Destination addresses derived per RFC 6052 Section 2.3.
IPv6-to-IPv4 header field mapping: Version=4, IHL=5, TOS from Traffic Class, Total Length = IPv6 Payload Length + 20, Identification=0 (default), Flags DF=1/MF=0, Fragment Offset=0, TTL from Hop Limit, Protocol from Next Header chain (ICMPv6(58)→ICMPv4(1)), Header Checksum computed, addresses derived per RFC 6052.
SIIT introduces no new security issues beyond those in IPv4 and IPv6 themselves. The IPsec Authentication Header (RFC 4302) cannot be used across an IPv6-to-IPv4 translator. Tunnel mode ESP can be translated; transport mode ESP fails unless checksum-neutral addresses are used. IPsec ESP endpoints normally detect the translator and encapsulate ESP in UDP (RFC 3948).
IPv6 Fragment Header fields when added during IPv4-to-IPv6 translation: Next Header in IPv6 header = 44 (Fragment); Fragment Header Next Header = ICMPv6(58) or copied protocol; Fragment Offset copied from IPv4; M flag copied from IPv4 MF bit; Identification = low-order 16 bits of IPv4 Identification field, high-order 16 bits set to zero.
IPv6 Fragment Header processing for IPv6-to-IPv4 translation: Total Length = IPv6 Payload Length - 8 (Fragment Header) + 20 (IPv4 header); Identification = low-order 16 bits of IPv6 Fragment Header Identification; MF flag copied from IPv6 M flag; Fragment Offset copied; DF cleared to allow further IPv4 fragmentation.
Parameter Problem pointer translation IPv4→IPv6 (Figure 3): offset 0(Version/IHL)→0, 1(TOS)→1, 2-3(Total Length)→4, 8(TTL)→7, 9(Protocol)→6, 12-15(Source)→8, 16-19(Dest)→24. Offsets for Identification (4-5), Flags/Fragment Offset (6-7), and Header Checksum (10-11) map to n/a causing the packet to be dropped.
Parameter Problem pointer translation IPv6→IPv4 (Figure 6): offset 0→0, 1→1, 4-5(Payload Length)→2, 6(Next Header)→9, 7(Hop Limit)→8, 8-23(Source Address)→12, 24-39(Dest Address)→16. Offsets 2-3 (Flow Label) map to n/a causing the packet to be dropped.