IPv6 Addressing of IPv4/IPv6 Translators
updates
- rfc-4291 — IP Version 6 Addressing Architecture
Extracted elements (20)
A null (all-zero) suffix was chosen over checksum-neutral or port-range-encoding suffixes. Checksum neutrality in the suffix only helps stateless translation (not stateful), and can alternatively be achieved by choosing a Network-Specific Prefix whose one's complement checksum equals 0 or 0xffff. Port-range bits are left reserved for possible future extension.
The /96 prefix length was chosen because it permits dotted decimal notation for the embedded IPv4 address per RFC 4291 without requiring an update to that specification. Additionally, the selected prefix 64:ff9b::/96 is checksum neutral: the sum of 0x0064 and 0xff9b equals 0xffff, which is zero in one's complement arithmetic.
The /96 Well-Known Prefix 64:ff9b::/96 was chosen over reusing the IPv4-mapped prefix (::ffff:0:0/96) and over requesting a /32 prefix. The IPv4-mapped prefix was rejected because current Windows and Mac OS implementations generate IPv4 packets—not IPv6—when encountering it, defeating the purpose of translation. A /32 was rejected partly due to STUN incompatibility in multi-translator stateful deployments.
When multiple stateful translators share the same prefix, packets from the same connection may be routed to different translators as internal routing state changes, breaking the connection. This can be avoided either by assigning different prefixes to different translators or by ensuring all translators sharing a prefix coordinate their per-flow state.
Current versions of Windows and Mac OS, when presented with an IPv4-mapped prefix (::ffff:0:0/96), generate IPv4 packets rather than IPv6 packets. Reusing that prefix for translation would therefore prevent these hosts from participating in translation-based connectivity without modification.
Bits 64 to 71 of an IPv4-embedded IPv6 address are reserved for compatibility with the IPv6 host identifier format and MUST be set to zero. When using a /96 Network-Specific Prefix, administrators MUST ensure bits 64–71 are zero.
Organizations advertising the Well-Known Prefix in inter-domain routing MUST be able to provide IPv4/IPv6 translation service. When using Network-Specific Prefixes in stateless translation, those prefixes MUST be advertised with proper aggregation to the IPv6 Internet.
Organizations deploying stateless IPv4/IPv6 translation SHOULD assign a Network-Specific Prefix to their service. IPv4-translatable and IPv4-converted IPv6 addresses MUST be constructed as specified in Section 2.2, and SHOULD use the same prefix to enable optimal intra-domain routing without translator involvement.
The suffix bits (remaining bits after prefix and embedded IPv4 address) are reserved for future extensions and SHOULD be set to zero. Translators receiving IPv4-embedded IPv6 addresses where suffix bits are not zero SHOULD ignore those bits and proceed as if they were zero.
The Well-Known Prefix MUST NOT be used for Scenario 3 (the IPv6 Internet to an IPv4 network) in stateful translation deployments, because this would combine the Well-Known Prefix with non-global IPv4 addresses. A Network-Specific Prefix (e.g., /96) MUST be used in that scenario.
The Well-Known Prefix SHOULD NOT be used to construct IPv4-translatable IPv6 addresses, because more-specific prefixes derived from it cannot be advertised in inter-domain routing. Network-Specific Prefixes SHOULD be used in stateless translation scenarios instead.
When IPv4/IPv6 translation relies on the Well-Known Prefix, IPv4-embedded IPv6 prefixes longer than the Well-Known Prefix MUST NOT be advertised in BGP (especially External BGP), as this would import the IPv4 routing table into IPv6 and introduce scalability issues. BGP nodes SHOULD configure filters discarding such advertisements.
Address translation algorithm: to encode, concatenate prefix, 32-bit IPv4 address, and suffix, then insert the null 'u' octet at bits 64–71 if prefix length is less than 96. To decode, for /96 extract the last 32 bits; for shorter prefixes, remove the 'u' octet to get a 120-bit sequence then extract the 32 bits following the prefix.
IPv4-embedded IPv6 addresses using the Well-Known Prefix or a /96 Network-Specific Prefix may be represented in dotted decimal notation per RFC 4291 Section 2.2, e.g., 64:ff9b::192.0.2.33. Other prefix lengths require standard hex notation.
The Well-Known Prefix for IPv4/IPv6 algorithmic address translation is 64:ff9b::/96. It is 96 bits long and may only be used in the form where the IPv4 address occupies the last 32 bits of the IPv6 address.
IANA updated the 'Internet Protocol Version 6 Address Space' registry to add a note for the 0000::/8 block documenting that the Well-Known Prefix 64:ff9b::/96 is defined from within that block per RFC 6052 for use in algorithmic IPv4-to-IPv6 address mapping.
An attacker could use an IPv4-embedded IPv6 address as a source address; after translation the packet appears as an IPv4 packet from the spoofed source, making the attacker hard to track. The mitigation is to implement reverse path checks and verify throughout the network that packets originate from authorized locations.
Attackers could attempt to configure nodes, DNS gateways, and translators with wrong prefix values, leading to network disruption, denial of service, or information disclosure. Network administrators must ensure translation prefixes are configured securely, though the specific mechanisms are out of scope.
Firewalls that filter based on IPv4 addresses may be bypassed by IPv6 packets carrying IPv4-embedded IPv6 addresses that translate to filtered IPv4 addresses. Administrators must ensure that packets to/from IPv4-embedded IPv6 addresses are subject to the same filtering as packets to/from the embedded IPv4 addresses directly.
IPv4-embedded IPv6 addresses consist of a variable-length prefix (32, 40, 48, 56, 64, or 96 bits), the 32-bit embedded IPv4 address, a reserved 'u' octet (bits 64–71, MUST be zero) inserted when prefix length is less than 96, and a variable-length suffix. The IPv4 address spans bits split around the 'u' octet for prefix lengths 40, 48, and 56.