Network Working Group Y. Cui Internet-Draft J. Wu Intended status: Standards Track P. Wu Expires: April 27, 2012 Tsinghua University Q. Sun C. Xie China Telecom C. Zhou Huawei Technologies Y. Lee Comcast October 25, 2011 Lightweight 4over6 in access network draft-cui-softwire-b4-translated-ds-lite-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. However, in dual-stack lite, CGN has to maintain active NAT sessions, which could become the performance bottom-neck due to high dynamic s of NAT entries, memory cost and log issue. This document propose the lightweight 4over6 mechanism which moves the translation function from tunnel concentrator (AFTR) to initiators (B4s), and hence reduce the mapping scale on the concentrator to per-customer level. For NAT44 translation usage, the mechanism will allocate port restricted IPv4 addresses to initiators in a flexible way independent of IPv6 network in the middle. 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." This Internet-Draft will expire on April 27, 2012. Cui, et al. Expires April 27, 2012 [Page 1] Internet-Draft B4-translated ds-lite October 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 . . . . . . . . . . . . . . . . . . . . 5 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Lightweight 4over6 Overview . . . . . . . . . . . . . . . . . 7 5. Port Restricted IPv4 Address Allocation . . . . . . . . . . . 8 6. Lightweight 4over6 Initiator Behavior . . . . . . . . . . . . 9 7. Lightweight 4over6 Concentrator Behavior . . . . . . . . . . . 10 8. Fragmentation and Reassembly . . . . . . . . . . . . . . . . . 11 9. DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 10. ICMP processing . . . . . . . . . . . . . . . . . . . . . . . 13 11. Mechanism Analysis . . . . . . . . . . . . . . . . . . . . . . 14 12. Security Consideration . . . . . . . . . . . . . . . . . . . . 15 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 Cui, et al. Expires April 27, 2012 [Page 2] Internet-Draft B4-translated ds-lite October 2011 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. This procedure allows AFTR to dynamically assign sessions to users when needed; hence, increases port-sharing radio and utilization. There is a trade-off, though. 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. We propose to create rule mapping in the AFTR and distributes the dynamic NAT table into B4 elements. The B4 element will be provisioned with an IPv6 address, an IPv4 address and a port-range. The IPv6 address will be used to create the Softwire. The IPv4 address and port-range will be used for NAT-44 in the home gateway(CPE). Most CPE have been performing NAT-44 today. The CPE will perform PAT on user's packets with the IPv4 address and port- range provisioned by the ISP. The packets are forwarded between the CPE and the AFTR by IPv6 encapsulation over the tunnel. The AFTR will maintain a static mapping entry with the IPv6 address, IPv4 address and port-range per user. 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 static mapping table to encapsulate the packets to the destination CPE. The AFTR would not create NAT entry per sessions. This will significantly reduce the AFTR's NAT table size. Compared to DS-lite, this extension reduces the AFTR NAT table size. Each entry represents a B4 element. This also relaxes the requirement to create a log entry per dynamic session. AFTR only needs to keep a log entry per B4 element. This is also an extended case which covers addressing sharing for [I-D.cui-softwire-host-4over6]. However, the extension will decrease IPv4 address utilization. Moreover, since port randomization algorithm must use ports within this port-range, it may cause the port randomization algorithm more predictable. Cui, et al. Expires April 27, 2012 [Page 3] Internet-Draft B4-translated ds-lite October 2011 Compared to stateless solutions with port range/set allocation such as 4rd, this mechanism is suitable for operators who prefers 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 to administrate and manage many 4rd domains in the network and mapping rules in the CPEs. Cui, et al. Expires April 27, 2012 [Page 4] Internet-Draft B4-translated ds-lite October 2011 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 [RFC2119]. Cui, et al. Expires April 27, 2012 [Page 5] Internet-Draft B4-translated ds-lite October 2011 3. Terminology Starting from here, the document will use the terminologies of lightweight 4over6 instead of DS-lite for distinction. Lightweight 4over6: lightweight 4over6 is an IPv4-over-IPv6 hub and spoke mechanism proposed in this document, which supports address sharing to deal with IPv4 address exhaustion, and places the IPv4 translation on the initiator side. Lightweight 4over6 initiator (or "initiator" for short): the tunnel initiator in lightweight 4over6 mechanism. The lightweight 4over6 initiator could be a host directly connected to IPv6, or an dual- stack CPE in front of an IPv4 local network. It is responsible for IPv4 public-private translation besides tunnel encapsulation and decapsulation. Lightweight 4over6 concentrator (or "concentrator" for short): the tunnel concentrator in lightweight 4over6 mechanism. The lightweight 4over6 concentrator connects the ISP IPv6 network and IPv4 Internet. It provides tunnel encapsulation and decapsulation but no IPv4 public-private translation. Cui, et al. Expires April 27, 2012 [Page 6] Internet-Draft B4-translated ds-lite October 2011 4. Lightweight 4over6 Overview Figure 1 provides an overview of the lightweight 4over6 mechanism. A lightweight 4over6 initiator which can be either an IPv6 hosts or CPE, and the lightweight 4over6 concentrator are separated by the IPv6 network in the middle, so they use IPv4-in-IPv6 tunnel to build IPv4 connectivity. An initiator uses IPv4 address with restricted port range for this IPv4 connectivity, which is acquired through either DHCPv4 with the concentrator, or through PCP with the PCP server. The concentrator keeps the mapping between initiator's IPv6 address and the allocated IPv4 address + port range. +-------------------------+ | IPv6 ISP Network | | | +---------+ | |LW 4over6|Host | |Initiator|===============+---------+ +-----------+ +---------+ |LW 4over6| | IPv4 | +--------+ | IPv4-in-IPv6 |Concen- |---| Internet | | | +---------+ |trator | | | |IPv4 LAN|--|LW 4over6|===============+---------+ +-----------+ | | |Initiator|CPE |DHCPv4 +--------+ +---------+ +----------+ |Server(Relay) | |PCP Server| | | +----------+ | +-------------------------+ Figure 1 Lightweight 4over6 overview Cui, et al. Expires April 27, 2012 [Page 7] Internet-Draft B4-translated ds-lite October 2011 5. Port Restricted IPv4 Address Allocation As is described above, a lightweight 4over6 initiator needs the public address and port for stateful translation. This is be achieved by basic PCP mechanism [I-D.ietf-pcp-base]. It's obvious that individual address + port allocation when required is not efficient due to round-trip time delay and high signaling volume caused. A practical manner would be allocating a group of address + port at one time beforehand, i.e., allocating IPv4 address with a port range, which is known as "restricted address". To our knowledge there're two methods which are probably suitable for restricted address allocation from concentrator to initiator. 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]. The other is extending PCP to support port range control. See [I-D.tsou-pcp-natcoord] for details. Adopting either method, An initiator can get port restricted IPv4 addresses allocated dynamically from the concentrator, i.e. the dynamic mapping rule between IPv4 address, port range and IPv6 address can be passed down to the initiator in the initiation phase. Unlike stateless 4over6 solutions such as [I-D.murakami-softwire-4rd], the port restricted address allocation in lightweight 4over6 has no requirement on careful planning of the IPv6 domain range, IPv4/IPv6 mapping relationship, prefix length and multiplex ratio, etc. It is quite flexible for ISPs to manage the IPv6 access network and have no impact on IPv6 routing. Cui, et al. Expires April 27, 2012 [Page 8] Internet-Draft B4-translated ds-lite October 2011 6. Lightweight 4over6 Initiator Behavior A lightweight 4over6 initiator should support either extended DHCP client, or extended PCP client, as is described above. When requiring IPv4 access, the initiator would run either client to get a dynamic port restricted IPv4 address, and renew/extend it when the lease/lifetime is about to expire. The data plane functions of the initiator includes translation and encapsulation/decapsulation. For CPE initiator case, the initiator runs a standard local NAT44 with the address pool consist of the allocated port restricted address. When sending out an IPv4 packet with private source address, it performs NAT44 function and translates the source address into public. Then it encapsulates the packet with concentrator's IPv6 address as destination IPv6 address, and forward it to the concentrator. When receiving an IPv4-in-IPv6 packet from the concentrator, the initiator decapsulates the IPv6 packet to get the IPv4 packet with public destination IPv4 address. Then it performs NAT44 function and translates the destination address into private. For host initiator 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, valid port range. Private- 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, valid range to applications. Either way the host guarantees that every port number in the packets sent out by itself falls into the allocated port range. Cui, et al. Expires April 27, 2012 [Page 9] Internet-Draft B4-translated ds-lite October 2011 7. Lightweight 4over6 Concentrator Behavior The lightweight 4over6 concentrator should either allocate port restricted addresses directly(perform an extended DHCPv4 server, or an 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 concentrator simultaneously install a mapping entry into the mapping table. This entry consists of the public IPv4 address, the port range and initiator's IPv6 address. Its lifetime is set according to the allocation. 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 initiator renews/ extends the allocation. The data plane functions of the concentrator is purely encapsulation and decapsulation. When receiving an IPv4-in-IPv6 packet from an initiator, the concentrator 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 initiator's IPv6 address in the mapping table. Then the concentrator encapsulates this packet using the IPv6 address found in the table as IPv6 destination address, and forwards it to the correct initiator based on native IPv6 routing. Hence there is no port-range routing in IPv6 network anymore. Cui, et al. Expires April 27, 2012 [Page 10] Internet-Draft B4-translated ds-lite October 2011 8. Fragmentation and Reassembly There is no change to [RFC6333] in fragmentation and reassembly behavior. Cui, et al. Expires April 27, 2012 [Page 11] Internet-Draft B4-translated ds-lite October 2011 9. DNS The DNS implementation is also the same to [RFC6333]. Cui, et al. Expires April 27, 2012 [Page 12] Internet-Draft B4-translated ds-lite October 2011 10. ICMP processing ICMP availability would become a challenge in port restricted address environment. To support ICMP "session" initiated from a lightweight 4over6 initiator, the mechanism divides ICMP id field in the same way with dividing port space, i.e. each initiator will get the ICMP id range which is identical to the allocated port range. An initiator only uses the allocated address and restricted id range when send out an ICMP request. Hence the concentrator can encapsulate the corresponding ICMP reply correctly according to the ICMP id field. The inbound ICMP request would be left unsupported on the concentrator, which is the similar behavior of NAT/CGN. See details about ICMP processing in section 4.2 of [I-D.sun-v6ops-laft6] Cui, et al. Expires April 27, 2012 [Page 13] Internet-Draft B4-translated ds-lite October 2011 11. Mechanism Analysis Compared with original dual-stack lite, lightweight 4over6 removes the translation burden from the concentrator and distribute the job to initiators on user-side. Also it decreases the state scale on concentrator from per-session level down to per-user level. This would significantly reduce the hardware cost of the concentrator, and relieve the situation that the concentrator becomes the performance bottleneck. Leveraging lightweight 4over6, one concentrator can serve a lot more customers. Besides, since this mechanism reduces the number of simultaneous address mappings of each customer on concentrator to one, it makes concentrator logging much more feasible. Moreover, locating the translation on user side eases the ALG and NAT referral problem since it'll be no different from the situation of local NAT in today's IPv4 network. Solutions like uPnP already exist for quite a long time. Most current CPEs have already implemented NAT44 functionalities, lightweight 4over6 would not bring a lot more complexity to existing CPEs. Lightweight 4over6 allocates port restricted address independent of the IPv6 network in the middle. No specific IPv6 address format is required. IPv4 and IPv6 addressing and routing remain separated. The ISP can provide IPv4 in a flexible, on-demand way, as well as manage the native IPv6 network without the influence of IPv4-over- IPv6 requirements. And it would also be easy to achieve future adjustment of IPv4 address pool. The costs of lightweight 4over6 for achieving all these benefits are lower IPv4 address utilization ratio and extra signaling behavior. The address multiplexing manner of port restricted address is relatively more static than the CGN manner. This may cause the port randomization algorithm more predictable. There are solutions which increase the prediction difficulty at the cost of more sophisticated port rule mapping [I-D.bsd-softwire-stateless-port-index-analysis]. And dual-stack lite doesn't require address and port allocation between concentrator and initiators. When compared to stateless solutions, lightweight 4over6 still keeps per-user states rather than becoming purely stateless. Cui, et al. Expires April 27, 2012 [Page 14] Internet-Draft B4-translated ds-lite October 2011 12. Security Consideration Since port randomization algorithm must use ports within this port- range, it may cause the port randomization algorithm more predictable. Therefore, non-continuous port set algorithms (e.g. as defined in [I-D.mdt-softwire-mapping-address-and-port]) can be introduced to further improve the security. Cui, et al. Expires April 27, 2012 [Page 15] Internet-Draft B4-translated ds-lite October 2011 13. 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. [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.ietf-pcp-base] Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. Selkirk, "Port Control Protocol (PCP)", draft-ietf-pcp-base-16 (work in progress), October 2011. [I-D.mdt-softwire-mapping-address-and-port] Troan, O., "Mapping of Address and Port (MAP)", draft-mdt-softwire-mapping-address-and-port-00 (work in progress), October 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. [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. [I-D.tsou-pcp-natcoord] Zhou, C., ZOU), T., Deng, X., Boucadair, M., and Q. Sun, Cui, et al. Expires April 27, 2012 [Page 16] Internet-Draft B4-translated ds-lite October 2011 "Using PCP To Coordinate Between the CGN and Home Gateway Via Port Allocation", draft-tsou-pcp-natcoord-03 (work in progress), July 2011. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- Stack Lite Broadband Deployments Following IPv4 Exhaustion", RFC 6333, August 2011. Cui, et al. Expires April 27, 2012 [Page 17] Internet-Draft B4-translated ds-lite October 2011 Authors' Addresses 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 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: weapon@csnet1.cs.tsinghua.edu.cn 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 Cui, et al. Expires April 27, 2012 [Page 18] Internet-Draft B4-translated ds-lite October 2011 Phone: +86-10-58552116> Email: xiechf@ctbri.com.cn Cathy Zhou Huawei Technologies Section B, Huawei Industrial Base, Bantian Longgang Shenzhen 518129 P.R.China Phone: +86-10-58552116> Email: cathyzhou@huawei.com Yiu L. Lee Comcast One Comcast Center Philadelphia, PA 19103 USA Email: yiu_lee@cable.comcast.com Cui, et al. Expires April 27, 2012 [Page 19]