RFC 7600
IPv4 Residual Deployment via IPv6 - A Stateless Solution (4rd)
RFC 7600: IPv4 Residual Deployment via IPv6, A Stateless Solution (4rd) 🎀
Part 1 of 10, more parts coming! 💖
okay bestie, the title block is giving everything we need. This is an Experimental doc from July 2015 📅. It was written by R. Despres (RD-IPtech), with S. Jiang as editor (Huawei Technologies Co., Ltd), R. Penno (Cisco Systems, Inc.), Y. Lee (Comcast), G. Chen (China Mobile), and M. Chen (BBIX, Inc.). The ISSN is 2070-1721. The header doesn't say it obsoletes or updates anything, so it stands on its own ✨
Internet Engineering Task Force (IETF) R. Despres
Request for Comments: 7600 RD-IPtech
Category: Experimental S. Jiang, Ed.
ISSN: 2070-1721 Huawei Technologies Co., Ltd
R. Penno
Cisco Systems, Inc.
Y. Lee
Comcast
G. Chen
China Mobile
M. Chen
BBIX, Inc.
July 2015Abstract
This doc lays out a stateless way for service providers to slowly move their networks over to IPv6-only domains while customers still get IPv4 🦋 The best part is that TCP/UDP IPv4 packets are still valid TCP/UDP IPv6 packets while they cross the domain, and IPv4 fragmentation rules stay fully intact end to end 🔥 Each customer can get one public IPv4 address, several of them, or a shared address with a restricted port set 💅
Status of This Memo
Real talk, this doc is not an Internet Standards Track spec. It's being published so people can look at it, try it out in experimental builds, and evaluate it 🧪
It defines an Experimental Protocol for the Internet community. It's a product of the Internet Engineering Task Force (IETF) and reflects the consensus of the IETF community. It went through public review and got the okay from the Internet Engineering Steering Group (IESG). Not every IESG-approved doc is up for any level of Internet Standard, so check Section 2 of RFC 5741 for that 🤓
If you want the latest status, errata, or a way to send feedback, go to http://www.rfc-editor.org/info/rfc7600 🌸
Copyright Notice
Copyright (c) 2015 IETF Trust and the people listed as the document authors. All rights reserved 💜
This doc is covered by BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info), as they were on the day it was published. Please read those carefully, since they explain what you can and can't do with it 📜 If you pull Code Components out of this doc, they have to include the Simplified BSD License text described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as the Simplified BSD License says 🫶
Table of Contents
1. Introduction ....................................................4
2. Terminology .....................................................5
3. The 4rd Model ...................................................7
4. Protocol Specifications .........................................9
4.1. NAT44 on CE ................................................9
4.2. Mapping Rules and Other Domain Parameters .................10
4.3. Reversible Packet Translations at Domain Entries
and Exits .................................................11
4.4. Address Mapping from CE IPv6 Prefixes to 4rd IPv4
Prefixes ..................................................17
4.5. Address Mapping from 4rd IPv4 Addresses to 4rd
IPv6 Addresses ............................................19
4.6. Fragmentation Processing ..................................23
4.6.1. Fragmentation at Domain Entry ......................23
4.6.2. Ports of Fragments Addressed to
Shared-Address CEs .................................24
4.6.3. Packet Identifications from Shared-Address CEs .....26
4.7. TOS and Traffic Class Processing ..........................26
4.8. Tunnel-Generated ICMPv6 Error Messages ....................27
4.9. Provisioning 4rd Parameters to CEs ........................27
5. Security Considerations ........................................30
6. IANA Considerations ............................................31
7. Relationship with Previous Works ...............................31
8. References .....................................................33
8.1. Normative References ......................................33
8.2. Informative References ....................................34
Appendix A. Textual Representation of Mapping Rules ...............37
Appendix B. Configuring Multiple Mapping Rules ....................37
Appendix C. Adding Shared IPv4 Addresses to an IPv6 Network .......39
C.1. With CEs within CPEs .......................................39
C.2. With Some CEs behind Third-Party Router CPEs ..............41
Appendix D. Replacing Dual-Stack Routing with IPv6-Only Routing ...42
Appendix E. Adding IPv6 and 4rd Service to a Net-10 Network .......43
Acknowledgements ..................................................44
Authors' Addresses ................................................441. Introduction ✨
Okay so service providers want to move to IPv6-only domains gradually, but customers still need IPv4. That means you need a stateless solution, meaning the provider's IPv4-IPv6 gateways don't have to keep any state per customer. That idea was already floating around in [Solutions-4v6] 🌈 This doc is one answer to it, and it's called "4rd" (IPv4 Residual Deployment) 💖 Same vibe as before: TCP/UDP IPv4 packets stay valid TCP/UDP IPv6 packets while they travel the domain, and IPv4 fragmentation rules stay fully intact end to end 🔥
The tunneling here is basically the reverse of IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) [RFC5969]. In 6rd, IPv6 packets get statelessly tunneled across IPv4 networks. In 4rd, IPv4 packets get tunneled across IPv6 networks 🦋
Here's the tricky part. IPv6 headers are too long to squeeze into IPv4 headers, which is why 6rd has to wrap whole IPv6 packets inside IPv4 packets. 4rd does it differently: IPv4 headers can be translated reversibly into IPv6 headers. That way, while the packet is crossing the IPv6 domain, UDP packets that have checksums and TCP packets are still valid IPv6 packets, and IPv6-only middleboxes that do deep packet inspection can still work with them, like for port inspection and web caches 🧚
To deal with the shortage of IPv4 addresses, customers can get shared public IPv4 addresses, each with a statically assigned restricted port set. Basically, that's a specific use of the Address plus Port (A+P) approach [RFC6346] 💅
If the network has enough public IPv4 addresses, customer sites can also just get full public IPv4 addresses. 4rd also covers cases where a bunch of public IPv4 addresses get assigned to a customer site 🍓
4rd builds on a bunch of earlier IPv4-via-IPv6 transition proposals, which are covered in Section 7 🫶
Some use cases: IPv4-only apps on 4rd-capable customer nodes can also work with stateful NAT64s [RFC6146], as long as those NAT64s are upgraded to support 4rd tunnels as well as their IP/ICMP translation [RFC6145]. The payoff is more complete IPv4 transparency than you get with double translation 👑
Quick map of the rest: Section 3 covers how the 4rd model fits into the Internet architecture, and Section 4 has the detailed protocol specs. Sections 5 and 6 are security considerations and IANA considerations, respectively. Earlier proposals that shaped this spec are in Section 7, and a few typical 4rd use cases live in Appendices A, B, C, D, and E 🎀
2. Terminology ✨
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this doc are to be read as described in [RFC2119] 🔥
Now the vocab, bestie 📚
- ISP: Internet Service Provider. Here the service can be DSL, fiber, cable, or mobile. The ISP can also be a private-network operator 🌐
- 4rd (IPv4 Residual Deployment): An extension of IPv4 service where public IPv4 addresses are statically shared across several customer sites, and each site gets its own exclusive port set. It runs across IPv6-routing domains 💜
- 4rd domain (or Domain): An ISP-run IPv6 network where 4rd is supported according to this spec 🏰
- Tunnel packet: An IPv6 packet that carries an IPv4 packet across a 4rd domain without anyone noticing. Its header has enough info to rebuild the IPv4 header when the packet leaves the Domain. Its payload is just the original IPv4 payload 🦋
- CE (Customer Edge): The customer-side tunnel endpoint. It can live in a host, a router, or both 🏠
- BR (Border Relay): The ISP-side tunnel endpoint. It's stateless (no per-CE and no per-session state), so you can copy it onto as many nodes as you need to scale 📈
- 4rd IPv6 address: An IPv6 address used as the destination of a Tunnel packet headed to a CE or a BR 🧚
- NAT64+: An ISP NAT64 [RFC6146] that's been upgraded to do 4rd tunneling whenever the IPv6 addresses it handles are 4rd IPv6 addresses 🌸
- 4rd IPv4 address: A public IPv4 address or, for a shared one, a public transport address (a public IPv4 address plus a port number) 🍓
- PSID (Port-Set Identifier): A flexible-length field that algorithmically identifies a port set 🔢
- 4rd IPv4 prefix: A flexible-length prefix that can be a public IPv4 prefix, a public IPv4 address, or a public IPv4 address followed by a PSID 💅
- Mapping rule: A set of parameters BRs and CEs use to derive 4rd IPv6 addresses from 4rd IPv4 addresses. CEs also use mapping rules to derive a 4rd IPv4 prefix from an IPv6 prefix that was delegated to them 🗺️
- EA bits (Embedded Address bits): Bits that are the same in a 4rd IPv4 address and in the 4rd IPv6 address derived from it 🫧
- BR Mapping rule: The Mapping rule that applies to off-domain IPv4 addresses (addresses reachable via BRs). It can also apply to some or all CE-assigned IPv4 addresses ✨
- CE Mapping rule: A Mapping rule that applies only to CE-assigned IPv4 addresses, shared or not 🎀
- NAT64+ Mapping rule: The Mapping rule that applies to IPv4 addresses reachable via a NAT64+ 🌈
- CNP (Checksum Neutrality Preserver): A field in 4rd IPv6 addresses that keeps TCP-like checksums from changing when IPv4 addresses get swapped out for 4rd IPv6 addresses 💖
- 4rd Tag: A 16-bit tag whose value lets 4rd CEs, BRs, and NAT64+s tell 4rd IPv6 addresses apart from other IPv6 addresses 🏷️
That's the end of part 1. Next up is Section 3, The 4rd Model 🧚💜
3. The 4rd Model ✨
4rd Domain
+-----------------------------+
| IPv6 routing |
| Enforced ingress filtering | +----------
... | | |
| +------+
Customer site | |BR(s) | IPv4
+------------+ | BR IPv6 prefix --> |and/or| Internet
| dual-stack | | |N4T64+|
| +--+ | +------+
| |CE+-+ <-- a CE IPv6 prefix | |
| +--+ | | +----------
| | | |
+------------+ | <--IPv4 tunnels--> +------------
=> Derived | (Mesh or hub-and-spoke |
4rd IPv4 prefix| topologies) | IPv6
| | Internet
... | |
| +------------
+-----------------------------+
<== one or several Mapping rules
(e.g., announced to CEs in stateless DHCPv6)
Figure 1: The 4rd Model in the Internet Architectureokay so, here's the big picture 🌸 Figure 1 shows how the 4rd model fits into the Internet architecture. Look at how neat it is 🦋
A 4rd domain is an IPv6 network with one or several 4rd BRs or NAT64+s sitting at its border with the public IPv4 Internet. It can also advertise its IPv4-IPv6 Mapping rule(s) to CEs, following Section 4.9. Main character energy, honestly 👑
All the BRs in a 4rd Domain are identical as far as 4rd is concerned, so no favourites 💅 When a 4rd CE has IPv4 packets that need to reach a BR, they get transformed (more on that in Section 4.3) into IPv6 packets. Those packets carry the same anycast IPv6 prefix in their destination addresses, which is the 80-bit BR prefix. Then they get routed to any of the BRs. The 80-bit BR IPv6 prefix is an arbitrarily chosen /64 prefix from the network operator's IPv6 address space, with 0x0300 (the 16-bit 4rd Tag, see R-9 in Section 4.5) appended to it 🎀
Each CE uses the Mapping rule that applies to it to derive its 4rd IPv4 prefix from its delegated IPv6 prefix. If it has several delegated prefixes, it derives one from each. Check Section 4.4 for the details 🧚 If the IPv4 prefix you get has more than 32 bits, the assigned IPv4 address gets shared among several CEs. The bits past the first 32 pick out a set of ports that's reserved for that CE. Iconic sharing skills 🫶
IPv4 traffic gets tunneled across the Domain automatically, either in mesh topology or hub-and-spoke topology [RFC4925]. By default, IPv4 traffic between two CEs follows a direct IPv6 route between them (that's mesh). If the ISP turns on the hub-and-spoke option, then every IPv4 packet going from one CE to another gets routed through a BR instead 🌈
While the traffic is crossing the Domain, every tunneled TCP/UDP IPv4 packet looks like a valid TCP/UDP IPv6 packet. So TCP/UDP access control lists that apply to IPv6 also apply to IPv4, and some other functions that use deep packet inspection might apply too. Lowkey genius ✨
For IPv4 anti-spoofing protection in CEs and BRs to keep working alongside 4rd tunneling, ingress filtering [RFC3704] has to be in effect in IPv6 (see R-12 and Section 5). No skipping this one, bestie 💀
If an ISP wants dynamic IPv4 address sharing, either as well as or instead of 4rd stateless address sharing, it can use a stateful NAT64 for that. If they upgrade this NAT to support 4rd tunnels (which turns it into a NAT64+), then CEs that have no static IPv4 space can still get complete IPv4 transparency between the CE and the NAT64. 🦋
Without that NAT64 upgrade, IPv4 traffic gets translated to IPv6 and back to IPv4 again. During that process, the DF = MF = 1 combination for IPv4 is lost. That combination is recommended for host fragmentation in Section 8 of [RFC4821], so losing it is a bummer 😭
Apart from the changes below, IPv4 packets come out of Domain traversal unchanged 🍓
- The IPv4 Time To Live (TTL) decreases during Domain traversal by the number of routers it crosses, unless it was 1 or 255 when it entered the Domain. That's fine because nobody can detect it end to end, and the TTL values that some protocols use to test whether communicating routers are adjacent stay preserved [RFC4271] [RFC5082]. The traceroute utility uses TTL expiry to find the routers on an end-to-end path, so its behaviour is affected too. You can read about that in Section 4.3 🙈
- IPv4 packets whose lengths are
<= 68octets always get their "Don't Fragment" (DF) flag set to 1 at Domain exit, even if they had DF = 0 at Domain entry. Totally acceptable, because packets this short can't be fragmented [RFC791], so their DF bits don't mean anything anyway. Also, both [RFC1191] and [RFC4821] recommend that sources always set DF to 1 💖 - Unless the Tunnel Traffic Class option applies to a Domain (Section 4.2), IPv4 packets might have their Type of Service (TOS) fields modified after Domain traversal (Section 4.7) 💅
4. Protocol Specifications 🎀
This section gets into the detailed 4rd protocol specs. Everything's mainly organised by function, so it's easy to find what you need 🧚 Here's the quick summary:
- A 4rd CE MUST follow R-1, R-2, R-3, R-4, R-6, R-7, R-8, R-9, R-10, R-11, R-12, R-13, R-14, R-16, R-17, R-18, R-19, R-20, R-21, R-22, R-23, R-24, R-25, R-26, and R-27.
- A 4rd BR MUST follow R-2, R-3, R-4, R-5, R-6, R-9, R-12, R-13, R-14, R-15, R-19, R-20, R-21, R-22, and R-24.
4.1. NAT44 on CE 🌸
R-1: A CE node that is assigned a shared public IPv4 address MUST include a NAT44 [RFC3022]. This NAT44 MUST only use external ports that are in the CE-assigned port set. 💜
NOTE: This specification only concerns IPv4 communication between IPv4-capable endpoints. For communication between IPv4-only endpoints and IPv6-only remote endpoints, the "Bump-in-the-Host" (BIH) specification [RFC6535] can be used. It can coexist in a node with the CE function, including scenarios where the IPv4-only function is a NAT44 [RFC3022]. ✨
4.2. Mapping Rules and Other Domain Parameters 🦋
R-2: CEs and BRs MUST be configured with the following Domain parameters:
- A. One or several Mapping rules, each one comprising the following:
- Rule IPv4 prefix
- EA-bits length
- Rule IPv6 prefix
- Well-Known Ports (WKPs) authorized (OPTIONAL)
- B. Domain Path MTU (PMTU)
- C. Hub-and-spoke topology (Yes or No)
- D. Tunnel Traffic Class (OPTIONAL)
"Rule IPv4 prefix" is what you use to find, by longest match, which Mapping rule applies to a 4rd IPv4 address (Section 4.5). A Mapping rule whose Rule IPv4 prefix is longer than /0 is a CE Mapping rule. BR and NAT64+ Mapping rules have to apply to all off-domain IPv4 addresses, so their Rule IPv4 prefixes are /0 🍓
"EA-bits length" is the number of bits that 4rd IPv4 addresses have in common with the 4rd IPv6 addresses derived from them. In a CE Mapping rule, it's also the number of bits that a CE-delegated IPv6 prefix shares with the 4rd IPv4 prefix derived from it. BR and NAT64+ Mapping rules have EA-bits lengths equal to 32 💖
"Rule IPv6 prefix" is the prefix that gets used as a substitute for the Rule IPv4 prefix when a 4rd IPv6 address is derived from a 4rd IPv4 address (Section 4.5). In a BR Mapping rule or a NAT64+ Mapping rule, it MUST be a /80 prefix whose bits 64-79 are the 4rd Tag 👑
"WKPs authorized" may be set for Mapping rules that assign shared IPv4 addresses to CEs. Those are the rules where the length of the Rule IPv4 prefix plus the EA-bits length goes over 32. If it's set, well-known ports may be assigned to some CEs that have particular IPv6 prefixes. If it's not set, fairness wins: all IPv6 prefixes concerned with the Mapping rule get port sets with identical values, and no port set includes any of the well-known ports ⚖️🌈
"Domain PMTU" is the IPv6 Path MTU that the ISP can guarantee for all of its IPv6 paths, both between CEs and between BRs and CEs. It MUST be at least 1280 octets [RFC2460] 🫶
"Hub-and-spoke topology", if set to Yes, requires CEs to tunnel all IPv4 packets via BRs. If it's set to No, CE-to-CE packets take the same routes as native IPv6 packets between those same CEs (that's mesh topology) 🧚
"Tunnel Traffic Class", if it's provided, is the IPv6 traffic class that BRs and CEs MUST set in Tunnel packets. When this is in play, changes to the IPv6 traffic class that happen during Domain traversal don't show up in the TOS fields of IPv4 packets at Domain exit (Section 4.7). Literally so specific 😭✨
4.3. Reversible Packet Translations at Domain Entries and Exits ✨
R-3: okay so, domain-entry nodes that get IPv4 packets with IPv4 options 🙅♀️ MUST discard these packets and send back ICMPv4 error messages to say "nope, IPv4-option incompatibility" (Type = 12, Code = 0, Pointer = 20) [RFC792]. Lowkey harsh, but it's acceptable because there are a lot of firewalls on the current IPv4 Internet that already filter IPv4 packets with IPv4 options. Same energy, honestly 💅
R-4: now for the good stuff 🎀 Domain-entry nodes that get IPv4 packets without IPv4 options MUST convert them into Tunnel packets. Whether they also get an IPv6 fragment header depends on what's needed to keep IPv4 transparency (Figure 2). Then domain-exit nodes MUST convert them back to IPv4 packets.
An IPv6 fragmentation header MUST be included at tunnel entry (Figure 2) if and only if one or several of the following conditions hold:
- The Tunnel Traffic Class option applies to the Domain.
TTL = 1 OR TTL = 255.- The IPv4 packet is already fragmented, or may be fragmented later on, i.e., if
MF = 1 OR offset > 0 OR (total length > 68 AND DF = 0).
To cut down on fragment headers when they aren't needed, the NAT44 of a CE that has one SHOULD send packets with TTL = 254 🦋
R-5: in Domains whose chosen topology is hub-and-spoke 🌸, BRs that receive 4rd IPv6 packets whose embedded destination IPv4 addresses match a CE Mapping rule MUST do the equivalent of reversibly translating their headers to IPv4, and then reversibly translate them back to IPv6, as though the packets were entering the Domain.
(A) Without IPv6 fragment header
IPv4 packet Tunnel packet
+--------------------+ : : +--------------------+
20| IPv4 Header | : <==> : | IPv6 Header | 40
+--------------------+ : : +--------------------+
| IP Payload | <==> | IP Payload |
| | Layer 4 | |
+--------------------+ unchanged +--------------------+
(B) With IPv6 fragment header
Tunnel packet
: +--------------------+
IPv4 packet : | IPv6 Header | 40
+--------------------+ : : +--------------------+
20| IPv4 Header | : <==> : |IPv6 Fragment Header| 8
+--------------------+ : : +--------------------+
| IP Payload | <==> | IP Payload |
| | Layer 4 | |
+--------------------+ unchanged +--------------------+Figure 2: Reversible Packet Translation
R-6: this is the big header-mapping moment 🧚 The values to set in IPv6 header fields at Domain entry are in Table 1 (no fragment header) and Table 2 (with fragment header). The values to set in IPv4 header fields at Domain exit are in Table 3 (no fragment header) and Table 4 (with fragment header).
Some IPv4 header info has no IPv6 equivalent, so we sneak it into IPv6 flow labels and the Identification fields of IPv6 fragment headers, as shown in Figure 3 💜
|0 |4 19|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | Addr_Prot_Cksm |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv6 Flow Label
0 1 2 |8 |16 31|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|.|.|.| 0 | IPv4_TOS | IPv4_ID |
/-+-\-\-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ \ TTL_255 IPv6 Identification Field
IPv4_DF TTL_1 (in fragment header if needed)Figure 3: 4rd Identification Fields of IPv6 Fragment Headers
+---------------------+----------------------------------------+
| IPv6 Field | Value (fields from IPv4 header) |
+---------------------+----------------------------------------+
| Version | 6 |
| Traffic Class | TOS |
| Addr_Prot_Cksm | Sum of addresses and Protocol (Note 1) |
| Payload length | Total length - 20 |
| Next header | Protocol |
| Hop limit | Time to Live |
| Source address | See Section 4.5 |
| Destination address | See Section 4.5 |
+---------------------+----------------------------------------+
Table 1: IPv4-to-IPv6 Reversible Header Translation
(without Fragment Header) +-----------------+----------------------------------------------+
| IPv6 Field | Value (fields from IPv4 header) |
+-----------------+----------------------------------------------+
| Version | 6 |
| Traffic Class | TOS OR Tunnel Traffic Class (Section 4.7) |
| Addr_Prot_Cksm | Sum of addresses and Protocol (Note 1) |
| Payload length | Total length - 12 |
| Next header | 44 (fragment header) |
| Hop limit | IF Time to Live = 1 or 255 THEN 254 |
| | ELSE Time to Live (Note 2) |
| Source address | See Section 4.5 |
| Dest. address | See Section 4.5 |
| 2nd next header | Protocol |
| Fragment offset | IPv4 fragment offset |
| M | More Fragments flag (MF) |
| IPv4_DF | Don't Fragment flag (DF) |
| TTL_1 | IF Time to Live = 1 THEN 1 ELSE 0 (Note 2) |
| TTL_255 | IF Time to Live = 255 THEN 1 ELSE 0 (Note 2) |
| IPv4_TOS | Type of Service (TOS) |
| IPv4_ID | Identification |
+-----------------+----------------------------------------------+
Table 2: IPv4-to-IPv6 Reversible Header Translation
(with Fragment Header) +-----------------+------------------------------------+
| IPv4 Field | Value (fields from IPv6 header) |
+-----------------+------------------------------------+
| Version | 4 |
| Header length | 5 |
| TOS | Traffic Class |
| Total length | Payload length + 20 |
| Identification | 0 |
| DF | 1 |
| MF | 0 |
| Fragment offset | 0 |
| Time to Live | Hop count |
| Protocol | Next header |
| Header checksum | Computed as per [RFC791] (Note 3) |
| Source address | Bits 80-111 of source address |
| Dest. address | Bits 80-111 of destination address |
+-----------------+------------------------------------+
Table 3: IPv6-to-IPv4 Reversible Header Translation
(without Fragment Header) +-----------------------+-----------------------------------------+
| IPv4 Field | Value (fields from IPv6 header) |
+-----------------------+-----------------------------------------+
| Version | 4 |
| Header length | 5 |
| TOS | Traffic Class OR IPv4_TOS (Section 4.7) |
| Total length | Payload length + 12 |
| Identification | IPv4_ID |
| DF | IPv4_DF |
| MF | M |
| Fragment offset | Fragment offset |
| Time to Live (Note 2) | IF TTL_255 = 1 THEN 255 |
| | ELSEIF TTL_1 = 1 THEN 1 |
| | ELSE hop count |
| Protocol | 2nd next header |
| Header checksum | Computed as per [RFC791] (Note 3) |
| Source address | Bits 80-111 of source address |
| Destination address | Bits 80-111 of destination address |
+-----------------------+-----------------------------------------+
Table 4: IPv6-to-IPv4 Reversible Header Translation
(with Fragment Header)NOTE 1: The need to save in the IPv6 header a checksum of both IPv4 addresses and the IPv4 protocol field results from the following facts: (1) header checksums, present in IPv4 but not in IPv6, protect addresses or protocol integrity; (2) in IPv4, ICMP messages and null-checksum UDP datagrams depend on this protection because, unlike other datagrams, they have no other address-and-protocol integrity protection. The sum MUST be performed in ordinary two's complement arithmetic.
IP-layer Packet length is another field covered by the IPv4 header checksum. It is not included in the saved checksum because (1) doing so would have conflicted with [RFC6437] (flow labels must be the same in all packets of each flow); (2) ICMPv4 messages have good enough protection with their own checksums; (3) the UDP length field provides to null-checksum UDP datagrams the same level of protection after Domain traversal as without Domain traversal (consistency between IP-layer and UDP-layer lengths can be checked).
NOTE 2: TTL treatment has been chosen to permit adjacency tests between two IPv4 nodes situated at both ends of a 4rd tunnel. TTL values to be preserved for this are TTL = 255 and TTL = 1. For other values, TTL decreases between two IPv4 nodes as though the traversed IPv6 routers were IPv4 routers.
The effect of this TTL treatment on IPv4 traceroute is specific: (1) the number of routers of the end-to-end path includes traversed IPv6 routers; (2) IPv6 routers of a Domain are listed after IPv4 routers of Domain entry and exit; (3) the IPv4 address shown for an IPv6 router is the IPv6-only dummy IPv4 address (Section 4.8); (4) the response time indicated for an IPv6 router is that of the next router.
NOTE 3: Provided the sum of obtained IPv4 addresses and protocol matches Addr_Prot_Cksm. If not, the packet MUST be silently discarded.
4.4. Address Mapping from CE IPv6 Prefixes to 4rd IPv4 Prefixes ✨
Okay bestie, this is where the pretty diagram comes in 🦋 Start at the top with the CE IPv6 prefix, find the Rule IPv6 prefix it matches the longest, swap that part for the Rule IPv4 prefix, and then the leftover bits tell you what you actually get. 💖
+--------------------------------------+
| CE IPv6 prefix |
+--------------------------+-----------+
: Longest match : :
: with a Rule IPv6 prefix : :
: || : EA-bits :
: \/ : length :
+--------------------------+ | :
| Rule IPv6 prefix |<----'---->:
+--------------------------+ :
|| : :
\/ : :
+-----------------+-----------+
|Rule IPv4 prefix | EA bits |
+-----------------+-----------+
: :
+-----------------------------+
| CE 4rd IPv4 prefix |
+-----------------------------+
________/ \_________ :
/ \ :
: ____:________________/ \__
: / : \
: <= 32 : : > 32 :
+----------------+ +-----------------+----+
|IPv4 prfx or add| OR | IPv4 address |PSID|
+----------------+ +-----------------+----+
: 32 : || :
\/
(by default) (If WKPs authorized)
: : : :
+---+----+---------+ +----+-------------+
Ports in |> 0|PSID|any value| OR |PSID| any value |
the CE port set +---+----+---------+ +----+-------------+
: 4 : 12 : : 16 :Figure 4: From CE IPv6 Prefix to 4rd IPv4 Address and Port Set
R-7: A CE whose delegated IPv6 prefix matches the Rule IPv6 prefix of one or several Mapping rules MUST pick the CE Mapping rule with the longest match 🎀 Then it works out its 4rd IPv4 prefix like in Figure 4: (1) the CE swaps the Rule IPv6 prefix for the Rule IPv4 prefix, and the result is the CE 4rd IPv4 prefix. (2) If that CE 4rd IPv4 prefix has fewer than 32 bits, the CE takes it as its assigned IPv4 prefix. If it has exactly 32 bits, the CE takes it as its IPv4 address. If it has more than 32 bits, the CE MUST take the first 32 bits as its shared public IPv4 address, and the bits after those first 32 as its Port-Set identifier (PSID) 🧚 By default, its restricted port set is the ports with any non-zero value in their first 4 bits (the PSID offset), followed by the PSID, followed by any values in the remaining bits. If the WKP authorized option applies to the Mapping rule, there is no 4-bit offset before the PSID, so all ports can be assigned 👑
NOTE: The choice of the default PSID position in port fields was guided by these objectives 💅
- For fairness, avoid having any of the well-known ports 0-1023 in the port set specified by any PSID value.
- For compatibility with RTP/RTCP [RFC4961], include pairs of consecutive ports in each port set.
- In order to facilitate operation and training, keep the PSID at a fixed position in port fields.
- In order to facilitate documentation in hexadecimal notation, and to facilitate maintenance, keep this position nibble-aligned.
Ports that are excluded from assignment to CEs are 0-4095, instead of just 0-1023. That's a trade-off to favor nibble alignment of PSIDs and overall simplicity 🌈
R-8: A CE whose delegated IPv6 prefix has its longest match with the Rule IPv6 prefix of the BR Mapping rule MUST take as its IPv4 address the 32 bits that come right after this Rule IPv6 prefix in the delegated IPv6 prefix 🦋 If this happens while the hub-and-spoke option applies to the Domain, or if the Rule IPv6 prefix is not a /80, that's a configuration error in the Domain. An implementation-dependent administrative action MAY be taken 🙈
A CE whose delegated IPv6 prefix matches neither the Rule IPv6 prefix of any CE Mapping rule nor the BR Mapping rule, and that sits in a Domain with a NAT64+ Mapping rule, MUST be noted as having the unspecified IPv4 address 💀
4.5. Address Mapping from 4rd IPv4 Addresses to 4rd IPv6 Addresses
okay bestie, this is where a 4rd IPv4 address gets turned into a 4rd IPv6 address 🦋✨ Figure 5 is the whole vibe, so look at this first:
: 32 : : 16 : \
+----------------------------+ +---------------+ |
| IPv4 address | |Port_or_ICMP_ID| | Shared-address
+----------------------------+ +---+------+----+ | case
: Longest match : : 4 : PSID : | (PSID length
: with a Rule IPv4 prefix : :length: | of the rule > 0)
: || : : : | with WKPs
: \/ : : : | not authorized
+----------------+-----------+ +------+ | (PSID offset = 4)
|Rule IPv4 prefix|IPv4 suffix| | PSID | |
+----------------+-----------+ +------+ |
: || \_______ \____ | | |
: \/ \ \| / |
+--------------------------+--------+-----+ /
| Rule IPv6 prefix | EA bits |
+--------------------------+--------------+
: :
+-----------------------------------------+
| IPv6 prefix |
+-----------------------------------------+
:\_______________________________ / \
: ___________________\______/ \_______________
: / \ \
: / (CE Mapping rule) \ (BR Mapping rule) \
: <= 64 : : 112 :
+----------+---+---+------+---+ +--------------+---+------+---+
|CE v6 prfx| 0 |tag|v4 add|CNP| |BR IPv6 prefix|tag|v4 add|CNP|
+----------+-|-+---+------+---+ +--------------+---+------+---+
: <= 64 : | :16 : 32 :16 : : 64 :16 : 32 :16 :
|
Padding to /64
Figure 5: From 4rd IPv4 Address to 4rd IPv6 AddressR-9: BRs, and CEs that are assigned public IPv4 addresses, shared or not, MUST derive 4rd IPv6 addresses from 4rd IPv4 addresses via the steps below or their functional equivalent (Figure 5 details the shared public IPv4 address case) 💖
NOTE: The rules for forming 4rd-specific Interface Identifiers (IIDs) are to obey [RFC7136]:
"Specifications of other forms of 64-bit IIDs MUST specify how all 64 bits are set."
and
"the whole IID value MUST be viewed as an opaque bit string by third parties, except possibly in the local context."
(1) Okay so, if hub-and-spoke topology doesn't apply to the Domain, or if it does but the IPv6 address being derived is a source address from a CE or a destination address from a BR, you look for the CE Mapping rule whose Rule IPv4 prefix has the longest match with the IPv4 address. 🔍
If no Mapping rule comes back from that search, you take the BR Mapping rule.
If the Mapping rule you got assigns IPv4 prefixes to CEs, meaning the length of the Rule IPv4 prefix plus EA-bits length is 32 - k, with k >= 0, you delete the last k bits of the IPv4 address.
Otherwise, if the length of the Rule IPv4 prefix plus the EA-bits length is 32 + k, with k > 0, you take k as the PSID length and append to the IPv4 address the PSID copied from bits p to p+3 of the Port_or_ICMP_ID field. Here p, the PSID offset, is 4 by default, and it's 0 if the WKPs authorized option applies to the rule. The Port_or_ICMP_ID field lives in different bits of the IP payload depending on whether the address is a source or destination, whether the packet is ICMP or not, and, if it is ICMP, whether it's an error message or an Echo message. This field is:
a. If the packet Protocol is not ICMP, the port field associated with the address (bits 0-15 for a source address and bits 16-31 for a destination address).
b. If the packet is an ICMPv4 Echo or Echo reply message, the ICMPv4 Identification field (bits 32-47).
c. If the packet is an ICMPv4 error message, the port field associated with the address in the returned packet header (bits 240-255 for a source address and bits 224-239 for a destination address).
NOTE 1: Using Identification fields of ICMP messages as port fields lets Echo requests and Echo replies get exchanged between shared-address CEs and IPv4 hosts that have exclusive IPv4 addresses. Echo exchanges between two shared-address CEs remain impossible, but that's a limitation baked into address sharing (one reason among many to use IPv6) 🌸
NOTE 2: When the PSID is taken from the port fields of the IPv4 payload, the implementation stays independent of any particular Layer 4 protocol that has such port fields, because it doesn't check that the protocol really is one with those fields. So, in the case of a source mistake, a packet may end up going from a BR to a shared-address CE using a protocol that this CE doesn't support. In that case, the CE NAT44 sends back an ICMPv4 "protocol unreachable" error message, and the IPv4 source is properly told about its mistake 🙈
(2) In the result, replace the Rule IPv4 prefix with the Rule IPv6 prefix.
(3) If the result is shorter than a /64, append to the result a null padding up to 64 bits, then the 4rd Tag (0x0300), and then the IPv4 address. ✨
NOTE: The 4rd Tag is a 4rd-specific mark. Its job is to make 4rd IPv6 addresses recognizable by CEs without interfering with how subnet prefixes get chosen in CE sites. (Those choices may have been made before 4rd gets enabled.) 🧚
To make this work, the 4rd Tag has its "u" and "g" bits [RFC4291] both set to 1, so it's as different as possible from those existing IPv6 address schemas. So far, u = g = 1 has not been used in any IPv6 addressing architecture 💅
With the 4rd Tag in place, IPv6 packets can be routed to the 4rd function inside a CE node based on a /80 prefix that no native IPv6 address can contain. 👑
(4) Add a Checksum Neutrality Preserver (CNP) to the result. Its value, in one's complement arithmetic, is the opposite of the sum of the 16-bit fields of the IPv6 address other than the IPv4 address and the CNP themselves (that is, five consecutive fields in address bits 0-79).
NOTE: The CNP guarantees that Tunnel packets are valid IPv6 packets for all Layer 4 protocols that use the same checksum algorithm as TCP. This guarantee doesn't depend on where the checksum fields of those protocols sit in IP payloads. (Today those protocols are UDP [RFC768], TCP [RFC793], UDP-Lite [RFC3828], and the Datagram Congestion Control Protocol (DCCP) [RFC5595]. Should new ones be specified, BRs will support them without needing an update.) 🎀
R-10: A 4rd-capable CE SHOULD, and a 4rd-enabled CE MUST, always prohibit all addresses that use its advertised prefix and have an IID starting with 0x0300 (4rd Tag), by using Duplicate Address Detection [RFC4862]. 🛑
R-11: A CE that is assigned the unspecified IPv4 address (see Section 4.4) MUST use, for packets tunneled between itself and the Domain NAT64+, addresses as detailed in Figure 6: part (a) for its IPv6 source, and part (b) as IPv6 destinations that depend on IPv4 destinations. A NAT64+, being NAT64 conforming [RFC6146], MUST accept IPv6 packets whose destination conforms to Figure 6(b) (4rd Tag instead of "u" and 0x00 octets). In its Binding Information Base, it MUST remember whether a mapping was created with a "u" or 4rd-tag destination. In the IPv4-to-IPv6 direction, it MUST use 4rd tunneling, with source address conforming to Figure 6(b), when using a mapping that was created with a 4rd-tag destination. 🦋
+---------------------+---------+-------+-------------+------+
(a) | CE IPv6 prefix | 0 |4rd Tag| 0 | CNP |
+---------------------+---------+-------+-------------+------+
: <= 64 : >= 0 : 16 : 32 : 16 :
4rd IPv6 address of a CE having no public IPv4 address
<----------- Rule IPv6 prefix --------->:
+-------------------------------+-------+-------------+------+
(b) | NAT64+ IPv6 prefix |4rd Tag|IPv4 address | CNP |
+-------------------------------+-------+-------------+------+
: 64 : 16 : 32 : 16 :
4rd IPv6 address of a host reachable via a NAT64+
Figure 6: Rules for CE and NAT64+R-12: For anti-spoofing protection, CEs and BRs MUST check that the IPv6 source address of each received Tunnel packet is the one that, according to R-9, gets derived from the source 4rd IPv4 address. To do this, the IPv4 address used to obtain the source 4rd IPv4 address is the one embedded in the IPv6 source address (in its bits 80-111). (This check is needed because IPv6 ingress filtering [RFC3704] only applies to IPv6 prefixes, with no guarantee that Tunnel packets are built the way R-9 specifies.) 🕵️♀️
R-13: For extra protection against packet corruption at a link layer that might go undetected at that layer while the Domain is being traversed, CEs and BRs SHOULD verify that the source and destination IPv6 addresses haven't been modified. This can be done by checking that they remain checksum neutral (see the Note above regarding the CNP). 🫶
4.6. Fragmentation Processing
4.6.1. Fragmentation at Domain Entry
R-14: If an IPv4 packet enters a CE or BR at a size where the derived Tunnel packet would be longer than the Domain PMTU, the packet has to be either discarded or fragmented. The Domain-entry node MUST discard it if the packet has DF = 1, and an ICMP error message gets returned to the source. Otherwise it MUST fragment it, with the payload of each fragment not exceeding PMTU - 48. The first fragment has its offset equal to the received offset. Subsequent fragments have offsets increased by the lengths of the payloads of the previous fragments. Functionally, fragmentation is supposed to happen in IPv4 before reversible header translation is applied to each fragment; see Section 4.3. 🍓
4.6.2. Ports of Fragments Addressed to Shared-Address CEs ✨
okay so ports only show up in the first fragment of a fragmented IPv4 packet 😭 which means a BR needs a way to get ALL the fragments to the right shared-address CE, not just the first one 🎀
A BR MAY systematically reassemble fragmented IPv4 packets before tunneling them. But that eats up a lot of memory, opens the door to denial-of-service attacks 💀, and can seriously bump up forwarding delays. So here's the requirement that handles it:
R-15: BRs SHOULD support an algorithm whereby received IPv4 packets can be forwarded on the fly. Here's an example of how that could look 🧚
(1) At BR initialization, if at least one CE Mapping rule deals with one or more shared public IPv4 addresses (i.e., length of Rule IPv4 prefix + EA-bits length > 32), the BR initializes an empty "IPv4 packet table" whose entries have these items:
- IPv4 source
- IPv4 destination
- IPv4 identification
- Destination port
(2) When the BR receives an IPv4 packet whose matching Mapping rule deals with one or more shared public IPv4 addresses (i.e., length of Rule IPv4 prefix + EA-bits length > 32), the BR searches the table for an entry whose IPv4 source, IPv4 destination, and IPv4 identification match the received packet. The BR then performs actions as detailed in Table 5, depending on which conditions hold.
+-----------------------------+---+---+---+---+---+---+---+---+
| - CONDITIONS - | | | | | | | | |
| First Fragment (offset = 0) | Y | Y | Y | Y | N | N | N | N |
| Last fragment (MF = 0) | Y | Y | N | N | Y | Y | N | N |
| An entry has been found | Y | N | Y | N | Y | N | Y | N |
| ------------------------- | | | | | | | | |
| - RESULTING ACTIONS - | | | | | | | | |
| Create a new entry | - | - | - | X | - | - | - | - |
| Use port of the entry | - | - | - | - | X | - | X | - |
| Update port of the entry | - | - | X | - | - | - | - | - |
| Delete the entry | X | - | - | - | X | - | - | - |
| Forward the packet | X | X | X | X | X | - | X | - |
+-----------------------------+---+---+---+---+---+---+---+---+
Table 5: BR Actions(3) The BR performs garbage collection for table entries that remain unchanged for longer than some limit. This limit, which is normally longer than the maximum time normally needed to reassemble a packet, is not critical. It should not, however, be longer than 15 seconds [RFC791].
R-16: For the above algorithm to work well, CEs that are assigned shared public IPv4 addresses MUST NOT interleave fragments of several fragmented packets. Keep those fragments in order, bestie 🫶
R-17: CEs that are assigned IPv4 prefixes and are in nodes that route public IPv4 addresses, rather than only using NAT44s, MUST have the same behavior as that described just above for BRs. It's giving "same rules, different hat" 👑
4.6.3. Packet Identifications from Shared-Address CEs 🦋
so when packets go from CEs that share the same IPv4 address to a common destination, we need a precaution to make sure the packet identifications set by the sources are all different 🙈 otherwise the destination could get confused while reassembling, since it only looks at the source IPv4 address and Identification. In theory the chance of that confusion is super low, but a safe solution is still needed so we don't create new attack opportunities 💅
R-18: A CE that is assigned a shared public IPv4 address MUST only use packet identifications that have the CE PSID in their bits 0 to PSID length - 1.
R-19: A BR or a CE that receives a packet from a shared-address CE MUST check that bits 0 to PSID length - 1 of their packet identifications are equal to the PSID found in the source 4rd IPv4 address. Double-check, no cap 🔥
4.7. TOS and Traffic Class Processing 🌈
ok this one's lowkey a love story 💜 IPv4 TOS and IPv6 traffic class have the same meaning: the differentiated services field, or DS field, from [RFC2474] and [RFC6040]. The first 6 bits hold a differentiated services codepoint (DSCP), and the last 2 bits can carry explicit congestion notifications (ECNs). Both of these can change while traffic crosses the Domain. [RFC2983] talks about how tunnel endpoints can handle the DSCP. The Tunnel Traffic Class option lets you ignore DS-field changes that happen during Domain traversal, if what you want is the behavior of generic tunnels conforming to [RFC2473] ✨
R-20: Unless the Tunnel Traffic Class option is configured for the Domain, BRs and CEs MUST copy the IPv4 TOS into the IPv6 traffic class at Domain entry, and copy back the IPv6 traffic class into the IPv4 TOS at Domain exit.
R-21: If the Tunnel Traffic Class option is configured for a Domain, BRs and CEs MUST, at Domain entry, take the configured Tunnel Traffic Class as the IPv6 traffic class and copy the received IPv4 TOS into the IPv4_TOS of the fragment header (Figure 3). At Domain exit, they MUST copy back the IPv4_TOS of the fragment header into the IPv4 TOS. 🎀
4.8. Tunnel-Generated ICMPv6 Error Messages 💀
if a Tunnel packet gets tossed on its way across a 4rd Domain because the destination is unreachable, an ICMPv6 error message goes back to the IPv6 source. For the IPv4 source of the dropped packet to find out about the loss, that ICMPv6 message has to be converted into an ICMPv4 message. Plot twist, but it makes sense 🧚
R-22: If a CE or BR receives an ICMPv6 error message [RFC4443], it MUST synthesize an ICMPv4 error packet [RFC792]. This packet MUST contain the first 8 octets of the discarded packet's IP payload. The reserved IPv4 dummy address (192.0.0.8/32; see Section 6) MUST be used as its source address.
As described in [RFC6145], ICMPv6 Type = 1 and Code = 0 (Destination Unreachable, No route to destination) MUST be translated into ICMPv4 Type = 3 and Code = 0 (Destination Unreachable, Net unreachable). ICMPv6 Type = 3 and Code = 0 (Time Exceeded, Hop limit exceeded in transit) MUST be translated into ICMPv4 Type = 11 and Code = 0 (Time Exceeded, time to live exceeded in transit). The translation rules are giving main character energy 🌸
4.9. Provisioning 4rd Parameters to CEs 🎀
okay so the domain parameters from Section 4.2 come with some rules we have to follow, and these are non-negotiable 💅
R-23: Every Domain MUST have a BR Mapping rule and/or a NAT64+ Mapping rule 🌸 The BR Mapping rule is only for CEs that get public IPv4 addresses, shared or not. The NAT64+ Mapping rule is only for CEs that are assigned the unspecified IPv4 address (Section 4.4), so they need an ISP NAT64 to reach IPv4 destinations 🧚
R-24: Each CE and each BR MUST support up to 32 Mapping rules ✨
This support for up to 32 Mapping rules is what makes sure independently acquired CEs and BR nodes can always interwork. It's giving compatibility 🫶
ISPs that need Mapping rules for more IPv4 prefixes than this number SHOULD split their networks into multiple Domains 🦋 Communication between those domains can happen over IPv4, or by some other implementation-dependent but equivalent means 💜
R-25: For mesh topologies, where CE-CE paths don't go via BRs, all Mapping rules of the Domain MUST be sent to all CEs 🌈 For hub-and-spoke topologies, where all CE-CE paths go via BRs, each CE MAY be sent only the BR Mapping rule of the Domain plus, if different, the CE Mapping rule that applies to its CE IPv6 prefix 🍓
R-26: In a Domain where the chosen topology is hub-and-spoke, all CEs MUST have IPv6 prefixes that match a CE Mapping rule 💀 Here's why it matters: if a CE's IPv6 prefix only matched the BR Mapping rule, longest-match selected routes would send packets straight to that CE. That would go against the hub-and-spoke requirement, and it's not the vibe 🙈
R-27: CEs MUST be able to acquire parameters of 4rd domains (Section 4.2) in DHCPv6 [RFC3315] 👑 The DHCPv6 option formats are detailed in Figures 7, 8, and 9, with field values specified after each figure ✨
Figure 7 is the outer wrapper, the DHCPv6 option for 4rd:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| option = OPTION_4RD | option-length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| encapsulated 4rd rule options |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: DHCPv6 Option for 4rdHere are the field values for it:
- option code:
97, OPTION_4RD (see Section 6) 🧚 - option-length: the length of encapsulated options, in octets
- encapsulated 4rd rule options: The OPTION_4RD DHCPv6 option contains at least one encapsulated OPTION_4RD_MAP_RULE option and a maximum of one encapsulated OPTION_4RD_NON_MAP_RULE option 💅 DHCP servers normally send whatever options the operator configures, so operators are advised to configure these options appropriately 🫶 DHCP servers MAY check that the configuration follows these rules and notify the operator in an implementation-dependent manner if the settings for these options aren't valid 🔥 The length of encapsulated options is in octets.
Now the encapsulated Mapping rule option, Figure 8:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| option = OPTION_4RD_MAP_RULE | option-length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| prefix4-len | prefix6-len | ea-len |W| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| rule-ipv4-prefix |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| rule-ipv6-prefix |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: Encapsulated Option for Mapping-Rule ParametersAnd the field values:
- option code:
98, encapsulated OPTION_4RD_MAP_RULE option (see Section 6) 🌸 - option-length:
20 - prefix4-len: number of bits of the Rule IPv4 prefix
- prefix6-len: number of bits of the Rule IPv6 prefix
- ea-len: EA-bits length
- W: WKP authorized, =
1if set ✨ - rule-ipv4-prefix: Rule IPv4 prefix, left-aligned
- rule-ipv6-prefix: Rule IPv6 prefix, left-aligned
Last but not least, Figure 9 is the encapsulated option for the non-Mapping-rule parameters of 4rd domains:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|option =OPTION_4RD_NON_MAP_RULE| option-length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|H| 0 |T| traffic-class | domain-pmtu |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: Encapsulated Option for Non-Mapping-Rule Parameters
of 4rd Domains- option code:
99, encapsulated OPTION_4RD_NON_MAP_RULE option (see Section 6) 🦋 - option-length:
4 - H: Hub-and-spoke topology (=
1if Yes) - T: Traffic Class flag (=
1if a Tunnel Traffic Class is provided) - traffic-class: Tunnel Traffic Class
- domain-pmtu: Domain PMTU (at least
1280octets)
Other ways of getting 4rd parameters to CEs, apart from DHCPv6, are off-scope for this document 🌈 That said, the same or similar parameter formats would be recommended to make training and operation easier 🍓
5. Security Considerations ✨
Spoofing attacks
With IPv6 ingress filtering in effect in the Domain [RFC3704], as required in Section 3 (Figure 1 in particular), and with consistency checks between 4rd IPv4 and IPv6 addresses (Section 4.5), 4rd introduces no spoofing opportunity in IPv4 😤 A customer can only use as source IPv6 address one that has been allocated to them. So they can only provide as source 4rd IPv4 address the one that derives this IPv6 address according to Section 4.5, meaning one that their ISP has allocated to them 🔒
Routing loop attacks
Routing loop attacks that may exist in some "automatic tunneling" scenarios are documented in [RFC6324]. No opportunities for routing loop attacks have been identified with 4rd 🦋
Fragmentation-related attacks
As discussed in Section 4.6, each BR of a Domain that assigns shared public IPv4 addresses should maintain a dynamic table of fragmented packets that go to these shared-address CEs 🧚
This leaves BRs vulnerable to denial-of-service attacks from hosts that would send very large numbers of first fragments and would never send last fragments having the same packet identifications 💀 This vulnerability is inherent in IPv4 address sharing, whether it's static or dynamic. Compared to what it is with algorithms that reassemble IPv4 packets in BRs, it is, however, significantly mitigated by the algorithm provided in Section 4.6.2, because that algorithm uses much less memory space 🫶
6. IANA Considerations 🌸
IANA has allocated the following:
- Encapsulated options OPTION_4RD (97), OPTION_4RD_MAP_RULE (98), and OPTION_4RD_NON_MAP_RULE (99) 👑 These options have been recorded in the option code space of the "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" registry. See Section 4.9 of this document and Section 24.3 of [RFC3315]).
Value | Description | Reference
-----------+-------------------------+---------------
97 | OPTION_4RD | this document
98 | OPTION_4RD_MAP_RULE | this document
99 | OPTION_4RD_NON_MAP_RULE | this document- Reserved IPv4 address
192.0.0.8/32to be used as the "IPv4 dummy address" (Section 4.8) ✨
7. Relationship with Previous Works 🧚
The present specification has been influenced by many previous IETF drafts 💜 The ones you can look at are in <http://tools.ietf.org/html/draft-xxxx>, where "xxxx" refers to the following, listed in order by the date of their first versions:
bagnulo-behave-nat64(2008-06-10)xli-behave-ivi(2008-07-06)despres-sam-scenarios(2008-09-28)boucadair-port-range(2008-10-23)ymbk-aplusp(2008-10-27)xli-behave-divi(2009-10-19)thaler-port-restricted-ip-issues(2010-02-28)cui-softwire-host-4over6(2010-07-06)dec-stateless-4v6(2011-03-05)matsushima-v6ops-transition-experience(2011-03-07)despres-intarea-4rd(2011-03-07)deng-aplusp-experiment-results(2011-03-07)operators-softwire-stateless-4v6-motivation(2011-05-05)xli-behave-divi-pd(2011-07-04)murakami-softwire-4rd(2011-07-04)murakami-softwire-4v6-translation(2011-07-04)despres-softwire-4rd-addmapping(2011-08-19)boucadair-softwire-stateless-requirements(2011-09-08)chen-softwire-4v6-add-format(2011-10-12)mawatari-softwire-464xlat(2011-10-16)mdt-softwire-map-dhcp-option(2011-10-24)mdt-softwire-mapping-address-and-port(2011-10-24)mdt-softwire-map-translation(2012-01-10)mdt-softwire-map-encapsulation(2012-01-27)
8. References 📚
8.1. Normative References 📚✨
okay bestie, these are the must-read papers 💅 every one of these is a "you need this to get the vibe" kind of source, and I'm not kidding about the list being long.
- [RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, DOI 10.17487/RFC0791, September 1981,
http://www.rfc-editor.org/info/rfc791. - [RFC792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, DOI 10.17487/RFC0792, September 1981,
http://www.rfc-editor.org/info/rfc792. - [RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, DOI 10.17487/RFC0793, September 1981,
http://www.rfc-editor.org/info/rfc793. - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997,
http://www.rfc-editor.org/info/rfc2119. - [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, December 1998,
http://www.rfc-editor.org/info/rfc2460. - [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, DOI 10.17487/RFC2474, December 1998,
http://www.rfc-editor.org/info/rfc2474. - [RFC2983] Black, D., "Differentiated Services and Tunnels", RFC 2983, DOI 10.17487/RFC2983, October 2000,
http://www.rfc-editor.org/info/rfc2983. - [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 2003,
http://www.rfc-editor.org/info/rfc3315. - [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, DOI 10.17487/RFC4291, February 2006,
http://www.rfc-editor.org/info/rfc4291. - [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 4443, DOI 10.17487/RFC4443, March 2006,
http://www.rfc-editor.org/info/rfc4443. - [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, DOI 10.17487/RFC4862, September 2007,
http://www.rfc-editor.org/info/rfc4862. - [RFC4925] Li, X., Ed., Dawkins, S., Ed., Ward, D., Ed., and A. Durand, Ed., "Softwire Problem Statement", RFC 4925, DOI 10.17487/RFC4925, July 2007,
http://www.rfc-editor.org/info/rfc4925. - [RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., Ed., and C. Pignataro, "The Generalized TTL Security Mechanism (GTSM)", RFC 5082, DOI 10.17487/RFC5082, October 2007,
http://www.rfc-editor.org/info/rfc5082. - [RFC6040] Briscoe, B., "Tunnelling of Explicit Congestion Notification", RFC 6040, DOI 10.17487/RFC6040, November 2010,
http://www.rfc-editor.org/info/rfc6040.
8.2. Informative References 🦋
ngl this list is the "extra credit" section 🧚 these are the deep-dive reads that give the full story, so grab a snack first 🍓
- [NAT444] Yamagata, I., Shirasaki, Y., Nakagawa, A., Yamaguchi, J., and H. Ashida, "NAT444", Work in Progress, draft-shirasaki-nat444-06, July 2012.
- [RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, DOI 10.17487/RFC0768, August 1980,
http://www.rfc-editor.org/info/rfc768. - [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, DOI 10.17487/RFC1191, November 1990,
http://www.rfc-editor.org/info/rfc1191. - [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,
http://www.rfc-editor.org/info/rfc1918. - [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473, December 1998,
http://www.rfc-editor.org/info/rfc2473. - [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)", RFC 3022, DOI 10.17487/RFC3022, January 2001,
http://www.rfc-editor.org/info/rfc3022. - [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, DOI 10.17487/RFC3704, March 2004,
http://www.rfc-editor.org/info/rfc3704. - [RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., Ed., and G. Fairhurst, Ed., "The Lightweight User Datagram Protocol (UDP-Lite)", RFC 3828, DOI 10.17487/RFC3828, July 2004,
http://www.rfc-editor.org/info/rfc3828. - [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 10.17487/RFC4271, January 2006,
http://www.rfc-editor.org/info/rfc4271. - [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007,
http://www.rfc-editor.org/info/rfc4821. - [RFC4961] Wing, D., "Symmetric RTP / RTP Control Protocol (RTCP)", BCP 131, RFC 4961, DOI 10.17487/RFC4961, July 2007,
http://www.rfc-editor.org/info/rfc4961. - [RFC5595] Fairhurst, G., "The Datagram Congestion Control Protocol (DCCP) Service Codes", RFC 5595, DOI 10.17487/RFC5595, September 2009,
http://www.rfc-editor.org/info/rfc5595. - [RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) -- Protocol Specification", RFC 5969, DOI 10.17487/RFC5969, August 2010,
http://www.rfc-editor.org/info/rfc5969. - [RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation Algorithm", RFC 6145, DOI 10.17487/RFC6145, April 2011,
http://www.rfc-editor.org/info/rfc6145. - [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,
http://www.rfc-editor.org/info/rfc6146. - [RFC6324] Nakibly, G. and F. Templin, "Routing Loop Attack Using IPv6 Automatic Tunnels: Problem Statement and Proposed Mitigations", RFC 6324, DOI 10.17487/RFC6324, August 2011,
http://www.rfc-editor.org/info/rfc6324. - [RFC6346] Bush, R., Ed., "The Address plus Port (A+P) Approach to the IPv4 Address Shortage", RFC 6346, DOI 10.17487/RFC6346, August 2011,
http://www.rfc-editor.org/info/rfc6346. - [RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, "IPv6 Flow Label Specification", RFC 6437, DOI 10.17487/RFC6437, November 2011,
http://www.rfc-editor.org/info/rfc6437. - [RFC6535] Huang, B., Deng, H., and T. Savolainen, "Dual-Stack Hosts Using "Bump-in-the-Host" (BIH)", RFC 6535, DOI 10.17487/RFC6535, February 2012,
http://www.rfc-editor.org/info/rfc6535. - [RFC6887] Wing, D., Ed., Cheshire, S., Boucadair, M., Penno, R., and P. Selkirk, "Port Control Protocol (PCP)", RFC 6887, DOI 10.17487/RFC6887, April 2013,
http://www.rfc-editor.org/info/rfc6887. - [RFC7136] Carpenter, B. and S. Jiang, "Significance of IPv6 Interface Identifiers", RFC 7136, DOI 10.17487/RFC7136, February 2014,
http://www.rfc-editor.org/info/rfc7136. - [Solutions-4v6] Boucadair, M., Ed., Matsushima, S., Lee, Y., Bonness, O., Borges, I., and G. Chen, "Motivations for Carrier-side Stateless IPv4 over IPv6 Migration Solutions", Work in Progress, draft-ietf-softwire-stateless-4v6-motivation-05, November 2012.
Appendix A. Textual Representation of Mapping Rules 🎀
okay so this appendix is basically the cheat sheet for how we write down Mapping rules 🧚 each one gets written like this, where 0bXXX just means the binary number XXX, and the square brackets [ ] mean "this bit is optional" 💜
{Rule IPv4 prefix, EA-bits length, Rule IPv6 prefix
[, WKPs authorized]}and here are some examples so you can see it in action 👑
{0.0.0.0/0, 32, 2001:db8:0:1:300::/80}
a BR Mapping rule
{198.16.0.0/14, 22, 2001:db8:4000::/34}
a CE Mapping rule
{0.0.0.0/0, 32, 2001:db8:0:1::/80}
a NAT64+ Mapping rule
{198.16.0.0/14, 22, 2001:db8:4000::/34, Yes}
a CE Mapping rule
and hub-and-spoke topologyAppendix B. Configuring Multiple Mapping Rules ✨
okay so, as far as Mapping rules go, the simplest deployment model is the one where the Domain has only one rule (the BR Mapping rule) 🌸. To give a CE an IPv4 address in this model, you assign it an IPv6 /112 made of the BR /64 prefix, the 4rd Tag, and the IPv4 address. BUT this model has some limitations 💀: (1) shared IPv4 addresses are not supported, (2) the IPv6 prefixes used for 4rd are too long to also be used for native IPv6 addresses, and (3) if the ISP's IPv4 address space is split into lots of disjoint IPv4 prefixes, the IPv6 routing plan ends up being just as complex as an IPv4 routing plan based on those prefixes. not ideal, bestie 😭
With more Mapping rules, the CE prefixes used for 4rd can be the same ones used for native IPv6 🦋. How you choose the CE Mapping rules for a particular deployment does not need to be standardized, so it's totally up to you ✨.
The following is just one pragmatic approach you can use for different deployment scenarios, and it's applied in some of the use cases below 💖.
- (1) Select a "Common_IPv6_prefix" that will appear at the beginning of all 4rd CE IPv6 prefixes 👑.
- (2) Choose all the IPv4 prefixes you're going to use, and assign one of them to each CE Mapping rule i 🎀.
- (3) For each CE Mapping rule i, do the following 🧚:
- A. Choose the length of its Rule IPv6 prefix (this can be the same for all CE Mapping rules).
- B. Determine its PSID_length(i). A CE Mapping rule that assigns shared addresses with a sharing ratio of
2^KihasPSID_length = Ki. A CE Mapping rule that assigns IPv4 prefixes of lengthL < 32is considered to have a negative PSID_length, which isPSID_length = L - 32🙈. - C. Derive the EA-bits length(i) with
EA-bits length(i) = 32 - L(Rule IPv4 prefix(i)) + PSID_length(i). - D. Derive the length of Rule_code(i), which is the prefix that gets appended to the common prefix to make the Rule IPv6 prefix of rule i:
L(Rule_code(i)) = L(CE IPv6 prefix(i))
- L(Common_IPv6_prefix)
- (32 - L(Rule IPv4 prefix(i)))
- PSID_length(i)- E. Derive Rule_code(i) with these constraints 🔥: (1) its length is L(Rule_code(i)); (2) it must not overlap with any of the Rule_codes you already got (so
010and01011do overlap, while00,011, and010do not); and (3) it has the lowest possible value as a fractional binary number (so0100 < 10 < 11011 < 111). Thus, rules whose Rule_code lengths are 4, 3, 5, and 2 give Rule_codes0000,001,00010, and01. - F. Take Rule IPv6 prefix(i) to be the Common_IPv6_prefix followed by Rule_code(i) ✨.
Here's the picture, because it's SO helpful 🍓:
:<--------------------- L(CE IPv6 prefix(i)) --------------------->:
: :
: 32 - L(Rule IPv4 prefix(i)) PSID_length(i):
: \ | :
: :<---------'--------><--'-->:
: : || :
: : \/ :
: :<------->:<--- EA-bits length(i) --->:
: L(Rule_code(i))
: : :
+----------------------------+---------+
| Common_IPv6_prefix |Rule_code|
| | (i) |
+----------------------------+---------+
:<------ L(Rule IPv6 prefix(i)) ------>:
Figure 10: Diagram of One Pragmatic ApproachAppendix C. Adding Shared IPv4 Addresses to an IPv6 Network 🦋
C.1. With CEs within CPEs 💅
okay so picture this: an ISP offers IPv6-only service to up to 2^20 customers 🌈. Each customer is delegated a /56, starting from the common prefix 2001:db8:0::/36. The ISP wants to add public IPv4 service for customers who are 4rd capable. It would prefer to do that with stateless operation in its nodes, but it has way fewer IPv4 addresses than IPv6 addresses, so a sharing ratio is necessary 😭.
The only IPv4 prefixes it can use are 192.8.0.0/15, 192.4.0.0/16, 192.2.0.0/16, and 192.1.0.0/16 (neither overlapping nor aggregatable). That gives 2^(32 - 15) + 3 * 2^(32 - 16) IPv4 addresses, i.e., 2^18 + 2^16. For all 2^20 customers to have the same sharing ratio, the number of IPv4 addresses to be shared has to be a power of 2, so the ISP can give up using one of its /16s, say the last one. (Whether or not it could be motivated to return it to its Internet Registry is off-scope for this document 🙈.) The sharing ratio to apply is then 2^20 / 2^18 = 2^2 = 4, giving a PSID length of 2 ✨.
Applying the principles from Appendix B with L(Common_IPv6_prefix) = 36, L(PSID) = 2 for all rules, and L(CE IPv6 prefix(i)) = 56 for all rules, the Rule_codes and Rule IPv6 prefixes come out like this 💖:
+--------------+--------+-----------+-----------+-------------------+
| CE Rule IPv4 | EA | Rule-Code | Code | CE Rule IPv6 |
| prefix | bits | length | (binary) | prefix |
| | length | | | |
+--------------+--------+-----------+-----------+-------------------+
| 192.8.0.0/15 | 19 | 1 | 0 | 2001:db8:0::/37 |
| 192.4.0.0/16 | 18 | 2 | 10 | 2001:db8:800::/38 |
| 192.2.0.0/16 | 18 | 2 | 11 | 2001:db8:c00::/38 |
+--------------+--------+-----------+-----------+-------------------+So the Mapping rules are these 🎀:
{192.8.0.0/15, 19, 2001:0db8:0000::/37}
{192.4.0.0/16, 18, 2001:0db8:0800::/38}
{192.2.0.0/16, 18, 2001:0db8:0c00::/38}
{0.0.0.0/0, 32, 2001:0db8:0000:0001:300::/80}Now let's look at a CE whose IPv6 prefix is, for example, 2001:db8:0bbb:bb00::/56 🧚. It derives its IPv4 address and its port set like this (Section 4.4):
CE IPv6 prefix : 2001:0db8:0bbb:bb00::/56
Rule IPv6 prefix(i): 2001:0db8:0800::/38 (longest match)
EA-bits length(i) : 18
EA bits : 0b11 1011 1011 1011 1011
Rule IPv4 prefix(i): 0b1100 0000 0000 0100 (192.4.0.0/16)
IPv4 address : 0b1100 0000 0000 0100 1110 1110 1110 1110
: 192.4.238.238
PSID : 0b11
Ports : 0bYYYY 11XX XXXX XXXX
with YYYY > 0, and X...X any valueAnd an IPv4 packet sent to address 192.4.238.238 and port 7777 gets tunneled to the IPv6 address that's worked out like this (Section 4.5) 🔥:
IPv4 address : 192.4.238.238 (0xc004 eeee)
: 0b1100 0000 0000 0100 1110 1110 1110 1110
Rule IPv4 prefix(i): 192.4.0.0/16 (longest match)
: 0b1100 0000 0000 0100
IPv4 suffix(i) : 0b1110 1110 1110 1110
EA-bits length(i) : 18
PSID length(i) : 2 (= 16 + 18 - 32)
Port field : 0b 0001 1110 0110 0001 (7777)
PSID : 0b11
Rule IPv6 prefix(i): 2001:0db8:0800::/38
CE IPv6 prefix : 2001:0db8:0bbb:bb00::/56
IPv6 address : 2001:0db8:0bbb:bb00:300:c004:eeee:YYYY
with YYYY = the computed CNPC.2. With Some CEs behind Third-Party Router CPEs 🌸
now let's look at an ISP with the same need as the one in the previous section, except that (1) instead of using only its own IPv6 infrastructure, it uses a third-party provider's, and (2) some of its customers use this provider's Customer Premises Equipment (CPEs) so they can use specific services the provider offers 🍓. In these CPEs, a non-zero index is used to route IPv6 packets to the physical port the CEs are attached to, say 0x2. Each such CPE delegates to the CE nodes the customer-site IPv6 prefix followed by this index.
The ISP is supposed to have the same IPv4 prefixes as in the previous use case (192.8.0.0/15, 192.4.0.0/16, and 192.2.0.0/16) and to use the same Common_IPv6_prefix, 2001:db8:0::/36 ✨.
We also assume that only a minority of customers use third-party CPEs, so it's enough to use only one of the two /16s for them 💜.
So the Mapping rules are these (see Appendix C.1) 👑:
{192.8.0.0/15, 19, 2001:0db8:0000::/37}
{192.4.0.0/16, 18, 2001:0db8:0800::/38}
{192.2.0.0/16, 18, 2001:0db8:0c00::/38}
{0.0.0.0/0, 32, 2001:0db8:0000:0001:300::/80}CEs that sit behind third-party CPEs derive their own IPv4 addresses and port sets just like described in Appendix C.1 🦋.
In a BR, and also in a CE if the topology is mesh, the IPv6 address derived from IPv4 address 192.4.238.238 and port 7777 is obtained as described in the previous section, EXCEPT for the last two steps, which are modified like this 🙈:
IPv4 address : 192.4.238.238 (0xc004 eeee)
: 0b1100 0000 0000 0100 1110 1110 1110 1110
Rule IPv4 prefix(i): 192.4.0.0/16 (longest match)
: 0b1100 0000 0000 0100
IPv4 suffix(i) : 0b1110 1110 1110 1110
EA-bits length(i) : 18
PSID length(i) : 2 (= 16 + 18 - 32)
Port field : 0b 0001 1110 0110 0001 (7777)
PSID : 0b11
Rule IPv6 prefix(i): 2001:0db8:0800::/38
CE IPv6 prefix : 2001:0db8:0bbb:bb00::/60
IPv6 address : 2001:0db8:0bbb:bb00:300:192.4.238.238:YYYY
with YYYY = the computed CNPAppendix D. Replacing Dual-Stack Routing with IPv6-Only Routing 🌈
in this use case, we've got an ISP that offers IPv4 service with public addresses individually assigned to its customers 💅. It also offers IPv6 service, because it has deployed dual-stack routing. Since it provides its own CPEs to customers, it can upgrade all of them to support 4rd 🎀. It wants to use that to replace dual-stack routing with IPv6-only routing, WITHOUT changing any IPv4 address or IPv6 prefix ✨.
To do this, the ISP can use the single-rule model described at the beginning of Appendix B. If the prefix routed to BRs is chosen to start with 2001:db8:0:1::/64, the rule is this 🧚:
{0.0.0.0/0, 32, 2001:db8:0:1:300::/80}Before disabling IPv4 routing, all that's needed in the network is the following 💖:
- In all routers, where there is an IPv4 route toward
x.x.x.x/n, add a parallel route toward2001:db8:0:1:300:x.x.x.x::/(80+n). - Where IPv4 address
x.x.x.xwas assigned to a CPE, now delegate IPv6 prefix2001:db8:0:1:300:x.x.x.x::/112.
NOTE: In parallel with this deployment, or after it, shared IPv4 addresses can be assigned to IPv6 customers 🍓. It is sufficient that the IPv4 prefixes used for this be different from those used for exclusive-address assignments. Under this constraint, Mapping rules can be set up according to the same principles as those described in Appendix C.
Appendix E. Adding IPv6 and 4rd Service to a Net-10 Network ✨
okay so this one is a real-life scenario and it's giving ISP drama 💅. Picture an ISP that has only deployed IPv4, possibly because some of its network devices aren't IPv6 capable yet 🙈. It ran out of public IPv4 addresses, so it gave customers private ones from 10.x.x.x 🌸. That gets it up to 2^24 customers, and it's called a "Net-10" network, using the NAT444 model [NAT444].
Now the ISP wants to offer IPv6 service right away, using 6rd [RFC5969] 🚀. It also wants to give incoming IPv4 connectivity to its customers with something simpler than the Port Control Protocol (PCP) [RFC6887] 🎀.
This appendix walks through an example that adds IPv6 (using 6rd) and 4rd services to the "Net-10" private IPv4 network 🦋.
The IPv6 prefix for 6rd is supposed to be 2001:db8::/32, and the public IPv4 prefix for shared addresses is supposed to be 198.16.0.0/16 (0xc610) 💜. The sharing ratio works out to 2^24 / 2^(32 - 16) = 256, which gives a PSID length of 8 ✨.
The ISP installs one or several BRs at its border to the public IPv4 Internet 🌈. They support 6rd, and 4rd sits on top of it. The BR prefix /64 is supposed to be the one derived from IPv4 address 10.0.0.1 (i.e., 2001:db8:0:100:/64) 🧚.
Per [RFC5969], the 6rd BRs get these settings: IPv4MaskLen = 8, 6rdPrefix = 2001:db8::/32, and 6rdBRIPv4Address = 192.168.0.1 (0xc0a80001) 🍓.
The 4rd Mapping rules are then:
{198.16.0.0/16, 24, 2001:db8:0:0:300::/80}
{0.0.0.0/0, 32, 2001:db8:0:100:300:/80,}Any customer device that supports 4rd in addition to 6rd can then use its assigned shared IPv4 address with 240 assigned ports 🔥.
If its NAT44 supports port forwarding for incoming IPv4 connectivity (statically, or dynamically with Universal Plug and Play (UPnP) and/or the NAT Port Mapping Protocol (NAT-PMP)), it can use that with ports from the assigned port set 👑. > This is the big win, bestie: that's a possibility that does not exist in Net-10 networks without 4rd/6rd 😭.
Acknowledgements 🫶
This specification has benefited over several years from independent proposals, questions, comments, constructive suggestions, and useful criticisms from numerous IETF contributors 💖. The authors would like to express recognition of all of these contributors, and especially the following, in alphabetical order by their first names: Behcet Sarikaya, Bing Liu, Brian Carpenter, Cameron Byrne, Congxiao Bao, Dan Wing, Derek Atkins, Erik Kline, Francis Dupont, Gabor Bajko, Hui Deng, Jacni Quin (who was an active coauthor of some earlier versions of this specification), James Huang, Jan Zorz, Jari Arkko, Kathleen Moriarty, Laurent Toutain, Leaf Yeh, Lorenzo Colitti, Marcello Bagnulo, Mark Townsley, Mohamed Boucadair, Nejc Skoberne, Olaf Maennel, Ole Troan, Olivier Vautrin, Peng Wu, Qiong Sun, Rajiv Asati, Ralph Droms, Randy Bush, Satoru Matsushima, Simon Perreault, Stuart Cheshire, Suresh Krishnan, Ted Lemon, Teemu Savolainen, Tetsuya Murakami, Tina Tsou, Tomek Mrugalski, Washam Fan, Wojciech Dec, Xiaohong Deng, Xing Li, and Yu Fu. ✨👑 Literally a whole squad.
Authors' Addresses 🦋
Remi Despres
RD-IPtech
3 rue du President Wilson
Levallois
France
Email: despres.remi@laposte.netSheng Jiang (editor)
Huawei Technologies Co., Ltd
Q14, Huawei Campus, No. 156 BeiQing Road
Hai-Dian District, Beijing 100095
China
Email: jiangsheng@huawei.comReinaldo Penno
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134
United States
Email: repenno@cisco.comYiu Lee
Comcast
One Comcast Center
Philadelphia, PA 19103
United States
Email: yiu_lee@cable.comcast.comGang Chen
China Mobile
29, Jinrong Avenue
Xicheng District, Beijing 100033
China
Email: phdgang@gmail.com, chengang@chinamobile.comMaoke Chen (a.k.a. Noriyuki Arai)
BBIX, Inc.
Tokyo Shiodome Building, Higashi-Shimbashi 1-9-1
Minato-ku, Tokyo 105-7310
Japan
Email: maoke@bbix.netThat's the whole RFC, bestie! 🌈💅 Thanks for reading, slay 👑
📦 where this page comes from
- ietf: rfc7600 2015-07
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms