Internet Engineering Task Force Alain Durand INTERNET-DRAFT SUN Microsystems,inc. June, 3, 2002 Expires December, 4, 2002 NAT64 - NAT46 Status of this memo This memo provides information to the Internet community. It does not specify an Internet standard of any kind. This memo is in full conformance with all provisions of Section 10 of RFC2026 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/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Abstract This document defines two scalable NAT mechanisms, NAT64 to enable IPv6-only devices to initiate communications with unmodified IPv4 only devices and NAT46 to enable IPv4-only devices to initiate communications with IPv6-only devices. 0. Terminology In this document, an IPv6-only node refers to a node that implement IPv6 and is configured with an IPv6 address. It may or may not implement IPv4 in the kernel, but if it does, the IPv4 stack is unconfigured. Similarly, an IPv4-only node may or may not implement IPv6, and if it does, its IPv6 stack is unconfigured. 1. Balkanization of the Internet. Very early in the design of IPv6, it was decided that there would be no D-day in the transition from IPv4 to IPv6. Such an approach had been experimented in the transition from NCP to TCP when the size of the Internet was only a few hundred hosts and it turned out to be rather chaotic. Even without a D-day, there will be a time where IPv6-only devices will appear in significant number. It is highly probable that, when this will happen, there would still be a very large population of unmodified IPv4-only devices in the Internet, so the question of how much communication is needed in between those two kind of devices is essential to understand when designing transition tools and scenarios. At one end of the spectrum, some say that the value of the Internet is that any device can talk to any other device, thus communication between IPv6-only nodes and IPv4-only nodes should be as seamless as possible. On the other end of the spectrum, some say that new IPv6-only devices will only need services from IPv6 nodes and will not talk to IPv4 nodes, thus the need for communication is minimal and can be handled by application proxies when and if needed. The issue with this later approach is that, even if the final communication is taking place between two IPv6 nodes, it may be the case that the communication set-up process will require third parties, like DNS resolution, LDAP queries, mail MX relay discovery,... and some of the steps in this resolution processes may include sending packet to an infrastructure service only available via IPv4. If IPv6 nodes cannot seamlessly uses those services from IPv4 land, communications between two IPv6-only nodes may or may not be possible. This could lead to the balkanization of the Internet where things may work in some places, but not in others, and troubleshooting will be difficult. 2. Problem statement. As the number of services that an IPv6 only node may require from the IPv4 Internet is potentially large, it will make sense to try to find a solution at the IP layer that will work for all services. This memo is proposing a scalable layer 3 solution to enable communication initiated by any IPv6-only node to any unmodified IPv4-only node or the other way round with minimum configuration in the network and very minimum configuration (zero if possible) on the end nodes and without introducing any new security problems. 3. NAT-PT Issues regarding NAT-PT have been described in [NAT-PTissues]. 4. NAT64 This section describe an address translation mechanism to enable an IPv6-only node to initiate a connection to an unmodified IPv4 node. 4.1 Background: IPv4 connections from a dual-stack node On a dual stack node, when an IPv6 application wants to send a packet to an IPv4 address x.y.z.t, it can encode it in a IPv4-mapped address format ::FFFF:x.y.z.t and let the kernel choose the IPv4 stack. In some sense, this is a form of address translation done within the node. ::FFFF:x.y.z.t ------------|---- |IPv6 Applica|tion| |------------|----| | IPv6 | IP|v4 | ------------|---- | | | \-----------------> ======================================> LAN NAT64 proposes to extend this mechanism to IPv6-only nodes. 4.2 Mapping IPv4 address to IPv4-mapped addresses On IPv6 only nodes implementing [RFC2553], the resolver library may add special code to the getnameinfo() routine to automatically map IPv4 addresses obtained via A record to IPv4-mapped addresses. This way, IPv6 applications using getnameinfo() will always be returned IPv6 addresses. Application performing direct DNS query for A records should perform this mapping themselves. 4.3 Sending an IPv4-mapped packet When an IPv6-only node wants to communicate with an IPv4 node, it can send packets to the corresponding IPv4-mapped address on a link using an IPv6 address of the same scope as source address. The IPv6 node should consult its routing table to find out the correct outgoing interface. ::FFFF:x.y.z.t ---|------------- |IPv|6 Application| |---|-------------| | IP|v6 | | ---|------------- | | \----|---------------------> ======================================> LAN 4.4 Intercepting the IPv4-mapped packets A NAT64 box can simply inject the ::FFFF:0/96 route in the routing domain where it is willing to perform IPv6 to IPv4 address translation. ::FFFF:x.y.z.t ---|------------- |IPv|6 Application| |---|-------------| | IP|v6 | | NAT64 ---|------------- <----advertising | | ::FFFF:0/96 \----|-----> -------------- --------- ===================|default router|===========|IPv6|IPv4|=======> -------------- --------- 4.5 Address translation IPv6 to IPv4 address translation is then performed in a similar way as described in NAT [RFC3022] and NAT-PT [RFC2766]. 4.6 Scalability NAT64 can be made to scale almost infinitely by adding NAT64 boxes. Each NAT64 will advertise a slightly longer prefix than ::FFFF:0/96. In the example bellow, four NAT64 advertise each 1/4 of the IPv4 address space. NAT64-0 ::FFFF:x.y.z.t ::FFFF:0000/98 ---|------------- --------- |IPv|6 Application| ====|IPv6|IPv4|=======> |---|-------------| | --------- | IP|v6 | | | ----------------- | NAT64-1 | | | ::FFFF:4000/98 \----|-----> -------------- | --------- ===================|default router|===========|IPv6|IPv4|=======> -------------- | --------- | | NAT64-2 | ::FFFF:8000/98 | --------- |====|IPv6|IPv4|=======> | --------- | | NAT64-3 | ::FFFF:C000/98 | --------- ====|IPv6|IPv4|=======> --------- Prefixes advertised by the NAT64 do not have to be all of the same length. For instance, if the network administrator knows there is a lot of traffic for a particular IPv4 prefix, he may want to dedicate a NAT64 for it and let the rest of the traffic go to the main NAT64 box. In the example bellow, the NAT64-0 box is dedicated to translate the traffic for 11.14.14.15 NAT64-0 ::FFFF:x.y.z.t ::FFFF:BEEF/128 ---|------------- --------- |IPv|6 Application| ====|IPv6|IPv4|=======> |---|-------------| | --------- | IP|v6 | | | ----------------- | NAT64-1 | | | ::FFFF:0000/96 \----|-----> -------------- | --------- ===================|default router|===========|IPv6|IPv4|=======> -------------- --------- 4.7 Limits of the model The underlying assumption of this model is that the routes to the NAT64 boxes are stable for the duration of the communication to be translated. All the traditional limitation of NAT [RFC2993] in IPv4 space also applies here. 5. NAT46 This section describe an address translation mechanism to enable an unmodified IPv4-only node to initiate a connection to an IPv6-only node. 5.1 Background NAT46 is designed to work for unmodified IPv4-only node, so doing address mapping in the resolver library is out of scope. Some form of ALG has to take place elsewhere in the DNS. The main issue of NAT-PT in this mode of operation is that the DNS ALG is very sensitive to denial of service attacks, as the pool of IPv4 addresses could very easily be exhausted by external attackers. The idea here is to perform the mappings "close" to the originating IPv4 nodes (i.e. in the DNS resolver) instead of "close" to the destination IPv6 node (i.e. in the DNS server), leaving it to the local IPv4 network administrators to offer the service to "bridge" toward the global IPv6 Internet. 5.2 Address mapping The first thing an unmodified IPv4-only node needs in order to establish a connection to an IPv6-only node is a DNS 'A' record that contains a mapping to the destination IPv6 address. As the underlying assumption is that the IPv4 node cannot be modified, this mapping can only be done by a DNS resolver. So the first step of this process if for the unmodified IPv4-only node to send a A query for a FQDN to a local DNS resolver. ----------------------------------- | | | | | ---- -------- | |IPv4| 'A' query | DNS | | |node|----------------------->|resolver| | ---- -------- | | | IPv4 network | ----------------------------------- Receiving the A query, the local DNS resolver tries to resolve it. If it succeeds, then the FQDN has one or more IPv4 address already assigned to it and there is no need for translation, the resolver just passes the A records back to the IPv4-only node. ----------------------------------- | | | | | ---- -------- 'A' query | |IPv4| 'A' replies | DNS |---------> | |node|<-----------------------|resolver|<-------- | ---- -------- 'A' replies | | | IPv4 network | ----------------------------------- If the A resolution fails, the resolver tries a AAAA query for the same FQDN. If that query fails, there is no IPv6 address assigned to that name, and the resolver returns a failure notification to the IPv4-only node. ----------------------------------- | | | | | ---- -------- 'AAAA' query fails | |IPv4| error notification | DNS |---------> | |node|<-----------------------|resolver| | ---- -------- | | | IPv4 network | ----------------------------------- If the AAAA query succeeds, the resolver creates mappings between the returned IPv6 address and the same number of IPv4 addresses taken out of a reserved prefix P. IANA considerations for this prefix are covered in Section 7. The resolver then creates A records for those IPv4 addresses, using the TTL includes in the AAAA answers, and return those A records back to the IPv4-only node. The mappings should be expired before the associated TTL. ----------------------------------- | | | | | ---- -------- 'AAAA' query | |IPv4| 'A' replies | DNS |---------> | |node|<-----------------------|resolver|<-------- | ---- |mapping | 'AAAA' replies | -------- | | | IPv4 network | ----------------------------------- 5.3 Address translation The proposition here is to collocate the local DNS resolver with a NAT46 box that will advertise the prefix P to the local network and intercept packets which destination addresses are included in P. The NAT46 is connected to the IPv6 Internet and is allocated a prefix Q/64 taken out of the IPv6 address block that has been allocated to the network. The NAT46 advertise the prefix Q/64 in the local IPv6 routing domain. Address mapping is then performed: - IPv4 src x.y.z.t is translated to IPv6 src Q::x.y.z.t - IPv4 dst m.n.o.p (from prefix P) is translated to the IPv6 addresses that was mapped by the DNS resolver. The rest of the translation is performed as described in NAT [RFC3022] and NAT-PT [RFC2766]. ----------------------------------- | | | route for P -------- | ---- <---------| NAT46 | | |IPv4| | DNS |================> | |node|----------------------->|resolver| IPv6 network | ---- IPv4 packet sent -------- | to the 'mapped' | | address m.n.o.p | | | | IPv4 network | ----------------------------------- When the packet returns from the IPv6 network, as the NAT46 box advertise the prefix Q/64, it can intercept it again and perform the opposite translation. ----------------------------------- | | route for Q/64 | -------- --------> | ---- | NAT46 | | |IPv4| | DNS |<================ | |node|<-----------------------|resolver| IPv6 network | ---- -------- | | | IPv4 network | ----------------------------------- 5.4 Mapping duration As said in 5.2, mapping should not last more than the TTL associated with the AAAA records. However, after a period of inactivity, the NAT46 box may decide to flush this mapping. 5.5 Scalability Scalability can be achieved in a similar way as in NAT64 by adding several NAT46 boxes and having each of them advertise a sub-prefix of P. It is possible to partition the IPv4 clients to use different DNS resolver and thus maintain the collocation of DNS resolver and NAT46. Another alternative could be to design a signaling protocol between the DNS resolver and the NAT46 boxes to trigger mapping on/mapping off information. Such a protocol is clearly beyond the scope of this document and is let for future studies. 5.6 Limits of the model The underlying assumption of this model is that the routes to the NAT46 boxes are stable for the duration of the communication to be translated. All the traditional limitation of NAT [RFC2993] in IPv4 space also applies here. Although NAT46 can be used in conjunction with [RFC1918] private address space, it will works for communication started from IPv4 private addresses to global IPv6 addresses. Neither NAT64 nor NAT46 enable an IPv6 node to initiate communications with an IPv4 node that is behind a NAT box and is using [RFC1918] IPv4 private addresses. 6. Security considerations NAT64 and NAT46 share the same security considerations as IPv4 NAT as they operate the same way. The security consideration raised in [NAT-PTissues] do not apply to NAT64. If such an attack is launched against NAT46, the effect will be limited to the IPv4 site covered by NAT46 and will not prevent communication from other nodes in the IPv4-only Internet to initiate communication with IPv6 only nodes. 7. IANA Considerations As NAT46 can be used in conjunction of [RFC1918] addresses, the prefixes 10/8, 172.16/12 and 192.168/16 cannot be use for address mapping. Allocating a /8 prefix would enable 2^24 (about 16 millions) contexts. Allocating a /16 prefix would enable 2^16 (about 65 thousands) contexts. Allocating a /24 prefix would enable 2^8 (256) contexts. Decision on the prefix length to allocate will be done in the NGtrans mailing list. 8. Author addresses Alain Durand SUN Microsystems, Inc 901 San Antonio Road MPK17-202 Palo Alto, CA 94303-4900 USA Mail: Alain.Durand@sun.com 9. References [RFC1918] Address Allocation for Private Internets. Y. Rekhter, B. Moskowitz, D. Karrenberg, G. J. de Groot, E. Lear. February 1996. [RFC2553] Basic Socket Interface Extensions for IPv6. R. Gilligan, S. Thomson, J. Bound, W. Stevens. March 1999. [RFC2766] Network Address Translation - Protocol Translation (NAT- PT). G. Tsirtsis, P. Srisuresh. February 2000. [RFC2993] Architectural Implications of NAT. T. Hain. November 2000. [RFC3022] Traditional IP Network Address Translator (Traditional NAT). P. Srisuresh, K. Egevang. January 2001. [NAT-PTissues] Issues with NAT-PT DNS ALG in RFC2766, A. Durand, draft-durand-natpt-dns-alg-issues-00.txt, work in progress. 10. Full Copyright Statement "Copyright (C) The Internet Society (2001). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.