One document matched: draft-ietf-behave-dns64-06.xml
<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc compact='yes'?>
<?rfc subcompact='no'?>
<?rfc symrefs="yes"?>
<?rfc tocdepth="6"?>
<?rfc editing="no"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<rfc category="std" docName="draft-ietf-behave-dns64-06" ipr="trust200902">
<front>
<title abbrev="DNS64">DNS64: DNS extensions for Network Address
Translation from IPv6 Clients to IPv4 Servers</title>
<author fullname="Marcelo Bagnulo" initials="M." surname="Bagnulo">
<organization>UC3M</organization>
<address>
<postal>
<street>Av. Universidad 30</street>
<city>Leganes</city>
<region>Madrid</region>
<code>28911</code>
<country>Spain</country>
</postal>
<phone>+34-91-6249500</phone>
<facsimile></facsimile>
<email>marcelo@it.uc3m.es</email>
<uri>http://www.it.uc3m.es/marcelo</uri>
</address>
</author>
<author fullname="Andrew Sullivan" initials="A.J."
surname="Sullivan">
<organization>Shinkuro</organization>
<address>
<postal>
<street>4922 Fairmont Avenue, Suite 250</street>
<city>Bethesda</city>
<region>MD</region>
<code>20814</code>
<country>USA</country>
</postal>
<phone>+1 301 961 3131</phone>
<email>ajs@shinkuro.com</email>
</address>
</author>
<author fullname="Philip Matthews" initials="P." surname="Matthews">
<organization abbrev="Alcatel-Lucent">Unaffiliated</organization>
<address>
<postal>
<street> 600 March Road</street>
<city>Ottawa</city>
<region>Ontario</region>
<code></code>
<country>Canada</country>
</postal>
<phone>+1 613-592-4343 x224</phone>
<facsimile></facsimile>
<email>philip_matthews@magma.ca</email>
<uri></uri>
</address>
</author>
<author fullname="Iljitsch van Beijnum" initials="I."
surname="van Beijnum">
<organization>IMDEA Networks</organization>
<address>
<postal>
<street>Av. Universidad 30</street>
<city>Leganes</city>
<region>Madrid</region>
<code>28911</code>
<country>Spain</country>
</postal>
<phone>+34-91-6246245</phone>
<email>iljitsch@muada.com</email>
</address>
</author>
<date year="2010" />
<area>Transport</area>
<workgroup>BEHAVE WG</workgroup>
<keyword>DNS64</keyword>
<keyword>IPv6</keyword>
<abstract>
<t>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.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>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 stateful NAT64 <xref
target="I-D.ietf-behave-v6v4-xlate-stateful"></xref>, allows an IPv6-only
client to initiate communications by name to an IPv4-only
server.</t>
<t>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 owner name 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).</t>
<t>Together with an 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.</t>
<t>These mechanisms are expected to play a critical role in the
IPv4-IPv6 transition and co-existence. Due to IPv4 address
depletion, it 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 in the end-hosts
themselves.</t>
</section>
<section title="Overview">
<t>This section provides a non-normative introduction to the DNS64 mechanism. </t>
<t>We assume that we have one or more IPv6/IPv4 translator boxes 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 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
cases where only IPv4 connectivity is available to the server).
Each IPv6/IPv4 translator used in conjunction with DNS64 must
allow communications initiated from the IPv6-only host to the
IPv4-only host.</t>
<t>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 cannot retrieve a
AAAA record for the queried name. The DNS64 service appears as
a regular DNS server or resolver to the IPv6 initiator. The
DNS64 receives a AAAA DNS query generated by the IPv6 initiator.
It first attempts a resolution for the requested AAAA records.
If there are no AAAA records 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. For each A record
discovered, DNS64 creates a synthetic AAAA RR from the
information retrieved in the A RR.</t>
<t>The owner name 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. If
not explicitly mentioned, all prefixes are treated equally and
the operations described in this document are performed using
the prefixes available. So as to be general, we will call any
of these prefixes Pref64::/n, and describe the operations made
with the generic prefix Pref64::/n. The IPv6 address
representing IPv4 addresses included in the AAAA RR synthesized
by the DNS64 contain Pref64::/n and they also embed the original
IPv4 address. </t>
<!--
The default algorithm to generate IPv6 representations
of IPv4 addresses is to concatenate an IPv6 prefix (called Pref64::/n) plus
the original IPv4 address and a all-zeros suffix (i.e. if the IPv4 node
has IPv4 address X, then the synthetic AAAA RR will contain
the IPv6 address formed as Pref64:X::).
-->
<t>The same algorithm and the same Pref64::/n prefix(es)
must be configured both in the DNS64 device and the
IPv6/IPv4 translator(s), 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 address that contains the Pref64::/n
be delivered to an IPv6/IPv4 translator, so they can be
translated into IPv4 packets.</t>
<!--
a route for the Pref64::/n with the next hop being the IPv6
address of the IPv6/IPv4 translator is configured in the IPv6
network, so that packets addressed to the IPv6 representations
of IPv4 addresses are routed to the IPv6/IPv4 translator.
-->
<t>Once the DNS64 has synthesized the AAAA RRs, the synthetic
AAAA RRs are 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 an IPv6/IPv4 translator which will forward it to the IPv4
network.</t>
<!--
thanks to the route for the Pref64::/n pointing to the IPv6
interface of the IPv6/IPv4 translator configured in the
routing of the IPv6 network
-->
<t>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.</t>
<t>The prefixes to be used as Pref64::/n and their applicability are discussed in
<xref target="I-D.ietf-behave-address-format" />.
There are two types of prefixes that can be used as Pref64::/n.
<list>
<t>The Pref64::/n can be the Well-Known Prefix 64:FF9B::/96
reserved by <xref target="I-D.ietf-behave-address-format" />
for the purpose of representing IPv4 addresses in IPv6 address space.</t>
<t>The Pref64::/n can be a Network-Specific Prefix (NSP). An NSP is
an IPv6 prefix assigned by an organization to create IPv6
representations of IPv4 addresses.</t>
</list>The main difference 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.</t>
<t>The DNS64 function can be performed in any of three places.</t>
<t>The first option is to locate the DNS64 function in
authoritative servers for a zone. In this case, the
authoritative server provides a synthetic AAAA RRs for an
IPv4-only host in its zone. This is one type of DNS64 server.</t>
<t>Another 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 recursive mode". This is
a second type of DNS64 server, and it is also one type of
DNS64 resolver.</t>
<t>The last option is to place the DNS64 function in the end hosts,
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". This is
the second type of DNS64 resolver.</t>
</section>
<section title="Background to DNS64-DNSSEC interaction">
<t>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. </t>
<t>A recursive resolver can be security-aware or
security-oblivious. 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.</t>
<t>DNSSEC includes some signaling bits that offer some
indicators of what the query originator understands.</t>
<t>If a query arrives at a vDNS64 device with the "DNSSEC OK" (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.</t>
<t> If a query arrives at a vDNS64 device with the "Checking Disabled" (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.</t>
<t> Here are the possible cases:
<list style="numbers">
<t>A DNS64 (DNSSEC-aware or DNSSEC-oblivious)
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.</t>
<t>A security-oblivious DNS64 receives a query with the
DO bit set, and the CD bit clear or 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.</t>
<t>A security-aware and non-validating DNS64
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 <xref target="RFC4035" />, section 4.2).
For that reason, this case amounts to the same as the
previous case, and no validation happens. </t>
<t>A security-aware and non-validating DNS64 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 <xref
target="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.</t>
<t>A security-aware and validating DNS64 node receives a
query with the DO bit clear and CD clear. In this case, the
resolver validates the data. If it fails, it returns RCODE
2 (Server failure); 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 should have set DO and CD), cannot tell that DNS64
is involved.</t>
<t>A security-aware and validating DNS64 node
receives a query with the DO bit set and CD clear.
This ought to work like the previous case, except
that the resolver should also set the "Authentic Data" (AD) bit on the
response.</t>
<t>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.</t> </list></t>
</section>
<section title="Terminology">
<t>This section provides definitions for the special terms
used in the document. </t>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
and "OPTIONAL" in this document are to be interpreted as
described in <xref target="RFC2119">RFC 2119</xref>.</t>
<t><list style="hanging">
<t hangText="Authoritative server:">A DNS server that can
answer authoritatively a given DNS question. </t>
<t hangText="DNS64:">A logical function that synthesizes
DNS resource records (e.g AAAA records containing IPv6
addresses) from DNS resource records actually contained in
the DNS (e.g., A records containing IPv4
addresses).</t>
<t hangText="DNS64 recursor:">A recursive resolver that
provides the DNS64 functionality as part of its operation.
This is the same thing as "DNS64 in recursive resolver
mode".</t>
<t hangText="DNS64 resolver:">Any resolver (stub resolver
or recursive resolver) that provides the DNS64 function.
</t>
<t hangText="DNS64 server:">Any server providing the DNS64
function.</t>
<t hangText="Recursive resolver:">A DNS server that
accepts requests from one resolver, and asks another
server (of some description) for the answer on behalf of
the first resolver.</t>
<t hangText="Synthetic RR:">A DNS resource record (RR)
that is not contained in any zone data file, but has been
synthesized from other RRs. An example is a synthetic AAAA
record created from an A record.</t>
<t hangText="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.</t>
</list></t>
<t>For a detailed understanding of this document, the reader
should also be familiar with DNS terminology from <xref target="RFC1034" />, <xref
target="RFC1035"></xref> and current NAT terminology from <xref
target="RFC4787"></xref>. Some parts of this document
assume familiarity with the terminology of the DNS security
extensions outlined in <xref target="RFC4035" />.</t>
</section>
<section title="DNS64 Normative Specification" anchor="normative">
<t>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.</t>
<t>The implementation SHOULD support mapping of separate IPv4 address
ranges to separate IPv6 prefixes for AAAA record
synthesis. This allows handling of special use IPv4
addresses <xref target="RFC5735" />. Support of multicast address
handling is out of the scope of this document. A possible approach is specified in
<xref target="I-D.venaas-behave-mcast46" />.</t>
<t>DNS64 also responds to PTR queries involving
addresses containing any of the IPv6 prefixes it uses for synthesis of AAAA RRs.</t>
<section title="Resolving AAAA queries and the answer section">
<t>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. DNS64 operation for classes other than IN
is undefined, and a DNS64 MUST behave as though no DNS64
function is configured.</t>
<section title="The answer when there is AAAA data
available">
<t>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 <xref
target="exclusion_set" />. If there is (non-excluded)
AAAA data available, DNS64 SHOULD NOT include synthetic
AAAA RRs in the response (see <xref
target="always-synth" /> 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.</t>
</section>
<section title="The answer when there is an error" anchor="aaaa_error">
<t>If the query results in a response with RCODE other
than 0 (No error condition), then there are two
possibilities. A result with RCODE=3 (Name Error) is
handled according to normal DNS operation (which is
normally to return 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.</t>
<t>Any other RCODE is treated as though the RCODE were 0
and the answer section were empty. This is because of
the large number of different responses from deployed
name servers when they receive AAAA queries without a
AAAA record being available.</t>
<t>It is important to note that, as of this writing,
some servers respond with RCODE=3 to a AAAA query even
if there is an A record available for that owner name.
Those servers are in clear violation of the meaning of
RCODE 3, and it is expected that they will decline in
use as IPv6 deployment increases.</t>
</section>
<section title="Special exclusion set for AAAA records"
anchor="exclusion_set">
<t> 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:0:0/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 dual-stack host.</t>
<t>When the DNS64 performs its initial AAAA query, if it
receives an answer with only AAAA records containing
addresses in the excluded 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
excluded range(s), 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 <xref target="assembly" />.
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.</t>
</section>
<section title="Dealing with CNAME and DNAME"
anchor="cname_dname">
<t>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 a AAAA record to follow. The resulting AAAA or
A record is treated like any other AAAA or A case, as
appropriate.</t>
<t>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.</t>
</section>
<section title="Data for the answer when performing synthesis">
<t>If the query results in no error but an empty answer
section in the response, the DNS64 attempts to retrieve
A records for the name in question, either by performing
another query or, in the case of an authortiative
server, by examining its own results. 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 mode and operation of the underlying resolver; this
is just as in <xref target="aaaa_error" />.) 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 <xref target="syntheticans"
/>. The DNS64 returns the synthesized AAAA records in
the answer section, removing the A records that form the
basis of the synthesis.</t>
</section>
<section title="Performing the synthesis" anchor="syntheticans">
<t>A synthetic AAAA record is created from an A record as
follows:<list style="symbols">
<t>The NAME field is set to the NAME field from the A record</t>
<t>The TYPE field is set to 28 (AAAA)</t>
<t>The CLASS field is set to the original CLASS field,
1. Under this specification, DNS64 for any CLASS other
than 1 is undefined.</t>
<t>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.)</t>
<t>The RDLENGTH field is set to 16</t>
<t>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 configured IPv4 address
ranges and select the corresponding IPv6 prefix to use in
synthesizing the AAAA RR. See <xref
target="address-transform" /> for discussion of the
algorithms to be used in effecting the transformation.</t>
</list></t>
</section>
<section title="Querying in parallel">
<t>The 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 where 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 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.)</t>
</section>
</section>
<section title="Generation of the IPv6 representations of IPv4 addresses" anchor="address-transform">
<t>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:
<list>
<t>The same algorithm to create an IPv6 address from
an IPv4 address MUST be used by both a DNS64 to
create the IPv6 address to be returned in the
synthetic AAAA RR from the IPv4 address contained in
an original A RR, and by a IPv6/IPv4 translator to
create the IPv6 address to be included in the
source address field of the outgoing IPv6
packets from the IPv4 address included in the
source address field of the incoming IPv4
packet.</t>
<t>The algorithm MUST be reversible; i.e., it MUST be
possible to derive the original IPv4 address from
the IPv6 representation. </t>
<t>The input for the algorithm MUST be limited to
the IPv4 address, the IPv6 prefix (denoted
Pref64::/n) used in the IPv6 representations and
optionally a set of stable parameters that are
configured in the DNS64 and in the NAT64 (such as fixed string to be
used as a suffix).
<list>
<t> For each prefix Pref64::/n, n MUST the less than or equal to 96.
If one or more Pref64::/n are configured in the DNS64 through any means in the DNS64
(such as manually configured, or other automatic means not specified
in this document), the default algorithm MUST use these prefixes (and not use the Well-Know Prefix).
If no prefix is available, the algorithm MUST use the Well-Known prefix
64:FF9B::/96 defined in <xref target="I-D.ietf-behave-address-format" /> to represent the IPv4 unicast address range</t>
</list></t>
<cref> Note in document: The value 64:FF9B::/96 is proposed as the value for the Well-Known prefix and needs to be confirmed
when <xref target="I-D.ietf-behave-address-format" /> is published as RFC.
</cref>
</list></t>
<t>A DNS64 MUST support the algorithm for
generating IPv6 representations of IPv4 addresses defined in Section 2 of
<xref target="I-D.ietf-behave-address-format"
/>. Moreover, the aforementioned algorithm MUST be the default algorithm used by the DNS64. While the normative description of the algorithm is provided in
<xref target="I-D.ietf-behave-address-format" />, a sample description of the algorithm and its application to
different scenarios is provided in <xref target="examples" /> for illustration purposes. </t>
</section>
<section title="Handling other RRs and the Additional Section">
<!--
<t>If a DNS64 receives a PTR query for the IP6.ARPA
domain, the DNS64 recursor searches for the queried
prefix on its own list of prefixes (i.e. one or more
Pref64 available). If the prefix contained in the
query is not included in its own list of prefixes, the
DNS64 handles the query as it would any other query
(i.e. it sends the query out to be resolved in stub
resolver and recursive resolver mode, and it returns a
referral in authoritative mode). If the prefix is
included in its own prefix list, then the DNS64
translates the QNAME field to the IN-ADDR.ARPA domain
by removing the Pref64:/n, and extracting the IPv4
address, applying the reverse of the algorithm used to
generate the IPv6 representation of IPv4 addresses.
The DNS64 then either performs that IN-ADDR.ARPA query
(if it is a stub or recursive resolver) or answers the
query (in authoritative mode). When the resulting
query is resolved, the DNS64 restores the QNAME field
to the IP6.ARPA domain, and sends the DNS response to
the original client.</t>
-->
<section title="PTR queries">
<t>If a DNS64 server 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 <xref target="RFC3596" />, and examine
the resulting address to see whether its prefix matches
any of the locally-configured Pref64::/n. There are two
alternatives for a DNS64 server to respond to such
PTR queries. A DNS64 server MUST provide one of these, and
SHOULD NOT provide both at the same time unless different
IP6.ARPA zones require answers of different sorts.</t>
<t>The first option is for the DNS64 server to
respond authoritatively for its prefixes. If the address
prefix matches any Pref64::/n used in the site, either a
NSP or the Well-Known Prefix (i.e. 64:FF9B::/96), 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 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.</t>
<t>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.</t>
<t>If the address prefix does not match any
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
server MUST respond authoritatively or with a referral,
as appropriate.</t>
</section>
<section title="Handling the additional section" anchor="addl_sec">
<t>DNS64 synthesis MUST NOT be performed on any records
in the additional section of synthesized answers. The
DNS64 MUST pass the additional section unchanged.</t>
<t>It may appear that adding synthetic records to the
additional section is desirable, because clients
sometimes use the data in the additional section to
proceed without having to re-query. There is in general
no promise, however, that the additional section will
contain all the relevant records, so any client that
depends on the additional section being able to satisfy
its needs (i.e. without additional queries) is
necessarily broken. An IPv6-only client that needs a
AAAA record, therefore, will send a query for the
necessary AAAA record if it is unable to find such a
record in the additional section of an answer it is
consuming. For a correctly-functioning client, the
effect would be no different if the additional section
were empty.</t>
<t>The alternative, of removing the A records in the
additional section and replacing them with synthetic AAAA
records, may cause a host behind a NAT64 to query
directly a nameserver that is unaware of the NAT64 in
question. The result in this case will be resolution
failure anyway, only later in the resolution operation.</t>
</section>
<section title="Other records">
<t>If the DNS64 is in recursive resolver mode, then
considerations outlined in <xref
target="I-D.ietf-dnsop-default-local-zones" /> may be
relevant.</t>
<t>All other RRs MUST be returned unchanged.</t>
</section>
</section>
<section title="Assembling a synthesized response to a
AAAA query" anchor="assembly">
<t>A DNS64 uses different pieces of data to build the
response returned to the querying client. </t>
<t>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.</t>
<t>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
<xref target="syntheticans" />. The authority and
additional sections are copied from the response to the
A query that the DNS64 performed.</t>
</section>
<section title="DNSSEC processing: DNS64 in recursive server mode">
<t>We consider the case where a recursive server that is
performing DNS64 also has a local policy to validate the
answers according to the procedures outlined in <xref
target="RFC4035" /> Section 5. We call this general case
vDNS64.</t>
<t>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:
<list style="numbers">
<t>If CD is not set and DO is not set, vDNS64 SHOULD
perform validation and do synthesis as needed.
<!-- The DNS64
MAY translate the A record to AAAA.
-->
</t>
<t>If CD is not set and DO is set, then vDNS64 SHOULD
perform validation. <!-- If the data validates, the
server MAY perform synthesis, but it MUST NOT set the AD
bit. This is acceptable, because whereas the original
data validated, the answer that is actually returned to
the originating client is not the validated data (and
therefore would not itself validate). --> 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 <xref
target="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).
<vspace blanklines="1" />
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
<xref target="RFC4035" />, section 4.9.3. An
application that wants to perform validation on its own
should use the CD bit.</t>
<t>If the CD bit is set and DO is set, then vDNS64 MAY
perform validation, but MUST NOT perform synthesis. It
MUST return the data to the query initiator, just like a
regular recursive resolver, and depend on the client to
do the validation and the synthesis itself.
<vspace blanklines="1" />
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.</t>
</list></t>
</section>
</section>
<section title="Deployment notes">
<t>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.</t>
<section title="DNS resolvers and DNS64">
<t>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 be unable to answer
the necessary AAAA queries.</t>
</section>
<section title="DNSSEC validators and DNS64">
<t>Existing DNSSEC validators (i.e. that are unaware of
DNS64) might reject all the data that comes from DNS64 as
having been tampered with (even if it did not set CD when
querying). 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 a DNS64, and allow
the DNS64 recursor to do all validation on its behalf.</t>
</section>
<section title="DNS64 and multihomed and dual-stack hosts">
<section title="IPv6 multihomed hosts">
<t>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.</t>
<t>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
interface. Hosts that attempt to use DNS answers
globally may encounter surprising failures in these
cases. For more discussion of this topic, see <xref
target="I-D.savolainen-mif-dns-server-selection" />.</t>
<t>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.</t>
</section>
<section title="Accidental dual-stack DNS64 use">
<t> Similarly, suppose that i1 has IPv6 connectivity and
can connect to the IPv4 Internet through NAT64, but i2
has native IPv4 connectivity. In this case, i1 could receive
an IPv6 address from a synthetic AAAA that would better
be reached via native IPv4. Again, it is worth
emphasising that this arises because there are two
networks involved.</t>
<t>Since it is most likely that the host will attempt
AAAA resolution first, in this arrangement the host will
often use the NAT64 when 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.</t>
</section>
<section title="Intentional dual-stack DNS64 use">
<t>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.</t>
<t>It is important for deployers of DNS64 to realise that, in some
circumstances, making the DNS64 available to a dual-stack host
will cause the host to prefer to send packets via NAT64 instead of
via native IPv4, with the associated loss of performance or
functionality (or both) entailed by the NAT. At the same time,
some hosts are not able to learn about DNS servers provisioned on
IPv6 addresses, or simply cannot send DNS packets over IPv6.</t>
</section>
</section>
</section>
<section title="Deployment scenarios and examples" anchor="examples">
<t>In this section, we walk through some sample scenarios that are expected to be common deployment cases.
It should be noted that this is provided for illustrative purposes and this section is not normative.
The normative definition of DNS64 is provided in <xref target="normative" /> and the normative definition
of the address transformation algorithm is provided in <xref target="I-D.ietf-behave-address-format" />.</t>
<t>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).
<list>
<t>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 <xref target="I-D.ietf-behave-v6v4-framework"/>.
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.</t>
<t>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 <xref target="I-D.ietf-behave-v6v4-framework"/>. 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 IPv4 end
site itself. </t>
</list></t>
<t>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:
<list style="numbers">
<t>An-IPv6-network-to-IPv4-Internet setup with DNS64 in DNS server mode</t>
<t>An-IPv6-network-to-IPv4-Internet setup with DNS64 in stub-resolver mode</t>
<t>IPv6-Internet-to-an-IPv4-network setup with DNS64 in DNS server mode</t>
</list></t>
<!-- <t>The notation used is the following: upper case letters are IPv4
addresses; upper case letters with a prime(') are IPv6 addresses; lower
case letters are ports; prefixes 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)".</t>
-->
<!-- <section title="Example of IPv6/IPv4 address transformation algorithm">
<t>In this section we describe the algorithm for the generation of
IPv6 address from IPv4 address to be implemented in the DNS64 in the case of a Pref64::/n with n=96.</t>
<t>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::/96.
If an Pref64::/96 is configured through any means in the DNS64
(such as manually configured, or other automatic mean not specified
in this document), the default algorithm will use this prefix.
If no prefix is available the algorithm will use the Well-Know prefix
(64:FF9B::/96) defined in <xref target="I-D.ietf-behave-address-format" /></t>
<t>The input for the algorithm are:
<list>
<t>The IPv4 address: X</t>
<t>The IPv6 prefix: Pref64::/96</t>
</list></t>
<t>The IPv6 address is generated by concatenating the prefix Pref64::/96, the IPv4 address X
So, the resulting IPv6 address would be Pref64:X</t>
<t>Reverse algorithm</t>
<t>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.</t>
<t>The only parameter required by the default algorithm is
an IPv6 prefix. This prefix is the one originally used to map IPv4
addresses into IPv6 addresses, and is denoted Pref64::/96.</t>
<t>The input for the algorithm are:
<list>
<t>The IPv6 address: X'</t>
<t>The IPv6 prefix: Pref64::/n</t>
</list></t>
<t>First, the algorithm checks that the fist 96 bits of the IPv6 address X'
match with the prefix Pref64::/96 i.e. verifies that Pref64::/96 = X'/96.
<list>
<t>If this is not the case, the algorithm ends and no IPv4 address is generated.</t>
<t>If the verification is successful, then last 32 bits of
address X' are extracted to form the IPv4 address.</t>
</list></t>
</section>
-->
<section title="Example of An-IPv6-network-to-IPv4-Internet setup with DNS64 in DNS server mode">
<t>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. </t>
<t>The scenario for this case is depicted in the following figure:</t>
<figure>
<preamble></preamble>
<artwork align="center">
+---------------------+ +---------------+
|IPv6 network | | IPv4 |
| | +-------------+ | Network |
| |--| Name server |--| |
| | | with DNS64 | | +----+ |
| +----+ | +-------------+ | | H2 | |
| | H1 |---| | | +----+ |
| +----+ | +-------+ | 192.0.2.1 |
| |------| NAT64 |----| |
| | +-------+ | |
| | | | |
+---------------------+ +---------------+
</artwork>
<postamble></postamble>
</figure>
<t>The figure shows an IPv6 node H1 and an
IPv4 node H2 with IPv4 address 192.0.2.1 and FQDN h2.example.com</t>
<t>A IPv6/IPv4 Translator connects the IPv6 network to the IPv4 Internet. This IPv6/IPv4 Translator has
an IPv4 address 203.0.113.1 assigned to its IPv4 interface and it is using the WKP 64:FF9B::/96 to
create IPv6 representations of IPv4 addresses, as defined in <xref target="I-D.ietf-behave-address-format" />.</t>
<t>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 can contact IPv4-only name servers via
IPv4.</t>
<t>The local name server is configured to represent the whole IPv4 unicast space with
using the WKP 64:FF9B::/96. For the purpose of this example, we assume
it learns this through manual configuration.</t>
<t>For this example, assume the typical DNS situation where IPv6 hosts
have only stub resolvers, and they are configured with the IP address of a name server that they always have to query and that performs recursive
lookups (henceforth called "the recursive nameserver").</t>
<t>The steps by which H1 establishes communication with H2 are: <list
style="numbers">
<t>H1 does a DNS lookup for h2.example.com. H1 does this
by sending a DNS query for a AAAA record for H2 to the recursive name
server. The recursive name server implements
DNS64 functionality.</t>
<t>The recursive name server resolves the query, and discovers that
there are no AAAA records for H2.</t>
<t>The recursive name server queries for A records for H2 and gets back
a single A records containing the IPv4 address 192.0.2.1. The name server then
synthesizes a AAAA records. The IPv6 address in the AAAA record
contains the prefix assigned to the IPv6/IPv4 Translator in the upper 96 bits then
the received IPv4 address i.e. the resulting IPv6 address is 64:FF9B::192.0.2.1</t>
<t>H1 receives the synthetic AAAA record and sends a packet
towards H2. The packet is sent to the destination address 64:FF9B::192.0.2.1.</t>
<t>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.</t>
</list></t>
</section>
<section title="An example of an-IPv6-network-to-IPv4-Internet setup with DNS64 in stub-resolver mode">
<t>This case is depicted in the following figure:</t>
<figure>
<preamble></preamble>
<artwork align="center">
+---------------------+ +---------------+
|IPv6 network | | IPv4 |
| | +--------+ | Network |
| |-----| Name |----| |
| +-----+ | | server | | +----+ |
| | H1 | | +--------+ | | H2 | |
| |with |---| | | +----+ |
| |DNS64| | +-------+ | 192.0.2.1 |
| +----+ |------| NAT64 |----| |
| | +-------+ | |
| | | | |
+---------------------+ +---------------+
</artwork>
<postamble></postamble>
</figure>
<t>The figure shows an IPv6 node H1 implementing the DNS64 function and an
IPv4 node H2 with IPv4 address 192.0.2.1 and FQDN h2.example.com </t>
<t>A IPv6/IPv4 Translator connects the IPv6 network to the IPv4 Internet. This IPv6/IPv4 Translator
is using the WKP 64:FF9B::/96 and an
IPv4 address T 203.0.113.1 assigned to its IPv4 interface.</t>
<t>H1 needs to know the prefix assigned to the
local IPv6/IPv4 Translator (64:FF9B::/96). For the purpose of this example, we assume
it learns this through manual configuration.</t>
<t>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.</t>
<t>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.
</t>
<t>The steps by which H1 establishes communication with H2 are: <list
style="numbers">
<t>H1 does a DNS lookup for h2.example.com. H1 does this
by sending a DNS query for a AAAA record for H2 to the recursive name
server.</t>
<t>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.</t>
<t>The stub resolver at H1 then queries for an A record for H2 and gets back an
A record containing the IPv4 address 192.0.2.1. 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 96 bits, then
the received IPv4 address i.e. the resulting IPv6 address is 64:FF9B::192.0.2.1.</t>
<t>H1 sends a packet
towards H2. The packet is sent to the destination address 64:FF9B::192.0.2.1.</t>
<t>The packet is routed to the IPv6 interface of the IPv6/IPv4 translator and the
subsequent communication flows using the IPv6/IPv4 translator mechanisms.</t>
</list></t>
</section>
<section title="Example of IPv6-Internet-to-an-IPv4-network setup DNS64 in DNS server mode">
<t>In this example, we consider an IPv6 node located in the IPv6 Internet
that initiates a communication to an IPv4 node located in the IPv4
site.</t>
<t>In some cases, this scenario can be addressed without using any form of DNS64 function.
This is so because in principle it is possible to assign a fixed IPv6 address
to each of the IPv4 nodes. Such an IPv6 address would be constructed using the
address transformation algorithm defined in <xref target="I-D.ietf-behave-address-format" />
that takes as input the Pref64::/96 and the IPv4 address of the IPv4 node.
Note that the IPv4 address can be a public or a private address; the latter does
not present any additional difficulty, since an NSP must be used as Pref64::/96
(in this scenario the usage of the Well-Known prefix is not supported as discussed
in <xref target="I-D.ietf-behave-address-format" />). Once these IPv6 addresses
have been assigned to represent the IPv4 nodes 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. </t>
<t>However, there are some more dynamic scenarios, where synthesizing AAAA RRs in this
setup may be needed. In particular,
when DNS Update <xref target="RFC2136"></xref>
is used in the IPv4 site to update the A RRs for the IPv4 nodes, there are two options:
One option is to modify the DNS 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 all the authoritative
servers 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.
However, it may be the case where
the primary server (that receives all the updates)
cannot be upgraded for whatever reason, but where
a secondary can be upgraded in order to handle the
(comparatively small amount) of AAAA queries. In such case, it is possible to use the DNS64 as described next.
The
DNS64 behavior that we describe in
this section covers the case of
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. -->
</t>
<t>The scenario for this case is depicted in the following figure:</t>
<figure>
<preamble></preamble>
<artwork align="center">
+-----------+ +----------------------+
| | | IPv4 site |
| IPv6 | +-------+ | +----+ |
| Internet |------| NAT64 |-----|---| H2 | |
| | +-------+ | +----+ |
| | | | 192.0.2.1 |
| | +------------+ | |
| |----| Name server|--| |
| | | with DNS64 | | |
+-----------+ +------------+ | |
| | | |
+----+ | |
| H1 | +----------------------+
+----+
</artwork>
<postamble></postamble>
</figure>
<t>The figure shows an IPv6 node H1 and an
IPv4 node H2 with IPv4 address X 192.0.2.1 and FQDN h2.example.com.</t>
<t>A IPv6/IPv4 translator connects the IPv4 network to the IPv6 Internet. This IPv6/IPv4 translator has
a NSP 2001:DB8::/96.</t>
<t>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.</t>
<t>The local name server needs to know the prefix assigned to the
local IPv6/IPv4 Translator (2001:DB8::/96). For the purpose of this example, we assume
it learns this through manual configuration.</t>
<!-- <t>For this example, assume the typical DNS situation where IPv6 hosts
have only stub resolvers and the local name server does the recursive
lookups.</t>
-->
<t>The steps by which H1 establishes communication with H2 are: <list
style="numbers">
<t>H1 does a DNS lookup for h2.example.com. H1 does this
by sending a DNS query for a AAAA record for H2. The query is
eventually forwarded to the server in the IPv4 site.</t>
<t>The local DNS server resolves the query (locally), and discovers that
there are no AAAA records for H2.</t>
<t>The name server verifies that h2.example.com 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 a AAAA record from the A RR and the prefix 2001:DB8::/96.
The IPv6 address in the AAAA record
is 2001:DB8::192.0.2.1.</t>
<t>H1 receives the synthetic AAAA record and sends a packet
towards H2. The packet is sent to the destination address 2001:DB8::192.0.2.1.</t>
<t>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.</t>
</list></t>
</section>
</section>
<section title="Security Considerations">
<t>See the discussion on the usage of DNSSEC and DNS64 described in section 3, section 5.5, and section 6.2.
.</t>
<!-- <t>NAT64 uses synthetic DNS RR to enable IPv6 clients to initiate communications with
IPv4 servers using the DNS. This essentially means that the DNS64 component generates
synthetic AAAA RR that are not contained in the master zone file. From a DNSSEC
perspective, this means that the straight DNSSEC verification of such RR would fail.
However, it is possible to restore DNSSEC functionality if the verification is performed
right before the DNS64 processing directly using the original A RR of the IPv4 server.
So, in order to jointly use the NAT64 approach described in thei specification and DNSSEC
validation, the DNS64 functionality should be performed in the resolver of the IPv6 client.
In this case, the IPv6 client would receive the original A RR with DNSSEC information and
it would first perform the DNSSEC validation. If it is succcessful, it would then proceed
the synthetize the AAAA RR according to the mechanism described in this document. It should
be noted that the synthetic AAAA RR would stay within the IPv6 client and it would not leak outside,
making further DNSSEC validations unnecesary.</t>
-->
</section>
<section title="IANA Considerations">
<t>This memo makes no request of IANA.</t>
</section>
<section title="Contributors">
<list>
<t>Dave Thaler</t>
<t>Microsoft</t>
<t>dthaler@windows.microsoft.com</t>
</list>
<!--
<list>
<t>George Tsirtsis</t>
<t>Qualcomm</t>
<t>tsirtsis@googlemail.com</t>
</list>
-->
</section>
<section title="Acknowledgements">
<t> 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, Doug Barton, Marc
Blanchet, Cameron Byrne, Brian Carpenter, Hui Deng, Francis
Dupont, Patrik Faltstrom, Ed Jankiewicz, Peter Koch, Suresh
Krishnan, Ed Lewis, Xing Li, Bill Manning, Matthijs Mekking,
Hiroshi Miyata, Simon Perrault, Teemu Savolainen, Jyrki Soini,
Dave Thaler, Mark Townsley, Rick van Rein, Stig Venaas, Magnus
Westerlund, Florian Weimer, Dan Wing, Xu Xiaohu, Xiangsong
Cui. </t>
<t>Marcelo Bagnulo and Iljitsch van Beijnum are partly funded by Trilogy,
a research project supported by the European Commission under its Seventh
Framework Program.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include='reference.RFC.2119'?>
<?rfc include='reference.RFC.1034'?>
<?rfc include='reference.RFC.1035'?>
<!-- <?rfc include='reference.RFC.2671'?>
<?rfc include='reference.RFC.2672'?>
<?rfc include='reference.RFC.2765'?> -->
<?rfc include='reference.RFC.4787'?>
<!-- <?rfc include="reference.I-D.ietf-behave-tcp"?>
<?rfc include="reference.RFC.5508"?> -->
<?rfc include="reference.I-D.ietf-behave-address-format"?>
</references>
<references title="Informative References">
<?rfc include="reference.I-D.ietf-behave-v6v4-xlate-stateful"?>
<!-- <?rfc include='reference.RFC.2766'?> -->
<?rfc include='reference.RFC.2136'?>
<!-- <?rfc include='reference.RFC.1858'?>
<?rfc include='reference.RFC.3128'?>
<?rfc include='reference.RFC.3022'?> -->
<?rfc include='reference.RFC.3484'?>
<?rfc include='reference.RFC.3596'?>
<?rfc include='reference.RFC.4033'?>
<?rfc include='reference.RFC.4034'?>
<?rfc include='reference.RFC.4035'?>
<?rfc include='reference.RFC.4966'?>
<?rfc include='reference.RFC.5735'?>
<!--<?rfc include='reference.I-D.iana-rfc3330bis'?>-->
<?rfc include='reference.I-D.ietf-behave-v6v4-framework'?>
<!-- <?rfc include='reference.I-D.ietf-6man-addr-select-sol'?> -->
<!-- <?rfc include='reference.RFC.3498'?> -->
<?rfc include='reference.I-D.venaas-behave-mcast46'?>
<?rfc include='reference.I-D.ietf-dnsop-default-local-zones'?>
<?rfc include='reference.I-D.savolainen-mif-dns-server-selection'?>
</references>
<section title="Motivations and Implications of synthesizing AAAA RR when real AAAA RR exists" anchor="always-synth">
<t>The motivation for synthesizing AAAA RRs when a real AAAA RRs exist is to support the following scenario:
<list>
<t> 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.</t>
<t> 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.</t>
<t> The client issues a DNS query to a DNS64 resolver.</t>
</list></t>
<t>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 RRs even when real AAAA RRs exist.</t>
<t>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.</t>
<t> RFC3484 <xref target="RFC3484" /> rules use longest prefix match to
select the preferred destination address to use.
So, if the DNS64 resolver returns both the synthetic AAAA RRs and the real AAAA
RRs, then if the DNS64 is operated by the same domain as the initiating
host, and a global unicast prefix (called an
NSP in <xref target="I-D.ietf-behave-address-format" />) is used,
then a synthetic AAAA RR is likely to be preferred.
</t>
<t> This means that without further configuration:
<list>
<t> In "An IPv6 network to the IPv4 Internet" scenario , the host will
prefer translated connectivity if an NSP is used. If the Well-Known
Prefix defined in <xref target="I-D.ietf-behave-address-format" />
is used, it will probably prefer native connectivity.</t>
<t> In the "IPv6 Internet to an IPv4 network" scenario, it is
possible to bias the selection towards the real AAAA
RR if the DNS64 resolver returns the real AAAA first in the DNS reply, when
an NSP is used (the Well-Known Prefix usage is not supported in
this case)</t>
<t> In "an IPv6 network to IPv4 network" scenario, for
local destinations (i.e., target hosts inside the local site), it is
likely that the NSP 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 the Well-Known Prefix
is used, the longest prefix match rule will select native
connectivity.</t>
</list></t>
<t> So this option introduces problems in the following cases:
<list>
<t> An IPv6 network to the IPv4 internet with an NSP</t>
<t> IPv6 to IPv4 in the same network when reaching external
destinations and an NSP is used.</t>
</list></t>
<t> In any case, the problem can be solved by properly configuring
the RFC3484 <xref target="RFC3484" /> policy table,
but this requires effort on the part of the site operator.</t>
</section>
<!--
<section title="Solution space analysis">
<section title="Tagging synthetic RR">
<t>As a general architecture consideration, it seems a good approach to preserve the
transparency when the 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 of
them impose some trade-offs between architectural cleanness and deployability.</t>
<t>Tagging the synthetic RRs is relevant in the An-IPv6-network-to-IPv4-Internet setup,
where the synthesis is not made by the authoritative name server and the
following discussion applies. This is not the case when the synthesis is
performed by the authoritative
DNS server, such as in the case of the setup presented in IPv6-Internet-to-An-IPv4-network. </t>
<t>Tagging is mostly useful for troubleshooting, and for
translation-aware end points.</t>
<t>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. 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. Therefore, this option is rejected.</t>
<t>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.</t>
<t>A similar option as the previous one would be to use an EDNS0 option <xref
target="RFC2671"></xref> to tag the DNS
responses that contain one or more synthetic AAAA RRs. There are however some additional issues with this.
The EDNS0 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.</t>
<t>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. Additional discussion about the advantages
and disadvantages of using a Well-Known prefix can be found <xref target="I-D.miyata-behave-prefix64"></xref>.</t>
</section>
<section title="Dual stack nodes">
<t>When dual stack nodes are involved in the communication, the potential
issue is that they end up using translated connectivity even though the native
connectivity is available. There are multiple ways to try to deal with this issue,
here we consider those related to DNS64.</t>
<t>There are two different cases involving dual-stack nodes.
Communication initiated from an IPv6-only node towards a dual
stack node and communication initiated from a dual stack node towards an
IPv4-only node. We will next consider each one of these cases.</t>
<section title=" Communication initiated from an IPv6-only node towards a dual stack node">
<t>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.</t>
</section>
<section title="Communication initiated from a dual stack node toward an IPv4 only node">
<t>We consider now the case of a dual stack node is initiating a communication with a IPv4-only
node that has a public IPv4 address published in an A RR.
Dual stack 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.</t>
<t> One option would be to configure the dual stack nodes not to use
the DNS64 mechanism. 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 be usable for
backup purposes if the native connectivity is down.</t>
<t>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.</t>
<t>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.</t>
<t>Another option not specific to DNS64 includes using the RFC3484 policy table e.g.
configuring the Pref64::/96 as low priority preference in the table. This
option requires some means to properly configure the policy table, which is
not currently available (only manual configuration is currently defined)
(see <xref target="I-D.ietf-6man-addr-select-sol"></xref> for more on this topic).</t>
</section>
</section>
<section title="Learning the Pref64::/96 prefix">
<t>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. </t>
<t>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.</t>
<t>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.</t>
<t>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 known name, such as pref64.example.com, or even in example.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.</t>
<t>For more extensive discussion on this topic, the reader is referred to <xref target="I-D.wing-behave-learn-prefix"></xref></t>
</section>
<section title="Supporting multiple NAT64 boxes with different associated prefixes">
<t>This discussion applies to the An-IPv6-network-to-IPv4-Internet setup.</t>
<t>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.
The question that we consider in this section is how these prefixes are managed by the DNS64 function.</t>
<t>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 server should detect the failure and start using an alternative
prefix. (Note that it 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 failure could be detected by the DNS64
device pinging itself from its IPv6 address towards its IPv4 address through
the NAT64 in question.</t>
<t>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:
<list style="symbols">
<t>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.</t>
<t>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. Rather than actually tracking per-client state, the same result could be
achieved by performing a hash over the client's address and return AAAA
records synthesized using the same Pref64 for all addresses that hash to the
same value. </t>
<t>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. This would provide the fault tolerance capabilities required without
need for the DNS64 to keep track of the state of the NAT64 boxes.</t>
</list></t>
</section>
-->
<!--
<section title="Application scenarios">
<t>In this section, we describe how to apply DNS64 to the suitable scenarios
described in draft-arkko-townsley-coexistence.</t>
<section title="Enterprise IPv6 only network">
<t>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.</t>
<figure>
<preamble></preamble>
<artwork><![CDATA[ +----+ +-------------+
| +------------------+IPv6 Internet+
| | +-------------+
IPv6 host-----------------+ GW |
| | +-------------+
| +------------------+IPv4 Internet+
+----+ +-------------+
|-------------------------public v6-----------------------------|
|-------public v6---------|NAT|----------public v4--------------|
]]></artwork>
<postamble></postamble>
</figure>
<t>The proposed NAT64/DNS64 is perfectly suitable for this particular scenario.
The deployment of the NAT64/DNS64 would be as follows: The NAT64 function
should be located in the GW device that connects the IPv6 site to the IPv4 Internet.
The DNS64 functionality can be placed in the name server or in the stub resolvers
</t>
<t>The proposed NAT64/DNS64 approach satisfies the requirements of this scenario,
in particular because it doesn't require any changes to current IPv6 hosts in the
site to obtain basic functionality.
</t>
</section>
-->
<!-- </section>
<section title="Additional Discussion">
<section title="About the Prefix used to map the IPv4 address space into IPv6">
<t>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.
</t>
<t>The different options for Pref64::/96 are the following
<list>
<t>Local: A locally assigned prefix out of the address block of the site running the NAT64 box</t>
<t>Well-known: A well known prefix that is reserved for this purpose. We have the following different options:
<list>
<t>IPv4 mapped prefix</t>
<t>IPv4 compatible prefix</t>
<t>A new prefix assigned by IANA for this purpose</t>
</list>
</t>
</list>
</t>
<t>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 (this is especially useful in the case of communications
involving dual stack hosts). 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 one
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.</t>
<t>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.
</t>
<t>However, there are several issues when considering using the well-known prefix option, namely:
<list>
<t>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.
However, in the case
of private IPv4 addresses, the synthesis can only be done by an authoritative
server, so DNSSEC issues don't apply, so there is no need synthetic addresses from "real" ones. </t>
<t>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 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.</t>
<t>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). </t>
</list>
</t>
</section>
</section>
-->
</back>
</rfc>
<!-- LocalWords: Rsav recursor RNAME TTL SOA RDLENGTH RDATA IANA PTR ARPA ADDR
-->
<!-- LocalWords: QNAME nameserver RRSets ISP Addr addr lookups routable LIR GW
-->
<!-- LocalWords: unicast internet AAAASYNT DHCP arkko townsley pre intra ECMP
-->
<!-- LocalWords: balancer ISPs thei succcessful synthetize unnecesary Thaler
-->
<!-- LocalWords: Tsirtsis Qualcomm Jari Xing Hiroshi Miyata Jankiewicz Magnus
-->
<!-- LocalWords: Westerlund Austein Matthijs Mekking Perrault Bagnulo Iljitsch
-->
<!-- LocalWords: Beijnum
-->| PAFTECH AB 2003-2026 | 2026-04-23 14:32:49 |