Stateless IP/ICMP Translation Algorithm (SIIT)
obsoleted by
- rfc-6145 — IP/ICMP Translation Algorithm
Extracted elements (27)
A new IPv4-translated address form is introduced rather than reusing IPv4-compatible addresses (0::0:a.b.c.d) because IPv4-compatible addresses are reserved for automatic tunneling. Using them for SIIT would create ambiguity and cause packets to be encapsulated rather than forwarded through the translator.
All translator operations are stateless: the translator operates independently on each packet and retains no state between packets. This allows redundant translator boxes without coordination, and allows the two directions of a TCP connection to traverse different translator boxes.
Fragmented UDP packets with zero checksum are dropped rather than translated because an informal backbone trace showed all 769 such packets (out of 34 million) were due to malicious or broken behavior (port scans, malformed fragments). The limitation is therefore not considered significant.
The IPv4-translated prefix (0::ffff:0:0:0/96) was specifically chosen so that it checksums to zero, thereby avoiding any changes to the transport protocol's pseudo-header checksum when IPv6-only nodes use IPv4-translatable source addresses. This preserves the stateless property of the translator.
When an IPv6-to-IPv4 translator's source address is not an IPv4-translated address (e.g., an ICMPv6 error from an IPv6-only router), the IPv4 source is set to 0.0.0.0 rather than dropping the packet entirely. This allows tools like traceroute to display something meaningful for IPv6-only hops in the path.
End-to-end path MTU discovery operates across the SIIT translator as long as path MTU is at least 1280 bytes. When an IPv6 node receives an ICMPv6 'packet too big' reporting MTU less than 1280, it reduces path MTU to 1280 and includes a Fragment header in each packet, allowing subsequent IPv4 fragmentation by routers on the IPv4 side.
IPv4 multicast addresses cannot be mapped to IPv6 multicast addresses; for example, ::ffff:224.1.2.3 is an IPv4-mapped address with a class D value but is not an IPv6 multicast address. This limitation makes SIIT inapplicable to multicast traffic.
IPv4 options are ignored (not translated) during IPv4-to-IPv6 translation. Similarly, IPv6 hop-by-hop options, destination options, and routing headers with Segments Left equal to zero are ignored during IPv6-to-IPv4 translation, with the Total Length and Protocol fields adjusted to skip these extension headers.
The IPv6 protocol was designed so that TCP and UDP pseudo-header checksums are unaffected by SIIT translations, so the translator need not modify normal TCP or UDP headers. The only exceptions are unfragmented IPv4 UDP packets with zero checksum and all ICMP messages (which require checksum recalculation due to ICMPv6's pseudo-header checksum).
An IPv6-only node using SIIT MUST use an IPv4-translatable address as its source address when the destination is an IPv4-mapped address. An IPv4-translatable address MUST NOT be used with other forms of IPv6 destination addresses.
If a peer has AAAA/A6 address records, the application or resolver SHOULD never fall back to looking for A records even if communication fails using the available AAAA/A6 records. This prevents traffic between two IPv6 nodes from accidentally passing through SIIT translators twice.
If an IPv6 routing header with a non-zero Segments Left field is present, the packet MUST NOT be translated. An ICMPv6 'parameter problem/erroneous header field' (Type 4/Code 0) error with the Pointer indicating the Segments Left field SHOULD be returned to the sender.
If an unexpired IPv4 source route option is present in an IPv4 packet, the packet MUST be discarded and an ICMPv4 'destination unreachable/source route failed' (Type 3/Code 5) error SHOULD be returned to the sender. IPv4 options are otherwise ignored without translation.
If the IPv4 DF flag is not set and the resulting IPv6 packet would exceed 1280 bytes, the IPv4 packet MUST be fragmented prior to translation so that each fragment's payload is at most 1232 bytes (1280 minus 40 for IPv6 header and 8 for Fragment header).
When a translator receives an unfragmented UDP IPv4 packet with a zero checksum field, it MUST compute the missing UDP checksum as part of translating the packet. The translator SHOULD also maintain a counter of how many UDP checksums are generated in this manner.
When a translator receives the first fragment of a fragmented UDP IPv4 packet with a zero checksum field, it SHOULD drop the packet and generate a system management event specifying at least the IP addresses and port numbers. Subsequent fragments with zero checksum SHOULD be silently dropped.
When translating an IPv4 packet with DF not set (or a fragment), the translator MUST always include an IPv6 Fragment header to indicate that the sender allows fragmentation. This is needed so that a subsequent IPv6-to-IPv4 translator knows not to set the DF flag.
ICMPv4 Destination Unreachable code translation to ICMPv6: codes 0/1 (net/host unreachable) → ICMPv6 code 0; code 2 (protocol unreachable) → ICMPv6 Parameter Problem (4/1) with Pointer to Next Header; code 3 (port unreachable) → code 4; code 4 (fragmentation needed) → Packet Too Big (Type 2) with MTU adjusted for header size difference. MTU plateau values from RFC 1191 used when IPv4 router omits MTU field.
ICMPv4-to-ICMPv6 type translation: Echo/Echo Reply (8/0) maps to 128/129; Destination Unreachable (3) maps to Type 1 with code translation; 'fragmentation needed' (3/4) maps to Packet Too Big (Type 2); Time Exceeded (11) maps to Type 3; Parameter Problem (12) maps to Type 4. Obsolete or single-hop ICMPv4 messages (Types 9, 10, 13–18, Source Quench, Redirect) are silently dropped.
ICMPv6-to-ICMPv4 type translation: Echo Request/Reply (128/129) maps to 0/8; Destination Unreachable (1) maps to Type 3 with code translation; Packet Too Big (2) maps to Destination Unreachable code 4 with MTU adjustment; Time Exceeded (3) maps to Type 11; Parameter Problem code 1 maps to protocol unreachable (3/2). Single-hop messages (MLD, Neighbor Discovery types 130–137) are silently dropped.
IPv4-mapped addresses (0::ffff:a.b.c.d) are used in IPv6 packets to refer to IPv4 nodes that are not IPv6-capable. When an IPv6-only node sends packets to an IPv4 node, it uses the IPv4-mapped address as the destination, which signals to the translator that translation is needed.
IPv4-translated addresses have the form 0::ffff:0:a.b.c.d (prefix 0::ffff:0:0:0/96) and refer to IPv6-enabled nodes. This new address form is distinct from IPv4-mapped and IPv4-compatible addresses and is used as the source address when an IPv6 node communicates through a SIIT translator.
ESP in transport mode is compatible with SIIT because ESP does not depend on header fields prior to the ESP header and the translator does not modify headers above the IP layer. ESP tunnel mode requires the IPv6 node to parse and generate inner IPv4 headers, making it more complex but potentially feasible.
SIIT does not introduce new security issues beyond those already present in IPv4, IPv6, and the routing protocols used to deliver packets to the translator. The security posture depends on the integrity of the routing that directs packets to the translator.
The IP Authentication Header (AH) does not work through a SIIT translator because AH covers the IPv4 Identification field, and an IPv6 endpoint cannot determine the value of the IPv4 Identification field used in packets sent by the IPv4 node, making AH verification impossible.
IPv4-to-IPv6 header translation maps Version to 6, Traffic Class from IPv4 TOS (8 bits), Flow Label to 0, Payload Length from IPv4 Total Length minus IPv4 header size, Next Header from IPv4 Protocol, Hop Limit from IPv4 TTL, Source Address to IPv4-mapped prefix (::ffff:0:0/96) with IPv4 source in low-order 32 bits, and Destination Address to IPv4-translated prefix (0::ffff:0:0:0/96) with IPv4 destination in low-order 32 bits.
IPv6-to-IPv4 header translation maps Version to 4, IHL to 5 (no options), TOS from IPv6 Traffic Class (8 bits), Total Length from IPv6 Payload Length plus 20, Identification to 0, DF flag set to 1, MF and Fragment Offset to 0, TTL from IPv6 Hop Limit, Protocol from IPv6 Next Header, Source Address from low-order 32 bits if IPv4-translated (else 0.0.0.0), and Destination Address from low-order 32 bits of IPv4-mapped destination.