One document matched: draft-ietf-behave-v6v4-xlate-stateful-05.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc compact='yes'?>
<?rfc subcompact='no'?>
<?rfc symrefs="yes"?>
<?rfc tocdepth="6"?>
<rfc category="std" docName="draft-ietf-behave-v6v4-xlate-stateful-05" ipr="pre5378Trust200902">
<front>
<title abbrev="NAT64">NAT64: Network Address and Protocol
Translation from IPv6 Clients to IPv4 Servers</title>
<author fullname="Marcelo Bagnulo" initials="M." surname="Bagnulo">
<organization>UC3M</organization>
<address>
<postal>
<street>Av. Universidad 30</street>
<city>Leganes</city>
<region>Madrid</region>
<code>28911</code>
<country>Spain</country>
</postal>
<phone>+34-91-6249500</phone>
<facsimile></facsimile>
<email>marcelo@it.uc3m.es</email>
<uri>http://www.it.uc3m.es/marcelo</uri>
</address>
</author>
<author fullname="Philip Matthews" initials="P." surname="Matthews">
<organization abbrev="Alcatel-Lucent">Alcatel-Lucent</organization>
<address>
<postal>
<street> 600 March Road</street>
<city>Ottawa</city>
<region>Ontario</region>
<code></code>
<country>Canada</country>
</postal>
<phone>+1 613-592-4343 x224</phone>
<facsimile></facsimile>
<email>philip_matthews@magma.ca</email>
<uri></uri>
</address>
</author>
<author initials="I" surname="van Beijnum" fullname="Iljitsch van Beijnum">
<organization>IMDEA Networks</organization>
<address>
<postal>
<street>Avda. del Mar Mediterraneo, 22</street>
<city>Leganes</city>
<region>Madrid</region>
<code>28918</code>
<country>Spain</country>
</postal>
<email>iljitsch@muada.com</email>
</address>
</author>
<date year="2009" />
<area>Transport</area>
<workgroup>BEHAVE WG</workgroup>
<keyword>NAT64</keyword>
<keyword>IPv6</keyword>
<abstract>
<t>NAT64 is a mechanism for translating IPv6 packets to IPv4 packets and
vice-versa. DNS64 is a mechanism for synthesizing AAAA records from A
records. These two mechanisms together enable client-server
communication between an IPv6-only client and an IPv4-only server, without
requiring any changes to either the IPv6 or the IPv4 node, for the class of
applications that work through NATs. They also enable peer-to-peer
communication between an IPv4 and an IPv6 node, where the communication can be
initiated by either end using existing, NAT-traversing, peer-to-peer
communication techniques. NAT64 also support IPv4 initiated communications to a subset
of the IPv6 hosts through statically configured bindings in the NAT64.
This document specifies NAT64, and
gives suggestions on how it should be deployed.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>This document specifies NAT64, a mechanism for IPv6-IPv4
transition and co-existence. Together with DNS64
<xref target="I-D.ietf-behave-dns64"></xref>, these two mechanisms allow a
IPv6-only client to initiate communications to an IPv4-only server,
They also enable peer-to-peer
communication between an IPv4 and an IPv6 node, where the communication can be
initiated by either end using existing, NAT-traversing, peer-to-peer
communication techniques. NAT64 also support IPv4 initiated communications to a subset
of the IPv6 hosts through statically configured bindings in the NAT64.</t>
<t>NAT64 is a mechanism for translating IPv6 packets to IPv4 packets and vice-versa.
The translation is done by translating the packet headers according
to IP/ICMP Translation Algorithm <xref target="I-D.ietf-behave-v6v4-xlate"></xref>, translating the IPv4 server
address by adding or removing an IPv6 prefix, and translating the IPv6
client address by installing mappings in the normal NAT manner. </t>
<t>DNS64 is a mechanism for synthesizing AAAA resource records (RR)
from A RR. The synthesis is done by adding a IPv6 prefix to the IPv4
address to create an IPv6 address, where the IPv6 prefix is assigned
to a NAT64 device.</t>
<t>Together, these two mechanisms allow a IPv6-only client to initiate
communications to an IPv4-only server.</t>
<t>These mechanisms are expected to play a critical role in the
IPv4-IPv6 transition and co-existence. Due to IPv4 address depletion,
it's likely that in the future, a lot of IPv6-only clients will want
to connect to IPv4-only servers. The NAT64 and DNS64 mechanisms are
easily deployable, since they require no changes to either the IPv6 client
nor the IPv4 server. For basic functionality, the approach only requires
the deployment of NAT64 function in the devices connecting an IPv6-only network to
the IPv4-only network, along with the deployment of a few DNS64-enabled
name servers in the IPv6-only network. However, some advanced features
such as support for DNSSEC validating stub resolvers or support for some
IPsec modes, require software updates to the IPv6-only hosts.
</t>
<t>The NAT64 and DNS64 mechanisms are related to the NAT-PT mechanism
defined in <xref target="RFC2766"></xref>, but significant differences
exist. First, NAT64 does not define the NATPT mechanisms used to support
the general case of IPv6 only servers to be contacted by IPv4 only clients, but only
defines the mechanisms for IPv6 clients to contact IPv4 servers and its
potential reuse to support peer to peer communications through standard
NAT traversal techniques. Second, NAT64 includes a set of
features that overcomes many of the reasons the original NAT-PT
specification was moved to historic status <xref
target="RFC4966"></xref>. </t>
<section title="Features of NAT64">
<t>The features of NAT64 are:<list style="symbols">
<t> NAT64 as specified in this document is compliant with the
recommendations for how NATs should handle UDP <xref
target="RFC4787"></xref>, TCP <xref target="RFC5382"></xref>, and ICMP
<xref target="RFC5508"></xref>. As such, NAT64 only supports Endpoint-Independent mappings
and supports both Endpoint-Independent and Address dependent filtering.
Because of the compliance with the aforementioned requirements, NAT64 is compatible
with ICE <xref target="I-D.ietf-mmusic-ice"></xref>.</t>
<t>In the absence of any state in NAT64 regarding a given IPv6
node, only said IPv6 node can initiate sessions to IPv4 nodes.
This works for roughly the same class of applications that work
through IPv4-to-IPv4 NATs.</t>
<t>Depending on the filtering policy used (Endpoint-Independent,
or Address-Dependent), IPv4-nodes MAY be able
to initiate sessions to a given IPv6 node, if the NAT64 somehow has an
appropriate mapping (i.e.,state) for said IPv6 node, via one of the
following mechanism.
<list>
<t> The IPv6 node has recently initiated a session to the
same or other external-IPv4 node.</t>
<t> The IPv6 node has used a NAT-traversal technique (such as ICE)
which essentially results in the previous bullet point.</t>
<t> If static configuration (i.e. mapping) exists
regarding said IPv6 node</t>
</list></t>
</list></t>
</section>
<section title="Overview">
<t>This section provides a non-normative introduction to the mechanisms
of NAT64. This is achieved by describing the NAT64 behavior involving a simple
setup, that involves a single NAT64 box, a single DNS64 box and a simple
network topology. The goal of this description is to provide the reader with
a general view of NAT64. It is not the goal of this
section to describe all possible configurations nor to provide a normative
specification of the NAT64 behavior. The normative specification of NAT64
is provided in <xref target="normative"/>.</t>
<t>NAT64 mechanism is implemented in an NAT64 box which has (at least) two
interfaces, an IPv4 interface connected to the the IPv4 network, and an
IPv6 interface connected to the IPv6 network. Packets generated in the
IPv6 network for a receiver located in the IPv4 network will be routed
within the IPv6 network towards the NAT64 box. The NAT64 box will
translate them and forward them as IPv4 packets through the IPv4 network
to the IPv4 receiver. The reverse takes place for packets generated in
the IPv4 network for an IPv6 receiver. NAT64, however, is not symmetric.
In order to be able to perform IPv6 - IPv4 translation NAT64 requires state,
binding an IPv6 address and port (hereafter called an IPv6 transport address)
to an IPv4 address and port (hereafter called an IPv4 transport address).</t>
<t>Such binding state is either statically configured in the NAT64 or it is
created when the first packet flowing from the
IPv6 network to the IPv4 network is translated. After the binding state
has been created,
packets flowing in either direction on that particular
flow are translated. The result is that, in the general case, NAT64 only supports
communications initiated by the IPv6-only node towards an IPv4-only
node. Some additional mechanisms (like ICE) or static binding configuration, can be used
to provide support for communications initiated by the
IPv4-only node to the IPv6-only node. </t>
<section title="NAT64 solution elements">
<t>In this section we describe the different elements involved in the
NAT64 approach.</t>
<t>The main component of the proposed solution is the translator
itself. The translator has essentially two main parts, the address
translation mechanism and the protocol translation mechanism.</t>
<t>Protocol translation from IPv4 packet header to IPv6 packet header
and vice-versa is performed according to <xref
target="I-D.ietf-behave-v6v4-xlate">IP/ICMP Translation Algorithm</xref>.</t>
<t>Address translation maps IPv6 transport addresses to IPv4 transport
addresses and vice-versa. In order to create these mappings the NAT64
box has two pools of addresses i.e. an IPv6 address pool (to represent
IPv4 addresses in the IPv6 network) and an IPv4 address pool (to
represent IPv6 addresses in the IPv4 network). </t>
<t>The IPv6 address pool is an IPv6 prefix assigned to the translator
itself (hereafter called Pref64::/n). Due to the abundance of IPv6 address space,
it is possible to assign an Pref64::/n that is equal or even bigger than the whole IPv4 address space. This allows
each IPv4 address to be mapped into a different IPv6 address by simply
concatenating the Pref64::/n with the IPv4 address being mapped and a suffix (i.e. an IPv4 address X is
mapped into the IPv6 address Pref64:X:SUFFIX). The provisioning of the Pref64::/n is
discussed at length in <xref target="I-D.ietf-behave-address-format" /> </t>
<!-- It should be noted that the the prefix used as
the IPv6 address pool is assigned to a specific NAT64 box and if there
are multiple NAT64 boxes, each box is allocated a different prefix.
Assigning the same prefix to multiple boxes may lead to communication
failures due to internal routing fluctuations. -->
<t>The IPv4 address pool is a set of IPv4 addresses,
normally a small prefix assigned by the local administrator. Since IPv4
address space is a scarce resource, the IPv4 address pool is small and
typically not sufficient to establish permanent one-to-one mappings with IPv6
addresses. So, except for the static/manually created ones,
mappings using the IPv4 address pool will be created
and released dynamically. Moreover, because of the IPv4 address
scarcity, the usual practice for NAT64 is likely to be the mapping of
IPv6 transport addresses into IPv4 transport addresses, instead of
IPv6 addresses into IPv4 addresses directly, which enable a higher
utilization of the limited IPv4 address pool.</t>
<t>Because of the dynamic nature of the IPv6 to IPv4 address mapping
and the static nature of the IPv4 to IPv6 address mapping, it is easy
to understand that it is far simpler to allow communication initiated
from the IPv6 side toward an IPv4 node, which address is algorithmically
mapped into an IPv6 address, than communications initiated from
IPv4-only nodes to an IPv6 node in which case IPv4 address needs to be
associated with it dynamically.</t>
<t>An IPv6 initiator can know or derive in advance the IPv6 address
representing the IPv4 target and send packets to that address. The
packets are intercepted by the NAT64 device, which associates an IPv4 transport
address of its IPv4 pool to the IPv6 transport address of the
initiator, creating binding state, so that reply packets can be
translated and forwarded back to the initiator. The binding state is
kept while packets are flowing. Once the flow stops, and based on a
timer, the IPv4 transport address is returned to the IPv4 address pool
so that it can be reused for other communications.</t>
<t>To allow an IPv6 initiator to do the standard DNS lookup to learn
the address of the responder, DNS64 <xref target="I-D.ietf-behave-dns64"></xref>
is used to synthesize an AAAA RR from the A
RR (containing the real IPv4 address of the responder). DNS64
receives the DNS queries generated by the IPv6 initiator. If there is
no AAAA record available for the target node (which is the normal case
when the target node is an IPv4-only node), DNS64 performs a query for
the A record. If an A record is returned, DNS64 creates a synthetic
AAAA RR that includes the IPv6 representations of the IPv4 address
created by concatenating the Pref64::/n of a NAT64 to the responder's IPv4
address and a suffix (i.e. if the IPv4 node has IPv4 address X, then the synthetic
AAAA RR will contain the IPv6 address formed as Pref64:X:SUFFIX). The
synthetic AAAA RR is passed back to the IPv6 initiator, which will
initiate an IPv6 communication with the IPv6 address associated to the
IPv4 receiver. The packet will be routed to the NAT64 device, which
will create the IPv6 to IPv4 address mapping as described before.</t>
</section>
<section title="NAT64 Behaviour Walkthrough">
<t>In this example, we consider an IPv6 node located in a IPv6-only
site that initiates a communication to a IPv4 node located in the IPv4
network.</t>
<t>The notation used is the following: upper case letters are IPv4
addresses; upper case letters with a prime(') are IPv6 addresses; lower
case letters are ports; prefixes of length n are indicated by "P::/n", an
IPv6 address built from an IPv4 address X by adding the prefix P and a
suffix SUFFIX is indicated as "P:X:SUFFIX"", mappings
are indicated as "(X,x) <--> (Y',y)".</t>
<t>The scenario for this case is depicted in the following figure:</t>
<figure>
<preamble></preamble>
<artwork align="center">
+---------------------------------------+ +---------------+
|IPv6 network +-------------+ | | |
| +----+ | Name server | +-------+ | IPv4 |
| | H1 | | with DNS64 | | NAT64 |----| Network |
| +----+ +-------------+ +-------+ | |
| |IP addr: Y' | | | | IP addr: X |
| --------------------------------- | | +----+ |
+---------------------------------------+ | | H2 | |
| +----+ |
+---------------+
</artwork>
<postamble></postamble>
</figure>
<t>The figure shows a IPv6 node H1 which has an IPv6 address Y' and an
IPv4 node H2 with IPv4 address X.</t>
<t>A NAT64 connects the IPv6 network to the IPv4 network. This NAT64 has
a /n prefix (called Pref64::/n) that it uses to represent IPv4 addresses in
the IPv6 address space and a single IPv4 address T assigned to its IPv4 interface.
The routing is configured in such a way, that the IPv6 packets addressed
to a destination address containing Pref64::/n are routed to the IPv6
interface of the NAT64 box. </t>
<t>Also shown is a local name server with DNS64 functionality. The local
name server needs to know the /n prefix assigned to the
local NAT64 (Pref64::/n). For the purpose of this example, we assume
it learns this through manual configuration.</t>
<t>For this example, assume the typical DNS situation where IPv6 hosts
have only stub resolvers and the local name server does the recursive
lookups.</t>
<t>The steps by which H1 establishes communication with H2 are: <list
style="numbers">
<t>H1 performs a DNS query for FQDN(H2) and receives the synthetic
AAAA RR from the local name server that implements the
DNS64 functionality. The AAAA record contains an IPv6 address formed
by the Pref64::/n associated to the NAT64 box and
the IPv4 address of H2 and a suffix (i.e. Pref64:X:SUFFIX).</t>
<t>H1 sends a packet
to H2. The packet is sent from a source transport address of
(Y',y) to a destination transport address of (Pref64:X:SUFFIX,x), where y
and x are ports set by H1.</t>
<t>The packet is routed to the IPv6 interface of the NAT64 (since
the IPv6 routing is configured that way).</t>
<t>The NAT64 receives the packet and performs the following
actions: <list style="symbols">
<t>The NAT64 selects an unused port t on its IPv4 address T
and creates the mapping entry (Y',y) <--> (T,t)</t>
<t>The NAT64 translates the IPv6 header into an IPv4 header
using IP/ICMP Translation Algorithm <xref target="I-D.ietf-behave-v6v4-xlate"></xref>.</t>
<t>The NAT64 includes (T,t) as source transport address in the
packet and (X,x) as destination transport address in the
packet. Note that X is extracted directly from the destination
IPv6 address of the received IPv6
packet that is being translated.</t>
</list></t>
<t>The NAT64 sends the translated packet out its IPv4
interface and the packet arrives at H2.</t>
<t>H2 node responds by sending a packet with destination transport
address (T,t) and source transport address (X,x).</t>
<t>The packet is routed to the NAT64 box, which will look for an
existing mapping containing (T,t). Since the mapping (Y',y)
<--> (T,t) exists, the NAT64 performs the following
operations: <list style="symbols">
<t>The NAT64 translates the IPv4 header into an IPv6 header
using IP/ICMP Translation Algorithm <xref target="I-D.ietf-behave-v6v4-xlate"></xref>.</t>
<t>The NAT64 includes (Y',y) as destination transport address in
the packet and (Pref64:X:SUFFIX,x) as source transport address
in the packet. Note that X is extracted directly from the
source IPv4 address of the received IPv4 packet that is being
translated.</t>
</list></t>
<t>The translated packet is sent out the IPv6 interface to
H1.</t>
</list></t>
<t>The packet exchange between H1 and H2 continues and packets are
translated in the different directions as previously
described.</t>
<t>It is important to note that the translation still works if the
IPv6 initiator H1 learns the IPv6 representation of H2's IPv4
address (i.e. Pref64:X:SUFFIX) through some scheme other than a DNS look-up.
This is because the DNS64 processing does NOT
result in any state installed in the NAT64 box and because the mapping
of the IPv4 address into an IPv6 address is the result of
concatenating the prefix defined within the site for this purpose
(called Pref64::/n in this document) to the original IPv4
address and a suffix.</t>
</section>
<section title="Filtering">
<t>A NAT64 box may do filtering, which means that it only allows a
packet in through an interface if the appropriate permission exists. A
NAT64 may do no filtering, or it may filter incoming IPv4 packets.
Filtering of incoming IPv6 packets is not described in this specification.</t>
<t>NAT64 filtering is consistent with the recommendations of RFC
4787 <xref target="RFC4787"></xref>, and the ones of
RFC 5382 <xref target="RFC5382"></xref>. Because of that, the NAT64
as specified in this document, supports both Endpoint-Independent filtering
and Address-Dependent filtering, both for TCP and UDP.</t>
<t>If a NAT64 performs Endpoint-Independent filtering of incoming IPv4 packets,
then an incoming IPv4 packet is dropped unless the NAT64 has state for the
destination transport address of the incoming IPv4 packet.</t>
<t>
If a NAT64 performs Address-Dependent filtering of incoming IPv4 packets, then an incoming IPv4 packet is dropped
unless the NAT64 has state involving the destination transport address of the IPv4 incoming packet
and the particular source IP address of the incoming IPv4 packet.</t>
</section>
</section>
</section>
<section title="Terminology">
<t>This section provides a definitive reference for all the terms used
in document. </t>
<t>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 <xref
target="RFC2119">RFC 2119</xref>.</t>
<t>The following terms are used in this document:</t>
<t><list style="hanging">
<t hangText="3-Tuple:"> The tuple (source IP address, destination
IP address, Query Identifier). A 3-tuple uniquely identifies an
ICMP Query session. When an ICMP Query session flows through
a NAT64, each session has two different 3-tuples: one with IPv4
addresses and one with IPv6 addresses. </t>
<t hangText="5-Tuple:">The tuple (source IP address, source port,
destination IP address, destination port, transport protocol). A
5-tuple uniquely identifies a UDP/TCP session. When a UDP/TCP session flows through
a NAT64, each session has two different 5-tuples: one with IPv4
addresses and one with IPv6 addresses. </t>
<t hangText="BIB:">Binding Information Base. A table of mappings kept
by a NAT64. Each NAT64 has three BIBs, one for TCP, one for
UDP and one for ICMP Queries.</t>
<t hangText="DNS64:">A logical function that synthesizes AAAA Resource Records
(containing IPv6 addresses) from A Resource Records (containing IPv4
addresses).</t>
<t hangText="Endpoint-Independent Mapping:">In NAT64, using the same
mapping for all the sessions involving a given IPv6 transport address
of an IPv6 host (irrespectively of the transport address of the IPv4
host involved in the communication).
Endpoint-independent mapping is
important for peer-to-peer communication. See <xref
target="RFC4787"></xref> for the definition of the different types
of mappings in IPv4-to-IPv4 NATs.</t>
<t hangText="Filtering, Endpoint-Independent:"> The NAT64 filters out
only incoming IPv4 packets not destined to a transport address for
which there is not state in the NAT64, regardless of the source
IPv4 transport address. The NAT forwards any packets destined to
any transport address for which it has state.
In other words, having state for a given transport address is sufficient
to allow any packets back to the internal endpoint. See <xref
target="RFC4787"></xref> for the definition of the different types
of filtering in IPv4-to-IPv4 NATs.</t>
<t hangText="Filtering, Address-Dependent:">
The NAT64 filters out incoming IPv4 packets not destined to a transport
address for which there is no state (similar to the Endpoint-Independent
filtering). Additionally, the NAT64 will filter out incoming
IPv4 packets coming from IPv4 address X and
destined for a transport address that it has state for if the NAT64 has not
sent packets to X previously (independently of the port
used by X).
In other words, for receiving packets from a
specific IPv4 endpoint, it is necessary for the IPv6
endpoint to send packets first to that specific IPv4
endpoint's IP address.</t>
<t hangText="Hairpinning:">Having a packet do a "U-turn" inside a NAT
and come back out the same interface as it arrived on. Hairpinning
support is important for peer-to-peer applications, as there are
cases when two different hosts on the same side of a NAT can only
communicate using sessions that hairpin through the NAT.</t>
<t hangText="Mapping or Binding:">A mapping between an IPv6 transport address and a
IPv4 transport address. Used to translate the addresses and ports
of packets flowing between the IPv6 host and the IPv4 host.
In NAT64, the IPv4 transport address is always
a transport address assigned to the NAT64 itself, while the IPv6
transport address belongs to some IPv6 host.</t>
<t hangText="NAT64:">A device that translates IPv6 packets to IPv4
packets and vice-versa. The NAT64 uses mapping state to
perform the translation between IPv6 and IPv4 addresses. The translation involves not only the
IP header, but also the transport header (TCP or UDP).</t>
<t hangText="Session:">A TCP, UDP or ICMP Query session. In other words, the
bi-directional flow of packets between two different
hosts. In NAT64, typically one host is an IPv4 host, and the
other one is an IPv6 host.</t>
<t hangText="Session table:">A table of sessions kept by a NAT64.
Each NAT64 has three session tables, one for TCP, one for UDP and one for ICMP Queries.</t>
<t hangText="Synthetic RR:">A DNS Resource Record (RR) that is not
contained in any zone data file, but has been synthesized from other
RRs. An example is a synthetic AAAA record created from an A
record.</t>
<t hangText="Transport Address:">The combination of an IPv6 or IPv4
address and a port. Typically written as (IP address, port); e.g.
(192.0.2.15, 8001).</t>
<t hangText="Tuple:">Refers to either a 3-Tuple or a 5-tuple as defined above.</t>
</list></t>
<t>For a detailed understanding of this document, the reader should also be
familiar with DNS terminology <xref target="RFC1035"></xref> and current
NAT terminology <xref target="RFC4787"></xref>.</t>
</section>
<section anchor="normative" title="NAT64 Normative Specification">
<t>A NAT64 is a device with at least one IPv6 interface and at least one IPv4 interface.
Each NAT64 device MUST have one unicast /n IPv6 prefix assigned to it,
denoted Pref64::/n (Additional consideration about the Pref64::/n are presented in
<xref target="address-transform"></xref>). Each NAT64 box MUST have one or more unicast
IPv4 addresses assigned to it. </t>
<t>A NAT64 uses the following dynamic data structures:<list
style="symbols">
<t>UDP Binding Information Base</t>
<t>UDP Session Table</t>
<t>TCP Binding Information Base</t>
<t>TCP Session Table</t>
<t>ICMP Query Binding Information Base</t>
<t>ICMP Query Session Table</t>
</list></t>
<t>These tables contain information needed for the NAT64 processing. The actual
division of the information into six tables is done in order to ease the
description of the NAT64 behaviour. NAT64 implementations MAY use different data structures
as long as they store all the required information and the externally
visible outcome is the same as the one described in this document.</t>
<t>A NAT64 has three Binding Information Bases (BIBs): one for TCP, one for
UDP and one for ICMP Queries. In the case of UDP and TCP BIBs, each
BIB entry specifies a mapping between an IPv6 transport address
and an IPv4 transport address:<list>
<t>(X',x) <--> (T,t)</t>
</list>where X' is some IPv6 address, T is an IPv4 address, and x and t
are ports. T will always be one of the IPv4 addresses assigned to the NAT64.
The BIB has then two columns, the BIB IPv6 transport address and the BIB IPv4 transport address.
A given IPv6 or IPv4 transport address can appear
in at most one entry in a BIB: for example, (2001:db8::17, 4) can
appear in at most one TCP and at most one UDP BIB entry. TCP and UDP
have separate BIBs because the port number space for TCP and UDP are
distinct. This implementation of the BIBs ensures Endpoint-Independent mappings in the NAT64.
The information in the BIBs is also used to implement Endpoint-Independent filtering.
(Address-Dependent filtering is implemented using the Session tables described below.)</t>
<t>In the case of the ICMP Query BIB, each ICMP Query BIB entry specify a
mapping between an (IPv6 address, IPv6 Identifier)
pair and an (IPv4 address, IPv4 Identifier) pair.
<list>
<t>(X',I1) <--> (T,I2)</t>
</list>
where X' is some IPv6 address, T is an IPv4 address, I1 is an ICMPv6 Identifier and I2
is an ICMPv4 Identifiers. T will always be one of the IPv4 addresses assigned to the NAT64.
A given (IPv6 or IPv4 address, IPv6 or IPv4 Identifier) pair can appear
in at most one entry in the ICMP Query BIB. </t>
<t>Entries in any of the three BIBs can be created dynamically as the result of the
flow of packets as described in the <xref target="sec-session-info"></xref>
but the can also be created manually by the system administrator. NAT64
implementations SHOULD support manually configured BIB entries for any of the three BIBs.
Dynamically-created entries are deleted from the corresponding BIB when the last session
associated to the BIB entry is removed from the session table.
Manually-configured BIB entries are not deleted when there is no corresponding
session table entry and can only be deleted by the administrator.</t>
<t>A NAT64 also has three session tables: one for TCP sessions, one
for UDP sessions and one for ICMP Query sessions. Each entry keeps information on the state of the
corresponding session.
In the TCP and UDP session tables, each entry specifies a mapping between a pair of IPv6 transport address
and a pair of IPv4 transport address:<list>
<t>(X',x),(Y',y) <--> (T,t),(Z,z)</t>
</list>where X' and Y' are IPv6 addresses, T and Z are IPv4 addresses, and x, y, z and t
are ports. T will always be one of the IPv4 addresses assigned to the NAT64.
Y' is always the IPv6 representation of the IPv4 address Z, so Y' is obtained
from Z using the algorithm applied by the NAT64 to create IPv6 representations of
IPv4 addresses. y will always be equal to z. </t>
<t>For each Session Table Entry (STE), there are then five columns:
<list>
<t>The STE source IPv6 transport address, (X',x) in the example above,</t>
<t>The STE destination IPv6 transport address, (Y',y) in the example above,</t>
<t>The STE source IPv4 transport address, (T,t) in the example above, and,</t>
<t>The STE destination IPv4 transport address, (Z,z) in the example above.</t>
<t>The STE lifetime.</t>
</list>
The terminology used for the session table entry columns is from the perspective
of an incoming IPv6 packet being translated into an outgoing IPv4 packet.</t>
<t>In the ICMP query session table, each entry specifies a mapping between a 3-tuple of IPv6 source address,
IPv6 destination address and ICMPv6 Query Id and a 3-tuple of IPv4 source address,
IPv4 destination address and ICMPv4 Query Id:<list>
<t>(X',Y',I1) <--> (T,Z,I2)</t>
</list>where X' and Y' are IPv6 addresses, T and Z are IPv4 addresses, I1 is an ICMPv6 Identifier and I2
is an ICMPv4 Identifier. T will always be one of the IPv4 addresses assigned to the NAT64.
Y' is always the IPv6 representation of the IPv4 address Z, so Y' is obtained
from Z using the algorithm applied by the NAT64 to create IPv6 representations of
IPv4 addresses.</t>
<t>For each Session Table Entry (STE), there are then six columns:
<list>
<t>The STE source IPv6 address, X' in the example above,</t>
<t>The STE destination IPv6 address, Y' in the example above,</t>
<t>The STE IPv6 Identifier, I1 in the example above,</t>
<t>The STE source IPv4 address, T in the example above,</t>
<t>The STE destination IPv4 address, Z in the example above, and,</t>
<t>The STE IPv4 Identifier, I2 in the example above.</t>
<t>The STE lifetime.</t>
</list></t>
<t>The NAT64 uses the session state information to determine when the
session is completed, and also uses session information for Address-Dependent
filtering. A session can be uniquely identified by either an incoming
tuple or an outgoing tuple.</t>
<t>For each TCP or UDP session, there is a corresponding BIB entry, uniquely
specified by either the source IPv6 transport address
(in the IPv6 --> IPv4 direction) or the destination IPv4 transport address (in the IPv4
--> IPv6 direction). For each ICMP Query session, there is a corresponding BIB entry, uniquely
specified by either the source IPv6 address and ICMPv6 Query Id
(in the IPv6 --> IPv4 direction) or the
destination IPv4 address and the ICMPv4 Query Id (in the IPv4
--> IPv6 direction). However, for all the BIBs, a single BIB entry can have multiple
corresponding sessions. When the last corresponding session is
deleted, if the BIB entry was dynamically created, the BIB entry is deleted.</t>
<t>The NAT64 will receive packets through its interfaces. These packets can be either IPv6
packets or IPv4 packets and they may carry TCP traffic, UDP traffic or ICMP traffic. The processing
of the packets will be described next. In the case that the processing is common to all the aforementioned
types of packets, we will refer to the packet as the incoming packet in general. In case that the processing
is specific to IPv6 packets, we will refer to the incoming IPv6 packet and similarly to the IPv4 packets.</t>
<t> The processing of an incoming
IP packet takes the following steps:<list style="numbers">
<t>Determining the incoming tuple</t>
<t>Filtering and updating binding and session information</t>
<t>Computing the outgoing tuple</t>
<t>Translating the packet</t>
<t>Handling hairpinning</t>
</list>The details of these steps are specified in the following
subsections.</t>
<t>This breakdown of the NAT64 behavior into processing steps is done
for ease of presentation. A NAT64 MAY perform the steps in a different
order, or MAY perform different steps, as long as the externally
visible outcome is the same.</t>
<section title="Determining the Incoming tuple">
<t>This step associates a incoming tuple with every incoming IP packet
for use in subsequent steps. In the case of TCP, UDP and ICMP error packets, the
tuple is a 5-tuple consisting of source IP address,
source port, destination IP address, destination port, transport
protocol. In case of ICMP Queries, the tuple is a 3-tuple consisting of
the source IP address, destination IP address and Query Identifier.</t>
<t>If the incoming IP packet contains a complete (un-fragmented) UDP
or TCP protocol packet, then the 5-tuple is computed by extracting
the appropriate fields from the packet.</t>
<t>If the incoming packet is an ICMP query message (i.e. an ICMPv4 Query message
or an ICMPv6 Informational message), the 3-tuple is the source IP address,
the destination IP address and the ICMP Query Identifier.</t>
<t>If the incoming IP packet contains a complete (un-fragmented)
ICMP error message, then the 5-tuple is computed by extracting the
appropriate fields from the IP packet embedded inside the ICMP
error message. However, the role of source and destination is swapped when
doing this: the embedded source IP address becomes the destination
IP address in the 5-tuple, the embedded source port becomes the
destination port in the 5-tuple, etc. If it is not possible to
determine the 5-tuple (perhaps because not enough of the embedded
packet is reproduced inside the ICMP message), then the incoming IP
packet is silently discarded.</t>
<t>If the incoming IP packet contains a fragment, then more
processing may be needed. This specification leaves open the exact
details of how a NAT64 handles incoming IP packets containing
fragments, and simply requires that the external behavior of the NAT64
is compliant with the following conditions:
<list>
<t>The NAT64 MUST handle fragments arriving out-of-order
conditioned to the following:
<list>
<t>The NAT64 MUST limit the amount of resources
devoted to the storage of fragmented packets
in order to protect from DoS attack. </t>
<t> As long as the NAT64 has available resources,
the NAT64 MUST allow the fragments to arrive
over a time interval. The time interval
MUST be configurable and the default value MUST
be of at least 10 seconds.</t>
<t> The NAT64 MAY require that the UDP, TCP, or ICMP header be
completely contained within the fragment that contains
OFFSET equal to zero.</t>
</list></t>
<t>A NAT64 MAY elect to queue the fragments as
they arrive and translate all fragments at the same time.
Alternatively, a NAT64 MAY translate the fragments as they arrive,
by storing information that allows it to compute the 5-tuple for
fragments other than the first. In the latter case, subsequent fragments
may arrive before the first.</t>
<t>Implementers of NAT64 should be aware that there are a number of
well-known attacks against IP fragmentation; see <xref
target="RFC1858"></xref> and <xref target="RFC3128"></xref>.
Implementers should also be aware of additional issues with
reassembling packets at high rates, described in <xref target="RFC4963"></xref>. </t>
</list></t>
</section>
<section anchor="sec-session-info"
title="Filtering and Updating Binding and Session Information">
<t>This step updates binding and session information stored in the
appropriate tables.
This step may also filter incoming packets, if desired.</t>
<t>Irrespectively of the transport protocol used, the NAT64 must silently discard
all incoming IPv6 packets containing a source address that contains the Pref64::/n.
This is required in order to prevent hairpinning loops as described in the Security
Considerations section. In addition, the NAT64 function will only process incoming
IPv6 packets that contain a destination address that contains Pref64::/n.
Likewise, the NAT64 function will only process incoming
IPv4 packets that contain a destination address that belong to the IPv4 pool assigned to the NAT64.</t>
<t>The details of this step depend on the protocol (UDP,
TCP or ICMP Query).</t>
<section title="UDP Session Handling">
<t>The state information stored for a UDP session in the UDP session table includes a timer that
tracks the remaining lifetime of the UDP session. When the timer
expires, the UDP session is deleted. If all the UDP sessions corresponding to a
UDP BIB entry are deleted, then the UDP BIB entry is also deleted (only applies to the case of dynamically created entries).</t>
<t>An IPv6 incoming packet with an incoming tuple with source transport address (X',x) and
destination transport address (Y',y) is processed as follows:
<list>
<t>The NAT64 searches
for a UDP BIB entry that contains an BIB IPv6 transport address that matches the IPv6 source transport address (X',x).
If such an entry does not exists, a new entry is created.
As BIB IPv6 transport address, the source IPv6 transport address of the packet (X',x) is included and
the BIB IPv4 transport address is set to (T,t) which is allocated using the rules defined in <xref target="transport address alloc"></xref>.
The result is a BIB entry as follows: (X',x) <--> (T,t).</t>
<t>The NAT64 searches for the session table entry
corresponding to the incoming 5-tuple. If no such entry is
found, a new entry is created.
The information included in the session table is as follows:
<list>
<t>The STE source IPv6 transport address is set to (X',x), the source IPv6 transport addresses contained in the received IPv6 packet,</t>
<t>The STE destination IPv6 transport address is set to (Y',y), the destination IPv6 transport addresses contained in the received IPv6 packet,</t>
<t>The STE source IPv4 transport address is extracted from the corresponding UDP BIB entry i.e. is set to (T,t),</t>
<t>The STE destination IPv4 transport is set to (Z(Y'),y), y being the same port as
the STE destination IPv6 transport address and Z(Y') being algorithmically generated from the IPv6
destination address (i.e. Y') using the reverse algorithm as specified in <xref target="address-transform"></xref> .</t>
</list>
The result is a Session table entry as follows: (X',x),(Y',y) <--> (T,t),(Z(Y'),y)</t>
<t>The NAT64 sets or resets the timer in the session table
entry to maximum session lifetime. By default, the maximum
session lifetime is 5 minutes. The packet is translated and forwarded as described in the following sections.</t>
</list></t>
<t>An IPv4 incoming packet, with an incoming tuple with source IPv4 transport address (Y,y) and
destination IPv4 transport address (X,x) is processed as follows:
<list>
<t>The NAT64 searches
for a UDP BIB entry that contains an BIB IPv4 transport address matches (Y,y) i.e. the IPv4 destination transport address in the incoming IPv4 packet.
If such an entry does not exists, the packet is dropped. An ICMP message MAY be sent to the
original sender of the packet, unless the discarded packet is
itself an ICMP message. The ICMP message, if sent, has a type
of 3 (Destination Unreachable).</t>
<t>If the NAT64
applies Address-Dependent filters on its IPv4 interface, then the NAT64 checks to see if
the incoming packet is allowed according to the
address-dependent filtering rule. To do this, it searches for
a session table entry with a STE source IPv4 transport address
equal to (X,x) (i.e. the destination IPv4 transport address in the incoming packet)
and STE destination IPv4 address
equal to Y (i.e. the source IPv4 address in the incoming packet).
If such an entry
is found (there may be more than one), packet processing
continues. Otherwise, the packet is discarded. If the packet
is discarded, then an ICMP message MAY be sent to the
original sender of the packet, unless the discarded packet is
itself an ICMP message. The ICMP message, if sent, has a type
of 3 (Destination Unreachable) and a code of 13 (Communication
Administratively Prohibited).</t>
<t>In case the packet is not discarded in the previous processing (either because the NAT64
is not filtering or because the packet is compliant with the Address-dependent filtering rule),
then the NAT64 searches for the session table entry
corresponding containing the STE source IPv4 transport address equal
to (X,x) and the STE destination IPv4 transport address equal to (Y,y). If no such entry is
found, a new entry is created.
In case a new UDP session table entry is created, it contains the following information:
<list>
<t>The STE source IPv6 transport address is extracted from the corresponding UDP BIB entry</t>
<t>The STE destination IPv6 transport address is set to (Z'(Y),y), y being the same port y than the destination IPv4
transport address and Z'(Y) being the
IPv6 representation of Y, generated using the
algorithm described in <xref target="address-transform"></xref></t>
<t>The STE source IPv4 transport address is set to (X,x) the destination IPv4 transport addresses contained in the received IPv4 packet,</t>
<t>The STE destination IPv4 transport is set to (Y,y), the source IPv4 transport addresses contained in the received IPv4 packet.</t>
</list></t>
<t>The NAT64 sets or resets the timer in the session table
entry to maximum session lifetime. By default, the maximum
session lifetime is 5 minutes.</t>
</list></t>
</section>
<section title="TCP Session Handling">
<t>The state information stored for a TCP session:
<list>
<t>Binding:(X',x),(Y',y) <--> (T,t),(Z,z)</t>
<t>Lifetime: is a timer that
tracks the remaining lifetime of the TCP session. When the timer
expires, the TCP session is deleted. If all the TCP sessions corresponding to a
TCP BIB entry are deleted, then the TCP BIB entry is also deleted (only applies to the case of dynamically created entries).</t>
</list></t>
<t>TCP sessions are expensive, because their inactivity lifetime is set to at least
2 hours and 4 min (as per <xref target="RFC5382"></xref>), so it is important that each TCP session table entry
corresponds to an existent TCP session. In order to do that, for each TCP session
established through it, it tracks the corresponding state machine as
follows.
</t>
<t>The states are the following ones:
<list>
<t>CLOSED: Analogous to <xref target="RFC0793"></xref>, CLOSED is a fictional state
because it represents the state when there is no state for this particular 5-tuple, and therefore,
no connection.</t>
<t>V4 SYN RCV: An IPv4 packet containing a TCP SYN was received by the NAT64, implying that a TCP connection is being initiated from the IPv4 side.
The NAT64 is now waiting for a matching IPv4 packet containing the TCP SYN in the opposite direction.</t>
<t>V6 SYN RCV: An IPv6 packet containing a TCP SYN was received by the NAT64, implying that a TCP connection is being initiated from the IPv6 side.
The NAT64 is now waiting for a matching IPv4 packet containing the TCP SYN in the opposite direction.</t>
<t>ESTABLISHED: Represent an open connection, with data flowing in both directions.</t>
<t>V4 FIN RCV: An IPv4 packet containing a TCP FIN was received by the NAT64, data can still flow in the connection,
the NAT64 is waiting for a matching TCP FIN in the opposite direction.</t>
<t>V6 FIN RCV: An IPv6 packet containing a TCP FIN was received by the NAT64, data can still flow in the connection,
the NAT64 is waiting for a matching TCP FIN in the opposite direction.</t>
<t>V6 FIN + V4 FIN RCV: Both an IPv4 packet containing a TCP FIN and an IPv6 packet containing an TCP FIN for
this connection were received by the NAT64. The NAT64 keeps the connection state alive and forwards packet
in both directions for a short period of time to allow remaining packets (in particular the ACKs) to be delivered.</t>
<t>RST RCV: A packet containing a TCP RST was received by the NAT64 for this connection. The NAT64 will keep the state
for the connection for a short time and if no other data packets for that connection are received, the assumption is that
the node has accepted the RST packet and the state for this connection is then terminated.</t>
</list></t>
<t>The state machine used by the NAT64 for the TCP session processing is depicted next.
The described state machine handles all TCP segments received through the IPv6 and IPv4 interface.
There is one state machine per TCP connection that is potentially established through the NAT64.
After bootstrapping of the NAT64 device, all TCP session are in CLOSED state. As we mention above,
the CLOSED state is a fictional state when is no state for that
particular connection in the NAT64. It should be noted that there is one state machine per connection, so only
packets belonging to a given connection are inputs to the state machine associated to that connection. In other words,
when in the state machine below we state that a packet is received, it is implicit that the incoming 5-tuple of the data packet
matches to the one of the state machine.</t>
<t> A TCP segment with the SYN flag set that is received through the IPv6 interface is
called a V6 SYN, similarly, V4 SYN, V4 FIN, V6 FIN, V6 FIN + V4 FIN, V6 RST and V4 RST.</t>
<figure>
<preamble></preamble>
<artwork align="center">
+----------------------------+ +-----------------------------+
| | | |
| V V |
| V6 +------+ V4 |
| +----SYN------|CLOSED|-----SYN------+ |
| | +------+ | |
| | ^ | |
| | |4min T.O. | |
| V | V |
| +-------+ +-------+ +-------+ |
| |V6 SYN | |RST RCV| |V4 SYN | |
| | RCV | +-------+ | RCV | |
| +-------+ | ^ +-------+ |
| | data pkt | | |
| | | V4 or V6 RST | |
2:04Hrs V4 SYN V | V6 SYN |
T.O. | +--------------+ | |
| +--------->| ESTABLISHED |<---------+ |
+--------------------->| | |
+--------------+ |
| | |
V4 FIN V6 FIN |
| | |
V V |
+---------+ +----------+ |
| V4 FIN | | V6 FIN | |
+---------+ +----------+ |
| | |
V6 FIN V4 FIN 4 min
| | T.O.
V V |
+-------------------+ |
| V4 FIN + V6 FIN |----------------------+
+-------------------+
</artwork>
<postamble></postamble>
</figure>
<t>We next describe the state information and the transitions.</t>
<t>*** CLOSED ***</t>
<t>If a V6 SYN is received with an incoming tuple with source transport address (X',x) and
destination transport address (Y',y) (This is the case of a TCP connection initiated from the IPv6 side), the processing is as follows:
<list style="numbers">
<t>The NAT64 searches
for a TCP BIB entry that matches the IPv6 source transport address (X',x).
<list style="empty">
<t>If such an entry does not exists, a new BIB entry is created.
The BIB IPv6 transport address is set to (X',x) (i.e. the source IPv6 transport address of the packet).
The BIB IPv4 transport address is set to an IPv4 transport address allocated using the rules defined
in <xref target="transport address alloc"></xref>
The processing of the packet continues as described in bullet 2.</t>
<t>If the entry already exists, then the processing continues as described bullet 2.</t>
</list></t>
<t>Then a new TCP session entry is created in the TCP session table.
The information included in the session table is as follows:
<list style="empty">
<t> The STE source IPv6 transport address is set to (X',x) (i.e. the source transport address contained in the received V6 SYN packet,</t>
<t> The STE destination IPv6 transport address is set to (Y',y) (i.e. the destination transport address
contained in the received V6 SYN packet,</t>
<t>The STE source IPv4 transport address is set to the BIB IPv4 transport address of the corresponding TCP BIB entry.</t>
<t>The STE destination IPv4 transport address contains the port y (i.e. the same port as
the IPv6 destination transport address) and the IPv4 address that is algorithmically generated from the IPv6
destination address (i.e. Y') using the reverse algorithm as specified in <xref target="address-transform"></xref>.</t>
<t>The lifetime of the TCP session table entry is set to at least to 4 min (the
transitory connection idle timeout as defined in <xref target="RFC5382"></xref>).</t>
</list></t>
<t>The state of the session is moved to V6 SYN RCV.</t>
<t>The NAT64 translates and forwards the packet as described
in the following sections</t>
</list></t>
<t> If a V4 SYN packet is received with an incoming tuple with source IPv4 transport address (Y,y) and
destination IPv4 transport address (X,x) (This is the case of a TCP connection initiated from the IPv4 side), the processing is as follows:
<list>
<t> If the security policy requires silently dropping externally initiated TCP connections, then
the packet is silently discarded, else,</t>
<t>If the destination transport address contained in the incoming V4 SYN (i.e. X,x) is not in use in the TCP BIB,
then the packet is discarded and an ICMP Port Unreachable error (Type 3, Code 3) is sent back to
the source of the v4 SYN. The state remains unchanged in CLOSED</t>
<t>If the destination transport address contained in the incoming V4 SYN (i.e. X,x) is in use in the TCP BIB, then
<list>
<t>A new session table entry is created in the TCP session table, containing the following information:
<list>
<t> The STE source IPv4 transport address is set to (X,x) (i.e. the destination transport address contained in the V4 SYN) </t>
<t> The STE destination IPv4 transport address is set to (Y,y) (i.e. the source transport address contained in the V4 SYN) </t>
<t> The STE transport IPv6 source address is set to the IPv6 transport address contained in the corresponding TCP BIB entry.</t>
<t>The STE destination IPv6
transport address contains the port y (i.e. the same port than the destination IPv4 transport address) and the
IPv6 representation of Y (i.e. the IPv4 address of the destination IPv4 transport address), generated using the
algorithm described in <xref target="address-transform"></xref>.</t>
<t>The lifetime of the entry is set to 6 seconds as per <xref target="RFC5382"></xref>.</t>
</list></t>
<t>The state is moved to V4 SYN RCV.</t>
<t>If the NAT64 is performing Address-Dependent filtering, the packet is stored (The motivation for
creating the session table entry and storing the packet (instead of simply dropping the packet based on the filtering) is
to support simultaneous open of TCP connections).</t>
<t>If the NAT64 is not performing Address-Dependent filtering, it translates and forwards the packet as described
in the following sections. </t>
</list></t>
</list></t>
<t>For any other packet belonging to this connection,
<list>
<t>If there is a corresponding entry in the TCP BIB
depending on the security policy other packets MAY be forwarded or MAY be silently discarded.
In any case, the state remains unchanged.</t>
<t>If there is no corresponding entry in the TCP BIB
the packet is silently discarded.</t>
</list>
</t>
<t>*** V4 SYN RCV ***</t>
<t>If a V6 SYN is received with incoming tuple with source transport address (X',x) and
destination transport address (Y',y), then the lifetime of the corresponding TCP session table entry is set to at least 2 hours 4 min (the
established connection idle timeout as defined in <xref target="RFC5382"></xref>).
The packet is translated and forwarded. The state is moved to ESTABLISHED.</t>
<t>If the lifetime expires, an ICMP Port Unreachable error (Type 3, Code 3) containing the IPv4 SYN packet stored is sent back to
the source of the v4 SYN, the session table entry is deleted and, the state is moved to CLOSED.</t>
<t>For any other packet, depending on the security policy other packets MAY be forwarded or MAY be silently discarded.
In any case, the state remains unchanged.</t>
<t>*** V6 SYN RCV ***</t>
<t>If a V4 SYN is received (with or without the ACK flag set), with an incoming tuple with source IPv4 transport address (Y,y) and
destination IPv4 transport address (X,x), then the state is moved to ESTABLISHED.
The timer is set to at least 2 hours 4 min (the
established connection idle timeout as defined in <xref target="RFC5382"></xref>).
The packet is translated and forwarded.</t>
<t>If the lifetime expires, the session table entry is deleted and the state is moved to CLOSED.</t>
<t>For any other packet, depending on the security policy other packets MAY be forwarded or MAY be silently discarded.
In any case, the state remains unchanged.</t>
<t>*** ESTABLISHED ***</t>
<t>If the lifetime expires, the session table entry is deleted and the state is moved to CLOSED.</t>
<t>If a V4 FIN packet is received, the packet is translated and forwarded.
The state is moved to V4 FIN RCV.</t>
<t>If a V6 FIN packet is received, the packet is translated and forwarded.
The state is moved to V6 FIN RCV.</t>
<t>If a V4 RST or a V6 RST packet is received, the packet is translated and forwarded. The lifetime is set to 4 min and
state is moved to RST RCV. (Since the NAT64 is uncertain whether the peer will accept the RST packet, instead of moving the state to
CLOSED, it moves to the RST RCV, which has a shorter lifetime. If no other packets are received for this connection during the
short timer, the NAT64 assumes that the peer has accepted the RST packet and moves to CLOSED. If packet keep flowing,
the NAT64 assumes that the peer has not accepted the RST packet and moves back to ESTABLISHED state.)</t>
<t>If any other packet is received, the packet is translated and forwarded. The lifetime is set to at least 2 hours and 4 min.
The state remains unchanged as ESTABLISHED.</t>
<t>*** V4 FIN RCV ***</t>
<t>If a V6 FIN packet is received, the packet is translated and forwarded.
The lifetime is set to 4 min. The state is moved to V6 FIN + V4 FIN RCV.</t>
<t>If any other packet is received, the packet is translated and forwarded. The lifetime is set to at least 2 hours and 4 min.
The state remains unchanged as V4 FIN RCV.</t>
<t>If the lifetime expires, the session table entry is deleted and the state is moved to CLOSED.</t>
<t>*** V6 FIN RCV ***</t>
<t>If a V4 FIN packet is received, the packet is translated and forwarded.
The lifetime is set to 4 min. The state is moved to V6 FIN + V4 FIN RCV.</t>
<t>If any other packet is received, the packet is translated and forwarded. The lifetime is set to at least 2 hours and 4 min.
The state remains unchanged as V6 FIN RCV.</t>
<t>If the lifetime expires, the session table entry is deleted and the state is moved to CLOSED.</t>
<t>*** V6 FIN + V4 FIN RCV ***</t>
<t>All packets are translated and forwarded.</t>
<t>If the lifetime expires, the session table entry is deleted and the state is moved to CLOSED.</t>
<t>*** RST RCV ***</t>
<t>If a packet other than a RST packet is received, the lifetime is set to at least 2 hours and 4 min and the state is moved to ESTABLISHED.</t>
<t>If the lifetime expires, the session table entry is deleted and the state is moved to CLOSED.</t>
</section>
<section title="Rules for allocation of IPv4 transport addresses" anchor="transport address alloc">
<t>If the rules specify that a new TCP or UDP BIB entry is created for a source
transport address of (S',s), then the NAT64 allocates an IPv4 transport
address for this BIB entry as follows:<list style="empty">
<t>If there exists some other BIB entry containing S' as the IPv6
address and mapping it to some IPv4 address T, then use T as the
IPv4 address. Otherwise, use any IPv4 address of the IPv4 pool assigned to the NAT64 to be used for translation.</t>
<t>If the port s is in the Well-Known port range 0..1023, then
the NAT64 SHOULD allocate a port t from this same range. Otherwise, if the port s
is in the range 1024..65535, then the NAT64 SHOULD allocate a port t from this
range. Furthermore, if port s is even, then t SHOULD be even, and
if port s is odd, then t SHOULD be odd. (this behavior is recommended in Section 7.1 of <xref target="RFC5382"></xref>)</t>
<t>In all cases, the allocated IPv4 transport address (T,t) MUST
NOT be in use in another entry in the same BIB, but MAY be in
use in the other BIB (referring to the UDP and TCP BIBs).</t>
</list>If it is not possible to allocate an appropriate IPv4
transport address or create a BIB entry for some reason, then the
packet is discarded. The NAT64 MAY send an ICMPv6 Destination Unreachable/Address unreachable (Code 3) message. </t>
</section>
<section title="ICMP Query Session Handling">
<t>The state information stored for an ICMP Query session in the ICMP Query session table includes a timer that
tracks the remaining lifetime of the session. When the timer
expires, the session is deleted. If all the sessions corresponding to a
ICMP Query BIB entry are deleted, then the ICMP Query BIB entry is also deleted in the case of dynamically created entries.</t>
<t>An incoming ICMPv6 Informational packet with IPv6 source address X', IPv6 destination address Y' and Identifier I1, is processed as follows:
<list>
<t>
If the local security policy determines that ICMPv6 Informative packets are to be filtered, the packet is silently discarded.
Else, the NAT64 searches
for a ICMP Query BIB entry that matches the (X',I1) pair.
If such entry does not exist, a new entry is created with the following data:
<list>
<t>The BIB IPv6 address is set to X' i.e. the source IPv6 address of the IPv6 packet.</t>
<t>The BIB ICMPv6 Query Id is set to I1 i.e. the ICMPv6 Query Identifier.</t>
<t>If there exists some other BIB entry containing the same IPv6
address X' and mapping it to some IPv4 address T, then use T as the
BIB IPv4 address for this new entry. Otherwise, use any IPv4 address assigned to the IPv4
interface.</t>
<t>As the BIB ICMPv4 Identifier use any available value i.e. any identifier value for which
no other entry exists with the same (IPv4 address, ICMPv4 Query Id) pair.</t>
</list></t>
<t>The NAT64 searches for an ICMP query session table entry
corresponding to the incoming 3-tuple (X',Y',I1). If no such entry is
found, a new entry is created.
The information included in the new session table entry is as follows:
<list>
<t>The STE IPv6 source address is set to the X' i.e. the address contained in the received IPv6 packet,</t>
<t>The STE IPv6 destination address is set to the Y' i.e. the address contained in the received IPv6 packet,</t>
<t>The STE IPv6 identifier is set to the I1 I.e. the identifier contained in the received IPv6 packet,</t>
<t>The STE IPv4 source address is set to the IPv4 address contained in the corresponding BIB entry,</t>
<t>The STE IPv4 identifier is set to the IPv4 identifier contained in the corresponding BIB entry,</t>
<t>The STE IPv4 destination address is algorithmically generated from Y' using the reverse algorithm as
specified in <xref target="address-transform"></xref>.</t>
</list></t>
<t>The NAT64 sets or resets the timer in the session table
entry to maximum session lifetime. By default, the maximum
session lifetime is 60 seconds. The maximum lifetime value SHOULD be configurable.
The packet is translated and forwarded as described in the following sections.</t>
</list></t>
<t>An incoming ICMPv4 Query packet with source IPv4 address Y,
destination IPv4 address X and Identifier I2 is processed as follows:
<list>
<t>The NAT64 searches
for a ICMP Query BIB entry that contains X as IPv4 address matches and I2 as the IPv4 Identifier.
If such an entry does not exists, the packet is dropped. An ICMP message MAY be sent to the
original sender of the packet, unless the discarded packet is
itself an ICMP message. The ICMP message, if sent, has a type
of 3 (Destination Unreachable).</t>
<t>If the NAT64
filters on its IPv4 interface, then the NAT64 checks to see if
the incoming packet is allowed according to the
address-dependent filtering rule. To do this, it searches for
a session table entry with a STE source IPv4 address equal to X, an STE IPv4 Identifier equal to I2
and a STE destination IPv4 address equal to Y.
If such an entry
is found (there may be more than one), packet processing
continues. Otherwise, the packet is discarded. If the packet
is discarded, then an ICMP message MAY be sent to the
original sender of the packet, unless the discarded packet is
itself an ICMP message. The ICMP message, if sent, has a type
of 3 (Destination Unreachable) and a code of 13 (Communication
Administratively Prohibited).</t>
<t>In case the packet is not discarded in the previous processing (either because the NAT64
is not filtering or because the packet is compliant with the Address-dependent filtering rule),
then the NAT64 searches for
a session table entry with a STE source IPv4 address equal to X, an STE IPv4 Identifier equal to I2
and a STE destination IPv4 address equal to Y. If no such entry is
found, a new entry is created with the following information:
<list>
<t>The STE source IPv4 address is set to X,</t>
<t>The STE IPv4 Identifier is set to I2,</t>
<t>The STE destination IPv4 address is set to Y,</t>
<t>The STE source IPv6 address is set to the IPv6 address of the corresponding BIB entry,</t>
<t>The STE IPv6 Identifier is set to the IPv6 Identifier of the corresponding BIB entry, and,</t>
<t>The STE destination IPv6 address is set to the
IPv6 representation of the IPv4 address of Y, generated using the
algorithm described in <xref target="address-transform"></xref>.</t>
<t>The NAT64 sets or resets the timer in the session table
entry to maximum session lifetime. By default, the maximum
session lifetime is 60 seconds. The maximum lifetime value SHOULD be configurable.
The packet is translated and forwarded as described in the following sections.</t>
</list></t>
</list></t>
</section>
<section title="Generation of the IPv6 representations of IPv4 addresses" anchor="address-transform">
<t>NAT64 support multiple algorithms for the generation of the IPv6 representation of an IPv4 address.
The constraints imposed to the generation algorithms are the following:
<list>
<t>The same algorithm to create an IPv6 address from an IPv4 address MUST be used by:
<list>
<t>The DNS64 to create the IPv6 address to be returned in the synthetic
AAAA RR from the IPv4 address contained in original A RR, and,</t>
<t>The NAT64 to create the IPv6 address to be included in the destination address
field of the outgoing IPv6 packets from the IPv4 address included in the destination address
field of the incoming IPv4 packet.</t>
</list> </t>
<t>The algorithm MUST be reversible, i.e. it MUST be possible to extract the original IPv4 address
from the IPv6 representation. </t>
<t>The input for the algorithm MUST be limited to the IPv4 address, the IPv6 prefix (denoted Pref64::/n) used in the
IPv6 representations and optionally a set of stable parameters that are
configured in the NAT64 (such as fixed string to be used as a suffix).
<list>
<t> If we note n the length of the prefix Pref64::/n, then n MUST the less or equal than 96.
If a Pref64::/n is configured through any means in the DNS64
(such as manually configured, or other automatic mean not specified
in this document), the default algorithm MUST use this prefix.
If no prefix is available, the algorithm SHOULD use the Well-Known prefix
(64:FF9B::/96) defined in
<xref target="I-D.ietf-behave-address-format" /></t>
</list></t>
</list></t>
<t>NAT64 MUST support the algorithm for generating IPv6 representations of IPv4 addresses defined in
section 2 of <xref target="I-D.ietf-behave-address-format" />. The aforementioned algorithm SHOULD be used as default algorithm.</t>
</section>
</section>
<section anchor="outgoing tuple" title="Computing the Outgoing Tuple">
<t>This step computes the outgoing tuple by translating the
addresses and ports or ICMP Query Id in the incoming tuple. </t>
<t>In the text below, a reference to the the "BIB" means either the
TCP BIB the UDP BIB or the ICMP Query BIB as appropriate.</t>
<t><list>
<t>NOTE: Not all addresses are translated using the BIB. BIB
entries are used to translate IPv6 source transport addresses to
IPv4 source transport addresses, and IPv4 destination transport
addresses to IPv6 destination transport addresses. They are NOT
used to translate IPv6 destination transport addresses to IPv4
destination transport addresses, nor to translate IPv4 source
transport addresses to IPv6 source transport addresses. The latter
cases are handled applying the algorithmic transformation described
in <xref target="address-transform"></xref>. This
distinction is important; without it, hairpinning doesn't work
correctly.</t>
</list></t>
<section title="Computing the outgoing 5-tuple for TCP and UDP.">
<t>The transport protocol
in the outgoing 5-tuple is always the same as that in the incoming
5-tuple.</t>
<t>When translating in the IPv6 --> IPv4 direction, let the incoming
source and destination transport addresses in the 5-tuple be (S',s)
and (D',d) respectively. The outgoing source transport address is
computed as follows: the BIB contains a entry (S',s) <--> (T,t), then the
outgoing source transport address is (T,t).</t>
<t>The outgoing destination address is computed
algorithmically from D' using the address transformation described in
<xref target="address-transform"></xref>.</t>
<t>When translating in the IPv4 --> IPv6 direction, let the incoming
source and destination transport addresses in the 5-tuple be (S,s)
and (D,d) respectively. The outgoing source transport address is
computed as follows: <list style="empty">
<t>The outgoing source transport address is generated from S using the address transformation algorithm described in
<xref target="address-transform"></xref>.</t>
<t>The BIB table is searched for an entry (X',x) <--> (D,d), and the outgoing destination transport address is set to (X',x).</t>
</list></t>
<!--
<t>When translating in the IPv4 --> IPv6 direction, let the incoming
source and destination transport addresses in the 5-tuple be (S,s)
and (D,d) respectively. The outgoing source transport address is
computed as follows: <list style="empty">
<t>The outgoing source transport address is generated from S using the address transformation algorithm described in
<xref target="address-transform"></xref>.</t>
</list>The outgoing destination transport address is computed as
follows:<list style="empty">
<t>If the BIB contains an entry (X',x) <--> (D,d), then
the outgoing destination transport address is (X',x).</t>
<t>Otherwise, discard the packet.</t>
</list></t>
<t>If the rules specify that the packet is discarded, then the NAT64
MAY send an ICMP reply to the original sender, unless the packet
being translated contains an ICMP message. The type should be 3
(Destination Unreachable) and the code should be 0 (Network
Unreachable in IPv4, and No Route to Destination in IPv6).</t>
-->
</section>
<section anchor="outgoing 3-tuple" title="Computing the outgoing 3-tuple for ICMP Query messages">
<t>When translating in the IPv6 --> IPv4 direction, let the incoming
source and destination addresses in the 3-tuple be S'
and D' respectively and the ICMPv6 Query Identifier be I1. The outgoing source address is
computed as follows: the BIB contains a entry (S',I1) <--> (T,I2), then the
outgoing source address is T and the ICMPv4 Query Id is I2.</t>
<t>The outgoing IPv4 destination address is computed
algorithmically from D' using the address transformation described in
<xref target="address-transform"></xref>.</t>
<t>When translating in the IPv4 --> IPv6 direction, let the incoming
source and destination addresses in the 3-tuple be S
and D respectively and the ICMPv4 query Id is I2. The outgoing source address is
generated from S using the address transformation algorithm described in
<xref target="address-transform"></xref>.
The BIB is searched for an entry containing (X',I1) <--> (D,I2) and
the outgoing destination address is X' and the outgoing ICMPv6 Query Id is I1.</t>
</section>
</section>
<section title="Translating the Packet">
<t>This step translates the packet from IPv6 to IPv4 or vice-versa.</t>
<t>The translation of the packet is as specified in section 3 and
section 4 of <xref target="I-D.ietf-behave-v6v4-xlate">IP/ICMP Translation Algorithm</xref>, with the following
modifications:<list style="symbols">
<t>When translating an IP header (sections 3.1 and 4.1), the
source and destination IP address fields are set to the source
and destination IP addresses from the outgoing tuple as determined in <xref target="outgoing tuple"></xref>.</t>
<t>When the protocol following the IP header is TCP or UDP, then
the source and destination ports are modified to the source and
destination ports from the outgoing 5-tuple. In addition, the TCP or UDP
checksum must also be updated to reflect the translated
addresses and ports; note that the TCP and UDP checksum covers
the pseudo-header which contains the source and destination IP
addresses. An algorithm for efficiently updating these checksums
is described in <xref target="RFC3022"></xref>.</t>
<t>When the protocol following the IP header is ICMP and it is an ICMP Query message,
the ICMP query Identifier is set to the one of the outgoing 3-tuple as determined in <xref target="outgoing 3-tuple"></xref>.</t>
<t>When the protocol following the IP header is ICMP (sections
3.4 and 4.4) and it is an ICMP error message,
the source and destination transport addresses in
the embedded packet are set to the destination and source
transport addresses from the outgoing 5-tuple (note the swap of
source and destination).</t>
</list></t>
<t>The size of outgoing packets as well and the potential need for fragmentation
is done according to the behavior defined in <xref target="I-D.ietf-behave-v6v4-xlate">IP/ICMP Translation Algorithm</xref>
</t>
</section>
<section title="Handling Hairpinning">
<t>This step handles hairpinning if necessary. A NAT64 that forwards packets originating from an IPv6 address,
destined for an IPv4 address that matches the active mapping for
another IPv6 address, back to that IPv6 address are defined as as
supporting "hairpinning".</t>
<t>If the destination IP address is an address assigned to the NAT64
itself (i.e., is one of the IPv4 addresses assigned to the IPv4
interface, or is covered by the Pref64::/n prefix assigned to the IPv6
interface), then the packet is a hairpin packet. The outgoing
5-tuple becomes the incoming 5-tuple, and the packet is treated as
if it was received on the outgoing interface. Processing of the
packet continues at step 2. Filtering and updating binding and session information described in <xref target="sec-session-info"/></t>
</section>
</section>
<section title="Security Considerations">
<t>Implications on end-to-end security.</t>
<t>Any protocol that protect IP header information are essentially incompatible
with NAT64. So, this implies that end to end IPsec verification will fail when
AH is used (both transport and tunnel mode) and when ESP is used in tunnel mode.
This is inherent to any network layer translation mechanism. End-to-end IPsec protection
can be restored, using UDP encapsulation as described in <xref target="RFC3948"></xref>.
The actual extensions to support IPsec are out of the scope of this document.</t>
<t>Filtering.</t>
<t>NAT64 creates binding state using packets flowing from the IPv6 side
to the IPv4 side. In accordance with the procedures defined in this
document following the guidelines defined in RFC 4787
<xref target="RFC4787"></xref> a NAT64 must offer
"enpoint independent filtering". This means:
<list>
<t> for any IPv6 side packet with source (S'1,s1) and destination
(Pref64::D1,d1) that creates an external mapping to (S1,s1), (D1,d1),</t>
<t> for any subsequent external connection to from S'1 to (D2,d2)
within a given binding timer window,</t>
<t> (S1,s1) = (S2,s2) for all values of D2,d2</t>
</list></t>
<t>Implementations may also provide support for "Address-Dependent
Mapping" and "Address and Port-Dependent Mapping", as also defined
in this document and following the guidelines defined in RFC 4787
<xref target="RFC4787"></xref>.</t>
<t>The security
properties however are determined by which packets the NAT64 filter
allows in and which it does not. The security properties are
determined by the filtering behavior and filtering configuration
in the filtering portions of the NAT64, not by the address mapping
behavior. For example,
<list>
<t> Without filtering - When "endpoint independent
filtering" is used in NAT64, once a binding is created in the
IPv6 ---> IPv4 direction, packets from any node on the IPv4 side
destined to the IPv6 transport address will traverse the
NAT64 gateway and be forwarded to the IPv6 transport address
that created the binding. However,</t>
<t> With filtering - When "endpoint independent
filtering" is used in NAT64, once a binding is created in the
IPv6 ---> IPv4 direction, packets from any node on the IPv4 side
destined to the IPv6 transport address will first be processed
against the filtering rules. If the source IPv4 address is
permitted, the packets will be forwarded to the IPv6 transport
address. If the source IPv4 address is explicitly denied -- or the
default policy is to deny all addresses not explicitly permitted
-- then the packet will discarded. A dynamic filter may be
employed where by the filter will only allow packets from the
IPv4 address to which the original packet that created the binding
was sent. This means that only the D IPv4 addresses to which the
IPv6 host has initiated connections will be able to reach the IPv6
transport address, and no others. This essentially narrows the
effective operation of the NAT64 device to a
"Address Dependent" behavior, though not by its
mapping behavior, but instead by its filtering behavior.</t>
</list></t>
<t>Attacks to NAT64.</t>
<t>The NAT64 device itself is a potential victim of different type of
attacks. In particular, the NAT64 can be a victim of DoS attacks.
The NAT64 box has a limited number of resources that can be consumed
by attackers creating a DoS attack. The NAT64 has a limited number
of IPv4 addresses that it uses to create the bindings. Even though the
NAT64 performs address and port translation, it is possible for an
attacker to consume all the IPv4 transport addresses by sending IPv6
packets with different source IPv6 transport addresses. It should be
noted that this attack can only be launched from the IPv6 side, since
IPv4 packets are not used to create binding state. DoS attacks can
also affect other limited resources available in the NAT64 such as
memory or link capacity. For instance, it is possible for an attacker
to launch a DoS attack to the memory of the NAT64 device by sending
fragments that the NAT64 will store for a given period. If the
number of fragments is high enough, the memory of the NAT64 could be
exhausted. NAT64 devices should implement proper protection against
such attacks, for instance allocating a limited amount of memory for
fragmented packet storage.
</t>
<t>Avoiding hairpinning loops</t>
<t>If the IPv6-only client can guess the IPv4 binding address that will be
created, it can use the IPv6 representation of it as source address for
creating this binding. Then any packet sent to the binding's IPv4
address will loop in the NAT64.</t>
<t>Consider the following example:</t>
<t>Suppose that the IPv4 pool is 192.0.2.0/24</t>
<t>Then the IPv6-only client sends this to NAT64:
<list>
<t>Source: [Pref64::192.0.2.1]:500</t>
<t>Destination: whatever</t>
</list></t>
<t>The NAT64 allocates 192.0.2.1:500 as IPv4 binding address.
Now anything sent to 192.0.2.1:500, be it a hairpinned IPv6 packet or an
IPv4 packet, will loop.</t>
<t>It should be noted that it is not hard to guess the IPv4 address that will be allocated.
First the attacker creates a binding and use e.g.
STUN to know your external IPv4. New bindings will always have this
address. Then it uses a source port in the range 1-1023. This will
increase your chances to 1/512 (since range and parity must be
preserved). </t>
<t>In order to address this vulnerability, the NAT64 drops IPv6 packets whose source address is in Pref64::/n. </t>
</section>
<section title="IANA Considerations">
<t>This document contains no IANA considerations.</t>
</section>
<section title="Contributors">
<t>George Tsirtsis</t>
<list>
<t>Qualcomm</t>
<t>tsirtsis@googlemail.com</t>
</list>
<t>Greg Lebovitz</t>
<list>
<t>Juniper</t>
<t>gregory.ietf@gmail.com</t>
</list>
<t>Simon Parreault</t>
<list>
<t>Viagenie</t>
<t>simon.perreault@viagenie.ca</t>
</list>
</section>
<section title="Acknowledgements">
<t>Dave Thaler, Dan Wing, Alberto Garcia-Martinez, Reinaldo Penno, Ranjana Rao,
Lars Eggert, Senthil Sivakumar, Zhen Cao and Joao Damas reviewed the document and
provided useful comments to improve it.</t>
<t>The content of the draft was improved thanks to discussions with Fred Baker and Jari Arkko.</t>
<t>Marcelo Bagnulo and Iljitsch van Beijnum are partly funded by Trilogy,
a research project supported by the European Commission under its Seventh
Framework Program.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include='reference.RFC.2119'?>
<?rfc include='reference.RFC.1035'?>
<!-- <?rfc include='reference.RFC.2671'?> -->
<?rfc include='reference.RFC.4787'?>
<!-- <?rfc include='reference.RFC.3484'?> -->
<?rfc include='reference.RFC.3948'?>
<?rfc include="reference.RFC.5382"?>
<?rfc include="reference.RFC.5508"?>
<?rfc include="reference.I-D.ietf-behave-v6v4-xlate"?>
<?rfc include="reference.I-D.ietf-behave-address-format"?>
</references>
<references title="Informative References">
<!-- <?rfc include='reference.RFC.2765'?>
<?rfc include="reference.RFC.1191"?>
<?rfc include="reference.RFC.1981"?> -->
<?rfc include="reference.I-D.ietf-behave-dns64"?>
<?rfc include="reference.RFC.0793"?>
<?rfc include='reference.RFC.2766'?>
<?rfc include='reference.RFC.1858'?>
<?rfc include='reference.RFC.3128'?>
<?rfc include='reference.RFC.3022'?>
<?rfc include='reference.RFC.4966'?>
<?rfc include='reference.I-D.ietf-mmusic-ice'?>
<!-- <?rfc include='reference.RFC.3498'?> -->
<?rfc include='reference.RFC.4963'?>
<?rfc include="reference.I-D.ietf-behave-v6v4-framework"?>
</references>
<section title="Application scenarios">
<t>In this section, we describe how to apply NAT64/DNS64 to the suitable scenarios
described in <xref target="I-D.ietf-behave-v6v4-framework"></xref> .</t>
<section title="Scenario 1: an IPv6 network to the IPv4 Internet">
<t>An IPv6 only network basically has IPv6 hosts
(those that are currently available) and because of different reasons
including operational simplicity, wants to run those hosts
in IPv6 only mode, while still providing access to the IPv4 Internet.
The scenario is depicted in the picture below.</t>
<figure>
<preamble></preamble>
<artwork><![CDATA[ +----+ +-------------+
| +------------------+IPv6 Internet+
| | +-------------+
IPv6 host-----------------+ GW |
| | +-------------+
| +------------------+IPv4 Internet+
+----+ +-------------+
|-------------------------public v6-----------------------------|
|-------public v6---------|NAT|----------public v4--------------|
]]></artwork>
<postamble></postamble>
</figure>
<t>The proposed NAT64/DNS64 is perfectly suitable for this particular scenario.
The deployment of the NAT64/DNS64 would be as follows: The NAT64 function
should be located in the GW device that connects the IPv6 site to the IPv4 Internet.
The DNS64 functionality can be placed either in the local recursive DNS server
or in the local resolver in the hosts.</t>
<!-- in different places. Probably the
best trade-off between architectural cleanness and deployment simplicity would
be to place it in the local recursive DNS server of the enterprise site.
The option that is easier to deploy would be to co-locate it with the NAT64 box.
The cleanest option would be included in the local resolver of the IPv6 hosts, but
this option seems the harder to deploy cause it implies changes to the hosts.
-->
<t>The proposed NAT64/DNS64 approach satisfies the requirements of this scenario,
in particular because it doesn't require any changes to current IPv6 hosts in the
site to obtain basic functionality.
</t>
</section>
<section title="Scenario 3: the IPv6 Internet to an IPv4 network ">
<t>The scenario of servers using private addresses and being reached from the
IPv6 Internet basically includes the cases that for whatever reason the servers
cannot be upgraded to IPv6 and they even may not have public IPv4 addresses and it would
be useful to allow IPv6 nodes in the IPv6 Internet to reach those servers. This
scenario is depicted in the figure below.</t>
<figure>
<preamble></preamble>
<artwork><![CDATA[ +----+
IPv6 Host(s)-------(Internet)-----+ GW +------Private IPv4 Servers
+----+
|---------public v6---------------|NAT|------private v4----------|
]]></artwork>
<postamble></postamble>
</figure>
<t>This scenario can again be perfectly served by the NAT64 approach. In this case
the NAT64 functionality is placed in the GW device connecting the IPv6 Internet to
the server's site. In this case, the DNS64 functionality is not required in general since real
(i.e. non synthetic) AAAA RRs for the IPv4 servers containing the IPv6 representation of
the IPv4 address of the servers can be created. See more discussion about this in
<xref target="I-D.ietf-behave-dns64"></xref>
</t>
<t>Again, this scenario is satisfied by the NAT64 since it supports the required functionality
without requiring changes in the IPv4 servers nor in the IPv6 clients.</t>
</section>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 02:09:46 |