6 Intended status: Standards Track A. Sullivan
7 Expires: April 22, 2010 Shinkuro
15 DNS64: DNS extensions for Network Address Translation from IPv6 Clients
17 draft-ietf-behave-dns64-01
21 This Internet-Draft is submitted to IETF in full conformance with the
22 provisions of BCP 78 and BCP 79.
24 Internet-Drafts are working documents of the Internet Engineering
25 Task Force (IETF), its areas, and its working groups. Note that
26 other groups may also distribute working documents as Internet-
29 Internet-Drafts are draft documents valid for a maximum of six months
30 and may be updated, replaced, or obsoleted by other documents at any
31 time. It is inappropriate to use Internet-Drafts as reference
32 material or to cite them other than as "work in progress."
34 The list of current Internet-Drafts can be accessed at
35 http://www.ietf.org/ietf/1id-abstracts.txt.
37 The list of Internet-Draft Shadow Directories can be accessed at
38 http://www.ietf.org/shadow.html.
40 This Internet-Draft will expire on April 22, 2010.
44 Copyright (c) 2009 IETF Trust and the persons identified as the
45 document authors. All rights reserved.
47 This document is subject to BCP 78 and the IETF Trust's Legal
48 Provisions Relating to IETF Documents in effect on the date of
49 publication of this document (http://trustee.ietf.org/license-info).
50 Please review these documents carefully, as they describe your rights
51 and restrictions with respect to this document.
55 Bagnulo, et al. Expires April 22, 2010 [Page 1]
57 Internet-Draft DNS64 October 2009
62 DNS64 is a mechanism for synthesizing AAAA records from A records.
63 DNS64 is used with an IPv6/IPv4 translator to enable client-server
64 communication between an IPv6-only client and an IPv4-only server,
65 without requiring any changes to either the IPv6 or the IPv4 node,
66 for the class of applications that work through NATs. This document
67 specifies DNS64, and provides suggestions on how it should be
68 deployed in conjunction with IPv6/IPv4 translators.
73 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
74 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
75 3. Background to DNS64 - DNSSEC interaction . . . . . . . . . . . 6
76 4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 8
77 5. DNS64 Normative Specification . . . . . . . . . . . . . . . . 9
78 5.1. Resolving AAAA queries and the answer section . . . . . . 9
79 5.1.1. The answer when there is AAAA data available . . . . . 9
80 5.1.2. The answer when there is an error . . . . . . . . . . 9
81 5.1.3. Data for the answer when performing synthesis . . . . 9
82 5.1.4. Performing the synthesis . . . . . . . . . . . . . . . 10
83 5.1.5. Querying in parallel . . . . . . . . . . . . . . . . . 11
84 5.2. Generation of the IPv6 representations of IPv4
85 addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
86 5.3. Handling other RRs . . . . . . . . . . . . . . . . . . . . 12
87 5.3.1. PTR queries . . . . . . . . . . . . . . . . . . . . . 12
88 5.3.2. Handling the additional section . . . . . . . . . . . 13
89 5.3.3. Other records . . . . . . . . . . . . . . . . . . . . 13
90 5.4. Assembling a synthesized response to a AAAA query . . . . 14
91 5.5. DNSSEC processing: DNS64 in recursive server mode . . . . 14
92 5.6. DNS64 and multihoming . . . . . . . . . . . . . . . . . . 15
93 6. Deployment notes . . . . . . . . . . . . . . . . . . . . . . . 16
94 6.1. DNS resolvers and DNS64 . . . . . . . . . . . . . . . . . 16
95 6.2. DNSSEC validators and DNS64 . . . . . . . . . . . . . . . 16
96 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16
97 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 16
98 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
99 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
100 10.1. Normative References . . . . . . . . . . . . . . . . . . . 17
101 10.2. Informative References . . . . . . . . . . . . . . . . . . 18
102 Appendix A. Deployment scenarios and examples . . . . . . . . . . 20
103 A.1. Embed and Zero-Pad algorithm description . . . . . . . . . 21
104 A.2. An-IPv6-network-to-IPv4-Internet setup with DNS64 in
105 DNS server mode . . . . . . . . . . . . . . . . . . . . . 22
106 A.3. An-IPv6-network-to-IPv4-Internet setup with DNS64 in
107 stub-resolver mode . . . . . . . . . . . . . . . . . . . . 23
111 Bagnulo, et al. Expires April 22, 2010 [Page 2]
113 Internet-Draft DNS64 October 2009
116 A.4. IPv6-Internet-to-an-IPv4-network setup DNS64 in DNS
117 server mode . . . . . . . . . . . . . . . . . . . . . . . 25
118 Appendix B. Motivations and Implications of synthesizing AAAA
119 RR when real AAAA RR exists . . . . . . . . . . . . . 27
120 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28
167 Bagnulo, et al. Expires April 22, 2010 [Page 3]
169 Internet-Draft DNS64 October 2009
174 This document specifies DNS64, a mechanism that is part of the
175 toolbox for IPv6-IPv4 transition and co-existence. DNS64, used
176 together with an IPv6/IPv4 translator such as NAT64
177 [I-D.bagnulo-behave-nat64], allows an IPv6-only client to initiate
178 communications by name to an IPv4-only server.
180 DNS64 is a mechanism for synthesizing AAAA resource records (RRs)
181 from A RRs. A synthetic AAAA RR created by the DNS64 from an
182 original A RR contains the same FQDN of the original A RR but it
183 contains an IPv6 address instead of an IPv4 address. The IPv6
184 address is an IPv6 representation of the IPv4 address contained in
185 the original A RR. The IPv6 representation of the IPv4 address is
186 algorithmically generated from the IPv4 address returned in the A RR
187 and a set of parameters configured in the DNS64 (typically, an IPv6
188 prefix used by IPv6 representations of IPv4 addresses and optionally
191 Together with a IPv6/IPv4 translator, these two mechanisms allow an
192 IPv6-only client to initiate communications to an IPv4-only server
193 using the FQDN of the server.
195 These mechanisms are expected to play a critical role in the IPv4-
196 IPv6 transition and co-existence. Due to IPv4 address depletion, it
197 is likely that in the future, many IPv6-only clients will want to
198 connect to IPv4-only servers. In the typical case, the approach only
199 requires the deployment of IPv6/IPv4 translators that connect an
200 IPv6-only network to an IPv4-only network, along with the deployment
201 of one or more DNS64-enabled name servers. However, some advanced
202 features require performing the DNS64 function directly by the end-
208 This section provides a non-normative introduction to the DNS64
211 We assume that we have an IPv6/IPv4 translator box connecting an IPv4
212 network and an IPv6 network. The IPv6/IPv4 translator device
213 provides translation services between the two networks enabling
214 communication between IPv4-only hosts and IPv6-only hosts. (NOTE: By
215 IPv6-only hosts we mean hosts running IPv6-only applications, hosts
216 that can only use IPv6, as well as the cases where only IPv6
217 connectivity is available to the client. By IPv4-only servers we
218 mean servers running IPv4-only applications, servers that can only
219 use IPv4, as well as the cases where only IPv4 connectivity is
223 Bagnulo, et al. Expires April 22, 2010 [Page 4]
225 Internet-Draft DNS64 October 2009
228 available to the server). The IPv6/IPv4 translator used in
229 conjunction with DNS64 must allow communications initiated from the
230 IPv6-only host to the IPv4-only host.
232 To allow an IPv6 initiator to do a standard AAAA RR DNS lookup to
233 learn the address of the responder, DNS64 is used to synthesize a
234 AAAA record from an A record containing a real IPv4 address of the
235 responder, whenever the DNS64 service cannot retrieve a AAAA record
236 for the requested host name. The DNS64 device appears as a regular
237 recursive resolver for the IPv6 initiator. The DNS64 box receives an
238 AAAA DNS query generated by the IPv6 initiator. It first attempts a
239 recursive resolution for the requested AAAA records. If there is no
240 AAAA record available for the target node (which is the normal case
241 when the target node is an IPv4-only node), DNS64 performs a query
242 for A records. If any A records are discovered, DNS64 creates a
243 synthetic AAAA RR from the information retrieved in each A RR.
245 The FQDN of a synthetic AAAA RR is the same as that of the original A
246 RR, but an IPv6 representation of the IPv4 address contained in the
247 original A RR is included in the AAAA RR. The IPv6 representation of
248 the IPv4 address is algorithmically generated from the IPv4 address
249 and additional parameters configured in the DNS64. Among those
250 parameters configured in the DNS64, there is at least one IPv6
251 prefix, called Pref64::/n. The IPv6 address representing IPv4
252 addresses included in the AAAA RR synthesized by the DNS64 function
253 contain Pref64::/n and they also embed the original IPv4 address.
255 The same algorithm and the same Pref64::/n prefix or prefixes must be
256 configured both in the DNS64 device and the IPv6/IPv4 translator, so
257 that both can algorithmically generate the same IPv6 representation
258 for a given IPv4 address. In addition, it is required that IPv6
259 packets addressed to an IPv6 destination that contains the Pref64::/n
260 be delivered to the IPv6/IPv4 translator, so they can be translated
263 Once the DNS64 has synthesized the AAAA RR, the synthetic AAAA RR is
264 passed back to the IPv6 initiator, which will initiate an IPv6
265 communication with the IPv6 address associated with the IPv4
266 receiver. The packet will be routed to the IPv6/IPv4 translator
267 which will forward it to the IPv4 network .
269 In general, the only shared state between the DNS64 and the IPv6/IPv4
270 translator is the Pref64::/n and an optional set of static
271 parameters. The Pref64::/n and the set of static parameters must be
272 configured to be the same on both; there is no communication between
273 the DNS64 device and IPv6/IPv4 translator functions. The mechanism
274 to be used for configuring the parameters of the DNS64 is beyond the
279 Bagnulo, et al. Expires April 22, 2010 [Page 5]
281 Internet-Draft DNS64 October 2009
284 The DNS64 function can be performed in two places.
286 One option is to locate the DNS64 function in recursive name
287 servers serving end hosts. In this case, when an IPv6-only host
288 queries the name server for AAAA RRs for an IPv4-only host, the
289 name server can perform the synthesis of AAAA RRs and pass them
290 back to the IPv6 only initiator. The main advantage of this mode
291 is that current IPv6 nodes can use this mechanism without
292 requiring any modification. This mode is called "DNS64 in DNS
295 The other option is to place the DNS64 function in the end hosts
296 themselves, coupled to the local stub resolver. In this case, the
297 stub resolver will try to obtain (real) AAAA RRs and in case they
298 are not available, the DNS64 function will synthesize AAAA RRs for
299 internal usage. This mode is compatible with some advanced
300 functions like DNSSEC validation in the end host. The main
301 drawback of this mode is its deployability, since it requires
302 changes in the end hosts. This mode is called "DNS64 in stub-
306 3. Background to DNS64 - DNSSEC interaction
308 DNSSEC presents a special challenge for DNS64, because DNSSEC is
309 designed to detect changes to DNS answers, and DNS64 may alter
310 answers coming from an authoritative server.
312 A recursive resolver can be security-aware or security-oblivious.
313 Moreover, a security-aware recursive name server can be validating or
314 non-validating, according to operator policy. In the cases below,
315 the recursive server is also performing DNS64, and has a local policy
316 to validate. We call this general case vDNS64, but in all the cases
317 below the DNS64 functionality should be assumed needed.
319 DNSSEC includes some signaling bits that offer some indicators of
320 what the query originator understands.
322 If a query arrives at a vDNS64 device with the DO bit set, the query
323 originator is signaling that it understands DNSSEC. The DO bit does
324 not indicate that the query originator will validate the response.
325 It only means that the query originator can understand responses
326 containing DNSSEC data. Conversely, if the DO bit is clear, that is
327 evidence that the querying agent is not aware of DNSSEC.
329 If a query arrives at a vDNS64 device with the CD bit set, it is an
330 indication that the querying agent wants all the validation data so
331 it can do checking itself. By local policy, vDNS64 could still
335 Bagnulo, et al. Expires April 22, 2010 [Page 6]
337 Internet-Draft DNS64 October 2009
340 validate, but it must return all data to the querying agent anyway.
342 Here are the possible cases:
344 1. A security-oblivious DNS64 node receives a query with the DO bit
345 clear. In this case, DNSSEC is not a concern, because the
346 querying agent does not understand DNSSEC responses.
348 2. A security-oblivious DNS64 node receives a query with the DO bit
349 set, and the CD bit clear. This is just like the case of a non-
350 DNS64 case: the server doesn't support it, so the querying agent
353 3. A security-aware and non-validating DNS64 node receives a query
354 with the DO bit set and the CD bit clear. Such a resolver is not
355 validating responses, likely due to local policy (see [RFC4035],
356 section 4.2). For that reason, this case amounts to the same as
357 the previous case, and no validation happens.
359 4. A security-aware and non-validating DNS64 node receives a query
360 with the DO bit set and the CD bit set. In this case, the
361 resolver is supposed to pass on all the data it gets to the query
362 initiator (see section 3.2.2 of [RFC4035]). This case will be
363 problematic with DNS64. If the DNS64 server modifies the record,
364 the client will get the data back and try to validate it, and the
365 data will be invalid as far as the client is concerned.
367 5. A security-aware and validating DNS64 node receives a query with
368 the DO bit clear and CD clear. In this case, the resolver
369 validates the data. If it fails, it returns RCODE 2 (SERVFAIL);
370 otherwise, it returns the answer. This is the ideal case for
371 vDNS64. The resolver validates the data, and then synthesizes
372 the new record and passes that to the client. The client, which
373 is presumably not validating (else it would have set DO and CD),
374 cannot tell that DNS64 is involved.
376 6. A security-aware and validating DNS64 node receives a query with
377 the DO bit set and CD clear. In principle, this ought to work
378 like the previous case, except that the resolver should also set
379 the AD bit on the response.
381 7. A security-aware and validating DNS64 node receives a query with
382 the DO bit set and CD set. This is effectively the same as the
383 case where a security-aware and non-validating recursive resolver
384 receives a similar query, and the same thing will happen: the
385 downstream validator will mark the data as invalid if DNS64 has
391 Bagnulo, et al. Expires April 22, 2010 [Page 7]
393 Internet-Draft DNS64 October 2009
398 This section provides definitions for the special terms used in the
401 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
402 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
403 document are to be interpreted as described in RFC 2119 [RFC2119].
405 Authoritative server: A DNS server that can answer authoritatively a
408 DNS64: A logical function that synthesizes DNS resource records (e.g
409 AAAA records containing IPv6 addresses) from DNS resource records
410 actually contained in the global DNS (e.g. A records containing
413 DNS64 recursor: A recursive resolver that provides the DNS64
414 functionality as part of its operation.
416 Recursive resolver: A DNS server that accepts requests from one
417 resolver, and asks another resolver for the answer on behalf of
418 the first resolver. In the context of this document, "the
419 recursive resolver" means a recursive resolver immediately next in
420 the DNS resolution chain from an end point. The end point usually
421 has only a stub resolver available.[[anchor5: I can't actually
422 remember why we needed the sentences following "In the context of
423 this document. . ." Unless someone has a reason, I'll take it
424 out. --ajs@shinkuro.com]]
426 Synthetic RR: A DNS resource record (RR) that is not contained in
427 any zone data file, but has been synthesized from other RRs. An
428 example is a synthetic AAAA record created from an A record.
430 Stub resolver: A resolver with minimum functionality, typically for
431 use in end points that depend on a recursive resolver. Most end
432 points on the Internet as of this writing use stub
433 resolvers.[[anchor6: Do we need this in the document? I don't
434 think so. 1034 defines this term. --ajs@shinkuro.com]]
436 IPv6/IPv4 translator: A device that translates IPv6 packets to IPv4
437 packets and vice-versa. It is only required that the
438 communication initiated from the IPv6 side be supported.
440 For a detailed understanding of this document, the reader should also
441 be familiar with DNS terminology from [RFC1034],[RFC1035] and current
442 NAT terminology from [RFC4787]. Some parts of this document assume
443 familiarity with the terminology of the DNS security extensions
447 Bagnulo, et al. Expires April 22, 2010 [Page 8]
449 Internet-Draft DNS64 October 2009
452 outlined in [RFC4035].
455 5. DNS64 Normative Specification
457 A DNS64 is a logical function that synthesizes AAAA records from A
458 records. The DNS64 function may be implemented in a stub resolver,
459 in a recursive resolver, or in an authoritative name server.
461 The implementation SHOULD support mapping of IPv4 address ranges to
462 separate IPv6 prefixes for AAAA record synthesis. This allows
463 handling of special use IPv4 addresses [I-D.iana-rfc3330bis].
464 Multicast address handling is further specified in
465 [I-D.venaas-behave-mcast46].
467 5.1. Resolving AAAA queries and the answer section
469 When the DNS64 receives a query for RRs of type AAAA and class IN, it
470 first attempts to retrieve non-synthetic RRs of this type and class,
471 either by performing a query or, in the case of an authoritative
472 server, by examining its own results.
474 5.1.1. The answer when there is AAAA data available
476 If the query results in one or more AAAA records in the answer
477 section, the result is returned to the requesting client as per
478 normal DNS semantics (except in the case where the AAAA falls in the
479 ::ffff/96 network; see below for treatment of that network). In this
480 case, DNS64 SHOULD NOT include synthetic AAAA RRs in the response
481 (see Appendix B for an analysis of the motivations for and the
482 implications of not complying with this recommendation). By default
483 DNS64 implementations MUST NOT synthesize AAAA RRs when real AAAA RRs
486 5.1.2. The answer when there is an error
488 If the query results in a response with an error code other than 0,
489 the result is handled according to normal DNS operation -- that is,
490 either the resolver tries again using a different server from the
491 authoritative NS RRSet, or it returns the error to the client. This
492 stage is still prior to any synthesis having happened, so a response
493 to be returned to the client does not need any special assembly than
494 would usually happen in DNS operation.
496 5.1.3. Data for the answer when performing synthesis
498 If the query results in no error but an empty answer section in the
499 response, the DNS64 resolver attempts to retrieve A records for the
503 Bagnulo, et al. Expires April 22, 2010 [Page 9]
505 Internet-Draft DNS64 October 2009
508 name in question. If this new A RR query results in an empty answer
509 or in an error, then the empty result or error is used as the basis
510 for the answer returned to the querying client. (Transient errors
511 may result in retrying the query, depening on the operation of the
512 resolver; this is just as in Section 5.1.2.) If instead the query
513 results in one or more A RRs, the DNS64 synthesizes AAAA RRs based on
514 the A RRs according to the procedure outlined in Section 5.1.4. The
515 DNS64 resolver then returns the synthesized AAAA records in the
516 answer section to the client, removing the A records that form the
517 basis of the synthesis.
519 As an exception to the general rule about always returning the AAAA
520 records if they are returned in the answer, AAAA records with
521 addresses in the ::ffff/96 network are treated just like the case
522 where there is neither an error nor an empty answer section. This is
523 because a real IPv6-only node will not be any more able to reach the
524 addresses in ::ffff/96 than it is able to reach an IPv4 address
525 without assistance. An implementation MAY use the address in
526 ::ffff/96 as the basis of synthesis without querying for an A record,
527 by using the last 32 bits of the address provided in the AAAA record.
528 [[anchor10: I changed this to say "neither. . .nor" because the
529 previous version suggested that it would return the error-or-empty-
530 answer to the querying client, and that can't be right. Correct?
533 5.1.4. Performing the synthesis
535 A synthetic AAAA record is created from an A record as follows:
537 o The NAME field is set to the NAME field from the A record
539 o The TYPE field is set to 28 (AAAA)
541 o The CLASS field is set to 1 (IN)
543 o The TTL field is set to the minimum of the TTL of the original A
544 RR and the SOA RR for the queried domain. (Note that in order to
545 obtain the TTL of the SOA RR the DNS64 does not need to perform a
546 new query, but it can remember the TTL from the SOA RR in the
547 negative response to the AAAA query).
549 o The RDLENGTH field is set to 16
551 o The RDATA field is set to the IPv6 representation of the IPv4
552 address from the RDATA field of the A record. The DNS64 SHOULD
553 check each A RR against IPv4 address ranges and select the
554 corresponding IPv6 prefix to use in synthesizing the AAAA RR. See
555 Section 5.2 for discussion of the algorithms to be used in
559 Bagnulo, et al. Expires April 22, 2010 [Page 10]
561 Internet-Draft DNS64 October 2009
564 effecting the transformation.
566 5.1.5. Querying in parallel
568 DNS64 MAY perform the query for the AAAA RR and for the A RR in
569 parallel, in order to minimize the delay. However, this would result
570 in performing unnecessary A RR queries in the case no AAAA RR
571 synthesis is required. A possible trade-off would be to perform them
572 sequentially but with a very short interval between them, so if we
573 obtain a fast reply, we avoid doing the additional query. (Note that
574 this discussion is relevant only if the DNS64 function needs to
575 perform external queries to fetch the RR. If the needed RR
576 information is available locally, as in the case of an authoritative
577 server, the issue is no longer relevant.)
579 5.2. Generation of the IPv6 representations of IPv4 addresses
581 DNS64 supports multiple algorithms for the generation of the IPv6
582 representation of an IPv4 address. The constraints imposed on the
583 generation algorithms are the following:
585 The same algorithm to create an IPv6 address from an IPv4 address
586 MUST be used by both the DNS64 to create the IPv6 address to be
587 returned in the synthetic AAAA RR from the IPv4 address contained
588 in original A RR, and by the IPv6/IPv4 translator to create the
589 IPv6 address to be included in the destination address field of
590 the outgoing IPv6 packets from the IPv4 address included in the
591 destination address field of the incoming IPv4 packet.
593 The algorithm MUST be reversible, i.e. it MUST be possible to
594 extract the original IPv4 address from the IPv6 representation.
596 The input for the algorithm MUST be limited to the IPv4 address,
597 the IPv6 prefix (denoted Pref64::/n) used in the IPv6
598 representations and optionally a set of stable parameters that are
599 configured in the DNS64 (such as fixed string to be used as a
602 If we note n the length of the prefix Pref64::/n, then n MUST
603 the less or equal than 96. If a Pref64::/n is configured
604 through any means in the DNS64 (such as manually configured, or
605 other automatic mean not specified in this document), the
606 default algorithm MUST use this prefix. If no prefix is
607 available, the algorithm MUST use the Well-Known prefix TBD1
608 defined in [I-D.thaler-behave-translator-addressing]
610 [[anchor12: Note in document: TBD1 in the passage above is to be
611 substituted by whatever prefix is assigned by IANA to be the well-
615 Bagnulo, et al. Expires April 22, 2010 [Page 11]
617 Internet-Draft DNS64 October 2009
622 DNS64 MUST support the following algorithms for generating IPv6
623 representations of IPv4 addresses defined in
624 [I-D.thaler-behave-translator-addressing]:
626 Zero-Pad And Embed, defined in section 3.2.3 of
627 [I-D.thaler-behave-translator-addressing]
629 Compensation-Pad And Embed, defined in section of 3.2.4 of
630 [I-D.thaler-behave-translator-addressing]
632 Embed And Zero-Pad, defined in section of 3.2.5 of
633 [I-D.thaler-behave-translator-addressing]
635 Preconfigured Mapping Table, defined in section of 3.2.6 of
636 [I-D.thaler-behave-translator-addressing]
638 The default algorithm used by DNS64 must be Embed and Zero-Pad.
639 While the normative description of the algorithms is provided in
640 [I-D.thaler-behave-translator-addressing], an sample description of
641 the algorithm and its application to different scenarios is provided
642 in Appendix A for illustration purposes.
644 5.3. Handling other RRs
648 If a DNS64 nameserver receives a PTR query for a record in the
649 IP6.ARPA domain, it MUST strip the IP6.ARPA labels from the QNAME,
650 reverse the address portion of the QNAME according to the encoding
651 scheme outlined in section 2.5 of [RFC3596] , and examine the
652 resulting address to see whether its prefix matches the locally-
653 configured Pref64::/n. There are two alternatives for a DNS64
654 nameserver to respond to such PTR queries. A DNS64 node MUST provide
655 one of these, and SHOULD NOT provide both at the same time unless
656 different IP6.ARPA zones require answers of different sorts.
658 The first option is for the DNS64 nameserver to respond
659 authoritatively for its prefixes. If the address prefix matches any
660 Pref64::/n used in the site, either a LIR prefix or a well-known
661 prefix used for NAT64 as defined in
662 [I-D.thaler-behave-translator-addressing], then the DNS64 server MAY
663 answer the query using locally-appropriate RDATA. The DNS64 server
664 MAY use the same RDATA for all answers. Note that the requirement is
665 to match any Pref64::/n used at the site, and not merely the locally-
666 configured Pref64::/n. This is because end clients could ask for a
667 PTR record matching an address received through a different (site-
671 Bagnulo, et al. Expires April 22, 2010 [Page 12]
673 Internet-Draft DNS64 October 2009
676 provided) DNS64, and if this strategy is in effect, those queries
677 should never be sent to the global DNS. The advantage of this
678 strategy is that it makes plain to the querying client that the
679 prefix is one operated by the DNS64 site, and that the answers the
680 client is getting are generated by the DNS64. The disadvantage is
681 that any useful reverse-tree information that might be in the global
682 DNS is unavailable to the clients querying the DNS64.
684 The second option is for the DNS64 nameserver to synthesize a CNAME
685 mapping the IP6.ARPA namespace to the corresponding IN-ADDR.ARPA
686 name. The rest of the response would be the normal DNS processing.
687 The CNAME can be signed on the fly if need be. The advantage of this
688 approach is that any useful information in the reverse tree is
689 available to the querying client. The disadvantage is that it adds
690 additional load to the DNS64 (because CNAMEs have to be synthesized
691 for each PTR query that matches the Pref64::/n), and that it may
692 require signing on the fly. [[anchor15: what are we supposed to do
693 here when the in-addr.arpa zone is unmaintained, as it may be. If
694 there is no data at the target name, then we'll get a CNAME with a
695 map to an empty namespace, I think? Isn't that bad?
698 If the address prefix does not match any of the Pref64::/n, then the
699 DNS64 server MUST process the query as though it were any other query
700 -- i.e. a recursive nameserver MUST attempt to resolve the query as
701 though it were any other (non-A/AAAA) query, and an authoritative
702 server MUST respond authoritatively or with a referral, as
705 5.3.2. Handling the additional section
707 DNS64 synthesis MUST NOT be performed on any records in the
708 additional section of synthesized answers. The DNS64 MUST pass the
709 additional section unchanged.
711 [[anchor16: We had some discussion, as an alternative to the above,
712 of allowing the DNS64 to truncate the additional section completely,
713 on the grounds that the additional section could break mixed-mode
714 iterative/forwarding resolvers that happen to end up behind DNS64.
715 Nobody else seemed to like that plan, so I haven't included it.
720 If the DNS64 is in recursive resolver mode, then it SHOULD also serve
721 the zones specified in [I-D.ietf-dnsop-default-local-zones], rather
722 than forwarding those queries elsewhere to be handled.
727 Bagnulo, et al. Expires April 22, 2010 [Page 13]
729 Internet-Draft DNS64 October 2009
732 All other RRs MUST be returned unchanged.
734 5.4. Assembling a synthesized response to a AAAA query
736 The DNS64 uses different pieces of data to build the response
737 returned to the querying client.
739 The query that is used as the basis for synthesis results either in
740 an error, an answer that can be used as a basis for synthesis, or an
741 empty (authoritative) answer. If there is an empty answer, then the
742 DNS64 responds to the original querying client with the answer the
743 DNS64 received to the original AAAA query. Otherwise, the response
744 is assembled as follows.
746 The header fields are set according to the usual rules for recursive
747 or authoritative servers, depending on the role that the DNS64 is
748 serving. The question section is copied from the original AAAA
749 query. The answer section is populated according to the rules in
750 Section 5.1.4. The authority section is copied from the response to
751 the A query that the DNS64 performed. The additional section is
752 populated according to the rules in Section 5.3.2.
754 [[anchor18: The cross-reference to how to do the additional section
755 can be removed, and replaced by "copied from the response to the A
756 query that the DNS64 performed" if we don't want to allow the DNS64
757 to truncate the additional section. See the note above. If I hear
758 no more feedback on this topic, then I'll make this change in the
759 next version. --ajs@shinkuro.com]]
761 5.5. DNSSEC processing: DNS64 in recursive server mode
763 We consider the case where the recursive server that is performing
764 DNS64 also has a local policy to validate the answers according to
765 the procedures outlined in [RFC4035] Section 5. We call this general
768 The vDNS64 uses the presence of the DO and CD bits to make some
769 decisions about what the query originator needs, and can react
772 1. If CD is not set and DO is not set, vDNS64 SHOULD perform
773 validation and do synthesis as needed.
775 2. If CD is not set and DO is set, then vDNS64 SHOULD perform
776 validation. Whenever vDNS64 performs validation, it MUST
777 validate the negative answer for AAAA queries before proceeding
778 to query for A records for the same name, in order to be sure
779 that there is not a legitimate AAAA record on the Internet.
783 Bagnulo, et al. Expires April 22, 2010 [Page 14]
785 Internet-Draft DNS64 October 2009
788 Failing to observe this step would allow an attacker to use DNS64
789 as a mechanism to circumvent DNSSEC. If the negative response
790 validates, and the response to the A query validates, then the
791 vDNS64 MAY perform synthesis and SHOULD set the AD bit in the
792 answer to the client. This is acceptable, because [RFC4035],
793 section 3.2.3 says that the AD bit is set by the name server side
794 of a security-aware recursive name server if and only if it
795 considers all the RRSets in the Answer and Authority sections to
796 be authentic. In this case, the name server has reason to
797 believe the RRSets are all authentic, so it SHOULD set the AD
798 bit. If the data does not validate, the vDNS64 MUST respond with
799 RCODE=2 (server failure).
800 A security-aware end point might take the presence of the AD bit
801 as an indication that the data is valid, and may pass the DNS
802 (and DNSSEC) data to an application. If the application attempts
803 to validate the synthesized data, of course, the validation will
804 fail. One could argue therefore that this approach is not
805 desirable. But security aware stub resolvers MUST NOT place any
806 reliance on data received from resolvers and validated on their
807 behalf without certain criteria established by [RFC4035], section
808 4.9.3. An application that wants to perform validation on its
809 own should use the CD bit.
811 3. If the CD bit is set and DO is set, then vDNS64 MAY perform
812 validation, but MUST NOT perform synthesis. It MUST hand the
813 data back to the query initiator, just like a regular recursive
814 resolver, and depend on the client to do the validation and the
816 The disadvantage to this approach is that an end point that is
817 translation-oblivious but security-aware and validating will not
818 be able to use the DNS64 functionality. In this case, the end
819 point will not have the desired benefit of NAT64. In effect,
820 this strategy means that any end point that wishes to do
821 validation in a NAT64 context must be upgraded to be translation-
824 5.6. DNS64 and multihoming
826 Synthetic AAAA records may be constructed on the basis of the network
827 context in which they were constructed. Therefore, a synthetic AAAA
828 received from one interface MUST NOT be used to resolve hosts via
829 another network interface. [[anchor21: This seems to be the result of
830 the discussion on-list starting with message id 18034D4D7FE9AE48BF19A
831 B1B0EF2729F3EF0E69687@NOK-EUMSG-01.mgdnok.nokia.com, but it's pretty
832 strange when stated baldly. In particular, how is the multi-homed
833 host supposed to know that a given AAAA is synthetic?
839 Bagnulo, et al. Expires April 22, 2010 [Page 15]
841 Internet-Draft DNS64 October 2009
846 While DNS64 is intended to be part of a strategy for aiding IPv6
847 deployment in an internetworking environment with some IPv4-only and
848 IPv6-only networks, it is important to realise that it is
849 incompatible with some things that may be deployed in an IPv4-only or
852 6.1. DNS resolvers and DNS64
854 Full-service resolvers that are unaware of the DNS64 function can be
855 (mis)configured to act as mixed-mode iterative and forwarding
856 resolvers. In a native-IPv4 context, this sort of configuration may
857 appear to work. It is impossible to make it work properly without it
858 being aware of the DNS64 function, because it will likely at some
859 point obtain IPv4-only glue records and attempt to use them for
860 resolution. The result that is returned will contain only A records,
861 and without the ability to perform the DNS64 function the resolver
862 will simply be unable to answer the necessary AAAA queries.
864 6.2. DNSSEC validators and DNS64
866 Existing DNSSEC validators (i.e. that are unaware of DNS64) will
867 reject all the data that comes from the DNS64 as having been tampered
868 with. If it is necessary to have validation behind the DNS64, then
869 the validator must know how to perform the DNS64 function itself.
870 Alternatively, the validating host may establish a trusted connection
871 with the DNS64, and allow the DNS64 to do all validation on its
875 7. Security Considerations
877 See the discussion on the usage of DNSSEC and DNS64 described in the
887 dthaler@windows.microsoft.com
895 Bagnulo, et al. Expires April 22, 2010 [Page 16]
897 Internet-Draft DNS64 October 2009
902 This draft contains the result of discussions involving many people,
903 including the participants of the IETF BEHAVE Working Group. The
904 following IETF participants made specific contributions to parts of
905 the text, and their help is gratefully acknowledged: Mark Andrews,
906 Jari Arkko, Rob Austein, Timothy Baldwin, Fred Baker, Marc Blanchet,
907 Cameron Byrne, Brian Carpenter, Hui Deng, Francis Dupont, Ed
908 Jankiewicz, Peter Koch, Suresh Krishnan, Ed Lewis, Xing Li, Matthijs
909 Mekking, Hiroshi Miyata, Simon Perrault, Teemu Savolainen, Jyrki
910 Soini, Dave Thaler, Mark Townsley, Stig Venaas, Magnus Westerlund,
911 Florian Weimer, Dan Wing, Xu Xiaohu.
913 Marcelo Bagnulo and Iljitsch van Beijnum are partly funded by
914 Trilogy, a research project supported by the European Commission
915 under its Seventh Framework Program.
920 10.1. Normative References
922 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
923 Requirement Levels", BCP 14, RFC 2119, March 1997.
925 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
926 STD 13, RFC 1034, November 1987.
928 [RFC1035] Mockapetris, P., "Domain names - implementation and
929 specification", STD 13, RFC 1035, November 1987.
931 [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)",
932 RFC 2671, August 1999.
934 [RFC2672] Crawford, M., "Non-Terminal DNS Name Redirection",
935 RFC 2672, August 1999.
937 [RFC2765] Nordmark, E., "Stateless IP/ICMP Translation Algorithm
938 (SIIT)", RFC 2765, February 2000.
940 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation
941 (NAT) Behavioral Requirements for Unicast UDP", BCP 127,
942 RFC 4787, January 2007.
944 [I-D.ietf-behave-tcp]
945 Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P.
946 Srisuresh, "NAT Behavioral Requirements for TCP",
947 draft-ietf-behave-tcp-08 (work in progress),
951 Bagnulo, et al. Expires April 22, 2010 [Page 17]
953 Internet-Draft DNS64 October 2009
958 [I-D.ietf-behave-nat-icmp]
959 Srisuresh, P., Ford, B., Sivakumar, S., and S. Guha, "NAT
960 Behavioral Requirements for ICMP protocol",
961 draft-ietf-behave-nat-icmp-12 (work in progress),
964 [I-D.thaler-behave-translator-addressing]
965 Thaler, D., "IPv6 Addressing of IPv6/IPv4 Translators",
966 draft-thaler-behave-translator-addressing-00 (work in
967 progress), July 2009.
969 10.2. Informative References
971 [I-D.bagnulo-behave-nat64]
972 Bagnulo, M., Matthews, P., and I. Beijnum, "NAT64: Network
973 Address and Protocol Translation from IPv6 Clients to IPv4
974 Servers", draft-bagnulo-behave-nat64-03 (work in
975 progress), March 2009.
977 [RFC2766] Tsirtsis, G. and P. Srisuresh, "Network Address
978 Translation - Protocol Translation (NAT-PT)", RFC 2766,
981 [RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound,
982 "Dynamic Updates in the Domain Name System (DNS UPDATE)",
983 RFC 2136, April 1997.
985 [RFC1858] Ziemba, G., Reed, D., and P. Traina, "Security
986 Considerations for IP Fragment Filtering", RFC 1858,
989 [RFC3128] Miller, I., "Protection Against a Variant of the Tiny
990 Fragment Attack (RFC 1858)", RFC 3128, June 2001.
992 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network
993 Address Translator (Traditional NAT)", RFC 3022,
996 [RFC3484] Draves, R., "Default Address Selection for Internet
997 Protocol version 6 (IPv6)", RFC 3484, February 2003.
999 [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi,
1000 "DNS Extensions to Support IP Version 6", RFC 3596,
1003 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
1007 Bagnulo, et al. Expires April 22, 2010 [Page 18]
1009 Internet-Draft DNS64 October 2009
1012 Rose, "DNS Security Introduction and Requirements",
1013 RFC 4033, March 2005.
1015 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
1016 Rose, "Resource Records for the DNS Security Extensions",
1017 RFC 4034, March 2005.
1019 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
1020 Rose, "Protocol Modifications for the DNS Security
1021 Extensions", RFC 4035, March 2005.
1023 [RFC4966] Aoun, C. and E. Davies, "Reasons to Move the Network
1024 Address Translator - Protocol Translator (NAT-PT) to
1025 Historic Status", RFC 4966, July 2007.
1027 [I-D.iana-rfc3330bis]
1028 Cotton, M. and L. Vegoda, "Special Use IPv4 Addresses",
1029 draft-iana-rfc3330bis-06 (work in progress),
1032 [I-D.ietf-mmusic-ice]
1033 Rosenberg, J., "Interactive Connectivity Establishment
1034 (ICE): A Protocol for Network Address Translator (NAT)
1035 Traversal for Offer/Answer Protocols",
1036 draft-ietf-mmusic-ice-19 (work in progress), October 2007.
1038 [I-D.ietf-6man-addr-select-sol]
1039 Matsumoto, A., Fujisaki, T., Hiromi, R., and K. Kanayama,
1040 "Solution approaches for address-selection problems",
1041 draft-ietf-6man-addr-select-sol-01 (work in progress),
1044 [RFC3498] Kuhfeld, J., Johnson, J., and M. Thatcher, "Definitions of
1045 Managed Objects for Synchronous Optical Network (SONET)
1046 Linear Automatic Protection Switching (APS)
1047 Architectures", RFC 3498, March 2003.
1049 [I-D.wing-behave-learn-prefix]
1050 Wing, D., Wang, X., and X. Xu, "Learning the IPv6 Prefix
1051 of an IPv6/IPv4 Translator",
1052 draft-wing-behave-learn-prefix-02 (work in progress),
1055 [I-D.miyata-behave-prefix64]
1056 Miyata, H. and M. Bagnulo, "PREFIX64 Comparison",
1057 draft-miyata-behave-prefix64-02 (work in progress),
1063 Bagnulo, et al. Expires April 22, 2010 [Page 19]
1065 Internet-Draft DNS64 October 2009
1068 [I-D.venaas-behave-mcast46]
1069 Venaas, S., "An IPv4 - IPv6 multicast translator",
1070 draft-venaas-behave-mcast46-00 (work in progress),
1073 [I-D.ietf-dnsop-default-local-zones]
1074 Andrews, M., "Locally-served DNS Zones",
1075 draft-ietf-dnsop-default-local-zones-08 (work in
1076 progress), February 2009.
1079 Appendix A. Deployment scenarios and examples
1081 In this section, we first provide a description of the default
1082 address transformation algorithm and then we walk through some sample
1083 scenarios that are expected to be common deployment cases. It should
1084 be noted that is provided for illustrative purposes and this section
1085 is not normative. The normative definition of DNS64 is provided in
1086 Section 5 and the normative definition of the address transformation
1087 algorithm is provided in [I-D.thaler-behave-translator-addressing].
1089 There are two main different setups where DNS64 is expected to be
1090 used (other setups are possible as well, but these two are the main
1091 ones identified at the time of this writing).
1093 One possible setup that is expected to be common is the case of an
1094 end site or an ISP that is providing IPv6-only connectivity or
1095 connectivity to IPv6-only hosts that wants to allow the
1096 communication from these IPv6-only connected hosts to the IPv4
1097 Internet. This case is called An-IPv6-network-to-IPv4-Internet.
1098 In this case, the IPv6/IPv4 Translator is used to connect the end
1099 site or the ISP to the IPv4 Internet and the DNS64 function is
1100 provided by the end site or the ISP.
1102 The other possible setup that is expected is an IPv4 site that
1103 wants that its IPv4 servers to be reachable from the IPv6
1104 Internet. This case is called IPv6-Internet-to-an-IPv4-network.
1105 It should be noted that the IPv4 addresses used in the IPv4 site
1106 can be either public or private. In this case, the IPv6/IPv4
1107 Translator is used to connect the IPv4 end site to the IPv6
1108 Internet and the DNS64 function is provided by the end site
1111 In this section we illustrate how the DNS64 behaves in the different
1112 scenarios that are expected to be common. We consider then 3
1113 possible scenarios, namely:
1119 Bagnulo, et al. Expires April 22, 2010 [Page 20]
1121 Internet-Draft DNS64 October 2009
1124 1. An-IPv6-network-to-IPv4-Internet setup with DNS64 in DNS server
1127 2. An-IPv6-network-to-IPv4-Internet setup with DNS64 in stub-
1130 3. IPv6-Internet-to-an-IPv4-network setup with DNS64 in DNS server
1133 The notation used is the following: upper case letters are IPv4
1134 addresses; upper case letters with a prime(') are IPv6 addresses;
1135 lower case letters are ports; prefixes are indicated by "P::X", which
1136 is an IPv6 address built from an IPv4 address X by adding the prefix
1137 P, mappings are indicated as "(X,x) <--> (Y',y)".
1139 A.1. Embed and Zero-Pad algorithm description
1141 In this section we describe the default algorithm for the generation
1142 of IPv6 address from IPv4 address to be implemented in the DNS64.
1144 The only parameter required by the default algorithm is an IPv6
1145 prefix. This prefix is used to map IPv4 addresses into IPv6
1146 addresses, and is denoted Pref64. If we note n the length of the
1147 prefix Pref64, then n must the less or equal than 96. If an Pref64
1148 is configured through any means in the DNS64 (such as manually
1149 configured, or other automatic mean not specified in this document),
1150 the default algorithm must use this prefix. If no prefix is
1151 available the algorithm must use the Well-Know prefix (include here
1152 the prefix to be assigned by IANA) defined in
1153 [I-D.thaler-behave-translator-addressing]
1155 The input for the algorithm are:
1159 The IPv6 prefix: Pref64::/n
1161 The IPv6 address is generated by concatenating the prefix Pref64::/n,
1162 the IPv4 address X and optionally (in case n is strictly smaller than
1163 96) an all-zero suffix. So, the resulting IPv6 address would be
1168 We next describe the reverse algorithm of the algorithm described in
1169 the previous section. This algorithm allows to generate and IPv4
1170 address from an IPv6 address. This reverse algorithm is NOT
1171 implemented by the DNS64 but it is implemented in the IPv6/IPv4
1175 Bagnulo, et al. Expires April 22, 2010 [Page 21]
1177 Internet-Draft DNS64 October 2009
1180 translator that is serving the same domain the DNS64.
1182 The only parameter required by the default algorithm is an IPv6
1183 prefix. This prefix is the one originally used to map IPv4 addresses
1184 into IPv6 addresses, and is denoted Pref64.
1186 The input for the algorithm are:
1188 The IPv6 address: X'
1190 The IPv6 prefix: Pref64::/n
1192 First, the algorithm checks that the fist n bits of the IPv6 address
1193 X' match with the prefix Pref64::/n i.e. verifies that Pref64::/n =
1196 If this is not the case, the algorithm ends and no IPv4 address is
1199 If the verification is successful, then the bits between the n+1
1200 and the n+32 of the IPv6 address X' are extracted to form the IPv4
1203 A.2. An-IPv6-network-to-IPv4-Internet setup with DNS64 in DNS server
1206 In this example, we consider an IPv6 node located in an IPv6-only
1207 site that initiates a communication to an IPv4 node located in the
1210 The scenario for this case is depicted in the following figure:
1213 +---------------------------------------+ +-----------+
1214 |IPv6 site +-------------+ |IP Addr: | |
1215 | +----+ | Name server | +-------+ T | IPv4 |
1216 | | H1 | | with DNS64 | |64Trans|------| Internet |
1217 | +----+ +-------------+ +-------+ +-----------+
1218 | |IP addr: Y' | | | |IP addr: X
1219 | --------------------------------- | +----+
1220 +---------------------------------------+ | H2 |
1223 The figure shows an IPv6 node H1 which has an IPv6 address Y' and an
1224 IPv4 node H2 with IPv4 address X.
1226 A IPv6/IPv4 Translator connects the IPv6 network to the IPv4
1227 Internet. This IPv6/IPv4 Translator has a prefix (called Pref64::/n)
1231 Bagnulo, et al. Expires April 22, 2010 [Page 22]
1233 Internet-Draft DNS64 October 2009
1236 an IPv4 address T assigned to its IPv4 interface.
1238 The other element involved is the local name server. The name server
1239 is a dual-stack node, so that H1 can contact it via IPv6, while it
1240 can contact IPv4-only name servers via IPv4.
1242 The local name server needs to know the prefix assigned to the local
1243 IPv6/IPv4 Translator (Pref64::/n). For the purpose of this example,
1244 we assume it learns this through manual configuration.
1246 For this example, assume the typical DNS situation where IPv6 hosts
1247 have only stub resolvers, and always query a name server that
1248 performs recursive lookups (henceforth called "the recursive
1251 The steps by which H1 establishes communication with H2 are:
1253 1. H1 does a DNS lookup for FQDN(H2). H1 does this by sending a DNS
1254 query for an AAAA record for H2 to the recursive name server.
1255 The recursive name server implements DNS64 functionality.
1257 2. The recursive name server resolves the query, and discovers that
1258 there are no AAAA records for H2.
1260 3. The recursive name server queries for an A record for H2 and gets
1261 back an A record containing the IPv4 address X. The name server
1262 then synthesizes an AAAA record. The IPv6 address in the AAAA
1263 record contains the prefix assigned to the IPv6/IPv4 Translator
1264 in the upper n bits then the IPv4 address X and then an all-zero
1265 padding i.e. the resulting IPv6 address is Pref64:X::
1267 4. H1 receives the synthetic AAAA record and sends a packet towards
1268 H2. The packet is sent from a source transport address of (Y',y)
1269 to a destination transport address of (Pref64:X::,x), where y and
1270 x are ports chosen by H2.
1272 5. The packet is routed to the IPv6 interface of the IPv6/IPv4
1273 Translator and the subsequent communication flows by means of the
1274 IPv6/IPv4 Translator mechanisms.
1276 A.3. An-IPv6-network-to-IPv4-Internet setup with DNS64 in stub-resolver
1279 The scenario for this case is depicted in the following figure:
1287 Bagnulo, et al. Expires April 22, 2010 [Page 23]
1289 Internet-Draft DNS64 October 2009
1292 +---------------------------------------+ +-----------+
1293 |IPv6 site +-------+ |IP addr: | |
1294 | +---------------+ | Name | +-------+ T | IPv4 |
1295 | | H1 with DNS64 | | Server| |64Trans|------| Internet |
1296 | +---------------+ +-------+ +-------+ +-----------+
1297 | |IP addr: Y' | | | |IP addr: X
1298 | --------------------------------- | +----+
1299 +---------------------------------------+ | H2 |
1302 The figure shows an IPv6 node H1 which has an IPv6 address Y' and an
1303 IPv4 node H2 with IPv4 address X. Node H1 is implementing the DNS64
1306 A IPv6/IPv4 Translator connects the IPv6 network to the IPv4
1307 Internet. This IPv6/IPv4 Translator has a prefix (called Pref64::/n)
1308 and an IPv4 address T assigned to its IPv4 interface.
1310 H1 needs to know the prefix assigned to the local IPv6/IPv4
1311 Translator (Pref64::/n). For the purpose of this example, we assume
1312 it learns this through manual configuration.
1314 Also shown is a name server. For the purpose of this example, we
1315 assume that the name server is a dual-stack node, so that H1 can
1316 contact it via IPv6, while it can contact IPv4-only name servers via
1319 For this example, assume the typical situation where IPv6 hosts have
1320 only stub resolvers and always query a name server that provides
1321 recursive lookups (henceforth called "the recursive name server").
1322 The recursive name server does not perform the DNS64 function.
1324 The steps by which H1 establishes communication with H2 are:
1326 1. H1 does a DNS lookup for FQDN(H2). H1 does this by sending a DNS
1327 query for a AAAA record for H2 to the recursive name server.
1329 2. The recursive DNS server resolves the query, and returns the
1330 answer to H1. Because there are no AAAA records in the global
1331 DNS for H2, the answer is empty.
1333 3. The stub resolver at H1 then queries for an A record for H2 and
1334 gets back an A record containing the IPv4 address X. The DNS64
1335 function within H1 then synthesizes a AAAA record. The IPv6
1336 address in the AAAA record contains the prefix assigned to the
1337 IPv6/IPv4 Translator in the upper n bits, then the IPv4 address X
1338 and then an all-zero padding i.e. the resulting IPv6 address is
1343 Bagnulo, et al. Expires April 22, 2010 [Page 24]
1345 Internet-Draft DNS64 October 2009
1348 4. H1 sends a packet towards H2. The packet is sent from a source
1349 transport address of (Y',y) to a destination transport address of
1350 (Pref64:X::,x), where y and x are ports chosen by H2.
1352 5. The packet is routed to the IPv6 interface of the IPv6/IPv4
1353 Translator and the subsequent communication flows using the IPv6/
1354 IPv4 Translator mechanisms.
1356 A.4. IPv6-Internet-to-an-IPv4-network setup DNS64 in DNS server mode
1358 In this example, we consider an IPv6 node located in the IPv6
1359 Internet site that initiates a communication to a IPv4 node located
1362 This scenario can be addressed without using any form of DNS64
1363 function. This is so because it is possible to assign a fixed IPv6
1364 address to each of the IPv4 servers. Such an IPv6 address would be
1365 constructed as the Pref64::/n concatenated with the IPv4 address of
1366 the IPv4 server and an all-zero padding. Note that the IPv4 address
1367 can be a public or a private address; the latter does not present any
1368 additional difficulty, since the LIR prefix must be used a Pref64 (in
1369 this scenario the usage of the WK prefix is not supported). Once
1370 these IPv6 addresses have been assigned to represent the IPv4 servers
1371 in the IPv6 Internet, real AAAA RRs containing these addresses can be
1372 published in the DNS under the site's domain. This is the
1373 recommended approach to handle this scenario, because it does not
1374 involve synthesizing AAAA records at the time of query. Such a
1375 configuration is easier to troubleshoot in the event of problems,
1376 because it always provides the same answer to every query.
1378 However, there are some more dynamic scenarios, where synthesizing
1379 AAAA RRs in this setup may be needed. In particular, when DNS Update
1380 [RFC2136] is used in the IPv4 site to update the A RRs for the IPv4
1381 servers, there are two options: One option is to modify the server
1382 that receives the dynamic DNS updates. That would normally be the
1383 authoritative server for the zone. So the authoritative zone would
1384 have normal AAAA RRs that are synthesized as dynamic updates occur.
1385 The other option is modify the authoritative server to generate
1386 synthetic AAAA records for a zone, possibly based on additional
1387 constraints, upon the receipt of a DNS query for the AAAA RR. The
1388 first option -- in which the AAAA is synthesized when the DNS update
1389 message is received, and the data published in the relevant zone --
1390 is recommended over the second option (i.e. the synthesis upon
1391 receipt of the AAAA DNS query). This is because it is usually easier
1392 to solve problems of misconfiguration and so on when the DNS
1393 responses are not being generated dynamically. For completeness, the
1394 DNS64 behavior that we describe in this section covers the case of
1395 synthesizing the AAAA RR when the DNS query arrives. Nevertheless,
1399 Bagnulo, et al. Expires April 22, 2010 [Page 25]
1401 Internet-Draft DNS64 October 2009
1404 such a configuration is NOT RECOMMENDED. Troubleshooting
1405 configurations that change the data depending on the query they
1406 receive is notoriously hard, and the IPv4/IPv6 translation scenario
1407 is complicated enough without adding additional opportunities for
1408 possible malfunction.
1410 The scenario for this case is depicted in the following figure:
1413 +-----------+ +----------------------------------------+
1414 | | | IPv4 site +-------------+ |
1415 | IPv6 | +-------+ +----+ | Name server | |
1416 | Internet |------|64Trans| | H2 | | with DNS64 | |
1417 +-----------+ +-------+ +----+ +-------------+ |
1418 |IP addr: Y' | | |IP addr: X | |
1419 +----+ | ----------------------------------- |
1420 | H1 | +----------------------------------------+
1423 The figure shows an IPv6 node H1 which has an IPv6 address Y' and an
1424 IPv4 node H2 with IPv4 address X.
1426 A IPv6/IPv4 Translator connects the IPv4 network to the IPv6
1427 Internet. This IPv6/IPv4 Translator has a prefix (called
1430 Also shown is the authoritative name server for the local domain with
1431 DNS64 functionality. For the purpose of this example, we assume that
1432 the name server is a dual-stack node, so that H1 or a recursive
1433 resolver acting on the request of H1 can contact it via IPv6, while
1434 it can be contacted by IPv4-only nodes to receive dynamic DNS updates
1437 The local name server needs to know the prefix assigned to the local
1438 IPv6/IPv4 Translator (Pref64::/n). For the purpose of this example,
1439 we assume it learns this through manual configuration.
1441 The steps by which H1 establishes communication with H2 are:
1443 1. H1 does a DNS lookup for FQDN(H2). H1 does this by sending a DNS
1444 query for an AAAA record for H2. The query is eventually
1445 forwarded to the server in the IPv4 site.
1447 2. The local DNS server resolves the query (locally), and discovers
1448 that there are no AAAA records for H2.
1450 3. The name server verifies that FQDN(H2) and its A RR are among
1451 those that the local policy defines as allowed to generate a AAAA
1455 Bagnulo, et al. Expires April 22, 2010 [Page 26]
1457 Internet-Draft DNS64 October 2009
1460 RR from. If that is the case, the name server synthesizes an
1461 AAAA record from the A RR and the relevant Pref64::/n. The IPv6
1462 address in the AAAA record contains the prefix assigned to the
1463 IPv6/IPv4 Translator in the first n bits and the IPv4 address X
1464 and then an all-zero padding.
1466 4. H1 receives the synthetic AAAA record and sends a packet towards
1467 H2. The packet is sent from a source transport address of (Y',y)
1468 to a destination transport address of (Pref64:X::,x), where y and
1469 x are ports chosen by H2.
1471 5. The packet is routed through the IPv6 Internet to the IPv6
1472 interface of the IPv6/IPv4 Translator and the communication flows
1473 using the IPv6/IPv4 Translator mechanisms.
1476 Appendix B. Motivations and Implications of synthesizing AAAA RR when
1479 The motivation for synthesizing AAAA RR when a real AAAA RR exists is
1480 to support the following scenario:
1482 An IPv4-only server application (e.g. web server software) is
1483 running on a dual-stack host. There may also be dual-stack server
1484 applications also running on the same host. That host has fully
1485 routable IPv4 and IPv6 addresses and hence the authoritative DNS
1486 server has an A and a AAAA record as a result.
1488 An IPv6-only client (regardless of whether the client application
1489 is IPv6-only, the client stack is IPv6-only, or it only has an
1490 IPv6 address) wants to access the above server.
1492 The client issues a DNS query to a DNS64 recursor.
1494 If the DNS64 only generates a synthetic AAAA if there's no real AAAA,
1495 then the communication will fail. Even though there's a real AAAA,
1496 the only way for communication to succeed is with the translated
1497 address. So, in order to support this scenario, the administrator of
1498 a DNS64 service may want to enable the synthesis of AAAA RR even when
1501 The implication of including synthetic AAAA RR when real AAAA RR
1502 exist is that translated connectivity may be preferred over native
1503 connectivity in some cases where the DNS64 is operated in DNS server
1506 RFC3484 [RFC3484] rules use longest prefix match to select which is
1507 the preferred destination address to use. So, if the DNS64 recursor
1511 Bagnulo, et al. Expires April 22, 2010 [Page 27]
1513 Internet-Draft DNS64 October 2009
1516 returns both the synthetic AAAA RR and the real AAAA RR, then if the
1517 DNS64 is operated by the same domain as the initiating host, and a
1518 global unicast prefix (called the LIR prefix as defined in
1519 [I-D.thaler-behave-translator-addressing]) is used, then the
1520 synthetic AAAA RR is likely to be preferred.
1522 This means that without further configuration:
1524 In the case of An IPv6 network to the IPv4 internet, the host will
1525 prefer translated connectivity if LIR prefix is used. If the
1526 Well-Known (WK) prefix defined in
1527 [I-D.thaler-behave-translator-addressing] is used, it will
1528 probably prefer native connectivity.
1530 In the case of the IPv6 Internet to an IPv4 network, it is
1531 possible to bias the selection towards the real AAAA RR if the
1532 DNS64 recursor returns the real AAAA first in the DNS reply, when
1533 the LIR prefix is used (the WK prefix usage is not recommended in
1536 In the case of the IPv6 to IPv4 in the same network, for local
1537 destinations (i.e., target hosts inside the local site), it is
1538 likely that the LIR prefix and the destination prefix are the
1539 same, so we can use the order of RR in the DNS reply to bias the
1540 selection through native connectivity. If a WK prefix is used,
1541 the longest prefix match rule will select native connectivity.
1543 So this option introduces problems in the following cases:
1545 An IPv6 network to the IPv4 internet with the LIR prefix
1547 IPv6 to IPv4 in the same network when reaching external
1548 destinations and the LIR prefix is used.
1550 In any case, the problem can be solved by properly configuring the
1551 RFC3484 [RFC3484] policy table, but this requires effort on the part
1552 of the site operator.
1567 Bagnulo, et al. Expires April 22, 2010 [Page 28]
1569 Internet-Draft DNS64 October 2009
1577 Leganes, Madrid 28911
1580 Phone: +34-91-6249500
1582 Email: marcelo@it.uc3m.es
1583 URI: http://www.it.uc3m.es/marcelo
1588 4922 Fairmont Avenue, Suite 250
1592 Phone: +1 301 961 3131
1593 Email: ajs@shinkuro.com
1602 Phone: +1 613-592-4343 x224
1604 Email: philip_matthews@magma.ca
1608 Iljitsch van Beijnum
1611 Leganes, Madrid 28911
1614 Phone: +34-91-6246245
1615 Email: iljitsch@muada.com
1623 Bagnulo, et al. Expires April 22, 2010 [Page 29]