idnits 2.17.1 draft-savolainen-mif-dns-server-selection-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 private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 26, 2010) is 5174 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) == Unused Reference: 'RFC3315' is defined on line 578, but no explicit reference was found in the text == Outdated reference: A later version (-11) exists of draft-ietf-behave-dns64-06 == Outdated reference: A later version (-15) exists of draft-ietf-mif-problem-statement-01 ** Downref: Normative reference to an Informational draft: draft-ietf-mif-problem-statement (ref. 'I-D.ietf-mif-problem-statement') ** Obsolete normative reference: RFC 2767 (Obsoleted by RFC 6535) ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) == Outdated reference: A later version (-12) exists of draft-ietf-mif-current-practices-00 == Outdated reference: A later version (-03) exists of draft-wing-behave-dns64-config-02 Summary: 4 errors (**), 0 flaws (~~), 7 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force T. Savolainen 3 Internet-Draft Nokia 4 Intended status: Standards Track February 26, 2010 5 Expires: August 30, 2010 7 DNS Server Selection on Multi-Homed Hosts 8 draft-savolainen-mif-dns-server-selection-02 10 Abstract 12 A multi-homed host may receive DNS server configuration information 13 from multiple physical and/or virtual network interfaces. In split 14 DNS scenarios not all DNS servers are able to provide the same 15 information. When the multi-homed host needs to utilize DNS, it has 16 to select which of the servers to contact to. This document 17 describes problems of split DNS for multi-homed hosts and also a 18 method for selecting the DNS server with help of DNS suffix 19 information received dynamically for each network interface. The 20 method is useful in split DNS scenarios where private names are used 21 and where correct DNS server selection is mandatory for successful 22 DNS resolution. 24 Status of this Memo 26 This Internet-Draft is submitted to IETF in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF), its areas, and its working groups. Note that 31 other groups may also distribute working documents as Internet- 32 Drafts. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 The list of current Internet-Drafts can be accessed at 40 http://www.ietf.org/ietf/1id-abstracts.txt. 42 The list of Internet-Draft Shadow Directories can be accessed at 43 http://www.ietf.org/shadow.html. 45 This Internet-Draft will expire on August 30, 2010. 47 Copyright Notice 48 Copyright (c) 2010 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 65 2. Problem description for split DNS with multi-homed hosts . . . 4 66 2.1. Private fully qualified domain names . . . . . . . . . . . 4 67 2.2. Network interface specific IP addresses . . . . . . . . . 5 68 3. DNS server selection procedure . . . . . . . . . . . . . . . . 7 69 3.1. DNS suffixes as hints . . . . . . . . . . . . . . . . . . 8 70 3.1.1. Learning of the DNS suffixes on existing networks . . 8 71 3.1.2. Explicit DNS suffix configuration with DHCP . . . . . 10 72 3.1.3. Changes to DNS resolution procedures . . . . . . . . . 11 73 4. Considerations for network administrators . . . . . . . . . . 12 74 5. Further considerations . . . . . . . . . . . . . . . . . . . . 12 75 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 76 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 77 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 78 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 79 9.1. Normative References . . . . . . . . . . . . . . . . . . . 13 80 9.2. Informative References . . . . . . . . . . . . . . . . . . 14 81 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14 83 1. Introduction 85 A multi-homed host faces several problems over single-homed host as 86 described in [I-D.ietf-mif-problem-statement]. This document studies 87 in detail problems split DNS may cause for multi-homed hosts and for 88 which optimized behaviour should be defined. The problems are mostly 89 the same in IPv4 and IPv6 domains. 91 In the split DNS scenario different DNS servers have different 92 information. Therefore DNS related information, which otherwise 93 could be consider global for a single-homed host, in a multi-homed 94 host has to be handled as local to a network interface. DNS record 95 synthesis, as described in DNS64 [I-D.ietf-behave-dns64] and Bump-In- 96 the-Stack [RFC2767], can be consider as one manifestation of split 97 DNS. 99 An obvious solution for the problem would be for network 100 administrators to cease utilizing any form of split DNS, or have 101 split DNS used only in deployments where hosts are not allowed to 102 multi-home. However, currently split DNS is deployed and multi-homed 103 hosts have to cope with that. 105 If an application is bound to utilize only a specific network 106 interface at a time, it essentially makes the host behave single- 107 interface way for that particular application and avoids the problems 108 of split DNS, if also application's DNS requests are handled strictly 109 with DNS service available in that particular network interface. If 110 all applications in a host are bound to use only single network 111 interface at a time, even if the used network interfaces were 112 different, the problems are generally avoided. Please see MIF 113 current practices [I-D.ietf-mif-current-practices] for more 114 information. The procedure described in chapter 3 applies when 115 applications are allowed to utilize multiple interfaces in parallel. 117 An example of an application that would benefit from multi-homing is 118 a web browser, which commonly accesses many different destinations 119 and should be able to dynamically communicate over different network 120 interfaces. 122 The solution presented in this memo is intended to be fully backwards 123 compatible and one that can be fully ignored by hosts and networks 124 that are not experiencing the described problem scenarios or that 125 does not implement the solution. 127 In deployments where split DNS is used, selection of the correct 128 destination and source addresses for the actual IP connection is 129 crucial, as the resolved destination's IP address may be only usable 130 on the network interface over which it was resolved on. However, the 131 actual IP address selection logic is not at the scope of this 132 document. 134 1.1. Requirements Language 136 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 137 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 138 document are to be interpreted as described in RFC 2119 [RFC2119]. 140 2. Problem description for split DNS with multi-homed hosts 142 This chapter describes two multi-homing related split DNS problem 143 scenarios for which the procedure described in chapter 3 is targeted 144 at. (DISCUSS: Even more more known problem scenarios caused by split 145 DNS for multi-homed hosts?) 147 2.1. Private fully qualified domain names 149 A multi-homed host may be connecting to one or more networks that are 150 using private fully qualified domain names. As an example, the host 151 may have simultaneously open a wireless LAN (WLAN) connection to open 152 Internet, cellular connection to an operator network, and virtual 153 private network (VPN) connection to a corporate network. When an 154 application initiates connection to an FQDN, the host needs to be 155 able to choose the right network interface for making successful DNS 156 query. This is illustrated in figure 1. If the FQDN is for a public 157 name, in figure 1 scenario it could be resolved with any DNS server 158 of any network interface, but if the FQDN would be corporation's or 159 operator's service's private name, the host would need to be able to 160 correctly select the right network interface for DNS procedures, i.e. 161 already before destination's IP address is known. 163 +---------------+ 164 | DNS server w/ | | Corporate 165 +------+ | public + |----| Intranet 166 | | | corporation's | | 167 | |===== VPN =======| private names | | 168 | | +---------------+ +----+ 169 | MIF | | FW | 170 | host | +----+ 171 | | +---------------+ | 172 | |----- WLAN ------| DNS server w/ |----| Public 173 | | | public names | | Internet 174 | | +---------------+ +----+ 175 | | | FW | 176 | | +---------------+ +----+ 177 | |---- cellular ---| DNS server w/ | | 178 +------+ | public + | | Operator 179 | operator's |----| Intranet 180 | private names | | 181 +---------------+ 183 Split DNS and private names illustrated 185 Figure 1 187 2.2. Network interface specific IP addresses 189 In the second problem an FQDN as such is valid and resolvable via 190 different network interfaces, but to different and not necessarily 191 globally reachable IP addresses, as illustrated in figure 2. This is 192 not so much a problem when a host is single-homed, but for multi- 193 homed host this results in additional challenges: the host's source 194 and destination address selection mechanism must ensure the 195 destination's IP address is only used in combination with source IP 196 addresses of the network interface the name was resolved on. 198 +----------------| | 199 +------+ IPv4 | DNS server A |------| IPv4 200 | |-- interface 1 --| saying Peer is | | 201 | | | at: 192.0.2.1 | | 202 | MIF | +----------------+ +------+ 203 | host | | Peer | 204 | | +----------------+ +------+ 205 | | IPv4 | DNS server B | | 206 | |-- interface 2 --| saying Peer is | | 207 +------+ | at: 10.0.0.1 |------| IPv4 208 +----------------+ | 210 Split DSN and different IP addresses for an FQDN on interfaces 1 and 211 2. 213 Figure 2 215 Similar situation can happen when IPv6 protocol translation is used 216 in combination with AAAA record synthesis proceduce 217 [I-D.ietf-behave-dns64]. A synthesised AAAA record is guaranteed to 218 be valid only on a network interface it was synthesized on. Figure 3 219 illustrates a scenario where the peer's IPv4 address is synthesized 220 into different IPv6 addresses by DNS servers A and B. The same 221 problem can happen in the IPv4 domain as well if A record synthesis 222 is done, for example as described in Bump-In-the-Stack [RFC2767]. 224 For a related problem for dual-stack hosts in a network with DNS64, 225 where IPv4 should be prioritized over synthesized IPv6, please see 226 [I-D.wing-behave-dns64-config]. 228 +------------------| +-------+ 229 +------+ IPv6 | DNS server A |----| NAT64 | 230 | |-- interface 1 --| saying Peer is | +-------+ 231 | | | at: A_Pref64::/n | | 232 | MIF | +------------------+ | +------+ 233 | host | IPv4 +---| Peer | 234 | | +------------------+ | +------+ 235 | | IPv6 | DNS server B | | 236 | |-- interface 2 --| saying Peer is | +-------+ 237 +------+ | at: B_Pref64::/n |----| NAT64 | 238 +------------------+ +-------+ 240 AAAA synthesis results in interface specific IPv6 addresses. 242 Figure 3 244 More complex scenario is an FQDN, which in addition to resolving into 245 network interface specific IP addresses, identifies on different 246 network interfaces completely different peer entities with 247 potentially different set of service offering. In even more complex 248 scenario, an FQDN identifies unique peer entity, but one that 249 provides different services on its different network interfaces. The 250 solution described in this document is not able to tackle these 251 higher layer issues. 253 A thing worth noting is that interface specific IP addresses can 254 cause problems also for a single-homed host, if the host retains its 255 DNS cache during movement from one network interface to another, and 256 thus on the new network interface host has cache entries invalid for 257 that network interface. Because of this the cached DNS information 258 should be considered network interface local instead of node global. 260 3. DNS server selection procedure 262 This chapter documents a possible procedure a host may utilize for 263 DNS server selection on multi-homing scenarios. 265 Essentially, the host shall build dynamically for each DNS query a 266 list of DNS servers it will try to contact to. The host shall cycle 267 through the list until a positive reply is received, or until all 268 selected DNS servers have been contacted or timed out. (DISCUSS: 269 What about those DNS servers that instead of negative answer always 270 return positive reply with an IP address of some default HTTP server, 271 which purpose is just to say 'page not found'?) 273 When building the list, the host shall prioritize DNS servers in a 274 optimal way for the query at hand. Host can utilize any information 275 it may have, e.g. possible user's preferences, host's general 276 preferences between network interfaces, differences on trust levels 277 of network interfaces (see Security Considerations), DNS suffix 278 information possibly available, or any other piece of information. 280 For the scenario where an FQDN maps to same service but different IP 281 addresses on different network interfaces, the source address 282 selection algorithm must be able to pick a source address from the 283 network interface that was used for DNS resolution. 285 In private FQDN deployments a negative reply from a DNS server 286 implies only that the DNS server at hand is not able to serve the 287 query. However, it is not probable that the secondary DNS servers on 288 the same network interface would be able to serve either, due likely 289 being in the same administrative domain. Therefore the next DNS 290 server host contacts should be from another network interface. 292 A host may optimize its behaviour by sending DNS requests in parallel 293 to multiple DNS servers of different network interfaces, but this 294 approach is not always practical: 296 o It may unnecessary trigger activation of a radio and thus increase 297 battery consumption. 299 o It may unnecessarily reveal private names to outsiders. 301 o It may be a privacy issue as it would reveal all names host is 302 resolving to all DNS servers. 304 3.1. DNS suffixes as hints 306 To help prioritize DNS servers in an optimal way, a host may learn 307 which DNS servers are most likely able to successfully serve requests 308 related to specific DNS suffixes. 310 By default, a host should assume all information is available via all 311 DNS servers of any network interface. 313 When a resource record is to be resolved, a host shall give highest 314 precedence to the DNS servers explicitly known to serve matching 315 suffixes and then to the DNS servers of the network interface(s) 316 advertising corresponding DNS suffix. 318 For example, when a resolution of an FQDN has been requested and the 319 host is prioritizing DNS servers of different network interfaces, the 320 host may prioritize higher DNS server(s) of the network interface(s) 321 with matching DNS suffix than it otherwise would have. 323 3.1.1. Learning of the DNS suffixes on existing networks 325 A host can learn the DNS suffixes of attached network interfaces from 326 DHCP search list options; DHCPv4 Domain Search Option number 119 327 [RFC3397] and DHCPv6 Domain Search List Option number 24 [RFC3646]. 328 This is illustrated in example figure 4 below. 330 Application Host DHCP server of DHCP server of 331 interface 1 interface 2 332 | | | 333 | +-----------+ | 334 (1) | | open | | 335 | | interface | | 336 | +-----------+ | 337 | | | 338 (2) | |---option REQ-->| 339 | |<--option RESP--| 340 | | | 341 | +-----------+ | 342 (3) | | store | | 343 | | suffixes | | 344 | +-----------+ | 345 | | | 346 | +-----------+ | 347 (4) | | open | | 348 | | interface | | 349 | +-----------+ | 350 | | | | 351 (5) | |---option REQ------------------->| 352 | |<--option RESP-------------------| 353 | | | | 354 | +----------+ | | 355 (6) | | store | | | 356 | | suffixes | | | 357 | +----------+ | | 358 | | | | 360 Learning DNS suffixes 362 Figure 4 364 Flow explanations: 366 1. A host opens its first network interface 368 2. The host obtains DNS suffix information for the new interface 1 369 from DHCP server 371 3. The host stores the learned DNS suffixes for later use 373 4. The host opens its seconds network interface 2 375 5. The host obtains DNS suffix, say 'example.com' information for 376 the new interface 2 from DHCP server 378 6. The host stores the learned DNS suffixes for later use 380 3.1.2. Explicit DNS suffix configuration with DHCP 382 To avoid overloading of existing DHCP(v6) options, new DHCP(v6) 383 options could be defined to assist in DNS server selection. The 384 options would define which DNS server should be used for resolving 385 names matching configured DNS suffixes. Below is description of the 386 DHCPv6 option. DHCPv4 version is to be added in next revision, but 387 would work similarly. 389 0 1 2 3 390 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 392 | OPTION_DNS_SERVER_SELECT | option-len | 393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 394 | | 395 | DNS-recursive-name-server (IPv6 address) | 396 | | 397 | | 398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 399 | DNS suffixes | 400 | ... | 401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 403 option-code: OPTION_DNS_SERVER_SELECT (TBD) 405 option-len: Lenght of the option in octets 407 DNS-recursive-name-server: An IPv6 address of a DNS server 409 DNS suffixes: The list of DNS suffixes MUST be encoded as 410 specified in section "Representation and use of 411 domain names" of . 413 DHCPv6 option for explicit DNS suffix configuration 415 Figure 5 417 The OPTION_DNS_SERVER_SELECT contains one or more DNS suffixes the 418 related DNS server has particular knowledge of (e.g. private 419 suffixes). The option can occur multiple times in a single DHCPv6 420 message, if multiple DNS servers are to be configured. 422 As the DNS options of [RFC3646], the OPTION_DNS_SERVER_SELECT option 423 MUST NOT appear in any other than the following messages: Solicit, 424 Advertise, Request, Renew, Rebind, Information-Request, and Reply. 426 Due backwards compatibility, the DHCPv6 message containing 427 OPTION_DNS_SERVER_SELECT also very likely contains 428 OPTION_DNS_SERVERS. In case both options contain same IPv6 429 addresses, only one copy of the IPv6 address SHALL be added to the 430 DNS server list. 432 In the case of a DNS server replying negatively to a question having 433 matching suffix, it will be for implementation to decide whether to 434 consider that as authoritative response, or whether to ask also from 435 other DNS servers. The implementation decision may be based, for 436 example, on deployment or trust models. 438 3.1.3. Changes to DNS resolution procedures 440 When a DNS resolver in a host is requested by an application to do 441 DNS resolution for an FQDN to an IP address, the host should look if 442 any of the configured DNS servers are known to serve addresses for 443 particular suffixes, or if any of the available network interfaces 444 are known to advertise DNS suffixes matching to the FQDN. If there 445 is a match, then explicitly configured DNS server(s) or DNS server(s) 446 of the particular interface should be priorized higher, i.e. be used 447 for name resolution procedures. This is illustrated in figure 6 448 below. To avoid accidental use of synthesized IPv6 addresses in the 449 dual-stack case, a host may prioritize DNS servers' IPv4 addresses 450 over IPv6 addresses. 452 Application Host DHCP server of DHCP server of 453 interface 1 interface 2 454 | | | | 455 (1) |--Name REQ-->| | | 456 | | | | 457 | +----------------+ | | 458 (2) | | DNS server | | | 459 | | prioritization | | | 460 | +----------------+ | | 461 | | | | 462 (3) | |------------DNS resolution------>| 463 | |<--------------------------------| 464 | | | | 465 (4) |<--Name resp-| | | 466 | | | | 468 Choosing interface based on DNS suffix 470 Figure 6 472 Flow explanations: 474 1. An application makes a request for resolving an FQDN, e.g. 475 'private.example.com' 477 2. A host creates list of DNS servers to contact to and uses 478 configured DNS server information and stored DNS suffix 479 information on priorization decisions. 481 3. The host has chosen interface 2, as from DHCP it was learned 482 earlier that the interface 2 has DNS suffix 'example.com'. The 483 host then resolves the requested name using interface 2's DNS 484 server to IP 192.0.2.1 486 4. The host replies to application with resolved IP address 487 192.0.2.1 489 4. Considerations for network administrators 491 Due to the problems caused by split DNS for multi-homed hosts, 492 network administrators should consider carefully deployment of split 493 DNS. 495 Network administrators deploying split DNS should assist hosts in DNS 496 server selection by configuring their DHCP servers with proper DNS 497 suffix information, which hosts then can use as hints. To ensure 498 hosts' source and destination IP address selection works correctly, 499 network administrators should also consider deployment of additional 500 technologies to help with that. 502 Network administrators can continue using DHCP DNS search list 503 options as before, but administrators should take into account that 504 multi-homed hosts may choose to use the DNS suffix information also 505 for DNS server selection purposes. 507 5. Further considerations 509 Overloading of existing DNS search list options is not without 510 problems, though: hosts would obviously use the DNS suffixes learned 511 from search lists also for name resolution purposes. This may not be 512 a problem in deployments where DNS search list options contain few 513 DNS suffixes like 'example.com, private.example.com', but can become 514 a problem if many suffixes are configured. To avoid overloading of 515 existing options, this document proposes standardization of a 516 completely new DHCP option. 518 6. Acknowledgements 520 The author would like to thank following people for their valuable 521 comments: Jari Arkko, Marcelo Bagnulo, Lars Eggert, Kurtis Lindqvist, 522 Fabien Rapin, Dave Thaler, Margaret Wasserman, Dec Wojciech, Suresh 523 Krishnan, Arifumi Matsumoto, Tomohiro Fujisaki and Dan Wing. 525 This document was prepared using xml2rfc template and related web- 526 tool. 528 7. IANA Considerations 530 This memo includes no request to IANA. 532 8. Security Considerations 534 An attacker may try to lure traffic from multi-homed host to his 535 network by advertising DNS suffixes attacker wishes to intercept or 536 deny service of. The host's security should not be based on correct 537 functionality of DNS server selection, but nevertheless risks of this 538 attack can be mitigated by using DNSSEC and additionally properly 539 prioritizing network interfaces with conflicting DNS suffix 540 advertisements. The prioritization could be based on trust level of 541 a network interface over which DNS suffix was learned from, like for 542 example: 544 1. Managed tunnel interfaces (such as VPN) considered most 545 trustworthy 547 2. Managed networks being on the middle 549 3. Unmanaged networks having lowest priority 551 Now, for example, if all of the three abovementioned networks would 552 advertise 'corporation.com' DNS suffix, the host would prefer the VPN 553 network interface for related DNS resolution requests. 555 9. References 557 9.1. Normative References 559 [I-D.ietf-behave-dns64] 560 Bagnulo, M., Sullivan, A., Matthews, P., and I. Beijnum, 561 "DNS64: DNS extensions for Network Address Translation 562 from IPv6 Clients to IPv4 Servers", 563 draft-ietf-behave-dns64-06 (work in progress), 564 February 2010. 566 [I-D.ietf-mif-problem-statement] 567 Blanchet, M. and P. Seite, "Multiple Interfaces Problem 568 Statement", draft-ietf-mif-problem-statement-01 (work in 569 progress), October 2009. 571 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 572 Requirement Levels", BCP 14, RFC 2119, March 1997. 574 [RFC2767] Tsuchiya, K., HIGUCHI, H., and Y. Atarashi, "Dual Stack 575 Hosts using the "Bump-In-the-Stack" Technique (BIS)", 576 RFC 2767, February 2000. 578 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 579 and M. Carney, "Dynamic Host Configuration Protocol for 580 IPv6 (DHCPv6)", RFC 3315, July 2003. 582 [RFC3397] Aboba, B. and S. Cheshire, "Dynamic Host Configuration 583 Protocol (DHCP) Domain Search Option", RFC 3397, 584 November 2002. 586 [RFC3646] Droms, R., "DNS Configuration options for Dynamic Host 587 Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, 588 December 2003. 590 9.2. Informative References 592 [I-D.ietf-mif-current-practices] 593 Wasserman, M., "Current Practices for Multiple Interface 594 Hosts", draft-ietf-mif-current-practices-00 (work in 595 progress), October 2009. 597 [I-D.wing-behave-dns64-config] 598 Wing, D., "DNS64 Resolvers and Dual-Stack Hosts", 599 draft-wing-behave-dns64-config-02 (work in progress), 600 February 2010. 602 Author's Address 604 Teemu Savolainen 605 Nokia 606 Hermiankatu 12 D 607 TAMPERE, FI-33720 608 FINLAND 610 Email: teemu.savolainen@nokia.com