Network Working Group I. van Beijnum
Internet-Draft IMDEA Networks
Expires: August 15, 2008 B. Carpenter
Univ. of Auckland
February 12, 2008
Modified Network Address Translation - Protocol Translation
draft-van-beijnum-v6ops-mnat-pt-00
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of 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 August 15, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Abstract
A smooth transition from IPv4 to IPv6 requires that either all hosts
are upgraded to dual stack before the first hosts can become IPv6-
only, or that there be some mechanism for IPv6-only hosts to talk to
IPv4-only hosts. Expecting the former within a reasonable timeframe
isn't realistic, based on current adoption of dual stack combined
with the latest projections for the IPv4 depletion that point to a
date early in the next decade. And the IETF has recently deprecated
van Beijnum & Carpenter Expires August 15, 2008 [Page 1]
Internet-Draft Modified NAT-PT February 2008
the main mechanism that allows the latter: NAT-PT.
This document proposes a modified form of NAT-PT that addresses the
reasons why the mechanism was deprecated and currently understood
requirements. This should allow future deployment of the modified
NAT-PT as an IPv4-to-IPv6 transition mechanism, giving operators the
option of running their networks largely IPv6-only.
1. Introduction
1.1. Background
The original NAT-PT mechanism outlined in [RFC2766] couples three
underlying techniques to arrive at a comprehensive solution that
allows IPv6-only hosts to initiate connections or associations
towards IPv4-only hosts:
1. Stateless IP and ICMP Translation [RFC2765]
2. Network Address / Port Translation
3. A DNS Application Layer Gateway [RFC2694]
Basically, when an IPv6 host wants to connect to a service, it looks
up the associated host/service name in the DNS. If no AAAA records
are available for the name in question, the DNS ALG synthesizes an
AAAA record based on the A record for the host/service and a prefix
that's routed to a translation device. The IPv6 host initiates
communication towards the resulting IPv6 address. The associated
packets end up at the translator, which recovers the original IPv4
destination address, translates between IPv6 and IPv4, performs IPv4
NAT and sends the resulting packet to the IPv4 destination. Return
packets are translated back and sent to the IPv6 host.
1.2. Summary of Requirements
[RFC4966] explains why NAT-PT as originally defined is problematic.
The main objections boil down to hosts being exposed to an unexpected
environment, issues with referrals in the absence of relevant
Application Layer Gateways, generation of synthetic DNS responses
that may be harmful if not properly contained and constraints on
network topology. Another problem with having a DNS ALG in a central
location in the network is that this makes it hard to make synthetic
AAAA records only flow towards IPv6-only hosts and not dual stack
hosts. A major requirement on any modified form of NAT-PT is to
mitigate or eliminate as many of the issues in [RFC4966] as possible.
van Beijnum & Carpenter Expires August 15, 2008 [Page 2]
Internet-Draft Modified NAT-PT February 2008
The underlying requirement can be summarized as providing a
scaleable, reliable and secure mechanism by which IPv4-only hosts may
exchange packets with IPv6-only hosts. Aspects of this include:
1. IPv4-only hosts are presumed to be legacy systems to which no
modifications whatever can be made. Even if IPv6 is supported on
their network, they have no way to understand or create IPv6
packets, even if certain applications understand IPv6 addresses.
2. IPv4-only hosts may be on legacy networks whose routers have no
support for IPv6.
3. For the purposes of this document, the IPv6 host has no direct
support for IPv4, i.e. it is not a dual-stack host. (If it was a
dual-stack host, it could have direct or tunneled and possibly
NATted IPv4 connectivity to the IPv4-only host.)
4. From the IPv4 host's point of view, nothing should behave worse
than in the case of an IPv4-to-IPv4 translation.
5. From the IPv6-only host's point of view, we can require some
special code in the IP stack, but no knowledge of IPv4 should
generally be required in the transport layer or above.
6. IPv6 routing should not be affected in any way, and there should
be no risk of importing "entropy" from the IPv4 routing tables
into IPv6.
7. At the point where the IPv6 and IPv4 addressing domains meet, it
is necessary to share limited IPv4 addresses among multiple IPv6
hosts in some way, while allowing the IPv4 host to assume that
{IPv4 address, port number} 2tuples are unique.
8. It should be possible to locate the translation device at an
arbitrary point in the network (i.e. not at fixed points such as
a site exit), so that there is full operational flexibility.
9. Any configuration need for an IPv6 host to make use of the
mechanism should be possible centrally, e.g. a DHCP option.
A full problem statement and requirements analysis is developed in
[I-D.bagnulo-v6ops-6man-nat64-pb-statement].
1.3. Outline of Solution
As noted in the requirements, we cannot ask for any change whatever
in legacy IPv4 hosts. However, it is considered reasonable to
require enhancements to IPv6-only stacks, which are much rarer at the
van Beijnum & Carpenter Expires August 15, 2008 [Page 3]
Internet-Draft Modified NAT-PT February 2008
time of writing than dual stacks, and certainly are not a legacy.
Based on this consideration, this document proposes to make the IPv6
side aware of the translation in order to avoid the majority of the
problems associated with the original NAT-PT. The objective is to
allow the IPv6 stack at the host to be aware of the presence of the
translator, of the addresses involved in the translation, and of
other information known by the translator that may be of value to the
IPv6 host.
There may be cases where a "legacy" IPv6 stack is in used that knows
nothing of this solution. We do propose a mechanism for this, which
can best be described as a DNS trick (moving the creation of
synthetic AAAA records much closer to the IPv6 host).
Although this document goes into some detail, it's intended as a
discussion document; as such, not every aspect is completely worked
out. This version incorporates text and ideas from
[I-D.carpenter-shanti].
In some discussions, a distinction is made between Network Address
Translation (NAT) which only translates addresses, and Network
Address/Port Translation (NAPT) which translates both addresses and
TCP/UDP port numbers. No such distinction is made here; "NAT" is
used to refer to both types of translation. In fact, due to the
requirement for multiple IPv6 hosts to share a limited number of IPv4
addresses, port multiplexing is inevitable.
The requirement above that behaviour be no worse than in IPv4-IPv4
NAT is significant. It means that the required behaviour is
isomorphic to an IPv6-to-IPv4 translation followed by IPv4-IPv4 NAT,
even if the two translations are implemented in a single stage.
We use the abbreviation "MNAT-PT" to refer to the modified NAT-PT
mechanism described in this document.
2. IPv6-to-IPv4 operation
In the following diagram,
A(x) is an IPv6 address of the IPv6 host X.
P(x) is the port number in use at X.
A(t) is a synthesized IPv6 address for the translator T.
P(y) is the port number in use at the IPv4 host Y.
van Beijnum & Carpenter Expires August 15, 2008 [Page 4]
Internet-Draft Modified NAT-PT February 2008
a(t) is an IPv4 address of the translator.
P(tx) is the translated port number presented to the IPv4 host.
a(y) is the IPv4 address of Y.
v6 host MNAT-PT v4 host
X T Y
_______ A(x) A(t) _______________ a(t) a(y) _______
| | V6|P(x) P(y)| V6| | | V4|P(tx) P(y)| V4| |
| | | | | S | N | | | | |
| U | S | | S | I | A | S | | S | U |
| L | T |------------| T | I | T | T |-----------| T | L |
| P | A | | A | T | | A | | A | P |
| | C | | C | | | C | | C | |
| | K | | K | | | K | | K | |
|___|___| |___|___|___|___| |___|___|
If there's another IPv4 NAT with address a(n) on the IPv4 path, it
won't know anything is special, and a(y) will be represented by a(n).
X, Y and T won't know that the NAT is there. X and T will not know
if Y has a private [RFC1918] address or if additional port
translation takes place.
2.1. Use of A records and addressing the translator
In the original NAT-PT design a DNS ALG would create synthetic AAAA
DNS records for FQDNs that only have A records. This is the source
of the worst problems described in [RFC4966]. Although discouraged,
this mechanism MAY still be used. However, in order to comply with
this specification, DNS ALGs MUST include an EDNS0 option [RFC2671]
in any replies that contain synthetic AAAA records to make these
records recognizable as synthetic so that they can be filtered by
hosts that have no need for them and DNS servers. IPv6 hosts that
want to communicate with IPv4 hosts SHOULD look up the A records
themselves, obtaining a(y), and create a synthetic IPv6 destination
address by concatenating a particular /96 prefix and the bits of
a(y). The resulting IPv6 address A(t) will cause the packet to be
delivered to the relevant MNAT-PT.
Thus the IPv6 hosts "behind" a MNAT-PT translator SHOULD behave in
one of two ways:
1. The IPv6 host has a combination of resolver, API and stack that
in effect maps A records into AAAA records expanded with that
/96. When resolving an FQDN via getaddrinfo(), the effect is to
return A(t) instead of a(y). The upper layer protocol will see
van Beijnum & Carpenter Expires August 15, 2008 [Page 5]
Internet-Draft Modified NAT-PT February 2008
only an IPv6 address.
2. Alternatively, the IPv6 host users IPv4 addresses in their native
or IPv4-mapped IPv6 form and then add the /96 bits as a packet is
about to be generated for transmission on the wire.
Both mechanisms will work in a network with a mixture of MNAT-PT and
dual-stack hosts. The former would see A(t), and the latter would
see a(y), using the same, unmodified, DNS server.
The two ways to do MNAT-PT have different tradeoffs. In both cases,
it's suboptimal to have MNAT-PT activated on dual stack hosts,
because this prevents native IPv4 operation. In addition to that, in
the former case going from IPv6-only with MNAT-PT to dual stack
without MNAT-PT (when native IPv6 connectivity becomes available)
doesn't cause interruptions in ongoing communication. In the latter
case, the transition from IPv6-only with MNAT-PT to dual stack
without MNAT-PT means all communication towards IPv4 destinations
will immediately change from using MNAT-PT to native IPv4, thereby
breaking ongoing sessions.
This document does not specify exactly how MNAT-PT should be
implemented; there is a range of design options, such as in the
resolver, in the socket API, or even in the stack itself, as detailed
below. This list of options is not exhaustive; any implementation
that exhibits similar externally visible behaviour is acceptable.
The most basic way to implement this specification is almost
identical to the original NAT-PT, except that the DNS ALG
functionality is moved as close to the hosts that make use of the
translator as possible. The DNS ALG can be integrated in a host's
resolver library or be provided by an external server topologically
close to the host. This means that the IPv6 stack on a host sees
synthetic AAAA records and treats the addresses in those AAAA records
as regular IPv6 addresses. For many applications and protocols, this
can work well, but it has the downside that applications may see NAT
applied to what they percieve as IPv6 communication. As such, this
way of implementing MNAT-PT is only recommended for applications and
protocols that have no problem working through NAT. Applications
SHOULD avoid storing addresses learned through synthetic AAAA records
in accordance with the zero (or one) TTL value in those records.
Alternatively, an implementation may forego the use of synthetic AAAA
records, and present IPv4 addresses in A records to applications as
IPv4-mapped IPv6 addresses in the ::ffff:0:0/96 prefix. When the
host in question only has IPv6 connectivity and it is configured with
a /96 prefix of a translator, it will, for the purposes of [RFC3484]
address selection, treat destination addresses of this type as IPv6
van Beijnum & Carpenter Expires August 15, 2008 [Page 6]
Internet-Draft Modified NAT-PT February 2008
addresses so the host's IPv6 address(es) can be used as a source
address. When generating IP packets, the stack replaces the ::ffff:
0:0/96 prefix in the destination address with the /96 prefix for the
translator and sends the packets to the translator. Applications may
recognize the IPv4-mapped IPv6 addresses and adjust their behaviour
to the apparent use of IPv4. However, the use of an IPv6 source
address could lead to unexpected application behaviour in this case.
Finally, an implementation may choose to provide full IPv4 service to
applications, by not only supporting the IPv6 socket API with IPv4-
mapped addresses as outlined above, but by also supporting the IPv4
socket API. For full compatibility, a synthetic IPv4 source address
in [RFC1918] space is generated, indicating to applications not only
that the communication is going towards an IPv4 destination, but also
that there will be NAT, so that applications can employ NAT traversal
techniques.
Each of these approaches removes the need for a DNS-ALG that is
created by the original NAT-PT model, and thereby removes the
problems caused by a DNS-ALG.
In the hopefully rare case that an IPv6 address representing an IPv4
host needs to be configured manually, it MAY be configured as the
MNAT-PT translator's /96 prefix concatenated with the IPv4 address.
The approach where IPv4 addresses are used in their native or IPv4-
mapped IPv6 form is preferable and SHOULD be used if supported
because this way, the host is able to communicate successfully if it
is later served by a different MNAT-PT translator or obtains native
IPv4 connectivity.
There are three possible approaches to the /96 prefix:
1. Use ::ffff:0:0/96 as an anycast prefix
2. Use a to-be-defined prefix other than ::ffff:0:0/96 as an anycast
prefix
3. Use a prefix specific to a translator
The authors are of the opinion that the benefits of simplicity of the
first approach don't outweigh the downsides of unexpectedly seeing
IPv4-mapped IPv6 addresses on the wire. In order to provide
flexibility to operators, the third option MUST be supported using
the discovery/configuration mechanisms outlined later in this
document. The desireability of the second option is open for further
discussion. As such:
The 96-bit prefix used by a translator SHOULD be in the IPv6 global
van Beijnum & Carpenter Expires August 15, 2008 [Page 7]
Internet-Draft Modified NAT-PT February 2008
unicast space (2000::/3) or unique local address space (fc00::/7).
Note that the status of parts of the IPv6 address space may change
over time; it is not appropriate to hardcode these prefixes in
applications or default configurations. The 96-bit prefix used by a
translator MUST NOT use the ::/96 or ::ffff:0:0/96 prefixes.
Discussion: There has been an operational preference that IPv4-mapped
IPv6 addresses should not appear on the wire, although this is broken
by SIIT ([RFC2765]), one of the underlying mechanisms of the original
NAT-PT. Operational difficulties have been reported with such
addresses escaping into the wild, and there is confusion because thay
are also used for automatic mapping within some dual stacks.
Although it requires more work, an arbitrary prefix for the
translator can still maintain the "checksum to zero" property.
However, since we assume that the MNAT-PT device will also perform
port mapping, checksum recalculation seems inevitable anyway. So
does the checksum-to-zero property matter? The SHANTI proposal
[I-D.carpenter-shanti] avoided this problem by actively translating
the IPv6 address used, at the expense of considerable complexity.
The current proposal is to accept that checksum recalculation in the
translator is inevitable (as it is in IPv4-IPv4 NAT). In this case,
the ::ffff:0:0/96 prefix has no particular advantage.
Allowing an arbitrary, or anycast, prefix to locate the MNAT-PT
device allows for arbitrary topology: the MNAT-PT can be on the IPv6
site, or in any ISP location that has both IPv4 and IPv6
connectivity. This allows for great flexibility in deployment
models.
For operational convenience, there must be a way for a client machine
to discover the locally applicable MNAT-PT /96 prefixe. This draft
does not fully specify this mechanism. The range of possibilities
include:
1. Default to the anycast prefix mentioned above.
2. Define a DHCPv6 option.
3. Define a DNS based convention such as mnat. prepended to the
local domain name. Use the /96 prefix of the corresponding AAAA
record.
4. Allow manual configuration of a DNS name as an almost last
resort.
5. Allow manual configuration as a last resort.
The authors intended to specify mechanisms for the second and third
van Beijnum & Carpenter Expires August 15, 2008 [Page 8]
Internet-Draft Modified NAT-PT February 2008
options in a later version of this document.
2.2. Use of a synthetic IPv4 source address
Optionally, IPv6-only hosts MAY support IPv4 (and IPv4-mapped IPv6)
socket calls for compatibility with applications that don't support
native IPv6 communication and/or need to be aware of the fact that
communication is happening over IPv4 and/or is subject to NAT. A
natural way to indicate this is through the use of an IPv4 source
address from [RFC1918] space.
An IPv6-only host implementing IPv4 compatible socket calls picks one
of its global scope IPv6 addresses as the source address A(x) for
MNAT-PT. It then generates a local IPv4 address in the prefix
172.31.0.0/16, where the lower 16 bits are chosen such that a TCP or
UDP checksum computed over the IPv6 addresses that appear on the wire
are the same as those resulting from the synthetic IPv4 source
address and the IPv4 destination address.
This means that the value of the lower 16 bits in the synthetic IPv4
address are generated through the one's complement addition of the
16-bit words that make up the 96 bit prefix used for IPv4
destinations reachable through the translator and the selected IPv6
source address. Then, a one's complement subtraction of the value
44063 (decimal) is performed to adjust for the 172.31.0.0/16 prefix.
The result of this is that TCP and UDP checksums computed over both
the IPv4 and MNAT-PT IPv6 representations of packets destined for the
translator are the same (ignoring port numbers for the moment). UDP
packets MUST have a valid checksum, as required by IPv6.
Although adjusting checksums during translation steps is relatively
easy, knowing that IPv4 and IPv6 versions of the checksum are
identical may allow for a more flexible implementation, where it's
not necessary to keep track of whether a packet was or will be
translated when a checksum is computed.
The resulting synthetic IPv4 address is internally used as the source
address in all IPv4 processing. Note that MNAT-PT translators keep
track of IPv6 hosts by their IPv6 address: the synthetic IPv4 source
address is unknown to translators and is only used for compatibility
with IPv4-aware applications.
2.3. Signaling from the translator to the IPv6 host
An option to be considered, derived from [I-D.carpenter-shanti], is
for the MNAT-PT to signal to the IPv6 host to inform it of the port
number P(tx) and outbound IPv4 address a(t) actually in use. The
IPv6 host is aware of its own IPv6 address and of the port number it
van Beijnum & Carpenter Expires August 15, 2008 [Page 9]
Internet-Draft Modified NAT-PT February 2008
is using, but these are meaningless on the IPv4 side. With the added
signaling, it would know the 4tuple {a(y), a(t), P(y), P(tx)} in use
on the IPv4 side. In this case, the IPv6 host could in principle
compute a transport checksum that will be valid after address and
port translation, and send this instead of a valid IPv6 checksum.
Such signaling, to be useful to the upper layer protocols in the IPv6
host, would need to occur before the upper layer protocol actually
sent its first packet; in effect the IPv6 stack would have to send a
"request to send" message to the MNAT-PT, in order for the MNAT-PT to
create the necessary translation state and respond with the {a(t),
P(tx)} values.
Tentatively, such a mechanism could use either a dedicated signaling
channel such as an SSL connection between the IPv6 host and the
MNAT-PT, or in-band signaling using a shim header modeled on SHIM6
[I-D.ietf-shim6-proto]. The type of information to be signaled might
include discovery of a(t) and P(tx), opening an external port, etc.
It is open to discussion whether this is worthwhile or whether a more
general approach such as [I-D.woodyatt-ald] might not be better.
This question is not discussed further in this draft.
2.4. Operation
Packets towards to-be-translated IPv4 destinations are transmitted
over the network as usual, but are delivered to the IPv6 interface of
the MNAT-PT translation device. The translation device performs SIIT
translation and IPv4 NAT. The possible artificial IPv4 source
address is ignored during these steps, since it is not required by
either step except as a means to keep track of which sessions on the
public IPv4 side map to which sessions on the IPv6 side. However,
since different IPv6 hosts served by the same translation device may
have selected the same artificial IPv4 address, (de)multiplexing
based on this value won't work. So the SIIT and NAT stages must be
integrated such that the NAT associates sessions on the public IPv4
side directly with the IPv6 side without a private IPv4 intermediate.
Port translation, port mapping, and transport checksum recalculation
will be handled by the NAT component exactly as in a normal IPv4-IPv4
NAT.
3. IPv4-to-IPv6 operation
In order for IPv6-only hosts to receive unsolicited incoming packets
(e.g. incoming TCP sessions and UDP packets that aren't replies to
UDP packets sent earlier), unsolicited packets towards a certain
address / port combination must be translated to a corresponding IPv6
van Beijnum & Carpenter Expires August 15, 2008 [Page 10]
Internet-Draft Modified NAT-PT February 2008
address by a MNAT-PT translators. Much of this resembles what a
normal NAT must do to handle unsolicited incoming packets destined
for servers using private [RFC1918] address space. If the NAT
function of the MNAT-PT (see above diagram) opens port P(tx) at IPv4
address a(t) for unsolicited packets, it must be configured to map
that port to a port P(x) at IPv6 address A(x). When a flow starts,
state is kept to be able to translate return packets from IPv6 to
IPv4.
The issues associated with configuring port mappings and creating,
maintaining and expiring this state are exactly those encountered by
normal NAT, but those can be avoided using the mechanism described
below.
Any organisation needing to provide MNAT-PT translation for
unsolicited incoming packets will need to allocate one or more IPv4
addresses under its control to this purpose, and arrange for the
corresponding mappings to be configured in MNAT-PT devices. It is
most likely that this will be done by sites running IPv6-only servers
and wishing to serve IPv4-only clients, or by the ISP serving a site.
A site running dual-stack servers has no need to run MNAT-PT, and an
IPv4-only site or ISP is unable to do so.
In most scenarios, the IPv4 address(es) assigned to an MNAT-PT device
will be globally routable public addresses. However, there is no
technical reason that they should not be chosen from private[RFC1918]
address space, if a deployment scenario requires it.
The IPv4 source address is encoded in bits 96 - 127 and the IPv4
destination port number in bits 80 - 95 of the IPv6 address for
thusly translated packets so that applications configured with the
knowledge that they are receiving incoming sessions from IPv4 hosts
may recover the original IPv4 source address and destination port
number. The source port number MUST NOT be changed during the
translation process. This makes the translation process stateless.
If desired, the owner of an address block that is used exclusively
for IPv4-to-IPv6 translation can publish mappings from IPv4 address/
port combinations to IPv6 address/port combinations in the reverse
DNS tree as follows:
_service._proto.31.2.0.192.in-addr.arpa IN SRV pri weight v6port FQDN
Where proto is an upper layer protocol (TCP or UDP), pri is a
priority, weight a weight, v6port is a port number used by the IPv6
host and FQDN a fully qualified domain name used by the IPv6 host in
accordance with [RFC2782]. service, however, is not a service name,
but the decimal form of the destination port number in the IPv4
van Beijnum & Carpenter Expires August 15, 2008 [Page 11]
Internet-Draft Modified NAT-PT February 2008
packet.
The address block is then advertised in IPv4 BGP with the well-known
community TRANSLATEV6 attached [RFC1997]. This allows operators of
translators that receive the advertisement through BGP to route
packets towards the address block in question to their own
translator, which recovers the mappings from the DNS and performs the
translation locally. Because the translator inserts its own /96
prefix in the IPv6 source address, packets flow back and forth
between the IPv4 and IPv6 hosts through the same translator.
It is of course compatible with the above that organisations obtain
address blocks for the specific purpose of making IPv6 services
available over IPv4 and anycasting these address blocks in addition
to setting the TRANSLATEV6 community. Because each TCP and UDP port
number can be mapped individually, a relatively small IPv4 address
block can accommodate a large number of IPv6 services, as long as
these services don't depend on well-known port numbers.
MNAT-PT translators MUST encode the IPv4 destiantion port number and
source address in the lower 48 bits of the IPv6 source address in
translated packets. This means that translators must have a /80
range of IPv6 addresses available to perform this type of
translation. Encoding of the IPv4 source address in the IPv6 source
address allows conformant applications or operating systems to
recover the original IPv4 destination port and source address of the
correspondent. However, this only works if the incoming packets are
indeed translated IPv4 packets. If this functionality is desired,
administrators must take care to keep incoming translated IPv4
sessions and normal IPv6 sessions apart by making these arrive at
different IPv6 addresses. In other words, if it's desired that
applications can tell when incoming sessions originate from IPv4
hosts, a server behind an MNAT-PT will need at least one IPv6 address
in its native IPv6 server role (announced as a public AAAA record),
and at least one other IPv6 address in its MNAT-PT serving role (not
announced as an AAAA record, but announced in SRV records in the
reverse IPv4 DNS).
Note that for this type of translation, there is no requirement that
checksums calculated over the IPv4 and IPv6 pseudo headers are the
same: translators must adjust checksums.
An alternative to this was part of the SHANTI proposal
[I-D.carpenter-shanti] in which the external address and port numbers
would be signaled to the IPv6 host stack. In this case checksums and
any other upper layer uses of the IPv4 information could be handled
in the IPv6 host alone. As noted above, it is an open question
whether this added complexity is worthwhile.
van Beijnum & Carpenter Expires August 15, 2008 [Page 12]
Internet-Draft Modified NAT-PT February 2008
4. Examples
The anycast range for IPv6-to-IPv4 translation is assumed to be
1000::/96 in these examples, and the IPv4 address of the translator
is 10.0.0.96. (10.0.0.96 and 172.18.64.80 are used as an example
public IPv4 addresses, not as private addresses here.)
4.1. IPv6-to-IPv4
IPv6 host pc1.beispiel.de 2001:db8:31::dead:beef wants to communicate
with IPv4 host www.example.com, which holds address 192.0.2.58.
pc1.beispiel.de doesn't use a synthetic IPv4 source address.
1. pc1.beispiel.de looks up AAAA records for www.example.com with no
results
2. pc1.beispiel.de looks up A records for www.example.com:
192.0.2.58
3. pc1.beispiel.de initiates a TCP session from 2001:db8:31::dead:
beef port 1025 to 1000::192.0.2.58 port 80
4. the translator sets up a translation mapping from { [2001:db8:
31::dead:beef]:1025 [1000::192.0.2.58]:80 } to { [10.0.0.96]:
49152 [192.0.2.58]:80 }
5. the translator translates packets back and forth until the
session is no longer used and the mapping is garbage collected
4.2. IPv6-to-IPv4 with synthetic IPv4 source address
IPv6 host pc2.beispiel.de 2001:db8:31::cafe wants to communicate with
IPv4 host www.example.com, which holds address 192.0.2.58.
pc2.beispiel.de uses a synthetic IPv4 source address.
1. pc2.beispiel.de does a one's complement addition of the values
1000, 0000, 0000, 0000, 0000, 0000 (the translator anycast
address), 2001, 0db8, 0031, 0000, 0000, 0000, 0000, cafe (its
source address) which results in 08e9
2. pc2.beispiel.de does a one's complement subtraction of ac1f
(172.31) from 08e9 = a336 (163.54)
3. pc2.beispiel.de configures a virtual network interface with IPv4
address 172.31.163.54
4. pc2.beispiel.de looks up AAAA records for www.example.com with no
results
van Beijnum & Carpenter Expires August 15, 2008 [Page 13]
Internet-Draft Modified NAT-PT February 2008
5. pc2.beispiel.de looks up A records for www.example.com:
192.0.2.58
6. pc2.beispiel.de initiates a TCP session from 2001:db8:31::cafe
port 1025 to 1000::192.0.2.58 port 80
7. the translator sets up a translation mapping from { [2001:db8:
31::cafe]:1025 [1000::192.0.2.58]:80 } to { 10.0.0.96:49153
192.0.2.58:80 }
8. the translator translates packets back and forth until the
session is no longer used and the mapping is garbage collected
4.3. IPv4-to-IPv6
IPv4 host mac1.example.com holding address 192.0.2.253 wants to
communicate over the FTP protocol with IPv6 host pc1.beispiel.de.
The port number available for this service is 32767. In order to
accommodate incoming sessions, pc1.beispiel.de has set up the
following entries in the DNS:
pc1.beispiel.de. IN A 172.18.64.80
_32767._tcp.80.64.18.172.in-addr.arpa IN SRV 21 pc1.ddns.beispiel.de.
pc1.ddns.beispiel.de. IN AAAA 2001:db8:31::dead:beef
The closest MNAT-PT translator uses prefix 2001:db8:ffff::/96 for
translations from IPv4 to IPv6.
1. mac1.example.com wants to connect to pc1.beispiel.de on port
32767
2. mac1.example.com looks up A records for pc1.beispiel.de in the
DNS: 172.18.64.80
3. mac1.example.com sets up a TCP session from 192.0.2.253:1025 to
172.18.64.80:32767
4. the packet for 172.18.64.80 is routed towards a MNAT-PT
translator
5. the translator transfers 172.18.64.80:32767 into
_32767._tcp.80.64.18.172.in-addr.arpa
6. the translator looks up SRV records: 0 0 21 pc1.ddns.beispiel.de
van Beijnum & Carpenter Expires August 15, 2008 [Page 14]
Internet-Draft Modified NAT-PT February 2008
7. the translator looks up AAAA records: 2001:db8:31::dead:beef
8. the translator sets up a mapping from { 192.0.2.253:1025
172.18.64.80:32767 } to { [2001:db8:ffff::192.0.2.253]:1025
[2001:db8:31::dead:beef]:21 }
9. the translator translates packets back and forth until the
session is no longer used and the mapping is garbage collected
5. Advantages and disadvantages
5.1. Disadvantages
MNAT-PT operation is possible without necessarily requiring changes
to the TCP/IP stack or applications, but in that case, applications
may operate under the assumption that they're talking to IPv6
correspondents, while in fact they are communicating with IPv4
correspondents. This may result in a mismatch in IP protocol version
for protocols that embed IP addresses.
5.2. Advantages
There are several advantages. An important one is that NAT issues
only come up when the host is communicating towards IPv4 addresses.
As such, it's trivial for applications to limit NAT workaround code
to sessions towards IPv4 destinations and assume global
addressability for IPv6 destinations. Since there is no DNS ALG, and
if there is one, it inserts the EDNS0 "poison pill" in any records
that contain synthetic AAAA records, there are no issues with
possible leakage of synthetic AAAA records as soon as the EDNS0
option is widely supported and/or DNS ALGs are no longer used. Both
IPv4 applications that use IPv4 socket calls and IPv6 applications
that use IPv6 socket calls with IPv4-mapped IPv6 addresses can work
over MNAT-PT. Alternatively, light-weight implementations may omit
all IPv4 code, except perhaps the ability to perform A record
lookups.
5.3. Advantages over providing real NATed IPv4 connectivity
An obvious way to enjoy many of the same benefits would be to build a
network that supports both IPv6 and IPv4 with NATed connectivity.
However, this means that there must be an IPv4 network infrastructure
in place in the form of IPv4 routers and IPv4 address provisioning
(DHCP). Today, this is easy to do in smaller installations if there
is a single public IPv4 address available. However, in larger
networks the planning of private IPv4 addressing can become
cumbersome, and when IPv4 addresses are scarce, it may be unavoidable
van Beijnum & Carpenter Expires August 15, 2008 [Page 15]
Internet-Draft Modified NAT-PT February 2008
to implement multiple levels of NAT. Multiple levels of NAT at the
very least impose the limits of the most restrictive NAT, and also
make hole punching that is used to be able to receive incoming
connections much harder as a single set of port numbers must be
shared by a larger number of hosts. NAT traversal technologies may
or may not support multiple layers of NAT.
With MNAT-PT, it's only necessary to provision IPv6 connectivity and
addressing, which is easier to plan for because unlike IPv4, a
standard /64 IPv6 subnet supports arbitrary numbers of hosts. The
translation device that performs NAT and the hosts making use of the
MNAT-PT service can be located with few topological constraints, so
multiple layers of NAT are much easier to avoid. Additionally, the
only state that must be kept by the translator is that inherent to
NAT operation, there is no need to maintain IPv4 addressing, allowing
for easier scalability of the solution.
6. Evaluation of RFC4966 concerns
This section provides an overview of the issues raised in [RFC4966]
and how they apply to the use of modified NAT-PT with modifications
on the IPv6 side.
6.1. Issues with Lack of Address Persistence
To-be-translated IPv4 destination addresses map to the same IPv6
destination address until the host selects a different /96 prefix.
However, if addresses are stored in their IPv4 form, this doesn't
lead to broken referrals. Issues with mapping persistence from the
IPv4 side to the IPv6 side are the same as with regular NAT and can
be solved in the same way: by having the application or OS set up a
persistent mapping that allows incoming connections.
6.2. DoS Attacks on Memory and Address/Port Pools
Denial-of-service issues are mostly the same as with regular NAT.
When a non-anycast translator is used, it's likely that
authentication through a control connection is required, allowing for
easy rejection of to-be-translated traffic coming from addresses that
don't have an active control connection. However, unless the IPv6
source host and the translator are prepared to set up an IPsec
tunnel, there is no way to reject to-be-translated traffic which
spoofs the source address of a host with an active control
connection. If the source host uses an IPv6 source address for this
communication that it doesn't use for other types of communication,
only on-path attackers or hosts on the same subnet have easy
knowledge of the source address in question.
van Beijnum & Carpenter Expires August 15, 2008 [Page 16]
Internet-Draft Modified NAT-PT February 2008
6.3. Issues Directly Related to Use of DNS-ALG
Fixed definitively.
6.4. Impact on IPv6 Application Development
Applications see regular IPv4 destination addresses for to-be-
translated destinations so they can engage IP version specific code
paths as required. The presence of the [RFC1918] synthetic source
address makes it possible for applications to use NAT workarounds for
to-be-translated destinations. The extra work the application needs
to do here is the same as it would when running on a dual stack host.
Alternatively, TCP/IP stacks may forego implementing the synthetic
IPv4 source address and/or applications may choose to remain ignorant
of whether they're communicating with an IPv4 or IPv6 correspondent.
In those cases, address-based referrals are likely to break for IPv4
destinations unless the MNAT-PT translator employs an Application
Layer Gateway for the protocol that's used.
7. Acknowledgments
This document has benefited from ideas from Marcelo Bagnulo and Alain
Durand. Readers are encouraged to also review
[I-D.carpenter-shanti], [I-D.durand-v6ops-natv4v6v4] and
[I-D.bagnulo-v6ops-6man-nat64-pb-statement].
8. IANA considerations
IANA is requested to allocate an IPv6 anycast /96 prefix TBD1 for the
location of a default MNAT-PT device.
IANA is requested to allocate an EDNS0 option and a DHCP option, both
TBD, and a BGP well-known community "TRANSLATEV6".
9. Security considerations
Security considerations need to be expanded in a revision of this
document. However, generically, MNAT-PT does not appear to introduce
any specific new attack vectors, although it does nothing to prevent
spoofing or DOS attacks. As a potential single point of failure that
stores per-flow state, it is intrinsically vulnerable to simple DOS.
Like any address translator, MNAT-PT is unfriendly to IPsec.
van Beijnum & Carpenter Expires August 15, 2008 [Page 17]
Internet-Draft Modified NAT-PT February 2008
The use of synthetic AAAA records is incompatible with DNSSEC; hosts
implementing both MNAT-PT and DNSSEC MUST therefore perform A lookups
themselves.
In the past, security issues have been identified with the use of
IPv4-mapped IPv6 addresses. If these addresses were to appear on the
wire, neither IPv4 nor IPv6 filters would recognize them as packets
associated with IPv4 operation, possibly allowing the bypassing of
access restrictions. The current proposal suggests that such
addresses should not appear on the wire (or on the wireless).
Implementers should take care to avoid having mechanisms that
restrict access based on IPv4 addresses without also taking into
account various translation mechanisms.
The malicious insertion of the TRANSLATEV6 BGP community by an
intermediate AS will lead to routing of an address block towards a
translator, making that address block unreachable. However,
intermediate ASes have many options to disrupt the flow of IP
traffic, and as such, this doesn't add to existing capabilities.
10. References
10.1. Normative References
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
E. Lear, "Address Allocation for Private Internets",
BCP 5, RFC 1918, February 1996.
[RFC2694] Srisuresh, P., Tsirtsis, G., Akkiraju, P., and A.
Heffernan, "DNS extensions to Network Address Translators
(DNS_ALG)", RFC 2694, September 1999.
[RFC2765] Nordmark, E., "Stateless IP/ICMP Translation Algorithm
(SIIT)", RFC 2765, February 2000.
[RFC2766] Tsirtsis, G. and P. Srisuresh, "Network Address
Translation - Protocol Translation (NAT-PT)", RFC 2766,
February 2000.
[RFC4966] Aoun, C. and E. Davies, "Reasons to Move the Network
Address Translator - Protocol Translator (NAT-PT) to
Historic Status", RFC 4966, July 2007.
[RFC3484] Draves, R., "Default Address Selection for Internet
Protocol version 6 (IPv6)", RFC 3484, February 2003.
van Beijnum & Carpenter Expires August 15, 2008 [Page 18]
Internet-Draft Modified NAT-PT February 2008
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
specifying the location of services (DNS SRV)", RFC 2782,
February 2000.
[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)",
RFC 2671, August 1999.
[RFC1997] Chandrasekeran, R., Traina, P., and T. Li, "BGP
Communities Attribute", RFC 1997, August 1996.
10.2. Informative References
[I-D.ietf-shim6-proto]
Bagnulo, M. and E. Nordmark, "Shim6: Level 3 Multihoming
Shim Protocol for IPv6", draft-ietf-shim6-proto-09 (work
in progress), November 2007.
[I-D.woodyatt-ald]
Woodyatt, J., "Application Listener Discovery (ALD) for
IPv6", draft-woodyatt-ald-02 (work in progress),
December 2007.
[I-D.carpenter-shanti]
Carpenter, B., "Shimmed IPv4/IPv6 Address Network
Translation Interface (SHANTI)", draft-carpenter-shanti-01
(work in progress), November 2007.
[I-D.durand-v6ops-natv4v6v4]
Durand, A., "Non dual-stack IPv6 deployments for broadband
providers", draft-durand-v6ops-natv4v6v4-00 (work in
progress), November 2007.
[I-D.bagnulo-v6ops-6man-nat64-pb-statement]
Bagnulo, M., "IPv6 - IPv4 Translators (NAT64) - Problem
Statement and Analysis",
draft-bagnulo-v6ops-6man-nat64-pb-statement-00 (work in
progress), November 2007.
Appendix A. Document and discussion information
Revision history:
o Version 00: initial version
o Version 01: added mechanisms that require changes at the IPv4 side
van Beijnum & Carpenter Expires August 15, 2008 [Page 19]
Internet-Draft Modified NAT-PT February 2008
o Version 02: added support for incoming sessions from IPv4-only to
IPv6-only host and IPv4-IPv6-IPv4 translation, removed mechanisms
that require changes at the IPv4 side to avoid confusion
o Version 00: added in material from SHANTI, added co-author,
clarifications throughout, new name, removed IPv4-IPv6-IPv4
operation and control connection text; this may be addressed in a
separate document later
The latest version of this document will always be available at
http://www.muada.com/drafts/. Please direct questions and comments
to the v6ops mailinglist or directly to the authors.
Authors' Addresses
Iljitsch van Beijnum
IMDEA Networks
Av. Universidad 30
Leganes, Madrid 28911
ES
Phone: +34-91-6246245
Email: iljitsch@muada.com
Brian Carpenter
Department of Computer Science
University of Auckland
PB 92019
Auckland, 1142
New Zealand
Email: brian.e.carpenter@gmail.com
van Beijnum & Carpenter Expires August 15, 2008 [Page 20]
Internet-Draft Modified NAT-PT February 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
van Beijnum & Carpenter Expires August 15, 2008 [Page 21]