Network Working Group G. Chen Internet-Draft H. Deng Intended status: Experimental B. Zhou Expires: January 7, 2010 China Mobile M. Xu L. Song Y. Cui Tsinghua University July 6, 2009 Reliable and Scalable NAT mechanism (RS-NAT) based on BGP for IPv4/6 Transition draft-chen-behave-rsnat-00 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 January 7, 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 January 7, 2010 [Page 1] Internet-Draft RS-NAT July 2009 Abstract For the rapid exhaustion of IPv4 address pool against the slow development of IPv6, IPv4/6 coexistence/transition proved to be a long period. In the IPv4/6 transition process, there are many NAT- like technologies existing in the internet. However the NAT boxes such as IPv4 NAT, IPv4/6 NAT are so poor in their reliability and scalability, which put a severe threat on the development of IPv4/6 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. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 9.1. Normative References . . . . . . . . . . . . . . . . . . . 14 9.2. Informative References . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 Chen, et al. Expires January 7, 2010 [Page 2] Internet-Draft RS-NAT July 2009 1. Introduction For the rapid exhaustion of IPv4 address pool against the slow development of IPv6, IPv4/6 coexistence/transition proved to be a long period. In the IPv4/6 transition process there are obviously two trends: one is the supporter of IPv6, who proposed many transition mechanisms such as NAT-PT , NAT64. The other is reluctant to use IPv6 because of the high cost of upgrade they network and some applications and want to use NAT444, DS-Lite to delay the exhaustion of IPv4. No matter which side will win the future, the NAT-like function is a key point in the coexistence/transition period. However much 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 exert high threat on reliability and scalability when the network becomes huge. For example the box will be single point of failure in the large scaled Network. Although some advices are proposed such as mentioned in 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 mechanism to overcome the stateful NAT problem mentioned above, which include IPv4 NAT and IPv4/6 NAT. Note that the stateless NAT mechanism IVI[I-D.baker-behave-ivi], and its limitation is out the scope of this document. Chen, et al. Expires January 7, 2010 [Page 3] Internet-Draft RS-NAT July 2009 2. RS-NAT Overview In the topology shown in figure 1, there are two main parts of network: the User Network and Service Network. User Network is the realm where the users initiate the communication with servers. The Service Network is the realm where the public service server located. In addition there are some RS-NAT boxes which act as bridges between the 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 can be IPv4,IPv6 or Dual-stacks. As a result there are several communication scenarios learned from the general topology using the general form IPvx-IPvy, which means users with IPvx protocol initiate connections to servers with IPvy protocol. These communication scenarios are (private)IPv4-IPv4, IPv4-IPv6, IPv6-IPv4, and IPv6-IPv6. VRRP[RFC3768] is perfect 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 scenarios. The User Network and Service Network are logical concepts, which may be composed of many small networks in one AS or several Ases. For example the User Network shown in Figure 1 may consist of several IPv4 metropolitan area networks in one network provider.The Service Network may be composed of IPv6 islands connected directly, through tunnels or IPv6 transit-core such as CNGI-CERNET2 in China. The metropolitan area networks in User Network may connect to Service Network individually through RS-NAT boxes which may be located at different cities. Obviously these sub-networks is multi-homed at least with two access links. Although the problem of multi-homing is beyond the scope of this document, it is worth explaining the detail of the topology. Note that the definition of User Network and Service Network are defined according to one communication. They are not strict because an end user can regarded as both initiator and server from different views. Chen, et al. Expires January 7, 2010 [Page 4] Internet-Draft RS-NAT July 2009 3. RS-NAT Box The following sections will discuss the requirement of RS-NAT Box and its basic functions. In order to achieve the role of bridge between the two networks in the scenarios, which are depicted in sections 3, the RS-NAT box should have three basic functions: the support of IPv4/6 dual-stack, router and IPv4/6 address translator. In the IPv6-IPv4 scenario RS-NAT router advertise the prefix64 [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 dispatch the prefix64 for each DNS request, which will be discussed in section 5. In the IPv4-IPv6 scenario RS-NAT router advertise its own IPv6 prefix routing information to Service Network, and send the prefix info of static IPv4 address pool to User Network. In this scenario DNS ALG mentioned in NAT-PT will be modified to support the separation of the data plane and control plane, which will be discussed in section 5. As an IP protocol translator the mapping mechanism in RS-NAT is also an important part. The address mapping information 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 January 7, 2010 [Page 5] Internet-Draft RS-NAT July 2009 4. Load Balancing Mechanisms Sections 3 and 4 have already depicted the framework of RS-NAT and the key role: RS-NAT box. 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 IPv6-IPv4 scenario. The connection setup follows two steps: 1) User sends DNS query to DNS64 and get the DNS reply with a IPv4- embeded IPv6 addresses in the form of Prefix64::IPv4 adress; 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 pool just as DNS64 does and they will use a Prefix- Assignment Algorithm to decide individually which part of prefix64 they are in charge of. The Prefix-Assignment Algorism follows the simple idea that all RS-NAT routers share the prefix almost evenly based on the BGP neighbor information. For example there is 2^8 2001::/24 in prefix64 pool 2001::/16 and there are 2 RS-NAT routers which are sorted according to the size of IP address. The Assignment plan is that prefixes form 2001:0000::/24 to 2001:7f00::/24 will be assigned to the router with larger IP address, and the prefixes from 2001:8000::/24 to 2001:ff00::/24 is in Chen, et al. Expires January 7, 2010 [Page 6] Internet-Draft RS-NAT July 2009 the charge of the other router. If there are more RS-NAT routers, these prefixes can also easy assigned to them. In order to balance the traffic among these RS-NAT routers, each router should advertise the route of its converged prefix64 to User Network. Note that for the Redundancy consideration each router can advertise the routes of other part of prefix64 with higher cost or larger granularity in order that when other RS-NAT routers fail for some reason, the alive can work immediately. 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 recompute the router prefix. BGP KEEPALVE and OPEN messages are used to achieve that trigger which will be explored in the next version of this document . 4.2. IPv4-IPv6 scenario The load balancing mechanism in IPv4-IPv6 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 Setup 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 Setup The differences between the two scenarios are in two fold: Chen, et al. Expires January 7, 2010 [Page 7] Internet-Draft RS-NAT July 2009 o The control plane: In IPv6-IPv4 it is the DNS64 that synchronize the IPv6 and IPv4 address for IPv4 hosts, while in IPv4-IPv6 a DNS ALG server monitors the DNS request and reply forming the mapping of IPv4/6 address. o Address mapping advertisement: For the load balancing reason,DNS ALG server is not designed for traffic translation and forwarding, which part is separated to RS-NAT routers. As a result the DNS ALG server should send the mapping info to RS-NAT routers using new BGP attribute which will be defined in section 6. Note that if the scenario is the mixture of the two, RS-NAT can work well with proper address configuration. Chen, et al. Expires January 7, 2010 [Page 8] Internet-Draft RS-NAT July 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 fails, the address mapping information in the box is lost causing the flows breaking up and reconnection. The first problem is solved in section 4 in that 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 tunnel technology. 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 January 7, 2010 [Page 9] Internet-Draft RS-NAT July 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/6 address mapping just simply structured as follows: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 address (4 Octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | IPv6 address (16 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. 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 January 7, 2010 [Page 10] Internet-Draft RS-NAT July 2009 6. Security Considerations TBD Chen, et al. Expires January 7, 2010 [Page 11] Internet-Draft RS-NAT July 2009 7. IANA Considerations TBD Chen, et al. Expires January 7, 2010 [Page 12] Internet-Draft RS-NAT July 2009 8. Acknowledgments TBD Chen, et al. Expires January 7, 2010 [Page 13] Internet-Draft RS-NAT July 2009 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. [RFC2694] Srisuresh, P., Tsirtsis, G., Akkiraju, P., and A. Heffernan, "DNS extensions to Network Address Translators (DNS_ALG)", RFC 2694, September 1999. [RFC2766] Tsirtsis, G. and P. Srisuresh, "Network Address Translation - Protocol Translation (NAT-PT)", RFC 2766, February 2000. [RFC2893] Gilligan, R. and E. Nordmark, "Transition Mechanisms for IPv6 Hosts and Routers", RFC 2893, August 2000. [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)", RFC 3022, January 2001. [RFC3768] Hinden, R., "Virtual Router Redundancy Protocol (VRRP)", RFC 3768, April 2004. [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006. [RFC4966] Aoun, C. and E. Davies, "Reasons to Move the Network Address Translator - Protocol Translator (NAT-PT) to Historic Status", RFC 4966, July 2007. 9.2. Informative References [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. [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.baker-behave-ivi] Chen, et al. Expires January 7, 2010 [Page 14] Internet-Draft RS-NAT July 2009 Li, X., Bao, C., Baker, F., and K. Yin, "IVI Update to SIIT and NAT-PT", draft-baker-behave-ivi-01 (work in progress), September 2008. [I-D.durand-softwire-dual-stack-lite] Durand, A., Droms, R., Haberman, B., and J. Woodyatt, "Dual-stack lite broadband deployments post IPv4 exhaustion", draft-durand-softwire-dual-stack-lite-01 (work in progress), November 2008. [I-D.miyata-behave-prefix64] Miyata, H. and M. Bagnulo, "PREFIX64 Comparison", draft-miyata-behave-prefix64-02 (work in progress), March 2009. [I-D.shirasaki-nat444-isp-shared-addr] Shirasaki, Y., Miyakawa, S., Nakagawa, A., Yamaguchi, J., and H. Ashida, "NAT444 with ISP Shared Address", draft-shirasaki-nat444-isp-shared-addr-01 (work in progress), March 2009. Chen, et al. Expires January 7, 2010 [Page 15] Internet-Draft RS-NAT July 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 January 7, 2010 [Page 16] Internet-Draft RS-NAT July 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 Chen, et al. Expires January 7, 2010 [Page 17]