Network Working Group Y. Cui Internet-Draft M. Xu Intended status: Standards Track S. Wang Expires: April 29, 2010 J. Wu X. Li Tsinghua University C. Metz Cisco Systems, Inc. October 26, 2009 IPv4/IPv6 Coexistence Framework (PET) draft-cui-softwire-pet-01 Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. 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. 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 Cui, et al. Expires April 29, 2010 [Page 1] Internet-Draft PET for IPv4/IPv6 Coexistence October 2009 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. Cui, et al. Expires April 29, 2010 [Page 2] Internet-Draft PET for IPv4/IPv6 Coexistence October 2009 Abstract IPv4 and IPv6 are expected to coexist for a long period. Currently, there are many IPv4/IPv6 transition/coexistence technologies, which can be generally divided into two categories: translation and tunneling. Both translation and tunneling have limitations and application scopes. In some typical transition scenarios, tunneling and translation are needed at the same time. In addition, there may be multiple network devices capable of doing translation or tunneling along the end-to-end path. It's important to choose particular device(devices) for doing translation or tunneling. This draft presents an IPv4-IPv6 transition/coexistence framework named PET (short for Prefixing, Encapsulation and Translation). PET is a network side solution which includes fundamental elements needed in various transition scenarios. In PET framework, signaling is required for transition devices to exchange necessary information and negotiate how to do combine transition and tunneling cooperatively. This draft also addresses how to deploy PETs and analyze the advantages and disadvantages of typical transition technologies that PET may adopt. Cui, et al. Expires April 29, 2010 [Page 3] Internet-Draft PET for IPv4/IPv6 Coexistence October 2009 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7 3. Fundamental elements for IPv4-IPv6 coexistance . . . . . . . . 8 4. PET Framework . . . . . . . . . . . . . . . . . . . . . . . . 9 4.1. PET operations on E-IP->I-IP->E-IP . . . . . . . . . . . . 10 4.2. PET operations on E-IP->I-IP->I-IP . . . . . . . . . . . . 11 4.3. PET operations on E-IP->E-IP->I-IP . . . . . . . . . . . . 12 5. PET signaling . . . . . . . . . . . . . . . . . . . . . . . . 14 6. Implementation issues . . . . . . . . . . . . . . . . . . . . 15 6.1. DNS consideration . . . . . . . . . . . . . . . . . . . . 15 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 8.1. Normative References . . . . . . . . . . . . . . . . . . . 17 8.2. Informative References . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 Cui, et al. Expires April 29, 2010 [Page 4] Internet-Draft PET for IPv4/IPv6 Coexistence October 2009 1. Introduction Recently more and more IPv6 networks have been deployed, especially IPv6 backbone networks. Howerver the existing IPv4 networks still carry the major network traffic and hold the major network services and applications. It has been a common sense that IPv4 and IPv6 networks will coexist for a long term. This leads to the need of IPv4-IPv6 coexistance technologies. There are many methods proposed for IPv4-IPv6 coexistance, which can be roughly classified into two categories: translation and tunneling. Translation is a technology that translates the semantic between IPv4 and IPv6. Examples of translation methods include SIIT [RFC 2765], NAT-PT [RFC 2766], BIS [RFC 2767], SOCKS64 [RFC 3089], BIA [RFC 3338], IVI [draft-ietf-xli-behave-ivi-02] and so on. Translation technology can realize IPv4 and IPv6 interworking directly; however, along with information loss, translation has performance issues. The address mapping in translation mechanism requires either NAT to maintain per-mapping state, or IPv6 and IPv4 address space that may be translated to be 1:1 in size. This becomes a problem when the network sizes on the side of NAT become large, which is the reason Behave WG restrict the scenario with the condition that at least one side of the NAT for IPv4-IPv6 translation has to be "a network with a clearly identifiable administrative domain" rather than Internet. Besides, from the perspective of application layer, per-application ALG is required for NAT-traversing. however, it is hard to implement ALG in hardware because of the variety of application protocol. Tunneling is the technology that encapsulates packets of a different protocol within the protocol of the network that delivers it, so as to realize forwarding across Incompatible network. Examples of tunneling methods include IP-in-IP tunnel [RFC 2893, RFC 4213], GRE tunnel [RFC 1702], 6to4 tunnel [RFC 2893], 6over4 tunnel [RFC 2529], softwire transition technology [RFC 5655] and so on. Tunneling technology can not realize the IPv4 and IPv6 interworking; it can only deal with the scenario where two IPv4 (IPv6) nodes/networks want to communicate with each other through IPv6 (IPv4) network. However, tunneling technology has several advantages. Besides high transparency, it can easily be implemented by hardware, and only routing across the transit network is possibly required rather than introducing routing information into the network of different address family. As described above, both translation and tunneling have limitations and application scopes. It's probable that both tunneling and translation are required in some scenario. In addition, when there're multiple device capable of doing translation along the network path, it's necessary to choose which device(devices) to do Cui, et al. Expires April 29, 2010 [Page 5] Internet-Draft PET for IPv4/IPv6 Coexistence October 2009 translation and thus which devices to do tunneling. Therefore, we need to decide proper method for various transition scenarios and how translation and tunneling collaborate to solve transition problems. This draft presents PET framework for IPv4-IPv6 transition and coexistence. It includes fundamental elements needed in various transition scenarios and can work differently on demand. PET requires signaling process to negotiate how to do the transition along the end-to-end path and distribute necessary information to execute transition technologies. This procedure is essential for compatibility of different technologies and diversity of scenarios. In addition, this draft also addresses how to deploy PETs and analyze the advantages and disadvantages of all transition methods that PET may adopt. Cui, et al. Expires April 29, 2010 [Page 6] Internet-Draft PET for IPv4/IPv6 Coexistence October 2009 2. Terminology 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 29, 2010 [Page 7] Internet-Draft PET for IPv4/IPv6 Coexistence October 2009 3. Fundamental elements for IPv4-IPv6 coexistance There are mainly two basic IPv4-IPv6 transition scenarios. One is to connect several edge networks of the same address family across a transit network of another address family, while the other scenario is to enable hosts/network of one address family to directly communicate with hosts/network of the other address family. We call the first scenario as heterogeneous crossing and the second as heterogeneous direct-connection. Most IPv4-IPv6 transition scenarios can be viewed as the combination of heterogeneous crossing and direct-connection. Generally, heterogeneous crossing can be achieved by tunneling or double translation, while heterogeneous direct- connection can be achieved by translation. In order to support either tunneling or translation, control plane operations always need prefix mappings or prefix announcement. So there are three fundamental elements needed in IPv4-IPv6 coexistance: prefixing, encapsulation and translation. P: prefixing, which includes all transition operations on control plane related to subnet prefix. For tunneling technology, prefixing includes prefix announcement, tunnel endpoint discovery, tunnel signaling and configuration, et al. For example, in Softwire technology, MP-BGP (Multi-protocol BGP) is extended to advertise the routing information of E-IP prefix with I-IP next-hop, and the parameters of tunnel endpoint before data plane forwarding. Based on this prefixing operation, the auto softwire tunnels can be established. For translation technology, prefixing includes address mappings of IPv4/IPv6, prefix configuration and announcement. E: encapsulation, which includes all tunneling operations on data plane, such as encapsulation, decapsulation, maximum transmission unit (MTU) processing and so on. Based on this operation, packets from E-IP network are encapsulated and sent across I-IP transit network to another E-IP network according to the prefix advertisement on control plane. T: translation, which includes all translation operations of data plane, such as address mapping and protocol translation, MTU processing. Based on address mapping, packets can be translated from one address family to another. Protocol translation is needed since IPv4 and IPv6 are not directly compatible. Here, protocol translation includes IP layer translation and application layer translation. To implement translation, PET may need to collaborate with the domain name system (DNS), since applications use domain name rather than IP address to visit other hosts a lot. Cui, et al. Expires April 29, 2010 [Page 8] Internet-Draft PET for IPv4/IPv6 Coexistence October 2009 4. PET Framework Based on the above three fundamental elements of IPv4/IPv6 coexistance, PET is a generic solution for IPv4/IPv6 transition for the scenarios of both heterogeneous crossing and direct-connection. Figure 1 shows the PET framwork. We use E-IP and I-IP instead of the exact IPv4 and IPv6. Here I-IP is either IPv4 or IPv6, while E-IP is the other address family. In this framework, the middle I-IP transit network is connected with various types of networks including E-IP transit/client networks, I-IP transit/client networks and dual stack networks. +------------------+ | E-IP (transit) | | Network | +------------------+ | | | | +-----+ +-----+ +---| PET |-----| PET |---+ | +-----+ +-----+ | +-------+ | | +---------+ | | +-----+ I-IP transit +-----+ | I-IP | | E-IP |---| PET | Network | PET |---|(transit)| |network| +-----+ +-----+ | network | +-------+ | | +---------+ | +-----+ +-----+ | +---| PET |-----| PET |---+ +-----+ +-----+ | \ / | | X | | / \ | +-------+ +-------+ | | | E-IP/ | | I-IP | | I-IP | |Network| |Network| +-------+ +-------+ Figure 1 PET Framework The basic idea of PET framework is to deploy PET boxes between middle I-IP transit networks and customer networks (E-IP or I-IP). PET box should support the above basic functions for IPv4/IPv6 coexistance, i.e. prefixing, encapsulation and translation. PET signaling is also an essential part of the framework since multiple PET boxes need to cooperate with each other. Through signaling, PET boxes can distibute necessary information and negotiate the particular functionalities executed on different boxes. PET signaling will be Cui, et al. Expires April 29, 2010 [Page 9] Internet-Draft PET for IPv4/IPv6 Coexistence October 2009 analyzed in the next section. We can extract three typical scenarios from Figure 1, including "E-IP->I-IP->E-IP", "E-IP->I-IP->I-IP" and "E-IP->E-IP->I-IP" (without the loss in genarality, we assume that host in the first network initiate the connection). For different scenarios, PET can provide different functionalities to ensure the inter-working of E-IP/I-IP network. We will analyze how PET works in the three scenarios in the following subsections. 4.1. PET operations on E-IP->I-IP->E-IP This is the scenario where an E-IP network wants to talk with another E-IP network across I-IP transit. There are two methods PET can adopt to handle this scenario. One is translation and the other is tunneling. If PET uses translation method, it'll need twice translations. An E-IP packet need to be translated by the first PET which is I-IP ingress, into an I-IP packet for being delivered through I-IP transit. When this packet arrives at the second PET which is I-IP egress, it will be translated back into an E-IP packet for being delivered in destination E-IP network. The other method for E-IP-I-IP-E-IP scenario is tunneling. This requires a PET to encapsulate the packets and send them to the other tunnel endpoint PET across I-IP transit. When these packets arrive at the second PET, they are decapsulated and sent to E-IP customer network. Because translation method will bring heavier load because of address mapping and protocal translation, PET prefers to use tunneling technology to handle E-IP-I-IP-E-IP scenario. Its operations are shown in Figure 2. +-------------+ +-------------+ +-------------+ +-------------+ |E-IP customer| | PET | | PET | |E-IP customer| | network | | | | | | network | +-------------+ +-------------+ +-------------+ +-------------+ | | | | |---forwarding--->| | | | encapsulation | | | | | | | |-------tunneling--->| | | | | | | | decapsulation | | | |------forwarding->| | | | | Figure 2 PET operations in E-IP->I-IP->E-IP scenario Cui, et al. Expires April 29, 2010 [Page 10] Internet-Draft PET for IPv4/IPv6 Coexistence October 2009 4.2. PET operations on E-IP->I-IP->I-IP This is the scenario where an E-IP customer network wants to talk with an I-IP customer network across I-IP transit. There are two methods to deal with this scenario. One is translation plus forwarding (Figure 3). The other is tunneling plus translation (Figure 4). In the first method, when an E-IP packet arrives at the first PET(IPv4-IPv6 edge), it will be translated into an I-IP packet and then sent to the I-IP client network through I-IP transit. In the second method, when an E-IP packet arrives at the first PET, it will be encapsulated as an I-IP packet for being delivered through I-IP transit. Once this packet arrives at the other tunnel endpoint PET, it will be decapsulated to the original E-IP packet and then be translated into an I-IP packet to deliver to the I-IP customer network. Both method works in theory, though the second method seems more complicated; however the key factor here is that translation brings heavy load, so the two related PET box need a singaling process to negotiate which one of them to do the translation, i.e. which method to use. In principle, it's better that translation is done by the PET whose performance is better and the sizes of the networks on the side of which is smaller. We'll discuss PET signaling in the next section. +-------------+ +-------------+ +-------------+ +-------------+ |E-IP customer| | PET | | PET | |I-IP customer| | network | | | | | | network | +-------------+ +-------------+ +-------------+ +-------------+ | | | | |---forwarding--->| | | | translation | | | | | | | |-----forwarding---->| | | | | | | | | | | | | | | | |----forwarding--->| | | | | Figure 3 PET operations (A) in E-IP->I-IP->I-IP scenario (Translation + Forwarding) Cui, et al. Expires April 29, 2010 [Page 11] Internet-Draft PET for IPv4/IPv6 Coexistence October 2009 +-------------+ +-------------+ +-------------+ +-------------+ |E-IP customer| | PET | | PET | |I-IP customer| | network | | | | | | network | +-------------+ +-------------+ +-------------+ +-------------+ | | | | |---forwarding--->| | | | | | | | encapsulation | | | |------tunneling---->| | | | | | | | decapsulation | | | translation | | | |----forwarding--->| | | | | Figure 4 PET operations (B) in E-IP->I-IP->I-IP scenario (Tunneling + Translation) 4.3. PET operations on E-IP->E-IP->I-IP This is the scenario where an E-IP customer network wants to talk with an I-IP customer network across E-IP transit. There are two methods to deal with this scenario. One is forwarding plus translation. The other is translation plus tunneling. In the first method, when an E-IP packet arrives at the first PET, it will be directly delivered to E-IP transit. At the edge of E-IP-I-IP, i.e. the second PET, the packet will be translated into an I-IP packet for delivering in I-IP customer network. In the second meothod, when an E-IP packet arrives at the first PET, it will be translated into an I-IP packet, and then PET encapsulates it and sends it to the second PET. When the E-IP packet encapsulating the translated I-IP packet arrives at the second PET, the I-IP packet will be decapsulated and sent to the I-IP customer network. Here both methods works,too. We also require PET signaling to negotiate which PET to do translation. Cui, et al. Expires April 29, 2010 [Page 12] Internet-Draft PET for IPv4/IPv6 Coexistence October 2009 +-------------+ +-------------+ +-------------+ +-------------+ |E-IP customer| | PET | | PET | |I-IP customer| | network | | | | | | network | +-------------+ +-------------+ +-------------+ +-------------+ | | | | |---forwarding--->| | | | | | | | | | | | |------forwarding--->| | | | | | | | translation | | | | | | | |--forwarding----->| | | | | Figure 5 PET operations (A) in E-IP->E-IP->I-IP scenario (Forwarding + Translation) +-------------+ +-------------+ +-------------+ +-------------+ |E-IP customer| | PET | | PET | |I-IP customer| | network | | | | | | network | +-------------+ +-------------+ +-------------+ +-------------+ | | | | |---forwarding--->| | | | translation | | | encapsulation | | | |------tunneling---->| | | | | | | | | | | | decapsulation | | | |--forwarding----->| | | | | Figure 6 PET operations (B) in E-IP->E-IP->I-IP scenario (Tunneling + Translation) Cui, et al. Expires April 29, 2010 [Page 13] Internet-Draft PET for IPv4/IPv6 Coexistence October 2009 5. PET signaling We can see from section 4 that translation is inevitably adopted in a lot typical scenarios while it's clear that translation technology has performance and scalability issues. So it's important that translation is done on a proper PETwhen necessary. The principle here is that PET box whose performance is better and the sizes of the networks on the side of which is smaller, is preferred to do translation. Here we propose a new concept called Translation Preference (TP) to express the PET's willing of performing translation according to some policies the network administrators constitute. Through exchanging the Translation preference among PETs, PET framework can choose which PET to do translation and decide the communication mode for corresponding scenarios. TP can be decided by the performance of PET box, the size of networks which PET is connected to, and the administrators' policy. We define the value of TP as the preference degree that the PET would like to translate a packet; the higher the TP value is, the higher probability the PET translates packets. Besides TP, there is another type of information that PETs would wants to exchange when translation is used, we call it PET prefix. PET prefix represents the prefix of network the PET box charges. Based on that other PETs can differentiate an IPv6 mapped address from a regular IPv6 address, thus learn about the source or desitination of a packet. For example, in a IPv6-IPv6-IPv4 scenario, PET can announce a /96 prefix in signaling to express that all the IPv6 address within the prefix is a mapped IPv6 address for a IPv4 host; if the address mapping is done through add/remove IPv6 prefix, then PET learns how to do address mapping based on this information. PET may need to exchange more infomation or do other negotiations in the future, we can use the signaling process to achieve it as long as it's necessary. We won't define how to do PET signaling for TP and PET prefix exactly and how the message formats should be in this draft, but we believe that this signaling process should be done by softwire signaling process through a slight extension of MP-BGP. Cui, et al. Expires April 29, 2010 [Page 14] Internet-Draft PET for IPv4/IPv6 Coexistence October 2009 6. Implementation issues In this draft, we recommend how to use tunneling and translation method in each scenario using PET. However, we do not restrict the specific tunneling and translation technology that PET adopts. It can be any transition technology, such as SIIT [RFC 2765], NAT-PT [RFC2766], BIS [RFC 2767], SOCKS64 [RFC 3089], BIA [RFC 3338], IVI[draft-ietf-xli-behave-ivi-02], IP-in-IP tunnel [RFC 2893, RFC 4213],GRE tunnel [RFC 1702], 6to4 tunnel [RFC 2893], 6over4 tunnel [RFC2529], softwire transition technology [RFC 5565] and so on. 6.1. DNS consideration It's a concern how to make PET collaborate with DNS system. In the translation schemes proposed lately, DNS is usually considered because hosts use domain names rather than IP address directly to visit other hosts a lot. Generally the DNS query strategy of these schemes can be divided into two types. The first method is to build a DNS ALG on the NAT and make all the DNS query and reply go through the NAT; the second method is to use DNS64 as a extended DNS server which collaborate with NAT to do the DNS translating. PET which may use these translation mechanisms introduces a slight change in that the PET box doing the translation may be not the PET box that is in the IPv4-IPv6 edge, so it's a little complicated. PET boxes may need to remember the DNS server address behind the other PET boxes. However, the influence of PET using these translation schemes on DNS varies among different schemes, so we won't discuss it one by one in this framework. Cui, et al. Expires April 29, 2010 [Page 15] Internet-Draft PET for IPv4/IPv6 Coexistence October 2009 7. Acknowledgements The authors would like to thank Lixia Zhang and Eric Nordmark for their valuable comments on this draft. Cui, et al. Expires April 29, 2010 [Page 16] Internet-Draft PET for IPv4/IPv6 Coexistence October 2009 8. References 8.1. Normative References [RFC1702] Hanks, S., Li, T., Farinacci, D., and P. Traina, "Generic Routing Encapsulation over IPv4 networks", RFC 1702, October 1994. [RFC2529] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4 Domains without Explicit Tunnels", RFC 2529, March 1999. [RFC2765] Nordmark, E., "Stateless IP/ICMP Translation Algorithm (SIIT)", RFC 2765, February 2000. [RFC2766] Tsirtsis, G. and P. Srisuresh, "Network Address Translation - Protocol Translation (NAT-PT)", RFC 2766, February 2000. [RFC2767] Tsuchiya, K., HIGUCHI, H., and Y. Atarashi, "Dual Stack Hosts using the "Bump-In-the-Stack" Technique (BIS)", RFC 2767, February 2000. [RFC2893] Gilligan, R. and E. Nordmark, "Transition Mechanisms for IPv6 Hosts and Routers", RFC 2893, August 2000. [RFC3089] Kitamura, H., "A SOCKS-based IPv6/IPv4 Gateway Mechanism", RFC 3089, April 2001. [RFC3338] Lee, S., Shin, M-K., Kim, Y-J., Nordmark, E., and A. Durand, "Dual Stack Hosts Using "Bump-in-the-API" (BIA)", RFC 3338, October 2002. [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for IPv6 Hosts and Routers", RFC 4213, October 2005. [RFC5565] Wu, J., Cui, Y., Metz, C., and E. Rosen, "Softwire Mesh Framework", RFC 5565, June 2009. 8.2. Informative References [I-D.xli-behave-ivi] Li, X., Bao, C., Chen, M., Zhang, H., and J. Wu, "The CERNET IVI Translation Design and Deployment for the IPv4/ IPv6 Coexistence and Transition", draft-xli-behave-ivi-02 (work in progress), June 2009. Cui, et al. Expires April 29, 2010 [Page 17] Internet-Draft PET for IPv4/IPv6 Coexistence October 2009 Authors' Addresses Yong Cui Tsinghua University Department of Computer Science, Tsinghua University Beijing 100084 P.R.China Phone: +86-10-6278-5822 Email: cy@csnet1.cs.tsinghua.edu.cn 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 Shengling Wang Tsinghua University Department of Computer Science, Tsinghua University Beijing 100084 P.R.China Phone: +86-10-6278-5822 Email: slwang@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 Cui, et al. Expires April 29, 2010 [Page 18] Internet-Draft PET for IPv4/IPv6 Coexistence October 2009 Xing Li Tsinghua University Department of Electronic Engineering, Tsinghua University Beijing 100084 P.R.China Phone: +86-10-6278-5983 Email: xing@cernet.edu.cn Chris Metz Cisco Systems, Inc. 3700 Cisco Way San Jose, Ca. 95134 USA Email: chmetz@cisco.com Cui, et al. Expires April 29, 2010 [Page 19]