summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc6147.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc6147.txt')
-rw-r--r--doc/rfc/rfc6147.txt1795
1 files changed, 1795 insertions, 0 deletions
diff --git a/doc/rfc/rfc6147.txt b/doc/rfc/rfc6147.txt
new file mode 100644
index 0000000..0ccd933
--- /dev/null
+++ b/doc/rfc/rfc6147.txt
@@ -0,0 +1,1795 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) M. Bagnulo
+Request for Comments: 6147 UC3M
+Category: Standards Track A. Sullivan
+ISSN: 2070-1721 Shinkuro
+ P. Matthews
+ Alcatel-Lucent
+ I. van Beijnum
+ IMDEA Networks
+ April 2011
+
+
+ DNS64: DNS Extensions for Network Address Translation
+ from IPv6 Clients to IPv4 Servers
+
+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 is an Internet Standards Track document.
+
+ This document is a product of the Internet Engineering Task Force
+ (IETF). It represents the consensus of the IETF community. It has
+ received public review and has been approved for publication by the
+ Internet Engineering Steering Group (IESG). Further information on
+ Internet Standards is available in Section 2 of RFC 5741.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ http://www.rfc-editor.org/info/rfc6147.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bagnulo, et al. Standards Track [Page 1]
+
+RFC 6147 DNS64 April 2011
+
+
+Copyright Notice
+
+ Copyright (c) 2011 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 Simplified BSD License.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bagnulo, et al. Standards Track [Page 2]
+
+RFC 6147 DNS64 April 2011
+
+
+Table of Contents
+
+ 1. Introduction ....................................................4
+ 2. Overview ........................................................5
+ 3. Background to DNS64-DNSSEC Interaction ..........................7
+ 4. Terminology .....................................................9
+ 5. DNS64 Normative Specification ..................................10
+ 5.1. Resolving AAAA Queries and the Answer Section .............11
+ 5.1.1. The Answer when There is AAAA Data Available .......11
+ 5.1.2. The Answer when There is an Error ..................11
+ 5.1.3. Dealing with Timeouts ..............................12
+ 5.1.4. Special Exclusion Set for AAAA Records .............12
+ 5.1.5. Dealing with CNAME and DNAME .......................12
+ 5.1.6. Data for the Answer when Performing Synthesis ......13
+ 5.1.7. Performing the Synthesis ...........................13
+ 5.1.8. Querying in Parallel ...............................14
+ 5.2. Generation of the IPv6 Representations of IPv4 Addresses ..14
+ 5.3. Handling Other Resource Records and the Additional
+ Section ...................................................15
+ 5.3.1. PTR Resource Record ................................15
+ 5.3.2. Handling the Additional Section ....................16
+ 5.3.3. Other Resource Records .............................17
+ 5.4. Assembling a Synthesized Response to a AAAA Query .........17
+ 5.5. DNSSEC Processing: DNS64 in Validating Resolver Mode ......17
+ 6. Deployment Notes ...............................................19
+ 6.1. DNS Resolvers and DNS64 ...................................19
+ 6.2. DNSSEC Validators and DNS64 ...............................19
+ 6.3. DNS64 and Multihomed and Dual-Stack Hosts .................19
+ 6.3.1. IPv6 Multihomed Hosts ..............................19
+ 6.3.2. Accidental Dual-Stack DNS64 Use ....................20
+ 6.3.3. Intentional Dual-Stack DNS64 Use ...................21
+ 7. Deployment Scenarios and Examples ..............................21
+ 7.1. Example of "an IPv6 Network to the IPv4 Internet"
+ Setup with DNS64 in DNS Server Mode .......................22
+ 7.2. Example of "an IPv6 Network to the IPv4 Internet"
+ Setup with DNS64 in Stub-Resolver Mode ....................23
+ 7.3. Example of "the IPv6 Internet to an IPv4 Network"
+ Setup with DNS64 in DNS Server Mode .......................24
+ 8. Security Considerations ........................................27
+ 9. Contributors ...................................................27
+ 10. Acknowledgements ..............................................27
+ 11. References ....................................................28
+ 11.1. Normative References .....................................28
+ 11.2. Informative References ...................................28
+ Appendix A. Motivations and Implications of Synthesizing AAAA
+ Resource Records when Real AAAA Resource Records
+ Exist ................................................30
+
+
+
+
+Bagnulo, et al. Standards Track [Page 3]
+
+RFC 6147 DNS64 April 2011
+
+
+1. Introduction
+
+ This document specifies DNS64, a mechanism that is part of the
+ toolbox for IPv4-IPv6 transition and coexistence. DNS64, used
+ together with an IPv6/IPv4 translator such as stateful NAT64
+ [RFC6146], 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 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).
+
+ Together with an IPv6/IPv4 translator, these two mechanisms allow an
+ IPv6-only client to initiate communications to an IPv4-only server
+ using the Fully Qualified Domain Name (FQDN) of the server.
+
+ These mechanisms are expected to play a critical role in the IPv4-
+ IPv6 transition and coexistence. 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 features
+ require performing the DNS64 function directly in the end hosts
+ themselves.
+
+ This document is structured as follows: Section 2 provides a
+ non-normative overview of the behavior of DNS64. Section 3 provides
+ a non-normative background required to understand the interaction
+ between DNS64 and DNS Security Extensions (DNSSEC). The normative
+ specification of DNS64 is provided in Sections 4, 5, and 6.
+ Section 4 defines the terminology, Section 5 is the actual DNS64
+ specification, and Section 6 covers deployment issues. Section 7 is
+ non-normative and provides a set of examples and typical deployment
+ scenarios.
+
+
+
+
+
+
+
+
+
+Bagnulo, et al. Standards Track [Page 4]
+
+RFC 6147 DNS64 April 2011
+
+
+2. Overview
+
+ This section provides an introduction to the DNS64 mechanism.
+
+ 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 and 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
+ and 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.
+
+ 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.
+
+ 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 addresses representing IPv4
+ addresses included in the AAAA RR synthesized by the DNS64 contain
+ Pref64::/n, and they also embed the original IPv4 address.
+
+ 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
+
+
+
+Bagnulo, et al. Standards Track [Page 5]
+
+RFC 6147 DNS64 April 2011
+
+
+ that IPv6 packets addressed to an IPv6 destination address that
+ contains the Pref64::/n be delivered to an IPv6/IPv4 translator that
+ has that particular Pref64::/n configured, so they can be translated
+ into IPv4 packets.
+
+ 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.
+
+ 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.
+
+ The prefixes to be used as Pref64::/n and their applicability are
+ discussed in [RFC6052]. There are two types of prefixes that can be
+ used as Pref64::/n.
+
+ o The Pref64::/n can be the Well-Known Prefix 64:ff9b::/96 reserved
+ by [RFC6052] for the purpose of representing IPv4 addresses in
+ IPv6 address space.
+
+ o 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.
+
+ 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.
+
+ The DNS64 function can be performed in any of three places. The
+ terms below are more formally defined in Section 4.
+
+ The first option is to locate the DNS64 function in authoritative
+ servers for a zone. In this case, the authoritative server provides
+ synthetic AAAA RRs for an IPv4-only host in its zone. This is one
+ type of DNS64 server.
+
+
+
+
+
+
+Bagnulo, et al. Standards Track [Page 6]
+
+RFC 6147 DNS64 April 2011
+
+
+ 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-resolver
+ mode". This is a second type of DNS64 server, and it is also one
+ type of DNS64 resolver.
+
+ 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 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.
+
+3. Background to DNS64-DNSSEC Interaction
+
+ DNSSEC ([RFC4033], [RFC4034], [RFC4035]) 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.
+ Moreover, a security-aware recursive resolver can be validating or
+ non-validating, according to operator policy. In the cases below,
+ the recursive resolver 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 to be 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 "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.
+
+
+
+
+
+
+
+Bagnulo, et al. Standards Track [Page 7]
+
+RFC 6147 DNS64 April 2011
+
+
+ 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.
+
+ Here are the possible cases:
+
+ 1. 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. The
+ DNS64 can do validation of the response, if dictated by its local
+ policy.
+
+ 2. 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.
+
+ 3. 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 [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 receives a query with
+ the DO bit set and the CD bit set. In this case, the DNS64 is
+ supposed to pass on all the data it gets to the query initiator
+ (see Section 3.2.2 of [RFC4035]). This case will not work with
+ DNS64, unless the validating resolver is prepared to do DNS64
+ itself. If the DNS64 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 resolver receives a query
+ with the DO bit clear and the CD bit 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.
+
+ 6. A security-aware and validating DNS64 resolver receives a query
+ with the DO bit set and the CD bit clear. This works like the
+ previous case, except that the resolver should also set the
+ "Authentic Data" (AD) bit on the response.
+
+
+
+
+Bagnulo, et al. Standards Track [Page 8]
+
+RFC 6147 DNS64 April 2011
+
+
+ 7. A security-aware and validating DNS64 resolver receives a query
+ with the DO bit set and the CD bit 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. The node needs to do
+ DNS64 itself, or else communication will fail.
+
+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 request.
+
+ 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).
+
+ DNS64 recursive resolver: A recursive resolver that provides the
+ DNS64 functionality as part of its operation. This is the same
+ thing as "DNS64 in recursive-resolver mode".
+
+ DNS64 resolver: Any resolver (stub resolver or recursive resolver)
+ that provides the DNS64 function.
+
+ DNS64 server: Any server providing the DNS64 function. This
+ includes the server portion of a recursive resolver when it is
+ providing the DNS64 function.
+
+ IPv4-only server: Servers running IPv4-only applications and servers
+ that can only use IPv4, as well as cases where only IPv4
+ connectivity is available to the server.
+
+ IPv6-only hosts: Hosts running IPv6-only applications and hosts that
+ can only use IPv6, as well as cases where only IPv6 connectivity
+ is available to the client.
+
+
+
+
+
+
+
+
+Bagnulo, et al. Standards Track [Page 9]
+
+RFC 6147 DNS64 April 2011
+
+
+ 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. Full discussion of DNS
+ recursion is beyond the scope of this document; see [RFC1034] and
+ [RFC1035] for full details.
+
+ Synthetic RR: A DNS resource record (RR) that is not contained in
+ the authoritative servers' zone data, but which is instead
+ synthesized from other RRs in the same zone. An example is a
+ synthetic AAAA record created from an A record.
+
+ 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] and [RFC1035] and
+ with current NAT terminology from [RFC4787]. Some parts of this
+ document assume familiarity with the terminology of the DNS security
+ extensions outlined in [RFC4035]. It is worth emphasizing that while
+ DNS64 is a logical function separate from the DNS, it is nevertheless
+ closely associated with that protocol. It depends on the DNS
+ protocol, and some behavior of DNS64 will interact with regular DNS
+ responses.
+
+5. DNS64 Normative Specification
+
+ 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. It
+ works within those DNS functions, and appears on the network as
+ though it were a "plain" DNS resolver or name server conforming to
+ [RFC1034] and [RFC1035].
+
+ 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 [RFC5735].
+
+ DNS messages contain several sections. The portion of a DNS message
+ that is altered by DNS64 is the answer section, which is discussed
+ below in Section 5.1. The resulting synthetic answer is put together
+ with other sections, and that creates the message that is actually
+ returned as the response to the DNS query. Assembling that response
+ is covered below in Section 5.4.
+
+ DNS64 also responds to PTR queries involving addresses containing any
+ of the IPv6 prefixes it uses for synthesis of AAAA RRs.
+
+
+
+
+Bagnulo, et al. Standards Track [Page 10]
+
+RFC 6147 DNS64 April 2011
+
+
+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. The query may be answered from
+ a local cache, if one is available. DNS64 operation for classes
+ other than IN is undefined, and a DNS64 MUST behave as though no
+ DNS64 function is configured.
+
+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, as considered in
+ Section 5.1.4. If there is (non-excluded) AAAA data available, DNS64
+ SHOULD NOT include synthetic AAAA RRs in the response (see Appendix A
+ 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 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 other than
+ what would usually happen in DNS operation.
+
+ Any other RCODE is treated as though the RCODE were 0 (see
+ Sections 5.1.6 and 5.1.7) 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 (see [RFC4074]). Note that this means, for practical
+ purposes, that several different classes of error in the DNS are all
+ treated as though a AAAA record is not available for that owner name.
+
+ 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.
+
+
+
+
+
+Bagnulo, et al. Standards Track [Page 11]
+
+RFC 6147 DNS64 April 2011
+
+
+5.1.3. Dealing with Timeouts
+
+ If the query receives no answer before the timeout (which might be
+ the timeout from every authoritative server, depending on whether the
+ DNS64 is in recursive-resolver mode), it is treated as RCODE=2
+ (Server failure).
+
+5.1.4. 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:0:0/96 network, and possibly (depending on the context) AAAA
+ records with the site's Pref64::/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.
+
+ 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 by default SHOULD 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.5. 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 a
+ 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, any chains of CNAME or DNAME RRs
+ are included as part of the answer along with the synthetic AAAA (if
+ appropriate).
+
+
+
+Bagnulo, et al. Standards Track [Page 12]
+
+RFC 6147 DNS64 April 2011
+
+
+5.1.6. Data for the Answer when Performing Synthesis
+
+ 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
+ authoritative 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. 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.7. The DNS64 returns the
+ synthesized AAAA records in the answer section, removing the A
+ records that form the basis of the synthesis.
+
+5.1.7. 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 the original CLASS field, 1. Under this
+ specification, DNS64 for any CLASS other than 1 is undefined.
+
+ o The Time to Live (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. If the SOA RR
+ was not delivered with the negative response to the AAAA query,
+ then the DNS64 SHOULD use the TTL of the original A RR or
+ 600 seconds, whichever is shorter. It is possible instead to
+ query explicitly for the SOA RR and use the result of that query,
+ but this will increase query load and time to resolution for
+ little additional benefit.) This is in keeping with the approach
+ used in negative caching [RFC2308].
+
+ 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 MUST
+ check each A RR against configured 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.
+
+
+
+
+
+Bagnulo, et al. Standards Track [Page 13]
+
+RFC 6147 DNS64 April 2011
+
+
+5.1.8. Querying in Parallel
+
+ The DNS64 MAY perform the query for the AAAA RR and for the A RR in
+ parallel, in order to minimize the delay.
+
+ NOTE: Querying in parallel will 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.)
+
+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:
+
+ o 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 an 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.
+
+ o The algorithm MUST be reversible; i.e., it MUST be possible to
+ derive the original IPv4 address from the IPv6 representation.
+
+ o 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 a fixed
+ string to be used as a suffix).
+
+ * For each prefix Pref64::/n, n MUST be less than or equal to 96.
+ If one or more Pref64::/n are configured in the DNS64 through
+ any means (such as manual configuration, or other automatic
+ means not specified in this document), the default algorithm
+ MUST use these prefixes (and not use the Well-Known Prefix).
+ If no prefix is available, the algorithm MUST use the
+ Well-Known Prefix 64:ff9b::/96 defined in [RFC6052] to
+ represent the IPv4 unicast address range.
+
+
+
+
+
+Bagnulo, et al. Standards Track [Page 14]
+
+RFC 6147 DNS64 April 2011
+
+
+ A DNS64 MUST support the algorithm for generating IPv6
+ representations of IPv4 addresses defined in Section 2 of [RFC6052].
+ Moreover, the aforementioned algorithm MUST be the default algorithm
+ used by the DNS64. While the normative description of the algorithm
+ is provided in [RFC6052], a sample description of the algorithm and
+ its application to different scenarios are provided in Section 7 for
+ illustration purposes.
+
+5.3. Handling Other Resource Records and the Additional Section
+
+5.3.1. PTR Resource Record
+
+ 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 [RFC3596], and examine the resulting
+ address to see whether its prefix matches any of the locally
+ configured Pref64::/n or the default Well-Known Prefix. 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:
+
+ 1. 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.
+
+ 2. The second option is for the DNS64 name server to synthesize a
+ CNAME mapping the IP6.ARPA namespace to the corresponding
+ IN-ADDR.ARPA name. In this case, the DNS64 name server SHOULD
+ ensure that there is RDATA at the PTR of the corresponding
+ IN-ADDR.ARPA name, and that there is not an existing CNAME at
+ that name. This is in order to avoid synthesizing a CNAME that
+ makes a CNAME chain longer or that does not actually point to
+
+
+
+Bagnulo, et al. Standards Track [Page 15]
+
+RFC 6147 DNS64 April 2011
+
+
+ anything. 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
+ disadvantages are 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.
+
+ 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 name server 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.
+
+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.
+
+ NOTE: 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.
+ 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 name server that is
+ unaware of the NAT64 in question. The result in this case will be
+ resolution failure anyway, but later in the resolution operation.
+ The prohibition on synthetic data in the additional section
+ reduces, but does not eliminate, the possibility of resolution
+ failures due to cached DNS data from behind the DNS64. See
+ Section 6.
+
+
+
+
+
+
+
+
+Bagnulo, et al. Standards Track [Page 16]
+
+RFC 6147 DNS64 April 2011
+
+
+5.3.3. Other Resource Records
+
+ If the DNS64 is in recursive-resolver mode, then considerations
+ outlined in [DEFAULT-LOCAL-ZONES] may be relevant.
+
+ All other RRs MUST be returned unchanged. This includes responses to
+ queries for A RRs.
+
+5.4. Assembling a Synthesized Response to a AAAA Query
+
+ A 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 (initiator's) 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
+ (initiator's) query. The answer section is populated according to
+ the rules in Section 5.1.7. The authority and additional sections
+ are copied from the response to the final query that the DNS64
+ performed, and used as the basis for synthesis.
+
+ The final response from the DNS64 is subject to all the standard DNS
+ rules, including truncation [RFC1035] and EDNS0 handling [RFC2671].
+
+5.5. DNSSEC Processing: DNS64 in Validating Resolver Mode
+
+ We consider the case where a recursive resolver 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:
+
+ 1. If CD is not set and DO is not set, vDNS64 SHOULD perform
+ validation and do synthesis as needed. See the next item for
+ rules about how to do validation and synthesis. In this case,
+ however, vDNS64 MUST NOT set the AD bit in any response.
+
+
+
+
+
+Bagnulo, et al. Standards Track [Page 17]
+
+RFC 6147 DNS64 April 2011
+
+
+ 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 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.
+
+ 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. Standards Track [Page 18]
+
+RFC 6147 DNS64 April 2011
+
+
+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 realize 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 be unable to answer the necessary AAAA queries.
+
+6.2. DNSSEC Validators and DNS64
+
+ An existing DNSSEC validator (i.e., one that is 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 recursive resolver 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.
+
+
+
+
+
+
+Bagnulo, et al. Standards Track [Page 19]
+
+RFC 6147 DNS64 April 2011
+
+
+ +---------------+ +-------------+
+ | i1 (IPv6)+----NAT64--------+IPv4 Internet|
+ | | +-------------+
+ | host |
+ | | +-------------+
+ | i2 (IPv6)+-----------------+IPv6 Internet|
+ +---------------+ +-------------+
+
+ Figure 1: IPv6 Multihomed Hosts
+
+ 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.
+
+ 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 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
+ emphasizing that this arises because there are two networks involved.
+
+ +---------------+ +-------------+
+ | i1 (IPv6)+----NAT64--------+IPv4 Internet|
+ | | +-------------+
+ | host |
+ | | +-------------+
+ | i2 (IPv4)+-----------------+IPv4 Internet|
+ +---------------+ +-------------+
+
+ Figure 2: Accidental Dual-Stack DNS64 Use
+
+ The default configuration of dual-stack hosts is that IPv6 is
+ preferred over IPv4 ([RFC3484]). In that arrangement, the host will
+ often use the NAT64 when native IPv4 would be more desirable. 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
+
+
+
+
+
+
+
+Bagnulo, et al. Standards Track [Page 20]
+
+RFC 6147 DNS64 April 2011
+
+
+ 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
+ with a LAN, and not with the IPv4 Internet. The IPv4 Internet is
+ only accessible using the NAT64. 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.
+
+ +---------------+ +-------------+
+ | i1 (IPv6)+----NAT64--------+IPv4 Internet|
+ | | +-------------+
+ | host |
+ | |
+ | i2 (IPv4)+---(local LAN only)
+ +---------------+
+
+ Figure 3: Intentional Dual-Stack DNS64 Use
+
+ It is important for deployers of DNS64 to realize 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.
+
+7. Deployment Scenarios and Examples
+
+ In this section, we illustrate how the DNS64 behaves in different
+ scenarios that are expected to be common. In particular, we will
+ consider the following scenarios defined in [RFC6144]: the "an IPv6
+ network to the IPv4 Internet" scenario (both with DNS64 in DNS server
+ mode and in stub-resolver mode) and the "IPv6 Internet to an IPv4
+ network" setup (with DNS64 in DNS server mode only).
+
+
+
+
+
+Bagnulo, et al. Standards Track [Page 21]
+
+RFC 6147 DNS64 April 2011
+
+
+ In all the examples below, there is an IPv6/IPv4 translator
+ connecting the IPv6 domain to the IPv4 one. Also, there is a name
+ server that is a dual-stack node, so it can communicate with IPv6
+ hosts using IPv6 and with IPv4 nodes using IPv4. In addition, we
+ assume that in the examples, the DNS64 function learns which IPv6
+ prefix it needs to use to map the IPv4 address space through manual
+ configuration.
+
+7.1. Example of "an IPv6 Network to the 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 network | | IPv4 |
+ | | +-------------+ | Internet |
+ | |--| Name server |--| |
+ | | | with DNS64 | | +----+ |
+ | +----+ | +-------------+ | | H2 | |
+ | | H1 |---| | | +----+ |
+ | +----+ | +------------+ | 192.0.2.1 |
+ | |---| IPv6/IPv4 |--| |
+ | | | Translator | | |
+ | | +------------+ | |
+ | | | | |
+ +---------------------+ +---------------+
+
+ Figure 4: "An IPv6 Network to the IPv4 Internet" Setup
+ with DNS64 in DNS Server Mode
+
+ The figure shows an IPv6 node H1 and an IPv4 node H2 with the IPv4
+ address 192.0.2.1 and FQDN h2.example.com.
+
+ The IPv6/IPv4 translator has an IPv4 address 203.0.113.1 assigned
+ to its IPv4 interface, and it is using the Well-Known Prefix
+ 64:ff9b::/96 to create IPv6 representations of IPv4 addresses. The
+ same prefix is configured in the DNS64 function in the local name
+ server.
+
+ 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 name server").
+
+
+
+
+Bagnulo, et al. Standards Track [Page 22]
+
+RFC 6147 DNS64 April 2011
+
+
+ The steps by which H1 establishes communication with H2 are:
+
+ 1. 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.
+
+ 2. The recursive name server resolves the query, and discovers that
+ there are no AAAA records for H2.
+
+ 3. The recursive name server performs an A-record query for H2 and
+ gets back an RRSet containing a single A record with the IPv4
+ address 192.0.2.1. The name server 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 and the
+ received IPv4 address in the lower 32 bits; i.e., the resulting
+ IPv6 address is 64:ff9b::192.0.2.1.
+
+ 4. 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.
+
+ 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.
+
+7.2. Example of "an IPv6 Network to the IPv4 Internet" Setup with DNS64
+ in Stub-Resolver Mode
+
+ This case is depicted in the following figure:
+
+ +---------------------+ +---------------+
+ |IPv6 network | | IPv4 |
+ | | +--------+ | Internet |
+ | |-----| Name |----| |
+ | +-----+ | | server | | +----+ |
+ | | H1 | | +--------+ | | H2 | |
+ | |with |---| | | +----+ |
+ | |DNS64| | +------------+ | 192.0.2.1 |
+ | +----+ |---| IPv6/IPv4 |--| |
+ | | | Translator | | |
+ | | +------------+ | |
+ | | | | |
+ +---------------------+ +---------------+
+
+ Figure 5: "An IPv6 Network to the IPv4 Internet" Setup
+ with DNS64 in Stub-Resolver Mode
+
+
+
+
+Bagnulo, et al. Standards Track [Page 23]
+
+RFC 6147 DNS64 April 2011
+
+
+ The figure shows an IPv6 node H1 implementing the DNS64 function and
+ an IPv4 node H2 with the IPv4 address 192.0.2.1 and FQDN
+ h2.example.com.
+
+ The IPv6/IPv4 translator has an IPv4 address 203.0.113.1 assigned
+ to its IPv4 interface, and it is using the Well-Known Prefix
+ 64:ff9b::/96 to create IPv6 representations of IPv4 addresses. The
+ same prefix is configured in the DNS64 function in H1.
+
+ 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 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 h2.example.com. 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 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 in the lower 32 bits; the resulting IPv6 address is
+ 64:ff9b::192.0.2.1.
+
+ 4. H1 sends a packet towards H2. The packet is sent to the
+ destination address 64:ff9b::192.0.2.1.
+
+ 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.
+
+7.3. Example of "the IPv6 Internet to an IPv4 Network" Setup with DNS64
+ in DNS Server Mode
+
+ 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.
+
+
+
+
+
+Bagnulo, et al. Standards Track [Page 24]
+
+RFC 6147 DNS64 April 2011
+
+
+ In some cases, this scenario can be addressed without using any form
+ of DNS64 function. This is because 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
+ [RFC6052] 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 [RFC6052]). 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.
+
+ 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
+ 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 to modify all of 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 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 a 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.
+
+
+
+
+
+
+
+
+
+
+
+
+Bagnulo, et al. Standards Track [Page 25]
+
+RFC 6147 DNS64 April 2011
+
+
+ The scenario for this case is depicted in the following figure:
+
+ +-----------+ +----------------------+
+ | | | IPv4 site |
+ | IPv6 | +------------+ | +----+ |
+ | Internet |----| IPv6/IPv4 |--|---| H2 | |
+ | | | Translator | | +----+ |
+ | | +------------+ | |
+ | | | | 192.0.2.1 |
+ | | +------------+ | |
+ | |----| Name server|--| |
+ | | | with DNS64 | | |
+ +-----------+ +------------+ | |
+ | | | |
+ +----+ | |
+ | H1 | +----------------------+
+ +----+
+
+ Figure 6: "The IPv6 Internet to an IPv4 Network" Setup
+ with DNS64 in DNS Server Mode
+
+ The figure shows an IPv6 node H1 and an IPv4 node H2 with the IPv4
+ address 192.0.2.1 and FQDN h2.example.com.
+
+ The IPv6/IPv4 translator is using an NSP 2001:db8::/96 to create IPv6
+ representations of IPv4 addresses. The same prefix is configured in
+ the DNS64 function in the local name server. The name server that
+ implements the DNS64 function is the authoritative name server for
+ the local domain.
+
+ The steps by which H1 establishes communication with H2 are:
+
+ 1. 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.
+
+ 2. The local DNS server resolves the query (locally), and discovers
+ that there are no AAAA records for H2.
+
+ 3. 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. 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.
+
+ 4. 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.
+
+
+
+Bagnulo, et al. Standards Track [Page 26]
+
+RFC 6147 DNS64 April 2011
+
+
+ 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.
+
+8. Security Considerations
+
+ DNS64 operates in combination with the DNS, and is therefore subject
+ to whatever security considerations are appropriate to the DNS mode
+ in which the DNS64 is operating (i.e., authoritative, recursive, or
+ stub-resolver mode).
+
+ DNS64 has the potential to interfere with the functioning of DNSSEC,
+ because DNS64 modifies DNS answers, and DNSSEC is designed to detect
+ such modifications and to treat modified answers as bogus. See the
+ discussion above in Sections 3, 5.5, and 6.2.
+
+ Additionally, for the correct functioning of the translation
+ services, the DNS64 and the NAT64 need to use the same Pref64. If an
+ attacker manages to change the Pref64 used by the DNS64, the traffic
+ generated by the host that receives the synthetic reply will be
+ delivered to the altered Pref64. This can result in either a denial-
+ of-service (DoS) attack (if the resulting IPv6 addresses are not
+ assigned to any device), a flooding attack (if the resulting IPv6
+ addresses are assigned to devices that do not wish to receive the
+ traffic), or an eavesdropping attack (in case the Pref64 is routed
+ through the attacker).
+
+9. Contributors
+
+ Dave Thaler
+ Microsoft
+ dthaler@windows.microsoft.com
+
+10. Acknowledgements
+
+ This document 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: Jaap
+ Akkerhuis, Mark Andrews, Jari Arkko, Rob Austein, Timothy Baldwin,
+ Fred Baker, Doug Barton, Marc Blanchet, Cameron Byrne, Brian
+ Carpenter, Zhen Cao, Hui Deng, Francis Dupont, Patrik Faltstrom,
+ David Harrington, Ed Jankiewicz, Peter Koch, Suresh Krishnan, Martti
+ Kuparinen, 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, Jeff
+ Westhead, Florian Weimer, Dan Wing, Xu Xiaohu, and Xiangsong Cui.
+
+
+
+
+Bagnulo, et al. Standards Track [Page 27]
+
+RFC 6147 DNS64 April 2011
+
+
+ Marcelo Bagnulo and Iljitsch van Beijnum are partly funded by
+ Trilogy, a research project supported by the European Commission
+ under its Seventh Framework Program.
+
+11. References
+
+11.1. Normative References
+
+ [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.
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)",
+ RFC 2671, August 1999.
+
+ [RFC4787] Audet, F. and C. Jennings, "Network Address Translation
+ (NAT) Behavioral Requirements for Unicast UDP", BCP 127,
+ RFC 4787, January 2007.
+
+ [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X.
+ Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052,
+ October 2010.
+
+11.2. Informative References
+
+ [DEFAULT-LOCAL-ZONES]
+ Andrews, M., "Locally-served DNS Zones", Work in Progress,
+ March 2011.
+
+ [RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound,
+ "Dynamic Updates in the Domain Name System (DNS UPDATE)",
+ RFC 2136, April 1997.
+
+ [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS
+ NCACHE)", RFC 2308, March 1998.
+
+ [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.
+
+
+
+
+Bagnulo, et al. Standards Track [Page 28]
+
+RFC 6147 DNS64 April 2011
+
+
+ [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
+ 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.
+
+ [RFC4074] Morishita, Y. and T. Jinmei, "Common Misbehavior Against
+ DNS Queries for IPv6 Addresses", RFC 4074, May 2005.
+
+ [RFC5735] Cotton, M. and L. Vegoda, "Special Use IPv4 Addresses",
+ BCP 153, RFC 5735, January 2010.
+
+ [RFC6144] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for
+ IPv4/IPv6 Translation", RFC 6144, April 2011.
+
+ [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful
+ NAT64: Network Address and Protocol Translation from IPv6
+ Clients to IPv4 Servers", RFC 6146, April 2011.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bagnulo, et al. Standards Track [Page 29]
+
+RFC 6147 DNS64 April 2011
+
+
+Appendix A. Motivations and Implications of Synthesizing AAAA Resource
+ Records when Real AAAA Resource Records Exist
+
+ The motivation for synthesizing AAAA RRs when real AAAA RRs exist is
+ to support the following scenario:
+
+ o 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 running on the same host. That host has fully
+ routable IPv4 and IPv6 addresses, and hence the authoritative DNS
+ server has an A record and a AAAA record.
+
+ o 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.
+
+ o The client issues a DNS query to a DNS64 resolver.
+
+ 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.
+
+ The implication of including synthetic AAAA RRs when real AAAA RRs
+ exist is that translated connectivity may be preferred over native
+ connectivity in some cases where the DNS64 is operated in DNS server
+ mode.
+
+ RFC 3484 [RFC3484] rules use "longest matching prefix" 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 (referred to as a Network-Specific Prefix
+ (NSP) in [RFC6052]) is used, then a synthetic AAAA RR is likely to be
+ preferred.
+
+ This means that without further configuration:
+
+ o In the "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 [RFC6052] is used, it will probably
+ prefer native connectivity.
+
+
+
+
+
+
+
+Bagnulo, et al. Standards Track [Page 30]
+
+RFC 6147 DNS64 April 2011
+
+
+ o 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).
+
+ o In the "an IPv6 network to an 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 matching prefix" rule will select native
+ connectivity.
+
+ The problem can be solved by properly configuring the RFC 3484
+ [RFC3484] policy table.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bagnulo, et al. Standards Track [Page 31]
+
+RFC 6147 DNS64 April 2011
+
+
+Authors' Addresses
+
+ Marcelo Bagnulo
+ UC3M
+ Av. Universidad 30
+ Leganes, Madrid 28911
+ Spain
+
+ Phone: +34-91-6249500
+ 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
+ EMail: philip_matthews@magma.ca
+
+
+ Iljitsch van Beijnum
+ IMDEA Networks
+ Avda. del Mar Mediterraneo, 22
+ Leganes, Madrid 28918
+ Spain
+
+ Phone: +34-91-6246245
+ EMail: iljitsch@muada.com
+
+
+
+
+
+
+
+
+
+
+Bagnulo, et al. Standards Track [Page 32]
+