RFC 8215

Local-Use IPv4/IPv6 Translation Prefix

📅 published August 2017, from ietf

RFC 8215 🎀

Local-Use IPv4/IPv6 Translation Prefix 🦋

Okay bestie, this is RFC 8215, and it's giving Standards Track energy ✨. T. Anderson from Redpill Linpro wrote it, it's dated August 2017, and its ISSN is 2070-1721 💜. It doesn't list anything it obsoletes or updates, so it's a fully standalone main character 👑.

Abstract 💖

This document reserves the IPv6 prefix 64:ff9b:1::/48 for local use within domains that enable IPv4/IPv6 translation mechanisms.

Status of This Memo 📜

This is an Internet Standards Track document, so it's officially a big deal 🔥.

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It went through public review and got approved for publication by the Internet Engineering Steering Group (IESG). If you want more info on Internet Standards, check out Section 2 of RFC 7841 🌸.

For the current status of this document, any errata, and how to give feedback on it, go to http://www.rfc-editor.org/info/rfc8215 🧚.

Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stand on the date this document was published. Please read these carefully, bestie, because they spell out your rights and restrictions for this document 🙈. Code Components pulled out of this document must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as described in the Simplified BSD License 💅.

Table of Contents 🌈

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   2
   3.  Problem Statement . . . . . . . . . . . . . . . . . . . . . .   2
   4.  Why 64:ff9b:1::/48? . . . . . . . . . . . . . . . . . . . . .   3
     4.1.  Prefix Length . . . . . . . . . . . . . . . . . . . . . .   3
     4.2.  Prefix Value  . . . . . . . . . . . . . . . . . . . . . .   4
   5.  Deployment Considerations . . . . . . . . . . . . . . . . . .   4
   6.  Checksum Neutrality . . . . . . . . . . . . . . . . . . . . .   5
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   6
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .   6
     9.2.  Informative References  . . . . . . . . . . . . . . . . .   7
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .   7
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   7

1. Introduction 🦋

This document reserves 64:ff9b:1::/48 for local use within domains that enable IPv4/IPv6 translation mechanisms. This is the coexistence glow-up ✨: multiple IPv4/IPv6 translation mechanisms can live together in the same network, and nobody has to borrow a Network-Specific Prefix from the operator's allocated global unicast address space 💖.

2. Terminology 📚

This document uses the following terms:

  • Network-Specific Prefix (NSP): a globally unique prefix assigned by a network operator for use with an IPv4/IPv6 translation mechanism [RFC6052].
  • Well-Known Prefix (WKP): the prefix 64:ff9b::/96, which is reserved for use with the [RFC6052] IPv4/IPv6 address translation algorithms 🍓.

3. Problem Statement 🌸

Okay, so the WKP 64:ff9b::/96 was reserved by [RFC6052], and then a bunch of new IPv4/IPv6 translation mechanisms got defined by the IETF, like the ones in [RFC6146] and [RFC7915]. They're built for totally different use cases, so an operator might want to run several of them at once 💅.

The WKP is reserved specifically for the algorithms in [RFC6052]. Newer RFCs describe translation mechanisms that use different algorithms, and an operator deploying those can't legitimately use the WKP 🙈.

Also, the WKP is a /96. So an operator who prefers the WKP over an NSP can only give it to one of their IPv4/IPv6 translation mechanisms. Every other one has to use an NSP 😭.

Section 3.1 of [RFC6052] puts certain restrictions on using the WKP, like forbidding its use together with private IPv4 addresses [RFC1918]. Those restrictions might clash with what the operator actually wants to do with a translation mechanism 💀.

Basically, the network needs a local-use prefix that lets multiple IPv4/IPv6 translation mechanisms coexist in one network domain, and that also works for translation mechanisms that don't use the [RFC6052] algorithms or follow its usage restrictions 🫶.

4. Why 64:ff9b:1::/48? 🔥

4.1. Prefix Length 📏

The big goal here is letting multiple translation mechanisms run at the same time in one network. So the first criterion is that the prefix length chosen must be shorter than the prefix length used by any individual translation mechanism 👑.

The second criterion is that the prefix length chosen is a multiple of 16. That way the prefix ends on a colon boundary when it's written out as text, which makes it way easier for operators to deal with 🧚.

The [RFC6052] algorithms specifies IPv4/IPv6 translation prefixes as short as /32. To fit multiple translation mechanisms using /32s, while still lining up on a 16-bit boundary, you'd need to reserve a /16. The IPv6 Operations Working Group said that was too wasteful, though 😭.

The shortest translation prefix reported to the IPv6 Operations Working Group as being deployed in a live network was /64. The longest 16-bit-aligned prefix length that can fit multiple instances of /64 is /48. So /48 was chosen, because it meets both criteria above and still doesn't waste too much of the IPv6 address space 🌈.

4.2. Prefix Value 🦋

We want to keep the extra "pollution" in the unallocated IPv6 address space, caused by this reservation, as small as possible. Putting the reserved prefix right next to the WKP 64:ff9b::/96 that [RFC6052] already reserved does exactly that 💖.

With a prefix length of /48 decided, that leaves two options: 64:ff9a:ffff::/48 and 64:ff9b:1::/48 🍓.

64:ff9a:ffff::/48 is totally adjacent to the [RFC6052] WKP. 64:ff9a:ffff::/48 and 64:ff9b::/96 combine into one uninterrupted range of IPv6 addresses, starting at 64:ff9a:ffff:: and ending at 64:ff9b::ffff:ffff ✨.

64:ff9b:1::/48 is not completely adjacent to 64:ff9b::/96, though. The range starting at 64:ff9b::1:0:0 and ending at 64:ff9b:0:ffff:ffff:ffff:ffff:ffff would stay unallocated 🙈.

That drawback is balanced out, though, by the fact that the smallest aggregate prefix covering both the [RFC6052] WKP and 64:ff9a:ffff::/48 is way bigger than the smallest aggregate prefix covering both the [RFC6052] WKP and 64:ff9b:1::/48. Those aggregates are 64:ff9a::/31 and 64:ff9b::/47, respectively 🔥. IPv6 address space gets allocated in prefixes, not address ranges, so you could argue that 64:ff9b:1::/48 is the option that makes special-use prefixes reserved for IPv4/IPv6 translation "pollute" the least possible amount of unallocated IPv6 address space 🧠.

Finally, 64:ff9b:1::/48 has the advantage that its text form is shorter than 64:ff9a:ffff::/48. It might seem small, but human network operators really like addresses that are easy to type, and that shouldn't be underestimated 💅.

After weighing the pros and cons above, 64:ff9b:1::/48 was chosen. ✨👑

7. IANA Considerations ✨

okay so IANA (the folks who keep the official Internet registries tidy 🧚) has added a brand new entry to the "IANA IPv6 Special-Purpose Address Registry" 💅 here's what it looks like:

+----------------------+---------------------+
| Attribute            | Value               |
+----------------------+---------------------+
| Address Block        | 64:ff9b:1::/48      |
| Name                 | IPv4-IPv6 Translat. |
| RFC                  | RFC 8215            |
| Allocation Date      | 2017-06             |
| Termination Date     | N/A                 |
| Source               | True                |
| Destination          | True                |
| Forwardable          | True                |
| Globally Reachable   | False               |
| Reserved-by-Protocol | False               |
+----------------------+---------------------+

and IANA also slid a footnote into the 0000::/8 entry of the "Internet Protocol Version 6 Address Space" registry 🦋

64:ff9b:1::/48 reserved for Local-Use IPv4/IPv6 Translation
[RFC8215].

8. Security Considerations 🔥

okay this one is serious bestie 😭 the reservation of 64:ff9b:1::/48 is not known to cause any new security considerations beyond those documented in Section 5 of [RFC6052]. so no fresh security drama from this block itself, but you still need to read Section 5 of [RFC6052] 🫶

9. References 📚

9.1. Normative References 💜

[RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, DOI 10.17487/RFC6052, October 2010, <https://www.rfc-editor.org/info/rfc6052>.

9.2. Informative References 🌸

[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, <https://www.rfc-editor.org/info/rfc1918>.

[RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, April 2011, <https://www.rfc-editor.org/info/rfc6146>.

[RFC7915] Bao, C., Li, X., Baker, F., Anderson, T., and F. Gont, "IP/ICMP Translation Algorithm", RFC 7915, DOI 10.17487/RFC7915, June 2016, <https://www.rfc-editor.org/info/rfc7915>.

Acknowledgements 🫶

The author would like to thank Fred Baker, Mohamed Boucadair, Brian E. Carpenter, Pier Carlo Chiodi, Joe Clarke, David Farmer, Suresh Krishnan, Warren Kumari, Holger Metschulat, Federico Santandrea, and David Schinazi for contributing to the creation of this document. the whole squad helped make this happen, iconic ✨

Author's Address 💌

Tore Anderson Redpill Linpro Vitaminveien 1A 0485 Oslo Norway

Phone: +47 959 31 212 Email: tore@redpill-linpro.com URI: http://www.redpill-linpro.com

📦 where this page comes from