Network Working Group Y. Cui Internet-Draft J. Wu Intended status: Standards Track D. Wu Expires: April 21, 2011 Tsinghua University October 18, 2010 B4 translated DS-lite enable AFTR to serve more B4s draft-cui-softwire-b4-translated-ds-lite-00 Abstract The well known Dual Stack lite (DS-lite) technology does great contribution to the deployment of IPv6 and alleviate the shortage of IPv4 address by making it possible to share a single IPv4 address between many hosts. However, the original DS-lite model make AFTR the bottleneck of whole system, thus AFTR's efficiency limits the capability of whole DS-lite model. This draft proposes a B4- translated Ds-lite to alleviate the burden of AFTR so that AFTR is able to serve more B4s. 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 21, 2011. Copyright Notice Copyright (c) 2010 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 Cui, et al. Expires April 21, 2011 [Page 1] Internet-Draft B4-translated DS-lite October 2010 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. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Cui, et al. Expires April 21, 2011 [Page 2] Internet-Draft B4-translated DS-lite October 2010 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Requirements language . . . . . . . . . . . . . . . . . . . . 5 3. B4-translated DS-lite deployment . . . . . . . . . . . . . . . 6 3.1. Handle outbound packets . . . . . . . . . . . . . . . . . 6 3.2. Handle inbound packets . . . . . . . . . . . . . . . . . . 7 4. Port request . . . . . . . . . . . . . . . . . . . . . . . . . 8 4.1. Port request mechanism . . . . . . . . . . . . . . . . . . 8 4.2. Port request policy . . . . . . . . . . . . . . . . . . . 8 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 6.1. Normative References . . . . . . . . . . . . . . . . . . . 10 6.2. Informative References . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 Cui, et al. Expires April 21, 2011 [Page 3] Internet-Draft B4-translated DS-lite October 2010 1. Introduction B4-translated DS-lite is a variant of original DS- lite[I-D.ietf-softwire-dual-stack-lite], it alleviates the burden of AFTR, thus to increase the throughput of AFTR. In DS-lite deployment, a single AFTR might serves thousands of B4s. In this condition, the efficiency of AFTR becomes the bottleneck of whole system. It is desirable to increase the AFTR's efficiency. If the AFTR can be more efficient, a single AFTR is able to serve more B4s. AFTR takes charge of packet encapsulation/decapsulation, packet forwarding and address translation. In the three operations, address translation is a heavy job, because address translation involves searching mapping table, which might consist of tens of thousands of entries. When the search algorithm is implemented by hardware, a large mapping table will cost a great amount of hardware resources on AFTR.In the meantime, the address translation is the only operation that can be moved to B4 side. On the contrary, B4 is only responsible for encapsulation/ decapsulation and there are many B4s served by a single AFTR, thus moving the address translation to B4 side will not add much burden to a single B4. In conclusion, it is desirable to move address translation from AFTR to B4 side, it is feasible, and enables a single AFTR to serve more B4s.this draft proposed the B4-translated DS-lite to enable AFTR to serve more B4s by moving address translation to B4 side. Cui, et al. Expires April 21, 2011 [Page 4] Internet-Draft B4-translated DS-lite October 2010 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 21, 2011 [Page 5] Internet-Draft B4-translated DS-lite October 2010 3. B4-translated DS-lite deployment This section describle the steps when a host behind B4 communicates with another host resides in Internet. 3.1. Handle outbound packets The B4 must know the external address and port in order to do address translation, thus the B4 must first establish mapping before traslation. In B4-translated DS-lite mechanism, it is suggested that the hosts are not aware of mapping establishment in B4. Figure 1 shows an example of mapping establishment in B4. In this example, the mapping establishment is conducted automatically when a packet, which contains an unknown source address-port combination, arrives. host B4 AFTR |----(1)-------------->| | | |---------(2)--------->| | |<--------(3)----------| | |---------(4)--------->| Figure 1 Mapping establishment 1. A host connected to a server on Internet, so it sends a packet to its default gateway, which is B4. If the B4 knows the corresponding external address of the source address, jump to step 4. 2. Gateway which functions as B4, obtains the source address-port of the outbound packet and requests to AFTR for a corresponding external address-port. 3. AFTR allocates an external address-port and responds to B4.When B4 receives this response, it records the internal address, internal port, external address and external port in a mapping table. This mapping table will be used to support the address translation of each received packet. 4. B4 does the address translation to the packet according to the mapping table and encapsulate this packet before sending it to AFTR. When AFTR receives this packet, it first records the source ipv4 address, source port number and ipv6 address of corresponding tunnel end point and then decapsulates the packet and forwards it to Internet.The source ipv4 address, source port Cui, et al. Expires April 21, 2011 [Page 6] Internet-Draft B4-translated DS-lite October 2010 number and ipv6 address comprise an entry of encapsulation table. This table will be used when inbound packets arrive. 3.2. Handle inbound packets When an inbound packet arrives at AFTR, AFTR checks the destination address-port and search the encapsulation table. Then AFTR encapsulate the packet and send it to its corresponding B4. When B4 receive the inbound packet, it simply decapsulate the packet, replace its destination address and port number and send it to the host. Cui, et al. Expires April 21, 2011 [Page 7] Internet-Draft B4-translated DS-lite October 2010 4. Port request 4.1. Port request mechanism In 3.1., B4 has the demand to learn the external address and port for the sake of successful address translation. Pinhole Control Protocol(PCP)[I-D.wing-softwire-port-control-protocol]can be leveraged to make needs meet. PCP is primarily used to enalbe PCP client to control how inbound packets are forwarded by upstream NAT devices so as to behave as a serve. Thus it enables PCP client to learn the external address and port. So the B4-translated DS-lite can leveraged Pinhole Control Protocol (PCP) mechanism to request ports. 4.2. Port request policy There are two strategy for B4 to request ports. One is to request on demand, which means that B4 only request for a new port when a packet, which can not be translated, arrives. This strategy has a main drawback that port request is called when each traffic flow begins. Every flow is subjected to a request and responce, which will increase the latency of packet sending. The other one is to request several ports at a time, thus the B4 can handle more outbound packets without another request.With this strategy, B4 is responsible for port management and original PCP request MUST be extended to support requesting a series of port number. This strategy also have drawbacks because it might due to the inefficient use of port sources. The request policy can be adjusted according to the demand of service provider. Cui, et al. Expires April 21, 2011 [Page 8] Internet-Draft B4-translated DS-lite October 2010 5. Acknowledgements Cui, et al. Expires April 21, 2011 [Page 9] Internet-Draft B4-translated DS-lite October 2010 6. References 6.1. Normative References [I-D.ietf-softwire-dual-stack-lite] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- Stack Lite Broadband Deployments Following IPv4 Exhaustion", draft-ietf-softwire-dual-stack-lite-06 (work in progress), August 2010. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 6.2. Informative References [I-D.wing-softwire-port-control-protocol] Wing, D., Penno, R., and M. Boucadair, "Pinhole Control Protocol (PCP)", draft-wing-softwire-port-control-protocol-02 (work in progress), July 2010. Cui, et al. Expires April 21, 2011 [Page 10] Internet-Draft B4-translated DS-lite October 2010 Authors' Addresses Yong Cui Tsinghua University Department of Computer Science, Tsinghua University Beijing 100084 P.R.China Phone: +86-10-6260-3059 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-6278-5983 Email: jianping@cernet.edu.cn Dan Wu Tsinghua University Department of Computer Science, Tsinghua University Beijing 100084 P.R.China Phone: +86-10-6277-7347 Email: wudanzy@csnet1.cs.tsinghua.edu.cn Cui, et al. Expires April 21, 2011 [Page 11]