Network Working Group G. Chen Internet-Draft H. Deng Intended status: Experimental B. Zhou Expires: April 29, 2010 China Mobile M. Xu L. Song Y. Cui Tsinghua University October 26, 2009 Reliable and Scalable NAT mechanism (RS-NAT) based on BGP for IPv4/IPv6 Transition draft-chen-behave-rsnat-02 Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on April 29, 2010. Copyright Notice Copyright (c) 2009 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 in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Chen, et al. Expires April 29, 2010 [Page 1] Internet-Draft RS-NAT April 2009 Abstract For the rapid exhaustion of IPv4 address pool against the slow development of IPv6, IPv4/IPv6 co-existence/transition would be a long period. In the IPv4/IPv6 transition process, there are many NAT- like technologies active in the internet. However, the NAT boxes such as IPv4 NAT, IPv4/IPv6 NAT are so poor in their reliability and scalability, which put a severe threat on the development of IPv4/IPv6 transition. This document defines a reliable and scalable NAT (RS- NAT) mechanism to solve the problem. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. RS-NAT Overview . . . . . . . . . . . . . . . . . . . . . . . 4 3. RS-NAT Box . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Load Balancing Mechanisms . . . . . . . . . . . . . . . . . . 6 4.1. IPv6-IPv4 scenario . . . . . . . . . . . . . . . . . . . . 6 4.2. IPv4-IPv6 scenario . . . . . . . . . . . . . . . . . . . . 7 5. Redundancy Mechanisms . . . . . . . . . . . . . . . . . . . . 9 5.1. Address mapping Attribute . . . . . . . . . . . . . . . . 9 5.2. Performance consideration . . . . . . . . . . . . . . . . 10 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 8.1. Normative References . . . . . . . . . . . . . . . . . . . 13 8.2. Informative References . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 Chen, et al. Expires April 29, 2010 [Page 2] Internet-Draft RS-NAT April 2009 1. Introduction For the rapid exhaustion of IPv4 address pool against the slow development of IPv6, IPv4/IPv6 co-existence/transition would be a long period. In order to facilitate the connectivity between IPv4 and IPv6 network, a NAT functionality should be deployed on the edge of different IP family network. However most of the NAT-like functions are stateful, which maintain the state of address mapping for network translation or ALG function. The stateful boxes in the network will bring high risks on reliability and scalability when the network becomes huge. For example the box will be a single point of failure in a large-scale network. Although some advices are proposed such as NAT64 using multi-box, the static configuration and localized mapping information in each box are not able to accommodate the dynamic internet environment. In this document, we proposed a Reliable and Scalable NAT (RS-NAT) mechanism to overcome the stateful NAT problem mentioned above, which include IPv4 NAT and IPv4/IPv6 NAT. Chen, et al. Expires April 29, 2010 [Page 3] Internet-Draft RS-NAT April 2009 2. RS-NAT Overview In the topology shown in Figure 1, the network can be divided into two parts: the User Network and Service Network. User Network is the realm where the users initiate a communication with servers. The Service Network is the realm where the remote destination (e.g., server) is attached. In addition there are some RS-NAT boxes which act as bridges between these networks. ____________ _______________ /. .. .. .. .\ +--------+ /. .. .. .. .. .\ | |--|RS-NAT A|--| | | | +--------+ | | |User Network| | |Service Network| | | +--------+ | | |. .. .. .. .|--|RS-NAT B|--|. .. .. .. .. .| \____________/ +--------+ \_______________/ Figure 1: General Topology of RS-NAT framework The User Network and Service Network could be IPv4,IPv6 or Dual- stack. As a result, there are several communication scenarios could be deduced from the general topology using the form of IPvx-IPvy, which means users with IPvx protocol initiate connections to servers reachable with IPvy protocol. These communication scenarios are (private)IPv4-IPv4, IPv4-IPv6, IPv6-IPv4, and IPv6-IPv6. VRRP[RFC3768] is suitable for IPv4-IPv4 scenarios and there is no need to use NAT for IPv6-IPv6. So in this document we mainly focus on IPv4-IPv6/IPv6-IPv4 interconnection scenarios. The User Network and Service Network are logical concepts, which may be composed of several ASes. For example, the User Network shown in Figure 1 may consist of several IPv4 networks belong to diffrent network providers. The User Network may connect to Service Network separately through RS-NAT boxes on which BGP [RFC4271] is performed . Note that the User Network and Service Network are exchangable because an end user can be regarded as both initiator and server from different views. Chen, et al. Expires April 29, 2010 [Page 4] Internet-Draft RS-NAT April 2009 3. RS-NAT Box The following Sections will discuss the requirements of RS-NAT Box and its basic embedded functions. In order to achieve the role of bridge between the two networks in the studied scenarios, which are depicted in Sections 3, the RS-NAT box is capable of dual-stack and forwording traffic based on IPv4/ IPv6 protocol translator. In the IPv6-IPv4 scenario RS-NAT router advertises different Prefix64s [I-D.miyata-behave-prefix64] routing information to User Network, and advertise the prefix info of static IPv4 address pool to Service Network. In this scenario, DNS64[I-D.bagnulo-behave-dns64] is employed to assign different Prefix64 for each DNS request randomly, which will be discussed in Section 5. In the IPv4-IPv6 scenario RS-NAT router advertises its own IPv6 prefix routing information to Service Network, and sends the prefix info of static IPv4 address pool to User Network. In this scenario, DNS ALG mentioned in NAT-PT[RFC2766] will be modified to support the separation of the data plane and control plane, which will be discussed in Section 5. The address mapping modules in RS-NAT is useful not only for the IP head translation, but essential for some application that embed network-layer addresses as well, such as FTP, SIP etc. Chen, et al. Expires April 29, 2010 [Page 5] Internet-Draft RS-NAT April 2009 4. Load Balancing Mechanisms This Section will show how the RS-NAT run and balance the traffic among these RS-NAT boxes. 4.1. IPv6-IPv4 scenario Figure 2 illustrates the connection setup in the IPv6-IPv4 scenario. The connection set-up follows two steps: 1) User sends DNS query to DNS64 and gets the DNS reply with an IPv4- embedded IPv6 addresses in the form of Prefix64::IPv4 address; 2) User sends the packet to the IPv4-embeded IPv6 addresses. The different IPv6 prefix will lead the packet to different RS-NAT routers, which is achieved by the RS-NAT routing function. The Control Plane .................... +-----+ .........|DNS64| . +-----+ +----+. +------+ +------+ |User| --------- |RS-NAT|---------|server| +----+\ +------+ /+------+ \ +------+ / ---------|RS-NAT|------- +------+ -------------------- The Data Plane Figure 2: IPv6-IPv4 Connection Setup As mentioned previously RS-NAT routers run BGP and keep BGP neighbor information with each other. Each RS-NAT router will maintain the IPv6 prefix which is identical with the prefix DNS64 stores. RS-NAT will performe a Prefix-Assignment Algorithm to decide individually which part of Prefix64 they are in charge of. The Prefix-Assignment Algorism follows the new idea that the IPv6 prefix is equally divided into several portions. And, each of them is assigned to RS-NAT routers. For example, there is 2^8 2001::/24 in Prefix64 pool of 2001::/16 and 2 RS-NAT routers. The Assignment plan is that prefixes from 2001: 0000::/24 to 2001:7f00::/24 will be assigned to the router with larger IPv4 address, and the prefixes from 2001:8000::/24 to 2001: ff00::/24 is in the charge of the other router. If there are more Chen, et al. Expires April 29, 2010 [Page 6] Internet-Draft RS-NAT April 2009 RS-NAT routers, these prefixes can also easy assigned to them according to the IP address sorting. In order to balance the traffic among these RS-NAT routers, each router should advertise the route of its aggregated Prefix64 to User Network. Note that for the redundancy consideration each router could advertise overlapped Prefix64 with low priority in case other RS-NAT routers are failed. Note that once RS-NAT routers are failed or new RS-NAT routers are configured to join in, the routing for load balance can be automatically configured by RS-NAT routers by themselves. Prefix- Assignment Algorithm will be triggered in each RS-NAT router to re- compute the router prefix. BGP KEEPALVE and OPEN messages are used to achieve that trigger. 4.2. IPv4-IPv6 scenario The load balancing mechanism in IPv4-IPv6 interconnection scenario is similar to the one in IPv6-IPv4 in that the IPv4 address pool should shared by RS-NAT routers and each RS-NAT router is responsible to advertise the route of their IPv4 address pool, which is similar to the routing procedure of RS-NAT routers in IPv6-IPv4. The IPv4-IPv6 connection set-up is shown in Figure 3. The Control Plane ..................... +----+ +-------+ +----+ |DNS4|....|DNS ALG|......|DNS6| +----+ +---|---+ +----+ +----+. +--|---+ +------+ |User| ---------- |RS-NAT| --------|server| +----+\ +--|---+ /+------+ \ +--|---+ / --------- |RS-NAT| ------ +------+ --------------------- The Date plane Figure 3: IPv4-IPv6 connection Set-up Figure 3 illustrates the connection setup in IPv4-IPv6 scenario. The connection setup follows three steps: Chen, et al. Expires April 29, 2010 [Page 7] Internet-Draft RS-NAT April 2009 1) User sends DNS query to DNS4 and the query will be redirected to DNS6 through a DNS-ALG box. Once the DNS reply reachs the DNS-ALG box, the box will pick a IPv4 address from the IPv4 address pool and form a mapping with the IPv6 address form the answer of the DNS reply. A new DNS relpy will be generated and sent to DNS4 and User. 2) Because the packet translation will be done in the RS-NAT router, the DNS ALG box should send the mapping info to RS-NAT routers using new BGP attribute which will be defined in Section 5 3) User sends the packet to the IPv4 address got from the answer of DNS reply. The different IPv4 addresses will lead the packet to different RS-NAT routers, which is achieved by the RS-NAT routing function. Note that in step 1 the DNS-ALG box acts just as DNS-ALG functions module in NAT-PT box. The difference between the two box is that DNS-ALG box in our plan is only responsible for the control plan without packet translation. In addition DNS-ALG box should in charge of the mapping distribution among those RS-NAT routers The differences between the two scenarios include two parts: o The control plane: In IPv6-IPv4 scenario, it is the DNS64 that synchronizes the IPv6 and IPv4 address for IPv4 hosts, while in IPv4-IPv6 scenario, a DNS ALG server monitors the DNS requests and replies and forms the mapping of IPv4/IPv6 address. o Address mapping advertisement: For the load balancing reason,DNS ALG server is not designed for traffic translation and forwarding, which are in the charge of RS-NAT routers. As a result the DNS ALG server should send the mapping info to RS-NAT routers using new BGP attribute which is defined in Section 5. Chen, et al. Expires April 29, 2010 [Page 8] Internet-Draft RS-NAT April 2009 5. Redundancy Mechanisms If there exits multi-boxes between the two edge of network, problems will arise when some boxes are not stable or failed. The problems are mainly in two aspects. The first problem is in routing aspect: when one box fails, there is no other valid routes to the destination. The second is in address mapping aspect: when one box is failed, the address mapping information in the box is lost. Furthermore, it will cause the flows broke up and reconnection. The first problem is solved in Section 4 in which the routing mechanism makes sure that the taffic will find a way out through another RS-NAT router by setting the different route cost or preference. In this Section we will define a BGP attribute that one RS-NAT can advertise the local address mapping to other neighbors which guarantees the redundancy of mapping info. With that redundancy address mapping information RS-NAT routers are able to translate the new traffic 5.1. Address mapping Attribute Address mapping attribute is an optional transitive attribute that is composed of a set of TLVs. The type code of the attribute is to be assigned by IANA. Each TLV contains information corresponding to a particular mapping information. The TLV is structured as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | mapping Type (2 Octets) | Length (2 Octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Value | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ apping Type (2 octets): It identifies the type of the mapping information being transmitted. This document defines the following types: - IPv4-IPv4: mapping Type = 1 - IPv4-IPv6/IPv6-IPv4: mapping Type = 2 - IPv6-IPv6: mapping Type=3 Unknown types are to be ignored and skipped upon receipt. Chen, et al. Expires April 29, 2010 [Page 9] Internet-Draft RS-NAT April 2009 Length (2 octets): the total number of octets of the Value field. Value (variable): The value is composed of the address mapping information. If mapping type is 2, the value contains an IPv4/IPv6 address mapping just simply structured as follows: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 address (4 Octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 prot nubmer (2 Octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | IPv6 address (16 Octets) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 prot nubmer (2 Octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5.2. Performance consideration As the mapping information is tremendous and dynamic. The performance of RS-NAT is an important issue. BGP reflector can be utilized to reduce the BGP update massage. If reflector is deployed, new mechanism should guarantee each RS-NAT routers knowing the number of routers. In addition some optimization of RS-NAT and possible modifications of BGP will be explored in the next version of this document. For example the mapping information should be advertised in a certain refresh-time interval Note that RS-NAT routers are located on the edge of network and they may not connect directly. BGP has its nature advantage to do signaling among edge routers over some intra-domain protocol. Chen, et al. Expires April 29, 2010 [Page 10] Internet-Draft RS-NAT April 2009 6. Security Considerations It needs to be further identified. Chen, et al. Expires April 29, 2010 [Page 11] Internet-Draft RS-NAT April 2009 7. IANA Considerations This memo includes no request to IANA. Chen, et al. Expires April 29, 2010 [Page 12] Internet-Draft RS-NAT April 2009 8. References 8.1. Normative References [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006. [RFC2766] Tsirtsis, G. and P. Srisuresh, "Network Address Translation - Protocol Translation (NAT-PT)", RFC 2766, February 2000. [RFC3768] Hinden, R., "Virtual Router Redundancy Protocol (VRRP)", RFC 3768, April 2004. [RFC4966] Aoun, C. and E. Davies, "Reasons to Move the Network Address Translator - Protocol Translator (NAT-PT) to Historic Status", RFC 4966, July 2007. 8.2. Informative References [I-D.bagnulo-behave-nat64] Bagnulo, M., Matthews, P., and I. Beijnum, "NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers", draft-bagnulo-behave-nat64-03 (work in progress), March 2009. [I-D.miyata-behave-prefix64] Miyata, H. and M. Bagnulo, "PREFIX64 Comparison", draft-miyata-behave-prefix64-02 (work in progress), March 2009. [I-D.bagnulo-behave-dns64] Bagnulo, M., Sullivan, A., Matthews, P., Beijnum, I., and M. Endo, "DNS64: DNS extensions for Network Address Translation from IPv6 Clients to IPv4 Servers", draft-bagnulo-behave-dns64-02 (work in progress), March 2009. Chen, et al. Expires April 29, 2010 [Page 13] Internet-Draft RS-NAT April 2009 Authors' Addresses Gang Chen China Mobile 53A,Xibianmennei Ave. Beijing 100053 P.R.China Phone: +86-13910710674 Email: phdgang@gmail.com Hui Deng China Mobile 53A,Xibianmennei Ave. Beijing 100053 P.R.China Phone: +86-13910750201 Email: denghui02@gmail.com Bo Zhou China Mobile 53A,Xibianmennei Ave. Beijing 100053 P.R.China Phone: +86-13811948723 Email: zhouboyj@chinamobile.com Mingwei Xu Tsinghua University Department of Computer Science, Tsinghua University Beijing 100084 P.R.China Phone: +86-10-6278-5822 Email: xmw@csnet1.cs.tsinghua.edu.cn Chen, et al. Expires April 29, 2010 [Page 14] Internet-Draft RS-NAT April 2009 Linjian Song Tsinghua University Department of Computer Science, Tsinghua University Beijing 100084 P.R.China Phone: +86-10-6278-5822 Email: songlinjian@csnet1.cs.tsinghua.edu.cn Yong Cui Tsinghua University Department of Computer Science, Tsinghua University Beijing 100084 P.R.China Phone: +86-10-6278-5822 Email: cuiyong@tsinghua.edu.cn