--- /dev/null
+
+
+
+BEHAVE WG M. Bagnulo
+Internet-Draft UC3M
+Intended status: Standards Track A. Sullivan
+Expires: April 22, 2010 Shinkuro
+ P. Matthews
+ Alcatel-Lucent
+ I. van Beijnum
+ IMDEA Networks
+ October 19, 2009
+
+
+DNS64: DNS extensions for Network Address Translation from IPv6 Clients
+ to IPv4 Servers
+ draft-ietf-behave-dns64-01
+
+Status of this Memo
+
+ This Internet-Draft is submitted to IETF in full conformance with the
+ provisions of BCP 78 and BCP 79.
+
+ Internet-Drafts are working documents of the Internet Engineering
+ Task Force (IETF), its areas, and its working groups. Note that
+ other groups may also distribute working documents as Internet-
+ Drafts.
+
+ Internet-Drafts are draft documents valid for a maximum of six months
+ and may be updated, replaced, or obsoleted by other documents at any
+ time. It is inappropriate to use Internet-Drafts as reference
+ material or to cite them other than as "work in progress."
+
+ The list of current Internet-Drafts can be accessed at
+ http://www.ietf.org/ietf/1id-abstracts.txt.
+
+ The list of Internet-Draft Shadow Directories can be accessed at
+ http://www.ietf.org/shadow.html.
+
+ This Internet-Draft will expire on April 22, 2010.
+
+Copyright Notice
+
+ Copyright (c) 2009 IETF Trust and the persons identified as the
+ document authors. All rights reserved.
+
+ This document is subject to BCP 78 and the IETF Trust's Legal
+ Provisions Relating to IETF Documents in effect on the date of
+ publication of this document (http://trustee.ietf.org/license-info).
+ Please review these documents carefully, as they describe your rights
+ and restrictions with respect to this document.
+
+
+
+Bagnulo, et al. Expires April 22, 2010 [Page 1]
+\f
+Internet-Draft DNS64 October 2009
+
+
+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.
+
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
+ 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
+ 3. Background to DNS64 - DNSSEC interaction . . . . . . . . . . . 6
+ 4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 8
+ 5. DNS64 Normative Specification . . . . . . . . . . . . . . . . 9
+ 5.1. Resolving AAAA queries and the answer section . . . . . . 9
+ 5.1.1. The answer when there is AAAA data available . . . . . 9
+ 5.1.2. The answer when there is an error . . . . . . . . . . 9
+ 5.1.3. Data for the answer when performing synthesis . . . . 9
+ 5.1.4. Performing the synthesis . . . . . . . . . . . . . . . 10
+ 5.1.5. Querying in parallel . . . . . . . . . . . . . . . . . 11
+ 5.2. Generation of the IPv6 representations of IPv4
+ addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
+ 5.3. Handling other RRs . . . . . . . . . . . . . . . . . . . . 12
+ 5.3.1. PTR queries . . . . . . . . . . . . . . . . . . . . . 12
+ 5.3.2. Handling the additional section . . . . . . . . . . . 13
+ 5.3.3. Other records . . . . . . . . . . . . . . . . . . . . 13
+ 5.4. Assembling a synthesized response to a AAAA query . . . . 14
+ 5.5. DNSSEC processing: DNS64 in recursive server mode . . . . 14
+ 5.6. DNS64 and multihoming . . . . . . . . . . . . . . . . . . 15
+ 6. Deployment notes . . . . . . . . . . . . . . . . . . . . . . . 16
+ 6.1. DNS resolvers and DNS64 . . . . . . . . . . . . . . . . . 16
+ 6.2. DNSSEC validators and DNS64 . . . . . . . . . . . . . . . 16
+ 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16
+ 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 16
+ 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
+ 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
+ 10.1. Normative References . . . . . . . . . . . . . . . . . . . 17
+ 10.2. Informative References . . . . . . . . . . . . . . . . . . 18
+ Appendix A. Deployment scenarios and examples . . . . . . . . . . 20
+ A.1. Embed and Zero-Pad algorithm description . . . . . . . . . 21
+ A.2. An-IPv6-network-to-IPv4-Internet setup with DNS64 in
+ DNS server mode . . . . . . . . . . . . . . . . . . . . . 22
+ A.3. An-IPv6-network-to-IPv4-Internet setup with DNS64 in
+ stub-resolver mode . . . . . . . . . . . . . . . . . . . . 23
+
+
+
+Bagnulo, et al. Expires April 22, 2010 [Page 2]
+\f
+Internet-Draft DNS64 October 2009
+
+
+ A.4. IPv6-Internet-to-an-IPv4-network setup DNS64 in DNS
+ server mode . . . . . . . . . . . . . . . . . . . . . . . 25
+ Appendix B. Motivations and Implications of synthesizing AAAA
+ RR when real AAAA RR exists . . . . . . . . . . . . . 27
+ Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bagnulo, et al. Expires April 22, 2010 [Page 3]
+\f
+Internet-Draft DNS64 October 2009
+
+
+1. Introduction
+
+ This document specifies DNS64, a mechanism that is part of the
+ toolbox for IPv6-IPv4 transition and co-existence. DNS64, used
+ together with an IPv6/IPv4 translator such as NAT64
+ [I-D.bagnulo-behave-nat64], allows an IPv6-only client to initiate
+ communications by name to an IPv4-only server.
+
+ DNS64 is a mechanism for synthesizing AAAA resource records (RRs)
+ from A RRs. A synthetic AAAA RR created by the DNS64 from an
+ original A RR contains the same FQDN of the original A RR but it
+ contains an IPv6 address instead of an IPv4 address. The IPv6
+ address is an IPv6 representation of the IPv4 address contained in
+ the original A RR. The IPv6 representation of the IPv4 address is
+ algorithmically generated from the IPv4 address returned in the A RR
+ and a set of parameters configured in the DNS64 (typically, an IPv6
+ prefix used by IPv6 representations of IPv4 addresses and optionally
+ other parameters).
+
+ Together with a IPv6/IPv4 translator, these two mechanisms allow an
+ IPv6-only client to initiate communications to an IPv4-only server
+ using the FQDN of the server.
+
+ These mechanisms are expected to play a critical role in the IPv4-
+ IPv6 transition and co-existence. Due to IPv4 address depletion, it
+ is likely that in the future, many IPv6-only clients will want to
+ connect to IPv4-only servers. In the typical case, the approach only
+ requires the deployment of IPv6/IPv4 translators that connect an
+ IPv6-only network to an IPv4-only network, along with the deployment
+ of one or more DNS64-enabled name servers. However, some advanced
+ features require performing the DNS64 function directly by the end-
+ hosts themselves.
+
+
+2. Overview
+
+ This section provides a non-normative introduction to the DNS64
+ mechanism.
+
+ We assume that we have an IPv6/IPv4 translator box connecting an IPv4
+ network and an IPv6 network. The IPv6/IPv4 translator device
+ provides translation services between the two networks enabling
+ communication between IPv4-only hosts and IPv6-only hosts. (NOTE: By
+ IPv6-only hosts we mean hosts running IPv6-only applications, hosts
+ that can only use IPv6, as well as the cases where only IPv6
+ connectivity is available to the client. By IPv4-only servers we
+ mean servers running IPv4-only applications, servers that can only
+ use IPv4, as well as the cases where only IPv4 connectivity is
+
+
+
+Bagnulo, et al. Expires April 22, 2010 [Page 4]
+\f
+Internet-Draft DNS64 October 2009
+
+
+ available to the server). The IPv6/IPv4 translator used in
+ conjunction with DNS64 must allow communications initiated from the
+ IPv6-only host to the IPv4-only host.
+
+ To allow an IPv6 initiator to do a standard AAAA RR DNS lookup to
+ learn the address of the responder, DNS64 is used to synthesize a
+ AAAA record from an A record containing a real IPv4 address of the
+ responder, whenever the DNS64 service cannot retrieve a AAAA record
+ for the requested host name. The DNS64 device appears as a regular
+ recursive resolver for the IPv6 initiator. The DNS64 box receives an
+ AAAA DNS query generated by the IPv6 initiator. It first attempts a
+ recursive resolution for the requested AAAA records. If there is no
+ AAAA record available for the target node (which is the normal case
+ when the target node is an IPv4-only node), DNS64 performs a query
+ for A records. If any A records are discovered, DNS64 creates a
+ synthetic AAAA RR from the information retrieved in each A RR.
+
+ The FQDN of a synthetic AAAA RR is the same as that of the original A
+ RR, but an IPv6 representation of the IPv4 address contained in the
+ original A RR is included in the AAAA RR. The IPv6 representation of
+ the IPv4 address is algorithmically generated from the IPv4 address
+ and additional parameters configured in the DNS64. Among those
+ parameters configured in the DNS64, there is at least one IPv6
+ prefix, called Pref64::/n. The IPv6 address representing IPv4
+ addresses included in the AAAA RR synthesized by the DNS64 function
+ contain Pref64::/n and they also embed the original IPv4 address.
+
+ The same algorithm and the same Pref64::/n prefix or prefixes must be
+ configured both in the DNS64 device and the IPv6/IPv4 translator, so
+ that both can algorithmically generate the same IPv6 representation
+ for a given IPv4 address. In addition, it is required that IPv6
+ packets addressed to an IPv6 destination that contains the Pref64::/n
+ be delivered to the IPv6/IPv4 translator, so they can be translated
+ into IPv4 packets.
+
+ Once the DNS64 has synthesized the AAAA RR, the synthetic AAAA RR is
+ passed back to the IPv6 initiator, which will initiate an IPv6
+ communication with the IPv6 address associated with the IPv4
+ receiver. The packet will be routed to the IPv6/IPv4 translator
+ which will forward it to the IPv4 network .
+
+ In general, the only shared state between the DNS64 and the IPv6/IPv4
+ translator is the Pref64::/n and an optional set of static
+ parameters. The Pref64::/n and the set of static parameters must be
+ configured to be the same on both; there is no communication between
+ the DNS64 device and IPv6/IPv4 translator functions. The mechanism
+ to be used for configuring the parameters of the DNS64 is beyond the
+ scope of this memo.
+
+
+
+Bagnulo, et al. Expires April 22, 2010 [Page 5]
+\f
+Internet-Draft DNS64 October 2009
+
+
+ The DNS64 function can be performed in two places.
+
+ One option is to locate the DNS64 function in recursive name
+ servers serving end hosts. In this case, when an IPv6-only host
+ queries the name server for AAAA RRs for an IPv4-only host, the
+ name server can perform the synthesis of AAAA RRs and pass them
+ back to the IPv6 only initiator. The main advantage of this mode
+ is that current IPv6 nodes can use this mechanism without
+ requiring any modification. This mode is called "DNS64 in DNS
+ server mode".
+
+ The other option is to place the DNS64 function in the end hosts
+ themselves, coupled to the local stub resolver. In this case, the
+ stub resolver will try to obtain (real) AAAA RRs and in case they
+ are not available, the DNS64 function will synthesize AAAA RRs for
+ internal usage. This mode is compatible with some advanced
+ functions like DNSSEC validation in the end host. The main
+ drawback of this mode is its deployability, since it requires
+ changes in the end hosts. This mode is called "DNS64 in stub-
+ resolver mode"".
+
+
+3. Background to DNS64 - DNSSEC interaction
+
+ DNSSEC presents a special challenge for DNS64, because DNSSEC is
+ designed to detect changes to DNS answers, and DNS64 may alter
+ answers coming from an authoritative server.
+
+ A recursive resolver can be security-aware or security-oblivious.
+ Moreover, a security-aware recursive name server can be validating or
+ non-validating, according to operator policy. In the cases below,
+ the recursive server is also performing DNS64, and has a local policy
+ to validate. We call this general case vDNS64, but in all the cases
+ below the DNS64 functionality should be assumed needed.
+
+ DNSSEC includes some signaling bits that offer some indicators of
+ what the query originator understands.
+
+ If a query arrives at a vDNS64 device with the DO bit set, the query
+ originator is signaling that it understands DNSSEC. The DO bit does
+ not indicate that the query originator will validate the response.
+ It only means that the query originator can understand responses
+ containing DNSSEC data. Conversely, if the DO bit is clear, that is
+ evidence that the querying agent is not aware of DNSSEC.
+
+ If a query arrives at a vDNS64 device with the CD bit set, it is an
+ indication that the querying agent wants all the validation data so
+ it can do checking itself. By local policy, vDNS64 could still
+
+
+
+Bagnulo, et al. Expires April 22, 2010 [Page 6]
+\f
+Internet-Draft DNS64 October 2009
+
+
+ validate, but it must return all data to the querying agent anyway.
+
+ Here are the possible cases:
+
+ 1. A security-oblivious DNS64 node receives a query with the DO bit
+ clear. In this case, DNSSEC is not a concern, because the
+ querying agent does not understand DNSSEC responses.
+
+ 2. A security-oblivious DNS64 node receives a query with the DO bit
+ set, and the CD bit clear. This is just like the case of a non-
+ DNS64 case: the server doesn't support it, so the querying agent
+ is out of luck.
+
+ 3. A security-aware and non-validating DNS64 node receives a query
+ with the DO bit set and the CD bit clear. Such a resolver is not
+ validating responses, likely due to local policy (see [RFC4035],
+ section 4.2). For that reason, this case amounts to the same as
+ the previous case, and no validation happens.
+
+ 4. A security-aware and non-validating DNS64 node receives a query
+ with the DO bit set and the CD bit set. In this case, the
+ resolver is supposed to pass on all the data it gets to the query
+ initiator (see section 3.2.2 of [RFC4035]). This case will be
+ problematic with DNS64. If the DNS64 server modifies the record,
+ the client will get the data back and try to validate it, and the
+ data will be invalid as far as the client is concerned.
+
+ 5. A security-aware and validating DNS64 node receives a query with
+ the DO bit clear and CD clear. In this case, the resolver
+ validates the data. If it fails, it returns RCODE 2 (SERVFAIL);
+ otherwise, it returns the answer. This is the ideal case for
+ vDNS64. The resolver validates the data, and then synthesizes
+ the new record and passes that to the client. The client, which
+ is presumably not validating (else it would have set DO and CD),
+ cannot tell that DNS64 is involved.
+
+ 6. A security-aware and validating DNS64 node receives a query with
+ the DO bit set and CD clear. In principle, this ought to work
+ like the previous case, except that the resolver should also set
+ the AD bit on the response.
+
+ 7. A security-aware and validating DNS64 node receives a query with
+ the DO bit set and CD set. This is effectively the same as the
+ case where a security-aware and non-validating recursive resolver
+ receives a similar query, and the same thing will happen: the
+ downstream validator will mark the data as invalid if DNS64 has
+ performed synthesis.
+
+
+
+
+Bagnulo, et al. Expires April 22, 2010 [Page 7]
+\f
+Internet-Draft DNS64 October 2009
+
+
+4. Terminology
+
+ This section provides definitions for the special terms used in the
+ document.
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in RFC 2119 [RFC2119].
+
+ Authoritative server: A DNS server that can answer authoritatively a
+ given DNS question.
+
+ DNS64: A logical function that synthesizes DNS resource records (e.g
+ AAAA records containing IPv6 addresses) from DNS resource records
+ actually contained in the global DNS (e.g. A records containing
+ IPv4 addresses).
+
+ DNS64 recursor: A recursive resolver that provides the DNS64
+ functionality as part of its operation.
+
+ Recursive resolver: A DNS server that accepts requests from one
+ resolver, and asks another resolver for the answer on behalf of
+ the first resolver. In the context of this document, "the
+ recursive resolver" means a recursive resolver immediately next in
+ the DNS resolution chain from an end point. The end point usually
+ has only a stub resolver available.[[anchor5: I can't actually
+ remember why we needed the sentences following "In the context of
+ this document. . ." Unless someone has a reason, I'll take it
+ out. --ajs@shinkuro.com]]
+
+ 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.
+
+ Stub resolver: A resolver with minimum functionality, typically for
+ use in end points that depend on a recursive resolver. Most end
+ points on the Internet as of this writing use stub
+ resolvers.[[anchor6: Do we need this in the document? I don't
+ think so. 1034 defines this term. --ajs@shinkuro.com]]
+
+ IPv6/IPv4 translator: A device that translates IPv6 packets to IPv4
+ packets and vice-versa. It is only required that the
+ communication initiated from the IPv6 side be supported.
+
+ For a detailed understanding of this document, the reader should also
+ be familiar with DNS terminology from [RFC1034],[RFC1035] and current
+ NAT terminology from [RFC4787]. Some parts of this document assume
+ familiarity with the terminology of the DNS security extensions
+
+
+
+Bagnulo, et al. Expires April 22, 2010 [Page 8]
+\f
+Internet-Draft DNS64 October 2009
+
+
+ outlined in [RFC4035].
+
+
+5. DNS64 Normative Specification
+
+ A DNS64 is a logical function that synthesizes AAAA records from A
+ records. The DNS64 function may be implemented in a stub resolver,
+ in a recursive resolver, or in an authoritative name server.
+
+ The implementation SHOULD support mapping of IPv4 address ranges to
+ separate IPv6 prefixes for AAAA record synthesis. This allows
+ handling of special use IPv4 addresses [I-D.iana-rfc3330bis].
+ Multicast address handling is further specified in
+ [I-D.venaas-behave-mcast46].
+
+5.1. Resolving AAAA queries and the answer section
+
+ When the DNS64 receives a query for RRs of type AAAA and class IN, it
+ first attempts to retrieve non-synthetic RRs of this type and class,
+ either by performing a query or, in the case of an authoritative
+ server, by examining its own results.
+
+5.1.1. The answer when there is AAAA data available
+
+ If the query results in one or more AAAA records in the answer
+ section, the result is returned to the requesting client as per
+ normal DNS semantics (except in the case where the AAAA falls in the
+ ::ffff/96 network; see below for treatment of that network). In this
+ case, DNS64 SHOULD NOT include synthetic AAAA RRs in the response
+ (see Appendix B for an analysis of the motivations for and the
+ implications of not complying with this recommendation). By default
+ DNS64 implementations MUST NOT synthesize AAAA RRs when real AAAA RRs
+ exist.
+
+5.1.2. The answer when there is an error
+
+ If the query results in a response with an error code other than 0,
+ the result is handled according to normal DNS operation -- that is,
+ either the resolver tries again using a different server from the
+ authoritative NS RRSet, or it returns the error to the client. This
+ stage is still prior to any synthesis having happened, so a response
+ to be returned to the client does not need any special assembly than
+ would usually happen in DNS operation.
+
+5.1.3. Data for the answer when performing synthesis
+
+ If the query results in no error but an empty answer section in the
+ response, the DNS64 resolver attempts to retrieve A records for the
+
+
+
+Bagnulo, et al. Expires April 22, 2010 [Page 9]
+\f
+Internet-Draft DNS64 October 2009
+
+
+ name in question. If this new A RR query results in an empty answer
+ or in an error, then the empty result or error is used as the basis
+ for the answer returned to the querying client. (Transient errors
+ may result in retrying the query, depening on the operation of the
+ resolver; this is just as in Section 5.1.2.) If instead the query
+ results in one or more A RRs, the DNS64 synthesizes AAAA RRs based on
+ the A RRs according to the procedure outlined in Section 5.1.4. The
+ DNS64 resolver then returns the synthesized AAAA records in the
+ answer section to the client, removing the A records that form the
+ basis of the synthesis.
+
+ As an exception to the general rule about always returning the AAAA
+ records if they are returned in the answer, AAAA records with
+ addresses in the ::ffff/96 network are treated just like the case
+ where there is neither an error nor an empty answer section. This is
+ because a real IPv6-only node will not be any more able to reach the
+ addresses in ::ffff/96 than it is able to reach an IPv4 address
+ without assistance. An implementation MAY use the address in
+ ::ffff/96 as the basis of synthesis without querying for an A record,
+ by using the last 32 bits of the address provided in the AAAA record.
+ [[anchor10: I changed this to say "neither. . .nor" because the
+ previous version suggested that it would return the error-or-empty-
+ answer to the querying client, and that can't be right. Correct?
+ --ajs@shinkuro.com]]
+
+5.1.4. Performing the synthesis
+
+ A synthetic AAAA record is created from an A record as follows:
+
+ o The NAME field is set to the NAME field from the A record
+
+ o The TYPE field is set to 28 (AAAA)
+
+ o The CLASS field is set to 1 (IN)
+
+ o The TTL field is set to the minimum of the TTL of the original A
+ RR and the SOA RR for the queried domain. (Note that in order to
+ obtain the TTL of the SOA RR the DNS64 does not need to perform a
+ new query, but it can remember the TTL from the SOA RR in the
+ negative response to the AAAA query).
+
+ o The RDLENGTH field is set to 16
+
+ o The RDATA field is set to the IPv6 representation of the IPv4
+ address from the RDATA field of the A record. The DNS64 SHOULD
+ check each A RR against IPv4 address ranges and select the
+ corresponding IPv6 prefix to use in synthesizing the AAAA RR. See
+ Section 5.2 for discussion of the algorithms to be used in
+
+
+
+Bagnulo, et al. Expires April 22, 2010 [Page 10]
+\f
+Internet-Draft DNS64 October 2009
+
+
+ effecting the transformation.
+
+5.1.5. Querying in parallel
+
+ DNS64 MAY perform the query for the AAAA RR and for the A RR in
+ parallel, in order to minimize the delay. However, this would result
+ in performing unnecessary A RR queries in the case no AAAA RR
+ synthesis is required. A possible trade-off would be to perform them
+ sequentially but with a very short interval between them, so if we
+ obtain a fast reply, we avoid doing the additional query. (Note that
+ this discussion is relevant only if the DNS64 function needs to
+ perform external queries to fetch the RR. If the needed RR
+ information is available locally, as in the case of an authoritative
+ server, the issue is no longer relevant.)
+
+5.2. Generation of the IPv6 representations of IPv4 addresses
+
+ DNS64 supports multiple algorithms for the generation of the IPv6
+ representation of an IPv4 address. The constraints imposed on the
+ generation algorithms are the following:
+
+ The same algorithm to create an IPv6 address from an IPv4 address
+ MUST be used by both the DNS64 to create the IPv6 address to be
+ returned in the synthetic AAAA RR from the IPv4 address contained
+ in original A RR, and by the IPv6/IPv4 translator to create the
+ IPv6 address to be included in the destination address field of
+ the outgoing IPv6 packets from the IPv4 address included in the
+ destination address field of the incoming IPv4 packet.
+
+ The algorithm MUST be reversible, i.e. it MUST be possible to
+ extract the original IPv4 address from the IPv6 representation.
+
+ The input for the algorithm MUST be limited to the IPv4 address,
+ the IPv6 prefix (denoted Pref64::/n) used in the IPv6
+ representations and optionally a set of stable parameters that are
+ configured in the DNS64 (such as fixed string to be used as a
+ suffix).
+
+ If we note n the length of the prefix Pref64::/n, then n MUST
+ the less or equal than 96. If a Pref64::/n is configured
+ through any means in the DNS64 (such as manually configured, or
+ other automatic mean not specified in this document), the
+ default algorithm MUST use this prefix. If no prefix is
+ available, the algorithm MUST use the Well-Known prefix TBD1
+ defined in [I-D.thaler-behave-translator-addressing]
+
+ [[anchor12: Note in document: TBD1 in the passage above is to be
+ substituted by whatever prefix is assigned by IANA to be the well-
+
+
+
+Bagnulo, et al. Expires April 22, 2010 [Page 11]
+\f
+Internet-Draft DNS64 October 2009
+
+
+ known prefix.]]
+
+ DNS64 MUST support the following algorithms for generating IPv6
+ representations of IPv4 addresses defined in
+ [I-D.thaler-behave-translator-addressing]:
+
+ Zero-Pad And Embed, defined in section 3.2.3 of
+ [I-D.thaler-behave-translator-addressing]
+
+ Compensation-Pad And Embed, defined in section of 3.2.4 of
+ [I-D.thaler-behave-translator-addressing]
+
+ Embed And Zero-Pad, defined in section of 3.2.5 of
+ [I-D.thaler-behave-translator-addressing]
+
+ Preconfigured Mapping Table, defined in section of 3.2.6 of
+ [I-D.thaler-behave-translator-addressing]
+
+ The default algorithm used by DNS64 must be Embed and Zero-Pad.
+ While the normative description of the algorithms is provided in
+ [I-D.thaler-behave-translator-addressing], an sample description of
+ the algorithm and its application to different scenarios is provided
+ in Appendix A for illustration purposes.
+
+5.3. Handling other RRs
+
+5.3.1. PTR queries
+
+ If a DNS64 nameserver receives a PTR query for a record in the
+ IP6.ARPA domain, it MUST strip the IP6.ARPA labels from the QNAME,
+ reverse the address portion of the QNAME according to the encoding
+ scheme outlined in section 2.5 of [RFC3596] , and examine the
+ resulting address to see whether its prefix matches the locally-
+ configured Pref64::/n. There are two alternatives for a DNS64
+ nameserver to respond to such PTR queries. A DNS64 node MUST provide
+ one of these, and SHOULD NOT provide both at the same time unless
+ different IP6.ARPA zones require answers of different sorts.
+
+ The first option is for the DNS64 nameserver to respond
+ authoritatively for its prefixes. If the address prefix matches any
+ Pref64::/n used in the site, either a LIR prefix or a well-known
+ prefix used for NAT64 as defined in
+ [I-D.thaler-behave-translator-addressing], 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-
+
+
+
+Bagnulo, et al. Expires April 22, 2010 [Page 12]
+\f
+Internet-Draft DNS64 October 2009
+
+
+ provided) DNS64, and if this strategy is in effect, those queries
+ should never be sent to the global DNS. The advantage of this
+ strategy is that it makes plain to the querying client that the
+ prefix is one operated by the DNS64 site, and that the answers the
+ client is getting are generated by the DNS64. The disadvantage is
+ that any useful reverse-tree information that might be in the global
+ DNS is unavailable to the clients querying the DNS64.
+
+ The second option is for the DNS64 nameserver to synthesize a CNAME
+ mapping the IP6.ARPA namespace to the corresponding IN-ADDR.ARPA
+ name. The rest of the response would be the normal DNS processing.
+ The CNAME can be signed on the fly if need be. The advantage of this
+ approach is that any useful information in the reverse tree is
+ available to the querying client. The disadvantage is that it adds
+ additional load to the DNS64 (because CNAMEs have to be synthesized
+ for each PTR query that matches the Pref64::/n), and that it may
+ require signing on the fly. [[anchor15: what are we supposed to do
+ here when the in-addr.arpa zone is unmaintained, as it may be. If
+ there is no data at the target name, then we'll get a CNAME with a
+ map to an empty namespace, I think? Isn't that bad?
+ --ajs@shinkuro.com]]
+
+ If the address prefix does not match any of the Pref64::/n, then the
+ DNS64 server MUST process the query as though it were any other query
+ -- i.e. a recursive nameserver MUST attempt to resolve the query as
+ though it were any other (non-A/AAAA) query, and an authoritative
+ 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.
+
+ [[anchor16: We had some discussion, as an alternative to the above,
+ of allowing the DNS64 to truncate the additional section completely,
+ on the grounds that the additional section could break mixed-mode
+ iterative/forwarding resolvers that happen to end up behind DNS64.
+ Nobody else seemed to like that plan, so I haven't included it.
+ --ajs@shinkuro.com]]
+
+5.3.3. Other records
+
+ If the DNS64 is in recursive resolver mode, then it SHOULD also serve
+ the zones specified in [I-D.ietf-dnsop-default-local-zones], rather
+ than forwarding those queries elsewhere to be handled.
+
+
+
+
+Bagnulo, et al. Expires April 22, 2010 [Page 13]
+\f
+Internet-Draft DNS64 October 2009
+
+
+ All other RRs MUST be returned unchanged.
+
+5.4. Assembling a synthesized response to a AAAA query
+
+ The DNS64 uses different pieces of data to build the response
+ returned to the querying client.
+
+ The query that is used as the basis for synthesis results either in
+ an error, an answer that can be used as a basis for synthesis, or an
+ empty (authoritative) answer. If there is an empty answer, then the
+ DNS64 responds to the original querying client with the answer the
+ DNS64 received to the original AAAA query. Otherwise, the response
+ is assembled as follows.
+
+ The header fields are set according to the usual rules for recursive
+ or authoritative servers, depending on the role that the DNS64 is
+ serving. The question section is copied from the original AAAA
+ query. The answer section is populated according to the rules in
+ Section 5.1.4. The authority section is copied from the response to
+ the A query that the DNS64 performed. The additional section is
+ populated according to the rules in Section 5.3.2.
+
+ [[anchor18: The cross-reference to how to do the additional section
+ can be removed, and replaced by "copied from the response to the A
+ query that the DNS64 performed" if we don't want to allow the DNS64
+ to truncate the additional section. See the note above. If I hear
+ no more feedback on this topic, then I'll make this change in the
+ next version. --ajs@shinkuro.com]]
+
+5.5. DNSSEC processing: DNS64 in recursive server mode
+
+ We consider the case where the recursive server that is performing
+ DNS64 also has a local policy to validate the answers according to
+ the procedures outlined in [RFC4035] Section 5. We call this general
+ case vDNS64.
+
+ The vDNS64 uses the presence of the DO and CD bits to make some
+ decisions about what the query originator needs, and can react
+ accordingly:
+
+ 1. If CD is not set and DO is not set, vDNS64 SHOULD perform
+ validation and do synthesis as needed.
+
+ 2. If CD is not set and DO is set, then vDNS64 SHOULD perform
+ validation. Whenever vDNS64 performs validation, it MUST
+ validate the negative answer for AAAA queries before proceeding
+ to query for A records for the same name, in order to be sure
+ that there is not a legitimate AAAA record on the Internet.
+
+
+
+Bagnulo, et al. Expires April 22, 2010 [Page 14]
+\f
+Internet-Draft DNS64 October 2009
+
+
+ Failing to observe this step would allow an attacker to use DNS64
+ as a mechanism to circumvent DNSSEC. If the negative response
+ validates, and the response to the A query validates, then the
+ vDNS64 MAY perform synthesis and SHOULD set the AD bit in the
+ answer to the client. This is acceptable, because [RFC4035],
+ section 3.2.3 says that the AD bit is set by the name server side
+ of a security-aware recursive name server if and only if it
+ considers all the RRSets in the Answer and Authority sections to
+ be authentic. In this case, the name server has reason to
+ believe the RRSets are all authentic, so it SHOULD set the AD
+ bit. If the data does not validate, the vDNS64 MUST respond with
+ RCODE=2 (server failure).
+ A security-aware end point might take the presence of the AD bit
+ as an indication that the data is valid, and may pass the DNS
+ (and DNSSEC) data to an application. If the application attempts
+ to validate the synthesized data, of course, the validation will
+ fail. One could argue therefore that this approach is not
+ desirable. But security aware stub resolvers MUST NOT place any
+ reliance on data received from resolvers and validated on their
+ behalf without certain criteria established by [RFC4035], section
+ 4.9.3. An application that wants to perform validation on its
+ own should use the CD bit.
+
+ 3. If the CD bit is set and DO is set, then vDNS64 MAY perform
+ validation, but MUST NOT perform synthesis. It MUST hand the
+ data back to the query initiator, just like a regular recursive
+ resolver, and depend on the client to do the validation and the
+ synthesis itself.
+ The disadvantage to this approach is that an end point that is
+ translation-oblivious but security-aware and validating will not
+ be able to use the DNS64 functionality. In this case, the end
+ point will not have the desired benefit of NAT64. In effect,
+ this strategy means that any end point that wishes to do
+ validation in a NAT64 context must be upgraded to be translation-
+ aware as well.
+
+5.6. DNS64 and multihoming
+
+ Synthetic AAAA records may be constructed on the basis of the network
+ context in which they were constructed. Therefore, a synthetic AAAA
+ received from one interface MUST NOT be used to resolve hosts via
+ another network interface. [[anchor21: This seems to be the result of
+ the discussion on-list starting with message id 18034D4D7FE9AE48BF19A
+ B1B0EF2729F3EF0E69687@NOK-EUMSG-01.mgdnok.nokia.com, but it's pretty
+ strange when stated baldly. In particular, how is the multi-homed
+ host supposed to know that a given AAAA is synthetic?
+ --ajs@shinkuro.com]]
+
+
+
+
+Bagnulo, et al. Expires April 22, 2010 [Page 15]
+\f
+Internet-Draft DNS64 October 2009
+
+
+6. Deployment notes
+
+ While DNS64 is intended to be part of a strategy for aiding IPv6
+ deployment in an internetworking environment with some IPv4-only and
+ IPv6-only networks, it is important to realise that it is
+ incompatible with some things that may be deployed in an IPv4-only or
+ dual-stack context.
+
+6.1. DNS resolvers and DNS64
+
+ Full-service resolvers that are unaware of the DNS64 function can be
+ (mis)configured to act as mixed-mode iterative and forwarding
+ resolvers. In a native-IPv4 context, this sort of configuration may
+ appear to work. It is impossible to make it work properly without it
+ being aware of the DNS64 function, because it will likely at some
+ point obtain IPv4-only glue records and attempt to use them for
+ resolution. The result that is returned will contain only A records,
+ and without the ability to perform the DNS64 function the resolver
+ will simply be unable to answer the necessary AAAA queries.
+
+6.2. DNSSEC validators and DNS64
+
+ Existing DNSSEC validators (i.e. that are unaware of DNS64) will
+ reject all the data that comes from the DNS64 as having been tampered
+ with. If it is necessary to have validation behind the DNS64, then
+ the validator must know how to perform the DNS64 function itself.
+ Alternatively, the validating host may establish a trusted connection
+ with the DNS64, and allow the DNS64 to do all validation on its
+ behalf.
+
+
+7. Security Considerations
+
+ See the discussion on the usage of DNSSEC and DNS64 described in the
+ document.
+
+
+8. Contributors
+
+ Dave Thaler
+
+ Microsoft
+
+ dthaler@windows.microsoft.com
+
+
+
+
+
+
+
+Bagnulo, et al. Expires April 22, 2010 [Page 16]
+\f
+Internet-Draft DNS64 October 2009
+
+
+9. Acknowledgements
+
+ This draft contains the result of discussions involving many people,
+ including the participants of the IETF BEHAVE Working Group. The
+ following IETF participants made specific contributions to parts of
+ the text, and their help is gratefully acknowledged: Mark Andrews,
+ Jari Arkko, Rob Austein, Timothy Baldwin, Fred Baker, Marc Blanchet,
+ Cameron Byrne, Brian Carpenter, Hui Deng, Francis Dupont, Ed
+ Jankiewicz, Peter Koch, Suresh Krishnan, Ed Lewis, Xing Li, Matthijs
+ Mekking, Hiroshi Miyata, Simon Perrault, Teemu Savolainen, Jyrki
+ Soini, Dave Thaler, Mark Townsley, Stig Venaas, Magnus Westerlund,
+ Florian Weimer, Dan Wing, Xu Xiaohu.
+
+ Marcelo Bagnulo and Iljitsch van Beijnum are partly funded by
+ Trilogy, a research project supported by the European Commission
+ under its Seventh Framework Program.
+
+
+10. References
+
+10.1. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
+ STD 13, RFC 1034, November 1987.
+
+ [RFC1035] Mockapetris, P., "Domain names - implementation and
+ specification", STD 13, RFC 1035, November 1987.
+
+ [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)",
+ RFC 2671, August 1999.
+
+ [RFC2672] Crawford, M., "Non-Terminal DNS Name Redirection",
+ RFC 2672, August 1999.
+
+ [RFC2765] Nordmark, E., "Stateless IP/ICMP Translation Algorithm
+ (SIIT)", RFC 2765, February 2000.
+
+ [RFC4787] Audet, F. and C. Jennings, "Network Address Translation
+ (NAT) Behavioral Requirements for Unicast UDP", BCP 127,
+ RFC 4787, January 2007.
+
+ [I-D.ietf-behave-tcp]
+ Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P.
+ Srisuresh, "NAT Behavioral Requirements for TCP",
+ draft-ietf-behave-tcp-08 (work in progress),
+
+
+
+Bagnulo, et al. Expires April 22, 2010 [Page 17]
+\f
+Internet-Draft DNS64 October 2009
+
+
+ September 2008.
+
+ [I-D.ietf-behave-nat-icmp]
+ Srisuresh, P., Ford, B., Sivakumar, S., and S. Guha, "NAT
+ Behavioral Requirements for ICMP protocol",
+ draft-ietf-behave-nat-icmp-12 (work in progress),
+ January 2009.
+
+ [I-D.thaler-behave-translator-addressing]
+ Thaler, D., "IPv6 Addressing of IPv6/IPv4 Translators",
+ draft-thaler-behave-translator-addressing-00 (work in
+ progress), July 2009.
+
+10.2. Informative References
+
+ [I-D.bagnulo-behave-nat64]
+ Bagnulo, M., Matthews, P., and I. Beijnum, "NAT64: Network
+ Address and Protocol Translation from IPv6 Clients to IPv4
+ Servers", draft-bagnulo-behave-nat64-03 (work in
+ progress), March 2009.
+
+ [RFC2766] Tsirtsis, G. and P. Srisuresh, "Network Address
+ Translation - Protocol Translation (NAT-PT)", RFC 2766,
+ February 2000.
+
+ [RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound,
+ "Dynamic Updates in the Domain Name System (DNS UPDATE)",
+ RFC 2136, April 1997.
+
+ [RFC1858] Ziemba, G., Reed, D., and P. Traina, "Security
+ Considerations for IP Fragment Filtering", RFC 1858,
+ October 1995.
+
+ [RFC3128] Miller, I., "Protection Against a Variant of the Tiny
+ Fragment Attack (RFC 1858)", RFC 3128, June 2001.
+
+ [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network
+ Address Translator (Traditional NAT)", RFC 3022,
+ January 2001.
+
+ [RFC3484] Draves, R., "Default Address Selection for Internet
+ Protocol version 6 (IPv6)", RFC 3484, February 2003.
+
+ [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi,
+ "DNS Extensions to Support IP Version 6", RFC 3596,
+ October 2003.
+
+ [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
+
+
+
+Bagnulo, et al. Expires April 22, 2010 [Page 18]
+\f
+Internet-Draft DNS64 October 2009
+
+
+ Rose, "DNS Security Introduction and Requirements",
+ RFC 4033, March 2005.
+
+ [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
+ Rose, "Resource Records for the DNS Security Extensions",
+ RFC 4034, March 2005.
+
+ [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
+ Rose, "Protocol Modifications for the DNS Security
+ Extensions", RFC 4035, March 2005.
+
+ [RFC4966] Aoun, C. and E. Davies, "Reasons to Move the Network
+ Address Translator - Protocol Translator (NAT-PT) to
+ Historic Status", RFC 4966, July 2007.
+
+ [I-D.iana-rfc3330bis]
+ Cotton, M. and L. Vegoda, "Special Use IPv4 Addresses",
+ draft-iana-rfc3330bis-06 (work in progress),
+ February 2009.
+
+ [I-D.ietf-mmusic-ice]
+ Rosenberg, J., "Interactive Connectivity Establishment
+ (ICE): A Protocol for Network Address Translator (NAT)
+ Traversal for Offer/Answer Protocols",
+ draft-ietf-mmusic-ice-19 (work in progress), October 2007.
+
+ [I-D.ietf-6man-addr-select-sol]
+ Matsumoto, A., Fujisaki, T., Hiromi, R., and K. Kanayama,
+ "Solution approaches for address-selection problems",
+ draft-ietf-6man-addr-select-sol-01 (work in progress),
+ June 2008.
+
+ [RFC3498] Kuhfeld, J., Johnson, J., and M. Thatcher, "Definitions of
+ Managed Objects for Synchronous Optical Network (SONET)
+ Linear Automatic Protection Switching (APS)
+ Architectures", RFC 3498, March 2003.
+
+ [I-D.wing-behave-learn-prefix]
+ Wing, D., Wang, X., and X. Xu, "Learning the IPv6 Prefix
+ of an IPv6/IPv4 Translator",
+ draft-wing-behave-learn-prefix-02 (work in progress),
+ May 2009.
+
+ [I-D.miyata-behave-prefix64]
+ Miyata, H. and M. Bagnulo, "PREFIX64 Comparison",
+ draft-miyata-behave-prefix64-02 (work in progress),
+ March 2009.
+
+
+
+
+Bagnulo, et al. Expires April 22, 2010 [Page 19]
+\f
+Internet-Draft DNS64 October 2009
+
+
+ [I-D.venaas-behave-mcast46]
+ Venaas, S., "An IPv4 - IPv6 multicast translator",
+ draft-venaas-behave-mcast46-00 (work in progress),
+ December 2008.
+
+ [I-D.ietf-dnsop-default-local-zones]
+ Andrews, M., "Locally-served DNS Zones",
+ draft-ietf-dnsop-default-local-zones-08 (work in
+ progress), February 2009.
+
+
+Appendix A. Deployment scenarios and examples
+
+ In this section, we first provide a description of the default
+ address transformation algorithm and then we walk through some sample
+ scenarios that are expected to be common deployment cases. It should
+ be noted that is provided for illustrative purposes and this section
+ is not normative. The normative definition of DNS64 is provided in
+ Section 5 and the normative definition of the address transformation
+ algorithm is provided in [I-D.thaler-behave-translator-addressing].
+
+ There are two main different setups where DNS64 is expected to be
+ used (other setups are possible as well, but these two are the main
+ ones identified at the time of this writing).
+
+ One possible setup that is expected to be common is the case of an
+ end site or an ISP that is providing IPv6-only connectivity or
+ connectivity to IPv6-only hosts that wants to allow the
+ communication from these IPv6-only connected hosts to the IPv4
+ Internet. This case is called An-IPv6-network-to-IPv4-Internet.
+ In this case, the IPv6/IPv4 Translator is used to connect the end
+ site or the ISP to the IPv4 Internet and the DNS64 function is
+ provided by the end site or the ISP.
+
+ The other possible setup that is expected is an IPv4 site that
+ wants that its IPv4 servers to be reachable from the IPv6
+ Internet. This case is called IPv6-Internet-to-an-IPv4-network.
+ It should be noted that the IPv4 addresses used in the IPv4 site
+ can be either public or private. In this case, the IPv6/IPv4
+ Translator is used to connect the IPv4 end site to the IPv6
+ Internet and the DNS64 function is provided by the end site
+ itself.
+
+ In this section we illustrate how the DNS64 behaves in the different
+ scenarios that are expected to be common. We consider then 3
+ possible scenarios, namely:
+
+
+
+
+
+Bagnulo, et al. Expires April 22, 2010 [Page 20]
+\f
+Internet-Draft DNS64 October 2009
+
+
+ 1. An-IPv6-network-to-IPv4-Internet setup with DNS64 in DNS server
+ mode
+
+ 2. An-IPv6-network-to-IPv4-Internet setup with DNS64 in stub-
+ resolver mode
+
+ 3. IPv6-Internet-to-an-IPv4-network setup with DNS64 in DNS server
+ mode
+
+ The notation used is the following: upper case letters are IPv4
+ addresses; upper case letters with a prime(') are IPv6 addresses;
+ lower case letters are ports; prefixes are indicated by "P::X", which
+ is an IPv6 address built from an IPv4 address X by adding the prefix
+ P, mappings are indicated as "(X,x) <--> (Y',y)".
+
+A.1. Embed and Zero-Pad algorithm description
+
+ In this section we describe the default algorithm for the generation
+ of IPv6 address from IPv4 address to be implemented in the DNS64.
+
+ The only parameter required by the default algorithm is an IPv6
+ prefix. This prefix is used to map IPv4 addresses into IPv6
+ addresses, and is denoted Pref64. If we note n the length of the
+ prefix Pref64, then n must the less or equal than 96. If an Pref64
+ is configured through any means in the DNS64 (such as manually
+ configured, or other automatic mean not specified in this document),
+ the default algorithm must use this prefix. If no prefix is
+ available the algorithm must use the Well-Know prefix (include here
+ the prefix to be assigned by IANA) defined in
+ [I-D.thaler-behave-translator-addressing]
+
+ The input for the algorithm are:
+
+ The IPv4 address: X
+
+ The IPv6 prefix: Pref64::/n
+
+ The IPv6 address is generated by concatenating the prefix Pref64::/n,
+ the IPv4 address X and optionally (in case n is strictly smaller than
+ 96) an all-zero suffix. So, the resulting IPv6 address would be
+ Pref64:X::
+
+ Reverse algorithm
+
+ We next describe the reverse algorithm of the algorithm described in
+ the previous section. This algorithm allows to generate and IPv4
+ address from an IPv6 address. This reverse algorithm is NOT
+ implemented by the DNS64 but it is implemented in the IPv6/IPv4
+
+
+
+Bagnulo, et al. Expires April 22, 2010 [Page 21]
+\f
+Internet-Draft DNS64 October 2009
+
+
+ translator that is serving the same domain the DNS64.
+
+ The only parameter required by the default algorithm is an IPv6
+ prefix. This prefix is the one originally used to map IPv4 addresses
+ into IPv6 addresses, and is denoted Pref64.
+
+ The input for the algorithm are:
+
+ The IPv6 address: X'
+
+ The IPv6 prefix: Pref64::/n
+
+ First, the algorithm checks that the fist n bits of the IPv6 address
+ X' match with the prefix Pref64::/n i.e. verifies that Pref64::/n =
+ X'/n.
+
+ If this is not the case, the algorithm ends and no IPv4 address is
+ generated.
+
+ If the verification is successful, then the bits between the n+1
+ and the n+32 of the IPv6 address X' are extracted to form the IPv4
+ address.
+
+A.2. An-IPv6-network-to-IPv4-Internet setup with DNS64 in DNS server
+ mode
+
+ In this example, we consider an IPv6 node located in an IPv6-only
+ site that initiates a communication to an IPv4 node located in the
+ IPv4 Internet.
+
+ The scenario for this case is depicted in the following figure:
+
+
+ +---------------------------------------+ +-----------+
+ |IPv6 site +-------------+ |IP Addr: | |
+ | +----+ | Name server | +-------+ T | IPv4 |
+ | | H1 | | with DNS64 | |64Trans|------| Internet |
+ | +----+ +-------------+ +-------+ +-----------+
+ | |IP addr: Y' | | | |IP addr: X
+ | --------------------------------- | +----+
+ +---------------------------------------+ | H2 |
+ +----+
+
+ The figure shows an IPv6 node H1 which has an IPv6 address Y' and an
+ IPv4 node H2 with IPv4 address X.
+
+ A IPv6/IPv4 Translator connects the IPv6 network to the IPv4
+ Internet. This IPv6/IPv4 Translator has a prefix (called Pref64::/n)
+
+
+
+Bagnulo, et al. Expires April 22, 2010 [Page 22]
+\f
+Internet-Draft DNS64 October 2009
+
+
+ an IPv4 address T assigned to its IPv4 interface.
+
+ The other element involved is the local name server. The name server
+ is a dual-stack node, so that H1 can contact it via IPv6, while it
+ can contact IPv4-only name servers via IPv4.
+
+ The local name server needs to know the prefix assigned to the local
+ IPv6/IPv4 Translator (Pref64::/n). For the purpose of this example,
+ we assume it learns this through manual configuration.
+
+ For this example, assume the typical DNS situation where IPv6 hosts
+ have only stub resolvers, and always query a name server that
+ performs recursive lookups (henceforth called "the recursive
+ nameserver").
+
+ The steps by which H1 establishes communication with H2 are:
+
+ 1. H1 does a DNS lookup for FQDN(H2). H1 does this by sending a DNS
+ query for an AAAA record for H2 to the recursive name server.
+ The recursive name server implements DNS64 functionality.
+
+ 2. The recursive name server resolves the query, and discovers that
+ there are no AAAA records for H2.
+
+ 3. The recursive name server queries for an A record for H2 and gets
+ back an A record containing the IPv4 address X. The name server
+ then synthesizes an AAAA record. The IPv6 address in the AAAA
+ record contains the prefix assigned to the IPv6/IPv4 Translator
+ in the upper n bits then the IPv4 address X and then an all-zero
+ padding i.e. the resulting IPv6 address is Pref64:X::
+
+ 4. H1 receives the synthetic AAAA record and sends a packet towards
+ H2. The packet is sent from a source transport address of (Y',y)
+ to a destination transport address of (Pref64:X::,x), where y and
+ x are ports chosen by H2.
+
+ 5. The packet is routed to the IPv6 interface of the IPv6/IPv4
+ Translator and the subsequent communication flows by means of the
+ IPv6/IPv4 Translator mechanisms.
+
+A.3. An-IPv6-network-to-IPv4-Internet setup with DNS64 in stub-resolver
+ mode
+
+ The scenario for this case is depicted in the following figure:
+
+
+
+
+
+
+
+Bagnulo, et al. Expires April 22, 2010 [Page 23]
+\f
+Internet-Draft DNS64 October 2009
+
+
+ +---------------------------------------+ +-----------+
+ |IPv6 site +-------+ |IP addr: | |
+ | +---------------+ | Name | +-------+ T | IPv4 |
+ | | H1 with DNS64 | | Server| |64Trans|------| Internet |
+ | +---------------+ +-------+ +-------+ +-----------+
+ | |IP addr: Y' | | | |IP addr: X
+ | --------------------------------- | +----+
+ +---------------------------------------+ | H2 |
+ +----+
+
+ The figure shows an IPv6 node H1 which has an IPv6 address Y' and an
+ IPv4 node H2 with IPv4 address X. Node H1 is implementing the DNS64
+ function.
+
+ A IPv6/IPv4 Translator connects the IPv6 network to the IPv4
+ Internet. This IPv6/IPv4 Translator has a prefix (called Pref64::/n)
+ and an IPv4 address T assigned to its IPv4 interface.
+
+ H1 needs to know the prefix assigned to the local IPv6/IPv4
+ Translator (Pref64::/n). For the purpose of this example, we assume
+ it learns this through manual configuration.
+
+ Also shown is a name server. For the purpose of this example, we
+ assume that the name server is a dual-stack node, so that H1 can
+ contact it via IPv6, while it can contact IPv4-only name servers via
+ IPv4.
+
+ For this example, assume the typical situation where IPv6 hosts have
+ only stub resolvers and always query a name server that provides
+ recursive lookups (henceforth called "the recursive name server").
+ The recursive name server does not perform the DNS64 function.
+
+ The steps by which H1 establishes communication with H2 are:
+
+ 1. H1 does a DNS lookup for FQDN(H2). H1 does this by sending a DNS
+ query for a AAAA record for H2 to the recursive name server.
+
+ 2. The recursive DNS server resolves the query, and returns the
+ answer to H1. Because there are no AAAA records in the global
+ DNS for H2, the answer is empty.
+
+ 3. The stub resolver at H1 then queries for an A record for H2 and
+ gets back an A record containing the IPv4 address X. The DNS64
+ function within H1 then synthesizes a AAAA record. The IPv6
+ address in the AAAA record contains the prefix assigned to the
+ IPv6/IPv4 Translator in the upper n bits, then the IPv4 address X
+ and then an all-zero padding i.e. the resulting IPv6 address is
+ Pref64:X::.
+
+
+
+Bagnulo, et al. Expires April 22, 2010 [Page 24]
+\f
+Internet-Draft DNS64 October 2009
+
+
+ 4. H1 sends a packet towards H2. The packet is sent from a source
+ transport address of (Y',y) to a destination transport address of
+ (Pref64:X::,x), where y and x are ports chosen by H2.
+
+ 5. The packet is routed to the IPv6 interface of the IPv6/IPv4
+ Translator and the subsequent communication flows using the IPv6/
+ IPv4 Translator mechanisms.
+
+A.4. IPv6-Internet-to-an-IPv4-network setup DNS64 in DNS server mode
+
+ In this example, we consider an IPv6 node located in the IPv6
+ Internet site that initiates a communication to a IPv4 node located
+ in the IPv4 site.
+
+ This scenario can be addressed without using any form of DNS64
+ function. This is so because it is possible to assign a fixed IPv6
+ address to each of the IPv4 servers. Such an IPv6 address would be
+ constructed as the Pref64::/n concatenated with the IPv4 address of
+ the IPv4 server and an all-zero padding. Note that the IPv4 address
+ can be a public or a private address; the latter does not present any
+ additional difficulty, since the LIR prefix must be used a Pref64 (in
+ this scenario the usage of the WK prefix is not supported). Once
+ these IPv6 addresses have been assigned to represent the IPv4 servers
+ in the IPv6 Internet, real AAAA RRs containing these addresses can be
+ published in the DNS under the site's domain. This is the
+ recommended approach to handle this scenario, because it does not
+ involve synthesizing AAAA records at the time of query. Such a
+ configuration is easier to troubleshoot in the event of problems,
+ because it always provides the same answer to every query.
+
+ However, there are some more dynamic scenarios, where synthesizing
+ AAAA RRs in this setup may be needed. In particular, when DNS Update
+ [RFC2136] is used in the IPv4 site to update the A RRs for the IPv4
+ servers, there are two options: One option is to modify the server
+ that receives the dynamic DNS updates. That would normally be the
+ authoritative server for the zone. So the authoritative zone would
+ have normal AAAA RRs that are synthesized as dynamic updates occur.
+ The other option is modify the authoritative server to generate
+ synthetic AAAA records for a zone, possibly based on additional
+ constraints, upon the receipt of a DNS query for the AAAA RR. The
+ first option -- in which the AAAA is synthesized when the DNS update
+ message is received, and the data published in the relevant zone --
+ is recommended over the second option (i.e. the synthesis upon
+ receipt of the AAAA DNS query). This is because it is usually easier
+ to solve problems of misconfiguration and so on when the DNS
+ responses are not being generated dynamically. For completeness, the
+ DNS64 behavior that we describe in this section covers the case of
+ synthesizing the AAAA RR when the DNS query arrives. Nevertheless,
+
+
+
+Bagnulo, et al. Expires April 22, 2010 [Page 25]
+\f
+Internet-Draft DNS64 October 2009
+
+
+ such a configuration is NOT RECOMMENDED. Troubleshooting
+ configurations that change the data depending on the query they
+ receive is notoriously hard, and the IPv4/IPv6 translation scenario
+ is complicated enough without adding additional opportunities for
+ possible malfunction.
+
+ The scenario for this case is depicted in the following figure:
+
+
+ +-----------+ +----------------------------------------+
+ | | | IPv4 site +-------------+ |
+ | IPv6 | +-------+ +----+ | Name server | |
+ | Internet |------|64Trans| | H2 | | with DNS64 | |
+ +-----------+ +-------+ +----+ +-------------+ |
+ |IP addr: Y' | | |IP addr: X | |
+ +----+ | ----------------------------------- |
+ | H1 | +----------------------------------------+
+ +----+
+
+ The figure shows an IPv6 node H1 which has an IPv6 address Y' and an
+ IPv4 node H2 with IPv4 address X.
+
+ A IPv6/IPv4 Translator connects the IPv4 network to the IPv6
+ Internet. This IPv6/IPv4 Translator has a prefix (called
+ Pref64::/n).
+
+ Also shown is the authoritative name server for the local domain with
+ DNS64 functionality. For the purpose of this example, we assume that
+ the name server is a dual-stack node, so that H1 or a recursive
+ resolver acting on the request of H1 can contact it via IPv6, while
+ it can be contacted by IPv4-only nodes to receive dynamic DNS updates
+ via IPv4.
+
+ The local name server needs to know the prefix assigned to the local
+ IPv6/IPv4 Translator (Pref64::/n). For the purpose of this example,
+ we assume it learns this through manual configuration.
+
+ The steps by which H1 establishes communication with H2 are:
+
+ 1. H1 does a DNS lookup for FQDN(H2). H1 does this by sending a DNS
+ query for an AAAA record for H2. The query is eventually
+ forwarded to the server in the IPv4 site.
+
+ 2. The local DNS server resolves the query (locally), and discovers
+ that there are no AAAA records for H2.
+
+ 3. The name server verifies that FQDN(H2) and its A RR are among
+ those that the local policy defines as allowed to generate a AAAA
+
+
+
+Bagnulo, et al. Expires April 22, 2010 [Page 26]
+\f
+Internet-Draft DNS64 October 2009
+
+
+ RR from. If that is the case, the name server synthesizes an
+ AAAA record from the A RR and the relevant Pref64::/n. The IPv6
+ address in the AAAA record contains the prefix assigned to the
+ IPv6/IPv4 Translator in the first n bits and the IPv4 address X
+ and then an all-zero padding.
+
+ 4. H1 receives the synthetic AAAA record and sends a packet towards
+ H2. The packet is sent from a source transport address of (Y',y)
+ to a destination transport address of (Pref64:X::,x), where y and
+ x are ports chosen by H2.
+
+ 5. The packet is routed through the IPv6 Internet to the IPv6
+ interface of the IPv6/IPv4 Translator and the communication flows
+ using the IPv6/IPv4 Translator mechanisms.
+
+
+Appendix B. Motivations and Implications of synthesizing AAAA RR when
+ real AAAA RR exists
+
+ The motivation for synthesizing AAAA RR when a real AAAA RR exists is
+ to support the following scenario:
+
+ An IPv4-only server application (e.g. web server software) is
+ running on a dual-stack host. There may also be dual-stack server
+ applications also running on the same host. That host has fully
+ routable IPv4 and IPv6 addresses and hence the authoritative DNS
+ server has an A and a AAAA record as a result.
+
+ An IPv6-only client (regardless of whether the client application
+ is IPv6-only, the client stack is IPv6-only, or it only has an
+ IPv6 address) wants to access the above server.
+
+ The client issues a DNS query to a DNS64 recursor.
+
+ If the DNS64 only generates a synthetic AAAA if there's no real AAAA,
+ then the communication will fail. Even though there's a real AAAA,
+ the only way for communication to succeed is with the translated
+ address. So, in order to support this scenario, the administrator of
+ a DNS64 service may want to enable the synthesis of AAAA RR even when
+ real AAAA RR exist.
+
+ The implication of including synthetic AAAA RR when real AAAA RR
+ exist is that translated connectivity may be preferred over native
+ connectivity in some cases where the DNS64 is operated in DNS server
+ mode.
+
+ RFC3484 [RFC3484] rules use longest prefix match to select which is
+ the preferred destination address to use. So, if the DNS64 recursor
+
+
+
+Bagnulo, et al. Expires April 22, 2010 [Page 27]
+\f
+Internet-Draft DNS64 October 2009
+
+
+ returns both the synthetic AAAA RR and the real AAAA RR, then if the
+ DNS64 is operated by the same domain as the initiating host, and a
+ global unicast prefix (called the LIR prefix as defined in
+ [I-D.thaler-behave-translator-addressing]) is used, then the
+ synthetic AAAA RR is likely to be preferred.
+
+ This means that without further configuration:
+
+ In the case of An IPv6 network to the IPv4 internet, the host will
+ prefer translated connectivity if LIR prefix is used. If the
+ Well-Known (WK) prefix defined in
+ [I-D.thaler-behave-translator-addressing] is used, it will
+ probably prefer native connectivity.
+
+ In the case of the IPv6 Internet to an IPv4 network, it is
+ possible to bias the selection towards the real AAAA RR if the
+ DNS64 recursor returns the real AAAA first in the DNS reply, when
+ the LIR prefix is used (the WK prefix usage is not recommended in
+ this case)
+
+ In the case of the IPv6 to IPv4 in the same network, for local
+ destinations (i.e., target hosts inside the local site), it is
+ likely that the LIR prefix and the destination prefix are the
+ same, so we can use the order of RR in the DNS reply to bias the
+ selection through native connectivity. If a WK prefix is used,
+ the longest prefix match rule will select native connectivity.
+
+ So this option introduces problems in the following cases:
+
+ An IPv6 network to the IPv4 internet with the LIR prefix
+
+ IPv6 to IPv4 in the same network when reaching external
+ destinations and the LIR prefix is used.
+
+ In any case, the problem can be solved by properly configuring the
+ RFC3484 [RFC3484] policy table, but this requires effort on the part
+ of the site operator.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bagnulo, et al. Expires April 22, 2010 [Page 28]
+\f
+Internet-Draft DNS64 October 2009
+
+
+Authors' Addresses
+
+ Marcelo Bagnulo
+ UC3M
+ Av. Universidad 30
+ Leganes, Madrid 28911
+ Spain
+
+ Phone: +34-91-6249500
+ Fax:
+ Email: marcelo@it.uc3m.es
+ URI: http://www.it.uc3m.es/marcelo
+
+
+ Andrew Sullivan
+ Shinkuro
+ 4922 Fairmont Avenue, Suite 250
+ Bethesda, MD 20814
+ USA
+
+ Phone: +1 301 961 3131
+ Email: ajs@shinkuro.com
+
+
+ Philip Matthews
+ Unaffiliated
+ 600 March Road
+ Ottawa, Ontario
+ Canada
+
+ Phone: +1 613-592-4343 x224
+ Fax:
+ Email: philip_matthews@magma.ca
+ URI:
+
+
+ Iljitsch van Beijnum
+ IMDEA Networks
+ Av. Universidad 30
+ Leganes, Madrid 28911
+ Spain
+
+ Phone: +34-91-6246245
+ Email: iljitsch@muada.com
+
+
+
+
+
+
+
+Bagnulo, et al. Expires April 22, 2010 [Page 29]
+\f
projects / thirdparty / bind9.git / commitdiff
