RFC 6052

IPv6 Addressing of IPv4/IPv6 Translators

📅 published October 2010, from ietf

RFC 6052 💖 IPv6 Addressing of IPv4/IPv6 Translators

Okay bestie, let's start with the ID card 🎀. This is RFC 6052, titled IPv6 Addressing of IPv4/IPv6 Translators. It's a Standards Track document from the IETF, so it's an actual Internet standard in the making, not just vibes 💅. It's dated October 2010 and carries ISSN 2070-1721. It updates RFC 4291 📝.

Five people wrote it: C. Bao and X. Li from CERNET Center/Tsinghua University, C. Huitema from Microsoft Corporation, M. Bagnulo from UC3M, and M. Boucadair from France Telecom 🫶.

Abstract ✨

Okay so this doc is about turning an IPv6 address into its matching IPv4 address, and back again, using nothing but statically configured information 🦋. It sets up a well-known prefix for those algorithmic translations, but organizations can also use their own network-specific prefixes when that makes sense. The algorithm gets used in IPv4/IPv6 translators, and also in other proxies and gateways (DNS, for example) that show up in IPv4/IPv6 setups 🌈.

Status of This Memo 🌸

This is an Internet Standards Track document 🎀.

It's a product of the Internet Engineering Task Force (IETF), so 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 on Internet Standards, check Section 2 of RFC 5741 📚.

For the current status, any errata, and how to send feedback, go to http://www.rfc-editor.org/info/rfc6052 🔗.

Copyright (c) 2010 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) in effect on the date of publication of this document. Please read these carefully, because they describe your rights and restrictions for this document. Code Components extracted from 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 . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Applicability Scope  . . . . . . . . . . . . . . . . . . .  3
     1.2.  Conventions  . . . . . . . . . . . . . . . . . . . . . . .  4
     1.3.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  IPv4-Embedded IPv6 Address Prefix and Format . . . . . . . . .  5
     2.1.  Well-Known Prefix  . . . . . . . . . . . . . . . . . . . .  5
     2.2.  IPv4-Embedded IPv6 Address Format  . . . . . . . . . . . .  5
     2.3.  Address Translation Algorithms . . . . . . . . . . . . . .  7
     2.4.  Text Representation  . . . . . . . . . . . . . . . . . . .  7
   3.  Deployment Guidelines  . . . . . . . . . . . . . . . . . . . .  8
     3.1.  Restrictions on the Use of the Well-Known Prefix . . . . .  8
     3.2.  Impact on Inter-Domain Routing . . . . . . . . . . . . . .  8
     3.3.  Choice of Prefix for Stateless Translation Deployments . .  9
     3.4.  Choice of Prefix for Stateful Translation Deployments  . . 11
   4.  Design Choices . . . . . . . . . . . . . . . . . . . . . . . . 12
     4.1.  Choice of Suffix . . . . . . . . . . . . . . . . . . . . . 12
     4.2.  Choice of the Well-Known Prefix  . . . . . . . . . . . . . 13
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 14
     5.1.  Protection against Spoofing  . . . . . . . . . . . . . . . 14
     5.2.  Secure Configuration . . . . . . . . . . . . . . . . . . . 15
     5.3.  Firewall Configuration . . . . . . . . . . . . . . . . . . 15
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 15
   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
   8.  Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 16
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 17
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 17

1. Introduction ✨

Bestie, this doc is part of a whole series of IPv4/IPv6 translation documents 🦋. The framework lives in [v4v6-FRAMEWORK], which also has a taxonomy of scenarios this document uses. Other documents cover how different translators and gateways behave, including ways to translate between IP headers and other message types that carry IP addresses 💅.

What this one does is spell out how a single IPv6 address gets translated to its corresponding IPv4 address, and vice versa, whenever an algorithmic mapping is used 🧚. Specific devices show up as examples, but it's the job of each device's spec to reference this document for the address mapping itself 📌.

Section 2 covers the prefixes and the format of "IPv4-embedded IPv6 addresses", which are IPv6 addresses where 32 bits hold an IPv4 address 💜. That format works for both "IPv4-converted" and "IPv4-translatable" IPv6 addresses. The section also defines the translation algorithms and the text representation of IPv4-embedded IPv6 addresses 🌈.

Section 3 talks about choosing prefixes, when you're allowed to use them, and how IPv4-embedded IPv6 addresses work with stateless and stateful translation 🎀.

Section 4 summarizes the reasoning behind two specific design decisions: picking a null suffix, and the exact value of the chosen prefix 🍓.

Section 5 covers security concerns, and yes, they're serious 😭.

Heads up on one scenario: a dual-stack host might send its traffic through an IPv6/IPv4 translator when it doesn't need to 🙈. This can happen because of the host's default address selection algorithm [RFC3484], referrals, or other reasons. Optimizing this for dual-stack hosts is for future study 🔮.

1.1. Applicability Scope 🌸

This doc is part of a series defining address translation services 🦋. The address format could also be used by other ways of connecting IPv6 and IPv4, like methods based on encapsulation. If the IETF develops encapsulation methods, we expect their descriptions to document how they use IPv4-embedded IPv6 addresses 💅.

1.2. Conventions 💜

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119] 📖.

1.3. Terminology 🧚

This document uses the following terms 🎀:

  • Address translator: any entity that has to derive an IPv4 address from an IPv6 address or vice versa. This covers not only devices that do IPv4/IPv6 packet translation, but also other entities that manipulate addresses, like name resolution proxies (for example, DNS64 [DNS64]) and possibly other types of Application Layer Gateways (ALGs) 💅.
  • IPv4-converted IPv6 addresses: IPv6 addresses used to represent IPv4 nodes in an IPv6 network. They're a variant of IPv4-embedded IPv6 addresses and follow the format in Section 2.2 ✨.
  • IPv4-embedded IPv6 addresses: IPv6 addresses where 32 bits contain an IPv4 address. Their format is described in Section 2.2 🦋.
  • IPv4/IPv6 translator: an entity that translates IPv4 packets to IPv6 packets, and vice versa. It may do "stateless" translation, meaning no per-flow state is required, or "stateful" translation, meaning per-flow state gets created when the first packet in a flow arrives 🌈.
  • IPv4-translatable IPv6 addresses: IPv6 addresses assigned to IPv6 nodes for use with stateless translation. They're a variant of IPv4-embedded IPv6 addresses and follow the format in Section 2.2 💖.
  • Network-Specific Prefix: an IPv6 prefix that an organization assigns for use in algorithmic mapping. Options for it are discussed in Sections 3.3 and 3.4 🍓.
  • Well-Known Prefix: the IPv6 prefix this document defines for use in an algorithmic mapping 👑.

2. IPv4-Embedded IPv6 Address Prefix and Format 🧚

2.1. Well-Known Prefix 🌸

Okay, this is the fun part ✨. This document reserves a "Well-Known Prefix" for use in an algorithmic mapping. The value of this IPv6 prefix is:

   64:ff9b::/96

2.2. IPv4-Embedded IPv6 Address Format 🎀

okay so IPv4-converted IPv6 addresses and IPv4-translatable IPv6 addresses are literally twins 👯‍♀️ They follow the exact same format, which we call the IPv4-embedded IPv6 address Format 💅 An IPv4-embedded IPv6 address has three parts: a variable-length prefix, the embedded IPv4 address, and a variable-length suffix 🦋 Check out the diagram below, where PL means prefix length:

+--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
|PL| 0-------------32--40--48--56--64--72--80--88--96--104---------|
+--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
|32|     prefix    |v4(32)         | u | suffix                    |
+--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
|40|     prefix        |v4(24)     | u |(8)| suffix                |
+--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
|48|     prefix            |v4(16) | u | (16)  | suffix            |
+--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
|56|     prefix                |(8)| u |  v4(24)   | suffix        |
+--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
|64|     prefix                    | u |   v4(32)      | suffix    |
+--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
|96|     prefix                                    |    v4(32)     |
+--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

Figure 1

So the prefix is either the "Well-Known Prefix" or a "Network-Specific Prefix" that belongs to the organization running the address translators 🌸 The prefix lengths are limited to 32, 40, 48, 56, 64, or 96 ✨ (The Well-Known Prefix is 96 bits long, so it only fits in the last row of the table, the /96 one 🫶)

Different deployments pick different prefix lengths for their Network-Specific Prefixes 🧚 The trade-offs between those lengths are talked about in Sections 3.3 and 3.4, so go check those out!

Now, bits 64 to 71 are reserved so the address stays compatible with the host identifier format from the IPv6 addressing architecture [RFC4291] 😭 These bits MUST be set to zero. If you're using a /96 Network-Specific Prefix, the administrators MUST make sure bits 64 to 71 are set to zero too 🔥 An easy way to do this is to build your /96 Network-Specific Prefix by starting with a /64 prefix and then adding 4 octets that are all zero 💜

The IPv4 address goes right after the prefix, most significant bits first 🍓 Depending on the prefix length, the 4 octets of the address might get split up by the reserved octet "u", and that octet's 8 bits MUST be set to zero 💅 Here's how it works for each length:

  • When the prefix is 32 bits long, the IPv4 address is encoded in positions 32 to 63.
  • When the prefix is 40 bits long, 24 bits of the IPv4 address are encoded in positions 40 to 63, with the remaining 8 bits in position 72 to 79.
  • When the prefix is 48 bits long, 16 bits of the IPv4 address are encoded in positions 48 to 63, with the remaining 16 bits in position 72 to 87.
  • When the prefix is 56 bits long, 8 bits of the IPv4 address are encoded in positions 56 to 63, with the remaining 24 bits in position 72 to 95.
  • When the prefix is 64 bits long, the IPv4 address is encoded in positions 72 to 103.
  • When the prefix is 96 bits long, the IPv4 address is encoded in positions 96 to 127.

If the prefix is 96 bits long, there are no leftover bits, so there's no suffix at all 🙈 In every other case, whatever bits are left over make up the suffix. Those bits are reserved for future extensions, and they SHOULD be set to zero. If address translators get IPv4-embedded IPv6 addresses where these bits aren't zero, they SHOULD ignore the bits' value and act as if those bits were zero. (Future extensions may specify a different behavior 🦋)

2.3. Address Translation Algorithms 🧮

okay so building an IPv4-embedded IPv6 address goes like this 💖

  • Concatenate the prefix, the 32 bits of the IPv4 address, and the suffix (if needed) to get a 128-bit address.
  • If the prefix length is less than 96 bits, insert the null octet "u" at the right spot (bits 64 to 71), which means the least significant octet gets left out, just like Figure 1 shows 🌈

And pulling the IPv4 addresses back out of IPv4-embedded IPv6 addresses goes like this 🔍

  • If the prefix is 96 bits long, extract the last 32 bits of the IPv6 address.
  • For the other prefix lengths, remove the "u" octet to get a 120-bit sequence (this effectively shifts bits 72-127 over to positions 64-119), then extract the 32 bits that come right after the prefix.

2.4. Text Representation ✍️

IPv4-embedded IPv6 addresses get written out as text following Section 2.2 of [RFC4291] 💜 Addresses built with the Well-Known Prefix or a /96 Network-Specific Prefix can also use the alternative form from Section 2.2 of [RFC4291], where the embedded IPv4 address is written in dotted decimal notation 🌸 Examples are in Tables 1 and 2, bestie 👀

+-----------------------+------------+------------------------------+
| Network-Specific      |    IPv4    | IPv4-embedded IPv6 address   |
| Prefix                |   address  |                              |
+-----------------------+------------+------------------------------+
| 2001:db8::/32         | 192.0.2.33 | 2001:db8:c000:221::          |
| 2001:db8:100::/40     | 192.0.2.33 | 2001:db8:1c0:2:21::          |
| 2001:db8:122::/48     | 192.0.2.33 | 2001:db8:122:c000:2:2100::   |
| 2001:db8:122:300::/56 | 192.0.2.33 | 2001:db8:122:3c0:0:221::     |
| 2001:db8:122:344::/64 | 192.0.2.33 | 2001:db8:122:344:c0:2:2100:: |
| 2001:db8:122:344::/96 | 192.0.2.33 | 2001:db8:122:344::192.0.2.33 |
+-----------------------+------------+------------------------------+

Table 1: Text Representation of IPv4-Embedded IPv6 Addresses Using Network-Specific Prefixes

+-------------------+--------------+----------------------------+
| Well-Known Prefix | IPv4 address | IPv4-Embedded IPv6 address |
+-------------------+--------------+----------------------------+
| 64:ff9b::/96      |  192.0.2.33  | 64:ff9b::192.0.2.33        |
+-------------------+--------------+----------------------------+

Table 2: Text Representation of IPv4-Embedded IPv6 Addresses Using the Well-Known Prefix

The Network-Specific Prefix examples in Table 1 come from the IPv6 prefix reserved for documentation in [RFC3849] 📚 The IPv4 address 192.0.2.33 sits inside the subnet 192.0.2.0/24, which is reserved for documentation in [RFC5735] 🧸 And the way IPv6 addresses are represented here is compatible with [RFC5952] ✨

3. Deployment Guidelines 🗺️

3.1. Restrictions on the Use of the Well-Known Prefix 🚫

The Well-Known Prefix MUST NOT be used to represent non-global IPv4 addresses, like the ones defined in [RFC1918] or listed in Section 3 of [RFC5735] 😤 Address translators MUST NOT translate packets where an address is made of the Well-Known Prefix plus a non-global IPv4 address. They MUST drop these packets. Bye bye 👋

The Well-Known Prefix SHOULD NOT be used to build IPv4-translatable IPv6 addresses.

Okay, so the nodes behind IPv4-translatable IPv6 addresses should be able to receive global IPv6 traffic sent to their IPv4-translatable IPv6 address without any intermediate protocol translation 🦋 That only works if the specific prefix used to build those addresses is advertised in inter-domain routing. Advertising more specific prefixes derived from the Well-Known Prefix isn't supported, as Section 3.2 explains 🙃 So Network-Specific Prefixes SHOULD be used in these scenarios, as Section 3.3 explains 💖

The Well-Known Prefix MAY be used by organizations that deploy translation services, as Section 3.4 explains 🌈

3.2. Impact on Inter-Domain Routing 🌐

The Well-Known Prefix MAY show up in inter-domain routing tables, if service providers decide to offer IPv6-IPv4 interconnection services to peers 🫶 Advertising the Well-Known Prefix SHOULD be controlled by upstream and/or downstream service providers according to inter-domain routing policies, for example through configuration of BGP [RFC4271] ⭐ Organizations that advertise the Well-Known Prefix in inter-domain routing MUST be able to provide IPv4/IPv6 translation service.

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) [RFC4271]. Why? Because that leads to importing the IPv4 routing table into the IPv6 one, which introduces scalability issues for the global IPv6 routing table 💀 Administrators of BGP nodes SHOULD configure filters that discard advertisements of embedded IPv6 prefixes longer than the Well-Known Prefix 🔥

When the IPv4/IPv6 translation service relies on Network-Specific Prefixes, the IPv4-translatable IPv6 prefixes used in stateless translation MUST be advertised with proper aggregation to the IPv6 Internet 👑 Similarly, if translators are configured with multiple Network-Specific Prefixes, those prefixes MUST be advertised to the IPv6 Internet with proper aggregation too 🎀

3.3. Choice of Prefix for Stateless Translation Deployments ✨

okay so organizations can totally deploy translation services using stateless translation 🦋 in these setups, internal IPv6 nodes get IPv4-translatable IPv6 addresses so IPv4 nodes can reach them, and the addresses of those external IPv4 nodes show up as IPv4-converted IPv6 addresses 💖

Organizations deploying stateless IPv4/IPv6 translation SHOULD assign a Network-Specific Prefix to their IPv4/IPv6 translation service. IPv4-translatable and IPv4-converted IPv6 addresses MUST be constructed as specified in Section 2.2. IPv4-translatable IPv6 addresses MUST use the selected Network-Specific Prefix. Both IPv4-translatable IPv6 addresses and IPv4-converted IPv6 addresses SHOULD use the same prefix. 🎀

using the same prefix is giving efficiency 🔥 internal IPv6 nodes will take the most efficient paths to reach the nodes served by IPv4-translatable IPv6 addresses. like, if a node learns the IPv4 address of an internal target without knowing that the target is actually behind the same translator the node uses, the translation rules make sure the IPv6 address built with the Network-Specific Prefix is the same as the IPv4-translatable IPv6 address assigned to the target 🧚 then standard routing preference ("most specific match wins") delivers the IPv6 packets directly, so they don't have to go to the translators and bounce back the way they came 💅

the intra-domain routing protocol must be able to deliver packets to the nodes served by IPv4-translatable IPv6 addresses 😭 this might mean routing on some or all of the embedded IPv4 address bits. the security considerations in Section 5 need routers to check that IPv4-translatable IPv6 source addresses are valid, using some form of reverse path check 🔒

here's a little example of how stateless translation management works 🌸

We will consider an IPv6 network with the prefix 2001:db8:
122::/48.  The network administrator has selected the Network-
Specific Prefix 2001:db8:122:344::/64 for managing stateless IPv4/
IPv6 translation.  The IPv4-translatable address block for IPv4
subnet 192.0.2.0/24 is 2001:db8:122:344:c0:2::/96.  In this
network, the host A is assigned the IPv4-translatable IPv6 address
2001:db8:122:344:c0:2:2100::, which corresponds to the IPv4
address 192.0.2.33.  Host A's address is configured either
manually or through DHCPv6.

In this example, host A is not directly connected to the
translator, but instead to a link managed by a router R.  The
router R is configured to forward to A the packets bound to 2001:
db8:122:344:c0:2:2100::.  To receive these packets, R will
advertise reachability of the prefix 2001:db8:122:344:c0:2:2100::/
104 in the intra-domain routing protocol -- or perhaps a shorter
prefix if many hosts on link have IPv4-translatable IPv6 addresses
derived from the same IPv4 subnet.  If a packet bound to
192.0.2.33 reaches the translator, the destination address will be
translated to 2001:db8:122:344:c0:2:2100::, and the packet will be
routed towards R and then to A.

Let's suppose now that a host B of the same domain learns the IPv4
address of A, maybe through an application-specific referral.  If
B has translation-aware software, B can compose a destination
address by combining the Network-Specific Prefix 2001:db8:122:
344::/64 and the IPv4 address 192.0.2.33, resulting in the address
2001:db8:122:344:c0:2:2100::.  The packet sent by B will be
forwarded towards R, and then to A, avoiding protocol translation.

okay now the routing and reverse path checks are way more efficient when they're done on the combo of the prefix and the IPv4 address ✨ in theory routers can route on prefixes of any length, but in practice there may be routers where routing on prefixes longer than 64 bits is slower 🐢 routing efficiency isn't the only thing to think about though. orgs also need to consider how available the prefixes are, plus the potential impact of all-zero identifiers 🙈

if you use a /32 prefix, all the routing bits sit in the top 64 bits of the IPv6 address, which gives excellent routing properties 👑 buuut these prefixes may be hard to get, and giving a whole /32 to a small set of IPv4-translatable IPv6 addresses might feel wasteful 😩 also, a /32 prefix plus a zero suffix leads to an all-zero interface identifier, which is an issue we talk about in Section 4.1.

intermediate lengths like /40, /48, or /56 are more like compromises 🍓 only some of the IPv4 bits end up in the /64 prefixes. reverse path checks in particular might not be super efficient. reverse path checks limited to the most significant bits of the IPv4 address reduce the chance of spoofing external IPv4 addresses, but they'd let IPv6 nodes spoof internal IPv4-translatable IPv6 addresses 👀

so we're proposing a compromise 💜 it's based on using no more than 1/256th of an organization's IPv6 allocation for the IPv4/IPv6 translation service. for example, if the org is an Internet Service Provider with an allocated IPv6 prefix of /32 or shorter, the ISP could dedicate a /40 prefix to the translation service. an end site with a /48 allocation could dedicate a /56 prefix to it, or possibly a /96 prefix if all the IPv4-translatable IPv6 addresses are on the same link ✨

the recommended prefix length also depends on the deployment scenario 🦋 stateless translation can be used for Scenario 1, Scenario 2, Scenario 5, and Scenario 6 from [v4v6-FRAMEWORK]. here's what the prefix length recommendations are for each:

  • For Scenario 1 (an IPv6 network to the IPv4 Internet) and Scenario 2 (the IPv4 Internet to an IPv6 network), an ISP holding a /32 allocation SHOULD use a /40 prefix, and a site holding a /48 allocation SHOULD use a /56 prefix.
  • For Scenario 5 (an IPv6 network to an IPv4 network) and Scenario 6 (an IPv4 network to an IPv6 network), the deployment SHOULD use a /64 or a /96 prefix.

3.4. Choice of Prefix for Stateful Translation Deployments 🌈

orgs can also deploy translation services based on stateful translation technology 💅 an org can choose either a Network-Specific Prefix or the Well-Known Prefix for its stateful IPv4/IPv6 translation service.

when these services are in use, IPv6 nodes get standard IPv6 addresses, while IPv4 nodes are represented by IPv4-converted IPv6 addresses, as specified in Section 2.2 ✨

the stateful part creates a possible stability issue when the org deploys multiple translators 😬 if several translators use the same prefix, packets from the same connection might get routed to different translators as the internal routing state changes. you can dodge this either by giving different prefixes to different translators, or by making sure all the translators using the same prefix coordinate their state 🫶

stateful translation can be used in the scenarios defined in [v4v6-FRAMEWORK]. the Well-Known Prefix SHOULD be used in these scenarios, with two exceptions 💖

  • In all scenarios, the translation MAY use a Network-Specific Prefix, if that's deemed appropriate for management reasons.
  • The Well-Known Prefix MUST NOT be used for Scenario 3 (the IPv6 Internet to an IPv4 network), because that would mean using the Well-Known Prefix with non-global IPv4 addresses 🚫 so a Network-Specific Prefix (for example, a /96 prefix) MUST be used in that scenario.

4. Design Choices 🧚

the prefix we picked reflects two design choices: the null suffix and the specific value of the Well-Known Prefix 🍰 here's a quick summary of the discussions that led to those two choices.

4.1. Choice of Suffix 🔍

the address format described in Section 2.2 recommends a zero suffix. before we made that call, we looked at a few options: checksum neutrality, encoding a port range, and a value different than 0 🤔

for stateless translation, there'd be no need for the translator to recompute a one's complement checksum if both the IPv4-translatable and the IPv4-converted IPv6 addresses were built in a "checksum-neutral" way. that means the IPv6 addresses would have the same one's complement checksum as the embedded IPv4 address ✨ for stateful translation, though, checksum neutrality doesn't get rid of checksum computation during translation, since only one of the two addresses would be checksum neutral 😅 we thought about reserving 16 bits in the suffix to guarantee checksum neutrality, but we said no because it wouldn't help with stateful translation, and checksum neutrality can also be reached by picking the right Network-Specific Prefix, i.e., one whose one's complement checksum equals either 0 or 0xffff 💜

there have also been proposals to add a port-range feature to stateless translation 🎀 instead of mapping an IPv4 address to exactly one IPv6 prefix, the options would let several IPv6 nodes share an IPv4 address, with each node managing a different range of ports. if a port range extension is needed, it could be defined later, using bits currently reserved as null in the suffix.

when a /32 prefix is used, an all-zero suffix gives an all-zero interface identifier 🙃 we get that this conflicts with Section 2.6.1 of RFC4291, which says all zeroes are used for the subnet-router anycast address. but in our spec there's only one node with an IPv4-translatable IPv6 address in the /64 subnet, so the anycast meaning doesn't cause any confusion 🫧 so we decided to keep the null suffix for now. this issue doesn't exist for prefixes longer than 32 bits, like the /40, /56, /64, and /96 prefixes we recommend in Section 3.3 🌟

4.2. Choice of the Well-Known Prefix 💅

okay bestie, before we picked the Well-Known Prefix we had three options on the table 🧚 ✨

  • reuse the IPv4-mapped prefix, ::ffff:0:0/96, as specified in RFC 2765, Section 2.1;
  • request IANA to allocate a /32 prefix, or
  • request allocation of a new /96 prefix.

we weighed the pros and cons of all three before landing on the recommended /96 Well-Known Prefix 🎀

the big perk of the existing IPv4-mapped prefix is that it's already defined 💖 so reusing it would take minimal standardization work. but being already defined isn't automatically a win, because current implementations might have side effects 🙈 when they're handed the IPv4-mapped prefix, current versions of Windows and Mac OS generate IPv4 packets, but they won't send IPv6 packets. so if we used that prefix, those nodes couldn't support translation without being modified, and that would totally defeat the whole point of translation techniques 💀 so we ruled out the first choice and decided not to reuse the IPv4-mapped prefix, ::ffff:0:0/96.

a /32 prefix would have let the embedded IPv4 address fit inside the top 64 bits of the IPv6 address 👑 that would've made routing and load balancing easier when an organization deploys several translators. but destination-address-based load balancing might not be what you want, ngl 🙃 it also isn't compatible with Session Traversal Utilities for NAT (STUN) [RFC5389] in deployments with multiple stateful translators that each have a different pool of IPv4 addresses. STUN compatibility only happens if the translators manage the same pool of IPv4 addresses and can coordinate their translation state. and in that case there's no big advantage to using a /32 prefix instead of a /96 prefix, so the vibe shifts 🦋

per Section 2.2 of [RFC4291], in the legal textual representations of IPv6 addresses, dotted decimal can only appear at the end 🌸 the /96 prefix fits that rule perfectly. it enables dotted decimal notation without needing an update to [RFC4291] ✨ and this representation makes the address format easier to use and the log files easier to read. iykyk, readable logs are everything 📜💜

the prefix we recommend is also "checksum neutral" 🌈 the sum of the hexadecimal numbers 0064 and ff9b is ffff, which is a value equal to zero in one's complement arithmetic. so an IPv4-embedded IPv6 address built with this prefix has the same one's complement checksum as the embedded IPv4 address. absolutely iconic 😭🫶

5. Security Considerations ✨

5.1. Protection against Spoofing 🙈

okay this one is serious, so let's go 🔥 IPv4/IPv6 translators can be modeled as special routers. that means they face the same risks and can use the same mitigations 🛡️ (the discussion of generic threats to routers and their mitigations is beyond the scope of this document.) there is, however, a particular risk that comes directly from embedding IPv4 addresses in IPv6: address spoofing 💀

an attacker could use an IPv4-embedded IPv6 address as the source address of malicious packets. after translation, those packets appear to be IPv4 packets from the specified source, and the attacker might be really hard to track 😱 if this is left without mitigation, the attack would let malicious IPv6 nodes spoof arbitrary IPv4 addresses. not the vibe at all 💔

the mitigation is to implement reverse path checks and to verify throughout the network that packets are coming from an authorized location 🔒💖

5.2. Secure Configuration 🔐

the prefixes used for address translation are what IPv6 nodes use to send packets to IPv6/IPv4 translators 🧚 attackers could try to fool nodes, DNS gateways, and IPv4/IPv6 translators into using wrong values for these parameters. that could mean network disruption, denial of service, and possible information disclosure 😭 to mitigate these attacks, network administrators need to make sure the prefixes are configured in a secure way 🫶

the mechanisms for achieving secure configuration of prefixes are beyond the scope of this document 🦋

5.3. Firewall Configuration 🧱

many firewalls and other security devices filter traffic based on IPv4 addresses 👀 attackers could try to fool these firewalls by sending IPv6 packets to or from IPv6 addresses that translate to the filtered IPv4 addresses. if that attack works, traffic that was previously blocked might slip through the firewalls disguised as IPv6 packets 💀 in all such scenarios, administrators should make sure that packets sent to or from IPv4-embedded IPv6 addresses get the same filtering as packets sent directly to or from the embedded IPv4 addresses 💅 this is non-negotiable, periodt 🛑

the mechanisms for configuring firewalls and security devices to achieve this filtering are beyond the scope of this document 🌈

6. IANA Considerations 🎀

IANA has made the following changes in the "Internet Protocol Version 6 Address Space" registry located at http://www.iana.org. 🍓

OLD:

IPv6 Prefix Allocation       Reference    Note
----------- ---------------- ------------ ----------------
0000::/8    Reserved by IETF [RFC4291]    [1][5]

NEW:

IPv6 Prefix Allocation       Reference    Note
----------- ---------------- ------------ ----------------
0000::/8    Reserved by IETF [RFC4291]    [1][5][6]

[6] The "Well-Known Prefix" 64:ff9b::/96 used in an algorithmic
    mapping between IPv4 to IPv6 addresses is defined out of the
    0000::/8 address block, per RFC 6052.

7. Acknowledgements 🫶

many people in the BEHAVE WG contributed to the discussion that led to this document 🧚 including Andrew Sullivan, Andrew Yourtchenko, Ari Keranen, Brian Carpenter, Charlie Kaufman, Dan Wing, Dave Thaler, David Harrington, Ed Jankiewicz, Fred Baker, Hiroshi Miyata, Iljitsch van Beijnum, John Schnizlein, Keith Moore, Kevin Yin, Magnus Westerlund, Margaret Wasserman, Masahito Endo, Phil Roberts, Philip Matthews, Remi Denis-Courmont, Remi Despres, and William Waites. the legends 👑💖

Marcelo Bagnulo is partly funded by Trilogy, a research project supported by the European Commission under its Seventh Framework Program 🌍✨

8. Contributors 💜

the following individuals co-authored documents from which text has been incorporated, listed in alphabetical order 📚

    Dave Thaler
    Microsoft Corporation
    One Microsoft Way
    Redmond, WA  98052
    USA
    Phone: +1 425 703 8835
    EMail: dthaler@microsoft.com

    Fred Baker
    Cisco Systems
    Santa Barbara, California  93117
    USA
    Phone: +1-408-526-4257
    Fax:   +1-413-473-2403
    EMail: fred@cisco.com

    Hiroshi Miyata
    Yokogawa Electric Corporation
    2-9-32 Nakacho
    Musashino-shi, Tokyo  180-8750
    JAPAN
    EMail: h.miyata@jp.yokogawa.com

9. References 📖

9.1. Normative References

[RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
           Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC4291]  Hinden, R. and S. Deering, "IP Version 6 Addressing
           Architecture", RFC 4291, February 2006.

9.2. Informative References

[DNS64]    Bagnulo, M., Sullivan, A., Matthews, P., and I. Beijnum,
           "DNS64: DNS extensions for Network Address Translation
           from IPv6 Clients to IPv4 Servers", Work in Progress,
           October 2010.

[RFC1918]  Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
           E. Lear, "Address Allocation for Private Internets",
           BCP 5, RFC 1918, February 1996.

[RFC3484]  Draves, R., "Default Address Selection for Internet
           Protocol version 6 (IPv6)", RFC 3484, February 2003.

[RFC3849]  Huston, G., Lord, A., and P. Smith, "IPv6 Address Prefix
           Reserved for Documentation", RFC 3849, July 2004.

[RFC4271]  Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
           Protocol 4 (BGP-4)", RFC 4271, January 2006.

[RFC5389]  Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
           "Session Traversal Utilities for NAT (STUN)", RFC 5389,
           October 2008.

[RFC5735]  Cotton, M. and L. Vegoda, "Special Use IPv4 Addresses",
           BCP 153, RFC 5735, January 2010.

[RFC5952]  Kawamura, S. and M. Kawashima, "A Recommendation for IPv6
           Address Text Representation", RFC 5952, August 2010.

[v4v6-FRAMEWORK]
           Baker, F., Li, X., Bao, C., and K. Yin, "Framework for
           IPv4/IPv6 Translation", Work in Progress, August 2010.

Authors' Addresses 🦋

Congxiao Bao
CERNET Center/Tsinghua University
Room 225, Main Building, Tsinghua University
Beijing,   100084
China
Phone: +86 10-62785983
EMail: congxiao@cernet.edu.cn


Christian Huitema
Microsoft Corporation
One Microsoft Way
Redmond, WA  98052-6399
U.S.A.
EMail: huitema@microsoft.com


Marcelo Bagnulo
UC3M
Av. Universidad 30
Leganes, Madrid  28911
Spain
Phone: +34-91-6249500
EMail: marcelo@it.uc3m.es
URI:   http://www.it.uc3m.es/marcelo


Mohamed Boucadair
France Telecom
3, Av Francois Chateaux
Rennes  350000
France
EMail: mohamed.boucadair@orange-ftgroup.com


Xing Li
CERNET Center/Tsinghua University
Room 225, Main Building, Tsinghua University
Beijing,   100084
China
Phone: +86 10-62785983
EMail: xing@cernet.edu.cn

that's the whole RFC, bestie 🌈💖 we made it through the entire spec and every single requirement, address and reference is intact 👑✨

📦 where this page comes from