From: Mark Andrews Date: Mon, 15 Feb 2010 22:48:28 +0000 (+0000) Subject: new draft X-Git-Tag: v9.6.2~5^2 X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=79464adea15c36db9c4ca7c4e4eebbd4c1768c2a;p=thirdparty%2Fbind9.git new draft --- diff --git a/doc/draft/draft-ietf-behave-dns64-01.txt b/doc/draft/draft-ietf-behave-dns64-01.txt deleted file mode 100644 index 25a6dd4d072..00000000000 --- a/doc/draft/draft-ietf-behave-dns64-01.txt +++ /dev/null @@ -1,1624 +0,0 @@ - - - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - diff --git a/doc/draft/draft-ietf-behave-dns64-06.txt b/doc/draft/draft-ietf-behave-dns64-06.txt new file mode 100644 index 00000000000..f648a21029a --- /dev/null +++ b/doc/draft/draft-ietf-behave-dns64-06.txt @@ -0,0 +1,1680 @@ + + + +BEHAVE WG M. Bagnulo +Internet-Draft UC3M +Intended status: Standards Track A. Sullivan +Expires: August 19, 2010 Shinkuro + P. Matthews + Alcatel-Lucent + I. van Beijnum + IMDEA Networks + February 15, 2010 + + +DNS64: DNS extensions for Network Address Translation from IPv6 Clients + to IPv4 Servers + draft-ietf-behave-dns64-06 + +Abstract + + DNS64 is a mechanism for synthesizing AAAA records from A records. + DNS64 is used with an IPv6/IPv4 translator to enable client-server + communication between an IPv6-only client and an IPv4-only server, + without requiring any changes to either the IPv6 or the IPv4 node, + for the class of applications that work through NATs. This document + specifies DNS64, and provides suggestions on how it should be + deployed in conjunction with IPv6/IPv4 translators. + +Status of this Memo + + This Internet-Draft is submitted to IETF in full conformance with the + provisions of BCP 78 and BCP 79. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that + other groups may also distribute working documents as Internet- + Drafts. + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as "work in progress." + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt. + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + + This Internet-Draft will expire on August 19, 2010. + + + + +Bagnulo, et al. Expires August 19, 2010 [Page 1] + +Internet-Draft DNS64 February 2010 + + +Copyright Notice + + Copyright (c) 2010 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the BSD License. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Bagnulo, et al. Expires August 19, 2010 [Page 2] + +Internet-Draft DNS64 February 2010 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 3. Background to DNS64-DNSSEC interaction . . . . . . . . . . . . 7 + 4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 8 + 5. DNS64 Normative Specification . . . . . . . . . . . . . . . . 9 + 5.1. Resolving AAAA queries and the answer section . . . . . . 10 + 5.1.1. The answer when there is AAAA data available . . . . . 10 + 5.1.2. The answer when there is an error . . . . . . . . . . 10 + 5.1.3. Special exclusion set for AAAA records . . . . . . . . 10 + 5.1.4. Dealing with CNAME and DNAME . . . . . . . . . . . . . 11 + 5.1.5. Data for the answer when performing synthesis . . . . 11 + 5.1.6. Performing the synthesis . . . . . . . . . . . . . . . 12 + 5.1.7. Querying in parallel . . . . . . . . . . . . . . . . . 12 + 5.2. Generation of the IPv6 representations of IPv4 + addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 + 5.3. Handling other RRs and the Additional Section . . . . . . 13 + 5.3.1. PTR queries . . . . . . . . . . . . . . . . . . . . . 13 + 5.3.2. Handling the additional section . . . . . . . . . . . 14 + 5.3.3. Other records . . . . . . . . . . . . . . . . . . . . 15 + 5.4. Assembling a synthesized response to a AAAA query . . . . 15 + 5.5. DNSSEC processing: DNS64 in recursive server mode . . . . 16 + 6. Deployment notes . . . . . . . . . . . . . . . . . . . . . . . 17 + 6.1. DNS resolvers and DNS64 . . . . . . . . . . . . . . . . . 17 + 6.2. DNSSEC validators and DNS64 . . . . . . . . . . . . . . . 17 + 6.3. DNS64 and multihomed and dual-stack hosts . . . . . . . . 17 + 6.3.1. IPv6 multihomed hosts . . . . . . . . . . . . . . . . 17 + 6.3.2. Accidental dual-stack DNS64 use . . . . . . . . . . . 18 + 6.3.3. Intentional dual-stack DNS64 use . . . . . . . . . . . 18 + 7. Deployment scenarios and examples . . . . . . . . . . . . . . 19 + 7.1. Example of An-IPv6-network-to-IPv4-Internet setup with + DNS64 in DNS server mode . . . . . . . . . . . . . . . . . 20 + 7.2. An example of an-IPv6-network-to-IPv4-Internet setup + with DNS64 in stub-resolver mode . . . . . . . . . . . . . 21 + 7.3. Example of IPv6-Internet-to-an-IPv4-network setup + DNS64 in DNS server mode . . . . . . . . . . . . . . . . . 23 + 8. Security Considerations . . . . . . . . . . . . . . . . . . . 25 + 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 + 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 25 + 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25 + 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 + 12.1. Normative References . . . . . . . . . . . . . . . . . . . 26 + 12.2. Informative References . . . . . . . . . . . . . . . . . . 26 + Appendix A. Motivations and Implications of synthesizing AAAA + RR when real AAAA RR exists . . . . . . . . . . . . . 28 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29 + + + + +Bagnulo, et al. Expires August 19, 2010 [Page 3] + +Internet-Draft DNS64 February 2010 + + +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 stateful NAT64 + [I-D.ietf-behave-v6v4-xlate-stateful], allows an IPv6-only client to + initiate communications by name to an IPv4-only server. + + DNS64 is a mechanism for synthesizing AAAA resource records (RRs) + from A RRs. A synthetic AAAA RR created by the DNS64 from an + original A RR contains the same 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 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 in the end- + hosts themselves. + + +2. Overview + + This section provides a non-normative 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, hosts that can only use IPv6, as well as cases where + only IPv6 connectivity is available to the client. By IPv4-only + servers we mean servers running IPv4-only applications, servers that + can only use IPv4, as well as cases where only IPv4 connectivity is + + + +Bagnulo, et al. Expires August 19, 2010 [Page 4] + +Internet-Draft DNS64 February 2010 + + + 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 address 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 + that IPv6 packets addressed to an IPv6 destination address that + contains the Pref64::/n be delivered to an IPv6/IPv4 translator, so + they can be translated into IPv4 packets. + + 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 + + + +Bagnulo, et al. Expires August 19, 2010 [Page 5] + +Internet-Draft DNS64 February 2010 + + + 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 [I-D.ietf-behave-address-format]. There are two types + of prefixes that can be used as Pref64::/n. + + The Pref64::/n can be the Well-Known Prefix 64:FF9B::/96 reserved + by [I-D.ietf-behave-address-format] for the purpose of + representing IPv4 addresses in IPv6 address space. + + The Pref64::/n can be a Network-Specific Prefix (NSP). An NSP is + an IPv6 prefix assigned by an organization 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 first option is to locate the DNS64 function in authoritative + servers for a zone. In this case, the authoritative server provides + a synthetic AAAA RRs for an IPv4-only host in its zone. This is one + type of DNS64 server. + + Another option is to locate the DNS64 function in recursive name + servers serving end hosts. In this case, when an IPv6-only host + queries the name server for AAAA RRs for an IPv4-only host, the name + server can perform the synthesis of AAAA RRs and pass them back to + the IPv6-only initiator. The main advantage of this mode is that + current IPv6 nodes can use this mechanism without requiring any + modification. This mode is called "DNS64 in DNS recursive mode". + This is a second type of DNS64 server, and it is also one type of + DNS64 resolver. + + The last option is to place the DNS64 function in the end hosts, + coupled to the local (stub) resolver. In this case, the stub + resolver will try to obtain (real) AAAA RRs and in case they are not + available, the DNS64 function will synthesize AAAA RRs for internal + usage. This mode is compatible with some advanced functions like + DNSSEC validation in the end host. The main drawback of this mode is + its deployability, since it requires changes in the end hosts. This + + + +Bagnulo, et al. Expires August 19, 2010 [Page 6] + +Internet-Draft DNS64 February 2010 + + + mode is called "DNS64 in stub-resolver mode". This is the second + type of DNS64 resolver. + + +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 "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. + + 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. + + 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], + + + +Bagnulo, et al. Expires August 19, 2010 [Page 7] + +Internet-Draft DNS64 February 2010 + + + 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 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 (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 node receives a query with + the DO bit set and CD clear. This ought to work like the + previous case, except that the resolver should also set the + "Authentic Data" (AD) bit on the response. + + 7. A security-aware and validating DNS64 node receives a query with + the DO bit set and CD set. This is effectively the same as the + case where a security-aware and non-validating recursive resolver + receives a similar query, and the same thing will happen: the + downstream validator will mark the data as invalid if DNS64 has + performed synthesis. + + +4. Terminology + + This section provides definitions for the special terms used in the + document. + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in RFC 2119 [RFC2119]. + + Authoritative server: A DNS server that can answer authoritatively a + given DNS question. + + + + + + + +Bagnulo, et al. Expires August 19, 2010 [Page 8] + +Internet-Draft DNS64 February 2010 + + + 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 recursor: A recursive resolver that provides the DNS64 + functionality as part of its operation. This is the same thing as + "DNS64 in recursive resolver mode". + + DNS64 resolver: Any resolver (stub resolver or recursive resolver) + that provides the DNS64 function. + + DNS64 server: Any server providing the DNS64 function. + + 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. + + 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. + + IPv6/IPv4 translator: A device that translates IPv6 packets to IPv4 + packets and vice-versa. It is only required that the + communication initiated from the IPv6 side be supported. + + For a detailed understanding of this document, the reader should also + be familiar with DNS terminology from [RFC1034], [RFC1035] and + current NAT terminology from [RFC4787]. Some parts of this document + assume familiarity with the terminology of the DNS security + extensions outlined in [RFC4035]. + + +5. DNS64 Normative Specification + + 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 separate IPv4 address + ranges to separate IPv6 prefixes for AAAA record synthesis. This + allows handling of special use IPv4 addresses [RFC5735]. Support of + multicast address handling is out of the scope of this document. A + possible approach is specified in [I-D.venaas-behave-mcast46]. + + DNS64 also responds to PTR queries involving addresses containing any + of the IPv6 prefixes it uses for synthesis of AAAA RRs. + + + + +Bagnulo, et al. Expires August 19, 2010 [Page 9] + +Internet-Draft DNS64 February 2010 + + +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. 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, considered in + Section 5.1.3. If there is (non-excluded) AAAA data available, DNS64 + SHOULD NOT include synthetic AAAA RRs in the response (see Appendix 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 RCODE other than 0 (No error + condition), then there are two possibilities. A result with RCODE=3 + (Name Error) is handled according to normal DNS operation (which is + normally to return the error to the client). This stage is still + prior to any synthesis having happened, so a response to be returned + to the client does not need any special assembly than would usually + happen in DNS operation. + + Any other RCODE is treated as though the RCODE were 0 and the answer + section were empty. This is because of the large number of different + responses from deployed name servers when they receive AAAA queries + without a AAAA record being available. + + 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. + +5.1.3. Special exclusion set for AAAA records + + Some IPv6 addresses are not actually usable by IPv6-only hosts. If + they are returned to IPv6-only querying agents as AAAA records, + therefore, the goal of decreasing the number of failure modes will + + + +Bagnulo, et al. Expires August 19, 2010 [Page 10] + +Internet-Draft DNS64 February 2010 + + + not be attained. Examples include AAAA records with addresses in the + ::ffff:0:0/96 network, and possibly (depending on the context) AAAA + records with the site's Pref::64/n or the Well-Known Prefix (see + below for more about the Well-Known Prefix). A DNS64 implementation + SHOULD provide a mechanism to specify IPv6 prefix ranges to be + treated as though the AAAA containing them were an empty answer. An + implementation SHOULD include the ::ffff/96 network in that range by + default. Failure to provide this facility will mean that clients + querying the DNS64 function may not be able to communicate with hosts + that would be reachable from a dual-stack host. + + When the DNS64 performs its initial AAAA query, if it receives an + answer with only AAAA records containing addresses in the excluded + range(s), then it MUST treat the answer as though it were an empty + answer, and proceed accordingly. If it receives an answer with at + least one AAAA record containing an address outside any of the + excluded range(s), then it MAY build an answer section for a response + including only the AAAA record(s) that do not contain any of the + addresses inside the excluded ranges. That answer section is used in + the assembly of a response as detailed in Section 5.4. + Alternatively, it MAY treat the answer as though it were an empty + answer, and proceed accordingly. It MUST NOT return the offending + AAAA records as part of a response. + +5.1.4. Dealing with CNAME and DNAME + + If the response contains a CNAME or a DNAME, then the CNAME or DNAME + chain is followed until the first terminating A or AAAA record is + reached. This may require the DNS64 to ask for an A record, in case + the response to the original AAAA query is a CNAME or DNAME without 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, the original CNAME or DNAME RR is + included as part of the answer, and the synthetic AAAA, if + appropriate, is included. + +5.1.5. Data for the answer when performing synthesis + + If the query results in no error but an empty answer section in the + response, the DNS64 attempts to retrieve A records for the name in + question, either by performing another query or, in the case of an + authortiative server, by examining its own results. If this new A RR + query results in an empty answer or in an error, then the empty + result or error is used as the basis for the answer returned to the + querying client. (Transient errors may result in retrying the query, + depending on the mode and operation of the underlying resolver; this + is just as in Section 5.1.2.) If instead the query results in one or + + + +Bagnulo, et al. Expires August 19, 2010 [Page 11] + +Internet-Draft DNS64 February 2010 + + + more A RRs, the DNS64 synthesizes AAAA RRs based on the A RRs + according to the procedure outlined in Section 5.1.6. The DNS64 + returns the synthesized AAAA records in the answer section, removing + the A records that form the basis of the synthesis. + +5.1.6. Performing the synthesis + + A synthetic AAAA record is created from an A record as follows: + + o The NAME field is set to the NAME field from the A record + + o The TYPE field is set to 28 (AAAA) + + o The CLASS field is set to the original CLASS field, 1. Under this + specification, DNS64 for any CLASS other than 1 is undefined. + + 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 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. + +5.1.7. 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. However, this would result + in performing unnecessary A RR queries in the case where no AAAA RR + synthesis is required. A possible trade-off would be to perform them + sequentially but with a very short interval between them, so if we + obtain a fast reply, we avoid doing the additional query. (Note that + this discussion is relevant only if the DNS64 function needs to + perform external queries to fetch the RR. If the needed RR + information is available locally, as in the case of an authoritative + server, the issue is no longer relevant.) + +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 + + + +Bagnulo, et al. Expires August 19, 2010 [Page 12] + +Internet-Draft DNS64 February 2010 + + + generation algorithms are the following: + + The same algorithm to create an IPv6 address from an IPv4 address + MUST be used by both a DNS64 to create the IPv6 address to be + returned in the synthetic AAAA RR from the IPv4 address contained + in an original A RR, and by a IPv6/IPv4 translator to create the + IPv6 address to be included in the source address field of the + outgoing IPv6 packets from the IPv4 address included in the source + address field of the incoming IPv4 packet. + + The algorithm MUST be reversible; i.e., it MUST be possible to + derive 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 and in the NAT64 (such as fixed string to + be used as a suffix). + + For each prefix Pref64::/n, n MUST the less than or equal to + 96. If one or more Pref64::/n are configured in the DNS64 + through any means in the DNS64 (such as manually configured, or + other automatic means not specified in this document), the + default algorithm MUST use these prefixes (and not use the + Well-Know Prefix). If no prefix is available, the algorithm + MUST use the Well-Known prefix 64:FF9B::/96 defined in + [I-D.ietf-behave-address-format] to represent the IPv4 unicast + address range + + [[anchor9: Note in document: The value 64:FF9B::/96 is proposed as + the value for the Well-Known prefix and needs to be confirmed + whenis published as RFC.]][I-D.ietf-behave-address-format] + + A DNS64 MUST support the algorithm for generating IPv6 + representations of IPv4 addresses defined in Section 2 of + [I-D.ietf-behave-address-format]. Moreover, the aforementioned + algorithm MUST be the default algorithm used by the DNS64. While the + normative description of the algorithm is provided in + [I-D.ietf-behave-address-format], a sample description of the + algorithm and its application to different scenarios is provided in + Section 7 for illustration purposes. + +5.3. Handling other RRs and the Additional Section + +5.3.1. PTR queries + + 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 + + + +Bagnulo, et al. Expires August 19, 2010 [Page 13] + +Internet-Draft DNS64 February 2010 + + + 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. 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. + + 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. + + The second option is for the DNS64 nameserver to synthesize a CNAME + mapping the IP6.ARPA namespace to the corresponding IN-ADDR.ARPA + name. The rest of the response would be the normal DNS processing. + The CNAME can be signed on the fly if need be. The advantage of this + approach is that any useful information in the reverse tree is + available to the querying client. The disadvantage is that it adds + additional load to the DNS64 (because CNAMEs have to be synthesized + for each PTR query that matches the Pref64::/n), and that it may + require signing on the fly. In addition, the generated CNAME could + correspond to an unpopulated in-addr.arpa zone, so the CNAME would + provide a reference to a non-existent record. + + If the address prefix does not match any 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. + + + +Bagnulo, et al. Expires August 19, 2010 [Page 14] + +Internet-Draft DNS64 February 2010 + + + 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 nameserver that is unaware of the + NAT64 in question. The result in this case will be resolution + failure anyway, only later in the resolution operation. + +5.3.3. Other records + + If the DNS64 is in recursive resolver mode, then considerations + outlined in [I-D.ietf-dnsop-default-local-zones] may be relevant. + + All other RRs MUST be returned unchanged. + +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 AAAA query. Otherwise, the response + is assembled as follows. + + The header fields are set according to the usual rules for recursive + or authoritative servers, depending on the role that the DNS64 is + serving. The question section is copied from the original AAAA + query. The answer section is populated according to the rules in + Section 5.1.6. The authority and additional sections are copied from + the response to the A query that the DNS64 performed. + + + + + + + +Bagnulo, et al. Expires August 19, 2010 [Page 15] + +Internet-Draft DNS64 February 2010 + + +5.5. DNSSEC processing: DNS64 in recursive server mode + + We consider the case where a recursive server that is performing + DNS64 also has a local policy to validate the answers according to + the procedures outlined in [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. + 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 + + + +Bagnulo, et al. Expires August 19, 2010 [Page 16] + +Internet-Draft DNS64 February 2010 + + + 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. + + +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 be unable to answer the necessary AAAA queries. + +6.2. DNSSEC validators and DNS64 + + Existing DNSSEC validators (i.e. that are unaware of DNS64) might + reject all the data that comes from DNS64 as having been tampered + with (even if it did not set CD when querying). If it is necessary + to have validation behind the DNS64, then the validator must know how + to perform the DNS64 function itself. Alternatively, the validating + host may establish a trusted connection with a DNS64, and allow the + DNS64 recursor to do all validation on its behalf. + +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 + + + +Bagnulo, et al. Expires August 19, 2010 [Page 17] + +Internet-Draft DNS64 February 2010 + + + has native IPv6 connectivity only. I1 might receive a AAAA answer + from a DNS64 that is configured for a particular NAT64; the IPv6 + address contained in that AAAA answer will not connect with anything + via i2. + + This example illustrates why it is generally preferable that hosts + treat DNS answers from one interface as local to that interface. The + answer received on one interface will not work on the other + interface. Hosts that attempt to use DNS answers globally may + encounter surprising failures in these cases. For more discussion of + this topic, see [I-D.savolainen-mif-dns-server-selection]. + + Note that the issue is not that there are two interfaces, but that + there are two networks involved. The same results could be achieved + with a single interface routed to two different networks. + +6.3.2. Accidental dual-stack DNS64 use + + Similarly, suppose that i1 has IPv6 connectivity and can connect to + the IPv4 Internet through NAT64, but i2 has native IPv4 connectivity. + In this case, i1 could receive an IPv6 address from a synthetic AAAA + that would better be reached via native IPv4. Again, it is worth + emphasising that this arises because there are two networks involved. + + Since it is most likely that the host will attempt AAAA resolution + first, in this arrangement the host will often use the NAT64 when + native IPv4 would be preferable. For this reason, hosts with IPv4 + connectivity to the Internet should avoid using DNS64. This can be + partly resolved by ISPs when providing DNS resolvers to clients, but + that is not a guarantee that the NAT64 will never be used when a + native IPv4 connection should be used. There is no general-purpose + mechanism to ensure that native IPv4 transit will always be + preferred, because to a DNS64-oblivious host, the DNS64 looks just + like an ordinary DNS server. Operators of a NAT64 should expect + traffic to pass through the NAT64 even when it is not necessary. + +6.3.3. Intentional dual-stack DNS64 use + + Finally, consider the case where the IPv4 connectivity on i2 is only + to a LAN, with an IPv6-only connection on i1 to the Internet, + connecting to the IPv4 Internet via NAT64. Traffic to the LAN may + not be routable from the global Internet, as is often the case (for + instance) with LANs using RFC1918 addresses. In this case, it is + critical that the DNS64 not synthesize AAAA responses for hosts in + the LAN, or else that the DNS64 be aware of hosts in the LAN and + provide context-sensitive answers ("split view" DNS answers) for + hosts inside the LAN. As with any split view DNS arrangement, + operators must be prepared for data to leak from one context to + + + +Bagnulo, et al. Expires August 19, 2010 [Page 18] + +Internet-Draft DNS64 February 2010 + + + another, and for failures to occur because nodes accessible from one + context are not accessible from the other. + + It is important for deployers of DNS64 to realise that, in some + circumstances, making the DNS64 available to a dual-stack host will + cause the host to prefer to send packets via NAT64 instead of via + native IPv4, with the associated loss of performance or functionality + (or both) entailed by the NAT. At the same time, some hosts are not + able to learn about DNS servers provisioned on IPv6 addresses, or + simply cannot send DNS packets over IPv6. + + +7. Deployment scenarios and examples + + In this section, we walk through some sample scenarios that are + expected to be common deployment cases. It should be noted that this + is provided for illustrative purposes and this section is not + normative. The normative definition of DNS64 is provided in + Section 5 and the normative definition of the address transformation + algorithm is provided in [I-D.ietf-behave-address-format]. + + There are two main different setups where DNS64 is expected to be + used (other setups are possible as well, but these two are the main + ones identified at the time of this writing). + + One possible setup that is expected to be common is the case of an + end site or an ISP that is providing IPv6-only connectivity or + connectivity to IPv6-only hosts that wants to allow the + communication from these IPv6-only connected hosts to the IPv4 + Internet. This case is called An-IPv6-network-to-IPv4-Internet + [I-D.ietf-behave-v6v4-framework]. In this case, the IPv6/IPv4 + Translator is used to connect the end site or the ISP to the IPv4 + Internet and the DNS64 function is provided by the end site or the + ISP. + + 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 + [I-D.ietf-behave-v6v4-framework]. It should be noted that the + IPv4 addresses used in the IPv4 site can be either public or + private. In this case, the IPv6/IPv4 translator is used to + connect the IPv4 end site to the IPv6 Internet and the DNS64 + function is provided by the IPv4 end site itself. + + 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 August 19, 2010 [Page 19] + +Internet-Draft DNS64 February 2010 + + + 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 + +7.1. Example of 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 network | | IPv4 | + | | +-------------+ | Network | + | |--| Name server |--| | + | | | with DNS64 | | +----+ | + | +----+ | +-------------+ | | H2 | | + | | H1 |---| | | +----+ | + | +----+ | +-------+ | 192.0.2.1 | + | |------| NAT64 |----| | + | | +-------+ | | + | | | | | + +---------------------+ +---------------+ + + The figure shows an IPv6 node H1 and an IPv4 node H2 with IPv4 + address 192.0.2.1 and FQDN h2.example.com + + A IPv6/IPv4 Translator connects the IPv6 network to the IPv4 + Internet. This IPv6/IPv4 Translator has an IPv4 address 203.0.113.1 + assigned to its IPv4 interface and it is using the WKP 64:FF9B::/96 + to create IPv6 representations of IPv4 addresses, as defined in + [I-D.ietf-behave-address-format]. + + 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 is configured to represent the whole IPv4 + unicast space with using the WKP 64:FF9B::/96. For the purpose of + this example, we assume it learns this through manual configuration. + + + +Bagnulo, et al. Expires August 19, 2010 [Page 20] + +Internet-Draft DNS64 February 2010 + + + For this example, assume the typical DNS situation where IPv6 hosts + have only stub resolvers, and they are configured with the IP address + of a name server that they always have to query and that performs + recursive lookups (henceforth called "the recursive nameserver"). + + 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 queries for A records for H2 and gets + back a single A records containing the IPv4 address 192.0.2.1. + The name server then synthesizes a AAAA records. The IPv6 + address in the AAAA record contains the prefix assigned to the + IPv6/IPv4 Translator in the upper 96 bits then the received IPv4 + address i.e. the resulting IPv6 address is 64:FF9B::192.0.2.1 + + 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. An example of an-IPv6-network-to-IPv4-Internet setup with DNS64 in + stub-resolver mode + + This case is depicted in the following figure: + + + + + + + + + + + + + + + + + +Bagnulo, et al. Expires August 19, 2010 [Page 21] + +Internet-Draft DNS64 February 2010 + + + +---------------------+ +---------------+ + |IPv6 network | | IPv4 | + | | +--------+ | Network | + | |-----| Name |----| | + | +-----+ | | server | | +----+ | + | | H1 | | +--------+ | | H2 | | + | |with |---| | | +----+ | + | |DNS64| | +-------+ | 192.0.2.1 | + | +----+ |------| NAT64 |----| | + | | +-------+ | | + | | | | | + +---------------------+ +---------------+ + + + The figure shows an IPv6 node H1 implementing the DNS64 function and + an IPv4 node H2 with IPv4 address 192.0.2.1 and FQDN h2.example.com + + A IPv6/IPv4 Translator connects the IPv6 network to the IPv4 + Internet. This IPv6/IPv4 Translator is using the WKP 64:FF9B::/96 + and an IPv4 address T 203.0.113.1 assigned to its IPv4 interface. + + H1 needs to know the prefix assigned to the local IPv6/IPv4 + Translator (64:FF9B::/96). For the purpose of this example, we + assume it learns this through manual configuration. + + 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 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 + + + +Bagnulo, et al. Expires August 19, 2010 [Page 22] + +Internet-Draft DNS64 February 2010 + + + IPv6 address in the AAAA record contains the prefix assigned to + the IPv6/IPv4 translator in the upper 96 bits, then the received + IPv4 address i.e. the resulting IPv6 address is 64:FF9B:: + 192.0.2.1. + + 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 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 that initiates a communication to an IPv4 node located in + the IPv4 site. + + In some cases, this scenario can be addressed without using any form + of DNS64 function. This is so because in principle it is possible to + assign a fixed IPv6 address to each of the IPv4 nodes. Such an IPv6 + address would be constructed using the address transformation + algorithm defined in [I-D.ietf-behave-address-format] that takes as + input the Pref64::/96 and the IPv4 address of the IPv4 node. Note + that the IPv4 address can be a public or a private address; the + latter does not present any additional difficulty, since an NSP must + be used as Pref64::/96 (in this scenario the usage of the Well-Known + prefix is not supported as discussed in + [I-D.ietf-behave-address-format]). Once these IPv6 addresses have + been assigned to represent the IPv4 nodes in the IPv6 Internet, real + AAAA RRs containing these addresses can be published in the DNS under + the site's domain. This is the recommended approach to handle this + scenario, because it does not involve synthesizing AAAA records at + the time of query. + + 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 modify all the authoritative servers to generate + synthetic AAAA records for a zone, possibly based on additional + constraints, upon the receipt of a DNS query for the AAAA RR. The + first option -- in which the AAAA is synthesized when the DNS update + message is received, and the data published in the relevant zone -- + + + +Bagnulo, et al. Expires August 19, 2010 [Page 23] + +Internet-Draft DNS64 February 2010 + + + is recommended over the second option (i.e. the synthesis upon + receipt of the AAAA DNS query). This is because it is usually easier + to solve problems of misconfiguration and so on when the DNS + responses are not being generated dynamically. However, it may be + the case where the primary server (that receives all the updates) + cannot be upgraded for whatever reason, but where a secondary can be + upgraded in order to handle the (comparatively small amount) of AAAA + queries. In such case, it is possible to use the DNS64 as described + next. The DNS64 behavior that we describe in this section covers the + case of synthesizing the AAAA RR when the DNS query arrives. + + The scenario for this case is depicted in the following figure: + + + +-----------+ +----------------------+ + | | | IPv4 site | + | IPv6 | +-------+ | +----+ | + | Internet |------| NAT64 |-----|---| H2 | | + | | +-------+ | +----+ | + | | | | 192.0.2.1 | + | | +------------+ | | + | |----| Name server|--| | + | | | with DNS64 | | | + +-----------+ +------------+ | | + | | | | + +----+ | | + | H1 | +----------------------+ + +----+ + + The figure shows an IPv6 node H1 and an IPv4 node H2 with IPv4 + address X 192.0.2.1 and FQDN h2.example.com. + + A IPv6/IPv4 translator connects the IPv4 network to the IPv6 + Internet. This IPv6/IPv4 translator has a NSP 2001:DB8::/96. + + 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 (2001:DB8::/96). For the purpose of this + example, we assume it learns this through manual configuration. + + The steps by which H1 establishes communication with H2 are: + + + + +Bagnulo, et al. Expires August 19, 2010 [Page 24] + +Internet-Draft DNS64 February 2010 + + + 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 from. If that is the case, the name server synthesizes + a AAAA record from the A RR and the prefix 2001:DB8::/96. The + IPv6 address in the AAAA record is 2001:DB8::192.0.2.1. + + 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. + + 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 + + See the discussion on the usage of DNSSEC and DNS64 described in + section 3, section 5.5, and section 6.2. . + + +9. IANA Considerations + + This memo makes no request of IANA. + + +10. Contributors + + Dave Thaler + + Microsoft + + dthaler@windows.microsoft.com + + +11. 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, + + + +Bagnulo, et al. Expires August 19, 2010 [Page 25] + +Internet-Draft DNS64 February 2010 + + + Jari Arkko, Rob Austein, Timothy Baldwin, Fred Baker, Doug Barton, + Marc Blanchet, Cameron Byrne, Brian Carpenter, Hui Deng, Francis + Dupont, Patrik Faltstrom, Ed Jankiewicz, Peter Koch, Suresh Krishnan, + Ed Lewis, Xing Li, Bill Manning, Matthijs Mekking, Hiroshi Miyata, + Simon Perrault, Teemu Savolainen, Jyrki Soini, Dave Thaler, Mark + Townsley, Rick van Rein, Stig Venaas, Magnus Westerlund, Florian + Weimer, Dan Wing, Xu Xiaohu, Xiangsong Cui. + + Marcelo Bagnulo and Iljitsch van Beijnum are partly funded by + Trilogy, a research project supported by the European Commission + under its Seventh Framework Program. + + +12. References + +12.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [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. + + [RFC4787] Audet, F. and C. Jennings, "Network Address Translation + (NAT) Behavioral Requirements for Unicast UDP", BCP 127, + RFC 4787, January 2007. + + [I-D.ietf-behave-address-format] + Huitema, C., Bao, C., Bagnulo, M., Boucadair, M., and X. + Li, "IPv6 Addressing of IPv4/IPv6 Translators", + draft-ietf-behave-address-format-04 (work in progress), + January 2010. + +12.2. Informative References + + [I-D.ietf-behave-v6v4-xlate-stateful] + Bagnulo, M., Matthews, P., and I. Beijnum, "Stateful + NAT64: Network Address and Protocol Translation from IPv6 + Clients to IPv4 Servers", + draft-ietf-behave-v6v4-xlate-stateful-08 (work in + progress), January 2010. + + [RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, + "Dynamic Updates in the Domain Name System (DNS UPDATE)", + RFC 2136, April 1997. + + + +Bagnulo, et al. Expires August 19, 2010 [Page 26] + +Internet-Draft DNS64 February 2010 + + + [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. + 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. + + [RFC5735] Cotton, M. and L. Vegoda, "iSpecial Use IPv4 Addresses", + BCP 153, RFC 5735, January 2010. + + [I-D.ietf-behave-v6v4-framework] + Baker, F., Li, X., Bao, C., and K. Yin, "Framework for + IPv4/IPv6 Translation", + draft-ietf-behave-v6v4-framework-06 (work in progress), + February 2010. + + [I-D.venaas-behave-mcast46] + Venaas, S., Asaeda, H., SUZUKI, S., and T. Fujisaki, "An + IPv4 - IPv6 multicast translator", + draft-venaas-behave-mcast46-01 (work in progress), + July 2009. + + [I-D.ietf-dnsop-default-local-zones] + Andrews, M., "Locally-served DNS Zones", + draft-ietf-dnsop-default-local-zones-09 (work in + progress), November 2009. + + [I-D.savolainen-mif-dns-server-selection] + Savolainen, T., "DNS Server Selection on Multi-Homed + Hosts", draft-savolainen-mif-dns-server-selection-01 (work + in progress), October 2009. + + + + +Bagnulo, et al. Expires August 19, 2010 [Page 27] + +Internet-Draft DNS64 February 2010 + + +Appendix A. Motivations and Implications of synthesizing AAAA RR when + real AAAA RR exists + + The motivation for synthesizing AAAA RRs when a real AAAA RRs exist + 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 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 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 the + preferred destination address to use. So, if the DNS64 resolver + returns both the synthetic AAAA RRs and the real AAAA RRs, then if + the DNS64 is operated by the same domain as the initiating host, and + a global unicast prefix (called an NSP in + [I-D.ietf-behave-address-format]) is used, then a synthetic AAAA RR + is likely to be preferred. + + This means that without further configuration: + + In "An IPv6 network to the IPv4 Internet" scenario , the host will + prefer translated connectivity if an NSP is used. If the Well- + Known Prefix defined in [I-D.ietf-behave-address-format] is used, + it will probably prefer native connectivity. + + 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 + + + +Bagnulo, et al. Expires August 19, 2010 [Page 28] + +Internet-Draft DNS64 February 2010 + + + is used (the Well-Known Prefix usage is not supported in this + case) + + In "an IPv6 network to IPv4 network" scenario, for local + destinations (i.e., target hosts inside the local site), it is + likely that the NSP and the destination prefix are the same, so we + can use the order of RR in the DNS reply to bias the selection + through native connectivity. If the Well-Known Prefix is used, + the longest prefix match rule will select native connectivity. + + So this option introduces problems in the following cases: + + An IPv6 network to the IPv4 internet with an NSP + + IPv6 to IPv4 in the same network when reaching external + destinations and an NSP 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. + + +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 + + + + + + + +Bagnulo, et al. Expires August 19, 2010 [Page 29] + +Internet-Draft DNS64 February 2010 + + + 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 August 19, 2010 [Page 30] +