Network Working Group Y. Cui Internet-Draft M. Xu Intended status: Standards Track P. Wu Expires: September 10, 2010 S. Wang J. Wu X. Li Tsinghua University C. Metz Cisco Systems, Inc. March 9, 2010 IPv4/IPv6 Coexistence Framework (PET) draft-cui-softwire-pet-02 Abstract IPv4 and IPv6 are expected to coexist for a long period. Currently, there are many IPv4/IPv6 transition/coexistence techniques, which can be roughly divided into two categories: tunneling and translation. Both tunneling and translation have restricted application scopes, and translation has some technical limitations. To maximize the benifits and reduce the costs, we may need to use both tunneling and translation in some scenarios. Besides, there may be multiple network devices capable of performing translation/tunneling along the end-to-end path. It's important to choose the appropriate device(devices) to execute translation/tunneling. This draft brings up the method of choosing the appropriate translation spot to avoid the limitations of translation. Furthermore, this draft presents an IPv4-IPv6 transition/coexistence framework named PET (short for Prefixing, Encapsulation and Translation). PET integrates tunneling and translation to support both traversing and IPv4-IPv6 interconnection, and uses tunneling and translation properly to constitute communication modes in different scenarios. When executing translation, PET achieves translation spot negotiation through signaling process between PET devices. PET framework covers most network transition scenarios. It is a generic solution framework for IPv4-IPv6 coexistence. 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- Cui, et al. Expires September 10, 2010 [Page 1] Internet-Draft PET for IPv4/IPv6 Coexistence March 2010 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 September 10, 2010. 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 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 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 September 10, 2010 [Page 2] Internet-Draft PET for IPv4/IPv6 Coexistence March 2010 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Fundamental elements for IPv4-IPv6 coexistence . . . . . . . . 7 4. PET Framework . . . . . . . . . . . . . . . . . . . . . . . . 8 4.1. PET operations on E-IP->I-IP->E-IP . . . . . . . . . . . . 9 4.2. PET operations on E-IP->I-IP->I-IP . . . . . . . . . . . . 10 4.3. PET operations on E-IP->E-IP->I-IP . . . . . . . . . . . . 11 5. PET signaling . . . . . . . . . . . . . . . . . . . . . . . . 13 5.1. signaling content . . . . . . . . . . . . . . . . . . . . 13 5.2. PET signaling extension in MP-BGP . . . . . . . . . . . . 14 5.3. BGP protocol behavior with PET signaling . . . . . . . . . 15 6. Implementation issues . . . . . . . . . . . . . . . . . . . . 16 6.1. DNS consideration . . . . . . . . . . . . . . . . . . . . 16 7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 17 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 9.1. Normative References . . . . . . . . . . . . . . . . . . . 19 9.2. Informative References . . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 Cui, et al. Expires September 10, 2010 [Page 3] Internet-Draft PET for IPv4/IPv6 Coexistence March 2010 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 widely believed that IPv4 and IPv6 networks will coexist for a long term. This leads to the demand for IPv4-IPv6 coexistence technology. Till now there are two types of IPv4-IPv6 coexistence techniques: tunneling and translation. Tunneling can achieve traversing across incompatible network, by means of encapsulation and decapsulation. In the scope of IPv4-IPv6 coexistence, tunneling can deal with the scenario where two IPv4 (IPv6) nodes/networks communicate with each other across IPv6 (IPv4) network. Examples of tunneling methods include IP-in-IP tunnel [RFC2893][RFC4213], GRE tunnel [RFC1702], 6to4 tunnel [RFC3056], 6over4 tunnel [RFC2529], softwire transition technique [RFC5565] and so on. Tunneling can not achieve IPv4-IPv6 interworking. However, tunneling has several advantages: it's highly transparent and lightweighted, it can be implemented fully by hardware, and it can keep IPv4 routing and IPv6 routing separated. On the other hand, translation is used to achieve direct inter- communication between IPv4 and IPv6 networks, by means of converting the semantic between IPv4 and IPv6. Examples of translation methods include SIIT [RFC2765], NAT-PT [RFC2766], BIS [RFC2767], SOCKS64 [RFC3089], BIA [RFC3338], IVI [I-D.xli-behave-ivi] and so on. Translation can achieve IPv4-IPv6 interworking, but it has limitations in operation complexity and scalability. To accomplish correct translation, the following operations are required: address or (address,port) tuple substitution, MTU discovery, fragmentation when necessary, IP and ICMP fields translation, ICMP address substitution in payload, IP/TCP/UDP checksum recomputing and application layer translation when necessary. It's rather complex for a per-packet process, especially when per-application application layer translation is included. When applying stateful translation, the dynamic mapping of (address, port) tuple should be maintained on the translation device. The total number of mapping entries is up to the order of flow number. As to stateless translation, it has to consume IPv4 addresses to satisfy IPv6 hosts. This is also not scalable since IPv6 address space is much larger than IPv4 address. Basic opeartions of stateless translation can be implemented by hardware, but ALG has to be implemented by software due to the variety of application protocols. Stateful translation can not be implemented by hardware. As described above, translation and tunneling have their respective limitations and/or application scopes. To maximize the benifits and Cui, et al. Expires September 10, 2010 [Page 4] Internet-Draft PET for IPv4/IPv6 Coexistence March 2010 reduce the costs, we may need to use both tunneling and translation in some scenarios. Besides, there may be multiple network devices capable of performing translation/tunneling along the end-to-end path. It's important to choose the appropriate device(devices) to execute translation/tunneling, and thus decide the proper methods to solve transition problems for various transition scenarios. This draft presents PET framework for IPv4-IPv6 transition and coexistence. PET includes fundamental elements needed in various transition scenarios to support both traversing and IPv4-IPv6 interconnection, and uses them properly to constitue communication modes in different scenarios. PET uses a signaling process to negotiate the appropriate translation spot in order to avoid the limitations of translation, and to distribute necessary information to execute transition mechanisms. Cui, et al. Expires September 10, 2010 [Page 5] Internet-Draft PET for IPv4/IPv6 Coexistence March 2010 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 September 10, 2010 [Page 6] Internet-Draft PET for IPv4/IPv6 Coexistence March 2010 3. Fundamental elements for IPv4-IPv6 coexistence 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 the other address family, while the other scenario is to enable host/network of one address family to communicate directly with host/network of the other address family. We call the first scenario heterogeneous crossing and the second one heterogeneous direct-connection. Most IPv4-IPv6 transition scenarios can be viewed as combination of heterogeneous crossing and direct- connection. Generally, heterogeneous crossing can be achieved by tunneling or two-time translation, while heterogeneous direct- connection can be achieved by translation. Besides, to support either tunneling or translation, control plane operations like prefix mapping or prefix announcement are always required. So there are three fundamental elements needed in IPv4-IPv6 coexistence: prefixing, encapsulation and translation. P: prefixing, which includes all the 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 prefixing operations, softwire tunnels can be established. For translation technology, prefixing includes IPv4-IPv6 address mapping method, prefix configuration and announcement. E: encapsulation, which includes all the tunneling operations on data plane, such as encapsulation, decapsulation, maximum transmission unit (MTU) processing and so on. Based on these operations, packets from E-IP network are encapsulated and forwarded across I-IP transit network to another E-IP network. To support correct forwarding, prefix advertisement on control plane is required. T: translation, which includes all the translation operations on data plane, such as address translation, protocol translation, MTU processing, et al. Based on address translation, addresses in IP packets can be translated from IPv4 to IPv6, or vice versa. Protocol translation is necessary since IPv4 and IPv6 are not directly compatible. Here, protocol translation includes IP layer translation and application layer translation. Devices executing translation may need to collaborate with the domain name system (DNS), since applications in end hosts use domain name rather than IP address to visit other hosts a lot. Cui, et al. Expires September 10, 2010 [Page 7] Internet-Draft PET for IPv4/IPv6 Coexistence March 2010 4. PET Framework PET is a generic solution for IPv4/IPv6 coexistence based on the three fundamental elements above, supporting both heterogeneous crossing and direct-connection. Figure 1 shows the topology of PET framwork. We use E-IP and I-IP instead of the exact IPv4 and IPv6. Here I-IP can be either IPv4 or IPv6, while E-IP is the other address family. In this framework, the I-IP transit network in the center is connected with various types of customer 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 | | / \ | +-------+ +-------+ | | | Dual- | | I-IP | | stack | |Network| |Network| +-------+ +-------+ Figure 1 PET Framework The basic idea of PET framework is to deploy PET boxes between the central I-IP transit network and customer networks (E-IP or I-IP). PET boxes should support the basic functions for IPv4/IPv6 coexistence, i.e., prefixing, encapsulation and translation. PET signaling is also an essential part of the framework for multiple PET boxes to cooperate with each other. Through signaling, PET boxes can negotiate the particular functions executed on different boxes and distibute necessary information to support these functions. PET Cui, et al. Expires September 10, 2010 [Page 8] Internet-Draft PET for IPv4/IPv6 Coexistence March 2010 signaling will be analyzed in the next section. We can extract three typical scenarios from Figure 1: "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). These three cases cover most network transition scenarios. PET can provide different functions for different scenarios to ensure network communcation. We will analyze how PET works in the three typical scenarios in the following subsections. 4.1. PET operations on E-IP->I-IP->E-IP This is the scenario where a E-IP network wants to communicate with another E-IP network across the I-IP transit. There are two methods PET can adopt to handle this scenario. One is two-time translation and the other is tunneling. If PET uses two-time translation, a E-IP packet need to be translated into an I-IP packet by the first PET(i.e., the I-IP ingress), get delivered through the I-IP transit, and be translated back into a E-IP packet at the second PET(i.e., the I-IP egress). The other method for E-IP->I-IP->E-IP scenario is tunneling. This requires the I-IP ingress PET to encapsulate the packets and send them to the I-IP egress 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 has limitations and brings heavier load, PET prefers to use tunneling to handle E-IP->I-IP->E-IP scenario. The 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 September 10, 2010 [Page 9] Internet-Draft PET for IPv4/IPv6 Coexistence March 2010 4.2. PET operations on E-IP->I-IP->I-IP This is the scenario where a E-IP customer network wants to communicate with an I-IP customer network across the 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 a E-IP packet arrives at the first PET(edge of E-IP and I-IP), it will be translated into an I-IP packet and then sent through the I-IP transit to the I-IP client network. In the second method, when a E-IP packet arrives at the first PET, it will be encapsulated as an I-IP packet, so as to get delivered through the I-IP transit. Once this packet arrives at the second PET(the other tunnel endpoint), it will be decapsulated to the original E-IP packet, then get translated into an I-IP packet and delivered to the I-IP customer network. In theory both methods work, and the second method seems more complicated. However we should notice that translation brings heavy load and has scalability issue, while tunneling is lightweighted. So an extra tunnel is actually acceptable. Hence the two related PET box need a singaling process to negotiate which method to use, in order to avoid the limitations of translation and maximize the benefits. In principle, it's better that translation is done by the PET box whose performance is better, and the network size behind 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 September 10, 2010 [Page 10] Internet-Draft PET for IPv4/IPv6 Coexistence March 2010 +-------------+ +-------------+ +-------------+ +-------------+ |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 a E-IP customer network wants to communicate with an I-IP customer network across the 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 a E-IP packet arrives at the first PET, it will be directly delivered to E-IP transit. At the second PET(edge of E-IP and I-IP), the packet will be translated into an I-IP packet and forwarded to the I-IP customer network. In the second meothod, when a E-IP packet arrives at the first PET, it will be translated into an I-IP packet. Then PET encapsulates it and sends it to the second PET. When the E-IP packet with the translated I-IP packet as its payload arrives at the second PET, the I-IP packet will get decapsulated and sent to the I-IP customer network. Here both methods works,too. We also require PET signaling to negotiate which method to adopt. Cui, et al. Expires September 10, 2010 [Page 11] Internet-Draft PET for IPv4/IPv6 Coexistence March 2010 +-------------+ +-------------+ +-------------+ +-------------+ |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 (Translation + Tunneling) Cui, et al. Expires September 10, 2010 [Page 12] Internet-Draft PET for IPv4/IPv6 Coexistence March 2010 5. PET signaling 5.1. signaling content We can see from section 4 that we have to adopt translation in some scenarios while it's clear that translation has performance and scalability issues. So it's important to ensure that when we have to perform translation, perform it on an approperate PET box. The criterion here is, the PET box whose performance is better, and the PET box the size of network behind which is smaller, is preferred to do translation. For example, PET box in edge network is preferred to perform translation than PET box in backbone. Here we propose a new concept called Translation Preference (TP) to express the appropriateness of a PET box to perform translation. By exchanging the Translation preference among PETs, PET framework can choose the appropriate PET box to perform translation and decide the appropriate communication modes for corresponding scenarios. TP can be decided by the performance of PET box, the size of networks behind PET box, and the administrators' policy. Factors like bandwidth and traffic volume of the PET box can infer the network size behind it, and factors like traffic load and the hardware configuration can tell the performance of the PET box. We require separated TPs for stateless and stateful translation because they have different foundations(stateless translation requires IPv6 host to posess IPv4 address). In a mixed scenario, some PET box can't perform stateless translation like others because IPv6 hosts in its network doesn't have IPv4 addresses. So we separate the TP signaling of stateless and stateful translation. Besides TP, there is another type of information that PETs wants to exchange. It's the necessary knowledge to execute translation. For stateless translation it's the mapping prefix, and for stateful translation it's the address pool PET can use for address mapping. For example, in an IPv6->PET1->IPv6->PET2->IPv4 scenario, if we use stateless translation, then PET2 need to tell PET1 the prefix for IPv4-IPv6 address mapping when PET1 performs the translation; if we use stateful translation, then PET2 need to tell PET1 the IPv4 addresses PET1 can use for address mapping when PET1 performs the translation. There may be some more information PETs need to exchange which we've not considered yet, we can use the signaling process to achieve it as long as it's necessary. The signaling process can be done through MP-BGP with some extensions. Cui, et al. Expires September 10, 2010 [Page 13] Internet-Draft PET for IPv4/IPv6 Coexistence March 2010 5.2. PET signaling extension in MP-BGP TP exchange can be achieved by BGP capability advertisement in BGP OPEN stage. We define a new capability called PET Capability to carry TP value. The Capability Code field is TBD(which indicates PET signaling capabilities). The Capability Length field is set to 2. The Capability Value field is defined as: 0 7 15 +------------+------------+ |Stateless TP|Stateful TP | +------------+------------+ The use and meaning of this field is as follow: Stateless TP - Translation Preference value for stateless translation negotiation. The higher the TP value is, the higher probability this PET performs translation. Stateful TP - Translation Preference value for stateful translation negotiation. The higher the TP value is, the higher probability this PET performs translation. There are two ways to carry the mapping prefix and the address pool information in BGP UPDATE message. The first one is using NLRI and two new SAFIs, and the second one is using a new BGP attribute. In the first way, we define two new SAFIs, "Stateless Translation SAFI" and "Stateful Translation SAFI" to represent the situation of stateless translation and stateful translation in PET. The MP_REACH_NLRI Attribute with these SAFIs carries the PET information instead of routing prefixes. With Stateless Translation SAFI, the NLRI should be an IPv6 prefix used for IPv4-IPv6 tranlation mapping; with Stateful Translation SAFI, the NLRI should be an IPv4 address pool for the receiving PET to use. Both the prefix and the address pool should following the NLRI Encoding format in [RFC4760]. The value of Stateless Translation SAFI and Stateful Translation SAFI is TBD by IANA. In the second way, we define a new BGP Attribute, "Translation Information Attribute" to carry the mapping prefix and the address pool. It's an optional transitive attribute and the attribute type code is TBD by IANA. The value field of this attribute is composed of a set of Type-Length-Value (TLV) encodings.The TLV is structured as follows: Cui, et al. Expires September 10, 2010 [Page 14] Internet-Draft PET for IPv4/IPv6 Coexistence March 2010 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type (2 Octets) | Length (2 Octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Value | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ We define two TLVs here, one is SLT_TLV(type code 1) and the other is SFT_TLV(type code 2). The Length field stands for the total number of octets in the Value field. The content of the Value field is the IPv6 mapping prefix for SLT_TLV, and IPv4 address pool for SFT_TLV, both in NLRI Encoding format. The Translation Information Attribute should carry at least one TLV in its value field. We may define more TLVs in the future, if it's necessary. 5.3. BGP protocol behavior with PET signaling The extensions for PET signaling above is based on BGP, so we require the PET boxes to run BGP process. In BGP Open stage, they advertise their TPs in PET Capability to one another. Having received TP from its peers, every PET box independently decides which one to perform translation based on these TP values. If the chosen translation PET box is on IPv4-IPv6 edge, then it'll perform translation like normal translation mechnisms. Else the chosen translation PET box isn't on IPv4-IPv6 edge, so the one on IPv4-IPv6 edge should advertise either the IPv6 mapping prefix or the IPv4 address pool to the one performing translation, using one of the two methods above. Besides, a tunnel will be introduced in this case. If this tunnel is using mechinisms like softwire mesh, then the corresponding BGP routing process should be triggered. The edge PET box will advertise the E-IP prefixes to the translation PET box, and the translation PET box will advertise the mapping address pool(stateful translation case)/E-IP address prefix of the network behind it(stateless translation case) to the edge PET box. Cui, et al. Expires September 10, 2010 [Page 15] Internet-Draft PET for IPv4/IPv6 Coexistence March 2010 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 network transition technology, such as SIIT [RFC2765], NAT-PT [RFC2766], IVI [I-D.xli-behave-ivi], IP-in-IP tunnel [RFC2893][RFC4213], GRE tunnel [RFC1702], 6to4 tunnel [RFC3056], softwire transition technique [RFC5565] and so on. Softwire is recommended as tunnel technique since it's automatic, network side and scalable. 6.1. DNS consideration It's a concern how to make PET collaborate with DNS system. In the translation schemes already proposed, DNS is usually considered. Generally speaking the DNS query strategy of these schemes can be divided into two types. The first method is to build a DNS ALG on the translation device and make all the DNS queries and replies go through the device; the second method is to use DNS64 as an extended DNS server which collaborates with the translation device to do the DNS translation. The principle of DNS translation in PET is that, the DNS translation process is binded to the PET box performing the translation rather than other PET boxes along the path. The DNS server should cooperate with the PET box and learn information like mapping perfix from it sometimes. Cui, et al. Expires September 10, 2010 [Page 16] Internet-Draft PET for IPv4/IPv6 Coexistence March 2010 7. IANA considerations IANA is requested to assign a value from the "BGP Capability Code" Registry, to be called "PET Capability", with this document as the reference. IANA is requested to assign two values from the "Subsequent Address Family" Registry, in the "Standards Action" range, to be called "Stateless Translation SAFI" and "Stateful Translation SAFI", with this document as the reference. IANA is requested to assign a value from the "BGP Path Attributes" Registry, to be called "Translation Information Attribute", with this document as the reference. Here the assignment of the two new SAFI value and the new BGP Attribute code can be an either-or choice. Cui, et al. Expires September 10, 2010 [Page 17] Internet-Draft PET for IPv4/IPv6 Coexistence March 2010 8. Acknowledgements The authors would like to thank Lixia Zhang, Eric Nordmark, Jari Arkko, Alain Durand and David Ward for their valuable comments on this draft. Cui, et al. Expires September 10, 2010 [Page 18] Internet-Draft PET for IPv4/IPv6 Coexistence March 2010 9. References 9.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. [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4 Clouds", RFC 3056, February 2001. [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. [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760, January 2007. [RFC5565] Wu, J., Cui, Y., Metz, C., and E. Rosen, "Softwire Mesh Framework", RFC 5565, June 2009. Cui, et al. Expires September 10, 2010 [Page 19] Internet-Draft PET for IPv4/IPv6 Coexistence March 2010 9.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-07 (work in progress), January 2010. Cui, et al. Expires September 10, 2010 [Page 20] Internet-Draft PET for IPv4/IPv6 Coexistence March 2010 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 Peng Wu Tsinghua University Department of Computer Science, Tsinghua University Beijing 100084 P.R.China Phone: +86-10-6278-5822 Email: weapon@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 Cui, et al. Expires September 10, 2010 [Page 21] Internet-Draft PET for IPv4/IPv6 Coexistence March 2010 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 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 September 10, 2010 [Page 22]