Local-Use IPv4/IPv6 Translation Prefix
Extracted elements (11)
64:ff9b:1::/48 was chosen over the alternative 64:ff9a:ffff::/48 because it yields a smaller aggregate prefix (64:ff9b::/47 vs. 64:ff9a::/31) when combined with the WKP 64:ff9b::/96, minimizing pollution of unallocated IPv6 address space. Its shorter textual representation was also a factor.
A /48 prefix length was chosen because it is the longest 16-bit-aligned prefix that can accommodate multiple instances of /64 translation prefixes (the shortest observed in live deployments). A /16 would have accommodated /32 prefixes but was deemed too wasteful by the IPv6 Operations Working Group.
The WKP 64:ff9b::/96 is restricted to RFC 6052 algorithms and forbids use with private IPv4 addresses (RFC 1918). Operators using newer mechanisms (RFC 6146, RFC 7915) or multiple simultaneous translation mechanisms cannot legitimately reuse the WKP, motivating the need for a separate local-use prefix.
64:ff9b:1::/48 is distinct from the WKP 64:ff9b::/96. The restrictions on the WKP described in RFC 6052 Section 3.1 — including the prohibition on use with private IPv4 addresses (RFC 1918) — do not apply to 64:ff9b:1::/48.
Operators must not use the aggregate prefix 64:ff9b::/47 to refer to all special-use prefixes for IPv4/IPv6 translation, as this aggregate covers an unallocated range (64:ff9b::1:0:0 through 64:ff9b:0:ffff:ffff:ffff:ffff:ffff) that the IETF could reserve in the future for entirely different purposes.
Use of 64:ff9b:1::/48 does not guarantee checksum neutrality, as many IPv4/IPv6 translation algorithms are fundamentally incompatible with it. When using RFC 7915 (SIIT) with RFC 6052 algorithms, operators must select a /96 sub-prefix whose six 16-bit words sum to a multiple of 0xffff. Example checksum-neutral sub-prefixes include 64:ff9b:1:fffe::/96 and 64:ff9b:1:fffd:1::/96.
64:ff9b:1::/48 or any more-specific prefix may only be used in inter-domain routing if done in accordance with the rules described in Section 3.2 of RFC 6052; its use in inter-domain routing is otherwise prohibited.
By default, IPv6 nodes and applications must not treat IPv6 addresses within 64:ff9b:1::/48 differently from other globally scoped IPv6 addresses. In particular, they must not make any assumptions regarding the syntax or properties of those addresses (e.g., embedded IPv4 addresses) or the type of translation mechanism involved.
The IPv6 prefix 64:ff9b:1::/48 is reserved for local use within network domains that enable IPv4/IPv6 translation mechanisms. It is technology-agnostic and may be used with any kind of IPv4/IPv6 translation mechanism deployed within the operator's network.
IANA added 64:ff9b:1::/48 to the 'IANA IPv6 Special-Purpose Address Registry' with Name='IPv4-IPv6 Translat.', Allocation Date=2017-06, Source=True, Destination=True, Forwardable=True, Globally Reachable=False, Reserved-by-Protocol=False. A footnote was also added to the 0000::/8 entry of the 'Internet Protocol Version 6 Address Space' registry.
The reservation of 64:ff9b:1::/48 is not known to cause any new security considerations beyond those documented in Section 5 of RFC 6052, which addresses security aspects of IPv4/IPv6 translation mechanisms.