Stateless IP/ICMP Translation for IPv6 Internet Data Center Environments (SIIT-DC): Dual Translation Mode
Extracted elements (23)
A node-based ER is similar to the 'Bump-in-the-Stack' (BIH) approach from RFC 6535, but deliberately omits an Extension Name Resolver component, keeping the ER focused solely on packet-level translation without DNS interference.
For intra-IDC IPv4 communication, adding extra EAMs directly in the ER (Section 5.2) avoids traversing the BR entirely, yielding lower latency than hairpinning (Section 5.1). The two approaches are mutually compatible: EAMs can appear on both ER and BR simultaneously.
The IPv4 Identification header is of limited practical importance (few application protocols use it beyond diagnostics), so its loss when Atomic Fragments are disabled is generally acceptable. Operators who need end-to-end preservation must enable Atomic Fragment generation on both BR and ER.
The IPv4 MTU is set to IPv6 Path MTU minus 20 bytes (the size of the IPv4-to-IPv6 header increase) so that a maximum-sized IPv4 packet fits within an unfragmented IPv6 packet, allowing application-layer segmentation (e.g., TCP MSS) to prevent IP-level fragmentation in the ER-to-BR path.
The 'on a stick' network-based ER variant connects both IPv4 and IPv6 interfaces to the same network segment so that dual-stack nodes retain native IPv6 connectivity while still benefiting from IPv4 translation. Native IPv6 traffic bypasses the ER entirely; only IPv4 traffic is routed through it.
The SIIT-DC Dual Translation (ER) architecture is explicitly an adaptation of 464XLAT (RFC 6877) to an Internet Data Center environment, providing end-to-end IPv4 address transparency for applications, protocols, or nodes incompatible with IPv6 or NAT. The ER restores the native IPv4 illusion that standard SIIT-DC cannot provide for NAT-incompatible protocols.
Intra-IDC hairpinning (Section 5.1) requires the BR to support the hairpinning behavior defined in Section 4.2 of RFC 7757. If the BR does not support hairpinning, operators must use the direct EAM approach described in Section 5.2 instead.
Private IPv4 addresses (RFC 1918) may be used as IPv4 Service Addresses for nodes or services that do not need public IPv4 Internet reachability, conserving the IDC operator's pool of public IPv4 addresses. Alternatively, the IPv4 Service Continuity Prefix (RFC 7335) may be used for addresses with only local significance behind an ER.
When using a network-based ER with a shared IPv4 prefix (Appendix A.1), other SIIT-DC services assigned IPv4 Service Addresses within the same prefix become unreachable from behind the ER, because downstream nodes ARP for them on-link instead of routing through the ER. Operators must either avoid prefix overlap or use the unrouted private address approach in Appendix A.2.
All EAMs configured in the BR that involve the IPv4/IPv6 Service Addresses handled by a given ER MUST also be present in that ER's configuration, ensuring bidirectional address translation consistency.
An ER SHOULD ensure that the IPv4 MTU presented to applications or downstream nodes equals the configured IPv6 Path MTU minus 20 bytes, preventing IPv6 fragmentation. A node-based ER sets this on the virtual adapter; a network-based ER advertises it via the DHCPv4 Interface MTU option (RFC 2132).
Each node on a network-based ER's IPv4 segment MUST acquire and assign an IPv4 Service Address to a local network interface. The document notes DHCPv4 or static assignment are both possible methods.
For a node-based ER, the IPv6 network MUST forward traffic destined for the ER's IPv6 Service Addresses to the node, and the node's operating system MUST in turn forward those packets to the ER. One method is assigning these as secondary IPv6 addresses so the upstream router learns of them via IPv6 Neighbor Discovery (RFC 4861).
It is RECOMMENDED that the IPv6 Path MTU configured in the ER be raised above the RFC 6145 default of 1280 bytes, since the ER-to-BR path typically resides within a single administrative domain. It is further RECOMMENDED that the ER and BR use identical configured IPv6 Path MTU values.
It is RECOMMENDED to use a node-based ER rather than a network-based ER when nodes are dual-stack capable, since the network-based ER would unnecessarily deprive those nodes of native IPv6 connectivity.
The SIIT-DC Border Relay MUST implement stateless protocol translation in accordance with RFC 6145 (IP/ICMP Translation Algorithm) and RFC 7757 (Explicit Address Mappings).
To preserve the IPv4 Identification header end-to-end, IPv6 Atomic Fragment generation MUST be enabled on both the BR and the ER. If Atomic Fragment generation is disabled on either, the IPv4 Identification value is lost during translation.
When using Additional EAMs for intra-IDC communication and the target service is located behind another ER, that other ER MUST be provisioned with an additional EAM containing the IPv4 and IPv6 Service Addresses of the originating node; otherwise the target ER cannot translate the incoming packet's source address.
A network-based Edge Relay forwards IPv4 Service Address traffic onto an IPv4 network segment and acts as the default IPv4 router for nodes on that segment. It has three sub-variants: basic IPv4-only segment, 'on a stick' (single dual-stack interface passes IPv6 natively while translating IPv4), and IPv6-bridging (transparently bridges IPv6 while intercepting IPv6 Service Address traffic for translation).
A node-based Edge Relay is implemented as a logical software function running inside an IPv6 node's operating system. It assigns the IPv4 Service Address to a virtual network adapter and installs a default IPv4 route, providing AF_INET socket connectivity for applications. Native IPv6 connectivity is unaffected and coexists.
The SIIT-DC Edge Relay (ER) is a device or logical function that provides 'native' IPv4 connectivity to IPv4-only devices or application software by implementing the Stateless IP/ICMP Translation Algorithm (RFC 6145) with Explicit Address Mapping (EAM) support. It reverses translations made by the Border Relay (BR) for inbound traffic and re-translates IPv4 to IPv6 for outbound traffic. It may be either node-based or network-based.
If the ER receives an IPv4 packet from a source address for which no EAM exists, both source and destination will be rewritten using the translation prefix per RFC 6052, resulting in a spoofed IPv4 source address after the BR reverses the translation. The ER SHOULD apply ingress filtering (RFC 2827) on its IPv4 interface to immediately discard such packets.
If the ER receives an IPv6 packet whose source address equals one of its own local IPv6 Service Addresses (or translates to a local IPv4 Service Address), the IPv4-only application would receive a packet appearing to originate from itself, potentially trusting it as locally generated. The ER SHOULD discard any received IPv6 packets with such source addresses.