BEHAVE WG D. Liu D. Liu H. Deng Internet-Draft H. Deng Intended status: Standard Track China Mobile Expires: September 8, 2010 March 7, 2010 NAT46 considerations draft-liu-behave-nat46-02 Abstract The period of IPv4/IPv6 transisation will last for a long time. Different phases of IPv4/IPv6 transisation have different scenarioes and requirements thus need different solutions. In the early stage of IPv4/IPv6 transisation, sicne the majority of the Internet resources locate in the IPv4 Internet, the main communication type of the IPv4/IPv6 transition is v6 to v4 which is the IPv6 clients iniate communication to the IPv4 servers. At the later stage of the IPv4/ IPv6 transisation, the servers may locate in the IPv6 network/ Internet, in this scenario, there is a need for the legacy IPv4 client to iniate communication to the IPv6 servers. This document analyses the problems of v4 to v6 communication and discusses a solution called PNAT-Lite. 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 September 8, 2010. Copyright Notice Liu Expires September 8, 2010 [Page 1] Internet-Draft NAT46 consideration March 2010 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions used in this document . . . . . . . . . . . . . . 5 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. 4. DNS46 consideration . . . . . . . . . . . . . . . . . . . . 7 5. 5. NAT46 GW consideration . . . . . . . . . . . . . . . . . . 9 6. 6. ALG consideration . . . . . . . . . . . . . . . . . . . . . 10 7. 7. NAT46 solution . . . . . . . . . . . . . . . . . . . . . . 11 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 11. Normative References . . . . . . . . . . . . . . . . . . . . . 16 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 17 Liu Expires September 8, 2010 [Page 2] Internet-Draft NAT46 consideration March 2010 1. Introduction +------------------------------------------------------+ | | | | | +----------------+ +---------------+ | | | IPv4 Network | |IPv6 Internet | | | | +-----------+ | +-----------+ | +-----------+ | | | | | |--|--|Translation|--|-| | | | | | |IPv4 Client| | | Box | | |IPv6 Server| | | | | +-----------+ | +-----------+ | +-----------+ | | | | | | | | | +----------------+ +---------------+ | | | | | | DNS DNS | | | | | +------------------------------------------------------+ Figure 1 NAT46: v4 to v6 communication scenario. As figure 1 illustrated, in v4 to v6 communication scenario, the IPv4 client which locates in the IPv4 network initiates communication to the IPv6 server which locates in the IPv6 Internet. To enable the v4 to v6 communication, a v4 to v6 translation entity need to be involved. As figure 1 illustrated, a translation box is introduced between the IPv4/IPv6 network which performs IPv4/IPv6 packets translation. To enable the v4 to v6 communication, it is also need to do v6 to v4 address mapping and handle the DNS query and response. As will be discussed in section 4, there are several different ways to implement it. Although there are different ways for implementation, the basic function module of v4 v6 translation should inlclude: 1) DNS handling: Used to handle DNS query and response. The IPv4 application may send type A DNS query to start the communication, but since the server is IPv6 server and may have no type A DNS record, there will be no type A DNS response returned. The DNS handling module is then used to solve this problem. It may send both type A and AAAA DNS queries on behalf of the IPv4 application and return the proper DNS response to the application. 2) Address mapping Liu Expires September 8, 2010 [Page 3] Internet-Draft NAT46 consideration March 2010 Address mapping module is used to create and maintain the IPv4 and IPv6 address mapping. Since the IPv4 application can only start communication using IPv4 address as destination IP addrss, there is a need to use an IPv4 address to represent the IPv6 server's address. This mapping normally is created dynamically on demand. The translation box need to use this mapping information for IPv4/IPv6 packet translation. 3) v4 v6 translation The translation module performs the IPv4 IPv6 packets translation. The translation module may need the mapping information to perform the translation, so the mapping information and translation module need to be synchronized. The translation may perform based on SIIT [RFC2765]. Liu Expires September 8, 2010 [Page 4] Internet-Draft NAT46 consideration March 2010 2. Conventions used in this document 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]. Liu Expires September 8, 2010 [Page 5] Internet-Draft NAT46 consideration March 2010 3. Terminology NAT46 GW: NAT46 gateway, refer to the entity that performs the IPv4/ IPv6 translation. Mapped-IPv4 address: Refers to the dynamically created IPv4 address that maps to the server's IPv6 address. This mapping information need to be synchronized with the NAT46 GW. Liu Expires September 8, 2010 [Page 6] Internet-Draft NAT46 consideration March 2010 4. DNS46 consideration The DNS handling and IPv4/IPv6 address mapping function together could be recognised as DNS46 ALG. There are different approaches to implement DNS46 ALG: in translation box, in DNS system, and in host. 1) Translation box (NAT46 GW) performs DNS46 ALG. In this approach, the IPv4 application's type A DNS query message will arrive at the NAT46 GW, the NAT46 GW translates it into IPv6 packet and change type A to AAAA. If the DNS system returns AAAA response, the NAT46 GW will translate the IPv6 DNS response packet into IPv4 and create a mapping of the AAAA record and a mapped-IPv4 address of the server then return to the IPv4 host a A record which contains the mapped-IPv4 address. The IPv4 client will use the mapped-IPv4 address as the IPv6 server's IP address to start the communication. 2) DNS46 performs DNS46 ALG. In this approach, there will be a DNS46 server in the network and performs the DNS46 ALG. The IPv4 client's type A DNS query will arrive at the DNS46 server, the DNS46 server will perform type A query, if there is no response, DNS46 will perform type AAAA query. If there is a type AAAA DNS response, DNS46 will create a mapping between the returned IPv6 address and a dynamically generated IPv4 address. Then DNS46 will return the mapped type A DNS response message to the IPv4 client. The DNS46 needs to synchronize this mapping information to the NAT46 GW. The IPv4 client will then use this mapped-IPv4 address to initiate the communication. 3) Host performs DNS46 ALG. In this approach, the DNS46 ALG function resides in the host. The IPv4 application in the IPv4 client send type A DNS query. The DNS46 ALG function in the host sends both type A and AAAA DNS query, when a type AAAA DNS response is received, the DNS46 ALG function in the host create a mapping between the IPv6 address of the server and a dynamically created mapped-IPv4 address. If the IPv4/IPv6 translation function resides in the host, the DNS46 function could synchronize the mapping information using internal implementation specific mechanism.Otherwise, an external synchronization mechanism is needed. The three different approaches have their own advantages and disadvantages: Liu Expires September 8, 2010 [Page 7] Internet-Draft NAT46 consideration March 2010 For the approach that performs DNS46 ALG in NAT46 GW, the main disadvantage is that it will add complexity to the NAT46 GW. The advantage of this approach is that there is no synchronization mechanism needed and no need to change the host and DNS system. The DNS46 approach's main advantage is that it reduces the complexity of the NAT46 GW and no change to the host. The disadvantage of this approach is that it needs to introduce new DNS entity (DNS46) and need to synchronize the IPv6-IPv4 mapping information between the NAT46 GW and DNS46. The advantage of host based DNS46 ALG approach is that it reduces the complexity of the NAT46 GW and no need to change of DNS system. The main disadvantage of this approach is that it requires changes to the host. There already have some proposals that try to solve the v4 v6 communication problem: Virtual IPv6 connection[ID-Virual IP] and soure IP NAT[ID-Source NAT]. Virtual IPv6 connection is based on the DNS system to perform DNS46 function. Specifically, in virtual IPv6 connection, the recursive DNS server requests the translation box to create the mapping information and then return the created A record to the application. Source IP NAT is also a DNS based solution. It uses flow information to identify the mapping record and thence allow each IPv4 address be used in multiple distinct communications. NAT-PT is a solution that using the translation box to performs DNS46 ALG function. But since NAT-PT's DNS46 ALG has many issues and limitations as discussed in RFC4966[RFC4966], the NAT-PT specification was abolished. Liu Expires September 8, 2010 [Page 8] Internet-Draft NAT46 consideration March 2010 5. NAT46 GW consideration NAT46 GW performs the translation function between IPv4 and IPv6. The NAT46 GW gets the mapping information of the server's IPv6 address and mapped-IPv4 address by DNS46 ALG function which either resides in NAT46 GW, DNS46 or in the host. The IPv4 packets with the mapped-IPv4 address as its destination address will be routed to the NAT46 GW. The NAT46 GW will first query its mapping table to see whether there is a mapping entry of this IPv4 address exist. When a mapping entry is found, the NAT46 GW will translate the IPv4 destination address to its corresponding IPv6 destination address. The IPv4 source address could be translated by adding a NAT46 GW prefix. Liu Expires September 8, 2010 [Page 9] Internet-Draft NAT46 consideration March 2010 6. ALG consideration When there is an IP address embedded in the payload, it will require the NAT46 GW to perform translation of the embedded IP address. NAT46 GW should support the most crucial legacy application's ALG. It would not require the NAT46 GW to support all the ALGs due to the scalability and complexity restriction. Liu Expires September 8, 2010 [Page 10] Internet-Draft NAT46 consideration March 2010 7. NAT46 solution This section discusses a NAT46 solution which implement Extened Name Resolver(ENR) and address mapping function in the translation box. There is no external synchronization mechanism needed since the address mapping and translation function resides in the same box.(as illustrated by figure 2) +----------------------------------------------------------------+ | | | | | +----------------+ +---------------+ | | | IPv4 Network | Translation box |IPv6 Internet | | | | +-----------+ | +--------------------+ |+------------+ | | | | | |--|--|+---+ +------------+| || | | | | | | | ||ENR| |Addr Mapping||--||IPv6 Server | | | | | |IPv4 Client| | |+---+ +------------+| || | | | | | +-----------+ | +--------------------+ |+------------+ | | | | | | | | | +----------------+ +---------------+ | | | | | | DNS DNS | | | | | +----------------------------------------------------------------+ Figure 2 ENR based NAT46 solution The ENR module works as follows: 1)The IPv4 application send type A DNS query. The IPv4 client may be configured to use the Translation box as its DNS server. 2)The type A DNS query is routed to the ENR module of the translation box, the ENR module will then send both type A and AAAA queries to the DNS system using its IPv4 interface. 3)The DNS system may return an A or an AAAA or both A and AAAA record according to the server's IP version. 4)The ENR module decide what DNS response message it will send to the IPv4 client based on network connection type towards the IPv6 Internet and the returned DNS message. Table 1 illustrated the detail operation of ENR: Liu Expires September 8, 2010 [Page 11] Internet-Draft NAT46 consideration March 2010 +---------+------+--------+-----------+---------+ | S. App. | Net. | Peer | ENR resp. | Fun. Map| | Query | Type | Type | to App. | /Trans. | +---------+------+--------+-----------+---------+ | A | * | A | A | no need | | A | * | A/AAAA | A | no need | | A | v6 | AAAA | Mapping A | v4-v6 | | A | v4v6 | AAAA | Mapping A | v4-v6 | +---------+------+--------+-----------+---------+ Table 1: ENR function based on network type As table 1 illustrated, ENR function could perform intelligent DNS handling based on the current connection type. Here Net.Type is the translation box's network connection type towards the IPv6 Internet. In the case that v6 to v4 mapping is needed, ENR module requests the address mapping module to create a mapped-IPv4 address for the server's IPv6 address. The ENR module will then return an A record which contains the mapped-IPv4 address. The IPv4 client will use this mapped-IPv4 address as the destination address of the server to start communication. Liu Expires September 8, 2010 [Page 12] Internet-Draft NAT46 consideration March 2010 8. Security Considerations TBD Liu Expires September 8, 2010 [Page 13] Internet-Draft NAT46 consideration March 2010 9. IANA Considerations None Liu Expires September 8, 2010 [Page 14] Internet-Draft NAT46 consideration March 2010 10. Contributors Zhen Cao China Mobile caozhen@chinamobile.com Bo Zhou China Mobile zhouboyj@chinamobile.com Liu Expires September 8, 2010 [Page 15] Internet-Draft NAT46 consideration March 2010 11.References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [ID-Virual IP] Christian Vogt,"Virtual IPv6 Connectivity for IPv4-Only Networks", 2009 [ID-Source NAT] C. Perkins, "Translating IPv4 to IPv6 based on source IPv4 address", 2009 [RFC2765] Nordmark,E., "Stateless IP/ICMP Translation Algorithm (SIIT)", RFC 2765, February 2000. [RFC4966] C.Aoun, "Reasons to Move the Network Address Translator - Protocol Translator(NAT-PT) to Historic Status", 2007 Liu Expires September 8, 2010 [Page 16] Internet-Draft NAT46 consideration March 2010 Author's Address Dapeng Liu China Mobile Unit2, 28 Xuanwumenxi Ave,Xuanwu District Beijing 100053 China Email: liudapeng@chinamobile.com Hui Deng China Mobile Unit2, 28 Xuanwumenxi Ave,Xuanwu District Beijing 100053 China Email: denghui@chinamobile.com Liu Expires September 8, 2010 [Page 17]