SIIT-DC: Stateless IP/ICMP Translation for IPv6 Data Center Environments
Extracted elements (24)
A Network-Specific Prefix (NSP) with a /96 prefix length is recommended over the Well-Known Prefix (64:ff9b::/96). A /96 NSP allows IPv4 addresses to be embedded in familiar dotted-quad notation within IPv6 text representations, simplifying ACL authoring. NSP also supports multi-instance deployments and inter-domain routing of the translation prefix.
BRs should be placed as close as possible to the direct path between IPv6 Service Addresses and end users to avoid RTT detour overhead (a distant BR adds 2× the detour latency). Implementing the BR as a logical function within the routers already handling native IPv6 traffic eliminates the need for dedicated hardware, separate network ports, and extra rack space.
IPv6 Atomic Fragments (a Fragmentation header on a non-fragmented packet, added when translating IPv4 DF=0 packets) are not useful in an IDC environment and it is recommended that BRs disable their generation. RFC 6145 permits this via an optional configuration function; RFC 6145bis is noted as deprecating this behavior entirely.
IPv6 Service Addresses are intentionally not required to be IPv4-translatable addresses. Requiring IPv4-translatable addresses would force the entire IPv6 infrastructure to treat translated IPv4 traffic as a special case, significantly increasing complexity and violating SIIT-DC's simplicity goals. Use of IPv4-translatable IPv6 Service Addresses is therefore discouraged.
SIIT-DC targets single-stack IPv6 operation rather than dual-stack to reduce operational complexity and address IPv4 exhaustion. Dual-stack runs two protocols with little ROI while large parts of the Internet remain IPv4-only and does not reduce IPv4 address consumption. Decommissioning SIIT-DC when IPv4 is finally retired requires only shutting off the BRs.
Stateless translation is chosen over stateful NAT64 because it enables line-rate performance with no per-flow state, per-packet ECMP load balancing between BRs, and high availability without state synchronization. The limiting factors are packets-per-second and bandwidth, not concurrent flow count.
The RFC 6052 algorithm embeds the full IPv4 client source address inside the IPv6 translation prefix, preserving it end-to-end through the IDC without any additional mechanism. Applications may optionally extract the embedded IPv4 address for geolocation, logging, and abuse handling.
Application-layer protocols that embed IP addresses in their payload (e.g., FTP) are incompatible with SIIT-DC translation. Such protocols can be supported by deploying an ER that reverses the BR's translations before packets reach the NAT-incompatible application. Protocols that work through standard NAT44 will generally work through SIIT-DC.
For TCP, the 20-byte IPv4-to-IPv6 header size increase is automatically handled: the IPv6 node advertises an MSS of 1440 bytes during the handshake, preventing IPv4 clients from sending 1500-byte packets that would require fragmentation after translation. Non-TCP transports require either raising the path MTU to the BR to 1520 bytes or accepting BR-side fragmentation.
SIIT-DC can be combined with DNS64 (RFC 6147) to allow IPv6-only applications to initiate communication with IPv4-only nodes. However, outgoing traffic must be sourced from an IPv6 Service Address covered by an EAM in the BR; otherwise the BR cannot translate the source to IPv4 and will discard the packet. Modifying the Default Address Selection Policy Table (RFC 6724) on the node can enforce this.
SIIT-DC is fully compatible with dual-stack infrastructure, enabling incremental migration: designate the existing native IPv6 address as the IPv6 Service Address, assign a corresponding IPv4 Service Address, update the 'IN A' DNS record to point to the new IPv4 Service Address, and reclaim the old native IPv4 address once all traffic has migrated.
When an IPv6 node receives an ICMPv6 Packet Too Big error with an MTU below 1280, it must emit atomic fragments. The BR's 'second approach' from RFC 6145 Section 6 prevents this by clamping translated ICMPv6 Packet Too Big values to a minimum of 1280, and sets DF=0 on translated IPv4 packets ≤1280 bytes so IPv4 routers handle fragmentation instead.
A SIIT-DC Border Relay MUST perform stateless IP/ICMP translation in accordance with RFC 6145 and RFC 7757.
If a Network-Specific Prefix from the provider's own address space is used as the translation prefix, care MUST be taken in front of services with application-level ACLs that distinguish internal from Internet traffic, as translated IPv4 Internet traffic may appear to originate from the provider's own network.
If the path MTU between the BR and IPv6 nodes is increased to 1520 bytes, the MTU on IPv6 nodes themselves SHOULD NOT be increased accordingly, as doing so would trigger Path MTU Discovery toward all IPv6 Internet destinations. Nodes MUST, however, be able to accept and process incoming packets larger than their own MTU.
MTU and fragmentation differences between IPv4 and IPv6 MUST be considered when deploying SIIT-DC. The recommendations in Section 4.9 seek to minimize IPv6 fragmentation, which operators may find undesired or operationally impossible.
To facilitate reliable delivery of ICMPv6 errors generated within the IDC in response to translated IPv4 packets, an SIIT-DC operator SHOULD implement RFC 6791 recommendations in the BRs, since such ICMPv6 errors are otherwise likely to be discarded.
An Explicit Address Mapping (EAM) is a bidirectional coupling between an IPv4 Service Address and an IPv6 Service Address configured on a BR or ER. When translating, the BR/ER rewrites address fields according to a matching EAM; the algorithm is specified in RFC 7757.
IPv4-to-IPv6 translation maps the client's IPv4 source address into the translation prefix (e.g., 203.0.113.50 becomes 2001:db8:46::203.0.113.50) and replaces the IPv4 destination Service Address with the corresponding IPv6 Service Address via EAM lookup. IPv6-to-IPv4 translation is the reverse operation.
Multiple BRs may be deployed simultaneously, but all must share the same translation prefix and an identical EAM Table. This enables per-packet ECMP load balancing and stateless high availability: if one BR fails, routing protocols automatically redirect traffic to an alternate BR without disrupting existing flows beyond normal IP rerouting.
The SIIT-DC Border Relay (BR) is a device or logical function that performs stateless IP/ICMP translation between IPv4 and IPv6. It sits at the boundary between the IPv4 Internet and the IPv6-only IDC network, translating packets in both directions using EAMs and the translation prefix.
The SIIT-DC Edge Relay (ER) is an optional device or logical function that provides seemingly native IPv4 connectivity to IPv4-only applications or nodes deep inside the IPv6 IDC. It reverses the BR's translations before packets reach NAT-incompatible or IPv4-dependent components.
The Translation Prefix is an IPv6 prefix into which the entire IPv4 address space is mapped per the RFC 6052 algorithm. It is routed to the BR's IPv6 interface; addresses without a matching EAM are translated by inserting or removing this prefix.
When a Network-Specific Prefix from the provider's own address space is the translation prefix, translated IPv4 Internet traffic may appear to application-level ACLs as originating from the provider's own network. The translation prefix must be treated the same as the Internet at large. Using a prefix distinct from and not a subset of any internal network prefix mitigates this risk.