Network Working Group Xiaohong Deng Internet Draft M. Boucadair Intended status: Standards Track France Telecom Expires: May 2012 C. Zhou Huawei Technologies October 31, 2011 NAT offload extension to Dual-Stack lite draft-zhou-softwire-b4-nat-04 Abstract Dual-Stack Lite, combining IPv4-in-IPv6 tunnel and Carrier Grade NAT technologies, provides an approach that offers IPv4 service via IPv6 network by sharing IPv4 addresses among customers during IPv6 transition period. Dual-stack lite, however, requires CGN to maintain active NAT sessions, which means processing performance, memory size and log abilities for NAT sessions should scale with number of sessions of subscribers; Hence increasing in CAPEX for operators would be resulted in when traffic increase. This document propose the NAT offload extensions to DS-Lite, which allows offloading NAT translation function from centralized network side (AFTR) to distributed customer equipments (B4), thereby offering a trade-off between CAPEX (e.g. less performance requirements on AFTR device) and OPEX (e.g., easy and fast deployment of Dual-Stack Lite) for operators. The ability of easily co-deploying with basic Dual- Stack Lite is essential to NAT offload extension to DS-Lite. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." DBC Expires May 31, 2012 [Page 1] Internet-Draft Lightweight extension to DS-Lite October 2011 This Internet-Draft will expire on April 26, 2012. 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. Background........................................................3 2. NAT offload extended DS-Lite Overview and terminologies...........3 3. NATed B4 Behavior.................................................5 3.1. Plain IPv4 Address...........................................5 3.2. Restricted IPv4 Address and port set provisioning............5 3.2.1. Restricted port allocation strategies and requirements..5 3.2.2. Restricted IPv4 Address and port set provisioning method ..............................................................6 3.3. Outgoing Packets Processing..................................6 3.4. Incoming Packets Processing..................................6 3.4.1. Incoming Ports considerations on a given restricted IPv4 address........................................................6 4. NAT offload AFTR Behaviour........................................7 4.1. Outgoing Packets Processing..................................7 4.2. Incoming Packets Processing..................................7 5. Fragmentation and Reassembly and DNS..............................7 6. Security Considerations...........................................8 7. IANA Considerations..............................................10 8. References.......................................................10 8.1. Normative References........................................10 8.2. Informative References......................................10 9. Acknowledgments..................................................12 DBC Expires May 31, 2012 [Page 2] Internet-Draft Lightweight extension to DS-Lite October 2011 1. Background The basic idea of NAT offload extension to DS-lite, is to reuse the basic DS-Lite infrastructure, including tunneling transport and provisioning method, and ICMP and fragmentation processing as well. The NAT offload extension makes the AFTR table scales with customer number other than traffic sessions. Based on this NAT offload extension, log entries for per subscriber instead of per session is achievable. IPv4 address utilization efficiency depends on port allocation strategies, e.g., per port on demand, or a buck of ports pre-allocation, which would be elaborated in Section 5. Besides, this method allows unique IPv6 address for delivery both IPv4 over IPv6 traffic and native IPv6 traffic without introduce any IPv4 addressing/rouging into IPv6 address/routing, as it reuses Dual Stack Lite tunneling transport infrastructure, unlike stateless solutions with port set allocation such as aplusp and 4rd, that either requires two IPv6 addresses separately for either IPv4 traffic over IPv6 or native IPv6 traffic, or require carefully design to avoid introduce IPv4 routing to IPv6 routing when using unique IPv6 address to transport both IPv4 over IPv6 traffic and native IPv6 traffic. 2. NAT offload extended DS-Lite Overview and terminologies Figure 1 provides an overview of the NAT offload extended DS-Lite. DBC Expires May 31, 2012 [Page 3] Internet-Draft Lightweight extension to DS-Lite October 2011 +-------------------------+ | IPv6 ISP Network | | | | | +-------------------------+ | | +-----------+ +----------+ | |NAT offload| | IPv4 | +--------+ | IPv4-in-IPv6 |AFTR |---| Internet | | | +---------+ | | | | |IPv4 LAN|--|NATed |===============+-----------+ +----------+ | | |B4 |CPE/HOST | +--------+ +---------+ | | | | | +-------------------------+ Figure 1 : NAT offload extended DS-Lite Overview NATed B4: A NAT offload extended B4 which is called NATed B4 in this document can be either an IPv6 hosts or a CPE. NATed B4 performs IP address and port translation function, besides establishment of IPv4 in IPv6 tunnel with AFTR. NAT offload AFTR: A NAT offload extended AFTR which is called NAT offload AFTR is responsible for establishing IPv4 in IPv6 tunneling with NATed B4 to transport IPv4 over IPv6 while the NAT translation function is offloaded to NATed B4. A NATed B4 uses IPv4 address with a restricted port set for this IPv4 connectivity, which may be provisioned via either DHCPv4 with the AFTR, or via PCP with the PCP server. The AFTR keeps the mapping between B4's IPv6 address, allocated IPv4 address, and a restricted port set ID on a per customer basis. For host NATed B4 case, the host gets public address directly. It is also suggested that the host run a local NAT to map randomly generated ports into the restricted port set. Private to public address translation would not be needed in this NAT. Another DBC Expires May 31, 2012 [Page 4] Internet-Draft Lightweight extension to DS-Lite October 2011 solution is to have the IP stack to only assign ports within the restricted port set to applications. Either way the host guarantees that every port number in the packets sent out by itself falls into the allocated port set. 3. NATed B4 Behavior The NATed B4 is responsible for performing NAT and/ALG functions, basic B4 functions, as well as supporting NAT Traversal mechanisms (e.g., UPnP or NAT-PMP). The tunneling provisioning of the B4 element should reuse what has defined in [I-D.ietf-softwire-dual-stack-lite]. 3.1. Plain IPv4 Address A NATed B4 MAY be assigned with a plain IPv4 address. When a plain, IPv4 address is assigned, the NAT operations are enforced as per current legacy CPEs. The NAT in the AFTR is disabled for that user.IPv4 datagrams are encapsulated in IPv6 as specified in [I-D.ietf-softwire-dual-stack-lite]. 3.2. Restricted IPv4 Address and port set provisioning 3.2.1. Restricted port allocation strategies and requirements Restricted port allocation strategies for this approach could either be allocating per port on demand, or be pre-allocating a port set (no matter a continuous port range, or multiple non-continuous sub port sets),which leads to trade-off between provisioning efficiency and IPv4 utilization efficiency. Note that efficiency on log is reported by operators as a practical requirement for AFTR, hence port set decoding should take this requirement into account, no matter which port allocation strategy is adopt. DBC Expires May 31, 2012 [Page 5] Internet-Draft Lightweight extension to DS-Lite October 2011 Unlike stateless 4over6 solutions such as [I-D.murakami-softwire- 4rd], the restricted port sets allocation for NAT offload extended DS-Lite has no requires on careful planning of the IPv6 and IPv4 addressing together. It therefore offers more flexibility for ISPs, when it comes to managing the IPv6 access network, and introduces no impact on IPv6 routing. 3.2.2. Restricted IPv4 Address and port set provisioning method Either DHCP for example, [I-D.bajko-pripaddrassign] or PCP would be candidate for delivery Restricted IPv4 and port set. With PCP, The basic PCP protocol allows per port on demand allocation, while an extension to PCP [I-D.tsou-pcp-natcoord] supports pre- allocate bulk of ports. 3.3. Outgoing Packets Processing Upon receiving an IPv4 packet, the B4 performs NAT using the public IPv4 address and port set assigned to it. Then B4 encapsulates the resulting IPv4 packet into an IPv6 packet, and delivers it through IPv6 connectivity to AFTR which will then decapsulate the encapsulated packet and forward it through IPv4. The destination IPv6 address used for encapsulation should be the AFTR's address. 3.4. Incoming Packets Processing Upon receipt of IPv4-in-IPv6 packet from AFTR, B4 will decapsulate the packet and translate the public IPv4 address to the private IPv4 address. Finally, it delivers the packet to the host using the translated IPv4 address. The source IPv6 address used for encapsulation at AFTR is the AFTR's address, and the destination address is set to the external address of B4. 3.4.1. Incoming Ports considerations on a given restricted IPv4 address As described in [I-D.ietf-intarea-shared-addressing-issues], a bulk of incoming ports can be reserved as a centralized resource shared by all subscribers using a given restricted IPv4 address. In order to DBC Expires May 31, 2012 [Page 6] Internet-Draft Lightweight extension to DS-Lite October 2011 distribute incoming ports as fair as possible among subscribers sharing a given restricted IPv4 address, other than allocating a continuous range of ports to each, a solution to distribute bulks of non-continuous ports among subscribers, which also takes port randomization into account, is elaborated in Section 3.1. 4. NAT offload AFTR Behaviour The NAT offload AFTR may be co-located with IP and /or restricted port set allocation server (e.g., a DHCP server, or a PCP server). The AFTR only maintains a static mapping entry per customer consist of IPv6 address, IPv4 address and port set ID, other than maintains NAT entries per session. 4.1. Outgoing Packets Processing For outgoing packets, the NAT offload AFTR simply decapsulates it and forwards it to IPv4 Internet. 4.2. Incoming Packets Processing For inbound traffic, NAT offload AFTR would use the IPv4 destination address and port as the index to retrieve mapping table in order to find a destination IPv6 address, and then encapsulates it into IPv6, so that native IPv6 routing could be used to forward the IPv4 in IPv6 traffic. 5. Fragmentation and Reassembly and DNS No change to Section 5.3 of [I-D.ietf-softwire-dual-stack-lite. The DNS behavior is the same as described in [I-D.ietf-softwire-dual- stack-lite]. DBC Expires May 31, 2012 [Page 7] Internet-Draft Lightweight extension to DS-Lite October 2011 6. Security Considerations As port randomization is one protection among others against blind attacks, a simple non-contiguous port sets distribution mechanism is therefore proposed to distribute bulks of non-continuous ports among subscribers, and to enable subscribers operating port randomized NAT. In this section, a non-continuous restricted port set encoding/decoding and an algorithm of random ephemeral port selection within the allocated restricted port set example proves that port randomization is applicable this approach. On every external IPv4 address, according to port set size N, log2(N) bits are randomly choosing by NAT offload AFTR as subscribers identification bits(s bit) among 1st and 16th bits. Take a sharing ration 1:32 for example, Figure 1 shows an example of 5 random selected bits of s bits. |1st |2nd |3rd |4th |5th |6th |7th | 8th| +----+----+----+----+----+----+----+----+ | 0 | s | 0 | 0 | s | 0 | s | 0 | +----+----+----+----+----+----+----+----+ |9th |10th|11th|12th|13th|14th|15th|16th| +----+----+----+----+----+----+----+----+ | s | 0 | s | 0 | 0 | 0 | 0 | 0 | +----+----+----+----+----+----+----+----+ Figure 2 : A s bit selection example (on a sharing ration 1:32 address). Subscriber ID pattern is formed by setting all the s bits to 1 and other trivial bits to 0. Figure 2 illustrates an example of subscriber ID pattern on a sharing ration 1:32 address. Note that the subscriber ID pattern will be different, guaranteed by the random s bit selection, on every restricted IP address no matter whether the sharing ratio varies.The NAT offload AFTR can use subscriber ID pattern as port set ID on a per restricted IPv4 address basis, which allows log entries scale on a subscriber basis, hence meets the log efficiency requirements described in Section 3.1.2. DBC Expires May 31, 2012 [Page 8] Internet-Draft Lightweight extension to DS-Lite October 2011 |1st |2nd |3rd |4th |5th |6th |7th | 8th| +----+----+----+----+----+----+----+----+ | 0 | 1 | 0 | 0 | 1 | 0 | 1 | 0 | +----+----+----+----+----+----+----+----+ |9th |10th|11th|12th|13th|14th|15th|16th| +----+----+----+----+----+----+----+----+ | 1 | 0 | 1 | 0 | 0 | 0 | 0 | 0 | +----+----+----+----+----+----+----+----+ Figure 3 : A subscriber ID pattern example (on a sharing ration 1:32 address). Subscribers ID value is then assigned by setting subscriber ID pattern bits (s bits shown in the following example) according to a customer value and setting other trivial bits to 1. |1st |2nd |3rd |4th |5th |6th |7th | 8th| +----+----+----+----+----+----+----+----+ | 1 | s | 1 | 1 | s | 1 | s | 1 | +----+----+----+----+----+----+----+----+ |9th |10th|11th|12th|13th|14th|15th|16th| +----+----+----+----+----+----+----+----+ | s | 1 | s | 1 | 1 | 1 | 1 | 1 | +----+----+----+----+----+----+----+----+ Figure 4 : A subscriber ID value example (0# subscriber on this restricted address). Subscriber ID pattern and subscriber ID value together uniquely defines a non-overlapping port set on a restricted IP address. Pseudo-code shown in the Figure 4 describe how to use subscriber ID pattern and subscriber ID value to implement a random ephemeral port selection function in a restricted port set. DBC Expires May 31, 2012 [Page 9] Internet-Draft Lightweight extension to DS-Lite October 2011 do{ restricted_next_ephemeral = (random()| customer_ID_pattern) & customer_ID_value; if(five-tuple is unique) return restricted_next_ephemeral; } Figure 5 : Random ephemeral port selection of restricted port set algorithm. 7. IANA Considerations TBD. 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 8.2. Informative References [I-D.bajko-pripaddrassign] Bajko, G., Savolainen, T., Boucadair, M., and P. Levis, "Port Restricted IP Address Assignment", draft-bajko-pripaddrassign-03 (work in progress), September 2010. DBC Expires May 31, 2012 [Page 10] Internet-Draft Lightweight extension to DS-Lite October 2011 [I-D.bsd-softwire-stateless-port-index-analysis] Boucadair, M., Skoberne, N., and W. Dec, "Analysis of Port Indexing Algorithms", draft-bsd-softwire-stateless-port-index-analysis-00 (work in progress), September 2011. [I-D.cui-softwire-dhcp-over-tunnel] Cui, Y., Wu, P., and J. Wu, "DHCPv4 Behavior over IP-IP tunnel", draft-cui-softwire-dhcp-over-tunnel-01 (work in progress), July 2011. [I-D.cui-softwire-host-4over6] Cui, Y., Wu, J., Wu, P., Metz, C., Vautrin, O., and Y. Lee, "Public IPv4 over Access IPv6 Network", draft-cui-softwire-host-4over6-06 (work in progress), July 2011. [I-D.murakami-softwire-4rd] Murakami, T., Troan, O., and S. Matsushima, "IPv4 Residual Deployment on IPv6 infrastructure - protocol specification", draft-murakami-softwire-4rd-01 (work in progress), September 2011. DBC Expires May 31, 2012 [Page 11] Internet-Draft Lightweight extension to DS-Lite October 2011 [I-D.sun-v6ops-laft6] Sun, Q. and C. Xie, "LAFT6: NAT offload address family transition for IPv6", draft-sun-v6ops-laft6-01 (work in progress), March 2011. 9. Acknowledgments Thank Alain Durand, Ole Troan and Ralph Dorm for their valuable feedback and discussion to this appraoch, and thanks to Qiong Sun for a discussion from operators needs' perspective. Appendix A. Variants of this approach A.1. Introduction This section defines variants of deployment for this NAT offload DS- Lite approach. A.2 describes its combination with stateless encapsulation. A.2 Stateless Encapsulation B4 may implement the stateless encapsulation specified in Section 4.4 of [I-D.ymbk-aplusp]. DBC Expires May 31, 2012 [Page 12] Internet-Draft Lightweight extension to DS-Lite October 2011 Authors' Addresses Xiaohong Deng France Telecom Email: xiaohong.deng@orange.com Mohamed Boucadair France Telecom Rennes, 35000 France Email: mohamed.boucadair@orange.com Cathy Zhou Huawei Technologies Bantian, Longgang District Shenzhen 518129 P.R. China Phone: Email: cathyzhou@huawei.com Tina Tsou Huawei Technologies (USA) 2330 Central Expressway Santa Clara, CA 95050 USA Phone: +1 408 330 4424 Email: tena@huawei.com Gabor Bajko Nokia Email: gabor.bajko@nokia.com DBC Expires May 31, 2012 [Page 13]