Network Working Group Y. Cui Internet-Draft M. Xu Intended status: Standards Track S. Wang Expires: April 4, 2010 X. Li J. Wu Tsinghua University C. Metz Cisco systems Oct. 2009 PET for IPv6 to IPv4 communication draft-cui-softwire-pet64-00.txt 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 February 28, 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. Cui, et al. Expires April 4, 2010 [Page 1] Internet-Draft pet64 Oct. 2009 Abstract This draft offers a solution using PET for the scenario that an IPv6- only client initiates a communication to an IPv4-only server through IPv6 backbone. In this communication scenario,translation is needed. However, translation work has requirements on the performance (hardware or software) of PET and the size of network that the PET is charge for. This draft introduces the concept of translation preference 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 decide which PET should act as a translator. In addition, this draft also gives how the PET collaborates with DNS to solve the IPv6-to-IPv4 communication problem. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. PET Framework in IPv6-toIPv4 communication scenario . . . . . 4 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. IPv6-to-IPv4 communication in PET framework . . . . . . . . . 7 4.1. IPv6-to-IPv4 communication scenario . . . . . . . . . . . 7 4.2. IPv6-to-IPv4 communication using PETs . . . . . . . . . . 8 4.3. PET and DNS collaboration for IPv6-to-IPv4 communication . . . . . . . . . . . . . . . . . . . . . . 9 4.3.1. PET1 Translation scenario . . . . . . . . . . . . . . 10 4.3.2. PET2 Translation scenario . . . . . . . . . . . . . . 11 4.4. Other considerations . . . . . . . . . . . . . . . . . . . 12 5. Filtering . . . . . . . . . . . . . . . . . . . . . . . . . . 13 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 6.1. Normative References . . . . . . . . . . . . . . . . . . . 14 6.2. Informative References . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 Cui, et al. Expires April 4, 2010 [Page 2] Internet-Draft pet64 Oct. 2009 1. Introduction IPv6 offers significant advantages over IPv4, however it will take a long time to replace IPv4 with IPv6. Therefore, these two protocols are expected to coexist during the transition period. On one hand, because it is difficult to update IPv4 applications, a lot of IPv6-only client will want to visit IPv4-only servers to enjoy the IPv4 applications. On the other hand, to promote the transition from IPv4 and to propel IPv6 development, some countries are establishing large-scale pure IPv6 backbone networks. So it is a key problem that an IPv6 client dwelled in an IPv6 network can efficiently communicate with an IPv4 server dwelled in an IPv4 network through IPv6 backbone. This draft proposes a solution that using PET framework [I-D.draft-cui-softwire-PET-framework-00]to solve the problem that an IPv6-only client initiates a communication to an IPv4-only server through IPv6 backbone (we call this communication scenario is IPv6- to-IPv4 in the following draft). In IPv6-to-IPv4 communication scenario, translation is inevitably adopted. Hence, which PET should act as a translator is a key problem to be considered. The reason is described as follows: Translation mechanism usually needs application level gateway (ALG), which is an application specific agent that allows an IPv6 host to communicate with an IPv4 host and vice versa. However, it is hard to use hardware to do the work of ALG. Thus, translation has requirements on the performance (including hardware performance and software performance) of PET and the network size the PET charges for. Usually, if a PET's performance is higher and the network's size which the PET charges for is smaller, the PET is supposed to perform translation, and vice versa. In this draft, we firstly give the PET framework in IPv6-to-IPv4 communication scenario, based on which this draft discusses two communication modes in 6to4 scenario(different PET perform translation in different modes). This draft introduces the concept of translation preference 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 decide the communication mode. In addition, this draft also gives how the PET collaborates with DNS to solve the IPv6-to-IPv4 communication problem. At last, this draft describes the filtering of PET. Cui, et al. Expires April 4, 2010 [Page 3] Internet-Draft pet64 Oct. 2009 2. PET Framework in IPv6-toIPv4 communication scenario Figure 1 shows the PET framework in IPv6-to-IPv4 scenario, which uses PET boxes between IPv6 backbone and its client networks. The client networks include IPv4 network, IPv4 virtual private networks (VPNs), IPv6 network and dual stack networks. In this draft, we only consider the scenario that one PET is charge of one client network. The scenario that Multiple PETs charge for one client network is out of consideration. +------------------+ | | | IPv6 network | | | +------------------+ | +-----------+ | PET | | | +-----------+ | +-----------------------------+ | | +--------+ +--------+ +--------+ +-------+ | IPv6 | | | IPv6 backbone | | | IPv4 | |network |___| PET | | PET |__|network| | | | | | | | | | | +--------+ +--------+ | | +--------+ | | +-------+ +-----------------------------+ | +-----------+ | PET | | | +-----------+ | +------------------+ | | | IPv4 network | | | +------------------+ Figure 1: PET Framework in IPv6-to-IPv4 scenario Cui, et al. Expires April 4, 2010 [Page 4] Internet-Draft pet64 Oct. 2009 3. Terminology This section provides the definitions for all the terms used in draft. 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 RFC 2119 [RFC2119]. The following terms are used in this document: PET: a smart transition toolbox supporting IPv4/IPv6 inter-working. PET toolbox has the following functions: P: representing prefixing. Prefixing includes all transition operations of control plane involved with subnet prefix. E: representing encapsulation. E includes all tunneling operations of data plane, such as encapsulation, decapsulation and maximum transmission unit (MTU) processing and so on. T: representing translation. It includes all translation operations of data plane, such as address mapping and protocol translation, MTU processing. A PET connects the IPv6 backbone to its client networks. It is a dual stack gateway. PETs can exchange their prefixes and Translation Preferences through softwire signaling [RFC 5565].When collaborating with DNSs, a PET charging for an IPv4 network MUST keep one-to-one mapping between the DNS's IPv4 address and its IPv6 mapping address. Translation Preference (TP): is a value set in a PET to show the preference degree that the PET would like to translate a packet. The higher is the TP, the higher probability that the PET translates packets. PET prefix: a prefix of a network which a PET is charge for. Through PET prefix, an IPv6 PET address is constructed. PET prefixes should be announced by PETs through softwire signaling [RFC 5565], based on that other PETs can differentiate an IPv6 PET address and a regular IPv6 address and judge where a packet comes from or is destined to. IPv6 PET address: an IPv6 address constructed by concatenating the /96 prefix of the PET that is charging for the IPv4 network and the IPv4 address assigned to the IPv4 server. IPv6 mapping address: the IPv6 address representing the IPv4 target. In IPv6-to-IPv4 scenario, an IPv4 target's IPv6 mapping address is Cui, et al. Expires April 4, 2010 [Page 5] Internet-Draft pet64 Oct. 2009 its IPv6 PET address. IPv4 mapping address: the IPv4 address representing the IPv6 target. DNS4: a DNS deployed in IPv4 network. It has an IPv6 mapping address. DNS4 SHOULD support for DNSSEC and some forms of IPsec. A DNS4 SHOULD keep the DNS6's IPv4 mapping addresses. This information MAY be set by static configuration. DNS6: a DNS deployed in an IPv6 network (including IPv6 backbone and IPv6 client networks). DNS6 SHOULD support for DNSSEC and some forms of IPsec.It has an IPv4 mapping address. A DNS4 SHOULD keep the DNS6's IPv4 mapping addresses. This information MAY be set by static configuration. Cui, et al. Expires April 4, 2010 [Page 6] Internet-Draft pet64 Oct. 2009 4. IPv6-to-IPv4 communication in PET framework 4.1. IPv6-to-IPv4 communication scenario Figure 2 shows one kind of IPv6-to-IPv4 communication scenario. A PET connects the IPv6 backbone to its client network, along with the deployment of a DNS6 in the IPv6 client network and a DNS4 in the IPv4 client network. +---------------+ +---------------+ +---------------+ | IPv6 network | +-----+ | | +-----+ |IPv4 network | | +------+ |_| PET1|_| IPv6 core |_| PET2|_| +------+ | | | DNS6 | +-----+ | network | +-----+ | | DNS4 | | | +------+ | | | | +------+ | +---------------+ +---------------+ +---------------+ Figure 2: IPv6-to-IPv4 communication scenario (DNS6 deployed in client network Figure 3 shows the other kind of IPv6-to-IPv4 communication scenario. A PET connects the IPv6 backbone to its client network, along with the deployment of a DNS6 in the IPv6 backbones and a DNS4 in the IPv4 client network. Of course, there can be multiple DNSs in the client networks though we only discuss the scenario that one DNS deployed in one client network. +---------------+ +---------------+ +---------------+ | IPv6 network | | IPv6 core | | IPv4 network | | | +-----+ | network | +------+ | | | |_| PET1|_| +------+ |_| PET2 |_| +------+ | | | +-----+ | | DNS6 | | +------+ | | DNS4 | | | | | +------+ | | +------+ | +---------------+ +---------------+ +---------------+ Figure 3: IPv6-to-IPv4 communication scenario (DNS6 deployed in core network) PET has two interfaces, an IPv4 (IPv6) interface connects to the IPv4 (IPv6) client network, and an IPv6 interface connects to the IPv6 backbone. Cui, et al. Expires April 4, 2010 [Page 7] Internet-Draft pet64 Oct. 2009 Each PET should know the existence each other, and they communicate the following information through softwire signaling: i) PET prefix. Through PET prefix announcement, PETs can differentiate an IPv6 PET address and a regular IPv6 address, and judge where the packet comes from or is destined to. ii)TP. Through TP announcement, which PET performs translation is decided. When collaborating with DNS, a PET charging for an IPv4 network MUST keep one-to-one mapping between the DNS's IPv4 address and its IPv6 mapping address. 4.2. IPv6-to-IPv4 communication using PETs When an IPv6 initiator wants to communicate with an IPv4 host, translation is inevitably adopted. Hence, which PET should act as a translator is a key problem to be considered. The reason is described as follows: Translation mechanism usually needs ALG, which is an application specific agent that allows an IPv6 host to communicate with an IPv4 host and vice versa. However, it is hard to use hardware to do the work of ALG. Thus, translation has requirements on the performance (including hardware performance and software performance) of PET and the network size the PET charges for. Usually, if a PET's performance is higher and the network's size which the PET charges for is smaller, the PET is supposed to perform translation, and vice versa. According to the requirements that performing translation on different PETs, there are two modes of IPv6-to-IPv4 communication using PETs as shown in Figures 4 and 5 respectively. In the first mode, when an IPv6 packet arrives at PET 1, it will be translated into an IPv4 packet and then sent to PET2 using softwire mechanism (i.e. 4 over 6 method) [RFC 5565] through IPv6 backbone. At last, this IPv4 packet will be forwarded directly to the IPv4 host in IPv4 client network. Cui, et al. Expires April 4, 2010 [Page 8] Internet-Draft pet64 Oct. 2009 +-------------+ +-----+ +--------+ +-----+ +-------------+ |IPv6 client | | PET1| | IPv6 | |PET2 | |IPv4 client | | network | | | |backbone| | | | network | +-------------+ +-----+ +--------+ +-----+ +-------------+ | | | | |-forwarding->| | | | translation | | | encap. | | | |-----tunneling--->| | | | | | | | decap. | | | |------forwarding->| | | | | Figure 4: PET1 translation in IPv6-to-IPv4 communication In the second method, when an IPv6 packet arrives at PET 1, it will be directly delivered through IPv6 backbone. Once this packet arrives at PET2, it will be translated in to an IPv4 and then destined to the target. +-------------+ +-----+ +--------+ +-----+ +-------------+ |IPv6 client | | PET1| | IPv6 | |PET2 | |IPv4 client | | network | | | |backbone| | | | network | +-------------+ +-----+ +--------+ +-----+ +-------------+ | | | | |-forwarding->| | | | |----forwarding--->| | | | translation | | | |-----forwarding-->| Figure 5: PET2 translation in IPv6-to-IPv4 communication 4.3. PET and DNS collaboration for IPv6-to-IPv4 communication IF an IPv6 initiator does not know the IPv6 mapping address of the IPv4 target, DNS may be need. In this case, PETs should collaborate with DNSs for IPv6-to-IPv4 communication. The following subsections introduce how PETs collaborate with DNSs in each communication mode. Cui, et al. Expires April 4, 2010 [Page 9] Internet-Draft pet64 Oct. 2009 4.3.1. PET1 Translation scenario +---------+ +------+ +-----+ +-----+ +------+ +----------+ |v6network| | DNS6 | | PET1| |PET2 | | DNS4 | |v4network | | host A | | | | | | | | | | host B | +---------+ +------+ +-----+ +-----+ +------+ +----------+ |dstv6 addr?>| | | | | | |---dstv6 addr?---> | | | | | | |dstv6,v4addr?>| | | | | |<-IPv4 addr B-| | | | | prefixPET2::v4B=C | | | |<---IPv6 addr C----| | | | save C | | | | || | | | | | translate | | | | |src:PET1v4/srcport:x| | | | | dst:B | | | | | map:A,y,x | | | | | encap. | | | | | |tunneling | | | | | | decap. | | | | | |-----------IPv4 pkt------->| Figure 6: PET operations ( translation+forwarding) In this scenario, if an IPv6 host (i.e. host A) does not know the IPv6 mapping address of IPv4 target, it will launch a name look up request for host B, the lookup query is directed to the DNS server on the V6 network. In case of DNS6 having no information about the IPv6 mapping address of IPv4 target, DNS6 forwards the name look up request to DNS4 (the DNS6 has the IPv6 mapping address of DNS4 beforehand maybe through static configuration). This name look up request will be intercepted by PET2. Since host B may have IPv6 and/or IPv4 addresses, PET2 forwards the original AAAA/A6 query to DNS4 unchanged, as well as an A query for the same host. If an AAAA/A6 record exists for the destination, this will be returned to PET2 which will forward it, also unchanged, to the originating host. If there is an A record for host B, the reply also returns to the PET 2, which translates the reply, adds the Prefix of itself (PET prefix) to construct the IPv6 PET address (prefixPET2:: v4B=C) and finally forwards it (IPv6 addr C) to DNS6. Now host A can use this address like any other IPv6 address and the DNS6 server can even cache it as long as the PET Prefix does not Cui, et al. Expires April 4, 2010 [Page 10] Internet-Draft pet64 Oct. 2009 change. After getting the IPv6 mapping address, the host A sends a packet to host B with source port 'y'. When PET 1 receives this packet, it performs translation and select an unused port 'x' to create the mapping entry (IPv6 address of host A, source port y and source port x). After that, PET 1 sends the packet to PET 2 through softwire mechanism (4over6 tunneling). When PET 2 receive this packet, it will directly deliver the packet to Host B. In the opposite direction, when a packet sent by host B arrives at PET 2, PET2 uses the softwire mechanism to send this packet to PET1. Because having the mapping information, PET 1 performs translation and then sends this packet to host A. The TTL values on all DNS resource records (RRs) passing through PET SHOULD be set to 0 so that DNS servers/clients do not cache temporarily assigned RRs. Note, however, that due to some buggy DNS client implementations a value of 1 might in some cases work better. The TTL values should be left unchanged for statically mapped. 4.3.2. PET2 Translation scenario +---------+ +------+ +-----+ +-----+ +------+ +---------+ |v6network| | DNS6 | | PET1| |PET2 | | DNS4 | |v4network| | host A | | | | | | | | | | host B | +---------+ +------+ +-----+ +-----+ +------+ +---------+ |dstv6 addr?->| | | | | | |---dstv6 addr?--->| | | | | | |dstv6,v4addr?>| | | | | |<-IPv4 addr B-| | | | | prefixPET2::v4B=C | | | |<--IPv6 addr C----| | | | save C | | | | |<-IPv6 addr C| | | | | |--IPv6 pkt/srcport:y ->| | | | | | | IPv6pkt/srcport:y | | | | | translate | | | | | src:PET1v4/srcport:x | | | | | dst:B | | | | | map:A,y,x | | | | | |-------------IPv4 pkt---->| Figure 7:PET operations in IPv6-IPv6-IPv4 scenario(forwarding +translation) In this case, PET 2 performs translation, to that end, PET 2 selects an unused port 'x' to create the mapping entry (IPv6 address of host A, source port y and source port x). Such binding state is created Cui, et al. Expires April 4, 2010 [Page 11] Internet-Draft pet64 Oct. 2009 when the first packet flowing from the IPv6 network to the IPv4 network is translated. After the binding state has been created, packets flowing in either direction on that particular flow are translated. The other progress is same as that in subsection 4.3.1. 4.4. Other considerations Address mappings for incoming sessions, as described above, are subject to denial of service attacks since one can make multiple queries for nodes residing in the V6 network causing the PETs to map and thus block legitimate incoming sessions. Thus, address mappings for incoming sessions should time out to minimize the effect of denial of service attacks. In fact, an IPv6 host can learn the address of IPv4 target from the DNS4 or from the DNS6. In this draft, we learn the idea from NAT64 [draft-ietf-behave-v6v4-xlate-stateful-01] that DNS6 servers maintain a mapping of names to IPv6 addresses for internal nodes and possibly cache mappings for some external nodes. In the case where the DNS6 contains the mapping for external IPv4 hosts, the DNS queries will not cross the IPv6 domain and that would obviate the need for PET intervention. Otherwise, the queries will cross the IPv6 domain and are subject to PET intervention. We also learn the idea from NAT64 [draft-ietf-behave-v6v4-xlate-stateful-01] that DNS4 servers cache name mapping for external nodes (i.e., V4 nodes) only. For basic functionality, the approach only requires the deployment of PETs connecting the IPv6 backbone to its client networks, along with the deployment of a DNS6 in the IPv6 client network and a DNS4 in the IPv4 client network. However, some advanced features such as support for DNSSEC validating stub resolvers or support for some IPsec modes, require software updates to the IPv6-only hosts. We recommend the time to failure of DNS is no longer than that of mapping in PETs to guarantee the available of IPv6 mapping address (i.e. PET address) of IPv4 target. It is important to note that the translation still works if the IPv6 initiator learns the IPv6 mapping address of IPv4 address (i.e. Pref64::X) through some schemes other than a DNS look-up. This is because the DNS processing does NOT result in any state installed in the PET box and because the IPv6 mapping address is constructed by concatenating the PET prefix to the original IPv4 address. Cui, et al. Expires April 4, 2010 [Page 12] Internet-Draft pet64 Oct. 2009 5. Filtering Similar to the NAT64 [draft-ietf-behave-v6v4-xlate-stateful-01], a PET box may do filtering, which means it only allows some kinds of packets through the interface according to the appropriate policies. Similar to the NAT64 [draft-ietf-behave-v6v4-xlate-stateful-01], a PET may do no filtering, or it may filter on its IPv4 interface. Filtering on the IPv6 interface is not supported because mappings are only created by packets traveling in the IPv6 --> IPv4 direction. Similar to the NAT64 [draft-ietf-behave-v6v4-xlate-stateful-01],PET filtering is consistent with the recommendations of RFC 4787 [RFC4787], and the ones of RFC 5382 [RFC5382]. Cui, et al. Expires April 4, 2010 [Page 13] Internet-Draft pet64 Oct. 2009 6. References 6.1. Normative References [RFC4787] Audet, F. and C. Jennings, "Network Address Translation (NAT) Behavioral Requirements for Unicast UDP", BCP 127, RFC 4787, January 2007. [RFC5382] Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P. Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, RFC 5382, October 2008. [RFC5565] Wu, J., Cui, Y., Metz, C., and E. Rosen, "Softwire Mesh Framework", RFC 5565, June 2009. 6.2. Informative References [I-D. draft-cui-softwire-PET-framework-00.txt] Y.Cui,M.Xu,S.Wang, X.Li,J. Wu, C. Metz, "PET-based framework for IPv4/IPv6 coexistence", July 2, 2009. [I-D. draft-ietf-behave-v6v4-xlate-stateful-01.txt] M.Bagnulo, P. Matthews,I. van Beijnum. "NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers", July 11, 2009. Cui, et al. Expires April 4, 2010 [Page 14] Internet-Draft pet64 Oct. 2009 Authors' Addresses Yong Cui Tsinghua University Department of Computer Science, Tsinghua University Beijing 100084 P.R.China Phone: +86-10-6278-5983 Email: cuiyong@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 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 Cui, et al. Expires April 4, 2010 [Page 15] Internet-Draft pet64 Oct. 2009 Jianping Wu Tsinghua University Department of Electronic Engineering, Tsinghua University Beijing 100084 P.R.China Phone: +86-10-6278-5983 Email: jianping@cernet.edu.cn Chris Metz Cisco systems 170 West Tasman Drive San Jose 95134-1706 CA Email: chmetz@cisco.com Cui, et al. Expires April 4, 2010 [Page 16]