Network Working Group D. Liu Internet-Draft China Mobile Intended status: Informational March 1, 2010 Expires: September 2, 2010 draft-liu-behave-nat46-01 draft-liu-behave-nat46-00 Abstract The IPv4/IPv6 transisation period will last for a long time. Different phases of IPv4/IPv6 transisation have different scenarioes and requirements and need different solutions. In the early stage of IPv4/IPv6 transisation, sicne the majority of Internet resoure locates in the IPv4 Internet, the main communication will be IPv6 clients iniate communication to IPv4 servers. But during the later stage of the transisation, the servers may locate in the IPv6 network/Internet, in this scenario, there is a need for IPv4 client to iniate communication to IPv6 servers. These document proposal solution to address this scenario. 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 2, 2010. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the Liu Expires September 2, 2010 [Page 1] Internet-Draft NAT46 consideration March 2010 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 . . . . . . . . . . . . . . 4 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. 4. DNS46 consideration . . . . . . . . . . . . . . . . . . . . 6 5. 5. NAT46 GW consideration . . . . . . . . . . . . . . . . . . 8 6. 6. ALG consideration . . . . . . . . . . . . . . . . . . . . . 9 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 10. Normative References . . . . . . . . . . . . . . . . . . . . . 13 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14 Liu Expires September 2, 2010 [Page 2] Internet-Draft NAT46 consideration March 2010 1. Introduction +------------------------------------------------------+ | | | | | +----------------+ +---------------+ | | | IPv4 Network | |IPv6 Internet | | | | +-----------+ | +-----------+ | +-----------+ | | | | | |--|--| NAT46 GW |--|-| | | | | | |IPv4 Client| | | | | |IPv6 Server| | | | | +-----------+ | +-----------+ | +-----------+ | | | | | | | | | +----------------+ +---------------+ | | | | | DNS | +------------------------------------------------------+ Figure 1 NAT46 scenario. As figure 1 illustrated, the IPv4 client which locates in the IPv4 network initiate communication to the IPv6 server which locates in the IPv6 Internet. Current specifications, such as NAT64 cannot be used this scenario. NAT-PT could address this scenario but due to the scalability and other issues, NAT-PT specification has been abolished. But in the later period of IPv4/IPv6 transition, it is clear that the NAT46 scenario will be needed. This document proposes a solution to address this scenario. Liu Expires September 2, 2010 [Page 3] 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 2, 2010 [Page 4] Internet-Draft NAT46 consideration March 2010 3. Terminology NAT46: refers to the scenario that IPv4 client initiate communication to IPv6 servers. 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 2, 2010 [Page 5] Internet-Draft NAT46 consideration March 2010 4. 4. DNS46 consideration In the NAT46 scenario, the IPv4 client tries to communicate with an IPv6 server. The IPv4 application will normally send type A DNS query. Since the server is IPv6 only and has only type AAAA DNS record, there will be no type A DNS response thus the communication will not succeed. There are there ways to solve this problem: 1) NAT46 GW performs DNS ALG. It means that when the IPv4 with type A DNS query message arrives at the NAT46 GW, the NAT64 GW translates it into IPv6 and 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 the mapped server IPv4 address then return to the IPv4 host with the mapped A record. The IPv4 client will use the mapped IPv4 address as the IPv6 server's IP address to start the communication. 2) DNS46 performs DNS ALG. This means that there will be a DNS46 server in the network and performs the DNS ALG. The IPv4 client's type A DNS query will arrives at DNS46, DNS46 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 inform this mapping information to the NAT46 GW. The IPv4 client will use this mapped IPv4 address to initiate the communication. 3) Host performs DNS ALG. In this situation, the DNS ALG function resides in the host. The IPv4 application in the IPv4 client send type A DNS query, when there is no response; the DNS ALG function in the host sends type AAAA DNS query, when a type AAAA DNS response is received, the DNS ALG function in the host create a mapping between the IPv6 address of the server and a domically created IPv4 mapping address. The DNS ALG function in the host will then need to notify the NAT46 GW about the mapping information. The three different approaches have their own advantages and disadvantages: For the approach that performs DNS ALG in NAT46 GW, the main disadvantage is that it will add complexity to the NAT46 GW. The Liu Expires September 2, 2010 [Page 6] Internet-Draft NAT46 consideration March 2010 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 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 performing DNS 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 and also need to synchronize IPv6-IPv4 mapping information between the host and DNS46 GW. The synchronization mechanism between the DNS ALG and NAT46 GW need to be further identified. Liu Expires September 2, 2010 [Page 7] Internet-Draft NAT46 consideration March 2010 5. 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 IPv4 address by DNS ALG function ether resides in NAT46 GW, DNS46 or 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 seed whether there is a mapping entry of this IPv4 address. 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 2, 2010 [Page 8] Internet-Draft NAT46 consideration March 2010 6. 6. ALG consideration When there are IP addresses embedded in the payload, it will require the NAT46 GW to perform translation of the embedded IP address. NAT46 GW should support the most commonly used protocol's ALG. It would not require the NAT46 GW to support all the ALGs due to the scalability and complexity restriction. Liu Expires September 2, 2010 [Page 9] Internet-Draft NAT46 consideration March 2010 7. Security Considerations TBD Liu Expires September 2, 2010 [Page 10] Internet-Draft NAT46 consideration March 2010 8. IANA Considerations None Liu Expires September 2, 2010 [Page 11] Internet-Draft NAT46 consideration March 2010 9. Acknowledgments TBD Liu Expires September 2, 2010 [Page 12] Internet-Draft NAT46 consideration March 2010 10. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Liu Expires September 2, 2010 [Page 13] 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 Liu Expires September 2, 2010 [Page 14]