BEHAVE WG M. Bagnulo
Internet-Draft UC3M
Intended status: Standards Track P. Matthews
Expires: April 30, 2009 Unaffiliated
I. van Beijnum
IMDEA Networks
A. Sullivan
Shinkuro
October 27, 2008
DNS64: DNS extensions for Network Address Translation from IPv6 Clients
to IPv4 Servers
draft-bagnulo-behave-dns64-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 April 30, 2009.
Abstract
DNS64 is a mechanism for synthesizing AAAA records from A records.
DNS64 is used with NAT64, an IPv6 IPv4 translator to 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. This
document specifies DNS64, and gives suggestions on how it should be
Bagnulo, et al. Expires April 30, 2009 [Page 1]
Internet-Draft DNS64 October 2008
deployed in conjunction with NAT64.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Walkthough . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7
3. Normative Specification . . . . . . . . . . . . . . . . . . . 8
3.1. DNS64 . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4. Solution space analysis . . . . . . . . . . . . . . . . . . . 10
4.1. Tagging synthetic RR . . . . . . . . . . . . . . . . . . . 10
4.2. Dual stack nodes . . . . . . . . . . . . . . . . . . . . . 11
4.3. IPv6 nodes implementing DNSSEC . . . . . . . . . . . . . . 13
4.4. Learning the Pref64::/96 prefix . . . . . . . . . . . . . 15
4.5. Supporting multiple NAT64 boxes with different
associated prefixes . . . . . . . . . . . . . . . . . . . 15
5. Application scenarios . . . . . . . . . . . . . . . . . . . . 17
5.1. Enterprise IPv6 only network . . . . . . . . . . . . . . . 17
6. Additional Discussion . . . . . . . . . . . . . . . . . . . . 17
6.1. About the Prefix used to map the IPv4 address space
into IPv6 . . . . . . . . . . . . . . . . . . . . . . . . 18
7. Security Considerations . . . . . . . . . . . . . . . . . . . 20
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
9. Changes from Previous Draft Versions . . . . . . . . . . . . . 20
10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 20
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
12.1. Normative References . . . . . . . . . . . . . . . . . . . 21
12.2. Informative References . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22
Intellectual Property and Copyright Statements . . . . . . . . . . 24
Bagnulo, et al. Expires April 30, 2009 [Page 2]
Internet-Draft DNS64 October 2008
1. Introduction
This document specifies DNS64, a mechanism that is part of the
toolbox for IPv6-IPv4 transition and co-existence. DNS64 used
together with NAT64, allows an IPv6-only client to initiate
communications by name to an IPv4-only server.
DNS64 is a mechanism for synthesizing AAAA resource records (RR) from
A RRs. The synthesis is done by adding a /96 prefix to the IPv4
address to create an IPv6 address, where the /96 prefix is assigned
to a NAT64 device.
NAT64 as defined in a companion document [I-D.bagnulo-behave-nat64]
is a mechanism for translating IPv6 packets to IPv4 packets. The
translation is done by translating the packet headers according to
SIIT [RFC2765], translating the IPv4 server address by adding or
removing a /96 prefix, and translating the IPv6 client address by
installing mappings in the normal NAT manner.
Together, these two mechanisms allow an IPv6-only client to initiate
communications to an IPv4-only server using the FQDN of the server.
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. These include hosts running IPv6-
only applications, IPv6-only hosts as well as the cases where only
IPv6-only connectivity between the client and the NAT64 is available.
In the general case, the approach only requires the deployment of
NAT64-enabled devices connecting an IPv6-only network to the IPv4-
only Internet, along with the deployment of a few DNS64-enabled name
servers in the IPv6-only network. However, some advanced features
require to perform the DNS64 function directly in the end-hosts
themselves.
1.1. Overview
This section provides a non-normative introduction to the DNS64
mechanism.
We assume that we have a NAT64 box which has two interfaces, an IPv4
interface connected to 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.
Bagnulo, et al. Expires April 30, 2009 [Page 3]
Internet-Draft DNS64 October 2008
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).
Such binding state 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 NAT64 only
supports communications initiated by the IPv6-only node towards an
IPv4-only node.
To allow an IPv6 initiator to do the standard DNS lookup to learn the
address of the responder, DNS64 is used to synthesize an AAAA record
from the A record (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
discovered, DNS64 creates a synthetic AAAA RR by adding the
Pref64::/96 of a NAT64 to the responder's IPv4 address (i.e. if the
IPv4 node has IPv4 address X, then the synthetic AAAA RR will contain
the IPv6 address formed as Pref64:X). 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.
The DNS64 function can be performed in two places. One option is to
locate the DNS64 function in the local name server. In this way,
when a IPv6 device queries the name server for a AAAA RR for an IPv4
only host, the name server will perform the synthesis to the AAAA RR
and pass it back to the IPv6 only initiator. The main advantage of
this mode is that current IPv6 nodes can use this mechanism without
requiring any modification. The other option is to place the DNS64
function in the end hosts themselves, coupled to the local stub
resolver. In this case, the stub resolver will try to obtain real
AAAA RRs and in case they are not available, the DNS64 function will
synthesize the AAAA RR for internal usage. The main advantage of
this mode is that the synthetic AAAA RR do not leak outside the host.
Moreover, this mode is compatible with some advanced functions like
DNSSEC validation in the end host. The main drawback of this mode is
its deployability, since it requires changes in the end hosts.
1.2. Walkthough
In this example, we consider an IPv6 node located in an IPv6-only
site that initiates a communication to a IPv4 node located in the
Bagnulo, et al. Expires April 30, 2009 [Page 4]
Internet-Draft DNS64 October 2008
IPv6 Internet.
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 are indicated by "P::X", which
is a IPv6 address built from an IPv4 address X by adding the prefix
P, mappings are indicated as "(X,x) <--> (Y',y)".
As we described above, DNS64 has two modes of operation: a DNS server
mode and a stub resolver mode. We will next describe the operation
of each mode.
DNS64 in DNS server mode
The scenario for this case is depicted in the following figure:
+---------------------------------------+ +-----------+
|IPv6 site +-------------+ |IP Addr: | |
| +----+ | Name server | +-------+ T | IPv4 |
| | H1 | | with DNS64 | | NAT64 |------| Internet |
| +----+ +-------------+ +-------+ +-----------+
| |IP addr: Y' | | | |IP addr: X
| --------------------------------- | +----+
+---------------------------------------+ | H2 |
+----+
The figure shows a IPv6 node H1 which has an IPv6 address Y' and an
IPv4 node H2 with IPv4 address X.
A NAT64 connects the IPv6 network to the IPv4 Internet. This NAT64
has a /96 prefix (called Pref64::/96) associated to its IPv6
interface and an IPv4 address T assigned to its IPv4 interface.
Also shown is a local name server with DNS64 functionality. For the
purpose of this example, we assume that the name server is a dual-
stack node, so that H1 can contact it via IPv6, while it can contact
IPv4-only name servers via IPv4.
The local name server needs to know the /96 prefix assigned to the
local NAT64 (Pref64::/96). For the purpose of this example, we
assume it learns this through manual configuration.
For this example, assume the typical DNS situation where IPv6 hosts
have only stub resolvers and the local name server does the recursive
lookups.
The steps by which H1 establishes communication with H2 are:
Bagnulo, et al. Expires April 30, 2009 [Page 5]
Internet-Draft DNS64 October 2008
1. H1 does a DNS lookup for the IPv6 address of H2. H1 does this by
sending a DNS query for an AAAA record for H2 to the local name
server. Assume the local name server is implementing DNS64
functionality.
2. The local DNS server resolves the query, and discovers that there
are no AAAA records for H2.
3. The name server queries for an A record for H2 and gets back an A
record containing the IPv4 address X. The name server then
synthesizes an AAAA record. The IPv6 address in the AAAA record
contains the prefix assigned to the NAT64 in the first 96 bits
and the IPv4 address X in the lower 32 bits.
4. H1 receives the synthetic AAAA record and sends a packet towards
H2. The packet is sent from a source transport address of (Y',y)
to a destination transport address of (Pref64:X,x), where y and x
are ports chosen by H2.
5. The packet is routed to the IPv6 interface of the NAT64 and the
communication flows using the NAT64 mechanisms as described in
the NAT64 specification[I-D.bagnulo-behave-nat64].
DNS64 in stub-resolver mode
The scenario for this case is depicted in the following figure:
+---------------------------------------+ +-----------+
|IPv6 site +-------+ |IP addr: | |
| +---------------+ | Name | +-------+ T | IPv4 |
| | H1 with DNS64 | | Server| | NAT64 |------| Internet |
| +---------------+ +-------+ +-------+ +-----------+
| |IP addr: Y' | | | |IP addr: X
| --------------------------------- | +----+
+---------------------------------------+ | H2 |
+----+
The figure shows a IPv6 node H1 which has an IPv6 address Y' and an
IPv4 node H2 with IPv4 address X. Node H1 is implementing the DNS64
function.
A NAT64 connects the IPv6 network to the IPv4 Internet. This NAT64
has a /96 prefix (called Pref64::/96) associated to its IPv6
interface and an IPv4 address T assigned to its IPv4 interface.
H1 needs to know the /96 prefix assigned to the local NAT64
(Pref64::/96). For the purpose of this example, we assume it learns
Bagnulo, et al. Expires April 30, 2009 [Page 6]
Internet-Draft DNS64 October 2008
this through manual configuration but we will discuss different
options for doing this in the analysis section of this document.
Also shown is a local name server. For the purpose of this example,
we assume that the name server is a dual-stack node, so that H1 can
contact it via IPv6, while it can contact IPv4-only name servers via
IPv4.
For this example, assume the typical DNS situation where IPv6 hosts
have only stub resolvers and the local name server does the recursive
lookups.
The steps by which H1 establishes communication with H2 are:
1. H1 does a DNS lookup for the IPv6 address of H2. H1 does this by
sending a DNS query for a AAAA record for H2 to the local name
server.
2. The local DNS server resolves the query, and discovers that there
are no AAAA records for H2 and informs H1.
3. The stub resolver at H1 then queries for an A record for H2 and
gets back an A record containing the IPv4 address X. The DNS64
function within H1 then synthesizes a AAAA record. The IPv6
address in the AAAA record contains the prefix assigned to the
NAT64 in the first 96 bits and the IPv4 address X in the lower 32
bits.
4. H1 sends a packet towards H2. The packet is sent from a source
transport address of (Y',y) to a destination transport address of
(Pref64:X,x), where y and x are ports chosen by H2.
5. The packet is routed to the IPv6 interface of the NAT64 and the
communication flows using the NAT64 mechanisms as described in
the NAT64 specification[I-D.bagnulo-behave-nat64].
2. Terminology
This section provides a definitive reference for all the terms used
in document.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
The following terms are used in this document:
Bagnulo, et al. Expires April 30, 2009 [Page 7]
Internet-Draft DNS64 October 2008
DNS64: A logical function that synthesizes AAAA records (containing
IPv6 addresses) from A records (containing IPv4 addresses).
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.
NAT64: A device that translates IPv6 packets to IPv4 packets and
vice-versa, with the provision that the communication must be
initiated from the IPv6 side. The translation involves not only
the IP header, but also the transport header (TCP or UDP).
Session: A TCP or UDP session. In other words, the bi-directional
flow of packets between two ports on two different hosts. In
NAT64, typically one host is an IPv4 host, and the other one is an
IPv6 host.
5-Tuple: The tuple (source IP address, source port, destination IP
address, destination port, transport protocol). A 5-tuple
uniquely identifies a session. When a session flows through a
NAT64, each session has two different 5-tuples: one with IPv4
addresses and one with IPv6 addresses.
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).
Mapping: 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.
For a detailed understand of this document, the reader should also be
familiar with DNS terminology [RFC1035] and current NAT terminology
[RFC4787].
3. Normative Specification
3.1. DNS64
A DNS64 is a logical function that synthesizes AAAA records from A
records. The DNS64 function may be implemented in a stub resolver or
in a local recursive name server.
The only configuration parameter required by the DNS64 is the /96
Bagnulo, et al. Expires April 30, 2009 [Page 8]
Internet-Draft DNS64 October 2008
IPv6 prefix assigned to a NAT64. This prefix is used to map IPv4
addresses into IPv6 addresses, and is denoted Pref64::/96. The DNS64
learns this prefix through some means not specified here.
When the DNS64 receives a query for RRs of type AAAA and class IN, it
first attempts to retrieve non-synthetic RRs of this type and class.
If this query results in one or more AAAA records or in an error
condition, this result is returned to the client as per normal DNS
semantics. If the query is successful, but doesn't return any
answers, the DNS64 resolver executes a recursive A RR lookup for the
name in question. If this query results in an empty result or in an
error, this result is returned to the client. If the query results
in one or more A RRs, the DNS64 synthesizes AAAA RRs based on the A
RRs and the /96 prefix of the translator. The DNS64 resolver then
returns the synthesized AAAA records to the client.
DNS64 MAY perform the query for the AAAA RR and for the A RR in
parallel, in order to minimize the delay. However, this would result
in performing unnecessary A RR queries in the case that the AAAA RR
exists. A possible tradeoff would be to make them sequentially but
with a very short interval between them, so if we obtain a fast
reply, we avoid doing the additional query.
Discussion: what is the right TTL for synthetic AAAA RR? One may
argue that since these are synthetic, they should not be cached
(especially if we mark them with a EDNS0 option or additional RR
included in the reply message, since then part of the information in
the reply may not be cached). On the other hand, not caching them
makes the mechanism less efficient and the synthetic AAAA RR as
defined in this document are likely to be valid for long periods
(unless the corresponding NAT64 is no valid, see the discussion about
how to manage multiple prefixes later on)
A synthetic AAAA record is created from an A record as follows:
o The NAME field is set to the NAME field from the A record
o The TYPE field is set to 28 (AAAA)
o The CLASS field is set to 1 (IN)
o The TTL field is set to 0 (To be discussed)
o The RDLENGTH field is set to 16
o The RDATA field is set to the IPv6 address whose upper 96 bits are
Pref64::/96 and whose lower 32 bits are the IPv4 address from the
RDATA field of the A record.
Bagnulo, et al. Expires April 30, 2009 [Page 9]
Internet-Draft DNS64 October 2008
4. Solution space analysis
So far the document describes the basic functionality that seems
needed to perform the DNS64 function. However, there are several
open issues that require further discussion. This section present
the issues and several approaches to deal with them.
Having DNS synthesize AAAA records creates a number of issues, as
described in [RFC4966]:
o The synthesized AAAA records may leak outside their intended
scope;
o Dual-stack hosts may communicate with IPv4-only servers using IPv6
which is then translated to IPv4, rather than using their IPv4
connectivity;
o The IPv6-only hosts will be unable to use DNSSEC to verify the
legitimacy of the synthetic AAAA records.
o The DNS64 box needs to learn the Pref64::/96 used by the NAT64
box.
o Supporting the case of multiple NAT64 boxes with different
associated prefixes
4.1. Tagging synthetic RR
As a general architecture consideration, it seems a good approach to
preserve the transparency when a semantics of an existent protocol is
changed. In this case, it seems architecturally sound to tag the
synthetic RR, so they can be identified as synthetic and act
accordingly. There are several ways we can achieve that, but all
them impose some tradeoffs between architectural cleanness and
deployability.
One option to tag the synthetic RR would be to use a different RR
type i.e. not to synthesize AAAA RR but to create a new RR type e.g.
AAAASYNT that would be used in this cases. This seems
architecturally clean, but the problem is that the host needs to
explicitly ask for this new RR type and this is simply incompatible
with existing IPv6 hosts. In order to support this, we would need to
upgrade the hosts and if we are going to do that, we may as well
simply use the DNS64 stub resolver mode and reduce even more the
leaking probability. However, it is an explicit goal of DNS64/NAT64
to support unmodified IPv6 hosts, so this could be considered as an
optimization but we would still need to synthesize AAAA RR and we
still need to mark those.
Bagnulo, et al. Expires April 30, 2009 [Page 10]
Internet-Draft DNS64 October 2008
Another option is to create a new RR that would be included in the
additional information part of the DNS response, basically saying
that one or more of the RRs contained in the DNS response message are
synthetic. So, in this case, we could create a new AAAASYNT RR type
and queries could be accepted directly for this RR and when a AAAA RR
is synthesized for the correspondent FQDN, the AAAASYNT would be
included in the additional information part of the DNS response that
contains the synthetic AAAA RR. Of course, in order to benefit from
this mechanism, the receiving host needs to be upgraded to understand
the new AAAASYNT RR, but this is backward compatible, in the sense
that if the host does not understand the AAAASYNT RR it would still
use the AAAA RR and it would be able to communicate. In addition, a
host can query explicitly for the AAAASYNT RR and verify if a given
AAAA RR is synthetic or not. This would result in a sort of public
repository of synthetic AAAA RRs, which is useful for transparency.
One downside with this is that the tag is not directly associated
with the synthetic AAAA RR but is some additional information
contained in the DNS response. In this sense we are tagging the DNS
response message rather than tagging the synthetic RR. Such
additional information could be lost in caching servers or other
means of relying DNS information, losing the tag.
A somehow similar option as the previous one would be to use an EDNS0
option [RFC2671] to tag the DNS responses that contain one or more
synthetic AAAA RRs. There are however some additional issues with
this. The ENDS0 option can only be included if the DNS query
contained the EDNS0 option. It would also be possible to find out if
a given AAAA RR is synthetic, since the querying party could ask for
the AAAA RR and include the EDNS0 option.
Another option would be to use a well known prefix as the
Pref64::/96. In this case, we could assume that any AAAA RR
containing the well know Pref64::/96 is synthetic. This would
achieve tagging the RR itself, since this information can not be lost
in caching servers. However, making the assumption that all AAAA RRs
containing the well know prefix are synthetic may not be a good
option, since there may be cases (e.g. manual mappings in the NAT64),
where the AAAA RR containing the IPv6 address representing the IPv4
address using the well know prefix, are actually configured and
published in the DNS as real RR.
4.2. Dual stack nodes
When dual stack nodes are involved in the communication, the
potential issue is that they prefer translated connectivity over the
native connectivity. There are multiple ways to try to deal with
this issue, here we consider those related to DNS64.
Bagnulo, et al. Expires April 30, 2009 [Page 11]
Internet-Draft DNS64 October 2008
There are two different cases involving dual-stack nodes.
Communication initiated from a dual stack node towards an IPv4-only
node and communication initiated from an IPv6-only node towards a
dual stack node. We will next consider each one of these cases.
Communication initiated from an IPv6-only node towards a dual stack
node
In this case, the IPv6 only node will query for the FQDN of the dual
stack node. The DNS64 function will try first to get the AAAA RR.
Since there is one available, it will return it and no AAAA RR will
be synthesized from the A RR of the dual stack node. However, it
should be noted that the DNS64 must first try to get the real AAAA RR
before starting the synthesis, if not, it may result in the
aforementioned problem.
Communication initiated from a dual stack node toward an IPv4 only
node
Nodes that have both IPv6 and IPv4 connectivity and are configured
with an address for a DNS64 as their resolving nameserver may receive
responses containing synthetic AAAA resource records. If the node
prefers IPv6 over IPv4, using the addresses in the synthetic AAAA RRs
means that the node will attempt to communicate through the NAT64
mechanism first, and only fall back to native IPv4 connectivity if
connecting through NAT64 fails (if the application tries the full set
of destination addresses). We have multiple options to avoid this.
One option would be to configure the dual stack nodes not to use the
DNS64 option. This would mean that the server they are using should
not be performing this function (at least not for them). The
drawback of this option is that the translated connectivity would not
usable for backup purposes if the native connectivity is down.
The other option is that the dual stack nodes perform the DNS64 in
stub resolver mode. In this case, they know which RRs are synthetic
and so they know when the connectivity is translated and can be
avoided. The problem with this option is that it only works for
upgraded dual stack nodes and not with currently available nodes.
Another option is that dual stack nodes identify synthetic AAAA RR
from their tagging (whatever this is) and avoid using the translated
connectivity associated with the synthetic RR. However, again, this
option only works for upgraded nodes.
Another option not specific to DNS64 include using the RFC3484 policy
table e.g. configuring the Pref64::/96 as low priority preference in
the table. This option requires some mean to properly configure the
Bagnulo, et al. Expires April 30, 2009 [Page 12]
Internet-Draft DNS64 October 2008
policy table, which is not currently available (only manual
configuration is currently defined) (see
[I-D.ietf-6man-addr-select-sol] for more on this topic).
4.3. IPv6 nodes implementing DNSSEC
A server working in recursive mode can be security-aware or security-
oblivious. A security-aware recursive name server can be validating
or non-validating. Let's call these Rso (recursing, security
oblivious), Rsav (recursing, security aware and validating), and Rsan
(recursing, security aware and non-validating). In the cases below,
the R is also performing DNS64.
If a query comes in with the DO bit set, the querier is signalling
that it understands DNSSEC (but _not_ that it is validating, note).
If a query comes in with the CD bit set, it is an indication that the
querying agent does not want the server to perform all the checking
(i.e. that the querying agent wants all the validation data so it can
do checking itself).
These are the relevant cases:
1. Rso receives a query with the DO bit set, and CD not set. This
is just like the case of a non-DNS64 case: the server doesn't
support it, so the querying agent is out of luck. (The case
without DO set doesn't matter -- everyone's security-oblivious,
so we don't care.)
2. Rsan receives a query with DO bit set and CD not set. This case
is subject to local policy according to RFC 4035, AS.4.2:
A security-aware resolver MUST support the signature
verification mechanisms described in Section 5 and SHOULD
apply them to every received response, except when:
+ the security-aware resolver is part of a security-aware
recursive name server, and the response is the result of
recursion on behalf of a query received with the CD bit
set;
+ the response is the result of a query generated directly
via some form of application interface that instructed the
security-aware resolver not to perform validation for this
query; or
+ validation for this query has been disabled by local
policy.
Bagnulo, et al. Expires April 30, 2009 [Page 13]
Internet-Draft DNS64 October 2008
It's the last bullet that's relevant. Probably what the
implemented cases will do is hand back the data like normal.
Probably, then, this case devolves to case 1.
3. Rsan receives a query with DO bit set and CD set. In _this_
case, the Rsan is supposed to pass on all the data it gets to the
query initiator (this is in AS.3.2.2 of 4035). This is a case
that is going to be problematic for NAT64. If it modifies the
record, the client will get the data back and try to validate it,
and the data will be BOGUS as far as the client is concerned.
4. Rsav receives a query with DO bit not set and CD not set. In
this case, the Rsav validates the data. If it fails, it returns
RCODE 2 (SERVFAIL); otherwise, it returns the answer. This is
the case we're hoping for with DNS64-in-the-server, I think. The
Rsav validates the data, and then synthesizes the new record and
passes that to the client. (If the TTL is 0, there's no cache.
Are we sure that's what we want?)
5. Rsav receives a query with DO bit set and CD not set. This is
just like (4).
6. Rsave receives a query with DO bit set and CD set. This works
out to be like (3). The same thing will happen: the downstream
validator will mark the data BOGUS.
We can use the presence of the DO and CD bits to make some decisions
on what will happen in the following way:
1. If CD is not set and DO is not set, the server SHOULD perform
validation and do any translation it wants. The DNS64
functionality MAY translate the A record to AAAA.
2. If CD is not set and DO is set, then it SHOULD perform
validation. If the data validates, the server MAY perform
translation, but it MUST NOT set the AD bit. This is not great,
because a security-aware end point may want the security data,
and may want to pass it up to an application, and we're
effectively turning DNSSEC off at the translator. However, if
the data does not validate, it MUST respond with RCODE=2 (server
failure). This means that we still get the validation benefit in
fact. We're cheating the protocol some, though.
3. If the CD is set and DO is set, then it SHOULD NOT perform
validation, and it SHOULD NOT perform translation. It SHOULD
hand the data back to the query initiator, just like a regular
recursing server, and depend on the client to do the validation
and the translation itself. The disadvantage to this approach is
Bagnulo, et al. Expires April 30, 2009 [Page 14]
Internet-Draft DNS64 October 2008
that an end point that is translation-oblivious but security-
aware and validating simply won't be able to use the DNS64
functionality. This is problematic. For instance, I have a
validating recursive name server in my home network right now,
behind the NAT. It validates successfully, but it knows nothing
about DNS64. If my ISP introduced DNS64 and NAT64 functionality
today, this would break, and I would either have to install a
DNS64-aware system or else give up DNSSEC. On the other hand, it
seems to me that we're early enough in the DNSSEC deployment
today that the users of validation out at the edges are still a
reduced community, who can be persuaded to use DNS64 themselves.
How long this will be the case is not plain.
4.4. Learning the Pref64::/96 prefix
The only piece of information that needs to be shared between the
devices performing the NAT64 function and the devices performing the
DNS64 function is the prefix Pref64::/96. Note that the Pref64::/96
must be distributed to all the hosts that are performing the DNS64
function in stub-resolver mode and to all the name servers that are
performing the DNS64 function.
One option is to configure the Pref64::/96 manually in all these
devices. While this may work for servers, it doesn't seem the best
approach for stub-resolvers.
Another option is to define a DHCP option to carry this information.
The main issue here is the security, especially when this information
is used in conjunction with DNSSEC.
Another option is to store this information in a new RR under a well
known name within each domain. This information can then be signed
using DNSSEC so its distribution would be secured. One possibility
is to use a well know name, such as pref64.blah.com. Another
possibility is to put it in the reverse zone. So the DNS64-aware
system, as part of its initiation step, asks for the reverse lookup
of the configured-interface address (i.e. $reverseaddress.ip6.arpa)
but with the new RRTYPE (call it 64PREFIX). This way, the data can
be part of the signed reverse zone, it can get dynamically determined
as part of the protocol establishing the address of the end point,
and we don't have to reserve a new special well-known name.
4.5. Supporting multiple NAT64 boxes with different associated prefixes
Consider the case where we have a site with multiple NAT64 boxes.
Each of these boxes has a different prefix associated, namely
Pref64_1::/96, Pref64_2::/96, ..., Pref64_n::/96. suppose that the
site is using one or more servers using providing the DNS64 function.
Bagnulo, et al. Expires April 30, 2009 [Page 15]
Internet-Draft DNS64 October 2008
The question that we consider in this section is how these prefixes
are managed by the DNS64 function.
One option would be to configure only one prefix to each DNS64
device. In this case, we would achieve some form of load balance and
traffic engineering features, since the hosts configured to use a
given DNS64 server will use a given prefix and this means that their
traffic will flow through a given NAT64 box. The problem is what
happens if the NAT64 box fails. At that point, the DNS64 sever
should detect the failure and start using an alternative prefix.
(Note that is the NAT64 the one that have failed, but the DNS64
server is still working, so the host would not try an alternative
DNS64 in this failure mode)
The other option would be to configure multiple prefixes in each
DNS64 server. The next question is how these are managed? We can
envision several ways of managing the prefixes in the DNS64 server:
o One option is that the DNS64 synthesizes a single AAAA RR using a
randomly chosen prefix. This would result in load sharing across
the multiple NAT64 boxes. However, this would mean that a given
IPv6 host can use different IPv4 transport addresses in the IPv4
Internet. This is because the different synthesized AAAA RR
contain different prefixes and this means that the communication
is established through a different NAT64 box, hence using a
different IPv4 address. Moreover, it is also possible that when
an IPv6 hosts initiates two different communications using the
same IPv6 transport source address, these are routed through
different NAT64 boxes and they are presented to the IPv4 Internet
as coming from different IPv4 transport source address. While the
endpoint independence requirement doesn't cover the case of
multiple NATs, it does seems that this option is against the
endpoint independent behavior and should be avoided.
o Another option is to track the requesting hosts and always use the
same prefix for a given host. In case of failure, the DNS64
function should detect the NAT64 is down and start using a
different prefix (associated to a working NAT64 box). The
downside of this option is that the DNS64 function needs to keep
track of the hosts and prefixes and working NAT64 boxes.
o Another option is for the DNS64 to return a list of synthesized
AAAA RR, one per available prefix. Besides, the DNS64 function
should keep track of the hosts, so the same prefix order is used
in all the replies to the same host. In this case, the host will
normally use the first one if it is working, so it will always use
the same NAT64 box and if something fails, it should retry with an
alternative address, effectively using a different NAT64 box.
Bagnulo, et al. Expires April 30, 2009 [Page 16]
Internet-Draft DNS64 October 2008
This would provide the fault tolerance capabilities required
without need for the DNS64 to keep track of the state of the NAT64
boxes.
5. Application scenarios
In this section, we describe how to apply DNS64 to the suitable
scenarios described in draft-arkko-townsley-coexistence.
5.1. Enterprise IPv6 only network
The Enterprise 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.
+----+ +-------------+
| +------------------+IPv6 Internet+
| | +-------------+
IPv6 host-----------------+ GW |
| | +-------------+
| +------------------+IPv4 Internet+
+----+ +-------------+
|-------------------------public v6-----------------------------|
|-------public v6---------|NAT|----------public v4--------------|
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 in the name server or in the stub resolvers
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.
6. Additional Discussion
Bagnulo, et al. Expires April 30, 2009 [Page 17]
Internet-Draft DNS64 October 2008
6.1. About the Prefix used to map the IPv4 address space into IPv6
In the NAT64 approach, we need to represent the IPv4 addresses in the
IPv6 Internet. Since there is enough address space in IPv6, we can
easily embed the IPv4 address into an IPv6 address, so that the IPv4
address information can be extracted from the IPv6 address without
requiring additional state. One way to that is to use an IPv6 prefix
Pref64::/96 and juxtapose the IPv4 address at the end (there are
other ways of doing it, but we are not discussing the different
formats here). In this document the Pref64::/96 prefix is extracted
from the address block assigned to the site running the NAT64 box.
However, one could envision the usage of other prefixes for that
function. In particular, it would be possible to define a well-known
prefix that can be used by the NAT64 devices to map IPv4 (public)
addresses into IPv6 addresses, irrespectively of the address space of
the site where the NAT64 is located. In this section, we discuss the
pro and cons of the different options.
the different options for Pref64::/96 are the following
Local: A locally assigned prefix out of the address block of the
site running the NAT64 box
Well-known: A well known prefix that is reserved for this purpose.
We have the following different options:
IPv4 mapped prefix
IPv4 compatible prefix
A new prefix assigned by IANA for this purpose
The reasons why using a well-known prefix is attractive are the
following: Having a global well-known prefix would allow to identify
which addresses are "real" IPv6 addresses with native connectivity
and which addresses are IPv6 addresses that represent an IPv4
address. From an architectural perspective, it seems the right thing
to do to make this visible since hosts and applications could react
accordingly and avoid or prefer such type of connectivity if needed.
From the DNS64 perspective, using the well-known prefix would imply
that the same synthetic AAAA RR will be created throughout the IPv6
Internet, which would result in consistent view of the RR
irrespective of the location in the topology. From a more practical
perspective, having a well-known prefix would allow to completely
decouple the DNS64 from the NAT64, since the DNS64 would always use
the well-known prefix to create the synthetic AAAA RR and there is no
need to configure the same Pref64::/96 both in the DNS64 and the
NAT64 that work together.
Bagnulo, et al. Expires April 30, 2009 [Page 18]
Internet-Draft DNS64 October 2008
Among the different options available for the well-known prefix, the
option of using a pre-existing prefix such as the IPv4-mapped or
IPv4-compatible prefix has the advantage that would potentially allow
the default selection of native connectivity over translated
connectivity for legacy hosts in communications involving dual-stack
hosts. This is because current RFC3484 default policy table includes
entries for the IPv4-mapped prefix and the IPv4-compatible prefix,
implying that native IPv6 prefixes will be preferred over these.
However, current implementations do not use the IPv4-mapped prefix on
the wire, beating the purpose of support unmodified hosts. The IPv4-
compatible prefix is used by hosts on the wire, but has a higher
priority than the IPv4-mapped prefix, which implies that current
hosts would prefer translated connectivity over native IPv4
connectivity (represented by the IPv4-mapped prefix in the default
policy table). So neither of the prefixes that are present in the
default policy table would result in the legacy hosts preferring
native connectivity over translated connectivity, so it doesn't seem
to be a compelling reason to re-use either the IPv4-mapped or the
IPv4-compatible prefix for this. So, we conclude that among the well
known prefix options, the preferred option would be to ask for a new
prefix from IANA to be allocated for this.
However, there are several issues when considering using the well-
known prefix option, namely:
The well-known prefix is suitable only for mapping IPv4 public
addresses into IPv6. IPv4 public addresses can be mapped using
the same prefix because they are globally unique. However, the
well-known prefix is not suitable for mapping IPv4 private
addresses. This is so because we cannot leverage on the
uniqueness of the IPv4 address to achieve uniqueness of the IPv6
address, so we need to use a different IPv6 prefix to disambiguate
the different private IPv4 address realms. As we describe above,
there is a clear use case for mapping IPv4 private addresses, so
there is a pressing need to map IPv4 private addresses. In order
to do so we will need to use at least for IPv4 private addresses,
IPv6 local prefixes. In that case, the architectural goal of
distinguishing the "real" IPv6 addresses from the IPv6 addresses
that represent IPv4 addresses can no longer be achieved in a
general manner, making this option less attractive.
The usage of a single well-known prefix to map IPv4 addresses
irrespective of the NAT64 used, may result in failure modes in
sites that have more than one NAT64 device. The main problem is
that intra-site routing fluctuations that result in packets of an
ongoing communication flow through a different NAT64 box than the
one they were initially using (e.g. a change in an ECMP load
balancer), would break ongoing communications. This is so if the
Bagnulo, et al. Expires April 30, 2009 [Page 19]
Internet-Draft DNS64 October 2008
different NAT64 boxes use a different IPv4 address, so the IPv4
peer of the communications will receive packets coming from a
different IPv4 address. This is avoided using a local address,
since each NAT64 box can have a different Pref64::/96 associated,
so routing fluctuations would not result in using a different
NAT64 box.
The usage of a well-known prefix is also problematic in the case
that different routing domains want to exchange routing
information involving these routes. Consider the case of an IPv6
site that has multiple providers and that each of these providers
provides access to the IPv4 Internet using the well known prefix.
Consider the hypothetical case that different parts of the IPv4
Internet are reachable through different IPv6 ISPs (yes, this
means that in a futuristic scenario, the IPv4 Internet is
partitioned). In order to reach the different parts through the
different ISPs, more specific routes representing the different
IPv4 destinations reachable need to be injected in the IPv6 sites.
This basically means that such configuration would imply to import
the IPv4 routing entropy into the IPv6 routing system. If
different local prefixes are used, then each ISP only announces
its own local prefix, and then the burden of defining which IPv4
destination is reachable through which ISP is placed somewhere
else (e.g. in the DNS64).
7. Security Considerations
See the discussion on the usage of DNSSEC and DNS64 described in the
analysis section.
8. IANA Considerations
9. Changes from Previous Draft Versions
Note to RFC Editor: Please remove this section prior to publication
of this document as an RFC.
[[This section lists the changes between the various versions of this
draft.]]
10. Contributors
Bagnulo, et al. Expires April 30, 2009 [Page 20]
Internet-Draft DNS64 October 2008
11. Acknowledgements
This draft has benefited from the review from Dave Thaler.
This draft contains the result of discussions involving many people,
including: Dan Wing, Jari Arkko, Mark Townsley, Fred Baker, Xing Li,
Hiroshi Miyata, Brian Carpenter, Ed Jankiewicz, Magnus Westerlund.
Marcelo Bagnulo and Iljitsch van Beijnum are partly funded by
Trilogy, a research project supported by the European Commission
under its Seventh Framework Program.
12. References
12.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)",
RFC 2671, August 1999.
[RFC2765] Nordmark, E., "Stateless IP/ICMP Translation Algorithm
(SIIT)", RFC 2765, February 2000.
[RFC4787] Audet, F. and C. Jennings, "Network Address Translation
(NAT) Behavioral Requirements for Unicast UDP", BCP 127,
RFC 4787, January 2007.
[I-D.ietf-behave-tcp]
Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P.
Srisuresh, "NAT Behavioral Requirements for TCP",
draft-ietf-behave-tcp-08 (work in progress),
September 2008.
[I-D.ietf-behave-nat-icmp]
Srisuresh, P., Ford, B., Sivakumar, S., and S. Guha, "NAT
Behavioral Requirements for ICMP protocol",
draft-ietf-behave-nat-icmp-10 (work in progress),
October 2008.
[I-D.bagnulo-behave-nat64]
Bagnulo, M., Matthews, P., and I. Beijnum, "NAT64/DNS64:
Network Address and Protocol Translation from IPv6 Clients
Bagnulo, et al. Expires April 30, 2009 [Page 21]
Internet-Draft DNS64 October 2008
to IPv4 Servers", draft-bagnulo-behave-nat64-01 (work in
progress), September 2008.
12.2. Informative References
[RFC2766] Tsirtsis, G. and P. Srisuresh, "Network Address
Translation - Protocol Translation (NAT-PT)", RFC 2766,
February 2000.
[RFC1858] Ziemba, G., Reed, D., and P. Traina, "Security
Considerations for IP Fragment Filtering", RFC 1858,
October 1995.
[RFC3128] Miller, I., "Protection Against a Variant of the Tiny
Fragment Attack (RFC 1858)", RFC 3128, June 2001.
[RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network
Address Translator (Traditional NAT)", RFC 3022,
January 2001.
[RFC4966] Aoun, C. and E. Davies, "Reasons to Move the Network
Address Translator - Protocol Translator (NAT-PT) to
Historic Status", RFC 4966, July 2007.
[I-D.ietf-mmusic-ice]
Rosenberg, J., "Interactive Connectivity Establishment
(ICE): A Protocol for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols",
draft-ietf-mmusic-ice-19 (work in progress), October 2007.
[I-D.ietf-6man-addr-select-sol]
Matsumoto, A., Fujisaki, T., Hiromi, R., and K. Kanayama,
"Solution approaches for address-selection problems",
draft-ietf-6man-addr-select-sol-01 (work in progress),
June 2008.
[RFC3498] Kuhfeld, J., Johnson, J., and M. Thatcher, "Definitions of
Managed Objects for Synchronous Optical Network (SONET)
Linear Automatic Protection Switching (APS)
Architectures", RFC 3498, March 2003.
Bagnulo, et al. Expires April 30, 2009 [Page 22]
Internet-Draft DNS64 October 2008
Authors' Addresses
Marcelo Bagnulo
UC3M
Av. Universidad 30
Leganes, Madrid 28911
Spain
Phone: +34-91-6249500
Fax:
Email: marcelo@it.uc3m.es
URI: http://www.it.uc3m.es/marcelo
Philip Matthews
Unaffiliated
Email: philip_matthews@magma.ca
URI:
Iljitsch van Beijnum
IMDEA Networks
Av. Universidad 30
Leganes, Madrid 28911
Spain
Phone: +34-91-6246245
Email: iljitsch@muada.com
Andrew Sullivan
Shinkuro
Email: ajs@shinkuro.com
Bagnulo, et al. Expires April 30, 2009 [Page 23]
Internet-Draft DNS64 October 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.
Bagnulo, et al. Expires April 30, 2009 [Page 24]