idnits 2.17.1 draft-wing-behave-dns64-config-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. == There are 2 instances of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 12, 2010) is 5187 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-11) exists of draft-ietf-behave-dns64-05 ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 3484 (Obsoleted by RFC 6724) ** Obsolete normative reference: RFC 4242 (Obsoleted by RFC 8415) == Outdated reference: A later version (-03) exists of draft-arifumi-6man-rfc3484-revise-02 == Outdated reference: A later version (-10) exists of draft-ietf-behave-address-format-04 == Outdated reference: A later version (-12) exists of draft-ietf-behave-ftp64-00 == Outdated reference: A later version (-06) exists of draft-savolainen-mif-dns-server-selection-01 -- Obsolete informational reference (is this intentional?): RFC 2373 (Obsoleted by RFC 3513) Summary: 4 errors (**), 0 flaws (~~), 8 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 BEHAVE Working Group D. Wing 3 Internet-Draft Cisco 4 Intended status: Standards Track February 12, 2010 5 Expires: August 16, 2010 7 DNS64 Resolvers and Dual-Stack Hosts 8 draft-wing-behave-dns64-config-02 10 Abstract 12 Some networks are expected to support IPv4-only, dual-stack, and 13 IPv6-only hosts at the same time. Such networks also want to IPv6/ 14 IPv4 translation for the IPv6-only host so it can access servers on 15 the IPv4 Internet. On such a network, the synthesized AAAA responses 16 from a DNS64 can cause traffic to be translated. This document 17 describes and analyzes several solutions to avoid that translation. 19 Status of this Memo 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- 27 Drafts. 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 August 16, 2010. 42 Copyright Notice 44 Copyright (c) 2010 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 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 3. Procedures to support IPv6-only and dual-stack hosts with 62 DNS64 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 3.1. IPv4-Mapped Address for 'normal' DNS server . . . . . . . 4 64 3.1.1. Host Transition . . . . . . . . . . . . . . . . . . . 4 65 3.1.2. Advantages and Disadvantages . . . . . . . . . . . . . 4 66 3.2. Disable DNS64 Functions in DNS Query . . . . . . . . . . . 5 67 3.2.1. Host Transition . . . . . . . . . . . . . . . . . . . 5 68 3.2.2. Advantages and Disadvantages . . . . . . . . . . . . . 5 69 3.3. New DHCP option for 'normal' DNS server . . . . . . . . . 6 70 3.3.1. Host Transition . . . . . . . . . . . . . . . . . . . 6 71 3.3.2. Advantages and Disadvantages . . . . . . . . . . . . . 6 72 3.4. Modify Host's Address Selection Rules . . . . . . . . . . 6 73 3.4.1. Host Transition . . . . . . . . . . . . . . . . . . . 7 74 3.4.2. Limitations and Advantages . . . . . . . . . . . . . . 7 75 3.4.3. Examples . . . . . . . . . . . . . . . . . . . . . . . 8 76 3.5. Use DHCP to Assign Appropriate DNS Server . . . . . . . . 8 77 3.5.1. Host Requirements . . . . . . . . . . . . . . . . . . 9 78 3.5.2. DHCPv4 and DHCPv6 Server Requirements . . . . . . . . 10 79 3.5.3. DHCP Server Operation . . . . . . . . . . . . . . . . 10 80 3.5.4. Host Transition . . . . . . . . . . . . . . . . . . . 11 81 3.5.5. Advantages and Disadvantages . . . . . . . . . . . . . 12 82 3.6. New DHCP option for DNS64 server . . . . . . . . . . . . . 12 83 3.6.1. Advantages and Disadvantages . . . . . . . . . . . . . 12 84 4. Security Considerations . . . . . . . . . . . . . . . . . . . 12 85 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 86 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 87 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 88 7.1. Normative References . . . . . . . . . . . . . . . . . . . 13 89 7.2. Informative References . . . . . . . . . . . . . . . . . . 14 90 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15 92 1. Introduction 94 In order to access IPv4 servers, an IPv6-only host needs to use an 95 IPv6/IPv4 translator. Typically, the IPv6-only host performs a DNS 96 query to a DNS64 recursive resolver, which synthesizes an AAAA when 97 necessary. However, if a dual-stack host uses that same DNS64 98 recursive resolver and normal address selection rules [RFC3484], the 99 dual-stack host will send traffic through the IPv6/IPv4 translator 100 when such traffic could have been sent using IPv4. Thus, as an 101 optimization, it is desirable that a dual-stack host avoid IPv6/IPv4 102 translation. 104 Note: If the dual-stack host's IPv4 traffic is being NATted the 105 difference is NAT44 versus NAT64, so the performance and scalability 106 concern is nearly identical. However, at least one application 107 breaks when translated between IP address families unless special 108 measures are taken [I-D.ietf-behave-ftp64]. The IETF should decide 109 if it is worthwhile to avoid NAT64 for dual-stack hosts that are 110 connected to a network operating a DNS64. 112 Note: Windows XP can only be configured with IPv4 DNS servers 113 [XP-DNS]. This means a Windows XP host is always dual-stack and 114 requires an IPv4 address in order to send its DNS queries. While 115 it is possible to work around this issue by running BIND on the 116 Windows XP device itself, this is complex. Thus, Windows XP 117 should not be considered a viable operating system to join an 118 IPv6-only network. 120 2. Terminology 122 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 123 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 124 document are to be interpreted as described in [RFC2119]. 126 "IPv4-only" means a host that has only IPv4 address(es) assigned to 127 its interface(s). "Dual-stack" means a host that has an IPv4 address 128 and an IPv6 address assigned to its interface(es). "IPv6-only" means 129 a host that has only IPv6 address(es) assigned to its interface(s). 131 3. Procedures to support IPv6-only and dual-stack hosts with DNS64 133 Several solutions are discussed in this section, in roughly the order 134 of preference (as determined by the author). 136 3.1. IPv4-Mapped Address for 'normal' DNS server 138 It has been observed that some common operating systems, when 139 configured as dual-stack, will successfully use an IPv4-mapped 140 address (and send an IPv4 packet). But when configured as IPv6-only, 141 they will not successfully use an IPv4-mapped address (because they 142 lack an IPv4 address) [experiment]. 144 We could take advantage of this by configuring the 'normal' DNS 145 server using an IPv4-mapped IPv6 address (that is, an IPv6 address 146 starting with ::ffff:/96), and configuring the DNS64 server using a 147 normal IPv6 address. 149 Because [RFC3646] says the DNS servers are used in the order listed, 150 a dual-stack host will use the 'normal' DNS server and an IPv6-only 151 host will be unable to use that 'normal' DNS server and will use the 152 next server on its list. 154 Note: Non-compliant IPv6 stacks might send a packet to the IPv4- 155 mapped IPv6 address (::ffff:c000:0201, using the example below). 156 To deal with such non-compliant IPv6 implementations the network 157 can filter (drop) traffic to that IPv6 address. 159 For example, a dual-stack host and an IPv6-only host would be 160 configured with the following DNS servers, in this order: 162 ::ffff:192.0.2.1 # 'normal' DNS server (usable only by 163 dual-stack host. Not usable by IPv6-only 164 host) 165 2001:0DB8:DDDD::1234 # DNS64 server 167 3.1.1. Host Transition 169 When transitioning from dual-stack to IPv6-only, nothing needs to 170 occur - the higher-priority DNS server (with the IPv4-mapped IPv6 171 address) will become inaccessible and the DNS client will failover to 172 the next-higher priority DNS server (which is the DNS64 server). 174 When transitioning from IPv6-only to dual-stack, nothing 175 automatically causes the host to start querying the 'normal' DNS 176 server. Thus, a host that transitions from IPv6-only to dual-stack 177 will continue to query the DNS64 until the host's stack re- 178 initializes. 180 3.1.2. Advantages and Disadvantages 182 Advantages: 184 o No change to hosts. 186 o On Linux systems, is not effective if the sysctl 187 net.ipv6.bindv6only is set, as this causes dual-stack systems to 188 not send packets to IPv4-mapped IPv6 addresses. 190 Disadvantages: 192 o Seems confusing to configure. 194 o Can we rely on IPv6-only hosts allowing IPv4-mapped IPv6 addresses 195 to be configured as their DNS servers? 197 3.2. Disable DNS64 Functions in DNS Query 199 A dual-stack host does not need synthesized AAAA records, and does 200 not need to use the network's NAT64. So, a dual-stack host could 201 send a DNS query to a DNS64 requesting no synthesized AAAA records. 202 This allows both dual-stack and IPv6-only hosts to be configured with 203 a DNS64. 205 To request no AAAA synthesis, the DNS query sets both the DO bit ("I 206 understand DNSSEC") and the CD bit ("I will do DNSSEC validation"). 207 When the DNS64 receives a query with those bits set, it does not 208 synthesize an AAAA response (because doing so would break DNSSEC 209 validation). 211 3.2.1. Host Transition 213 If host transitions from dual-stack to IPv6-only, it would need to 214 perform its own DNS64 function (which requires it know the prefix of 215 its NAT64) or would have to not set the DO and CD bits in DNS 216 queries. Likewise, if a host transitions from IPv6-only to dual- 217 stack, it needs to know to start sending DNS queries with the DO and 218 CD bits set.s 220 3.2.2. Advantages and Disadvantages 222 Advantages: 224 o Simple 226 Disadvantages: 228 o Requires dual-stack host support DNSSEC validation. 230 o Requires host support Section 3.2.1. 232 o There are security implications if the DNS client is lying and is 233 not, in fact, going to perform its own DNSSEC validation. 235 3.3. New DHCP option for 'normal' DNS server 237 Another approach, which requires modification of dual-stack hosts 238 which want to avoid the DNS64, is to introduce a new DHCP option. 240 This approach feels a little backwards at first. The idea is to 241 support unmodified hosts (which might be dual-stack but might be 242 IPv6-only) by placing DNS64 servers into the normal DHCPv6 option for 243 DNS servers [RFC3646]. Then, place the 'normal' DNS servers into a 244 *new* DHCPv6 option. 246 3.3.1. Host Transition 248 TBD. 250 3.3.2. Advantages and Disadvantages 252 Disadvantages: 254 o If dual-stack hosts want to avoid NAT64, they need to be modified 255 to understand this new DHCP option. If they aren't modified, they 256 will use NAT64. 258 3.4. Modify Host's Address Selection Rules 260 The default address selection rules [RFC3484] prefer IPv6 over IPv4. 261 This means, for a dual-stack host, that IPv6 will be preferred (if 262 available) over IPv4. If a dual-stack host is configured to use a 263 DNS64 server, that DNS64 server will synthesize an AAAA response if 264 there is an A record. Thus, the dual-stack host will always use IPv6 265 if a DNS lookup was involved, even if IPv4 could have been used more 266 optimally. 268 Note: If both a NAT44 and NAT64 are deployed on the same network, 269 roughly the same inefficiency occurs (that is, NAT state is 270 created). However, it is generally considered better to perform 271 NAT44 than NAT64, because NAT64 translates between IP address 272 families which can have side effects (e.g., FTP). 274 To avoid this, the host's default address selection rules [RFC3484] 275 can be modified so that IPv4 is preferred over the IPv6/IPv4 276 translator's prefix. At the same time, native IPv6 can still be 277 preferred over IPv4. This is accomplished by adding the network's 278 IPv6/IPv4 translator's prefix as the lowest Precedence in the address 279 selection rules. 281 If the IPv6/IPv4 translator's prefix is the IANA-assigned well-known 282 prefix (64:FF9B::/96, as assigned in 283 [I-D.ietf-behave-address-format]), this can be hard-coded or easily 284 scripted into the system startup. However, if the IPv6/IPv4 285 translator's prefix is a network-specific prefix (NSP, as described 286 in [I-D.ietf-behave-address-format]), the default address selection 287 rules can be modified only after the host learns its currently- 288 connected network's IPv6/IPv4 translator's prefix (e.g., using 289 [I-D.wing-behave-learn-prefix]). 291 On some operating systems, the address selection rules can be 292 configured using a command line utility (e.g., Windows, FreeBSD), 293 without new software in the host's IP stack. Other operating systems 294 are not as accommodating of this solution (see Section 3.4.2). 296 Note: it may be desirable to create a standard to adjust a host's 297 address selection rules based on the translator's prefix. This is 298 a topic for the IPv6 maintenance working group [6man]. This 299 automatic mechanism may involve modifications to the host's IP 300 stack, depending on how the IETF chooses to standardize such a 301 mechanism. FOR EXAMPLE, it may be useful to consider 302 [I-D.wing-behave-learn-prefix] (which proposes using either DNS or 303 DHCPv6) in conjunction with adjusting the host's address selection 304 rules. 306 3.4.1. Host Transition 308 An IPv6-only and a dual-stack host can both be configured with the 309 same address selection rules (namely, both can add the network's 310 translator as the lowest Precedence). This is because the IPv6-only 311 host will never use IPv4 (because it lacks an IPv4 address) and will 312 thus fall through and use the IPv6 address synthesized by the DNS64 313 containing the IPv6/IPv4 translator's prefix (that is, as shown in 314 the examples, the IPv6-only host will use the Precedence 3 entry in 315 the default policy table). The dual-stack host, if it receives an 316 AAAA response, will prefer use IPv6; if it receives only an A 317 response, it will prefer to use IPv4 (using Precedence 10 for IPv4- 318 mapped addresses defined in Section 2.5.4 of [RFC2373]). 320 3.4.2. Limitations and Advantages 322 The following limitations are observed: 324 o OSX does not implement a [RFC3484] or [RFC3484]-like policy table. 326 o Some applications implement their own address selection rules, 327 effectively ignoring the OS's address selection rules. 329 The following advantages are observed: 331 o Causes IPv4 to be preferred over IPv6/IPv4 translator addresses, 332 even if DNS was not used to obtain the IPv4 or IPv6 address (e.g., 333 applications which do not use DNS). 335 3.4.3. Examples 337 For example, if a network is using the WKP 64:FF9B::/96 338 [I-D.ietf-behave-address-format] and a host is using the new default 339 policy table from [I-D.arifumi-6man-rfc3484-revise] (which added 340 Precedence 5 for Teredo), the host's new policy table would contain 341 one new entry with Precedence 3, as shown below: 343 Prefix Precedence Label 344 ::1/128 50 0 # localhost 345 ::/0 30 2 # IPv6 native 346 2002::/16 20 3 # 6to4 347 ::ffff:0:0/96 10 4 # IPv4-mapped 348 2001::/32 5 5 # Teredo 349 64:FF9B::/96 3 6 # 6/4 translator's prefix 351 As another example, if a network has the prefix 2001:0DB8::/32 and 352 the NAT64 is using the Network-Specific Prefix (NSP) 2001:0DB8: 353 AAAA::/96, and the host is using the new default policy table from 354 [I-D.arifumi-6man-rfc3484-revise] (which added Precedence 5 for 355 Teredo), the host's new policy table would contain one new entry with 356 Precedence 3, as shown below: 358 Prefix Precedence Label 359 ::1/128 50 0 # localhost 360 ::/0 30 2 # IPv6 native 361 2002::/16 20 3 # 6to4 362 ::ffff:0:0/96 10 4 # IPv4-mapped 363 2001::/32 5 5 # Teredo 364 2001:0DB8:AAAA::/96 3 6 # 6/4 translator's prefix 366 3.5. Use DHCP to Assign Appropriate DNS Server 368 Note: due to the limitations of this solution (see 369 Section 3.5.5), it may have little or no value. 371 To avoid unnecessary traffic through a translator, it is desirable to 372 configure IPv4-only and dual-stack hosts with a 'normal' DNS 373 recursive resolver. 375 However, it is necessary to configure IPv6-only hosts with a DNS64 376 [I-D.ietf-behave-dns64] recursive resolver so those hosts can use an 377 IPv6/IPv4 translator and access servers on the IPv4 Internet. 379 It is difficult to provide different DNS servers to those types of 380 hosts, because there is no existing protocol that declares a host is 381 IPv4-only, dual-stack, or IPv6-only. 383 This document describes how a network's DHCPv4 and DHCPv6 servers, 384 combined with a client-identifiers [RFC4361] chosen by the host, can 385 determine if a host is IPv4-only, dual-stack, or IPv6-only, and 386 assign the correct DNS server according to that determination. 388 Note: the DHCP mechanism described in this section have some 389 overlap with the Multiple Interfaces Working Group [mif] and with 390 split-zone DNS [I-D.savolainen-mif-dns-server-selection]. 392 Both an IPv4-only host and a dual-stack host obtain an IPv4 network 393 address. Today, hosts most commonly obtain an IPv4 address using 394 DHCPv4 [RFC2131]. An IPv6-only host does not obtain an IPv4 address; 395 however, it may be using DHCPv6 to obtain other information (e.g., 396 NTP servers). The following procedure takes advantage of that 397 difference to determine if a host is IPv4-only, dual-stack, or IPv6- 398 only. 400 3.5.1. Host Requirements 402 The host has the following requirements: 404 1. if the host uses IPv4, it MUST use DHCPv4 to learn its IPv4 405 address and its DNS server address(es); and, 407 2. if the host uses IPv6, it MUST use DHCPv6 to learn its IPv6 DNS 408 resolver, using the Information-Request message described in 409 Section 18.1.5 of [RFC3315] and using [RFC3646]; and, 411 3. the host MUST use client-identifiers [RFC4361] to identify itself 412 to its DHCP server(s), and MUST use the same client-identifier 413 for both DHCPv4 and DHCPv6 415 Note: This last requirement is stronger than the SHOULD in 416 Section 6.2 of [RFC4361] 418 If the host does not support DHCP authentication, and acquires/ 419 releases its IPv4 address while keeping its IPv6 address, it MUST 420 support the procedure described in Section 3.5.4; and, 422 4. the host MUST support the DHCP Information Refresh Time Option 423 [RFC4242]. 425 3.5.2. DHCPv4 and DHCPv6 Server Requirements 427 The DHCPv4 and DHCPv6 servers have the following requirements: 429 1. the DHCPv4 and DHCPv6 servers MUST be able to communicate with 430 each other both client-identifiers [RFC4361] and if an IPv4 431 address is assigned to that client-identifier; and, 433 2. If the DHCP server and the host support DHCP authentication, the 434 DHCP server MUST support the procedure described in 435 Section 3.5.4. 437 3. MUST support the DHCP Information Refresh Time Option [RFC4242]. 439 3.5.3. DHCP Server Operation 441 If the DHCP server first receives a DHCPv4 request for a particular 442 client-identifier, it responds with the 'normal' DNS resolver. The 443 DHCPv6 server remembers that RFC4361 client identity and if the 444 DHCPv6 server sees a DHCPv6 request from that same client identity, 445 it responds to the DHCPv6 request with a 'normal' DNS resolver. 447 If the DHCP server first receives a DHCPv6 request for a particular 448 client-identifier, it responds with a short information refresh time 449 [RFC4242] (e.g., 30 seconds) and a DNS64 recursive resolver. 451 Note-1: This means that during the short information refresh 452 time, both a dual-stack host and an IPv6-only will have their DNS 453 queries processed by the DNS64 recursive resolver. During that 454 time, both the dual-stack host and the IPv6-only host will get 455 connectivity to IPv4 servers, but the dual-stack host will use the 456 IPv6/IPv4 translator until the information refresh time expires. 458 Note-2: for discussion: Consider have DHCP server slightly delay 459 (e.g., 100ms) responding to a DHCPv6 request. This gives a chance 460 for the DHCPv4 request to be received, thus avoiding the issue 461 described in Note-1. 463 After the short information refresh time, the DHCPv6 client will send 464 a new request. By that time, the DHCPv6 server will have either: 466 a. have seen a DHCPv4 request from the same RFC4361 host. This 467 indicates the host supports dual-stack. The DHCP server should 468 extend the DHCPv6 lease, and provide a 'normal' DNS server 469 (instead of the DNS64 server). 471 b. have not seen a DHCPv4 request from the same RFC4361 host. This 472 indicates the host is IPv6-only. The DHCP server should extend 473 the DHCPv6 lease and continue providing the same DNS64 server. 475 3.5.4. Host Transition 477 During natural evolution of a network or because of debugging/ 478 troubleshooting, a host might transition between IPv4-only, dual- 479 stack, or IPv6-only. When the host acquires or releases its IPv4 480 address it transitions to needing a different DNS server; if the host 481 has an IPv4 address, it needs a 'normal' DNS server and if it does 482 not have an IPv4 address it needs a DNS64 server. 484 There are two transitions considered, where the host transitions: 486 1. from IPv6-only to IPv4-supporting (that is, IPv4-only or dual- 487 stack), 489 2. from IPv4-supporting (that is, IPv4-only or dual-stack) to IPv6- 490 only. 492 When doing (1), the DHCPv4 server will provide a 'normal' DNS server 493 (because the DHCPv4 server sees the same client-identifier as seen by 494 the DHCPv6 server). So case (1) is solved. 496 However, when doing (2), the host is giving up its IPv4 address and 497 is currently using a normal DNS server, but needs to be told to use a 498 DNS64 server instead. There are two mechanisms to provide that 499 function, based on the network and host's support of DHCP 500 authentication (Section 19.1.1 of [RFC3315]) 502 1. with DHCP authentication: When a certain client identifier loses 503 or acquires its IPv4 address and also has an IPv6 address, the 504 DHCPv6 server MUST send a DHCP RECONFIGURE message [RFC3315] to 505 the host and SHOULD include the Option Request option indicating 506 the DNS server information has changed. The RECONFIGURE message 507 triggers the host to send a new Information-Request message to 508 the DHCPv6 server. 510 2. without DHCP authentication: the host, when keeping its IPv6 511 address and releasing its IPv4 address, MUST also issue a new 512 DHCPv6 Information-Request message to the DHCPv6 server. 514 In both cases, the Information-Request message causes the DHCPv6 515 server to reply with a DNS64 recursive resolver, as discussed in 516 Section 3.5.2. 518 3.5.5. Advantages and Disadvantages 520 Advantages: 522 o Dual-stack applications, which perform DNS lookups, will 523 effectively avoid NAT64 when using the 'normal' DNS server. 525 Disadvantages: 527 o A network with mixed IPv4-only/dual-stack hosts and IPv6-only 528 hosts needs to have a mix of DNS configurations for those hosts. 529 Thus, mechanisms that advertise the same DNS servers to all hosts 530 cannot be used on such networks (e.g., IPv6 router 531 advertisements). 533 o If separate networks operate DHCPv4 and DHCPv6 (e.g., as with 534 Dual-Stack Lite where the ISP operates DHCPv4 and the customer 535 premise router operates DHCPv6), it is likely impossible for the 536 DHCPv4 and DHCPv6 servers to communicate necessary information 537 with each other. 539 o Windows does not support [RFC4361]. 541 o OSX does not support DHCPv6. 543 3.6. New DHCP option for DNS64 server 545 Another approach, which requires modification of IPv6-only hosts 546 which need to use the DNS64, is to introduce a new DHCP option. 548 The idea is to support unmodified dual-stack hosts (which use the 549 normal DNS server provided via [RFC3646]), but to modify IPv6-only 550 hosts to look for the DNS64 server in a newly-defined DHCPv6 option. 552 3.6.1. Advantages and Disadvantages 554 Disadvantages: 556 o Requires modifying IPv6-only hosts, and without this modification 557 they won't work at all with a DNS64. 559 4. Security Considerations 561 TBD. 563 5. Acknowledgements 565 Thanks to Mohamed Boucadair, Marcelo Braun, Ralph Droms, Dave Thaler, 566 Bernie Volz, and Andrew Yourtchenko for their review comments. 568 This document was produced using version 1.35pre1 of XML2RFC. 570 6. IANA Considerations 572 This document has no actions for IANA. 574 7. References 576 7.1. Normative References 578 [I-D.ietf-behave-dns64] 579 Bagnulo, M., Sullivan, A., Matthews, P., and I. Beijnum, 580 "DNS64: DNS extensions for Network Address Translation 581 from IPv6 Clients to IPv4 Servers", 582 draft-ietf-behave-dns64-05 (work in progress), 583 December 2009. 585 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 586 Requirement Levels", BCP 14, RFC 2119, March 1997. 588 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 589 RFC 2131, March 1997. 591 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 592 and M. Carney, "Dynamic Host Configuration Protocol for 593 IPv6 (DHCPv6)", RFC 3315, July 2003. 595 [RFC3484] Draves, R., "Default Address Selection for Internet 596 Protocol version 6 (IPv6)", RFC 3484, February 2003. 598 [RFC3646] Droms, R., "DNS Configuration options for Dynamic Host 599 Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, 600 December 2003. 602 [RFC4242] Venaas, S., Chown, T., and B. Volz, "Information Refresh 603 Time Option for Dynamic Host Configuration Protocol for 604 IPv6 (DHCPv6)", RFC 4242, November 2005. 606 [RFC4361] Lemon, T. and B. Sommerfeld, "Node-specific Client 607 Identifiers for Dynamic Host Configuration Protocol 608 Version Four (DHCPv4)", RFC 4361, February 2006. 610 7.2. Informative References 612 [6man] IETF, "IPv6 Maintenance Working Group", 2009, 613 . 615 [I-D.arifumi-6man-rfc3484-revise] 616 Matsumoto, A., Fujisaki, T., and R. Hiromi, "Things To Be 617 Considered for RFC 3484 Revision", 618 draft-arifumi-6man-rfc3484-revise-02 (work in progress), 619 October 2009. 621 [I-D.ietf-behave-address-format] 622 Huitema, C., Bao, C., Bagnulo, M., Boucadair, M., and X. 623 Li, "IPv6 Addressing of IPv4/IPv6 Translators", 624 draft-ietf-behave-address-format-04 (work in progress), 625 January 2010. 627 [I-D.ietf-behave-ftp64] 628 Beijnum, I., "IPv6-to-IPv4 translation FTP 629 considerations", draft-ietf-behave-ftp64-00 (work in 630 progress), December 2009. 632 [I-D.savolainen-mif-dns-server-selection] 633 Savolainen, T., "DNS Server Selection on Multi-Homed 634 Hosts", draft-savolainen-mif-dns-server-selection-01 (work 635 in progress), October 2009. 637 [I-D.wing-behave-learn-prefix] 638 Wing, D., "Learning the IPv6 Prefix of a Network's IPv6/ 639 IPv4 Translator", draft-wing-behave-learn-prefix-04 (work 640 in progress), October 2009. 642 [RFC2373] Hinden, R. and S. Deering, "IP Version 6 Addressing 643 Architecture", RFC 2373, July 1998. 645 [XP-DNS] Microsoft, "Windows XP: IPv6 configuration items", 5 2005, 646 . 649 [experiment] 650 Braun, "practical issues with using v4-mapped addresses 651 for nat64", Jul 2008, . 654 [mif] IETF, "Multiple Interfaces Working Group", 2009, 655 . 657 Author's Address 659 Dan Wing 660 Cisco Systems, Inc. 661 170 West Tasman Drive 662 San Jose, CA 95134 663 USA 665 Email: dwing@cisco.com