RFC 6333
Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion
RFC 6333 🌸 Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion
okay bestie, this one is giving ✨ real-world networking drama ✨. it's an Internet Standards Track doc from the Internet Engineering Task Force (IETF), published in August 2011, with ISSN 2070-1721 💜 the authors are A. Durand (Juniper Networks), R. Droms (Cisco), J. Woodyatt (Apple), and Y. Lee (Comcast). the title block doesn't list anything it obsoletes or updates, so it's a fresh standard, no cap 🫶
Abstract 🦋
this doc takes another look at the dual-stack model and introduces Dual-Stack Lite 💅 the goal is to line up the costs and benefits of deploying IPv6 in service provider networks. the trick is that a broadband provider can share IPv4 addresses among customers by combining two well-known techs: IP in IP (IPv4-in-IPv6) and Network Address Translation (NAT) 🧚
Status of This Memo 🍓
this is an Internet Standards Track document, fr fr.
it's a product of the Internet Engineering Task Force (IETF) and represents the consensus of the IETF community. it got public review and was approved for publication by the Internet Engineering Steering Group (IESG). more info on Internet Standards is in Section 2 of RFC 5741.
for the current status, any errata, and how to give feedback, check http://www.rfc-editor.org/info/rfc6333 💖
Copyright Notice 🎀
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
this doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as in effect on the date of publication. please read these carefully because they spell out your rights and restrictions. Code Components pulled out of this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty as described in the Simplified BSD License 🫶
Table of Contents 📚
1. Introduction ....................................................3
2. Requirements Language ...........................................4
3. Terminology .....................................................4
4. Deployment Scenarios ............................................4
4.1. Access Model ...............................................4
4.2. CPE ........................................................5
4.3. Directly Connected Device ..................................6
5. B4 Element ......................................................7
5.1. Definition .................................................7
5.2. Encapsulation ..............................................7
5.3. Fragmentation and Reassembly ...............................7
5.4. AFTR Discovery .............................................7
5.5. DNS ........................................................8
5.6. Interface Initialization ...................................8
5.7. Well-Known IPv4 Address ....................................8
6. AFTR Element ....................................................9
6.1. Definition .................................................9
6.2. Encapsulation ..............................................9
6.3. Fragmentation and Reassembly ...............................9
6.4. DNS .......................................................10
6.5. Well-Known IPv4 Address ...................................10
6.6. Extended Binding Table ....................................10
7. Network Considerations .........................................10
7.1. Tunneling .................................................10
7.2. Multicast Considerations ..................................10
8. NAT Considerations .............................................11
8.1. NAT Pool ..................................................11
8.2. NAT Conformance ...........................................11
8.3. Application Level Gateways (ALGs) .........................11
8.4. Sharing Global IPv4 Addresses .............................11
8.5. Port Forwarding / Keep Alive ..............................11
9. Acknowledgements ...............................................12
10. IANA Considerations ...........................................12
11. Security Considerations .......................................12
12. References ....................................................13
12.1. Normative References .....................................13
12.2. Informative References ...................................14
Appendix A. Deployment Considerations .............................16
A.1. AFTR Service Distribution and Horizontal Scaling ...........16
A.2. Horizontal Scaling .........................................16
A.3. High Availability ..........................................16
A.4. Logging ....................................................16
Appendix B. Examples ..............................................17
B.1. Gateway-Based Architecture .................................17
B.1.1. Example Message Flow ...................................19
B.1.2. Translation Details ....................................23
B.2. Host-Based Architecture ....................................24
B.2.1. Example Message Flow ...................................27
B.2.2. Translation Details ....................................311. Introduction 🌈
okay so the common thinking for more than 10 years was that the move to IPv6 would happen purely through the dual-stack model, and that most things would get converted that way before we ran out of IPv4. 💀 that did NOT happen. the IANA free pool of IPv4 addresses is now depleted, way before enough IPv6 deployment had taken place. so lots of IPv4 services still have to keep running even with severely limited address space 😭
this doc specifies Dual-Stack Lite, which is all about better aligning costs and benefits in service provider networks. Dual-Stack Lite keeps IPv4 services going and gives people a reason to deploy IPv6. it also de-couples IPv6 deployment in the service provider network from the rest of the Internet, which makes incremental deployment way easier 🦋
the core move: a broadband service provider can share IPv4 addresses among customers by combining two well-known technologies, IP in IP (IPv4-in-IPv6) and Network Address Translation (NAT) ✨
this doc makes a distinction between a dual-stack-capable device and a dual-stack-provisioned device. the first one has code that implements both IPv4 and IPv6, from the network layer all the way up to the applications. the second is a similar device that has been provisioned with both an IPv4 and an IPv6 address on its interface(s). the doc also refines this a bit by separating interfaces provisioned directly by the service provider from ones provisioned by the customer 💅
pure IPv6-only devices (ones that don't include an IPv4 stack) are outside the scope of this document 🙈
the plan: first some deployment scenarios, then the behaviour of the two elements of Dual-Stack Lite, the Basic Bridging BroadBand (B4) element and the Address Family Transition Router (AFTR) element. after that, it gets into networking and NAT-ing considerations 🫶
2. Requirements Language 🎀
okay the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be read as described in RFC 2119 [RFC2119] 💖
3. Terminology 🧚
the tech in this doc is known as Dual-Stack Lite, and the abbreviation "DS-Lite" gets used throughout 💜
this doc also introduces two new terms: the DS-Lite Basic Bridging BroadBand (B4) element and the DS-Lite Address Family Transition Router (AFTR) element 🦋
Dual-stack is defined in [RFC4213].
NAT-related terminology is defined in [RFC4787].
CPE stands for Customer Premise Equipment. that's the layer 3 device in the customer premise that connects to the service provider network. it's often a home gateway 🏠 but sometimes computers are directly attached to the service provider network, and in that case those computers can be viewed as CPEs too 💅
4. Deployment Scenarios 🍓
4.1. Access Model ✨
okay so instead of relying on a cascade of NATs, the Dual-Stack Lite model is built on IPv4-in-IPv6 tunnels. the tunnels cross the network to reach a carrier-grade IPv4-IPv4 NAT (the AFTR), and that's where customers share IPv4 addresses 👑 there are a few big benefits here:
- this tech decouples the deployment of IPv6 in the service provider network (up to the customer premise equipment or CPE) from the deployment of IPv6 in the global Internet and in customer applications and devices. 🌸
- managing the service provider access networks gets simpler by leveraging the large IPv6 address space. overlapping private IPv4 address spaces aren't required to support very large customer bases. 🧚
- since tunnels can terminate anywhere in the service provider network, this architecture lends itself to horizontal scaling and gives some flexibility to adapt to changing traffic load. more discussion of horizontal scaling is in Appendix A. 📈
- tunnels provide a direct connection between B4 and the AFTR. this can be leveraged so customers and their applications can control how the NAT function of the AFTR is performed. 🫶
the key characteristic of this approach is that communications between end-nodes stay within their address family. IPv6 sources only talk to IPv6 destinations, and IPv4 sources only talk to IPv4 destinations 🦋 there's no protocol family translation involved, which makes life way easier for applications that carry literal IP addresses in their payloads 💅✨
4.2. CPE ✨
okay so this section is about home LANs with a home gateway (aka the CPE 🏠), and the service provider only gives that box IPv6. it's giving "IPv6 only, figure it out" 💅
a DS-Lite CPE is an IPv6-aware CPE with a B4 interface living on its WAN side 🦋
bestie, a DS-Lite CPE SHOULD NOT run a NAT function between its internal interface and the B4 interface 🙅♀️ bc the AFTR in the service provider's network is the one doing NAT. doing it twice would be a double-NAT disaster, and nobody wants that 😭
BUT it SHOULD still run its own DHCP(v4) server 🎀 handing out [RFC1918] address space (like 192.168.0.0/16) to the home hosts. it SHOULD tell those hosts it's their default IPv4 router, and it SHOULD also list itself as a DNS server using DHCP Option 6 (DNS Server). on top of that, it SHOULD run a DNS proxy 🧚 that takes DNS IPv4 requests from home hosts and sends them over IPv6 to the service provider's DNS servers, as covered in Section 5.5.
Note: if an IPv4 home host decides to go use some other IPv4 DNS server, the DS-Lite CPE forwards those DNS requests through the B4 interface, same as any other regular IPv4 packet. but every DNS request creates a binding in the AFTR, and a huge pile of them can seriously eat into the AFTR's NAT table utilization 💀
IPv6-capable devices go straight to the IPv6 Internet 🌈 their packets just follow IPv6 routing. they don't touch the tunnel and nobody translates them. it's expected that most IPv6-capable devices are also IPv4 capable, so they'll just get an IPv4 [RFC1918]-style address inside the home and reach the IPv4 Internet the same way the legacy IPv4-only devices do ✨
pure IPv6-only devices (ones with no IPv4 stack at all) are outside the scope of this doc 🙈
4.3. Directly Connected Device
in broadband home networks, some devices plug straight into the broadband service provider 🔌 no home gateway in the middle. they're hooked right up to a modem, so they're basically acting as CPEs themselves 👑
in this setup, the customer device is a dual-stack-capable host that the service provider provisions with IPv6 only. the device itself acts as a B4 element, and its IPv4 service comes through an IPv4-in-IPv6 tunnel, just like in the home gateway/CPE case. it can run any combination of IPv4 and/or IPv6 applications, which is so iconic 🔥
a directly connected DS-Lite device SHOULD send its DNS requests over IPv6 to the IPv6 DNS server it's been configured to use 🫶
same vibe as the earlier sections: IPv6 packets follow IPv6 routing, they don't go through the tunnel, and they aren't subject to any translation 🦋
supporting IPv4-only devices and IPv6-only devices in this scenario is out of scope for this document 💅
5. B4 Element
5.1. Definition
the B4 element is a function that lives on a dual-stack-capable node, either a directly connected device or a CPE. its whole job is to create a tunnel to an AFTR 🚇✨
5.2. Encapsulation
the tunnel is a multipoint-to-point IPv4-in-IPv6 tunnel that ends on a service provider AFTR 🎀
check Section 7.1 for more tunneling considerations, bestie 💖
Note: right now DS-Lite only defines IPv4-in-IPv6 tunnels, but other types of encapsulation could be defined in the future 🔮
5.3. Fragmentation and Reassembly
wrapping IPv4 traffic in an encapsulation (IPv4-in-IPv6 or anything else) to send it over IPv6 shrinks the effective MTU of the datagram 😤 and sadly, path MTU discovery [RFC1191] is not a reliable way to deal with that 💀
one fix is for the service provider to raise the MTU of every link between the B4 element and the AFTR elements by at least 40 bytes 🍓 that's enough room for the IPv6 encapsulation header plus the IPv4 datagram, so the IPv6 packet doesn't need fragmenting.
BUT not every service provider can bump their link MTU, so the B4 element MUST perform fragmentation and reassembly when the outgoing link MTU can't fit the extra IPv6 header. the original IPv4 packet isn't oversized 🙅♀️ it only gets oversized after the IPv6 encapsulation. the inner IPv4 packet MUST NOT be fragmented. fragmentation MUST happen after the IPv6 encapsulation of the packet, and reassembly MUST happen before the IPv4 packet is decapsulated. the detailed procedure is specified in [RFC2473] Section 7.2 📚
5.4. AFTR Discovery
to set up the IPv4-in-IPv6 tunnel, the B4 element needs the IPv6 address of the AFTR element 🗺️ that address can be configured in a bunch of ways: out-of-band, manual config, or a variety of DHCPv6 options. so many options, it's giving buffet 🍽️
to guarantee interoperability, a B4 element SHOULD implement the DHCPv6 option defined in [RFC6334] 🫶
5.5. DNS
a B4 element only gets configured by the service provider with IPv6 🌸 so the only way it can learn a DNS recursive server's address is through DHCPv6 (or some other similar IPv6 method). DHCPv6 only defines an option for the IPv6 address of that recursive server, so the B4 element can't easily find the IPv4 address of it. which means it has to do all DNS resolution over IPv6 🧚
the B4 element can hand that IPv6 address down to downstream IPv6 nodes, but NOT to downstream IPv4 nodes. (sorry, IPv4 nodes, the B4 element is not giving you the address 😭) so the B4 element SHOULD implement a DNS proxy, following the recommendations of [RFC5625] ✨
if you've got a security-aware resolver behind the B4 element, the DNS proxy in the B4 element must also be security aware. the details are in [RFC4033] Section 6 🔐
5.6. Interface Initialization
the B4 element can be implemented in a host and a CPE alongside other technologies, like native dual-stack 🌈 but the host and the CPE SHOULD select to start only one technology during initialization. for example, if the CPE picks native dual-stack mode, it SHOULD NOT initialize the B4 element 🙅♀️ how they pick is out of scope for this document 💅
5.7. Well-Known IPv4 Address
any locally unique IPv4 address could be configured on the IPv4-in-IPv6 tunnel to represent the B4 element 🦋 this is often needed when the B4 element is sourcing IPv4 datagrams directly over the tunnel. to avoid clashing with any other address, IANA has set aside a well-known range, 192.0.0.0/29 👑
192.0.0.0 is the reserved subnet address. 192.0.0.1 is reserved for the AFTR element, and 192.0.0.2 is reserved for the B4 element 🎀 if a service provider has a special configuration that stops the B4 element from using 192.0.0.2, the B4 element MAY use any other address in the 192.0.0.0/29 range instead.
Note: a whole range of addresses has been reserved for this purpose. the goal is to make room for nodes that run multiple B4 elements 🧚♀️
6. AFTR Element
6.1. Definition
an AFTR element is the combination of an IPv4-in-IPv6 tunnel endpoint and an IPv4-IPv4 NAT, both running on the same node 🏗️ the whole main character setup 👑
6.2. Encapsulation
the tunnel is a point-to-multipoint IPv4-in-IPv6 tunnel that ends at the B4 elements 🌈
see Section 7.1 for more tunneling considerations 💖
Note: right now DS-Lite only defines IPv4-in-IPv6 tunnels, but other types of encapsulation could be defined in the future 🔮
6.3. Fragmentation and Reassembly
like we said before, fragmentation and reassembly have to be handled by the tunnel endpoints 🫶 so the AFTR MUST perform fragmentation and reassembly when the underlying link MTU can't handle the encapsulation overhead. fragmentation MUST happen after the IPv6 encapsulation of the packet, and reassembly MUST happen before the IPv6 header is decapsulated. the detailed procedure is specified in [RFC2473] Section 7.2 📚
fragmenting at the Tunnel Entry-Point is a lightweight operation 🍃 but reassembly at the Tunnel Exit-Point can get expensive 😭 when the Tunnel Exit-Point gets the first fragmented packet, it must wait for the second fragmented packet to show up so it can reassemble the two fragmented IPv6 packets for decapsulation. that means the Tunnel Exit-Point has to buffer and keep track of fragmented packets 🧠
now consider that the AFTR is the Tunnel Exit-Point for many tunnels. if lots of devices all send a big pile of fragmented packets through the AFTR to its managed B4 elements at the same time, the AFTR has to buffer and burn through enormous resources just to track all those flows 💀 this reassembly work can seriously hit the AFTR's performance. BUT that only happens when lots of clients are sourcing large IPv4 packets at once. the authors believe most clients RECEIVE large IPv4 packets (like watching video streams) instead of SOURCING them (like streaming video out), so reassembly is only a fraction of the AFTR's overall workload 🎬
when the AFTR's resources drop below a pre-defined threshold, the AFTR SHOULD send a notification to the administrator before the resources are completely used up 🚨 the threshold and notification procedures are implementation dependent and out of scope for this document.
methods for avoiding fragmentation, like rewriting the TCP Maximum Segment Size (MSS) option or using technologies such as the Subnetwork Encapsulation and Adaptation Layer defined in [RFC5320], are out of scope for this document 🙈
6.4. DNS
like we said before, a DS-Lite node running a B4 element does its DNS resolution over IPv6 🌸 so DNS packets aren't expected to go through the AFTR element at all 💅
6.5. Well-Known IPv4 Address
the AFTR SHOULD use the well-known IPv4 address 192.0.0.1, which IANA reserved, to configure the IPv4-in-IPv6 tunnel 🦋 that address can then be used to report ICMP problems, and it'll show up in traceroute outputs too 🗺️
6.6. Extended Binding Table
the NAT binding table of the AFTR element gets extended to include the source IPv6 address of the incoming packets 🪪 that IPv6 address is used to tell apart the overlapping IPv4 address space of the service provider's customers. it's literally how the AFTR knows who's who 👑
by doing a reverse lookup in the extended IPv4 NAT binding table, the AFTR knows how to rebuild the IPv6 encapsulation when packets come back from the Internet ✨ that means there's no need for a static configuration for each tunnel 🙌
7. Network Considerations
7.1. Tunneling
tunneling MUST be done in accordance with [RFC2473] and [RFC4213] 📦 and traffic classes ([RFC2474]) from the IPv4 headers MUST be carried over to the IPv6 headers and vice versa 🍓 no dropping the vibes in either direction 💖
7.2. Multicast Considerations
discussion of multicast is out of scope for this document 🙈
8. NAT Considerations
8.1. NAT Pool
the AFTR MAY be provisioned with different NAT pools 🏊♀️ the address ranges in those pools may be disjoint, but they MUST NOT overlap 🙅♀️ operators can set up policies on the AFTR to assign clients to different pools. for example, an AFTR can have two interfaces, and each interface gets its own disjoint NAT pool 🔥 or a policy might say one set of B4s uses NAT pool 1 while a different set uses NAT pool 2 🧚
8.2. NAT Conformance
okay so a Dual-Stack Lite AFTR MUST act like the best current practice says it should 🎀 The current version of that practice is written down in [RFC4787], [RFC5508], and [RFC5382]. If you want more tea on carrier-grade NATs, check [LSN-REQS] 🧚
8.3. Application Level Gateways (ALGs)
the AFTR does NAT-44, which means it inherits all the NAT drama 💀 Some protocols need an ALG sitting in the NAT box so they can get through, and Active FTP is the classic example, since it only works properly with an ALG 😭 ALGs eat resources, and there are SO many different kinds. The AFTR is a shared device serving a huge number of B4 elements, so it's literally impossible for it to implement every ALG that exists now or ever will 🫶
8.4. Sharing Global IPv4 Addresses
the AFTR shares one IP with a bunch of users at once, which is a major win because it helps squeeze more out of IPv4 addresses 🦋 But it also brings some messy stuff like logging and lawful intercept, so it's not all sunshine 🌸 If you want the deep dive on sharing the port space of IPv4 addresses, check [RFC6269].
8.5. Port Forwarding / Keep Alive
the PCP working group is building a control plane for the carrier-grade NAT [LSN-REQS] in the IETF, and it's giving main character energy 👑 The Port Control Protocol (PCP) lets applications negotiate with the NAT directly so they can open ports and agree on lifetime values, which means they can skip sending keep-alive traffic 💅 More on PCP lives in [PCP-BASE].
9. Acknowledgements ✨
The authors want to shout out Mark Townsley 🫶 He helped shape the overall architecture of this tech by pointing the work toward [SNAT]. This document is basically the result of merging [DURAND-DS-LITE] and [SNAT], so that's a whole team effort 🌈 They also gave a huge thank you to Shin Miyakawa, Katsuyasu Toyama, Akihide Hiura, Takashi Uematsu, Tetsutaro Hara, Yasunori Matsubayashi, and Ichiro Mizukoshi for all the convos. Thanks as well to David Ward, Jari Arkko, Thomas Narten, and Geoff Huston for their constructive feedback 💖 And a special shoutout to Dave Thaler and Dan Wing for their reviews and comments, you two are iconic 👑
10. IANA Considerations 🦋
So basically, IANA handed out the well-known IPv4 prefix 192.0.0.0/29 for this document 🎀 That range is used to number the Dual-Stack Lite interfaces. Reserving a /29 gives you room for 6 possible interfaces on a multi-home node, which is honestly so generous 🍓 The IPv4 address 192.0.0.1 is reserved as the IPv4 address of the default router for these Dual-Stack Lite hosts.
11. Security Considerations 🔥
okay this section is serious bestie, so pay attention 🙈 Security issues tied to NAT have been documented for ages. Check out [RFC2663] and [RFC2993] if you want the history.
Here's the twist 😱 Moving the NAT functionality out of the CPE and into the core of the service provider network, and sharing IPv4 addresses between customers, creates extra requirements for logging when there's abuse. In any setup where an IPv4 address doesn't uniquely point to one end host, the IPv4 address and a timestamp just aren't enough to identify a specific broadband customer 💀 The AFTR should have the ability to log the tunnel-id, protocol, ports/IP addresses, and the creation time of the NAT binding so it can uniquely identify user sessions. What exactly gets logged is up to the implementation and out of scope for this document, so no judgment there 🫶
The AFTR does translation for interior IPv4 hosts that use RFC 1918 addresses or the IANA reserved range (192.0.0.0/29). Sometimes an ISP sets policies on the AFTR and tells it to skip translation for traffic matching <IPv4 Address, port number, protocol>. When the AFTR gets a packet from an interior host that matches one of those policies, it can just forward the packet without translating it 🧚 The addresses, ports, and protocol info must be provisioned on the AFTR before the packet shows up. How that provisioning happens is out of scope for this spec ✨
Now the part that matters most 😭 When decapsulating packets, the AFTR MUST only forward packets whose source is an RFC 1918 address, an IANA reserved address range, or any other out-of-band pre-authorized address. The AFTR MUST drop every other packet 🚫 This stops rogue devices from launching denial-of-service attacks with unauthorized public IPv4 addresses in the IPv4 source header field, or an unauthorized transport port range in the IPv4 transport header field. For example, rogue devices could bombard a public web server with a TCP SYN ACK attack [RFC4987]. The victim would get TCP SYNs from random IPv4 source addresses at a rapid rate, and that would deny TCP services to legitimate users 💔
With IPv4 addresses shared by multiple users, ports become a critical resource 🍓 So the AFTR needs some mechanisms to limit port usage, either by rate-limiting new connections or by putting a hard limit on the maximum number of ports one user can use. If that number is high enough, it shouldn't interfere with normal usage, and it should still protect the shared pool reasonably well 🛡️ More considerations on sharing IPv4 addresses are in [RFC6269], and other logging considerations and recommendations are in [RFC6302] 📚
AFTRs should support ways to limit service to registered customers 🎀 One simple option is to set up an IPv6 ingress filter on the AFTR's tunnel interface so it only accepts the IPv6 address range defined in the filter 💜
12. References 📚
12.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in
IPv6 Specification", RFC 2473, December 1998.
[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,
December 1998.
[RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition
Mechanisms for IPv6 Hosts and Routers", RFC 4213,
October 2005.
[RFC5625] Bellis, R., "DNS Proxy Implementation Guidelines",
BCP 152, RFC 5625, August 2009.
[RFC6334] Hankins, D. and T. Mrugalski, "Dynamic Host Configuration
Protocol for IPv6 (DHCPv6) Option for Dual-Stack Lite",
RFC 6334, August 2011.12.2. Informative References
[DURAND-DS-LITE]
Durand, A., "Dual-stack lite broadband deployments post
IPv4 exhaustion", Work in Progress, July 2008.
[LSN-REQS] Perreault, S., Ed., Yamagata, I., Miyakawa, S., Nakagawa,
A., and H. Ashida, "Common requirements for Carrier Grade
NAT (CGN)", Work in Progress, July 2011.
[PCP-BASE] Wing, D., Ed., Cheshire, S., Boucadair, M., Penno, R.,
and P. Selkirk, "Port Control Protocol (PCP)", Work
in Progress, July 2011.
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
November 1990.
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.,
and E. Lear, "Address Allocation for Private Internets",
BCP 5, RFC 1918, February 1996.
[RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address
Translator (NAT) Terminology and Considerations",
RFC 2663, August 1999.
[RFC2993] Hain, T., "Architectural Implications of NAT", RFC 2993,
November 2000.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements",
RFC 4033, March 2005.
[RFC4787] Audet, F., Ed., and C. Jennings, "Network Address
Translation (NAT) Behavioral Requirements for Unicast
UDP", BCP 127, RFC 4787, January 2007.
[RFC4987] Eddy, W., "TCP SYN Flooding Attacks and Common
Mitigations", RFC 4987, August 2007.
[RFC5320] Templin, F., Ed., "The Subnetwork Encapsulation and
Adaptation Layer (SEAL)", RFC 5320, February 2010.
[RFC5382] Guha, S., Ed., Biswas, K., Ford, B., Sivakumar, S., and
P. Srisuresh, "NAT Behavioral Requirements for TCP",
BCP 142, RFC 5382, October 2008.
[RFC5508] Srisuresh, P., Ford, B., Sivakumar, S., and S. Guha, "NAT
Behavioral Requirements for ICMP", BCP 148, RFC 5508,
April 2009.
[RFC5571] Storer, B., Pignataro, C., Ed., Dos Santos, M., Stevant,
B., Ed., Toutain, L., and J. Tremblay, "Softwire Hub and
Spoke Deployment Framework with Layer Two Tunneling
Protocol Version 2 (L2TPv2)", RFC 5571, June 2009.
[RFC6269] Ford, M., Boucadair, M., Durand, A., Levis, P., and P.
Roberts, "Issues with IP Address Sharing", RFC 6269,
June 2011.
[RFC6302] Durand, A., Gashinsky, I., Lee, D., and S. Sheppard,
"Logging Recommendations for Internet-Facing Servers",
BCP 162, RFC 6302, June 2011.
[SNAT] Droms, R. and B. Haberman, "Softwires Network Address
Translation (SNAT)", Work in Progress, July 2008.Appendix A. Deployment Considerations 🧚
A.1. AFTR Service Distribution and Horizontal Scaling
the big win with Dual-Stack Lite is that it's a tunnel-based solution, so tunnel endpoints can live anywhere in the service provider network 🦋
If you use the DHCPv6 tunnel endpoint option [RFC6334], service providers can make groups of users that share the same AFTR 💖 Those groups can be merged or split whenever they want. This gives you a horizontally scaled setup, where you just add more AFTRs to get more capacity ✨ Since those groups can change over time, it's best to make sure AFTRs don't need per-user configuration to provide service 🫶
A.2. Horizontal Scaling
a service provider can start with just a few centralized AFTRs 🌸 Later, when more capacity is needed, more AFTRs can get added and pushed closer to the edges of the access network 🍓
A.3. High Availability
the big deal with Dual-Stack Lite is how simple it is on the customer side 🎀 An IP4-in-IPv6 tunnel and a default route over it in the B4 element are all you need to get IPv4 connectivity. High availability is assumed to be the service provider's job, not the customer devices' job 💅 So a single IPv6 address of the tunnel endpoint is provided in the DHCPv6 option defined in [RFC6334]. How the service provider actually achieves high availability is outside the scope of this specification 🫶
A.4. Logging
a DS-Lite AFTR implementation should offer the ability to log NAT binding creations, or other ways to track the ports/IP addresses used by customers 📚 This helps with troubleshooting, which matters a lot to service providers trying to figure out why something isn't working. It also helps meet region-specific requirements for answering legally binding requests for information from law enforcement authorities 👑
Appendix B. Examples 💜
B.1. Gateway-Based Architecture ✨
okay so this one is aimed at home internet setups 🏠, but it's easy to adapt to other deployments where a whole pile of IPv4-only devices already exists and nobody's ditching them anytime soon 💅. The installed base matters, bestie.
Picture this: a Dual-Stack Lite CPE that's only provisioned with IPv6 on its WAN port, no IPv4 at all 🌸. The CPE acts as an IPv4 DHCP server for the LAN (wireline and wireless), handing out [RFC1918] addresses. It may also support IPv6 Auto-Configuration and/or a DHCPv6 server for the LAN. When an IPv4-only device connects, the CPE gives it a [RFC1918] address. When a dual-stack-capable device connects, the CPE gives it a [RFC1918] address and a global IPv6 address 🫶. On top of that, the CPE creates an IPv4-in-IPv6 softwire tunnel [RFC5571] to an AFTR sitting in the service provider network.
When the device wants IPv6 service, it sends the IPv6 datagram to the CPE natively, and the CPE routes that traffic upstream to the IPv6 default gateway 🦋.
When the device wants IPv4 service, it sources the IPv4 datagram with its [RFC1918] address and sends it to the CPE. The CPE encapsulates that IPv4 datagram inside the IPv4-in-IPv6 softwire tunnel and forwards the resulting IPv6 datagram to the AFTR. This is a plot twist compared to what CPEs usually do today, which is NAT the [RFC1918] address to the public IPv4 address and route the datagram upstream 👀. When the AFTR receives the IPv6 datagram, it decapsulates the IPv6 header and performs an IPv4-to-IPv4 NAT on the source address 💜.
So the Dual-Stack Lite deployment model has three components, as shown in Figure 1: the Dual-Stack Lite home router with a B4 element, the AFTR, and a softwire between them. The B4 element is the softwire initiator (SI) [RFC5571] in the home router, and the softwire concentrator (SC) [RFC5571] lives in the AFTR. The AFTR does IPv4-IPv4 NAT translations to multiplex multiple subscribers through a pool of global IPv4 addresses, and the overlapping address spaces that subscribers use get sorted out by identifying the tunnel endpoints 🧚.
+-----------+
| Host |
+-----+-----+
|10.0.0.1
|
|
|10.0.0.2
+---------|---------+
| | |
| Home router |
|+--------+--------+|
|| B4 ||
|+--------+--------+|
+--------|||--------+
|||2001:db8:0:1::1
|||
|||<-IPv4-in-IPv6 softwire
|||
-------|||-------
/ ||| \
| ISP core network |
\ ||| /
-------|||-------
|||
|||2001:db8:0:2::1
+--------|||--------+
| AFTR |
|+--------+--------+|
|| Concentrator ||
|+--------+--------+|
| |NAT| |
| +-+-+ |
+---------|---------+
|192.0.2.1
|
--------|--------
/ | \
| Internet |
\ | /
--------|--------
|
|198.51.100.1
+-----+-----+
| IPv4 Host |
+-----------+
Figure 1: Gateway-Based ArchitectureSome notes to keep in your back pocket 📝:
- The Dual-Stack Lite home router is not required to be on the same link as the host.
- The Dual-Stack Lite home router could be replaced by a Dual-Stack Lite router in the service provider network.
The end result is that an IPv4 datagram gets translated into an IPv4-in-IPv6 softwire datagram for its trip across the softwire 🚀. At the other end, the IPv4 datagram is decapsulated, and the translated IPv4 address is inserted based on a translation from the softwire. Iconic. 😭
B.1.1. Example Message Flow
okay, let's walk through the example in Figure 2 🎀. Here the translation tables in the AFTR are set up to forward between IP/TCP (10.0.0.1/10000) and IP/TCP (192.0.2.1/5000). So a datagram that the Dual-Stack Lite home router gets from the host at 10.0.0.1, using TCP DST port 10000, gets translated into a datagram with IPv4 SRC address 192.0.2.1 and TCP SRC port 5000 out on the Internet 💖.
+-----------+
| Host |
+-----+-----+
| |10.0.0.1
IPv4 datagram 1 | |
| |
v |10.0.0.2
+---------|---------+
| | |
| home router |
|+--------+--------+|
|| B4 ||
|+--------+--------+|
+--------|||--------+
| |||2001:db8:0:1::1
IPv6 datagram 2| |||
| |||<-IPv4-in-IPv6 softwire
-----|-|||-------
/ | ||| \
| ISP core network |
\ | ||| /
-----|-|||-------
| |||
| |||2001:db8:0:2::1
+------|-|||--------+
| | AFTR |
| v ||| |
|+--------+--------+|
|| Concentrator ||
|+--------+--------+|
| |NAT| |
| +-+-+ |
+---------|---------+
| |192.0.2.1
IPv4 datagram 3 | |
| |
-----|--|--------
/ | | \
| Internet |
\ | | /
-----|--|--------
| |
v |198.51.100.1
+-----+-----+
| IPv4 Host |
+-----------+
Figure 2: Outbound Datagram +-----------------+--------------+-----------------+
| Datagram | Header field | Contents |
+-----------------+--------------+-----------------+
| IPv4 datagram 1 | IPv4 Dst | 198.51.100.1 |
| | IPv4 Src | 10.0.0.1 |
| | TCP Dst | 80 |
| | TCP Src | 10000 |
| --------------- | ------------ | ------------- |
| IPv6 datagram 2 | IPv6 Dst | 2001:db8:0:2::1 |
| | IPv6 Src | 2001:db8:0:1::1 |
| | IPv4 Dst | 198.51.100.1 |
| | IPv4 Src | 10.0.0.1 |
| | TCP Dst | 80 |
| | TCP Src | 10000 |
| --------------- | ------------ | ------------- |
| IPv4 datagram 3 | IPv4 Dst | 198.51.100.1 |
| | IPv4 Src | 192.0.2.1 |
| | TCP Dst | 80 |
| | TCP Src | 5000 |
+-----------------+--------------+-----------------+
Datagram Header ContentsSo when datagram 1 hits the Dual-Stack Lite home router, the B4 element wraps it up in datagram 2 and sends it along to the Dual-Stack Lite carrier-grade NAT over the softwire 🧚♀️.
When the tunnel concentrator in the AFTR gets datagram 2, it passes the IPv4 datagram on to the NAT. The NAT checks its NAT table and sees that a datagram received on the softwire with TCP SRC port 10000 should be translated into datagram 3, with IPv4 SRC address 192.0.2.1 and TCP SRC port 5000 🌈.
Now for the inbound direction, shown in Figure 3 📥. When the NAT function in the AFTR receives datagram 1, it looks up the IP/TCP DST information in its translation table. In this example, the NAT changes the TCP DST port to 10000, sets the IP DST address to 10.0.0.1, and forwards the datagram to the softwire. Then the B4 in the home router decapsulates the IPv4 datagram from the inbound softwire datagram and forwards it to the host 🍓.
+-----------+
| Host |
+-----+-----+
^ |10.0.0.1
IPv4 datagram 3 | |
| |
| |10.0.0.2
+---------|---------+
| +-+-+ |
| home router |
|+--------+--------+|
|| B4 ||
|+--------+--------+|
+--------|||--------+
^ |||2001:db8:0:1::1
IPv6 datagram 2 | |||
| |||<-IPv4-in-IPv6 softwire
| |||
-----|-|||-------
/ | ||| \
| ISP core network |
\ | ||| /
-----|-|||-------
| |||
| |||2001:db8:0:2::1
+------|-|||--------+
| AFTR |
|+--------+--------+|
|| Concentrator ||
|+--------+--------+|
| |NAT| |
| +-+-+ |
+---------|---------+
^ |192.0.2.1
IPv4 datagram 1 | |
| |
-----|--|--------
/ | | \
| Internet |
\ | | /
-----|--|--------
| |
| |198.51.100.1
+-----+-----+
| IPv4 Host |
+-----------+
Figure 3: Inbound Datagram +-----------------+--------------+-----------------+
| Datagram | Header field | Contents |
+-----------------+--------------+-----------------+
| IPv4 datagram 1 | IPv4 Dst | 192.0.2.1 |
| | IPv4 Src | 198.51.100.1 |
| | TCP Dst | 5000 |
| | TCP Src | 80 |
| --------------- | ------------ | ------------- |
| IPv6 datagram 2 | IPv6 Dst | 2001:db8:0:1::1 |
| | IPv6 Src | 2001:db8:0:2::1 |
| | IPv4 Dst | 10.0.0.1 |
| | IPv4 Src | 198.51.100.1 |
| | TCP Dst | 10000 |
| | TCP Src | 80 |
| --------------- | ------------ | ------------- |
| IPv4 datagram 3 | IPv4 Dst | 10.0.0.1 |
| | IPv4 Src | 198.51.100.1 |
| | TCP Dst | 10000 |
| | TCP Src | 80 |
+-----------------+--------------+-----------------+
Datagram Header ContentsB.1.2. Translation Details ✨
okay so the AFTR has a NAT that swaps softwire/port pairs for IPv4-address/port pairs, and back again 💅 The same translation gets applied to IPv4 datagrams coming in on the device's external interface and to the ones coming from the softwire endpoint inside the device 🦋
In Figure 2, the translator's network interface in the AFTR sits on the Internet, and the softwire interface connects to the Dual-Stack Lite home router. The AFTR translator is set up like this 🎀
- Network interface: Translate IPv4 destination address and TCP destination port to the softwire identifier and TCP destination port
- Softwire interface: Translate softwire identifier and TCP source port to IPv4 source address and TCP source port
Here's how the translation in Figure 3 plays out 🌸
- Datagram 1 is received on the AFTR translator network interface. The translator looks up the IPv4-address/port pair in its translator table, rewrites the IPv4 destination address to 10.0.0.1 and the TCP source port to 10000, and forwards the datagram to the softwire.
- The IPv4 datagram is received on the Dual-Stack Lite home router B4. The B4 function extracts the IPv4 datagram, and the Dual-Stack Lite home router forwards datagram 3 to the host.
+------------------------------------+--------------------+
| Softwire-Id/IPv4/Prot/Port | IPv4/Prot/Port |
+------------------------------------+--------------------+
| 2001:db8:0:1::1/10.0.0.1/TCP/10000 | 192.0.2.1/TCP/5000 |
+------------------------------------+--------------------+
Dual-Stack Lite Carrier-Grade NAT Translation TableThe Softwire-Id is the IPv6 address assigned to the Dual-Stack Lite CPE 🧚 Hosts behind the same Dual-Stack Lite home router have the same Softwire-Id. The source IPv4 address is the [RFC1918] address assigned by the Dual-Stack home router, and it's unique to each host behind the CPE. The AFTR would receive packets sourced from different IPv4 addresses in the same softwire tunnel 👑 The AFTR combines the Softwire-Id and IPv4 address/port [Softwire-Id, IPv4+ Port] to uniquely identify the host behind the same Dual-Stack Lite home router. Main character energy for sure 💜
B.2. Host-Based Architecture
this architecture is targeted at new, large-scale deployments of dual-stack-capable devices implementing a Dual-Stack Lite interface 🍓
Picture this: a Dual-Stack Lite host device is directly connected to the service provider network 🌈 The host device is dual-stack capable but only provisioned with an IPv6 global address. Besides, the host device will pre-configure a well-known IPv4 non-routable address; see Section 10 (IANA Considerations). This well-known IPv4 non-routable address is similar to the 127.0.0.1 loopback address. Every host device that implements Dual-Stack Lite will pre-configure the same address. This address will be used to source the IPv4 datagram when the device accesses IPv4 services. Besides, the host device will create an IPv4-in-IPv6 softwire tunnel to an AFTR. The carrier-grade NAT will reside in the service provider network 🫶
When the device accesses IPv6 service, the device will send the IPv6 datagram natively to the default gateway ✨
When the device accesses IPv4 service, it will source the IPv4 datagram with the well-known non-routable IPv4 address. Then, the host device will encapsulate the IPv4 datagram inside the IPv4-in-IPv6 softwire tunnel and send the IPv6 datagram to the AFTR. When the AFTR receives the IPv6 datagram, it will decapsulate the IPv6 header and perform IPv4-to-IPv4 NAT on the source address 🔥
This scenario works on both wireline and wireless networks. A typical wireless device will connect directly to the service provider without a CPE in between 📱
As illustrated in Figure 4, this Dual-Stack Lite deployment model is made of three components: the Dual-Stack Lite host, the AFTR, and a softwire between the softwire initiator B4 in the host and the softwire concentrator in the AFTR. The Dual-Stack Lite host is assumed to have IPv6 service and can exchange IPv6 traffic with the AFTR 🦋
The AFTR performs IPv4-IPv4 NAT translations to multiplex multiple subscribers through a pool of global IPv4 addresses. Overlapping IPv4 address spaces used by the Dual-Stack Lite hosts are disambiguated through the identification of tunnel endpoints 🌸
In this situation, the Dual-Stack Lite host configures the IPv4 address 192.0.0.2 out of the well-known range 192.0.0.0/29 (defined by IANA) on its B4 interface. It also configures the first non-reserved IPv4 address of the reserved range, 192.0.0.1, as the address of its default gateway 💖
+-------------------+
| |
| Host 192.0.0.2 |
|+--------+--------+|
|| B4 ||
|+--------+--------+|
+--------|||--------+
|||2001:db8:0:1::1
|||
|||<-IPv4-in-IPv6 softwire
|||
-------|||-------
/ ||| \
| ISP core network |
\ ||| /
-------|||-------
|||
|||2001:db8:0:2::1
+--------|||--------+
| AFTR |
|+--------+--------+|
|| Concentrator ||
|+--------+--------+|
| |NAT| |
| +-+-+ |
+---------|---------+
|192.0.2.1
|
--------|--------
/ | \
| Internet |
\ | /
--------|--------
|
|198.51.100.1
+-----+-----+
| IPv4 Host |
+-----------+
Figure 4: Host-Based ArchitectureThe resulting solution accepts an IPv4 datagram that is translated into an IPv4-in-IPv6 softwire datagram for transmission across the softwire. At the corresponding endpoint, the IPv4 datagram is decapsulated, and the translated IPv4 address is inserted based on a translation from the softwire 🎀✨
B.2.1. Example Message Flow 🦋
okay so in Figure 5, the AFTR's translation tables are set up to forward between IP/TCP (192.0.0.2/10000) and IP/TCP (192.0.2.1/5000) 💅. so a datagram that comes in from the host at 192.0.0.2, using TCP DST port 10000, gets translated into a datagram with IPv4 SRC address 192.0.2.1 and TCP SRC port 5000 out on the Internet ✨
+-------------------+
| |
|Host 192.0.0.2 |
|+--------+--------+|
|| B4 ||
|+--------+--------+|
+--------|||--------+
| |||2001:db8:0:1::1
IPv6 datagram 1| |||
| |||<-IPv4-in-IPv6 softwire
| |||
-----|-|||-------
/ | ||| \
| ISP core network |
\ | ||| /
-----|-|||-------
| |||
| |||2001:db8:0:2::1
+------|-|||--------+
| | AFTR |
| v ||| |
|+--------+--------+|
|| Concentrator ||
|+--------+--------+|
| |NAT| |
| +-+-+ |
+---------|---------+
| |192.0.2.1
IPv4 datagram 2 | |
-----|--|--------
/ | | \
| Internet |
\ | | /
-----|--|--------
| |
v |198.51.100.1
+-----+-----+
| IPv4 Host |
+-----------+
Figure 5: Outbound Datagram +-----------------+--------------+-----------------+
| Datagram | Header field | Contents |
+-----------------+--------------+-----------------+
| IPv6 datagram 1 | IPv6 Dst | 2001:db8:0:2::1 |
| | IPv6 Src | 2001:db8:0:1::1 |
| | IPv4 Dst | 198.51.100.1 |
| | IPv4 Src | 192.0.0.2 |
| | TCP Dst | 80 |
| | TCP Src | 10000 |
| --------------- | ------------ | ------------- |
| IPv4 datagram 2 | IPv4 Dst | 198.51.100.1 |
| | IPv4 Src | 192.0.2.1 |
| | TCP Dst | 80 |
| | TCP Src | 5000 |
+-----------------+--------------+-----------------+
Datagram Header Contentsso when the Dual-Stack Lite host sends out an IPv4 packet, it wraps it up in datagram 1 and sends it to the AFTR over the softwire 🎀
when the concentrator in the AFTR gets datagram 1, it hands the IPv4 datagram over to the NAT 🧚. the NAT checks its translation table and sees that a datagram arriving on the softwire with TCP SRC port 10000 should be translated into datagram 3, with IPv4 SRC address 192.0.2.1 and TCP SRC port 5000 💜
now Figure 6 is the inbound side 👑. when the NAT in the AFTR gets datagram 1, it looks up the IP/TCP DST in its translation table. in this example the NAT changes the TCP DST port to 10000, sets the IP DST address to 192.0.0.2, and forwards the datagram to the softwire 🦋. then the B4 inside the host unwraps the IPv4 datagram from the inbound softwire datagram and passes it up to the host's application layer 🫶
+-------------------+
| |
|Host 192.0.0.2 |
|+--------+--------+|
|| B4 ||
|+--------+--------+|
+--------|||--------+
^ |||2001:db8:0:1::1
IPv6 datagram 2 | |||
| |||<-IPv4-in-IPv6 softwire
| |||
-----|-|||-------
/ | ||| \
| ISP core network |
\ | ||| /
-----|-|||-------
| |||
| |||2001:db8:0:2::1
+------|-|||--------+
| AFTR |
| | ||| |
|+--------+--------+|
|| Concentrator ||
|+--------+--------+|
| |NAT| |
| +-+-+ |
+---------|---------+
^ |192.0.2.1
IPv4 datagram 1 | |
-----|--|--------
/ | | \
| Internet |
\ | | /
-----|--|--------
| |
| |198.51.100.1
+-----+-----+
| IPv4 Host |
+-----------+
Figure 6: Inbound Datagram +-----------------+--------------+-----------------+
| Datagram | Header field | Contents |
+-----------------+--------------+-----------------+
| IPv4 datagram 1 | IPv4 Dst | 192.0.2.1 |
| | IPv4 Src | 198.51.100.1 |
| | TCP Dst | 5000 |
| | TCP Src | 80 |
| --------------- | ------------ | ------------- |
| IPv6 datagram 2 | IPv6 Dst | 2001:db8:0:1::1 |
| | IPv6 Src | 2001:db8:0:2::1 |
| | IPv4 Dst | 192.0.0.2 |
| | IPv4 Src | 198.51.100.1 |
| | TCP Dst | 10000 |
| | TCP Src | 80 |
+-----------------+--------------+-----------------+
Datagram Header ContentsB.2.2. Translation Details 🌸
the AFTR's translation steps are exactly the same as in Appendix B.1.2 ✨ the one difference is that every host-based B4 uses the same well-known IPv4 address 192.0.0.2 🍓. so to tell the host-based B4s apart, the AFTR uses each host-based B4's IPv6 address instead, which is unique to that host 🔥
+-------------------------------------+--------------------+
| Softwire-Id/IPv4/Prot/Port | IPv4/Prot/Port |
+-------------------------------------+--------------------+
| 2001:db8:0:1::1/192.0.0.2/TCP/10000 | 192.0.2.1/TCP/5000 |
+-------------------------------------+--------------------+
Dual-Stack Lite Carrier-Grade NAT Translation Tablethe Softwire-Id is the IPv6 address assigned to the Dual-Stack host 💖. every host has its own unique Softwire-Id 🌈. the source IPv4 address is one of the well-known IPv4 addresses, and the AFTR could get packets from different hosts that all use that same well-known address, coming in through different softwire tunnels 🙈. so, just like in the gateway architecture, the AFTR combines the Softwire-Id and the IPv4 address/port, [Softwire-Id, IPv4+Port], to uniquely identify each individual host 💅✨
Authors' Addresses 🎀
Alain Durand Juniper Networks 1194 North Mathilda Avenue Sunnyvale, CA 94089-1206 USA
EMail: adurand@juniper.net
Ralph Droms Cisco 1414 Massachusetts Avenue Boxborough, MA 01714 USA
EMail: rdroms@cisco.com
James Woodyatt Apple 1 Infinite Loop Cupertino, CA 95014 USA
EMail: jhw@apple.com
Yiu L. Lee Comcast One Comcast Center Philadelphia, PA 19103 USA
EMail: yiu_lee@cable.comcast.com
📦 where this page comes from
- ietf: rfc6333 2011-08
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms