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