BEHAVE WG M. Bagnulo
Internet-Draft UC3M
Intended status: Standards Track A. Sullivan
Expires: June 18, 2010 Shinkuro
P. Matthews
Alcatel-Lucent
I. van Beijnum
IMDEA Networks
December 15, 2009
DNS64: DNS extensions for Network Address Translation from IPv6 Clients
to IPv4 Servers
draft-ietf-behave-dns64-03
Abstract
DNS64 is a mechanism for synthesizing AAAA records from A records.
DNS64 is used with 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 provides suggestions on how it should be
deployed in conjunction with IPv6/IPv4 translators.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and 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 June 18, 2010.
Bagnulo, et al. Expires June 18, 2010 [Page 1]
Internet-Draft DNS64 December 2009
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the BSD License.
Bagnulo, et al. Expires June 18, 2010 [Page 2]
Internet-Draft DNS64 December 2009
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Background to DNS64 - DNSSEC interaction . . . . . . . . . . . 6
4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 8
5. DNS64 Normative Specification . . . . . . . . . . . . . . . . 9
5.1. Resolving AAAA queries and the answer section . . . . . . 9
5.1.1. The answer when there is AAAA data available . . . . . 9
5.1.2. The answer when there is an error . . . . . . . . . . 9
5.1.3. Special exclusion set for AAAA records . . . . . . . . 10
5.1.4. Dealing with CNAME and DNAME . . . . . . . . . . . . . 10
5.1.5. Data for the answer when performing synthesis . . . . 11
5.1.6. Performing the synthesis . . . . . . . . . . . . . . . 11
5.1.7. Querying in parallel . . . . . . . . . . . . . . . . . 11
5.2. Generation of the IPv6 representations of IPv4
addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
5.3. Handling other RRs and the Additional Section . . . . . . 13
5.3.1. PTR queries . . . . . . . . . . . . . . . . . . . . . 13
5.3.2. Handling the additional section . . . . . . . . . . . 14
5.3.3. Other records . . . . . . . . . . . . . . . . . . . . 14
5.4. Assembling a synthesized response to a AAAA query . . . . 14
5.5. DNSSEC processing: DNS64 in recursive server mode . . . . 14
6. Deployment notes . . . . . . . . . . . . . . . . . . . . . . . 16
6.1. DNS resolvers and DNS64 . . . . . . . . . . . . . . . . . 16
6.2. DNSSEC validators and DNS64 . . . . . . . . . . . . . . . 16
6.3. DNS64 and multihomed and dual-stack hosts . . . . . . . . 16
6.3.1. IPv6 multihomed hosts . . . . . . . . . . . . . . . . 16
6.3.2. Accidental dual-stack DNS64 use . . . . . . . . . . . 17
6.3.3. Intentional dual-stack DNS64 use . . . . . . . . . . . 17
7. Security Considerations . . . . . . . . . . . . . . . . . . . 17
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 18
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
10.1. Normative References . . . . . . . . . . . . . . . . . . . 18
10.2. Informative References . . . . . . . . . . . . . . . . . . 19
Appendix A. Deployment scenarios and examples . . . . . . . . . . 21
A.1. IPv6/IPv4 address transformation algorithm . . . . . . . . 22
A.2. An-IPv6-network-to-IPv4-Internet setup with DNS64 in
DNS server mode . . . . . . . . . . . . . . . . . . . . . 23
A.3. An-IPv6-network-to-IPv4-Internet setup with DNS64 in
stub-resolver mode . . . . . . . . . . . . . . . . . . . . 24
A.4. IPv6-Internet-to-an-IPv4-network setup DNS64 in DNS
server mode . . . . . . . . . . . . . . . . . . . . . . . 26
Appendix B. Motivations and Implications of synthesizing AAAA
RR when real AAAA RR exists . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29
Bagnulo, et al. Expires June 18, 2010 [Page 3]
Internet-Draft DNS64 December 2009
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 an IPv6/IPv4 translator such as NAT64
[I-D.ietf-behave-v6v4-xlate-stateful], allows an IPv6-only client to
initiate communications by name to an IPv4-only server.
DNS64 is a mechanism for synthesizing AAAA resource records (RRs)
from A RRs. A synthetic AAAA RR created by the DNS64 from an
original A RR contains the same FQDN of the original A RR but it
contains an IPv6 address instead of an IPv4 address. The IPv6
address is an IPv6 representation of the IPv4 address contained in
the original A RR. The IPv6 representation of the IPv4 address is
algorithmically generated from the IPv4 address returned in the A RR
and a set of parameters configured in the DNS64 (typically, an IPv6
prefix used by IPv6 representations of IPv4 addresses and optionally
other parameters).
Together with a IPv6/IPv4 translator, 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
is likely that in the future, many IPv6-only clients will want to
connect to IPv4-only servers. In the typical case, the approach only
requires the deployment of IPv6/IPv4 translators that connect an
IPv6-only network to an IPv4-only network, along with the deployment
of one or more DNS64-enabled name servers. However, some advanced
features require performing the DNS64 function directly by the end-
hosts themselves.
2. Overview
This section provides a non-normative introduction to the DNS64
mechanism.
We assume that we have an IPv6/IPv4 translator box connecting an IPv4
network and an IPv6 network. The IPv6/IPv4 translator device
provides translation services between the two networks enabling
communication between IPv4-only hosts and IPv6-only hosts. (NOTE: By
IPv6-only hosts we mean hosts running IPv6-only applications, hosts
that can only use IPv6, as well as the cases where only IPv6
connectivity is available to the client. By IPv4-only servers we
mean servers running IPv4-only applications, servers that can only
use IPv4, as well as the cases where only IPv4 connectivity is
Bagnulo, et al. Expires June 18, 2010 [Page 4]
Internet-Draft DNS64 December 2009
available to the server). The IPv6/IPv4 translator used in
conjunction with DNS64 must allow communications initiated from the
IPv6-only host to the IPv4-only host.
To allow an IPv6 initiator to do a standard AAAA RR DNS lookup to
learn the address of the responder, DNS64 is used to synthesize a
AAAA record from an A record containing a real IPv4 address of the
responder, whenever the DNS64 service cannot retrieve a AAAA record
for the requested host name. The DNS64 device appears as a regular
recursive resolver for the IPv6 initiator. The DNS64 box receives an
AAAA DNS query generated by the IPv6 initiator. It first attempts a
recursive resolution for the requested AAAA records. 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 A records. If any A records are discovered, DNS64 creates a
synthetic AAAA RR from the information retrieved in each A RR.
The FQDN of a synthetic AAAA RR is the same as that of the original A
RR, but an IPv6 representation of the IPv4 address contained in the
original A RR is included in the AAAA RR. The IPv6 representation of
the IPv4 address is algorithmically generated from the IPv4 address
and additional parameters configured in the DNS64. Among those
parameters configured in the DNS64, there is at least one IPv6
prefix, called Pref64::/n. The IPv6 address representing IPv4
addresses included in the AAAA RR synthesized by the DNS64 function
contain Pref64::/n and they also embed the original IPv4 address.
The same algorithm and the same Pref64::/n prefix or prefixes must be
configured both in the DNS64 device and the IPv6/IPv4 translator, so
that both can algorithmically generate the same IPv6 representation
for a given IPv4 address. In addition, it is required that IPv6
packets addressed to an IPv6 destination that contains the Pref64::/n
be delivered to the IPv6/IPv4 translator, so they can be translated
into IPv4 packets.
Once the DNS64 has synthesized the AAAA RR, the synthetic AAAA RR is
passed back to the IPv6 initiator, which will initiate an IPv6
communication with the IPv6 address associated with the IPv4
receiver. The packet will be routed to the IPv6/IPv4 translator
which will forward it to the IPv4 network .
In general, the only shared state between the DNS64 and the IPv6/IPv4
translator is the Pref64::/n and an optional set of static
parameters. The Pref64::/n and the set of static parameters must be
configured to be the same on both; there is no communication between
the DNS64 device and IPv6/IPv4 translator functions. The mechanism
to be used for configuring the parameters of the DNS64 is beyond the
scope of this memo.
Bagnulo, et al. Expires June 18, 2010 [Page 5]
Internet-Draft DNS64 December 2009
The prefixes to be used as Pref64::/n and their applicability are
discussed in [I-D.ietf-behave-address-format]. There are two types
of prefixes that can be used as Pref64::/n.
The Pref64::/n can be the Well-Known prefix 64:FF9B::/96 reserved
by [I-D.ietf-behave-address-format] for the purpose of
representing IPv4 addresses in IPv6 address space.
The Pref64::/n can be a Network Specific Prefix (NSP). An NSP is
an IPv6 prefix assigned by an organization for to create IPv6
representations of IPv4 addresses.
The main different in the nature of the two types of prefixes is that
the NSP is a locally assigned prefix that is under control of the
organization that is providing the translation services, while the
Well-Known prefix is a prefix that has a global meaning since it has
been assigned for the specific purpose of representing IPv4 addresses
in IPv6 address space.
The DNS64 function can be performed in two places.
One option is to locate the DNS64 function in recursive name
servers serving end hosts. In this case, when an IPv6-only host
queries the name server for AAAA RRs for an IPv4-only host, the
name server can perform the synthesis of AAAA RRs and pass them
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. This mode is called "DNS64 in DNS
server mode".
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 AAAA RRs for
internal usage. 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. This mode is called "DNS64 in stub-
resolver mode"".
3. Background to DNS64 - DNSSEC interaction
DNSSEC presents a special challenge for DNS64, because DNSSEC is
designed to detect changes to DNS answers, and DNS64 may alter
answers coming from an authoritative server.
A recursive resolver can be security-aware or security-oblivious.
Bagnulo, et al. Expires June 18, 2010 [Page 6]
Internet-Draft DNS64 December 2009
Moreover, a security-aware recursive name server can be validating or
non-validating, according to operator policy. In the cases below,
the recursive server is also performing DNS64, and has a local policy
to validate. We call this general case vDNS64, but in all the cases
below the DNS64 functionality should be assumed needed.
DNSSEC includes some signaling bits that offer some indicators of
what the query originator understands.
If a query arrives at a vDNS64 device with the DO bit set, the query
originator is signaling that it understands DNSSEC. The DO bit does
not indicate that the query originator will validate the response.
It only means that the query originator can understand responses
containing DNSSEC data. Conversely, if the DO bit is clear, that is
evidence that the querying agent is not aware of DNSSEC.
If a query arrives at a vDNS64 device with the CD bit set, it is an
indication that the querying agent wants all the validation data so
it can do checking itself. By local policy, vDNS64 could still
validate, but it must return all data to the querying agent anyway.
Here are the possible cases:
1. A security-oblivious DNS64 node receives a query with the DO bit
clear. In this case, DNSSEC is not a concern, because the
querying agent does not understand DNSSEC responses.
2. A security-oblivious DNS64 node receives a query with the DO bit
set, and the CD bit clear. 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.
3. A security-aware and non-validating DNS64 node receives a query
with the DO bit set and the CD bit clear. Such a resolver is not
validating responses, likely due to local policy (see [RFC4035],
section 4.2). For that reason, this case amounts to the same as
the previous case, and no validation happens.
4. A security-aware and non-validating DNS64 node receives a query
with the DO bit set and the CD bit set. In this case, the
resolver is supposed to pass on all the data it gets to the query
initiator (see section 3.2.2 of [RFC4035]). This case will be
problematic with DNS64. If the DNS64 server modifies the record,
the client will get the data back and try to validate it, and the
data will be invalid as far as the client is concerned.
5. A security-aware and validating DNS64 node receives a query with
the DO bit clear and CD clear. In this case, the resolver
Bagnulo, et al. Expires June 18, 2010 [Page 7]
Internet-Draft DNS64 December 2009
validates the data. If it fails, it returns RCODE 2 (SERVFAIL);
otherwise, it returns the answer. This is the ideal case for
vDNS64. The resolver validates the data, and then synthesizes
the new record and passes that to the client. The client, which
is presumably not validating (else it would have set DO and CD),
cannot tell that DNS64 is involved.
6. A security-aware and validating DNS64 node receives a query with
the DO bit set and CD clear. In principle, this ought to work
like the previous case, except that the resolver should also set
the AD bit on the response.
7. A security-aware and validating DNS64 node receives a query with
the DO bit set and CD set. This is effectively the same as the
case where a security-aware and non-validating recursive resolver
receives a similar query, and the same thing will happen: the
downstream validator will mark the data as invalid if DNS64 has
performed synthesis.
4. Terminology
This section provides definitions for the special terms used in the
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].
Authoritative server: A DNS server that can answer authoritatively a
given DNS question.
DNS64: A logical function that synthesizes DNS resource records (e.g
AAAA records containing IPv6 addresses) from DNS resource records
actually contained in the global DNS (e.g. A records containing
IPv4 addresses).
DNS64 recursor: A recursive resolver that provides the DNS64
functionality as part of its operation.
Recursive resolver: A DNS server that accepts requests from one
resolver, and asks another resolver for the answer on behalf of
the first resolver.
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.
Bagnulo, et al. Expires June 18, 2010 [Page 8]
Internet-Draft DNS64 December 2009
IPv6/IPv4 translator: A device that translates IPv6 packets to IPv4
packets and vice-versa. It is only required that the
communication initiated from the IPv6 side be supported.
For a detailed understanding of this document, the reader should also
be familiar with DNS terminology from [RFC1034],[RFC1035] and current
NAT terminology from [RFC4787]. Some parts of this document assume
familiarity with the terminology of the DNS security extensions
outlined in [RFC4035].
5. DNS64 Normative Specification
A DNS64 is a logical function that synthesizes AAAA records from A
records. The DNS64 function may be implemented in a stub resolver,
in a recursive resolver, or in an authoritative name server.
The implementation SHOULD support mapping of IPv4 address ranges to
separate IPv6 prefixes for AAAA record synthesis. This allows
handling of special use IPv4 addresses [I-D.iana-rfc3330bis].
Multicast address handling is further specified in
[I-D.venaas-behave-mcast46].
5.1. Resolving AAAA queries and the answer section
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,
either by performing a query or, in the case of an authoritative
server, by examining its own results.
5.1.1. The answer when there is AAAA data available
If the query results in one or more AAAA records in the answer
section, the result is returned to the requesting client as per
normal DNS semantics, except in the case where any of the AAAA
records match a special exclusion set of prefixes, considered in
Section 5.1.3. If there is (non-excluded) AAAA data available, DNS64
SHOULD NOT include synthetic AAAA RRs in the response (see Appendix B
for an analysis of the motivations for and the implications of not
complying with this recommendation). By default DNS64
implementations MUST NOT synthesize AAAA RRs when real AAAA RRs
exist.
5.1.2. The answer when there is an error
If the query results in a response with an error code other than 0,
the result is handled according to normal DNS operation -- that is,
either the resolver tries again using a different server from the
Bagnulo, et al. Expires June 18, 2010 [Page 9]
Internet-Draft DNS64 December 2009
authoritative NS RRSet, or it returns the error to the client. This
stage is still prior to any synthesis having happened, so a response
to be returned to the client does not need any special assembly than
would usually happen in DNS operation.
5.1.3. Special exclusion set for AAAA records
Some IPv6 addresses are not actually usable by IPv6-only hosts. If
they are returned to IPv6-only querying agents as AAAA records,
therefore, the goal of decreasing the number of failure modes will
not be attained. Examples include AAAA records with addresses in the
::ffff/96 network, and possibly (depending on the context) AAAA
records with the site's Pref::64/n or the Well-Known prefix (see
below for more about the Well-Known prefix). A DNS64 implementation
SHOULD provide a mechanism to specify IPv6 prefix ranges to be
treated as though the AAAA containing them were an empty answer. An
implementation SHOULD include the ::ffff/96 network in that range by
default. Failure to provide this facility will mean that clients
querying the DNS64 function may not be able to communicate with hosts
that would be reachable from a dial-stack host.
When the DNS64 performs its initial AAAA query, if it receives an
answer with only AAAA records containing addresses in the target
range(s), then it MUST treat the answer as though it were an empty
answer, and proceed accordingly. If it receives an answer with at
least one AAAA record containing an address outside any of the target
ranges, then it MAY build an answer section for a response including
only the AAAA record(s) that do not contain any of the addresses
inside the excluded ranges. That answer section is used in the
assembly of a response as detailed in Section 5.4. Alternatively, it
MAY treat the answer as though it were an empty answer, and proceed
accordingly. It MUST NOT return the offending AAAA records as part
of a response.
5.1.4. Dealing with CNAME and DNAME
If the response contains a CNAME or a DNAME, then the CNAME or DNAME
chain is followed until the first terminating A or AAAA record is
reached. This may require the DNS64 to ask for an A record, in case
the response to the original AAAA query is a CNAME or DNAME without
an AAAA record to follow. The resulting AAAA or A record is treated
like any other AAAA or A case, as appropriate.
When assembling the answer section, the original CNAME or DNAME RR is
included as part of the answer, and the synthetic AAAA, if
appropriate, is included.
Bagnulo, et al. Expires June 18, 2010 [Page 10]
Internet-Draft DNS64 December 2009
5.1.5. Data for the answer when performing synthesis
If the query results in no error but an empty answer section in the
response, the DNS64 resolver attempts to retrieve A records for the
name in question. If this new A RR query results in an empty answer
or in an error, then the empty result or error is used as the basis
for the answer returned to the querying client. (Transient errors
may result in retrying the query, depending on the operation of the
resolver; this is just as in Section 5.1.2.) If instead the query
results in one or more A RRs, the DNS64 synthesizes AAAA RRs based on
the A RRs according to the procedure outlined in Section 5.1.6. The
DNS64 resolver then returns the synthesized AAAA records in the
answer section to the client, removing the A records that form the
basis of the synthesis.
5.1.6. Performing the synthesis
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 the minimum of the TTL of the original A
RR and the SOA RR for the queried domain. (Note that in order to
obtain the TTL of the SOA RR the DNS64 does not need to perform a
new query, but it can remember the TTL from the SOA RR in the
negative response to the AAAA query).
o The RDLENGTH field is set to 16
o The RDATA field is set to the IPv6 representation of the IPv4
address from the RDATA field of the A record. The DNS64 SHOULD
check each A RR against IPv4 address ranges and select the
corresponding IPv6 prefix to use in synthesizing the AAAA RR. See
Section 5.2 for discussion of the algorithms to be used in
effecting the transformation.
5.1.7. Querying in parallel
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 no AAAA RR
synthesis is required. A possible trade-off would be to perform them
sequentially but with a very short interval between them, so if we
obtain a fast reply, we avoid doing the additional query. (Note that
Bagnulo, et al. Expires June 18, 2010 [Page 11]
Internet-Draft DNS64 December 2009
this discussion is relevant only if the DNS64 function needs to
perform external queries to fetch the RR. If the needed RR
information is available locally, as in the case of an authoritative
server, the issue is no longer relevant.)
5.2. Generation of the IPv6 representations of IPv4 addresses
DNS64 supports multiple algorithms for the generation of the IPv6
representation of an IPv4 address. The constraints imposed on the
generation algorithms are the following:
The same algorithm to create an IPv6 address from an IPv4 address
MUST be used by both 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 by the IPv6/IPv4 translator 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.
The algorithm MUST be reversible, i.e. it MUST be possible to
extract the original IPv4 address from the IPv6 representation.
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 DNS64 (such as fixed string to be used as a
suffix).
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 MUST use the Well-Known prefix 64:
FF9B::/96 defined in [I-D.ietf-behave-address-format]
[[anchor9: Note in document: The value 64:FF9B::/96 is proposed as
the value for the Well-Known prefix and needs to be confirmed
whenis published as RFC.]][I-D.ietf-behave-address-format]
DNS64 MUST support the algorithm for generating IPv6 representations
of IPv4 addresses defined Section 2 of
[I-D.ietf-behave-address-format]. Moreover, the aforementioned
algorithm MUST be the default algorithm used by DNS64. While the
normative description of the algorithm is provided in
[I-D.ietf-behave-address-format], an sample description of the
algorithm and its application to different scenarios is provided in
Appendix A for illustration purposes.
Bagnulo, et al. Expires June 18, 2010 [Page 12]
Internet-Draft DNS64 December 2009
5.3. Handling other RRs and the Additional Section
5.3.1. PTR queries
If a DNS64 nameserver receives a PTR query for a record in the
IP6.ARPA domain, it MUST strip the IP6.ARPA labels from the QNAME,
reverse the address portion of the QNAME according to the encoding
scheme outlined in section 2.5 of [RFC3596] , and examine the
resulting address to see whether its prefix matches the locally-
configured Pref64::/n. There are two alternatives for a DNS64
nameserver to respond to such PTR queries. A DNS64 node MUST provide
one of these, and SHOULD NOT provide both at the same time unless
different IP6.ARPA zones require answers of different sorts.
The first option is for the DNS64 nameserver to respond
authoritatively for its prefixes. If the address prefix matches any
Pref64::/n used in the site, either a NSP prefix or the Well-Known
prefix used for NAT64 (i.e. 64:FF9B::/96) as defined in
[I-D.ietf-behave-address-format], then the DNS64 server MAY answer
the query using locally-appropriate RDATA. The DNS64 server MAY use
the same RDATA for all answers. Note that the requirement is to
match any Pref64::/n used at the site, and not merely the locally-
configured Pref64::/n. This is because end clients could ask for a
PTR record matching an address received through a different (site-
provided) DNS64, and if this strategy is in effect, those queries
should never be sent to the global DNS. The advantage of this
strategy is that it makes plain to the querying client that the
prefix is one operated by the DNS64 site, and that the answers the
client is getting are generated by the DNS64. The disadvantage is
that any useful reverse-tree information that might be in the global
DNS is unavailable to the clients querying the DNS64.
The second option is for the DNS64 nameserver to synthesize a CNAME
mapping the IP6.ARPA namespace to the corresponding IN-ADDR.ARPA
name. The rest of the response would be the normal DNS processing.
The CNAME can be signed on the fly if need be. The advantage of this
approach is that any useful information in the reverse tree is
available to the querying client. The disadvantage is that it adds
additional load to the DNS64 (because CNAMEs have to be synthesized
for each PTR query that matches the Pref64::/n), and that it may
require signing on the fly. In addition, the generated CNAME could
correspond to an unpopulated in-addr.arpa zone, so the CNAME would
provide a reference to a non-existent record.
If the address prefix does not match any of the Pref64::/n, then the
DNS64 server MUST process the query as though it were any other query
-- i.e. a recursive nameserver MUST attempt to resolve the query as
though it were any other (non-A/AAAA) query, and an authoritative
Bagnulo, et al. Expires June 18, 2010 [Page 13]
Internet-Draft DNS64 December 2009
server MUST respond authoritatively or with a referral, as
appropriate.
5.3.2. Handling the additional section
DNS64 synthesis MUST NOT be performed on any records in the
additional section of synthesized answers. The DNS64 MUST pass the
additional section unchanged.
5.3.3. Other records
If the DNS64 is in recursive resolver mode, then it SHOULD also serve
the zones specified in [I-D.ietf-dnsop-default-local-zones], rather
than forwarding those queries elsewhere to be handled.
All other RRs MUST be returned unchanged.
5.4. Assembling a synthesized response to a AAAA query
The DNS64 uses different pieces of data to build the response
returned to the querying client.
The query that is used as the basis for synthesis results either in
an error, an answer that can be used as a basis for synthesis, or an
empty (authoritative) answer. If there is an empty answer, then the
DNS64 responds to the original querying client with the answer the
DNS64 received to the original AAAA query. Otherwise, the response
is assembled as follows.
The header fields are set according to the usual rules for recursive
or authoritative servers, depending on the role that the DNS64 is
serving. The question section is copied from the original AAAA
query. The answer section is populated according to the rules in
Section 5.1.6. The authority and additional sections are copied from
the response to the A query that the DNS64 performed.
5.5. DNSSEC processing: DNS64 in recursive server mode
We consider the case where the recursive server that is performing
DNS64 also has a local policy to validate the answers according to
the procedures outlined in [RFC4035] Section 5. We call this general
case vDNS64.
The vDNS64 uses the presence of the DO and CD bits to make some
decisions about what the query originator needs, and can react
accordingly:
Bagnulo, et al. Expires June 18, 2010 [Page 14]
Internet-Draft DNS64 December 2009
1. If CD is not set and DO is not set, vDNS64 SHOULD perform
validation and do synthesis as needed.
2. If CD is not set and DO is set, then vDNS64 SHOULD perform
validation. Whenever vDNS64 performs validation, it MUST
validate the negative answer for AAAA queries before proceeding
to query for A records for the same name, in order to be sure
that there is not a legitimate AAAA record on the Internet.
Failing to observe this step would allow an attacker to use DNS64
as a mechanism to circumvent DNSSEC. If the negative response
validates, and the response to the A query validates, then the
vDNS64 MAY perform synthesis and SHOULD set the AD bit in the
answer to the client. This is acceptable, because [RFC4035],
section 3.2.3 says that the AD bit is set by the name server side
of a security-aware recursive name server if and only if it
considers all the RRSets in the Answer and Authority sections to
be authentic. In this case, the name server has reason to
believe the RRSets are all authentic, so it SHOULD set the AD
bit. If the data does not validate, the vDNS64 MUST respond with
RCODE=2 (server failure).
A security-aware end point might take the presence of the AD bit
as an indication that the data is valid, and may pass the DNS
(and DNSSEC) data to an application. If the application attempts
to validate the synthesized data, of course, the validation will
fail. One could argue therefore that this approach is not
desirable. But security aware stub resolvers MUST NOT place any
reliance on data received from resolvers and validated on their
behalf without certain criteria established by [RFC4035], section
4.9.3. An application that wants to perform validation on its
own should use the CD bit.
3. If the CD bit is set and DO is set, then vDNS64 MAY perform
validation, but MUST NOT perform synthesis. It MUST hand the
data back to the query initiator, just like a regular recursive
resolver, and depend on the client to do the validation and the
synthesis itself.
The disadvantage to this approach is that an end point that is
translation-oblivious but security-aware and validating will not
be able to use the DNS64 functionality. In this case, the end
point will not have the desired benefit of NAT64. In effect,
this strategy means that any end point that wishes to do
validation in a NAT64 context must be upgraded to be translation-
aware as well.
Bagnulo, et al. Expires June 18, 2010 [Page 15]
Internet-Draft DNS64 December 2009
6. Deployment notes
While DNS64 is intended to be part of a strategy for aiding IPv6
deployment in an internetworking environment with some IPv4-only and
IPv6-only networks, it is important to realise that it is
incompatible with some things that may be deployed in an IPv4-only or
dual-stack context.
6.1. DNS resolvers and DNS64
Full-service resolvers that are unaware of the DNS64 function can be
(mis)configured to act as mixed-mode iterative and forwarding
resolvers. In a native-IPv4 context, this sort of configuration may
appear to work. It is impossible to make it work properly without it
being aware of the DNS64 function, because it will likely at some
point obtain IPv4-only glue records and attempt to use them for
resolution. The result that is returned will contain only A records,
and without the ability to perform the DNS64 function the resolver
will simply be unable to answer the necessary AAAA queries.
6.2. DNSSEC validators and DNS64
Existing DNSSEC validators (i.e. that are unaware of DNS64) will
reject all the data that comes from the DNS64 as having been tampered
with. If it is necessary to have validation behind the DNS64, then
the validator must know how to perform the DNS64 function itself.
Alternatively, the validating host may establish a trusted connection
with the DNS64, and allow the DNS64 to do all validation on its
behalf.
6.3. DNS64 and multihomed and dual-stack hosts
6.3.1. IPv6 multihomed hosts
Synthetic AAAA records may be constructed on the basis of the network
context in which they were constructed. If a host sends DNS queries
to resolvers in multiple networks, it is possible that some of them
will receive answers from a DNS64 without all of them being connected
via a NAT64. For instance, suppose a system has two interfaces, i1
and i2. Whereas i1 is connected to the IPv4 Internet via NAT64, i2
has native IPv6 connectivity only. I1 might receive a AAAA answer
from a DNS64 that is configured for a particular NAT64; the IPv6
address contained in that AAAA answer will not connect with anything
via i2.
This example illustrates why it is generally preferable that hosts
treat DNS answers from one interface as local to that interface. The
answer received on one interface will not work on the other
Bagnulo, et al. Expires June 18, 2010 [Page 16]
Internet-Draft DNS64 December 2009
interface. Hosts that attempt to use DNS answers globally may
encounter surprising failures in these cases. For more discussion of
this topic, see [I-D.savolainen-mif-dns-server-selection].
Note that the issue is not that there are two interfaces, but that
there are two networks involved. The same results could be achieved
with a single interface routed to two different networks.
6.3.2. Accidental dual-stack DNS64 use
Similarly, suppose that i1 has IPv6 connectivity and can connect to
the IPv4 Internet through NAT64, but i2 has IPv4 native transit. In
this case, i1 could receive an IPv6 address from a synthetic AAAA
that would better be reached via native IPv4 transit. Again, it is
worth emphasising that this arises because there are two networks
involved.
Since it is most likely that the host will attempt AAAA resolution
first, in this arrangement the host will often use the NAT64 when a
native IPv4 would be preferable. For this reason, hosts with IPv4
connectivity to the Internet should avoid using DNS64. This can be
partly resolved by ISPs when providing DNS resolvers to clients, but
that is not a guarantee that the NAT64 will never be used when a
native IPv4 connection should be used. There is no general-purpose
mechanism to ensure that native IPv4 transit will always be
preferred, because to a DNS64-oblivious host, the DNS64 looks just
like an ordinary DNS server. Operators of a NAT64 should expect
traffic to pass through the NAT64 even when it is not necessary.
6.3.3. Intentional dual-stack DNS64 use
Finally, consider the case where the IPv4 connectivity on i2 is only
to a LAN, with an IPv6-only connection on i1 to the Internet,
connecting to the IPv4 Internet via NAT64. Traffic to the LAN may
not be routable from the global Internet, as is often the case (for
instance) with LANs using RFC1918 addresses. In this case, it is
critical that the DNS64 not synthesize AAAA responses for hosts in
the LAN, or else that the DNS64 be aware of hosts in the LAN and
provide context-sensitive answers ("split view" DNS answers) for
hosts inside the LAN. As with any split view DNS arrangement,
operators must be prepared for data to leak from one context to
another, and for failures to occur because nodes accessible from one
context are not accessible from the other.
7. Security Considerations
See the discussion on the usage of DNSSEC and DNS64 described in the
Bagnulo, et al. Expires June 18, 2010 [Page 17]
Internet-Draft DNS64 December 2009
document.
8. Contributors
Dave Thaler
Microsoft
dthaler@windows.microsoft.com
9. Acknowledgements
This draft contains the result of discussions involving many people,
including the participants of the IETF BEHAVE Working Group. The
following IETF participants made specific contributions to parts of
the text, and their help is gratefully acknowledged: Mark Andrews,
Jari Arkko, Rob Austein, Timothy Baldwin, Fred Baker, Marc Blanchet,
Cameron Byrne, Brian Carpenter, Hui Deng, Francis Dupont, Ed
Jankiewicz, Peter Koch, Suresh Krishnan, Ed Lewis, Xing Li, Matthijs
Mekking, Hiroshi Miyata, Simon Perrault, Teemu Savolainen, Jyrki
Soini, Dave Thaler, Mark Townsley, Stig Venaas, Magnus Westerlund,
Florian Weimer, Dan Wing, Xu Xiaohu.
Marcelo Bagnulo and Iljitsch van Beijnum are partly funded by
Trilogy, a research project supported by the European Commission
under its Seventh Framework Program.
10. References
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, November 1987.
[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.
[RFC2672] Crawford, M., "Non-Terminal DNS Name Redirection",
RFC 2672, August 1999.
Bagnulo, et al. Expires June 18, 2010 [Page 18]
Internet-Draft DNS64 December 2009
[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-address-format]
Huitema, C., Bao, C., Bagnulo, M., Boucadair, M., and X.
Li, "IPv6 Addressing of IPv4/IPv6 Translators",
draft-ietf-behave-address-format-02 (work in progress),
December 2009.
10.2. Informative References
[I-D.ietf-behave-v6v4-xlate-stateful]
Bagnulo, M., Matthews, P., and I. Beijnum, "NAT64: Network
Address and Protocol Translation from IPv6 Clients to IPv4
Servers", draft-ietf-behave-v6v4-xlate-stateful-04 (work
in progress), December 2009.
[RFC2766] Tsirtsis, G. and P. Srisuresh, "Network Address
Translation - Protocol Translation (NAT-PT)", RFC 2766,
February 2000.
[RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound,
"Dynamic Updates in the Domain Name System (DNS UPDATE)",
RFC 2136, April 1997.
[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.
[RFC3484] Draves, R., "Default Address Selection for Internet
Protocol version 6 (IPv6)", RFC 3484, February 2003.
[RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi,
"DNS Extensions to Support IP Version 6", RFC 3596,
October 2003.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Bagnulo, et al. Expires June 18, 2010 [Page 19]
Internet-Draft DNS64 December 2009
Rose, "DNS Security Introduction and Requirements",
RFC 4033, March 2005.
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Resource Records for the DNS Security Extensions",
RFC 4034, March 2005.
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Protocol Modifications for the DNS Security
Extensions", RFC 4035, March 2005.
[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.iana-rfc3330bis]
Cotton, M. and L. Vegoda, "Special Use IPv4 Addresses",
draft-iana-rfc3330bis-11 (work in progress), August 2009.
[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-02 (work in progress),
July 2009.
[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.
[I-D.wing-behave-learn-prefix]
Wing, D., "Learning the IPv6 Prefix of a Network's IPv6/
IPv4 Translator", draft-wing-behave-learn-prefix-04 (work
in progress), October 2009.
[I-D.venaas-behave-mcast46]
Venaas, S., Asaeda, H., SUZUKI, S., and T. Fujisaki, "An
IPv4 - IPv6 multicast translator",
draft-venaas-behave-mcast46-01 (work in progress),
July 2009.
[I-D.ietf-dnsop-default-local-zones]
Bagnulo, et al. Expires June 18, 2010 [Page 20]
Internet-Draft DNS64 December 2009
Andrews, M., "Locally-served DNS Zones",
draft-ietf-dnsop-default-local-zones-09 (work in
progress), November 2009.
[I-D.savolainen-mif-dns-server-selection]
Savolainen, T., "DNS Server Selection on Multi-Homed
Hosts", draft-savolainen-mif-dns-server-selection-01 (work
in progress), October 2009.
Appendix A. Deployment scenarios and examples
In this section, we first provide a description of the default
address transformation algorithm and then we walk through some sample
scenarios that are expected to be common deployment cases. It should
be noted that is provided for illustrative purposes and this section
is not normative. The normative definition of DNS64 is provided in
Section 5 and the normative definition of the address transformation
algorithm is provided in [I-D.ietf-behave-address-format].
There are two main different setups where DNS64 is expected to be
used (other setups are possible as well, but these two are the main
ones identified at the time of this writing).
One possible setup that is expected to be common is the case of an
end site or an ISP that is providing IPv6-only connectivity or
connectivity to IPv6-only hosts that wants to allow the
communication from these IPv6-only connected hosts to the IPv4
Internet. This case is called An-IPv6-network-to-IPv4-Internet.
In this case, the IPv6/IPv4 Translator is used to connect the end
site or the ISP to the IPv4 Internet and the DNS64 function is
provided by the end site or the ISP.
The other possible setup that is expected is an IPv4 site that
wants that its IPv4 servers to be reachable from the IPv6
Internet. This case is called IPv6-Internet-to-an-IPv4-network.
It should be noted that the IPv4 addresses used in the IPv4 site
can be either public or private. In this case, the IPv6/IPv4
Translator is used to connect the IPv4 end site to the IPv6
Internet and the DNS64 function is provided by the end site
itself.
In this section we illustrate how the DNS64 behaves in the different
scenarios that are expected to be common. We consider then 3
possible scenarios, namely:
1. An-IPv6-network-to-IPv4-Internet setup with DNS64 in DNS server
mode
Bagnulo, et al. Expires June 18, 2010 [Page 21]
Internet-Draft DNS64 December 2009
2. An-IPv6-network-to-IPv4-Internet setup with DNS64 in stub-
resolver mode
3. IPv6-Internet-to-an-IPv4-network setup with DNS64 in DNS server
mode
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 an IPv6 address built from an IPv4 address X by adding the prefix
P, mappings are indicated as "(X,x) <--> (Y',y)".
A.1. IPv6/IPv4 address transformation algorithm
In this section we describe the default algorithm for the generation
of IPv6 address from IPv4 address to be implemented in the DNS64.
The only parameter required by the default algorithm is an IPv6
prefix. This prefix is used to map IPv4 addresses into IPv6
addresses, and is denoted Pref64::/n. If we note n the length of the
prefix Pref64, then n must the less or equal than 96. If an
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 must use the Well-Know prefix (64:
FF9B::/96) defined in [I-D.ietf-behave-address-format]
The input for the algorithm are:
The IPv4 address: X
The IPv6 prefix: Pref64::/n
The IPv6 address is generated by concatenating the prefix Pref64::/n,
the IPv4 address X and optionally (in case n is strictly smaller than
96) an all-zero suffix. So, the resulting IPv6 address would be
Pref64:X::
Reverse algorithm
We next describe the reverse algorithm of the algorithm described in
the previous section. This algorithm allows to generate and IPv4
address from an IPv6 address. This reverse algorithm is NOT
implemented by the DNS64 but it is implemented in the IPv6/IPv4
translator that is serving the same domain the DNS64.
The only parameter required by the default algorithm is an IPv6
prefix. This prefix is the one originally used to map IPv4 addresses
Bagnulo, et al. Expires June 18, 2010 [Page 22]
Internet-Draft DNS64 December 2009
into IPv6 addresses, and is denoted Pref64::/n.
The input for the algorithm are:
The IPv6 address: X'
The IPv6 prefix: Pref64::/n
First, the algorithm checks that the fist n bits of the IPv6 address
X' match with the prefix Pref64::/n i.e. verifies that Pref64::/n =
X'/n.
If this is not the case, the algorithm ends and no IPv4 address is
generated.
If the verification is successful, then the bits between the n+1
and the n+32 of the IPv6 address X' are extracted to form the IPv4
address.
A.2. An-IPv6-network-to-IPv4-Internet setup with DNS64 in DNS server
mode
In this example, we consider an IPv6 node located in an IPv6-only
site that initiates a communication to an IPv4 node located in the
IPv4 Internet.
The scenario for this case is depicted in the following figure:
+---------------------------------------+ +-----------+
|IPv6 site +-------------+ |IP Addr: | |
| +----+ | Name server | +-------+ T | IPv4 |
| | H1 | | with DNS64 | |64Trans|------| Internet |
| +----+ +-------------+ +-------+ +-----------+
| |IP addr: Y' | | | |IP addr: X
| --------------------------------- | +----+
+---------------------------------------+ | H2 |
+----+
The figure shows an IPv6 node H1 which has an IPv6 address Y' and an
IPv4 node H2 with IPv4 address X.
A IPv6/IPv4 Translator connects the IPv6 network to the IPv4
Internet. This IPv6/IPv4 Translator has a prefix (called Pref64::/n)
an IPv4 address T assigned to its IPv4 interface.
The other element involved is the local name server. The name server
is a dual-stack node, so that H1 can contact it via IPv6, while it
Bagnulo, et al. Expires June 18, 2010 [Page 23]
Internet-Draft DNS64 December 2009
can contact IPv4-only name servers via IPv4.
The local name server needs to know the prefix assigned to the local
IPv6/IPv4 Translator (Pref64::/n). 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 always query a name server that
performs recursive lookups (henceforth called "the recursive
nameserver").
The steps by which H1 establishes communication with H2 are:
1. H1 does a DNS lookup for FQDN(H2). H1 does this by sending a DNS
query for an AAAA record for H2 to the recursive name server.
The recursive name server implements DNS64 functionality.
2. The recursive name server resolves the query, and discovers that
there are no AAAA records for H2.
3. The recursive 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 IPv6/IPv4 Translator
in the upper n bits then the IPv4 address X and then an all-zero
padding i.e. the resulting IPv6 address is Pref64:X::
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 IPv6/IPv4
Translator and the subsequent communication flows by means of the
IPv6/IPv4 Translator mechanisms.
A.3. An-IPv6-network-to-IPv4-Internet setup with DNS64 in stub-resolver
mode
The scenario for this case is depicted in the following figure:
Bagnulo, et al. Expires June 18, 2010 [Page 24]
Internet-Draft DNS64 December 2009
+---------------------------------------+ +-----------+
|IPv6 site +-------+ |IP addr: | |
| +---------------+ | Name | +-------+ T | IPv4 |
| | H1 with DNS64 | | Server| |64Trans|------| Internet |
| +---------------+ +-------+ +-------+ +-----------+
| |IP addr: Y' | | | |IP addr: X
| --------------------------------- | +----+
+---------------------------------------+ | H2 |
+----+
The figure shows an 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 IPv6/IPv4 Translator connects the IPv6 network to the IPv4
Internet. This IPv6/IPv4 Translator has a prefix (called Pref64::/n)
and an IPv4 address T assigned to its IPv4 interface.
H1 needs to know the prefix assigned to the local IPv6/IPv4
Translator (Pref64::/n). For the purpose of this example, we assume
it learns this through manual configuration.
Also shown is a 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 situation where IPv6 hosts have
only stub resolvers and always query a name server that provides
recursive lookups (henceforth called "the recursive name server").
The recursive name server does not perform the DNS64 function.
The steps by which H1 establishes communication with H2 are:
1. H1 does a DNS lookup for FQDN(H2). H1 does this by sending a DNS
query for a AAAA record for H2 to the recursive name server.
2. The recursive DNS server resolves the query, and returns the
answer to H1. Because there are no AAAA records in the global
DNS for H2, the answer is empty.
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
IPv6/IPv4 Translator in the upper n bits, then the IPv4 address X
and then an all-zero padding i.e. the resulting IPv6 address is
Pref64:X::.
Bagnulo, et al. Expires June 18, 2010 [Page 25]
Internet-Draft DNS64 December 2009
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 IPv6/IPv4
Translator and the subsequent communication flows using the IPv6/
IPv4 Translator mechanisms.
A.4. IPv6-Internet-to-an-IPv4-network setup DNS64 in DNS server mode
In this example, we consider an IPv6 node located in the IPv6
Internet site that initiates a communication to a IPv4 node located
in the IPv4 site.
This scenario can be addressed without using any form of DNS64
function. This is so because it is possible to assign a fixed IPv6
address to each of the IPv4 servers. Such an IPv6 address would be
constructed as the Pref64::/n concatenated with the IPv4 address of
the IPv4 server and an all-zero padding. Note that the IPv4 address
can be a public or a private address; the latter does not present any
additional difficulty, since the NSP prefix must be used a Pref64::/n
(in this scenario the usage of the Well-Known prefix is not
supported). Once these IPv6 addresses have been assigned to
represent the IPv4 servers in the IPv6 Internet, real AAAA RRs
containing these addresses can be published in the DNS under the
site's domain. This is the recommended approach to handle this
scenario, because it does not involve synthesizing AAAA records at
the time of query. Such a configuration is easier to troubleshoot in
the event of problems, because it always provides the same answer to
every query.
However, there are some more dynamic scenarios, where synthesizing
AAAA RRs in this setup may be needed. In particular, when DNS Update
[RFC2136] is used in the IPv4 site to update the A RRs for the IPv4
servers, there are two options: One option is to modify the server
that receives the dynamic DNS updates. That would normally be the
authoritative server for the zone. So the authoritative zone would
have normal AAAA RRs that are synthesized as dynamic updates occur.
The other option is modify the authoritative server to generate
synthetic AAAA records for a zone, possibly based on additional
constraints, upon the receipt of a DNS query for the AAAA RR. The
first option -- in which the AAAA is synthesized when the DNS update
message is received, and the data published in the relevant zone --
is recommended over the second option (i.e. the synthesis upon
receipt of the AAAA DNS query). This is because it is usually easier
to solve problems of misconfiguration and so on when the DNS
responses are not being generated dynamically. For completeness, the
DNS64 behavior that we describe in this section covers the case of
Bagnulo, et al. Expires June 18, 2010 [Page 26]
Internet-Draft DNS64 December 2009
synthesizing the AAAA RR when the DNS query arrives. Nevertheless,
such a configuration is not recommended. Troubleshooting
configurations that change the data depending on the query they
receive is notoriously hard, and the IPv4/IPv6 translation scenario
is complicated enough without adding additional opportunities for
possible malfunction.
The scenario for this case is depicted in the following figure:
+-----------+ +----------------------------------------+
| | | IPv4 site +-------------+ |
| IPv6 | +-------+ +----+ | Name server | |
| Internet |------|64Trans| | H2 | | with DNS64 | |
+-----------+ +-------+ +----+ +-------------+ |
|IP addr: Y' | | |IP addr: X | |
+----+ | ----------------------------------- |
| H1 | +----------------------------------------+
+----+
The figure shows an IPv6 node H1 which has an IPv6 address Y' and an
IPv4 node H2 with IPv4 address X.
A IPv6/IPv4 Translator connects the IPv4 network to the IPv6
Internet. This IPv6/IPv4 Translator has a prefix (called
Pref64::/n).
Also shown is the authoritative name server for the local domain with
DNS64 functionality. For the purpose of this example, we assume that
the name server is a dual-stack node, so that H1 or a recursive
resolver acting on the request of H1 can contact it via IPv6, while
it can be contacted by IPv4-only nodes to receive dynamic DNS updates
via IPv4.
The local name server needs to know the prefix assigned to the local
IPv6/IPv4 Translator (Pref64::/n). For the purpose of this example,
we assume it learns this through manual configuration.
The steps by which H1 establishes communication with H2 are:
1. H1 does a DNS lookup for FQDN(H2). H1 does this by sending a DNS
query for an AAAA record for H2. The query is eventually
forwarded to the server in the IPv4 site.
2. The local DNS server resolves the query (locally), and discovers
that there are no AAAA records for H2.
Bagnulo, et al. Expires June 18, 2010 [Page 27]
Internet-Draft DNS64 December 2009
3. The name server verifies that FQDN(H2) and its A RR are among
those that the local policy defines as allowed to generate a AAAA
RR from. If that is the case, the name server synthesizes an
AAAA record from the A RR and the relevant Pref64::/n. The IPv6
address in the AAAA record contains the prefix assigned to the
IPv6/IPv4 Translator in the first n bits and the IPv4 address X
and then an all-zero padding.
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 through the IPv6 Internet to the IPv6
interface of the IPv6/IPv4 Translator and the communication flows
using the IPv6/IPv4 Translator mechanisms.
Appendix B. Motivations and Implications of synthesizing AAAA RR when
real AAAA RR exists
The motivation for synthesizing AAAA RR when a real AAAA RR exists is
to support the following scenario:
An IPv4-only server application (e.g. web server software) is
running on a dual-stack host. There may also be dual-stack server
applications also running on the same host. That host has fully
routable IPv4 and IPv6 addresses and hence the authoritative DNS
server has an A and a AAAA record as a result.
An IPv6-only client (regardless of whether the client application
is IPv6-only, the client stack is IPv6-only, or it only has an
IPv6 address) wants to access the above server.
The client issues a DNS query to a DNS64 recursor.
If the DNS64 only generates a synthetic AAAA if there's no real AAAA,
then the communication will fail. Even though there's a real AAAA,
the only way for communication to succeed is with the translated
address. So, in order to support this scenario, the administrator of
a DNS64 service may want to enable the synthesis of AAAA RR even when
real AAAA RR exist.
The implication of including synthetic AAAA RR when real AAAA RR
exist is that translated connectivity may be preferred over native
connectivity in some cases where the DNS64 is operated in DNS server
mode.
Bagnulo, et al. Expires June 18, 2010 [Page 28]
Internet-Draft DNS64 December 2009
RFC3484 [RFC3484] rules use longest prefix match to select which is
the preferred destination address to use. So, if the DNS64 recursor
returns both the synthetic AAAA RR and the real AAAA RR, then if the
DNS64 is operated by the same domain as the initiating host, and a
global unicast prefix (called the NSP prefix as defined in
[I-D.ietf-behave-address-format]) is used, then the synthetic AAAA RR
is likely to be preferred.
This means that without further configuration:
In the case of An IPv6 network to the IPv4 internet, the host will
prefer translated connectivity if NSP prefix is used. If the
Well-Known prefix defined in [I-D.ietf-behave-address-format] is
used, it will probably prefer native connectivity.
In the case of the IPv6 Internet to an IPv4 network, it is
possible to bias the selection towards the real AAAA RR if the
DNS64 recursor returns the real AAAA first in the DNS reply, when
the NSP prefix is used (the Well-Known prefix usage is not
recommended in this case)
In the case of the IPv6 to IPv4 in the same network, for local
destinations (i.e., target hosts inside the local site), it is
likely that the NSP prefix and the destination prefix are the
same, so we can use the order of RR in the DNS reply to bias the
selection through native connectivity. If a Well-Known prefix is
used, the longest prefix match rule will select native
connectivity.
So this option introduces problems in the following cases:
An IPv6 network to the IPv4 internet with the NSP prefix
IPv6 to IPv4 in the same network when reaching external
destinations and the NSP prefix is used.
In any case, the problem can be solved by properly configuring the
RFC3484 [RFC3484] policy table, but this requires effort on the part
of the site operator.
Bagnulo, et al. Expires June 18, 2010 [Page 29]
Internet-Draft DNS64 December 2009
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
Andrew Sullivan
Shinkuro
4922 Fairmont Avenue, Suite 250
Bethesda, MD 20814
USA
Phone: +1 301 961 3131
Email: ajs@shinkuro.com
Philip Matthews
Unaffiliated
600 March Road
Ottawa, Ontario
Canada
Phone: +1 613-592-4343 x224
Fax:
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
Bagnulo, et al. Expires June 18, 2010 [Page 30]
