Network Working Group Xiaohong Deng Internet Draft M. Boucadair Intended status: Standards Track France Telecom Expires: April 2012 P. Wu Tsinghua University Q. Sun China Telecom C. Zhou Huawei Technologies October 25, 2011 Lightweight extension to Dual-Stack lite draft-zhou-softwire-b4-nat-03 Abstract The dual-stack lite mechanism provide an IPv4 access method over IPv6 ISP network for end users. Dual-Stack Lite enables an IPv6 provider to share IPv4 addresses among customers by combining IPv4-in-IPv6 tunnel and Carrier Grade NAT technologies. However, with basic Dual- stack Lite approach, CGN has to maintain active NAT sessions, which requires processing performance, memory size for NAT sessions and log abilities scale with number of sessions from subscribers, and hence result in increasing of CAPEX for operators when traffic increase. This document propose the lightweight extensions to DS-Lite, which allows offloading NAT translation function from centralized network side (AFTR) to distributed customer equipments (B4), thereby offering flexibilities for ISPs to adjust trade-off between CAPEX (e.g. less performance requirements on AFTR device), OPEX (e.g., easy and fast deployment of Dual-Stack Lite). The ability of easily co-deploying with basic Dual-Stack Lite is essential to lightweight 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/. DBW Expires April 25, 2012 [Page 1] Internet-Draft Lightweight extension to DS-Lite October 2011 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." 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. Introduction.....................................................3 2. Lightweight extended DS-Lite Overview and terminologies..........4 3. NATed B4 Behavior................................................5 3.1. Plain IPv4 Address..........................................6 3.2. Restricted IPv4 Address and port set provisioning...........6 3.2.1. Restricted port allocation strategies and requirements.6 3.2.2. Restricted IPv4 Address and port set provisioning method .............................................................6 3.3. Outgoing Packets Processing.................................7 3.4. Incoming Packets Processing.................................7 3.4.1. Incoming Ports considerations on a given restricted IPv4 address.......................................................7 4. Lightweight AFTR Behaviour.......................................8 5. Fragmentation and Reassembly and DNS.............................8 6. ICMP processing..................................................9 DBW Expires April 25, 2012 [Page 2] Internet-Draft Lightweight extension to DS-Lite October 2011 7. Security Considerations..........................................9 8. IANA Considerations.............................................11 9. References......................................................12 9.1. Normative References.......................................12 9.2. Informative References.....................................12 10. Acknowledgments................................................13 1. Introduction Dual-stack lite technology [RFC6333] provides IPv4 access over IPv6 access network. Dual-Stack lite (DS-lite) also mitigates IPv4 address exhaustion by sharing public IPv4 addresses amongst users.The B4 element establishes an IPv4-in-IPv6 softwire to the AFTR and encapsulates the IPv4 packets into the softwire. When AFTR receives the IPv6 packets, it will decapsulate them and perform NAT-44 on the packets. The AFTR is required to maintain active NAT sessions. In a centralized deployment models where one AFTR serves thousands of users, the large numbers of NAT sessions may become performance bottom-neck. First, maintaining active NAT sessions requires AFTR constantly creating and purging NAT sessions. Second, a large NAT table demands more processing power for searching and more memory space. In addition, dynamic session-based NAT will create large number of log entries, which will also be a challenging problem. To address these issues, we propose an extension to DS-lite. The B4 element will be provisioned with an IPv6 address, an IPv4 address and restricted port sets, so that address and port translation can be performed at the customer side, e.g.,CPE, with only one requirement that port translation should inside the restricted port sets. The IPv4 traffic over IPv6 transport would reuse the basic DS-Lite infrastructure, including tunneling transport and provisioning method as well, and share basic idea of using mapping table on a per IPv6 address basis to initiate customers. The AFTR will then only maintain a static mapping entry between the IPv6 address, IPv4 address and port set ID, instead of maintain NAT entries per session. For inbound IPv4 packet on AFTR, it would use the IPv4 destination address and port as the index and use the forwarding rule in the mapping table to encapsulate the packets to the destination CPE. Compared to DS-lite, this lightweight extension makes the AFTR table scales with customer number other than traffic sessions. Based on this lightweight extension, log entries for per subscriber instead of per session is also achiveble.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. DBW Expires April 25, 2012 [Page 3] Internet-Draft Lightweight extension to DS-Lite October 2011 Compared to stateless solutions with port set allocation such as 4rd, this mechanism is suitable for operators who prefer to keep IPv6 and IPv4 addressing separated. For example, an operator may want to provide IPv4 with an on-demand way in its IPv6 network, the dynamic allocation of IPv4 address and port makes more efficient usage of IPv4 resource. Another example is that an operator may only have many small and discontinuous IPv4 blocks available to provide IPv4 over IPv6, rather than a few big IPv4 blocks. This mechanism keeps dynamic feature of IPv4-IPv6 address binding as in DS-Lite, so it won't require administrating and managing many 4rd domains in the network and mapping rules in the CPEs. 2. Lightweight extended DS-Lite Overview and terminologies Figure 1 provides an overview of the lightweight extended DS-Lite. +-------------------------+ | IPv6 ISP Network | | | | | +-------------------------+ | | +-----------+ +----------+ | |Lightweight| | IPv4 | +--------+ | IPv4-in-IPv6 |AFTR |---| Internet | | | +---------+ | | | | |IPv4 LAN|--|NATed |===============+-----------+ +----------+ | | |B4 |CPE/HOST | +--------+ +---------+ | | | | | +-------------------------+ Figure 1 : Lightweight extended DS-Lite Overview DBW Expires April 25, 2012 [Page 4] Internet-Draft Lightweight extension to DS-Lite October 2011 NATed B4: A Lightweight 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. Lightweight AFTR: A Lightweight extended AFTR which is called Lightweight 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 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]. DBW Expires April 25, 2012 [Page 5] Internet-Draft Lightweight extension to DS-Lite October 2011 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. Unlike stateless 4over6 solutions such as [I-D.murakami-softwire- 4rd], the restricted port sets allocation for Lightweight extended DS-Lite has no requires on careful planning of the IPv6 domain range, IPv4/IPv6 mapping relationship, prefix length and multiplex ratio, etc. 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 One is extending DHCP to support address allocation with port range embedded. [I-D.bajko-pripaddrassign] discusses this DHCP usage. In this special context, we need to build the DHCPv4 procedure over IPv6 [I-D.cui-softwire-dhcp-over-tunnel]. DBW Expires April 25, 2012 [Page 6] Internet-Draft Lightweight extension to DS-Lite October 2011 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. Adopting either method, An NATed B4 can have a restricted port set with an IPv4 addresses allocated from the lightweight AFTR. 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 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. Lightweight AFTR Behaviour DBW Expires April 25, 2012 [Page 7] Internet-Draft Lightweight extension to DS-Lite October 2011 The lightweight AFTR should either allocate port restricted addresses directly (perform an extended DHCPv4 server, or a basic or/extended PCP server), or leave the allocation to dedicated DHCP/PCP server (and perform a relay in DHCP case). When accomplishing one such allocation, the lightweight AFTR simultaneously install a mapping entry into the mapping table. This entry consists of the public IPv4 address the port set ID and NATed's IPv6 address. Its lifetime is set as per restricted IPv4 provisioning method. It'll be used for encapsulation of inbound packets. This mapping entry would be deleted when the lifetime expires, and refresh its lifetime when the NATed B4 renews/extends the allocation. The data plane function of the lightweight AFTR is purely encapsulation and decapsulation. When receiving an IPv4-in-IPv6 packet from an NATed B4, the lightweight AFTR decapsulates it and forwards it to IPv4 Internet. When receiving an IPv4 packet from the Internet, it uses the destination address and port from this packet to lookup the destination NATed B4's IPv6 address in the mapping table. Then the lightweight AFTR encapsulates this packet using the IPv6 address found in the table as IPv6 destination address, and forwards it to the correct NATed B4 based on native IPv6 routing. Since basic DS-Lite transporting infrastructure is re-used, no influence introduced from IPv4 routing to the IPv6 routing. 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]. 6. ICMP processing ICMP availability would become a challenge in port restricted address environment. To support ICMP "session" initiated from a NATed B4, the mechanism divides ICMP id field in the same way with dividing port space, i.e. each NATed B4 will get the ICMP id range which is identical to the allocated port range. A NATed B4only uses the DBW Expires April 25, 2012 [Page 8] Internet-Draft Lightweight extension to DS-Lite October 2011 allocated address and restricted id range when send out an ICMP request. Hence the lightweight AFTR can encapsulate the corresponding ICMP reply correctly according to the ICMP id field. The inbound ICMP request would be left unsupported on the NATed AFTR, which is the similar behavior of NAT/CGN. See details about ICMP processing in section 4.2 of [I-D.sun-v6ops-laft6] 7. 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 lightweight 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). DBW Expires April 25, 2012 [Page 9] Internet-Draft Lightweight extension to DS-Lite October 2011 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 lightweight 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. |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). DBW Expires April 25, 2012 [Page 10] Internet-Draft Lightweight extension to DS-Lite October 2011 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. 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. 8. IANA Considerations TBD. 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 9.2. Informative References [I-D.bajko-pripaddrassign] DBW Expires April 25, 2012 [Page 11] Internet-Draft Lightweight extension to DS-Lite October 2011 Bajko, G., Savolainen, T., Boucadair, M., and P. Levis, "Port Restricted IP Address Assignment", draft-bajko-pripaddrassign-03 (work in progress), September 2010. [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 DBW Expires April 25, 2012 [Page 12] Internet-Draft Lightweight extension to DS-Lite October 2011 Residual Deployment on IPv6 infrastructure - protocol specification", draft-murakami-softwire-4rd-01 (work in progress), September 2011. [I-D.sun-v6ops-laft6] Sun, Q. and C. Xie, "LAFT6: Lightweight address family transition for IPv6", draft-sun-v6ops-laft6-01 (work in progress), March 2011. 10. Acknowledgments TBD Appendix A. Variants of this approach A.1. Introduction This section defines variants of deployment for this lightweight 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]. DBW Expires April 25, 2012 [Page 13] 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 Yong Cui Tsinghua University Department of Computer Science, Tsinghua University Beijing 100084 P.R.China Phone: +86-10-62603059 Email: yong@csnet1.cs.tsinghua.edu.cn Jianping Wu Tsinghua University Department of Computer Science, Tsinghua University DBW Expires April 25, 2012 [Page 14] Internet-Draft Lightweight extension to DS-Lite October 2011 Beijing 100084 P.R.China Phone: +86-10-62785983 Email: jianping@cernet.edu.cn Peng Wu Tsinghua University Department of Computer Science, Tsinghua University Beijing 100084 P.R.China Phone: +86-10-62785822 Email: peng-wu@foxmail.com Qiong Sun China Telecom Room 708, No.118, Xizhimennei Street Beijing 100035 P.R.China Phone: +86-10-58552936> Email: sunqiong@ctbri.com.cn Chongfeng Xie China Telecom Room 708, No.118, Xizhimennei Street Beijing 100035 P.R.China Yiu L. Lee Comcast One Comcast Center Philadelphia, PA 19103 USA Email: yiu_lee@cable.comcast.com Gabor Bajko Nokia Email: gabor.bajko@nokia.com DBW Expires April 25, 2012 [Page 15]