idnits 2.17.1 draft-ietf-ipv6-dns-discovery-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 661 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of too long lines in the document, the longest one being 3 characters in excess of 72. == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. == There are 3 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 RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. 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: 'DHCPv6' is defined on line 471, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2462 (ref. 'ADDRCONF') (Obsoleted by RFC 4862) ** Obsolete normative reference: RFC 2845 (ref. 'TSIG') (Obsoleted by RFC 8945) == Outdated reference: A later version (-28) exists of draft-ietf-dhc-dhcpv6-27 -- Possible downref: Normative reference to a draft: ref. 'DELEG' Summary: 8 errors (**), 0 flaws (~~), 7 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Alain Durand 2 INTERNET-DRAFT SUN Microsystems, inc. 3 October 25, 2002 Jun-ichiro itojun Hagino 4 Expires April 2002 IIJ Research Laboratory 5 Dave Thaler 6 Microsoft 8 Well known site local unicast addresses 9 to communicate with recursive DNS servers 10 12 Status of this memo 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC2026. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet Drafts are valid for a maximum of six months and may be 23 updated, replaced, or obsoleted by other documents at any time. It 24 is inappropriate to use Internet Drafts as reference material or to 25 cite them other than as a "work in progress". 27 To view the list Internet-Draft Shadow Directories, see 28 http://www.ietf.org/shadow.html. 30 Abstract 32 This documents specifies 3 well known addresses to configure stub 33 resolvers on IPv6 nodes to enable them to communicate with recursive 34 DNS server with minimum configuration in the network and without 35 running a discovery protocol on the end nodes. This method may be 36 used when no other information about the addresses of recursive DNS 37 servers is available. Implementation of stub resolvers using this as 38 default configuration must provide a way to override this. 40 Copyright notice 42 Copyright (C) The Internet Society (2002). All Rights Reserved. 44 1. Introduction 46 RFC 2462 [ADDRCONF] provides a way to autoconfigure nodes with one or 47 more IPv6 address and default routes. 49 However, for a node to be fully operational on a network, many other 50 parameters are needed, such as the address of a name server that 51 offer recursive service (a.k.a. recursive DNS server), mail relays, 52 web proxies, etc. Except for name resolution, all the other services 53 are usually described using names, not addresses, such as 54 smtp.myisp.net or webcache.myisp.net. For obvious bootstrapping 55 reasons, a node needs to be configured with the IP address (and not 56 the name) of a recursive DNS server. As IPv6 addresses look much 57 more complex than IPv4 ones, there is some incentive to make this 58 configuration as automatic and simple as possible. 60 Although it would be desirable to have all configuration parameters 61 configured/discovered automatically, it is common practice in IPv4 62 today to ask the user to do manual configuration for some of them by 63 entering server names in a configuration form. So, a solution that 64 will allow for automatic configuration of the recursive DNS server is 65 seen as an important step forward in the autoconfiguration story. 67 The intended usage scenario for this proposal is a home or enterprise 68 network where IPv6 nodes are plugged/unplugged with minimum 69 management and use local resources available on the network to 70 autoconfigure. This proposal is also useful in cellular networks 71 where all mobile devices are included within the same site. 73 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 74 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 75 document are to be interpreted as described in [KEYWORDS]. 77 2. Well known addresses vs discovery 79 Some of the discussions in the past around DNS server discovery have 80 been trying to characterize the solution space into stateless versus 81 stateful or server oriented versus severless. It is not absolutely 82 clear how much state if any needs to be kept to perform DNS server 83 discovery, and, although the semantic differences between a router 84 and a server are well understood from a conceptual perspective, the 85 current implementations tend to blur the picture. In another attempt 86 to characterize different approaches, one can look at how much 87 intelligence a client needs to have in order to use the service. 89 One avenue is to ask the IPv6 node to participate in a discovery 90 protocol, such as SLP or DHCP, learn the address of the server and 91 send packets to this server. Another one is to configure the IPv6 92 node with well known addresses and let the local routing system 93 forward packets to the right place. This document explores this 94 later avenue of configuration using well known addresses that does 95 not require participation of the end node in any discovery mechanism. 97 3. Reserved prefix and addresses 99 The mechanism described here is: 100 - intended for ongoing use and not not just for bootstrapping 101 - intended to populate a stub resolver's list of available 102 recursive servers only if that list is otherwise unpopulated 103 - providing reliability through redundancy using three unicast 104 addresses. 106 3.1 Stub resolver configuration 108 This memo reserved three well known IPv6 site local addresses. 110 In the absence of any other information about the addresses of 111 recursive DNS servers, IPv6 stub-resolvers MAY use any of those three 112 IPv6 addresses in their list of candidate recursive DNS servers. 114 3.2 Recursive DNS servers configuration 116 Within sites, one or more recursive DNS server SHOULD be configured 117 with any of those three addresses. It is RECOMMENDED that large sites 118 deploy 3 recursive DNS servers, one for each reserved address. Small 119 site could use only one recursive DNS server and assign the 3 120 addresses to it. 122 3.3 Rationale for the choice of three addresses 124 Three was chosen based on common practice in many places in the 125 industry. While it's true that if the first one fails, that it's 126 unlikely the second one will succeed (due to there really being no 127 DNS server at all), using multiple addresses is important so that 128 when ones do exist, the host can fail over to a second server more 129 quickly than routing converges. Three servers is a compromise between 130 extra reliability and increased complexity (maintaining additional 131 servers, having multiple entries in the routing system, additional 132 delays before the stub resolver returns an error,...). 134 Another reason to have multiple addresses is to avoid the need to use 135 of anycast addresses to achieve reliability through redundancy. On 136 top of the classic problems (TCP sessions, ICMP messages,...) using 137 an anycast address would hide the real locations of the recursive DNS 138 servers to the stub resolver, prohibiting it to keep track of which 139 servers are performing correctly. For this particular matter, using 140 well known addresses is no different than configuring the stub 141 resolver with regular addresses taken from the local site. 143 3.4 Implementation considerations 145 Stub resolver implementation MAY be configured by default using those 146 addresses. However, implementing only the mechanism described in this 147 memo may end up causing some interoperability problems when operating 148 in networks where no recursive DNS server is configured with any of 149 the well known addresses. Thus, stub resolvers MUST implement 150 mechanisms for overriding this default, for example: manual 151 configuration, L2 mechanisms and/or DHCPv6. 153 4. Routing 155 A solution to enable the stub resolvers to reach the recursive DNS 156 servers is to inject host routes in the local routing system. 157 Examples of methods for injecting host routes and a brief discussion 158 of their fate sharing properties are presented here: 160 a) Manual injection of routes by a router on the same subnet. 161 If the node running the recursive DNS server goes down, the router 162 may or may not be notified and keep announcing the route. 164 b) Running a routing protocol on the same node running the DNS 165 resolver. 166 If the process running the recursive DNS server dies, the routing 167 protocol may or may not be notified and keep announcing the route. 169 c) Running a routing protocol within the same process running the 170 recursive DNS server. 171 If the recursive DNS server and the routing protocol run in 172 separated threads, similar concerns as above are true. 174 d) Developing an "announcement" protocol that the recursive DNS 175 server could use to advertize the host route to the nearby router. 176 Details of such a protocol are out of scope of this document, but 177 something similar to [MLD] is possible. However, the three first 178 mechanisms should cover most cases. 180 An alternate solution is to configure a link with the well known 181 prefix and position the three recursive DNS servers on that link. 182 The advantage of this method is that host routes are not necessary , 183 the well known prefix is advertised to the routing system by the 184 routers on the link. However, in the event of a problem on the 185 physical link, all resolvers will become unreachable. 187 IANA considerations for this prefix are covered in Section 6. 189 5. Site local versus global scope considerations 191 The rationales for having a site local prefix are: 193 -a) Using a site local prefix will ensure that the traffic to the 194 recursive DNS servers stays local to the site. This will prevent 195 the DNS requests from accidentally leaking out of the site. 196 However, the local resolver can implement a policy to forward DNS 197 resolution of non-local addresses to an external DNS resolver. 199 -b) Reverse DNS resolution of site local addresses is only 200 meaningful within the site. Thus, making sure that such queries 201 are first sent to a recursive DNS server located within the site 202 perimeter increase their likelihood of success. 204 6. Examples of use 206 This section presents example scenarios showing how the mechanism 207 described in this memo can co-exist with other techniques, namely 208 manual configuration and DHCPv6 discovery. 210 Note: those examples are just there to illustrate some usage 211 scenarios and in no way do they suggest any recommended practices. 213 6.1 Simple case, general purpose recursive DNS server 215 This example shows the case of a network that manages one recursive 216 DNS server and a large number of nodes running DNS stub resolvers. 217 The recursive DNS server is performing (and caching) all the 218 recursive queries on behalf of the stub resolvers. The recursive DNS 219 server is configured with an IPv6 address taken from the prefix 220 delegated to the site and with the 3 well known addresses defined in 221 this memo. The stub resolvers are either configured with the "real" 222 IPv6 address of the recursive DNS server or with the well known site 223 local unicast addresses defined in this memo. 225 -------------------------------------------- 226 | | 227 | --------------------- | 228 | |DNS stub resolver | | 229 | |configured with the| | 230 | |"real" address of | | 231 | |the recursive DNS | | 232 | |server | | 233 | --------------------- | 234 | ----------- | | 235 | |recursive| | | 236 | |DNS |<---------- | 237 | |server |<---------------- | 238 | ----------- | | 239 | ---------------------- | 240 | |DNS stub resolver | | 241 | |configured with 3 | | 242 | |well known addresses| | 243 | ---------------------- | 244 | | 245 -------------------------------------------- 247 (The recursive DNS server is configured to listen both on 248 its IPv6 address and on the well known address) 250 6.2 Three recursive DNS servers 252 This is a similar example as above, except that three recursive DNS 253 resolvers are configured instead of just one. 255 ------------------------------------------- 256 | | 257 | --------------------- | 258 | |DNS stub resolver | | 259 | |configured with the| | 260 | |"real" address of | | 261 | |the recursive DNS | | 262 | |server | | 263 | --------------------- | 264 | | | 265 | ----------- | | 266 | |recursive| | | 267 | |DNS |<---------| | 268 | |server 1 |<---------|------ | 269 | ----------- | | | 270 | | | | 271 | ----------- | | | 272 | |recursive| | | | 273 | |DNS |<---------| | | 274 | |server 2 |<---------|-----| | 275 | ----------- | | | 276 | | | | 277 | ----------- | | | 278 | |recursive| | | | 279 | |DNS |<---------- | | 280 | |server 3 |<---------------| | 281 | ----------- | | 282 | ---------------------- | 283 | |DNS stub resolver | | 284 | |configured with 3 | | 285 | |well known addresses| | 286 | ---------------------- | 287 | | 288 ------------------------------------------- 290 (The recursive DNS server is configured to listen both on 291 its IPv6 address and on the well known address) 293 6.3 DNS forwarder 295 A drawback of the choice of site local scope for the reserved 296 addresses for recursive DNS server is that, in the case of a 297 home/small office network connected to an ISP, DNS traffic cannot be 298 sent directly to the ISP recursive DNS server without having the ISP 299 and all its customers share the same definition of site. 301 In this scenario, the home/small office network is connected to the 302 ISP router (PE) via an edge router (CPE). 304 ------------- 305 / | 306 -------- ----- / | 307 |ISP PE| |CPE| / Customer | 308 | |===========| |====< site | 309 | | | | \ | 310 -------- ----- \ | 311 \ | 312 ------------- 314 The customer router CPE could be configured on its internal interface 315 with one of the reserved site local addresses and listen for DNS 316 queries. It would be configured to use one (or several) of the well 317 known site local unicast addresses within the ISP's site to send its 318 own queries to. It would act as a DNS forwarder, forwarding queries 319 received on its internal interface to the ISP's recursive DNS server. 321 ------------- 322 / | 323 ---------- -------------- / | 324 |ISP | | CPE| / Customer | 325 |DNS |===========| DNS|====< site | 326 |server | <------|---forwarder|-----\---- | 327 ---------- -------------- \ | 328 \ | 329 ------------- 331 In this configuration, the CPE is acting as a multi-sited router. 333 6.4 DNS forwarder with DHCPv6 interactions 335 In this variant scenario, DHCPv6 is be used between the PE and CPE to 336 do prefix delegation [DELEG] and recursive DNS server discovery. 338 ------------- 339 / | 340 -------- -------------- / | 341 |ISP | |customer CPE| / Customer | 342 |DHCPv6|===========| DHCPv6|====< site | 343 |server| <------|------client| \ | 344 -------- -------------- \ | 345 \ | 346 ------------- 348 This example will show how DHCPv6 and well known site local unicast 349 addresses cooperate to enable the internal nodes to access DNS. 351 The customer router CPE is configured on its internal interface with 352 one of the reserved site local addresses and listen for DNS queries. 353 It would act as a DNS forwarder, as in 5.2, forwarding those queries 354 to the recursive DNS server pointed out by the ISP in the DHCPv6 355 exchange. 357 ------------- 358 / | 359 ---------- -------------- / | 360 |ISP | |customer CPE| / Customer | 361 |DNS |===========| DNS|====< site | 362 |resolver| <------|---forwarder|-----\---- | 363 ---------- -------------- \ | 364 \ | 365 ------------- 367 The same CPE router could also implement a local DHCPv6 server and 368 advertizes itself as DNS forwarder. 370 ------------- 371 / | 372 -------- -------------- / Customer | 373 |ISP PE| |customer CPE| / site | 374 | |===========|DHCPv6 |====< | 375 | | |server------|-----\---> | 376 -------- -------------- \ | 377 \ | 378 ------------- 380 Within the site: 382 a) DHCPv6 aware clients use DHCPv6 to obtain the address of the 383 DNS forwarder... 385 ------------- 386 / | 387 ---------- -------------- / Customer | 388 |ISP | |customer CPE| / site | 389 |DNS |===========| DNS|====< | 390 |resolver| <------|---forwarder|-----\----DHCPv6 | 391 ---------- -------------- \ client | 392 \ | 393 ------------- 394 (The address of the DNS forwarder is acquired via DHCPv6.) 396 b) other nodes simply send their DNS request to the reserved site 397 local addresses. 399 ------------- 400 / | 401 ---------- -------------- / customer | 402 |ISP | |customer CPE| / site | 403 |DNS |===========| DNS|====< | 404 |resolver| <------|---forwarder|-----\----non DHCPv6| 405 ---------- -------------- \ node | 406 \ | 407 ------------- 408 (Internal nodes use the reserved site local unicast address.) 410 A variant of this scenario is the CPE can decide to pass the global 411 address of the ISP recursive DNS server in the DHCPv6 exchange with 412 the internal nodes. 414 7. IANA considerations 416 The site local prefix fec0:0000:0000:ffff::/64 is to be reserved out 417 of the site local fec0::/10 prefix. 419 The unicast addresses fec0:000:0000:ffff::1, fec0:000:0000:ffff::2 420 and fec0:000:0000:ffff::3 are to be reserved for recursive DNS server 421 configuration. 423 All other addresses within the fec0:0000:0000:ffff::/64 are reserved 424 for future use and are expected to be assigned only with IESG 425 approval. 427 8. Security Considerations 429 Ensuring that queries reach a legitimate DNS server relies on the 430 security of the IPv6 routing infrastructure. The issues here are the 431 same as those for protecting basic IPv6 connectivity. 433 IPsec/IKE can be used as the well known addresses are used as unicast 434 addresses. 436 The payload can be protected using standard DNS security techniques. 437 If the client can preconfigure a well known private or public key 438 then TSIG [TSIG] can be used with the same packets presented for the 439 query. If this is not the case, then TSIG keys will have to be 440 negotiated using [TKEY]. After the client has the proper key then 441 the query can be performed. 443 The use of site local addresses instead of global addresses will 444 ensure the DNS queries issued by host using this mechanism will not 445 leak out of the site. 447 9. References 449 [KEYWORDS] 450 Bradner, S., "Key words for use in RFCs to Indicate 451 Requirement Levels", BCP 14, RFC 2119, March 1997. 453 [ADDRCONF] 454 Thomson, S., and T. Narten, "IPv6 Stateless Address 455 Autoconfiguration", RFC 2462, December 1998. 457 [MLD] 458 Deering, S., Fenner, W., Haberman, B., 459 "Multicast Listener Discovery (MLD) for IPv6", 460 RFC2710, October 1999. 462 [TSIG] 463 Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington, 464 "Secret Key Transaction Authentication for DNS (TSIG)", 465 RFC2845, May 2000. 467 [TKEY] 468 D. Eastlake, "Secret Key Establishment for DNS (TKEY RR)", 469 RFC2930, September 2000. 471 [DHCPv6] 472 Bound, J., Carney, M., Perkins, C., Lemon, T., Volz, B. and 473 Droms, R. (ed.), "Dynamic host Configuration Protocol for IPv6 474 (DHCPv6)", draft-ietf-dhc-dhcpv6-27 (work in progress), 475 Februray 2002. 477 [DELEG] 478 Troan, O., Droms, R., "IPv6 Prefix Options for DHCPv6", 479 draft-troan-dhcpv6-opt-prefix-delegation-01.txt (work in progress), 480 February 2002. 482 10. Authors' Addresses 484 Alain Durand 485 SUN microsystems, inc. 486 17 Network Circle, UMPK 17-202 487 Menlo Park, CA 94025 488 Email: Alain.Durand@sun.com 490 Jun-ichiro itojun HAGINO 491 Research Laboratory, Internet Initiative Japan Inc. 492 Takebashi Yasuda Bldg., 493 3-13 Kanda Nishiki-cho, 494 Chiyoda-ku, Tokyo 101-0054, JAPAN 495 Email: itojun@iijlab.net 497 Dave Thaler 498 Microsoft 499 One Microsoft Way 500 Redmond, CA 98052, USA 501 Email: dthaler@microsoft.com 503 11. Full Copyright Statement 505 Copyright (C) The Internet Society (2002). All Rights Reserved. 507 This document and translations of it may be copied and furnished to 508 others, and derivative works that comment on or otherwise explain it 509 or assist in its implementation may be prepared, copied, published 510 and distributed, in whole or in part, without restriction of any 511 kind, provided that the above copyright notice and this paragraph are 512 included on all such copies and derivative works. However, this 513 document itself may not be modified in any way, such as by removing 514 the copyright notice or references to the Internet Society or other 515 Internet organizations, except as needed for the purpose of 516 developing Internet standards in which case the procedures for 517 copyrights defined in the Internet languages other than English. 519 The limited permissions granted above are perpetual and will not be 520 revoked by the Internet Society or its successors or assigns. 522 This document and the information contained herein is provided on an 523 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 524 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 525 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 526 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 527 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.