Internet Engineering Task Force Alain Durand
INTERNET-DRAFT SUN Microsystems,inc.
June, 3, 2002
Expires December, 4, 2002
NAT64 - NAT46
<draft-durand-ngtrans-nat64-nat46-00.txt>
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.