6 Intended status: Standards Track A. Sullivan
7 Expires: April 4, 2011 Shinkuro
15 DNS64: DNS extensions for Network Address Translation from IPv6 Clients
17 draft-ietf-behave-dns64-11
21 DNS64 is a mechanism for synthesizing AAAA records from A records.
22 DNS64 is used with an IPv6/IPv4 translator to enable client-server
23 communication between an IPv6-only client and an IPv4-only server,
24 without requiring any changes to either the IPv6 or the IPv4 node,
25 for the class of applications that work through NATs. This document
26 specifies DNS64, and provides suggestions on how it should be
27 deployed in conjunction with IPv6/IPv4 translators.
31 This Internet-Draft is submitted in full conformance with the
32 provisions of BCP 78 and BCP 79.
34 Internet-Drafts are working documents of the Internet Engineering
35 Task Force (IETF). Note that other groups may also distribute
36 working documents as Internet-Drafts. The list of current Internet-
37 Drafts is at http://datatracker.ietf.org/drafts/current/.
39 Internet-Drafts are draft documents valid for a maximum of six months
40 and may be updated, replaced, or obsoleted by other documents at any
41 time. It is inappropriate to use Internet-Drafts as reference
42 material or to cite them other than as "work in progress."
44 This Internet-Draft will expire on April 4, 2011.
48 Copyright (c) 2010 IETF Trust and the persons identified as the
49 document authors. All rights reserved.
51 This document is subject to BCP 78 and the IETF Trust's Legal
55 Bagnulo, et al. Expires April 4, 2011 [Page 1]
57 Internet-Draft DNS64 October 2010
60 Provisions Relating to IETF Documents
61 (http://trustee.ietf.org/license-info) in effect on the date of
62 publication of this document. Please review these documents
63 carefully, as they describe your rights and restrictions with respect
64 to this document. Code Components extracted from this document must
65 include Simplified BSD License text as described in Section 4.e of
66 the Trust Legal Provisions and are provided without warranty as
67 described in the Simplified BSD License.
111 Bagnulo, et al. Expires April 4, 2011 [Page 2]
113 Internet-Draft DNS64 October 2010
118 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
119 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
120 3. Background to DNS64-DNSSEC interaction . . . . . . . . . . . . 8
121 4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 10
122 5. DNS64 Normative Specification . . . . . . . . . . . . . . . . 11
123 5.1. Resolving AAAA queries and the answer section . . . . . . 11
124 5.1.1. The answer when there is AAAA data available . . . . . 12
125 5.1.2. The answer when there is an error . . . . . . . . . . 12
126 5.1.3. Dealing with timeouts . . . . . . . . . . . . . . . . 12
127 5.1.4. Special exclusion set for AAAA records . . . . . . . . 13
128 5.1.5. Dealing with CNAME and DNAME . . . . . . . . . . . . . 13
129 5.1.6. Data for the answer when performing synthesis . . . . 13
130 5.1.7. Performing the synthesis . . . . . . . . . . . . . . . 14
131 5.1.8. Querying in parallel . . . . . . . . . . . . . . . . . 14
132 5.2. Generation of the IPv6 representations of IPv4
133 addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
134 5.3. Handling other Resource Records and the Additional
135 Section . . . . . . . . . . . . . . . . . . . . . . . . . 16
136 5.3.1. PTR Resource Record . . . . . . . . . . . . . . . . . 16
137 5.3.2. Handling the additional section . . . . . . . . . . . 17
138 5.3.3. Other Resource Records . . . . . . . . . . . . . . . . 17
139 5.4. Assembling a synthesized response to a AAAA query . . . . 18
140 5.5. DNSSEC processing: DNS64 in validating resolver mode . . . 18
141 6. Deployment notes . . . . . . . . . . . . . . . . . . . . . . . 19
142 6.1. DNS resolvers and DNS64 . . . . . . . . . . . . . . . . . 19
143 6.2. DNSSEC validators and DNS64 . . . . . . . . . . . . . . . 20
144 6.3. DNS64 and multihomed and dual-stack hosts . . . . . . . . 20
145 6.3.1. IPv6 multihomed hosts . . . . . . . . . . . . . . . . 20
146 6.3.2. Accidental dual-stack DNS64 use . . . . . . . . . . . 21
147 6.3.3. Intentional dual-stack DNS64 use . . . . . . . . . . . 21
148 7. Deployment scenarios and examples . . . . . . . . . . . . . . 22
149 7.1. Example of An-IPv6-network-to-IPv4-Internet setup with
150 DNS64 in DNS server mode . . . . . . . . . . . . . . . . . 22
151 7.2. An example of an-IPv6-network-to-IPv4-Internet setup
152 with DNS64 in stub-resolver mode . . . . . . . . . . . . . 24
153 7.3. Example of IPv6-Internet-to-an-IPv4-network setup
154 DNS64 in DNS server mode . . . . . . . . . . . . . . . . . 25
155 8. Security Considerations . . . . . . . . . . . . . . . . . . . 27
156 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
157 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 28
158 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28
159 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28
160 12.1. Normative References . . . . . . . . . . . . . . . . . . . 28
161 12.2. Informative References . . . . . . . . . . . . . . . . . . 29
162 Appendix A. Motivations and Implications of synthesizing AAAA
163 Resource Records when real AAAA Resource Records
167 Bagnulo, et al. Expires April 4, 2011 [Page 3]
169 Internet-Draft DNS64 October 2010
172 exist . . . . . . . . . . . . . . . . . . . . . . . . 30
173 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31
223 Bagnulo, et al. Expires April 4, 2011 [Page 4]
225 Internet-Draft DNS64 October 2010
230 This document specifies DNS64, a mechanism that is part of the
231 toolbox for IPv6-IPv4 transition and co-existence. DNS64, used
232 together with an IPv6/IPv4 translator such as stateful NAT64
233 [I-D.ietf-behave-v6v4-xlate-stateful], allows an IPv6-only client to
234 initiate communications by name to an IPv4-only server.
236 DNS64 is a mechanism for synthesizing AAAA resource records (RRs)
237 from A RRs. A synthetic AAAA RR created by the DNS64 from an
238 original A RR contains the same owner name of the original A RR but
239 it contains an IPv6 address instead of an IPv4 address. The IPv6
240 address is an IPv6 representation of the IPv4 address contained in
241 the original A RR. The IPv6 representation of the IPv4 address is
242 algorithmically generated from the IPv4 address returned in the A RR
243 and a set of parameters configured in the DNS64 (typically, an IPv6
244 prefix used by IPv6 representations of IPv4 addresses and optionally
247 Together with an IPv6/IPv4 translator, these two mechanisms allow an
248 IPv6-only client to initiate communications to an IPv4-only server
249 using the FQDN of the server.
251 These mechanisms are expected to play a critical role in the IPv4-
252 IPv6 transition and co-existence. Due to IPv4 address depletion, it
253 is likely that in the future, many IPv6-only clients will want to
254 connect to IPv4-only servers. In the typical case, the approach only
255 requires the deployment of IPv6/IPv4 translators that connect an
256 IPv6-only network to an IPv4-only network, along with the deployment
257 of one or more DNS64-enabled name servers. However, some features
258 require performing the DNS64 function directly in the end-hosts
261 This document is structured as follows: section 2 provides a non-
262 normative overview of the behaviour of DNS64. Section 3 provides a
263 non-normative background required to understand the interaction
264 between DNS64 and DNSSEC. The normative specification of DNS64 is
265 provided in sections 4, 5 and 6. Section 4 defines the terminology,
266 section 5 is the actual DNS64 specification and section 6 covers
267 deployments issues. Section 7 is non-normative and provides a set of
268 examples and typical deployment scenarios.
273 This section provides an introduction to the DNS64 mechanism.
275 We assume that we have one or more IPv6/IPv4 translator boxes
279 Bagnulo, et al. Expires April 4, 2011 [Page 5]
281 Internet-Draft DNS64 October 2010
284 connecting an IPv4 network and an IPv6 network. The IPv6/IPv4
285 translator device provides translation services between the two
286 networks enabling communication between IPv4-only hosts and IPv6-only
287 hosts. (NOTE: By IPv6-only hosts we mean hosts running IPv6-only
288 applications, hosts that can only use IPv6, as well as cases where
289 only IPv6 connectivity is available to the client. By IPv4-only
290 servers we mean servers running IPv4-only applications, servers that
291 can only use IPv4, as well as cases where only IPv4 connectivity is
292 available to the server). Each IPv6/IPv4 translator used in
293 conjunction with DNS64 must allow communications initiated from the
294 IPv6-only host to the IPv4-only host.
296 To allow an IPv6 initiator to do a standard AAAA RR DNS lookup to
297 learn the address of the responder, DNS64 is used to synthesize a
298 AAAA record from an A record containing a real IPv4 address of the
299 responder, whenever the DNS64 cannot retrieve a AAAA record for the
300 queried name. The DNS64 service appears as a regular DNS server or
301 resolver to the IPv6 initiator. The DNS64 receives a AAAA DNS query
302 generated by the IPv6 initiator. It first attempts a resolution for
303 the requested AAAA records. If there are no AAAA records available
304 for the target node (which is the normal case when the target node is
305 an IPv4-only node), DNS64 performs a query for A records. For each A
306 record discovered, DNS64 creates a synthetic AAAA RR from the
307 information retrieved in the A RR.
309 The owner name of a synthetic AAAA RR is the same as that of the
310 original A RR, but an IPv6 representation of the IPv4 address
311 contained in the original A RR is included in the AAAA RR. The IPv6
312 representation of the IPv4 address is algorithmically generated from
313 the IPv4 address and additional parameters configured in the DNS64.
314 Among those parameters configured in the DNS64, there is at least one
315 IPv6 prefix. If not explicitly mentioned, all prefixes are treated
316 equally and the operations described in this document are performed
317 using the prefixes available. So as to be general, we will call any
318 of these prefixes Pref64::/n, and describe the operations made with
319 the generic prefix Pref64::/n. The IPv6 address representing IPv4
320 addresses included in the AAAA RR synthesized by the DNS64 contain
321 Pref64::/n and they also embed the original IPv4 address.
323 The same algorithm and the same Pref64::/n prefix(es) must be
324 configured both in the DNS64 device and the IPv6/IPv4 translator(s),
325 so that both can algorithmically generate the same IPv6
326 representation for a given IPv4 address. In addition, it is required
327 that IPv6 packets addressed to an IPv6 destination address that
328 contains the Pref64::/n be delivered to an IPv6/IPv4 translator that
329 has that particular Pref64::/n configured, so they can be translated
335 Bagnulo, et al. Expires April 4, 2011 [Page 6]
337 Internet-Draft DNS64 October 2010
340 Once the DNS64 has synthesized the AAAA RRs, the synthetic AAAA RRs
341 are passed back to the IPv6 initiator, which will initiate an IPv6
342 communication with the IPv6 address associated with the IPv4
343 receiver. The packet will be routed to an IPv6/IPv4 translator which
344 will forward it to the IPv4 network.
346 In general, the only shared state between the DNS64 and the IPv6/IPv4
347 translator is the Pref64::/n and an optional set of static
348 parameters. The Pref64::/n and the set of static parameters must be
349 configured to be the same on both; there is no communication between
350 the DNS64 device and IPv6/IPv4 translator functions. The mechanism
351 to be used for configuring the parameters of the DNS64 is beyond the
354 The prefixes to be used as Pref64::/n and their applicability are
355 discussed in [I-D.ietf-behave-address-format]. There are two types
356 of prefixes that can be used as Pref64::/n.
358 The Pref64::/n can be the Well-Known Prefix 64:FF9B::/96 reserved
359 by [I-D.ietf-behave-address-format] for the purpose of
360 representing IPv4 addresses in IPv6 address space.
362 The Pref64::/n can be a Network-Specific Prefix (NSP). An NSP is
363 an IPv6 prefix assigned by an organization to create IPv6
364 representations of IPv4 addresses.
366 The main difference in the nature of the two types of prefixes is
367 that the NSP is a locally assigned prefix that is under control of
368 the organization that is providing the translation services, while
369 the Well-Known Prefix is a prefix that has a global meaning since it
370 has been assigned for the specific purpose of representing IPv4
371 addresses in IPv6 address space.
373 The DNS64 function can be performed in any of three places. The
374 terms below are more formally defined in Section 4.
376 The first option is to locate the DNS64 function in authoritative
377 servers for a zone. In this case, the authoritative server provides
378 synthetic AAAA RRs for an IPv4-only host in its zone. This is one
379 type of DNS64 server.
381 Another option is to locate the DNS64 function in recursive name
382 servers serving end hosts. In this case, when an IPv6-only host
383 queries the name server for AAAA RRs for an IPv4-only host, the name
384 server can perform the synthesis of AAAA RRs and pass them back to
385 the IPv6-only initiator. The main advantage of this mode is that
386 current IPv6 nodes can use this mechanism without requiring any
387 modification. This mode is called "DNS64 in DNS recursive resolver
391 Bagnulo, et al. Expires April 4, 2011 [Page 7]
393 Internet-Draft DNS64 October 2010
396 mode". This is a second type of DNS64 server, and it is also one
397 type of DNS64 resolver.
399 The last option is to place the DNS64 function in the end hosts,
400 coupled to the local (stub) resolver. In this case, the stub
401 resolver will try to obtain (real) AAAA RRs and in case they are not
402 available, the DNS64 function will synthesize AAAA RRs for internal
403 usage. This mode is compatible with some functions like DNSSEC
404 validation in the end host. The main drawback of this mode is its
405 deployability, since it requires changes in the end hosts. This mode
406 is called "DNS64 in stub-resolver mode". This is the second type of
410 3. Background to DNS64-DNSSEC interaction
412 DNSSEC ([RFC4033], [RFC4034], [RFC4035]) presents a special challenge
413 for DNS64, because DNSSEC is designed to detect changes to DNS
414 answers, and DNS64 may alter answers coming from an authoritative
417 A recursive resolver can be security-aware or security-oblivious.
418 Moreover, a security-aware recursive resolver can be validating or
419 non-validating, according to operator policy. In the cases below,
420 the recursive resolver is also performing DNS64, and has a local
421 policy to validate. We call this general case vDNS64, but in all the
422 cases below the DNS64 functionality should be assumed needed.
424 DNSSEC includes some signaling bits that offer some indicators of
425 what the query originator understands.
427 If a query arrives at a vDNS64 device with the "DNSSEC OK" (DO) bit
428 set, the query originator is signaling that it understands DNSSEC.
429 The DO bit does not indicate that the query originator will validate
430 the response. It only means that the query originator can understand
431 responses containing DNSSEC data. Conversely, if the DO bit is
432 clear, that is evidence that the querying agent is not aware of
435 If a query arrives at a vDNS64 device with the "Checking Disabled"
436 (CD) bit set, it is an indication that the querying agent wants all
437 the validation data so it can do checking itself. By local policy,
438 vDNS64 could still validate, but it must return all data to the
439 querying agent anyway.
441 Here are the possible cases:
447 Bagnulo, et al. Expires April 4, 2011 [Page 8]
449 Internet-Draft DNS64 October 2010
452 1. A DNS64 (DNSSEC-aware or DNSSEC-oblivious) receives a query with
453 the DO bit clear. In this case, DNSSEC is not a concern, because
454 the querying agent does not understand DNSSEC responses. The
455 DNS64 can do validation of the response, if dictated by its local
458 2. A security-oblivious DNS64 receives a query with the DO bit set,
459 and the CD bit clear or set. This is just like the case of a
460 non-DNS64 case: the server doesn't support it, so the querying
461 agent is out of luck.
463 3. A security-aware and non-validating DNS64 receives a query with
464 the DO bit set and the CD bit clear. Such a resolver is not
465 validating responses, likely due to local policy (see [RFC4035],
466 section 4.2). For that reason, this case amounts to the same as
467 the previous case, and no validation happens.
469 4. A security-aware and non-validating DNS64 receives a query with
470 the DO bit set and the CD bit set. In this case, the DNS64 is
471 supposed to pass on all the data it gets to the query initiator
472 (see section 3.2.2 of [RFC4035]). This case will not work with
473 DNS64, unless the validating resolver is prepared to do DNS64
474 itself. If the DNS64 modifies the record, the client will get
475 the data back and try to validate it, and the data will be
476 invalid as far as the client is concerned.
478 5. A security-aware and validating DNS64 resolver receives a query
479 with the DO bit clear and CD clear. In this case, the resolver
480 validates the data. If it fails, it returns RCODE 2 (Server
481 failure); otherwise, it returns the answer. This is the ideal
482 case for vDNS64. The resolver validates the data, and then
483 synthesizes the new record and passes that to the client. The
484 client, which is presumably not validating (else it should have
485 set DO and CD), cannot tell that DNS64 is involved.
487 6. A security-aware and validating DNS64 resolver receives a query
488 with the DO bit set and CD clear. This works like the previous
489 case, except that the resolver should also set the "Authentic
490 Data" (AD) bit on the response.
492 7. A security-aware and validating DNS64 resolver receives a query
493 with the DO bit set and CD set. This is effectively the same as
494 the case where a security-aware and non-validating recursive
495 resolver receives a similar query, and the same thing will
496 happen: the downstream validator will mark the data as invalid if
497 DNS64 has performed synthesis. The node needs to do DNS64
498 itself, or else communication will fail.
503 Bagnulo, et al. Expires April 4, 2011 [Page 9]
505 Internet-Draft DNS64 October 2010
510 This section provides definitions for the special terms used in the
513 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
514 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
515 document are to be interpreted as described in RFC 2119 [RFC2119].
517 Authoritative server: A DNS server that can answer authoritatively a
520 DNS64: A logical function that synthesizes DNS resource records (e.g
521 AAAA records containing IPv6 addresses) from DNS resource records
522 actually contained in the DNS (e.g., A records containing IPv4
525 DNS64 recursive resolver: A recursive resolver that provides the
526 DNS64 functionality as part of its operation. This is the same
527 thing as "DNS64 in recursive resolver mode".
529 DNS64 resolver: Any resolver (stub resolver or recursive resolver)
530 that provides the DNS64 function.
532 DNS64 server: Any server providing the DNS64 function. This
533 includes the server portion of a recursive resolver when it is
534 providing the DNS64 function.
536 IPv4-only server: Servers running IPv4-only applications, servers
537 that can only use IPv4, as well as cases where only IPv4
538 connectivity is available to the server.
540 IPv6-only hosts: Hosts running IPv6-only applications, hosts that
541 can only use IPv6, as well as cases where only IPv6 connectivity
542 is available to the client.
544 Recursive resolver: A DNS server that accepts requests from one
545 resolver, and asks another server (of some description) for the
546 answer on behalf of the first resolver. Full discussion of DNS
547 recursion is beyond the scope of this document; see [RFC1034] and
548 [RFC1035] for full details.
550 Synthetic RR: A DNS resource record (RR) that is not contained in
551 the authoritative servers' zone data, but which is instead
552 synthesized from other RRs in the same zone. An example is a
553 synthetic AAAA record created from an A record.
559 Bagnulo, et al. Expires April 4, 2011 [Page 10]
561 Internet-Draft DNS64 October 2010
564 IPv6/IPv4 translator: A device that translates IPv6 packets to IPv4
565 packets and vice-versa. It is only required that the
566 communication initiated from the IPv6 side be supported.
568 For a detailed understanding of this document, the reader should also
569 be familiar with DNS terminology from [RFC1034], [RFC1035] and
570 current NAT terminology from [RFC4787]. Some parts of this document
571 assume familiarity with the terminology of the DNS security
572 extensions outlined in [RFC4035]. It is worth emphasizing that while
573 DNS64 is a logical function separate from the DNS, it is nevertheless
574 closely associated with that protocol. It depends on the DNS
575 protocol, and some behavior of DNS64 will interact with regular DNS
579 5. DNS64 Normative Specification
581 DNS64 is a logical function that synthesizes AAAA records from A
582 records. The DNS64 function may be implemented in a stub resolver,
583 in a recursive resolver, or in an authoritative name server. It
584 works within those DNS functions, and appears on the network as
585 though it were a "plain" DNS resolver or name server conforming to
586 [RFC1034], and [RFC1035].
588 The implementation SHOULD support mapping of separate IPv4 address
589 ranges to separate IPv6 prefixes for AAAA record synthesis. This
590 allows handling of special use IPv4 addresses [RFC5735].
592 DNS messages contain several sections. The portion of a DNS message
593 that is altered by DNS64 is the Answer section, which is discussed
594 below in section Section 5.1. The resulting synthetic answer is put
595 together with other sections, and that creates the message that is
596 actually returned as the response to the DNS query. Assembling that
597 response is covered below in section Section 5.4.
599 DNS64 also responds to PTR queries involving addresses containing any
600 of the IPv6 prefixes it uses for synthesis of AAAA RRs.
602 5.1. Resolving AAAA queries and the answer section
604 When the DNS64 receives a query for RRs of type AAAA and class IN, it
605 first attempts to retrieve non-synthetic RRs of this type and class,
606 either by performing a query or, in the case of an authoritative
607 server, by examining its own results. The query may be answered from
608 a local cache, if one is available. DNS64 operation for classes
609 other than IN is undefined, and a DNS64 MUST behave as though no
610 DNS64 function is configured.
615 Bagnulo, et al. Expires April 4, 2011 [Page 11]
617 Internet-Draft DNS64 October 2010
620 5.1.1. The answer when there is AAAA data available
622 If the query results in one or more AAAA records in the answer
623 section, the result is returned to the requesting client as per
624 normal DNS semantics, except in the case where any of the AAAA
625 records match a special exclusion set of prefixes, considered in
626 Section 5.1.4. If there is (non-excluded) AAAA data available, DNS64
627 SHOULD NOT include synthetic AAAA RRs in the response (see Appendix A
628 for an analysis of the motivations for and the implications of not
629 complying with this recommendation). By default DNS64
630 implementations MUST NOT synthesize AAAA RRs when real AAAA RRs
633 5.1.2. The answer when there is an error
635 If the query results in a response with RCODE other than 0 (No error
636 condition), then there are two possibilities. A result with RCODE=3
637 (Name Error) is handled according to normal DNS operation (which is
638 normally to return the error to the client). This stage is still
639 prior to any synthesis having happened, so a response to be returned
640 to the client does not need any special assembly than would usually
641 happen in DNS operation.
643 Any other RCODE is treated as though the RCODE were 0 (see sections
644 Section 5.1.6 and Section 5.1.7) and the answer section were empty.
645 This is because of the large number of different responses from
646 deployed name servers when they receive AAAA queries without a AAAA
647 record being available (see [RFC4074]). Note that this means, for
648 practical purposes, that several different classes of error in the
649 DNS are all treated as though a AAAA record is not available for that
652 It is important to note that, as of this writing, some servers
653 respond with RCODE=3 to a AAAA query even if there is an A record
654 available for that owner name. Those servers are in clear violation
655 of the meaning of RCODE 3, and it is expected that they will decline
656 in use as IPv6 deployment increases.
658 5.1.3. Dealing with timeouts
660 If the query receives no answer before the timeout (which might be
661 the timeout from every authoritative server, depending on whether the
662 DNS64 is in recursive resolver mode), it is treated as RCODE=2
671 Bagnulo, et al. Expires April 4, 2011 [Page 12]
673 Internet-Draft DNS64 October 2010
676 5.1.4. Special exclusion set for AAAA records
678 Some IPv6 addresses are not actually usable by IPv6-only hosts. If
679 they are returned to IPv6-only querying agents as AAAA records,
680 therefore, the goal of decreasing the number of failure modes will
681 not be attained. Examples include AAAA records with addresses in the
682 ::ffff:0:0/96 network, and possibly (depending on the context) AAAA
683 records with the site's Pref::64/n or the Well-Known Prefix (see
684 below for more about the Well-Known Prefix). A DNS64 implementation
685 SHOULD provide a mechanism to specify IPv6 prefix ranges to be
686 treated as though the AAAA containing them were an empty answer. An
687 implementation SHOULD include the ::ffff/96 network in that range by
688 default. Failure to provide this facility will mean that clients
689 querying the DNS64 function may not be able to communicate with hosts
690 that would be reachable from a dual-stack host.
692 When the DNS64 performs its initial AAAA query, if it receives an
693 answer with only AAAA records containing addresses in the excluded
694 range(s), then it MUST treat the answer as though it were an empty
695 answer, and proceed accordingly. If it receives an answer with at
696 least one AAAA record containing an address outside any of the
697 excluded range(s), then it MAY build an answer section for a response
698 including only the AAAA record(s) that do not contain any of the
699 addresses inside the excluded ranges. That answer section is used in
700 the assembly of a response as detailed in Section 5.4.
701 Alternatively, it MAY treat the answer as though it were an empty
702 answer, and proceed accordingly. It MUST NOT return the offending
703 AAAA records as part of a response.
705 5.1.5. Dealing with CNAME and DNAME
707 If the response contains a CNAME or a DNAME, then the CNAME or DNAME
708 chain is followed until the first terminating A or AAAA record is
709 reached. This may require the DNS64 to ask for an A record, in case
710 the response to the original AAAA query is a CNAME or DNAME without a
711 AAAA record to follow. The resulting AAAA or A record is treated
712 like any other AAAA or A case, as appropriate.
714 When assembling the answer section, any chains of CNAME or DNAME RRs
715 are included as part of the answer along with the synthetic AAAA (if
718 5.1.6. Data for the answer when performing synthesis
720 If the query results in no error but an empty answer section in the
721 response, the DNS64 attempts to retrieve A records for the name in
722 question, either by performing another query or, in the case of an
723 authoritative server, by examining its own results. If this new A RR
727 Bagnulo, et al. Expires April 4, 2011 [Page 13]
729 Internet-Draft DNS64 October 2010
732 query results in an empty answer or in an error, then the empty
733 result or error is used as the basis for the answer returned to the
734 querying client. If instead the query results in one or more A RRs,
735 the DNS64 synthesizes AAAA RRs based on the A RRs according to the
736 procedure outlined in Section 5.1.7. The DNS64 returns the
737 synthesized AAAA records in the answer section, removing the A
738 records that form the basis of the synthesis.
740 5.1.7. Performing the synthesis
742 A synthetic AAAA record is created from an A record as follows:
744 o The NAME field is set to the NAME field from the A record.
746 o The TYPE field is set to 28 (AAAA).
748 o The CLASS field is set to the original CLASS field, 1. Under this
749 specification, DNS64 for any CLASS other than 1 is undefined.
751 o The TTL field is set to the minimum of the TTL of the original A
752 RR and the SOA RR for the queried domain. (Note that in order to
753 obtain the TTL of the SOA RR, the DNS64 does not need to perform a
754 new query, but it can remember the TTL from the SOA RR in the
755 negative response to the AAAA query. If the SOA RR was not
756 delivered with the negative response to the AAAA query, then the
757 DNS64 SHOULD use a the minimum of the TTL of the original A RR and
758 600 seconds. It is possible instead to query explicitly for the
759 SOA RR and use the result of that query, but this will increase
760 query load and time to resolution for little additional benefit.)
761 This is in keeping with the approach used in negative caching
764 o The RDLENGTH field is set to 16.
766 o The RDATA field is set to the IPv6 representation of the IPv4
767 address from the RDATA field of the A record. The DNS64 MUST
768 check each A RR against configured IPv4 address ranges and select
769 the corresponding IPv6 prefix to use in synthesizing the AAAA RR.
770 See Section 5.2 for discussion of the algorithms to be used in
771 effecting the transformation.
773 5.1.8. Querying in parallel
775 The DNS64 MAY perform the query for the AAAA RR and for the A RR in
776 parallel, in order to minimize the delay.
778 Note: Querying in parallel will result in performing unnecessary A RR
779 queries in the case where no AAAA RR synthesis is required. A
783 Bagnulo, et al. Expires April 4, 2011 [Page 14]
785 Internet-Draft DNS64 October 2010
788 possible trade-off would be to perform them sequentially but with a
789 very short interval between them, so if we obtain a fast reply, we
790 avoid doing the additional query. (Note that this discussion is
791 relevant only if the DNS64 function needs to perform external queries
792 t fetch the RR. If the needed RR information is available locally,
793 as in the case of an authoritative server, the issue is no longer
796 5.2. Generation of the IPv6 representations of IPv4 addresses
798 DNS64 supports multiple algorithms for the generation of the IPv6
799 representation of an IPv4 address. The constraints imposed on the
800 generation algorithms are the following:
802 The same algorithm to create an IPv6 address from an IPv4 address
803 MUST be used by both a DNS64 to create the IPv6 address to be
804 returned in the synthetic AAAA RR from the IPv4 address contained
805 in an original A RR, and by a IPv6/IPv4 translator to create the
806 IPv6 address to be included in the source address field of the
807 outgoing IPv6 packets from the IPv4 address included in the source
808 address field of the incoming IPv4 packet.
810 The algorithm MUST be reversible; i.e., it MUST be possible to
811 derive the original IPv4 address from the IPv6 representation.
813 The input for the algorithm MUST be limited to the IPv4 address,
814 the IPv6 prefix (denoted Pref64::/n) used in the IPv6
815 representations and optionally a set of stable parameters that are
816 configured in the DNS64 and in the NAT64 (such as fixed string to
817 be used as a suffix).
819 For each prefix Pref64::/n, n MUST be less than or equal to 96.
820 If one or more Pref64::/n are configured in the DNS64 through
821 any means (such as manually configured, or other automatic
822 means not specified in this document), the default algorithm
823 MUST use these prefixes (and not use the Well-Known Prefix).
824 If no prefix is available, the algorithm MUST use the Well-
825 Known Prefix 64:FF9B::/96 defined in
826 [I-D.ietf-behave-address-format] to represent the IPv4 unicast
829 [[anchor6: Note in document: The value 64:FF9B::/96 is proposed as
830 the value for the Well-Known prefix and needs to be confirmed
831 whenis published as RFC.]][I-D.ietf-behave-address-format]
833 A DNS64 MUST support the algorithm for generating IPv6
834 representations of IPv4 addresses defined in Section 2 of
835 [I-D.ietf-behave-address-format]. Moreover, the aforementioned
839 Bagnulo, et al. Expires April 4, 2011 [Page 15]
841 Internet-Draft DNS64 October 2010
844 algorithm MUST be the default algorithm used by the DNS64. While the
845 normative description of the algorithm is provided in
846 [I-D.ietf-behave-address-format], a sample description of the
847 algorithm and its application to different scenarios is provided in
848 Section 7 for illustration purposes.
850 5.3. Handling other Resource Records and the Additional Section
852 5.3.1. PTR Resource Record
854 If a DNS64 server receives a PTR query for a record in the IP6.ARPA
855 domain, it MUST strip the IP6.ARPA labels from the QNAME, reverse the
856 address portion of the QNAME according to the encoding scheme
857 outlined in section 2.5 of [RFC3596], and examine the resulting
858 address to see whether its prefix matches any of the locally-
859 configured Pref64::/n or the default Well-known prefix. There are
860 two alternatives for a DNS64 server to respond to such PTR queries.
861 A DNS64 server MUST provide one of these, and SHOULD NOT provide both
862 at the same time unless different IP6.ARPA zones require answers of
865 1. The first option is for the DNS64 server to respond
866 authoritatively for its prefixes. If the address prefix matches
867 any Pref64::/n used in the site, either a NSP or the Well-Known
868 Prefix (i.e. 64:FF9B::/96), then the DNS64 server MAY answer the
869 query using locally-appropriate RDATA. The DNS64 server MAY use
870 the same RDATA for all answers. Note that the requirement is to
871 match any Pref64::/n used at the site, and not merely the
872 locally-configured Pref64::/n. This is because end clients could
873 ask for a PTR record matching an address received through a
874 different (site-provided) DNS64, and if this strategy is in
875 effect, those queries should never be sent to the global DNS.
876 The advantage of this strategy is that it makes plain to the
877 querying client that the prefix is one operated by the (DNS64)
878 site, and that the answers the client is getting are generated by
879 DNS64. The disadvantage is that any useful reverse-tree
880 information that might be in the global DNS is unavailable to the
881 clients querying the DNS64.
883 2. The second option is for the DNS64 nameserver to synthesize a
884 CNAME mapping the IP6.ARPA namespace to the corresponding IN-
885 ADDR.ARPA name. In this case, the DNS64 nameserver SHOULD ensure
886 that there is RDATA at the PTR of the corresponding IN-ADDR.ARPA
887 name, and that there is not an existing CNAME at that name. This
888 is in order to avoid synthesizing a CNAME that makes a CNAME
889 chain longer or that does not actually point to anything. The
890 rest of the response would be the normal DNS processing. The
891 CNAME can be signed on the fly if need be. The advantage of this
895 Bagnulo, et al. Expires April 4, 2011 [Page 16]
897 Internet-Draft DNS64 October 2010
900 approach is that any useful information in the reverse tree is
901 available to the querying client. The disadvantage is that it
902 adds additional load to the DNS64 (because CNAMEs have to be
903 synthesized for each PTR query that matches the Pref64::/n), and
904 that it may require signing on the fly.
906 If the address prefix does not match any Pref64::/n, then the DNS64
907 server MUST process the query as though it were any other query; i.e.
908 a recursive nameserver MUST attempt to resolve the query as though it
909 were any other (non-A/AAAA) query, and an authoritative server MUST
910 respond authoritatively or with a referral, as appropriate.
912 5.3.2. Handling the additional section
914 DNS64 synthesis MUST NOT be performed on any records in the
915 additional section of synthesized answers. The DNS64 MUST pass the
916 additional section unchanged.
918 NOTE: It may appear that adding synthetic records to the
919 additional section is desirable, because clients sometimes use the
920 data in the additional section to proceed without having to re-
921 query. There is in general no promise, however, that the
922 additional section will contain all the relevant records, so any
923 client that depends on the additional section being able to
924 satisfy its needs (i.e. without additional queries) is necessarily
925 broken. An IPv6-only client that needs a AAAA record, therefore,
926 will send a query for the necessary AAAA record if it is unable to
927 find such a record in the additional section of an answer it is
928 consuming. For a correctly-functioning client, the effect would
929 be no different if the additional section were empty.The
930 alternative, of removing the A records in the additional section
931 and replacing them with synthetic AAAA records, may cause a host
932 behind a NAT64 to query directly a nameserver that is unaware of
933 the NAT64 in question. The result in this case will be resolution
934 failure anyway, only later in the resolution operation. The
935 prohibition on synthetic data in the additional section reduces,
936 but does not eliminate, the possibility of resolution failures due
937 to cached DNS data from behind the DNS64. See Section 6.
939 5.3.3. Other Resource Records
941 If the DNS64 is in recursive resolver mode, then considerations
942 outlined in [I-D.ietf-dnsop-default-local-zones] may be relevant.
944 All other RRs MUST be returned unchanged. This includes responses to
951 Bagnulo, et al. Expires April 4, 2011 [Page 17]
953 Internet-Draft DNS64 October 2010
956 5.4. Assembling a synthesized response to a AAAA query
958 A DNS64 uses different pieces of data to build the response returned
959 to the querying client.
961 The query that is used as the basis for synthesis results either in
962 an error, an answer that can be used as a basis for synthesis, or an
963 empty (authoritative) answer. If there is an empty answer, then the
964 DNS64 responds to the original querying client with the answer the
965 DNS64 received to the original (initiator's) query. Otherwise, the
966 response is assembled as follows.
968 The header fields are set according to the usual rules for recursive
969 or authoritative servers, depending on the role that the DNS64 is
970 serving. The question section is copied from the original
971 (initiator's) query. The answer section is populated according to
972 the rules in Section 5.1.7. The authority and additional sections
973 are copied from the response to the final query that the DNS64
974 performed, and used as the basis for synthesis.
976 The final response from the DNS64 is subject to all the standard DNS
977 rules, including truncation [RFC1035] and EDNS0 handling [RFC2671].
979 5.5. DNSSEC processing: DNS64 in validating resolver mode
981 We consider the case where a recursive resolver that is performing
982 DNS64 also has a local policy to validate the answers according to
983 the procedures outlined in [RFC4035] Section 5. We call this general
986 The vDNS64 uses the presence of the DO and CD bits to make some
987 decisions about what the query originator needs, and can react
990 1. If CD is not set and DO is not set, vDNS64 SHOULD perform
991 validation and do synthesis as needed. See the next item for
992 rules about how to do validation and synthesis. In this case,
993 however, vDNS64 MUST NOT set the AD bit in any response.
995 2. If CD is not set and DO is set, then vDNS64 SHOULD perform
996 validation. Whenever vDNS64 performs validation, it MUST
997 validate the negative answer for AAAA queries before proceeding
998 to query for A records for the same name, in order to be sure
999 that there is not a legitimate AAAA record on the Internet.
1000 Failing to observe this step would allow an attacker to use DNS64
1001 as a mechanism to circumvent DNSSEC. If the negative response
1002 validates, and the response to the A query validates, then the
1003 vDNS64 MAY perform synthesis and SHOULD set the AD bit in the
1007 Bagnulo, et al. Expires April 4, 2011 [Page 18]
1009 Internet-Draft DNS64 October 2010
1012 answer to the client. This is acceptable, because [RFC4035],
1013 section 3.2.3 says that the AD bit is set by the name server side
1014 of a security-aware recursive name server if and only if it
1015 considers all the RRSets in the Answer and Authority sections to
1016 be authentic. In this case, the name server has reason to
1017 believe the RRSets are all authentic, so it SHOULD set the AD
1018 bit. If the data does not validate, the vDNS64 MUST respond with
1019 RCODE=2 (Server failure).
1020 A security-aware end point might take the presence of the AD bit
1021 as an indication that the data is valid, and may pass the DNS
1022 (and DNSSEC) data to an application. If the application attempts
1023 to validate the synthesized data, of course, the validation will
1024 fail. One could argue therefore that this approach is not
1025 desirable, but security aware stub resolvers must not place any
1026 reliance on data received from resolvers and validated on their
1027 behalf without certain criteria established by [RFC4035], section
1028 4.9.3. An application that wants to perform validation on its
1029 own should use the CD bit.
1031 3. If the CD bit is set and DO is set, then vDNS64 MAY perform
1032 validation, but MUST NOT perform synthesis. It MUST return the
1033 data to the query initiator, just like a regular recursive
1034 resolver, and depend on the client to do the validation and the
1036 The disadvantage to this approach is that an end point that is
1037 translation-oblivious but security-aware and validating will not
1038 be able to use the DNS64 functionality. In this case, the end
1039 point will not have the desired benefit of NAT64. In effect,
1040 this strategy means that any end point that wishes to do
1041 validation in a NAT64 context must be upgraded to be translation-
1047 While DNS64 is intended to be part of a strategy for aiding IPv6
1048 deployment in an internetworking environment with some IPv4-only and
1049 IPv6-only networks, it is important to realise that it is
1050 incompatible with some things that may be deployed in an IPv4-only or
1053 6.1. DNS resolvers and DNS64
1055 Full-service resolvers that are unaware of the DNS64 function can be
1056 (mis)configured to act as mixed-mode iterative and forwarding
1057 resolvers. In a native IPv4 context, this sort of configuration may
1058 appear to work. It is impossible to make it work properly without it
1059 being aware of the DNS64 function, because it will likely at some
1063 Bagnulo, et al. Expires April 4, 2011 [Page 19]
1065 Internet-Draft DNS64 October 2010
1068 point obtain IPv4-only glue records and attempt to use them for
1069 resolution. The result that is returned will contain only A records,
1070 and without the ability to perform the DNS64 function the resolver
1071 will be unable to answer the necessary AAAA queries.
1073 6.2. DNSSEC validators and DNS64
1075 An existing DNSSEC validator (i.e. that is unaware of DNS64) might
1076 reject all the data that comes from DNS64 as having been tampered
1077 with (even if it did not set CD when querying). If it is necessary
1078 to have validation behind the DNS64, then the validator must know how
1079 to perform the DNS64 function itself. Alternatively, the validating
1080 host may establish a trusted connection with a DNS64, and allow the
1081 DNS64 recursive resolver to do all validation on its behalf.
1083 6.3. DNS64 and multihomed and dual-stack hosts
1085 6.3.1. IPv6 multihomed hosts
1087 Synthetic AAAA records may be constructed on the basis of the network
1088 context in which they were constructed. If a host sends DNS queries
1089 to resolvers in multiple networks, it is possible that some of them
1090 will receive answers from a DNS64 without all of them being connected
1091 via a NAT64. For instance, suppose a system has two interfaces, i1
1092 and i2. Whereas i1 is connected to the IPv4 Internet via NAT64, i2
1093 has native IPv6 connectivity only. I1 might receive a AAAA answer
1094 from a DNS64 that is configured for a particular NAT64; the IPv6
1095 address contained in that AAAA answer will not connect with anything
1098 +---------------+ +-------------+
1099 | i1 (IPv6)+----NAT64--------+IPv4 Internet|
1103 | i2 (IPv6)+-----------------+IPv6 Internet|
1104 +---------------+ +-------------+
1106 Figure 1: IPv6 multihomed hosts
1108 This example illustrates why it is generally preferable that hosts
1109 treat DNS answers from one interface as local to that interface. The
1110 answer received on one interface will not work on the other
1111 interface. Hosts that attempt to use DNS answers globally may
1112 encounter surprising failures in these cases.
1114 Note that the issue is not that there are two interfaces, but that
1115 there are two networks involved. The same results could be achieved
1119 Bagnulo, et al. Expires April 4, 2011 [Page 20]
1121 Internet-Draft DNS64 October 2010
1124 with a single interface routed to two different networks.
1126 6.3.2. Accidental dual-stack DNS64 use
1128 Similarly, suppose that i1 has IPv6 connectivity and can connect to
1129 the IPv4 Internet through NAT64, but i2 has native IPv4 connectivity.
1130 In this case, i1 could receive an IPv6 address from a synthetic AAAA
1131 that would better be reached via native IPv4. Again, it is worth
1132 emphasising that this arises because there are two networks involved.
1134 +---------------+ +-------------+
1135 | i1 (IPv6)+----NAT64--------+IPv4 Internet|
1139 | i2 (IPv4)+-----------------+IPv4 Internet|
1140 +---------------+ +-------------+
1142 Figure 2: Accidental dual-stack DNS64 use
1144 The default configuration of dual-stack hosts is that IPv6 is
1145 preferred over IPv4 ([RFC3484]). In that arrangement the host will
1146 often use the NAT64 when native IPv4 would be more desirable. For
1147 this reason, hosts with IPv4 connectivity to the Internet should
1148 avoid using DNS64. This can be partly resolved by ISPs when
1149 providing DNS resolvers to clients, but that is not a guarantee that
1150 the NAT64 will never be used when a native IPv4 connection should be
1151 used. There is no general-purpose mechanism to ensure that native
1152 IPv4 transit will always be preferred, because to a DNS64-oblivious
1153 host, the DNS64 looks just like an ordinary DNS server. Operators of
1154 a NAT64 should expect traffic to pass through the NAT64 even when it
1157 6.3.3. Intentional dual-stack DNS64 use
1159 Finally, consider the case where the IPv4 connectivity on i2 is only
1160 with a LAN, and not with the IPv4 Internet. The IPv4 Internet is
1161 only accessible using the NAT64. In this case, it is critical that
1162 the DNS64 not synthesize AAAA responses for hosts in the LAN, or else
1163 that the DNS64 be aware of hosts in the LAN and provide context-
1164 sensitive answers ("split view" DNS answers) for hosts inside the
1165 LAN. As with any split view DNS arrangement, operators must be
1166 prepared for data to leak from one context to another, and for
1167 failures to occur because nodes accessible from one context are not
1168 accessible from the other.
1175 Bagnulo, et al. Expires April 4, 2011 [Page 21]
1177 Internet-Draft DNS64 October 2010
1180 +---------------+ +-------------+
1181 | i1 (IPv6)+----NAT64--------+IPv4 Internet|
1185 | i2 (IPv4)+---(local LAN only)
1188 Figure 3: Intentional dual-stack DNS64 use
1190 It is important for deployers of DNS64 to realise that, in some
1191 circumstances, making the DNS64 available to a dual-stack host will
1192 cause the host to prefer to send packets via NAT64 instead of via
1193 native IPv4, with the associated loss of performance or functionality
1194 (or both) entailed by the NAT. At the same time, some hosts are not
1195 able to learn about DNS servers provisioned on IPv6 addresses, or
1196 simply cannot send DNS packets over IPv6.
1199 7. Deployment scenarios and examples
1201 In this section we illustrate how the DNS64 behaves in different
1202 scenarios that are expected to be common. In particular we will
1203 consider the following scenarios defined in
1204 [I-D.ietf-behave-v6v4-framework]: the an-IPv6-network-to-IPv4-
1205 Internet scenario (both with DNS64 in DNS server mode and in stub-
1206 resolver mode) and the IPv6-Internet-to-an-IPv4-network setup (with
1207 DNS64 in DNS server mode only).
1209 In all the examples below, there is a IPv6/IPv4 translator connecting
1210 the IPv6 domain to the IPv4 one. Also there is a name server that is
1211 a dual-stack node, so it can communicate with IPv6 hosts using IPv6
1212 and with IPv4 nodes using IPv4. In addition, we assume that in the
1213 examples, the DNS64 function learns which IPv6 prefix it needs to use
1214 to map the IPv4 address space through manual configuration.
1216 7.1. Example of An-IPv6-network-to-IPv4-Internet setup with DNS64 in
1219 In this example, we consider an IPv6 node located in an IPv6-only
1220 site that initiates a communication to an IPv4 node located in the
1223 The scenario for this case is depicted in the following figure:
1231 Bagnulo, et al. Expires April 4, 2011 [Page 22]
1233 Internet-Draft DNS64 October 2010
1236 +---------------------+ +---------------+
1237 |IPv6 network | | IPv4 |
1238 | | +-------------+ | Internet |
1239 | |--| Name server |--| |
1240 | | | with DNS64 | | +----+ |
1241 | +----+ | +-------------+ | | H2 | |
1242 | | H1 |---| | | +----+ |
1243 | +----+ | +------------+ | 192.0.2.1 |
1244 | |---| IPv6/IPv4 |--| |
1245 | | | Translator | | |
1246 | | +------------+ | |
1248 +---------------------+ +---------------+
1250 Figure 4: An-IPv6-network-to-IPv4-Internet setup with DNS64 in DNS
1253 The figure shows an IPv6 node H1 and an IPv4 node H2 with IPv4
1254 address 192.0.2.1 and FQDN h2.example.com.
1256 The IPv6/IPv4 Translator has an IPv4 address 203.0.113.1 assigned to
1257 its IPv4 interface and it is using the WKP 64:FF9B::/96 to create
1258 IPv6 representations of IPv4 addresses. The same prefix is
1259 configured in the DNS64 function in the local name server.
1261 For this example, assume the typical DNS situation where IPv6 hosts
1262 have only stub resolvers, and they are configured with the IP address
1263 of a name server that they always have to query and that performs
1264 recursive lookups (henceforth called "the recursive nameserver").
1266 The steps by which H1 establishes communication with H2 are:
1268 1. H1 does a DNS lookup for h2.example.com. H1 does this by sending
1269 a DNS query for a AAAA record for H2 to the recursive name
1270 server. The recursive name server implements DNS64
1273 2. The recursive name server resolves the query, and discovers that
1274 there are no AAAA records for H2.
1276 3. The recursive name server performs an A-record query for H2 and
1277 gets back an RRset containing a single A record with the IPv4
1278 address 192.0.2.1. The name server then synthesizes a AAAA
1279 record. The IPv6 address in the AAAA record contains the prefix
1280 assigned to the IPv6/IPv4 Translator in the upper 96 bits and the
1281 received IPv4 address in the lower 32 bits i.e. the resulting
1282 IPv6 address is 64:FF9B::192.0.2.1.
1287 Bagnulo, et al. Expires April 4, 2011 [Page 23]
1289 Internet-Draft DNS64 October 2010
1292 4. H1 receives the synthetic AAAA record and sends a packet towards
1293 H2. The packet is sent to the destination address 64:FF9B::
1296 5. The packet is routed to the IPv6 interface of the IPv6/IPv4
1297 translator and the subsequent communication flows by means of the
1298 IPv6/IPv4 translator mechanisms.
1300 7.2. An example of an-IPv6-network-to-IPv4-Internet setup with DNS64 in
1303 This case is depicted in the following figure:
1306 +---------------------+ +---------------+
1307 |IPv6 network | | IPv4 |
1308 | | +--------+ | Internet |
1309 | |-----| Name |----| |
1310 | +-----+ | | server | | +----+ |
1311 | | H1 | | +--------+ | | H2 | |
1312 | |with |---| | | +----+ |
1313 | |DNS64| | +------------+ | 192.0.2.1 |
1314 | +----+ |---| IPv6/IPv4 |--| |
1315 | | | Translator | | |
1316 | | +------------+ | |
1318 +---------------------+ +---------------+
1321 Figure 5: An-IPv6-network-to-IPv4-Internet setup with DNS64 in stub-
1324 The figure shows an IPv6 node H1 implementing the DNS64 function and
1325 an IPv4 node H2 with IPv4 address 192.0.2.1 and FQDN h2.example.com.
1327 The IPv6/IPv4 Translator has an IPv4 address 203.0.113.1 assigned to
1328 its IPv4 interface and it is using the WKP 64:FF9B::/96 to create
1329 IPv6 representations of IPv4 addresses. The same prefix is
1330 configured in the DNS64 function in H1.
1332 For this example, assume the typical DNS situation where IPv6 hosts
1333 have only stub resolvers, and they are configured with the IP address
1334 of a name server that they always have to query and that performs
1335 recursive lookups (henceforth called "the recursive nameserver").
1336 The recursive name server does not perform the DNS64 function.
1338 The steps by which H1 establishes communication with H2 are:
1343 Bagnulo, et al. Expires April 4, 2011 [Page 24]
1345 Internet-Draft DNS64 October 2010
1348 1. H1 does a DNS lookup for h2.example.com. H1 does this by sending
1349 a DNS query for a AAAA record for H2 to the recursive name
1352 2. The recursive DNS server resolves the query, and returns the
1353 answer to H1. Because there are no AAAA records in the global
1354 DNS for H2, the answer is empty.
1356 3. The stub resolver at H1 then queries for an A record for H2 and
1357 gets back an A record containing the IPv4 address 192.0.2.1. The
1358 DNS64 function within H1 then synthesizes a AAAA record. The
1359 IPv6 address in the AAAA record contains the prefix assigned to
1360 the IPv6/IPv4 translator in the upper 96 bits, then the received
1361 IPv4 address i.e. the resulting IPv6 address is 64:FF9B::
1364 4. H1 sends a packet towards H2. The packet is sent to the
1365 destination address 64:FF9B::192.0.2.1.
1367 5. The packet is routed to the IPv6 interface of the IPv6/IPv4
1368 translator and the subsequent communication flows using the IPv6/
1369 IPv4 translator mechanisms.
1371 7.3. Example of IPv6-Internet-to-an-IPv4-network setup DNS64 in DNS
1374 In this example, we consider an IPv6 node located in the IPv6
1375 Internet that initiates a communication to an IPv4 node located in
1378 In some cases, this scenario can be addressed without using any form
1379 of DNS64 function. This is so because it is possible to assign a
1380 fixed IPv6 address to each of the IPv4 nodes. Such an IPv6 address
1381 would be constructed using the address transformation algorithm
1382 defined in [I-D.ietf-behave-address-format] that takes as input the
1383 Pref64::/96 and the IPv4 address of the IPv4 node. Note that the
1384 IPv4 address can be a public or a private address; the latter does
1385 not present any additional difficulty, since an NSP must be used as
1386 Pref64::/96 (in this scenario the usage of the Well-Known prefix is
1387 not supported as discussed in [I-D.ietf-behave-address-format]).
1388 Once these IPv6 addresses have been assigned to represent the IPv4
1389 nodes in the IPv6 Internet, real AAAA RRs containing these addresses
1390 can be published in the DNS under the site's domain. This is the
1391 recommended approach to handle this scenario, because it does not
1392 involve synthesizing AAAA records at the time of query.
1394 However, there are some more dynamic scenarios, where synthesizing
1395 AAAA RRs in this setup may be needed. In particular, when DNS Update
1399 Bagnulo, et al. Expires April 4, 2011 [Page 25]
1401 Internet-Draft DNS64 October 2010
1404 [RFC2136] is used in the IPv4 site to update the A RRs for the IPv4
1405 nodes, there are two options: One option is to modify the DNS server
1406 that receives the dynamic DNS updates. That would normally be the
1407 authoritative server for the zone. So the authoritative zone would
1408 have normal AAAA RRs that are synthesized as dynamic updates occur.
1409 The other option is modify all the authoritative servers to generate
1410 synthetic AAAA records for a zone, possibly based on additional
1411 constraints, upon the receipt of a DNS query for the AAAA RR. The
1412 first option -- in which the AAAA is synthesized when the DNS update
1413 message is received, and the data published in the relevant zone --
1414 is recommended over the second option (i.e. the synthesis upon
1415 receipt of the AAAA DNS query). This is because it is usually easier
1416 to solve problems of misconfiguration when the DNS responses are not
1417 being generated dynamically. However, it may be the case where the
1418 primary server (that receives all the updates) cannot be upgraded for
1419 whatever reason, but where a secondary can be upgraded in order to
1420 handle the (comparatively small amount) of AAAA queries. In such
1421 case, it is possible to use the DNS64 as described next. The DNS64
1422 behavior that we describe in this section covers the case of
1423 synthesizing the AAAA RR when the DNS query arrives.
1425 The scenario for this case is depicted in the following figure:
1428 +-----------+ +----------------------+
1430 | IPv6 | +------------+ | +----+ |
1431 | Internet |----| IPv6/IPv4 |--|---| H2 | |
1432 | | | Translator | | +----+ |
1433 | | +------------+ | |
1435 | | +------------+ | |
1436 | |----| Name server|--| |
1437 | | | with DNS64 | | |
1438 +-----------+ +------------+ | |
1441 | H1 | +----------------------+
1444 Figure 6: IPv6-Internet-to-an-IPv4-network setup DNS64 in DNS server
1447 The figure shows an IPv6 node H1 and an IPv4 node H2 with IPv4
1448 address 192.0.2.1 and FQDN h2.example.com.
1450 The IPv6/IPv4 Translator is using a NSP 2001:DB8::/96 to create IPv6
1451 representations of IPv4 addresses. The same prefix is configured in
1455 Bagnulo, et al. Expires April 4, 2011 [Page 26]
1457 Internet-Draft DNS64 October 2010
1460 the DNS64 function in the local name server. The name server that
1461 implements the DNS64 function is the authoritative name server for
1464 The steps by which H1 establishes communication with H2 are:
1466 1. H1 does a DNS lookup for h2.example.com. H1 does this by sending
1467 a DNS query for a AAAA record for H2. The query is eventually
1468 forwarded to the server in the IPv4 site.
1470 2. The local DNS server resolves the query (locally), and discovers
1471 that there are no AAAA records for H2.
1473 3. The name server verifies that h2.example.com and its A RR are
1474 among those that the local policy defines as allowed to generate
1475 a AAAA RR from. If that is the case, the name server synthesizes
1476 a AAAA record from the A RR and the prefix 2001:DB8::/96. The
1477 IPv6 address in the AAAA record is 2001:DB8::192.0.2.1.
1479 4. H1 receives the synthetic AAAA record and sends a packet towards
1480 H2. The packet is sent to the destination address 2001:DB8::
1483 5. The packet is routed through the IPv6 Internet to the IPv6
1484 interface of the IPv6/IPv4 translator and the communication flows
1485 using the IPv6/IPv4 translator mechanisms.
1488 8. Security Considerations
1490 DNS64 operates in combination with the DNS, and is therefore subject
1491 to whatever security considerations are appropriate to the DNS mode
1492 in which the DNS64 is operating (i.e. authoritative, recursive, or
1493 stub resolver mode).
1495 DNS64 has the potential to interfere with the functioning of DNSSEC,
1496 because DNS64 modifies DNS answers, and DNSSEC is designed to detect
1497 such modification and to treat modified answers as bogus. See the
1498 discussion above in Section 3, Section 5.5, and Section 6.2.
1500 Additionally, for the correct functioning of the translation
1501 services, the DNS64 and the NAT64 need to use the same Pref64. If an
1502 attacker manages to change the Pref64 used by the DNS64, the traffic
1503 generated by the host that receives the synthetic reply will be
1504 delivered to the altered Pref64. This can result in either a DoS
1505 attack (if resulting IPv6 addresses are not assigned to any device)
1506 or in a flooding attack (if the resulting IPv6 addresses are assigned
1507 to devices that do not wish to receive the traffic) or in
1511 Bagnulo, et al. Expires April 4, 2011 [Page 27]
1513 Internet-Draft DNS64 October 2010
1516 eavesdropping attack (in case the Pref64 is routed through the
1520 9. IANA Considerations
1522 This memo makes no request of IANA.
1531 dthaler@windows.microsoft.com
1534 11. Acknowledgements
1536 This draft contains the result of discussions involving many people,
1537 including the participants of the IETF BEHAVE Working Group. The
1538 following IETF participants made specific contributions to parts of
1539 the text, and their help is gratefully acknowledged: Jaap Akkerhuis,
1540 Mark Andrews, Jari Arkko, Rob Austein, Timothy Baldwin, Fred Baker,
1541 Doug Barton, Marc Blanchet, Cameron Byrne, Brian Carpenter, Zhen Cao,
1542 Hui Deng, Francis Dupont, Patrik Faltstrom, David Harrington, Ed
1543 Jankiewicz, Peter Koch, Suresh Krishnan, Martti Kuparinen, Ed Lewis,
1544 Xing Li, Bill Manning, Matthijs Mekking, Hiroshi Miyata, Simon
1545 Perrault, Teemu Savolainen, Jyrki Soini, Dave Thaler, Mark Townsley,
1546 Rick van Rein, Stig Venaas, Magnus Westerlund, Jeff Westhead, Florian
1547 Weimer, Dan Wing, Xu Xiaohu, Xiangsong Cui.
1549 Marcelo Bagnulo and Iljitsch van Beijnum are partly funded by
1550 Trilogy, a research project supported by the European Commission
1551 under its Seventh Framework Program.
1556 12.1. Normative References
1558 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
1559 Requirement Levels", BCP 14, RFC 2119, March 1997.
1561 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
1562 STD 13, RFC 1034, November 1987.
1567 Bagnulo, et al. Expires April 4, 2011 [Page 28]
1569 Internet-Draft DNS64 October 2010
1572 [RFC1035] Mockapetris, P., "Domain names - implementation and
1573 specification", STD 13, RFC 1035, November 1987.
1575 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation
1576 (NAT) Behavioral Requirements for Unicast UDP", BCP 127,
1577 RFC 4787, January 2007.
1579 [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)",
1580 RFC 2671, August 1999.
1582 [I-D.ietf-behave-address-format]
1583 Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X.
1584 Li, "IPv6 Addressing of IPv4/IPv6 Translators",
1585 draft-ietf-behave-address-format-10 (work in progress),
1588 12.2. Informative References
1590 [I-D.ietf-behave-v6v4-xlate-stateful]
1591 Bagnulo, M., Matthews, P., and I. Beijnum, "Stateful
1592 NAT64: Network Address and Protocol Translation from IPv6
1593 Clients to IPv4 Servers",
1594 draft-ietf-behave-v6v4-xlate-stateful-12 (work in
1595 progress), July 2010.
1597 [RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound,
1598 "Dynamic Updates in the Domain Name System (DNS UPDATE)",
1599 RFC 2136, April 1997.
1601 [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS
1602 NCACHE)", RFC 2308, March 1998.
1604 [RFC3484] Draves, R., "Default Address Selection for Internet
1605 Protocol version 6 (IPv6)", RFC 3484, February 2003.
1607 [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi,
1608 "DNS Extensions to Support IP Version 6", RFC 3596,
1611 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
1612 Rose, "DNS Security Introduction and Requirements",
1613 RFC 4033, March 2005.
1615 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
1616 Rose, "Resource Records for the DNS Security Extensions",
1617 RFC 4034, March 2005.
1619 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
1623 Bagnulo, et al. Expires April 4, 2011 [Page 29]
1625 Internet-Draft DNS64 October 2010
1628 Rose, "Protocol Modifications for the DNS Security
1629 Extensions", RFC 4035, March 2005.
1631 [RFC4074] Morishita, Y. and T. Jinmei, "Common Misbehavior Against
1632 DNS Queries for IPv6 Addresses", RFC 4074, May 2005.
1634 [RFC5735] Cotton, M. and L. Vegoda, "Special Use IPv4 Addresses",
1635 BCP 153, RFC 5735, January 2010.
1637 [I-D.ietf-behave-v6v4-framework]
1638 Baker, F., Li, X., Bao, C., and K. Yin, "Framework for
1639 IPv4/IPv6 Translation",
1640 draft-ietf-behave-v6v4-framework-10 (work in progress),
1643 [I-D.ietf-dnsop-default-local-zones]
1644 Andrews, M., "Locally-served DNS Zones",
1645 draft-ietf-dnsop-default-local-zones-14 (work in
1646 progress), September 2010.
1649 Appendix A. Motivations and Implications of synthesizing AAAA Resource
1650 Records when real AAAA Resource Records exist
1652 The motivation for synthesizing AAAA RRs when real AAAA RRs exist is
1653 to support the following scenario:
1655 An IPv4-only server application (e.g. web server software) is
1656 running on a dual-stack host. There may also be dual-stack server
1657 applications running on the same host. That host has fully
1658 routable IPv4 and IPv6 addresses and hence the authoritative DNS
1659 server has an A and a AAAA record.
1661 An IPv6-only client (regardless of whether the client application
1662 is IPv6-only, the client stack is IPv6-only, or it only has an
1663 IPv6 address) wants to access the above server.
1665 The client issues a DNS query to a DNS64 resolver.
1667 If the DNS64 only generates a synthetic AAAA if there's no real AAAA,
1668 then the communication will fail. Even though there's a real AAAA,
1669 the only way for communication to succeed is with the translated
1670 address. So, in order to support this scenario, the administrator of
1671 a DNS64 service may want to enable the synthesis of AAAA RRs even
1672 when real AAAA RRs exist.
1674 The implication of including synthetic AAAA RRs when real AAAA RRs
1675 exist is that translated connectivity may be preferred over native
1679 Bagnulo, et al. Expires April 4, 2011 [Page 30]
1681 Internet-Draft DNS64 October 2010
1684 connectivity in some cases where the DNS64 is operated in DNS server
1687 RFC3484 [RFC3484] rules use longest prefix match to select the
1688 preferred destination address to use. So, if the DNS64 resolver
1689 returns both the synthetic AAAA RRs and the real AAAA RRs, then if
1690 the DNS64 is operated by the same domain as the initiating host, and
1691 a global unicast prefix (called an NSP in
1692 [I-D.ietf-behave-address-format]) is used, then a synthetic AAAA RR
1693 is likely to be preferred.
1695 This means that without further configuration:
1697 In the "An IPv6 network to the IPv4 Internet" scenario, the host
1698 will prefer translated connectivity if an NSP is used. If the
1699 Well-Known Prefix defined in [I-D.ietf-behave-address-format] is
1700 used, it will probably prefer native connectivity.
1702 In the "IPv6 Internet to an IPv4 network" scenario, it is possible
1703 to bias the selection towards the real AAAA RR if the DNS64
1704 resolver returns the real AAAA first in the DNS reply, when an NSP
1705 is used (the Well-Known Prefix usage is not supported in this
1708 In the "An IPv6 network to IPv4 network" scenario, for local
1709 destinations (i.e., target hosts inside the local site), it is
1710 likely that the NSP and the destination prefix are the same, so we
1711 can use the order of RR in the DNS reply to bias the selection
1712 through native connectivity. If the Well-Known Prefix is used,
1713 the longest prefix match rule will select native connectivity.
1715 The problem can be solved by properly configuring the RFC3484
1716 [RFC3484] policy table.
1724 Leganes, Madrid 28911
1727 Phone: +34-91-6249500
1729 Email: marcelo@it.uc3m.es
1730 URI: http://www.it.uc3m.es/marcelo
1735 Bagnulo, et al. Expires April 4, 2011 [Page 31]
1737 Internet-Draft DNS64 October 2010
1742 4922 Fairmont Avenue, Suite 250
1746 Phone: +1 301 961 3131
1747 Email: ajs@shinkuro.com
1756 Phone: +1 613-592-4343 x224
1758 Email: philip_matthews@magma.ca
1762 Iljitsch van Beijnum
1765 Leganes, Madrid 28911
1768 Phone: +34-91-6246245
1769 Email: iljitsch@muada.com
1791 Bagnulo, et al. Expires April 4, 2011 [Page 32]