summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc6333.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc6333.txt')
-rw-r--r--doc/rfc/rfc6333.txt1795
1 files changed, 1795 insertions, 0 deletions
diff --git a/doc/rfc/rfc6333.txt b/doc/rfc/rfc6333.txt
new file mode 100644
index 0000000..edad44a
--- /dev/null
+++ b/doc/rfc/rfc6333.txt
@@ -0,0 +1,1795 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) A. Durand
+Request for Comments: 6333 Juniper Networks
+Category: Standards Track R. Droms
+ISSN: 2070-1721 Cisco
+ J. Woodyatt
+ Apple
+ Y. Lee
+ Comcast
+ August 2011
+
+
+ Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion
+
+Abstract
+
+ This document revisits the dual-stack model and introduces the Dual-
+ Stack Lite technology aimed at better aligning the costs and benefits
+ of deploying IPv6 in service provider networks. Dual-Stack Lite
+ enables a broadband service provider to share IPv4 addresses among
+ customers by combining two well-known technologies: IP in IP (IPv4-
+ in-IPv6) and Network Address Translation (NAT).
+
+Status of This Memo
+
+ This is an Internet Standards Track document.
+
+ This document is a product of the Internet Engineering Task Force
+ (IETF). It represents the consensus of the IETF community. It has
+ received public review and has been approved for publication by the
+ Internet Engineering Steering Group (IESG). Further information on
+ Internet Standards is available in Section 2 of RFC 5741.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ http://www.rfc-editor.org/info/rfc6333.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Durand, et al. Standards Track [Page 1]
+
+RFC 6333 Dual-Stack Lite August 2011
+
+
+Copyright Notice
+
+ Copyright (c) 2011 IETF Trust and the persons identified as the
+ document authors. All rights reserved.
+
+ This document is subject to BCP 78 and the IETF Trust's Legal
+ Provisions Relating to IETF Documents
+ (http://trustee.ietf.org/license-info) in effect on the date of
+ publication of this document. Please review these documents
+ carefully, as they describe your rights and restrictions with respect
+ to this document. Code Components extracted from this document must
+ include Simplified BSD License text as described in Section 4.e of
+ the Trust Legal Provisions and are provided 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
+
+
+
+Durand, et al. Standards Track [Page 2]
+
+RFC 6333 Dual-Stack Lite August 2011
+
+
+ 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 ....................................31
+
+1. Introduction
+
+ The common thinking for more than 10 years has been that the
+ transition to IPv6 will be based solely on the dual-stack model and
+ that most things would be converted this way before we ran out of
+ IPv4. However, this has not happened. The IANA free pool of IPv4
+ addresses has now been depleted, well before sufficient IPv6
+ deployment had taken place. As a result, many IPv4 services have to
+ continue to be provided even under severely limited address space.
+
+ This document specifies the Dual-Stack Lite technology, which is
+ aimed at better aligning the costs and benefits in service provider
+ networks. Dual-Stack Lite will enable both continued support for
+ IPv4 services and incentives for the deployment of IPv6. It also
+ de-couples IPv6 deployment in the service provider network from the
+ rest of the Internet, making incremental deployment easier.
+
+ Dual-Stack Lite enables a broadband service provider to share IPv4
+ addresses among customers by combining two well-known technologies:
+ IP in IP (IPv4-in-IPv6) and Network Address Translation (NAT).
+
+ This document makes a distinction between a dual-stack-capable and a
+ dual-stack-provisioned device. The former is a device that has code
+ that implements both IPv4 and IPv6, from the network layer to the
+ applications. The latter is a similar device that has been
+ provisioned with both an IPv4 and an IPv6 address on its
+ interface(s). This document will also further refine this notion by
+ distinguishing between interfaces provisioned directly by the service
+ provider from those provisioned by the customer.
+
+
+
+Durand, et al. Standards Track [Page 3]
+
+RFC 6333 Dual-Stack Lite August 2011
+
+
+ Pure IPv6-only devices (i.e., devices that do not include an IPv4
+ stack) are outside of the scope of this document.
+
+ This document will first present some deployment scenarios and then
+ define the behavior of the two elements of the Dual-Stack Lite
+ technology: the Basic Bridging BroadBand (B4) element and the Address
+ Family Transition Router (AFTR) element. It will then go into
+ networking and NAT-ing considerations.
+
+2. Requirements Language
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in RFC 2119 [RFC2119].
+
+3. Terminology
+
+ The technology described in this document is known as Dual-Stack
+ Lite. The abbreviation "DS-Lite" will be used throughout this text.
+
+ This document 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. This is the layer 3
+ device in the customer premise that is connected to the service
+ provider network. That device is often a home gateway. However,
+ sometimes computers are directly attached to the service provider
+ network. In such cases, such computers can be viewed as CPEs as
+ well.
+
+4. Deployment Scenarios
+
+4.1. Access Model
+
+ Instead of relying on a cascade of NATs, the Dual-Stack Lite model is
+ built on IPv4-in-IPv6 tunnels to cross the network to reach a
+ carrier-grade IPv4-IPv4 NAT (the AFTR), where customers will share
+ IPv4 addresses. There are a number of benefits to this approach:
+
+ o This technology 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.
+
+
+
+Durand, et al. Standards Track [Page 4]
+
+RFC 6333 Dual-Stack Lite August 2011
+
+
+ o The management of the service provider access networks is
+ simplified by leveraging the large IPv6 address space.
+ Overlapping private IPv4 address spaces are not required to
+ support very large customer bases.
+
+ o As tunnels can terminate anywhere in the service provider network,
+ this architecture lends itself to horizontal scaling and provides
+ some flexibility to adapt to changing traffic load. More
+ discussion of horizontal scaling can be found in Appendix A.
+
+ o Tunnels provide a direct connection between B4 and the AFTR. This
+ can be leveraged to enable customers and their applications to
+ control how the NAT function of the AFTR is performed.
+
+ A key characteristic of this approach is that communications between
+ end-nodes stay within their address family. IPv6 sources only
+ communicate with IPv6 destinations, and IPv4 sources only communicate
+ with IPv4 destinations. There is no protocol family translation
+ involved in this approach. This simplifies greatly the task of
+ applications that may carry literal IP addresses in their payloads.
+
+4.2. CPE
+
+ This section describes home Local Area networks characterized by the
+ presence of a home gateway, or CPE, provisioned only with IPv6 by the
+ service provider.
+
+ A DS-Lite CPE is an IPv6-aware CPE with a B4 interface implemented in
+ the WAN interface.
+
+ A DS-Lite CPE SHOULD NOT operate a NAT function between an internal
+ interface and a B4 interface, as the NAT function will be performed
+ by the AFTR in the service provider's network. This will avoid
+ accidentally operating in a double-NAT environment.
+
+ However, it SHOULD operate its own DHCP(v4) server handing out
+ [RFC1918] address space (e.g., 192.168.0.0/16) to hosts in the home.
+ It SHOULD advertise itself as the default IPv4 router to those home
+ hosts. It SHOULD also advertise itself as a DNS server in the DHCP
+ Option 6 (DNS Server). Additionally, it SHOULD operate a DNS proxy
+ to accept DNS IPv4 requests from home hosts and send them using IPv6
+ to the service provider DNS servers, as described in Section 5.5.
+
+
+
+
+
+
+
+
+
+Durand, et al. Standards Track [Page 5]
+
+RFC 6333 Dual-Stack Lite August 2011
+
+
+ Note: If an IPv4 home host decides to use another IPv4 DNS server,
+ the DS-Lite CPE will forward those DNS requests via the B4 interface,
+ the same way it forwards any regular IPv4 packets. However, each DNS
+ request will create a binding in the AFTR. A large number of DNS
+ requests may have a direct impact on the AFTR's NAT table
+ utilization.
+
+ IPv6-capable devices directly reach the IPv6 Internet. Packets
+ simply follow IPv6 routing, they do not go through the tunnel, and
+ they are not subject to any translation. It is expected that most
+ IPv6-capable devices will also be IPv4 capable and will simply be
+ configured with an IPv4 [RFC1918]-style address within the home
+ network and access the IPv4 Internet the same way as the legacy IPv4-
+ only devices within the home.
+
+ Pure IPv6-only devices (i.e., devices that do not include an IPv4
+ stack) are outside of the scope of this document.
+
+4.3. Directly Connected Device
+
+ In broadband home networks, some devices are directly connected to
+ the broadband service provider. They are connected straight to a
+ modem, without a home gateway. Those devices are, in fact, acting as
+ CPEs.
+
+ Under this scenario, the customer device is a dual-stack-capable host
+ that is provisioned by the service provider with IPv6 only. The
+ device itself acts as a B4 element, and the IPv4 service is provided
+ by an IPv4-in-IPv6 tunnel, just as in the home gateway/CPE case.
+ That device can run any combinations of IPv4 and/or IPv6
+ applications.
+
+ A directly connected DS-Lite device SHOULD send its DNS requests over
+ IPv6 to the IPv6 DNS server it has been configured to use.
+
+ Similarly to the previous sections, IPv6 packets follow IPv6 routing,
+ they do not go through the tunnel, and they are not subject to any
+ translation.
+
+ The support of IPv4-only devices and IPv6-only devices in this
+ scenario is out of scope for this document.
+
+
+
+
+
+
+
+
+
+
+Durand, et al. Standards Track [Page 6]
+
+RFC 6333 Dual-Stack Lite August 2011
+
+
+5. B4 Element
+
+5.1. Definition
+
+ The B4 element is a function implemented on a dual-stack-capable
+ node, either a directly connected device or a CPE, that creates a
+ tunnel to an AFTR.
+
+5.2. Encapsulation
+
+ The tunnel is a multipoint-to-point IPv4-in-IPv6 tunnel ending on a
+ service provider AFTR.
+
+ See Section 7.1 for additional tunneling considerations.
+
+ Note: At this point, DS-Lite only defines IPv4-in-IPv6 tunnels;
+ however, other types of encapsulation could be defined in the future.
+
+5.3. Fragmentation and Reassembly
+
+ Using an encapsulation (IPv4-in-IPv6 or anything else) to carry IPv4
+ traffic over IPv6 will reduce the effective MTU of the datagram.
+ Unfortunately, path MTU discovery [RFC1191] is not a reliable method
+ to deal with this problem.
+
+ A solution to deal with this problem is for the service provider to
+ increase the MTU size of all the links between the B4 element and the
+ AFTR elements by at least 40 bytes to accommodate both the IPv6
+ encapsulation header and the IPv4 datagram without fragmenting the
+ IPv6 packet.
+
+ However, as not all service providers will be able to increase their
+ link MTU, the B4 element MUST perform fragmentation and reassembly if
+ the outgoing link MTU cannot accommodate the extra IPv6 header. The
+ original IPv4 packet is not oversized. The packet is oversized after
+ the IPv6 encapsulation. The inner IPv4 packet MUST NOT be
+ fragmented. Fragmentation MUST happen after the encapsulation of the
+ IPv6 packet. Reassembly MUST happen before the decapsulation of the
+ IPv4 packet. A detailed procedure has been specified in [RFC2473]
+ Section 7.2.
+
+5.4. AFTR Discovery
+
+ In order to configure the IPv4-in-IPv6 tunnel, the B4 element needs
+ the IPv6 address of the AFTR element. This IPv6 address can be
+ configured using a variety of methods, ranging from an out-of-band
+ mechanism, manual configuration, or a variety of DHCPv6 options.
+
+
+
+
+Durand, et al. Standards Track [Page 7]
+
+RFC 6333 Dual-Stack Lite August 2011
+
+
+ In order to guarantee interoperability, a B4 element SHOULD implement
+ the DHCPv6 option defined in [RFC6334].
+
+5.5. DNS
+
+ A B4 element is only configured from the service provider with IPv6.
+ As such, it can only learn the address of a DNS recursive server
+ through DHCPv6 (or other similar method over IPv6). As DHCPv6 only
+ defines an option to get the IPv6 address of such a DNS recursive
+ server, the B4 element cannot easily discover the IPv4 address of
+ such a recursive DNS server, and as such will have to perform all DNS
+ resolution over IPv6.
+
+ The B4 element can pass this IPv6 address to downstream IPv6 nodes,
+ but not to downstream IPv4 nodes. As such, the B4 element SHOULD
+ implement a DNS proxy, following the recommendations of [RFC5625].
+
+ To support a security-aware resolver behind the B4 element, the DNS
+ proxy in the B4 element must also be security aware. Details can be
+ found in [RFC4033] Section 6.
+
+5.6. Interface Initialization
+
+ The B4 element can be implemented in a host and CPE in conjunction
+ with other technologies such as native dual-stack. The host and the
+ CPE SHOULD select to start only one technology during initialization.
+ For example, if the CPE selects to start in native dual-stack mode,
+ it SHOULD NOT initialize the B4 element. This selection process 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. Configuring such an address
+ is often necessary when the B4 element is sourcing IPv4 datagrams
+ directly over the tunnel. In order to avoid conflicts with any other
+ address, IANA has defined 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 prevents the B4
+ element from using 192.0.0.2, the B4 element MAY use any other
+ addresses within the 192.0.0.0/29 range.
+
+ Note: A range of addresses has been reserved for this purpose. The
+ intent is to accommodate nodes implementing multiple B4 elements.
+
+
+
+
+
+Durand, et al. Standards Track [Page 8]
+
+RFC 6333 Dual-Stack Lite August 2011
+
+
+6. AFTR Element
+
+6.1. Definition
+
+ An AFTR element is the combination of an IPv4-in-IPv6 tunnel endpoint
+ and an IPv4-IPv4 NAT implemented on the same node.
+
+6.2. Encapsulation
+
+ The tunnel is a point-to-multipoint IPv4-in-IPv6 tunnel ending at the
+ B4 elements.
+
+ See Section 7.1 for additional tunneling considerations.
+
+ Note: At this point, DS-Lite only defines IPv4-in-IPv6 tunnels;
+ however, other types of encapsulation could be defined in the future.
+
+6.3. Fragmentation and Reassembly
+
+ As noted previously, fragmentation and reassembly need to be taken
+ care of by the tunnel endpoints. As such, the AFTR MUST perform
+ fragmentation and reassembly if the underlying link MTU cannot
+ accommodate the encapsulation overhead. Fragmentation MUST happen
+ after the encapsulation on the IPv6 packet. Reassembly MUST happen
+ before the decapsulation of the IPv6 header. A detailed procedure
+ has been specified in [RFC2473] Section 7.2.
+
+ Fragmentation at the Tunnel Entry-Point is a lightweight operation.
+ In contrast, reassembly at the Tunnel Exit-Point can be expensive.
+ When the Tunnel Exit-Point receives the first fragmented packet, it
+ must wait for the second fragmented packet to arrive in order to
+ reassemble the two fragmented IPv6 packets for decapsulation. This
+ requires the Tunnel Exit-Point to buffer and keep track of fragmented
+ packets. Consider that the AFTR is the Tunnel Exit-Point for many
+ tunnels. If many devices simultaneously source a large number of
+ fragmented packets through the AFTR to its managed B4 elements, this
+ will require the AFTR to buffer and consume enormous resources to
+ keep track of the flows. This reassembly process will significantly
+ impact the AFTR's performance. However, this impact only happens
+ when many clients simultaneously source large IPv4 packets. Since we
+ believe that the majority of the clients will receive large IPv4
+ packets (such as watching video streams) instead of sourcing large
+ IPv4 packets (such as sourcing video streams), reassembly is only a
+ fraction of the overall AFTR's workload.
+
+
+
+
+
+
+
+Durand, et al. Standards Track [Page 9]
+
+RFC 6333 Dual-Stack Lite August 2011
+
+
+ When the AFTR's resources are running below a pre-defined threshold,
+ the AFTR SHOULD generate a notification to the administrator before
+ the resources are completely exhausted. The threshold and
+ notification procedures are implementation dependent and are out of
+ scope for this document.
+
+ Methods to avoid fragmentation, such as rewriting the TCP Maximum
+ Segment Size (MSS) option or using technologies such as the
+ Subnetwork Encapsulation and Adaptation Layer as defined in
+ [RFC5320], are out of scope for this document.
+
+6.4. DNS
+
+ As noted previously, a DS-Lite node implementing a B4 element will
+ perform DNS resolution over IPv6. As a result, DNS packets are not
+ expected to go through the AFTR element.
+
+6.5. Well-Known IPv4 Address
+
+ The AFTR SHOULD use the well-known IPv4 address 192.0.0.1 reserved by
+ IANA to configure the IPv4-in-IPv6 tunnel. That address can then be
+ used to report ICMP problems and will appear in traceroute outputs.
+
+6.6. Extended Binding Table
+
+ The NAT binding table of the AFTR element is extended to include the
+ source IPv6 address of the incoming packets. This IPv6 address is
+ used to disambiguate between the overlapping IPv4 address space of
+ the service provider customers.
+
+ By doing a reverse lookup in the extended IPv4 NAT binding table, the
+ AFTR knows how to reconstruct the IPv6 encapsulation when the packets
+ come back from the Internet. That way, there is no need to keep a
+ static configuration for each tunnel.
+
+7. Network Considerations
+
+7.1. Tunneling
+
+ Tunneling MUST be done in accordance to [RFC2473] and [RFC4213].
+ Traffic classes ([RFC2474]) from the IPv4 headers MUST be carried
+ over to the IPv6 headers and vice versa.
+
+7.2. Multicast Considerations
+
+ Discussion of multicast is out of scope for this document.
+
+
+
+
+
+Durand, et al. Standards Track [Page 10]
+
+RFC 6333 Dual-Stack Lite August 2011
+
+
+8. NAT Considerations
+
+8.1. NAT Pool
+
+ The AFTR MAY be provisioned with different NAT pools. The address
+ ranges in the pools may be disjoint but MUST NOT be overlapped.
+ Operators may implement policies in the AFTR to assign clients in
+ different pools. For example, an AFTR can have two interfaces. Each
+ interface will have a disjoint pool NAT assigned to it. In another
+ case, a policy implemented on the AFTR may specify that one set of
+ B4s will use NAT pool 1 and a different set of B4s will use NAT
+ pool 2.
+
+8.2. NAT Conformance
+
+ A Dual-Stack Lite AFTR MUST implement behavior conforming to the best
+ current practice, currently documented in [RFC4787], [RFC5508], and
+ [RFC5382]. More discussions about carrier-grade NATs can be found in
+ [LSN-REQS].
+
+8.3. Application Level Gateways (ALGs)
+
+ The AFTR performs NAT-44 and inherits the limitations of NAT. Some
+ protocols require ALGs in the NAT device to traverse through the NAT.
+ For example, Active FTP requires the ALG to work properly. ALGs
+ consume resources, and there are many different types of ALGs. The
+ AFTR is a shared network device that supports a large number of B4
+ elements. It is impossible for the AFTR to implement every current
+ and future ALG.
+
+8.4. Sharing Global IPv4 Addresses
+
+ The AFTR shares a single IP with multiple users. This helps to
+ increase the IPv4 address utilization. However, it also brings some
+ issues such as logging and lawful intercept. More considerations on
+ sharing the port space of IPv4 addresses can be found in [RFC6269].
+
+8.5. Port Forwarding / Keep Alive
+
+ The PCP working group is standardizing a control plane to the
+ carrier-grade NAT [LSN-REQS] in the IETF. The Port Control Protocol
+ (PCP) enables applications to directly negotiate with the NAT to open
+ ports and negotiate lifetime values to avoid keep-alive traffic.
+ More on PCP can be found in [PCP-BASE].
+
+
+
+
+
+
+
+Durand, et al. Standards Track [Page 11]
+
+RFC 6333 Dual-Stack Lite August 2011
+
+
+9. Acknowledgements
+
+ The authors would like to acknowledge the role of Mark Townsley for
+ his input on the overall architecture of this technology by pointing
+ this work in the direction of [SNAT]. Note that this document
+ results from a merging of [DURAND-DS-LITE] and [SNAT]. Also to be
+ acknowledged are the many discussions with a number of people
+ including Shin Miyakawa, Katsuyasu Toyama, Akihide Hiura, Takashi
+ Uematsu, Tetsutaro Hara, Yasunori Matsubayashi, and Ichiro Mizukoshi.
+ The authors would also like to thank David Ward, Jari Arkko, Thomas
+ Narten, and Geoff Huston for their constructive feedback. Special
+ thanks go to Dave Thaler and Dan Wing for their reviews and comments.
+
+10. IANA Considerations
+
+ Per this document, IANA has allocated a well-known IPv4 192.0.0.0/29
+ network prefix. That range is used to number the Dual-Stack Lite
+ interfaces. Reserving a /29 allows for 6 possible interfaces on a
+ multi-home node. The IPv4 address 192.0.0.1 is reserved as the IPv4
+ address of the default router for such Dual-Stack Lite hosts.
+
+11. Security Considerations
+
+ Security issues associated with NAT have long been documented. See
+ [RFC2663] and [RFC2993].
+
+ However, moving the NAT functionality from the CPE to the core of the
+ service provider network and sharing IPv4 addresses among customers
+ create additional requirements when logging data for abuse usage.
+ With any architecture where an IPv4 address does not uniquely
+ represent an end host, IPv4 addresses and timestamps are no longer
+ sufficient to identify a particular broadband customer. The AFTR
+ should have the capability to log the tunnel-id, protocol, ports/IP
+ addresses, and the creation time of the NAT binding to uniquely
+ identify the user sessions. Exact details of what is logged are
+ implementation specific and out of scope for this document.
+
+ The AFTR performs translation functions for interior IPv4 hosts using
+ RFC 1918 addresses or the IANA reserved address range (192.0.0.0/29).
+ In some circumstances, an ISP may provision policies in the AFTR and
+ instruct the AFTR to bypass translation functions based on <IPv4
+ Address, port number, protocol>. When the AFTR receives a packet
+ with matching information of the policy from the interior host, the
+ AFTR can simply forward the packet without translation. The
+ addresses, ports, and protocol information must be provisioned on the
+ AFTR before receiving the packet. The provisioning mechanism is out
+ of scope for this specification.
+
+
+
+
+Durand, et al. Standards Track [Page 12]
+
+RFC 6333 Dual-Stack Lite August 2011
+
+
+ When decapsulating packets, the AFTR MUST only forward packets
+ sourced by RFC 1918 addresses, an IANA reserved address range, or any
+ other out-of-band pre-authorized addresses. The AFTR MUST drop all
+ other packets. This prevents rogue devices from launching denial-of-
+ service attacks using 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 by launching a TCP SYN ACK attack
+ [RFC4987]. The victim will receive TCP SYN from random IPv4 source
+ addresses at a rapid rate and deny TCP services to legitimate users.
+
+ With IPv4 addresses shared by multiple users, ports become a critical
+ resource. As such, some mechanisms need to be put in place by an
+ AFTR to limit port usage, either by rate-limiting new connections or
+ putting a hard limit on the maximum number of ports usable by a
+ single user. If this number is high enough, it should not interfere
+ with normal usage and still provide reasonable protection of the
+ shared pool. More considerations on sharing IPv4 addresses can be
+ found in [RFC6269]. Other considerations and recommendations on
+ logging can be found in [RFC6302].
+
+ AFTRs should support ways to limit service only to registered
+ customers. One simple option is to implement an IPv6 ingress filter
+ on the AFTR's tunnel interface to accept only 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.
+
+
+
+
+
+
+
+Durand, et al. Standards Track [Page 13]
+
+RFC 6333 Dual-Stack Lite August 2011
+
+
+ [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.
+
+
+
+Durand, et al. Standards Track [Page 14]
+
+RFC 6333 Dual-Stack Lite August 2011
+
+
+ [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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Durand, et al. Standards Track [Page 15]
+
+RFC 6333 Dual-Stack Lite August 2011
+
+
+Appendix A. Deployment Considerations
+
+A.1. AFTR Service Distribution and Horizontal Scaling
+
+ One of the key benefits of the Dual-Stack Lite technology lies in the
+ fact that it is a tunnel-based solution. As such, tunnel endpoints
+ can be anywhere in the service provider network.
+
+ Using the DHCPv6 tunnel endpoint option [RFC6334], service providers
+ can create groups of users sharing the same AFTR. Those groups can
+ be merged or divided at will. This leads to a horizontally scaled
+ solution, where more capacity is added with more AFTRs. As those
+ groups of users can evolve over time, it is best to make sure that
+ AFTRs do not require per-user configuration in order to provide
+ service.
+
+A.2. Horizontal Scaling
+
+ A service provider can start using just a few centralized AFTRs.
+ Later, when more capacity is needed, more AFTRs can be added and
+ pushed closer to the edges of the access network.
+
+A.3. High Availability
+
+ An important element in the design of the Dual-Stack Lite technology
+ is the simplicity of implementation on the customer side. An IP4-in-
+ IPv6 tunnel and a default route over it in the B4 element are all
+ that is needed to get IPv4 connectivity. It is assumed that high
+ availability is the responsibility of the service provider, not the
+ customer devices implementing Dual-Stack Lite. As such, a single
+ IPv6 address of the tunnel endpoint is provided in the DHCPv6 option
+ defined in [RFC6334]. Specific means to achieve high availability on
+ the service provider side are outside the scope of this
+ specification.
+
+A.4. Logging
+
+ DS-Lite AFTR implementation should offer the functionality to log NAT
+ binding creations or other ways to keep track of the ports/IP
+ addresses used by customers. This is both to support
+ troubleshooting, which is very important to service providers trying
+ to figure out why something may not be working, and to meet region-
+ specific requirements for responding to legally binding requests for
+ information from law enforcement authorities.
+
+
+
+
+
+
+
+Durand, et al. Standards Track [Page 16]
+
+RFC 6333 Dual-Stack Lite August 2011
+
+
+Appendix B. Examples
+
+B.1. Gateway-Based Architecture
+
+ This architecture is targeted at residential broadband deployments
+ but can be adapted easily to other types of deployment where the
+ installed base of IPv4-only devices is important.
+
+ Consider a scenario where a Dual-Stack Lite CPE is provisioned only
+ with IPv6 in the WAN port, not IPv4. The CPE acts as an IPv4 DHCP
+ server for the LAN (wireline and wireless) handing out [RFC1918]
+ addresses. In addition, the CPE may support IPv6 Auto-Configuration
+ and/or a DHCPv6 server for the LAN. When an IPv4-only device
+ connects to the CPE, that CPE will hand out a [RFC1918] address to
+ the device. When a dual-stack-capable device connects to the CPE,
+ that CPE will hand out a [RFC1918] address and a global IPv6 address
+ to the device. Besides, the CPE will create an IPv4-in-IPv6 softwire
+ tunnel [RFC5571] to an AFTR that resides in the service provider
+ network.
+
+ When the device accesses IPv6 service, it will send the IPv6 datagram
+ to the CPE natively. The CPE will route the traffic upstream to the
+ IPv6 default gateway.
+
+ When the device accesses IPv4 service, it will source the IPv4
+ datagram with the [RFC1918] address and send the IPv4 datagram to the
+ CPE. The CPE will encapsulate the IPv4 datagram inside the IPv4-in-
+ IPv6 softwire tunnel and forward the IPv6 datagram to the AFTR. This
+ is in contrast to what the CPE normally does today, which is to NAT
+ the [RFC1918] address to the public IPv4 address and route the
+ datagram upstream. When the AFTR receives the IPv6 datagram, it will
+ decapsulate the IPv6 header and perform an IPv4-to-IPv4 NAT on the
+ source address.
+
+ As illustrated in Figure 1, this Dual-Stack Lite deployment model
+ consists of three components: the Dual-Stack Lite home router with a
+ B4 element, the AFTR, and a softwire between the B4 element acting as
+ softwire initiator (SI) [RFC5571] in the Dual-Stack Lite home router
+ and the softwire concentrator (SC) [RFC5571] in the AFTR. The AFTR
+ performs IPv4-IPv4 NAT translations to multiplex multiple subscribers
+ through a pool of global IPv4 addresses. Overlapping address spaces
+ used by subscribers are disambiguated through the identification of
+ tunnel endpoints.
+
+
+
+
+
+
+
+
+Durand, et al. Standards Track [Page 17]
+
+RFC 6333 Dual-Stack Lite August 2011
+
+
+ +-----------+
+ | 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 Architecture
+
+
+
+
+Durand, et al. Standards Track [Page 18]
+
+RFC 6333 Dual-Stack Lite August 2011
+
+
+ Notes:
+
+ o The Dual-Stack Lite home router is not required to be on the same
+ link as the host.
+
+ o The Dual-Stack Lite home router could be replaced by a Dual-Stack
+ Lite router in the service provider network.
+
+ The 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.1.1. Example Message Flow
+
+ In the example shown in Figure 2, the translation tables in the AFTR
+ are configured to forward between IP/TCP (10.0.0.1/10000) and IP/TCP
+ (192.0.2.1/5000). That is, a datagram received by the Dual-Stack
+ Lite home router from the host at address 10.0.0.1, using TCP DST
+ port 10000, will be translated to a datagram with IPv4 SRC address
+ 192.0.2.1 and TCP SRC port 5000 in the Internet.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Durand, et al. Standards Track [Page 19]
+
+RFC 6333 Dual-Stack Lite August 2011
+
+
+ +-----------+
+ | 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
+
+
+
+Durand, et al. Standards Track [Page 20]
+
+RFC 6333 Dual-Stack Lite August 2011
+
+
+ +-----------------+--------------+-----------------+
+ | 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 Contents
+
+ When datagram 1 is received by the Dual-Stack Lite home router, the
+ B4 element encapsulates the datagram in datagram 2 and forwards it to
+ the Dual-Stack Lite carrier-grade NAT over the softwire.
+
+ When the tunnel concentrator in the AFTR receives datagram 2, it
+ forwards the IPv4 datagram to the NAT, which determines from its NAT
+ table that the datagram received on the softwire with TCP SRC
+ port 10000 should be translated to datagram 3 with IPv4 SRC address
+ 192.0.2.1 and TCP SRC port 5000.
+
+ Figure 3 shows an inbound message received at the AFTR. When the NAT
+ function in the AFTR receives datagram 1, it looks up the IP/TCP DST
+ information in its translation table. In the example in Figure 3,
+ 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. The B4 in the
+ home router decapsulates the IPv4 datagram from the inbound softwire
+ datagram and forwards it to the host.
+
+
+
+
+
+
+
+
+
+
+
+Durand, et al. Standards Track [Page 21]
+
+RFC 6333 Dual-Stack Lite August 2011
+
+
+ +-----------+
+ | 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
+
+
+
+Durand, et al. Standards Track [Page 22]
+
+RFC 6333 Dual-Stack Lite August 2011
+
+
+ +-----------------+--------------+-----------------+
+ | 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 Contents
+
+B.1.2. Translation Details
+
+ The AFTR has a NAT that translates between softwire/port pairs and
+ IPv4-address/port pairs. The same translation is applied to IPv4
+ datagrams received on the device's external interface and from the
+ softwire endpoint in the device.
+
+ In Figure 2, the translator network interface in the AFTR is on the
+ Internet, and the softwire interface connects to the Dual-Stack Lite
+ home router. The AFTR translator is configured as follows:
+
+ 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 is how the translation in Figure 3 works:
+
+ o 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.
+
+
+
+Durand, et al. Standards Track [Page 23]
+
+RFC 6333 Dual-Stack Lite August 2011
+
+
+ o 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 Table
+
+ The 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 is 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.
+
+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.
+
+ Consider a scenario where 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.
+
+
+
+
+
+
+
+
+
+Durand, et al. Standards Track [Page 24]
+
+RFC 6333 Dual-Stack Lite August 2011
+
+
+ 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
+ consists 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Durand, et al. Standards Track [Page 25]
+
+RFC 6333 Dual-Stack Lite August 2011
+
+
+ +-------------------+
+ | |
+ | 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 Architecture
+
+ The 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.
+
+
+
+
+
+Durand, et al. Standards Track [Page 26]
+
+RFC 6333 Dual-Stack Lite August 2011
+
+
+B.2.1. Example Message Flow
+
+ In the example shown in Figure 5, the translation tables in the AFTR
+ are configured to forward between IP/TCP (192.0.0.2/10000) and IP/TCP
+ (192.0.2.1/5000). That is, a datagram received from the host at
+ address 192.0.0.2, using TCP DST port 10000, will be translated to a
+ datagram with IPv4 SRC address 192.0.2.1 and TCP SRC port 5000 in the
+ Internet.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Durand, et al. Standards Track [Page 27]
+
+RFC 6333 Dual-Stack Lite August 2011
+
+
+ +-------------------+
+ | |
+ |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
+
+
+
+
+
+
+
+
+
+
+Durand, et al. Standards Track [Page 28]
+
+RFC 6333 Dual-Stack Lite August 2011
+
+
+ +-----------------+--------------+-----------------+
+ | 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 Contents
+
+ When sending an IPv4 packet, the Dual-Stack Lite host encapsulates it
+ in datagram 1 and forwards it to the AFTR over the softwire.
+
+ When it receives datagram 1, the concentrator in the AFTR hands the
+ IPv4 datagram to the NAT, which determines from its translation table
+ that the datagram received on the softwire with TCP SRC port 10000
+ should be translated to datagram 3 with IPv4 SRC address 192.0.2.1
+ and TCP SRC port 5000.
+
+ Figure 6 shows an inbound message received at the AFTR. When the NAT
+ function in the AFTR receives datagram 1, it looks up the IP/TCP DST
+ in its translation table. In the example in Figure 6, the NAT
+ translates the TCP DST port to 10000, sets the IP DST address to
+ 192.0.0.2, and forwards the datagram to the softwire. The B4 inside
+ the host decapsulates the IPv4 datagram from the inbound softwire
+ datagram, and forwards it to the host's application layer.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Durand, et al. Standards Track [Page 29]
+
+RFC 6333 Dual-Stack Lite August 2011
+
+
+ +-------------------+
+ | |
+ |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
+
+
+
+
+
+
+
+
+
+
+Durand, et al. Standards Track [Page 30]
+
+RFC 6333 Dual-Stack Lite August 2011
+
+
+ +-----------------+--------------+-----------------+
+ | 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 Contents
+
+B.2.2. Translation Details
+
+ The AFTR translation steps are the same as in Appendix B.1.2. One
+ difference is that all the host-based B4s will use the same well-
+ known IPv4 address 192.0.0.2. To uniquely identify the host-based
+ B4, the AFTR will use the host-based B4's IPv6 address, which is
+ unique for the 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 Table
+
+ The Softwire-Id is the IPv6 address assigned to the Dual-Stack host.
+ Each host has a unique Softwire-Id. The source IPv4 address is one
+ of the well-known IPv4 addresses. The AFTR could receive packets
+ from different hosts sourced from the same IPv4 well-known address
+ from different softwire tunnels. Similar to the gateway
+ architecture, the AFTR combines the Softwire-Id and IPv4 address/port
+ [Softwire-Id, IPv4+Port] to uniquely identify the individual host.
+
+
+
+
+
+
+
+
+
+
+Durand, et al. Standards Track [Page 31]
+
+RFC 6333 Dual-Stack Lite August 2011
+
+
+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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Durand, et al. Standards Track [Page 32]
+