idnits 2.17.1 draft-ietf-ipngwg-dns-discovery-analysis-00.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 -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** 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 15 characters in excess of 72. 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.) -- The document date (July 12, 2001) is 8324 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) == Missing Reference: 'MLD' is mentioned on line 258, but not defined == Missing Reference: 'RFC 2608' is mentioned on line 1302, but not defined == Unused Reference: 'ANYCAST' is defined on line 1638, but no explicit reference was found in the text == Unused Reference: 'SLPv2' is defined on line 1706, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 1546 (ref. 'ANYCAST') ** Obsolete normative reference: RFC 2373 (ref. 'ADDRARCH') (Obsoleted by RFC 3513) ** Obsolete normative reference: RFC 2535 (ref. 'DNSSEC') (Obsoleted by RFC 4033, RFC 4034, RFC 4035) -- No information found for draft-aboba-dhc- - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'DOMSEARCH' == Outdated reference: A later version (-01) exists of draft-haberman-ipngwg-host-anycast-00 -- Possible downref: Normative reference to a draft: ref. 'HOST-ANYCAST' -- Possible downref: Non-RFC (?) normative reference: ref. 'IOS' -- Possible downref: Normative reference to a draft: ref. 'ITOJUN-ANYCAST' == Outdated reference: A later version (-47) exists of draft-ietf-dnsext-mdns-00 ** Downref: Normative reference to an Informational draft: draft-ietf-dnsext-mdns (ref. 'MDNS') ** Obsolete normative reference: RFC 2461 (ref. 'ND') (Obsoleted by RFC 4861) == Outdated reference: A later version (-15) exists of draft-ietf-ipngwg-icmp-name-lookups-07 ** Downref: Normative reference to an Experimental draft: draft-ietf-ipngwg-icmp-name-lookups (ref. 'NODEINFO') ** Obsolete normative reference: RFC 2082 (ref. 'RIPMD5') (Obsoleted by RFC 4822) ** Obsolete normative reference: RFC 2845 (ref. 'TSIG') (Obsoleted by RFC 8945) ** Downref: Normative reference to an Experimental RFC: RFC 1464 (ref. 'TXT') Summary: 14 errors (**), 0 flaws (~~), 9 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPNG Working Group DNS Discovery Design Team 3 INTERNET-DRAFT Dave Thaler, Editor 4 Expires September 2001 July 12, 2001 6 Analysis of DNS Server Discovery Mechanisms for IPv6 7 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six 20 months and may be updated, replaced, or obsoleted by other 21 documents at any time. It is inappropriate to use Internet- Drafts 22 as reference material or to cite them other than as "work in 23 progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Copyright Notice 33 Copyright (C) The Internet Society (2001). All Rights Reserved. 35 Abstract 36 Draft DDDT Report January 2002 38 There are any number of ways that IPv6 hosts can discover 39 information required to enable name resolution, in the absence of 40 a DHCP server. This document discusses the issues and provides a 41 taxonomy of possible solutions, and evaluates them against various 42 design criteria. Finally, it provides recommendations as input to 43 the standards process. 45 1. Introduction 47 The function of name-to-address resolution (or vice versa) in IP 48 is performed by the Domain Name Service (DNS) [RFC1034, RFC1035]. 49 Using DNS requires that at least one DNS Server be known and 50 reachable by a device desiring to resolution. 52 There is also underway, known as Multicast DNS (mDNS) [MDNS], on 53 resolving names on the link in the absence of a DNS Server. In a 54 managed environment with DNS Servers, mDNS is typically disabled 55 (via the domain search path). As a result, it is required that a 56 device be able to discover whether DNS Servers are available and 57 discover its search path. Thus, the mechanisms analyzed in this 58 report do not conflict with, but actually support the mDNS work. 60 In the absence of a DHCP server, the current IPv6 protocol suite 61 does not yet provide a mechanism to discover DNS servers or search 62 paths. To solve this problem, a design team was chartered by the 63 IPNG Working Group to investigate possible solutions and provide a 64 recommendation as input to the working group. 66 This document summarizes the approaches investigated, and provides 67 an analysis of each, and describes its recommendations. The 68 design team participants are listed in the Authors' Addresses 69 section below. 71 2. Requirements 73 For a device to effectively resolve names, and potentially allow 74 resolution of its name to be performed, the following information 75 is required: 77 o One or more addresses of DNS servers. If a list is obtained, a 78 client need only rediscover DNS servers if all addresses in the 79 list are unreachable. However, if a list is obtained from a 80 single point, such as one of the DNS servers, then a 82 Draft DDDT Report January 2002 84 requirement exists that the list of servers be up-to-date and 85 easily maintainable. 87 o Domain name 89 o Search path. It is currently common practice, for the search 90 path to be computed by a device based on its domain name 91 obtained. However, a DHCP option [DOMSEARCH] is being proposed 92 in the DHC WG, and so search path configuration is likely to be 93 a requirement in general. 95 It is a further requirement that the above information be obtained 96 without using a DHCP server. 98 Automatic configuration of DNS servers, if no DNS servers exist 99 within the IPv6 site, is not a requirement. However, it is 100 expected that there may be devices on site boundaries which will 101 want to relay messages containing the above types of DNS 102 information across site boundaries. One such likely scenario 103 would be a home gateway device, where a home is its own site, 104 wanting to allow devices in the home to discover and use an 105 external DNS server, provided by an ISP. 107 3. Criteria for Evaluation 109 Each mechanism can be evaluated against a number of criteria: 111 Scalability 112 Is the mechanism scalable to a huge number of devices within a 113 site? 115 Security 116 Does the mechanism support authentication? What pre- 117 configuration is assumed? 119 Time to Deploy 120 Can the mechanism be deployed immediately? What devices need 121 to have software updated to deploy the mechanism? What devices 122 need to have additional configuration done with existing 123 software? 125 Business Motivation 126 Do the parties required to implement any new code have a 127 business motivation to do so, in preference to other options? 129 Draft DDDT Report January 2002 131 Do the parties required to deploy any new devices or software 132 have a business motivation to do so, in preference to other 133 options? 135 Standardization 136 Does the mechanism require anything new to be standardized? If 137 so, is the standardization within the realm of another Working 138 Group? 140 Fate Sharing 141 If deployed, does the mechanism introduce dependencies on other 142 devices, protocols, or processes that would not normally be 143 required to perform name resolution? 145 Convergence Time 146 Upon the failure of a DNS server, router, or link, how long 147 does it take for the mechanism to converge? 149 Scenarios 150 Does the mechanism work in all scenarios? Scenarios of note 151 include: 153 o Isolated link with a DNS server but no routers 155 o Site with routers, but no multicast routing enabled 157 o Hosts connected over an NBMA link 159 4. Taxonomy 161 Mechanisms can be categorized by their choice of transport 162 mechanism (e.g., are the messages multicast or unicast?), and by 163 their choice of packet format. 165 Sections 5 and 6 cover these two axes, and describe the set of 166 mechanisms evaluated. 168 5. Transport Mechanisms 170 5.1. Anycast for DNS server discovery only 172 This method is based on the use of a well-known site-scoped 173 anycast address which is used during DNS server discovery only. 175 Draft DDDT Report January 2002 177 We assume that IANA defines a well-known site-scoped anycast 178 address, which can be assigned one or more servers. For optimal 179 fate-sharing, we assume that these servers are DNS servers. The 180 aim is to provide a mechanism that allows DNS servers assigned the 181 well-known anycast address to be reachable within a site. 183 The proposal is based on a two-step discovery process. First, a 184 device sends, using a connection-less protocol, a server-discovery 185 message with the anycast address as a destination address. The 186 message will eventually reach a topologically closest server with 187 the anycast address. The server will send a reply with a unicast 188 address as the source address, containing a list of unicast 189 addresses of valid DNS servers, plus the domain name and search 190 path. Thereafter, all communication for name resolution is done 191 using one of the unicast addresses in the list obtained. Only if 192 all addresses in the list are unreachable does the device need to 193 repeat the discovery process. 195 Obviously, this requires that all IPv6 devices requiring DNS 196 server discovery in the absence of a DHCP server must implement 197 this mechanism. 199 There are three immediate deployment options: 201 a) Run the servers on routers, and configure them to inject host 202 routes for the anycast address into the site's routing 203 infrastructure. 205 b) Run a routing protocol on the servers, and configure them to 206 inject host routes for the anycast address into the site's 207 routing infrastructure. Note that this requires that a server 208 and its router(s) must run the same routing protocol, at least 209 for communication between the router(s) and the server(s) on 210 the link. Note that, however, a server does not need to 211 participate fully in the routing protocol, it only needs to be 212 able to inject routes. For example, RIPng [RIPNG], configured 213 for outbound advertisements only, would be sufficient. 215 c) Run multiple servers on the same link(s), and configure their 216 local router(s) to inject host routes for the anycast address 217 into the site's routing infrastructure. Running multiple 218 servers on the same link provides robustness to the failure of 219 a server, while routing provides robustness to the loss of 220 routers and other links. There may still be some failures, 222 Draft DDDT Report January 2002 224 however, such as a unidirectional failure of the router's 225 interface, which are not handled by this option. 227 If new code can be added to the router, a fourth option is also 228 possible: 230 d) Using Neighbor Discovery to track whether servers are present. 231 In this case a router will be configured to solicit certain 232 Site-scoped anycast addresses when booting. This can also be 233 done periodically. Upon receiving a reply, the router will 234 have the true address of the server in its Neighbor Cache and 235 can inject a host route into the system for this Site-scoped 236 anycast address. A variant of this option, which would not 237 require configuring the routers with the addresses to solicit, 238 would be to combine it with running a routing protocol on the 239 servers. The router could then solicit whatever addresses 240 were advertised in host routes, and take advantage of neighbor 241 unreachability detection to quickly expire host routes. 243 Routers should have this feature and allow configuration to 244 enable or disable it. Also the Site-scoped addresses can be 245 configurable when enabling this feature. This is to ensure 246 that network administrators can add new Site-scoped addresses 247 without the need for new software. On some links, it may be 248 required to not allow hosts to announce these services. Hence 249 soliciting anycast addresses should not be enabled on those 250 links. 252 It should be noted that this option does not require any 253 protocol changes to ND, as it relies on the allocation of 254 Well-known site-scoped anycast addresses to the hosts. 256 For a longer-term solution, a mechanism for communicating anycast 257 group joins to routers is desired. It is expected that this would 258 be done as an extension to the Multicast Listener Discovery [MLD] 259 protocol, and the sockets API for joining multicast groups. There 260 is now work in progress [HOST-ANYCAST] in this regard. 262 More details on generic anycast issues are available in [ITOJUN- 263 ANYCAST]. 265 Draft DDDT Report January 2002 267 5.1.1. Evaluation 269 Scalability 270 The use of anycast can scale up to an arbitrarily large number 271 of devices within the site, since to perform DNS server 272 discovery, devices will only contact their closest server. As 273 a result, scalability can be achieved by adding more servers as 274 the number of devices increases. Since all traffic is unicast 275 traffic, no extra bandwidth is consumed on links other than 276 those between a device and its closest server. 278 A large number of servers can also be supported easily, if 279 desired, since only a single server is contacted to obtain a 280 list of DNS servers, and the list obtained need not contain all 281 DNS servers in the site. 283 Security 284 The use of anycast is vulnerable to the same attacks as 285 unicast. This mechanism can best be authenticated by having 286 the content signed via a content-specific mechanism. 288 It may be possible to use IPsec to authenticate the discovery 289 messages, but IKE cannot be used for anycast transmission, as 290 RFC 2373 does not allow an anycast address to be used as the 291 source address of packets. As a result, barring future 292 research and development of other key distribution protocols, 293 using IPsec instead of a content-specific mechanism would 294 require manual keying. 296 In addition to securing discovery messages, it is also 297 necessary to secure the mechanism used to communicate anycast 298 joins from DNS servers to routers. Without such 299 authentication, the possibility would exist for a rogue server 300 to redirect traffic to itself, and away from valid servers. 302 In option (a), this is easy since the server is on the same 303 machine as the router. Likewise, in option (c), joins are done 304 by manual configuration which is easily securable. Option (b), 305 however, requires utilizing authentication mechanisms available 306 with current routing protocols (e.g., MD5 with RIPng [RIPMD5]). 308 In option (d), only Neighbor Discovery messages need to be 309 secured. However, authenticating Neighbor Discovery messages 310 is needed regardless of the option chosen, even if only to 312 Draft DDDT Report January 2002 314 secure discovery by devices on the same link. 316 Time to Deploy 317 Anycast discovery can be deployed as soon as clients are 318 available, using any of the immediate-term options listed 319 above, alone or in any combination, at the choice of each site 320 administrator, without any need to coordinate with others. 322 For immediate option (a), one must update one or more routers 323 to run a server, if none already do. 325 For immediate option (b), one must update one or more DNS 326 servers to run an IPv6 routing protocol which can talk to its 327 local router(s). 329 For immediate option (c), one must ensure that multiple servers 330 are deployed on the same link(s). One then configures its 331 local routers with a static host route for the anycast address. 333 To deploy option (d), routers on servers' links need to be able 334 to inject routes based on responses received from ND 335 solicitations. This would require SW upgrades for those 336 existing routers. 338 In all four options, one must finally configure the servers 339 with the well-known anycast address. No configuration is 340 needed on other routers or devices, so configuration is 341 confined to a small number of devices. It is expected that at 342 least one of the above options will be acceptable to IPv6 site 343 administrators for the immediate future. 345 Business Motivation 346 The primary business motivation is that it can be deployed 347 immediately with a minimum of effort and cost, compared to 348 other options. As time progresses, the incentive to upgrade to 349 either option (d) or a dynamic joining protocol is that the 350 site would not be limited to the three basic options. 352 Standardization 353 For immediate deployment, including option (d), nothing new is 354 required. For a longer-term optimal solution, an anycast- 355 joining protocol is required. It is expected that this would 357 Draft DDDT Report January 2002 359 be done within the IPv6 Working Group as an extension to MLD. 361 Fate Sharing 362 This mechanism exhibits good fate sharing properties. No 363 additional dependencies on any other devices, protocols, or 364 processes exist, beyond those that are already required for 365 performing actual name resolution using DNS (i.e., unicast 366 reachability). 368 Convergence Time 369 When a router or link fails, the convergence time is the 370 convergence time of the unicast routing protocol in the site, 371 if the server is off-link, or the convergence time of Neighbor 372 Discovery if the server is on-link. When a server fails, this 373 is also the convergence time of DNS server discovery, but not 374 for name resolution. Since unicast is used for actual name 375 resolution, a host with a list of DNS servers may converge 376 faster to another DNS server it previously discovered, when a 377 DNS server fails. 379 Scenarios 380 This mechanism should work in all scenarios discussed. 381 Specifically, it will work in the absence of routers and in the 382 absence of multicast-capable media and routing protocols. 384 5.2. Anycast for name resolution 386 Assign a well-known site-scoped anycast address to DNS servers. 387 Use anycast destination address on DNS queries. Anycast packet 388 will eventually reach the topologically a closest DNS server. DNS 389 server will send a reply. 391 While the other mechanisms evaluated try to obtain unicast IPv6 392 addresses of DNS servers, this approach uses anycast as the actual 393 name resolution transport. 395 Acquiring the domain name and search path must still be done as in 396 section 5.1 above, however. 398 Draft DDDT Report January 2002 400 5.2.1. Configuration 402 Define a well-known site-scoped anycast address, and write it down 403 on a document. Let us assume that it is fec0::9999 for now. 405 Configure clients to send DNS queries to the address. The 406 configuration does not need to be modified even if the machine 407 moves from a site to another, as the anycast address is well- 408 known. 410 Configure DNS servers (server-1, server-2 to server-N) with the 411 anycast address, and make them reply the query to fec0::9999. 412 Make sure that packets with the anycast destination address get 413 routed to DNS servers. (see a section below on this topic) 415 5.2.2. Actual use 417 (1) When a DNS name resolution is necessary for a client, the 418 client would transmit a DNS query (usually UDP) toward 419 fec0::9999. 421 client -> fec0::9999 DNS query 423 (2) The DNS query will reach one of the DNS servers (suppose it 424 was "server-X"). The server will resolve the name by making 425 a recursive query. The server will send a reply to the 426 client. If we follow the RFC 2373 restriction that an 427 anycast address cannot be used as a source address, we need 428 to use server-X's unicast address as the source. In this 429 case, DNS clients should not check the source address of DNS 430 replies. Some existing implementations do this to check if 431 the packet was really from the server queried. The check is 432 rather weak, however, as it is easy to spoof the source 433 address. Instead, DNSSEC should be used here. 435 server-X -> client DNS reply 437 5.2.3. Evaluation 439 Note that there are multiple ways to handle anycast routing in a 440 site. Some of them require us to inject a /128 route into the 441 routing system, some of them does not. 443 Scalability 444 The scalability of the proposal is exactly the same as the 446 Draft DDDT Report January 2002 448 scalability implication in anycast routing. Note that, as the 449 proposal uses a site-scoped anycast address, we need to scale 450 up to a single site - we do not need to scale up to the whole 451 Internet. 453 Regarding to the site network size, the approach should have no 454 problem, except the possible delay imposed by extra hops 455 between DNS clients and servers. 457 Regarding to the impact from the number of possible DNS servers 458 to the site routing system, there should be no problem. Even 459 if we are to inject a /128 route to the site routing system, we 460 will have a single extra routing entry on site routers. As we 461 share a single site-scoped anycast address among the DNS 462 servers, we just need to carry a single /128 route in the site 463 routing system. 465 Regarding to the load balancing among DNS servers, it depends 466 on (1) the network topology in the site, (2) where the DNS 467 servers are located, (3) where the DNS clients are located, and 468 (4) the anycast routing mechanism we use. If we need to 469 implement a perfect load balancing among DNS servers (equal 470 load onto each DNS servers), we should just put DNS servers 471 onto a single IPv6 subnet. Neighbor discovery for anycast 472 address should take care of it. Refer to [ND], section 7.2.7. 474 There is no impact against the worldwide routing system. 476 Security 477 The security issues with this mechanism are the same as those 478 discussed in section 5.1. 480 Time to Deploy 481 The proposal is based on standardized mechanisms, including 482 anycast, routing protocols (like RIPng) and DNS lookup over 483 IPv6. This is just a matter of configuration to deploy this 484 proposal. 486 There are widely-deployed implementations that support anycast 487 address assignment. There are many IPv6 routing protocol 488 implementations. 490 As for DNS lookup over IPv6, there are servers (including ISC 491 BIND9) and clients (including BIND9, NetBSD, OpenBSD, FreeBSD, 493 Draft DDDT Report January 2002 495 and Linux) that support it. 497 The use of TCP with anycast needs more study (spec-wise), so 498 DNS query/reply over IPv6 TCP may need some time to deploy. 500 Regarding to the sanity checks made by DNS client 501 implementation, BIND-based implementation has a configurable 502 option to turn off the source address validation on the DNS 503 reply packet. 505 To deploy this proposal, there is no requirement to run 506 additional servers. 508 Business Motivation 509 If there are operating system implementations without anycast 510 support, we apparently cannot use the operating system 511 implementation as a DNS server. If there are commercial 512 operating systems that do not support anycast, they now have a 513 good motivation to support it. 515 Standardization 516 As the proposal uses DNS as the content format, it is safe to 517 say that the content is standardized well. 519 We already have couple of standardized IPv6 routing protocols. 520 So even if we are to use routing protocol to inject a /128 521 route for the DNS server anycast address, there should be no 522 problem. 524 For full discussions on anycast routing, refer to [ADDRARCH] 525 and [ITOJUN-ANYCAST]. 527 Fate Sharing 528 As DNS queries use site-scoped anycast address as the 529 destination, DNS query/reply relies upon anycast routing 530 mechanism. There is no circular dependency between anycast 531 routing and DNS lookups. 533 Convergence Time 534 There are couple of possible configurations for anycast packet 535 delivery. 537 If we run anycast DNS servers on routers, the convergence time 538 will be the same as the router failure recovery time. When a 539 router with DNS server dies, we need to wait until another 541 Draft DDDT Report January 2002 543 router to take it over. 545 If we inject /128 routes onto the site routing system for 546 anycast packet delivery, the convergence time will depend on 547 the routing information propagation time of the site routing 548 system. 550 As to partial failure (like DNS server daemon died but the 551 operating system is alive), there are many failure modes to 552 mention and there are many implementation dependencies. 553 Implementers may need to diagnose partial failure modes in 554 detail. 556 Scenarios 557 This mechanism should work in all scenarios discussed. 559 5.3. Link-scoped multicast with router-only responses 561 This transport approach is modeled after IPv6 Neighbor Discovery 562 [ND] transport mechanisms. It could be part of [ND] or another 563 protocol using a similar transport mechanism. 565 This approach has two modes. The first is routers periodically 566 advertise DNS information (e.g., DNS server addresses, default 567 domain, and search path) to all nodes on a link by sending an 568 advertisement to the all nodes link-scope multicast address (i.e., 569 FF02::1 ). 571 The second mode is that nodes needing DNS information can send a 572 solicitation to the all routers link-scope multicast address 573 (e.g., FF02::2) requesting DNS information. Routers with the DNS 574 information will respond with an advertisement with the requested 575 DNS information. This advertisement will be sent to the unicast 576 address of the node sending the solicitation. 578 5.3.1. Evaluation 580 Scalability 581 This transport approach has excellent scalability. It scales 582 as well as ND and DNS does currently. All of the multicast 583 traffic is local to the link. The periodic advertisement rates 584 can be tuned to environment including turn it off completely 585 and relying on the solicitation/advertisement mode. 587 Draft DDDT Report January 2002 589 ND transport mechanisms work on a variety of link (e.g., 590 multicast capable, point-to-point, shared media, etc.). It 591 will well suited for both wired and wireless links. 593 Security 594 Mechanisms that are being developed to authenticate ND can be 595 applied to this approach as well. The only preconfiguration is 596 done in routers where the DNS information is held. 598 No new security issues are raised. All of the traffic is link- 599 scoped. Any attacks require link access and if successful only 600 affect nodes on the individual link. 602 Time to Deploy 603 This approach requires implementation in nodes wishing to learn 604 DNS information and in routers to provide the information. The 605 router will need to be configured with the DNS information 606 needed in the advertisements. 608 If done as an extension to ND, it will be a small amount of 609 work to extend the ND implementation to add the additional 610 functionality. If done in a new protocol it would be more 611 difficult to create the new protocol. 613 It should be possible to deploy it quickly once the details are 614 scoped out and the implementations are developed. There is no 615 new network wide services such as multicast or anycast that 616 need to be deployed. There are no dependencies with other 617 protocols. 619 Business Motivation 620 This approach is a simple extension to existing protocols in 621 existing products and there should be ample motivation to add 622 it to existing products. No complex dependencies are created. 623 No new network transport mechanisms (e.g., anycast) are 624 required. No network operators have to deploy any new 625 transport mechanisms (e.g., multicast and/or anycast). 627 Standardization 628 A single document would have to be written to describe an 629 extension to ND or a new protocol. This would have to become 631 Draft DDDT Report January 2002 633 an IETF standard. This is within the scope of the IPng working 634 group. No other IETF working groups would need to be involved. 636 Fate Sharing 637 The only fate sharing issue raised is that it ties the 638 discovery of DNS information with the operation of routers on a 639 link. This is very similar to the common practice with IPv4 of 640 using Bootp relays in routers to communicate with DHCP servers, 641 so in practical terms the issue is very small. 643 No changes are made to DNS servers or way nodes communicate 644 with DNS servers. 646 Convergence Time 647 Convergence time is similar to current IPv4 DNS operation using 648 DHCP for DNS discovery. No new convergence issues are created. 649 If one of a set of DNS servers is unavailable (e.g., down, 650 isolated, etc.), then normal DNS recover mechanisms will select 651 an alternative DNS servers. 653 If one of a set of routers is unavailable, other routers on the 654 link will continue providing the DNS information. 656 If the last DNS server is unavailable, then it is down. If the 657 last router is unavailable, then new nodes will not be able to 658 learn DNS information or reach any DNS server through the 659 router. 661 Scenarios 662 This mechanism works over a broad range of scenarios. It 663 should work as well on links that are high performance (e.g., 664 LANs) and low performance (e.g., wireless). 666 However, this mechanism relies on routers and does not support 667 DNS servers on isolated links. Other local DNS server 668 discovery mechanisms (e.g., multicast DNS) would be needed. 669 This approach is believed to be compatible with multicast DNS 670 approach being developed in the IETF. 672 It can be used in either a periodic multicast advertisement, or 673 a solicitation/advertisement mode. 675 Draft DDDT Report January 2002 677 5.4. Link-scoped multicast (with router assist) 679 In this approach, devices send a request to a (new) well-known 680 link-scoped multicast address. DNS servers and routers both 681 listen to this multicast address. If any DNS servers exist on the 682 list, they can respond directly to the host. 684 In addition, routers are responsible for using some other 685 mechanism to obtain the DNS server list (e.g., one of the other 686 mechanisms evaluated in this document). Routers with the DNS 687 information will respond with an advertisement with the requested 688 DNS information. 690 5.4.1. Evaluation 692 Scalability 693 This mechanism scales fine on each individual link. The 694 scalability across the site depends on the scalability of the 695 inter-router mechanism used. 697 Security 698 The use of multicast is vulnerable to the same attacks as 699 unicast. This mechanism can best be authenticated by having 700 the content signed via a content-specific mechanism. 702 It may be possible to use IPsec to authenticate the discovery 703 messages, but IKE cannot be used for multicast transmission. 704 As a result, barring future research and development of other 705 key distribution protocols, using IPsec instead of a content- 706 specific mechanism would require manual keying. 708 In contrast to the anycast approaches, it is not strictly 709 necessary to secure the mechanism used to communicate multicast 710 joins from DNS servers to routers, since a rogue server cannot 711 redirect traffic to itself that would otherwise reach a valid 712 server. 714 Time to Deploy 715 This approach can be deployed by devices immediately, as link- 716 scoped multicast is already ubiquitous. However, the time to 717 deploy router assist to discover off-link servers depends on 718 the inter-router mechanism chosen. 720 Draft DDDT Report January 2002 722 Business Motivation 723 No strong business case for choosing this mechanism over the 724 others evaluated is known. 726 Standardization 727 Nothing new is required, beyond whatever is required for the 728 content mechanism and the inter-router mechanism. 730 Fate Sharing 731 Good fate sharing is preserved in this partial mechanism, as no 732 additional dependencies on other devices or protocols is 733 introduced, beyond whatever is required for the inter-router 734 mechanism. 736 Convergence Time 737 The convergence time depends on the convergence time of the 738 inter-router mechanism used. 740 Scenarios 741 This mechanism works on an isolated link, and can work in the 742 absence of multicast routing (provided a non-multicast inter- 743 router mechanism is used). 745 However, it does not support the NBMA link scenario. 747 5.5. Site-scoped multicast 749 Site-scoped multicast could be used to discover all DNS servers 750 within a site. This would be analogous to the way multicast is 751 currently used by IPv6 hosts to discover their neighboring 752 routers, but over the span of a site rather than just a single 753 link. 755 There are several possible ways for site-scoped multicast to be 756 used for DNS (or any other) server discovery. The clients could 757 send multicast query packets to a well-known, site-local, "all- 758 site-DNS-servers" multicast address, to which all DNS servers 759 would listen and respond. Alternatively, the servers themselves 760 could send periodic multicast advertisement packets to a well- 761 known, site-local, "all-site-DNS-clients" multicast address, to 762 Draft DDDT Report January 2002 764 which all clients would listen in order to discover the presence 765 and address(es) of all of the site's DNS servers. Probably the 766 best approach, from the point of view of responsiveness, scaling, 767 and traffic volume is to use both of those techniques in 768 combination, exactly as they are used for router discovery, as 769 follows: 771 o Two well-known, site-local scoped, multicast addresses are 772 assigned by IANA, one for all-site-DNS-routers and one for all- 773 site-DNS-clients. 775 o When a DNS server starts up, it multicasts a small number (say, 776 3) of advertisement messages to the all-site-DNS-clients 777 address at short (sub-second) intervals, and then continues to 778 retransmit the advertisement messages but at much larger 779 intervals (30 seconds or more). It also sends a unicast 780 response to any (unicast or multicast) DNS discovery query 781 message it receives. 783 o When a client starts up (or when the first attempt to perform a 784 DNS look-up occurs), if the client has not yet heard any 785 advertisements from DNS servers, it multicast up to a small 786 number (say, 3) of query messages to the all-site-DNS-servers 787 address at short (sub-second) intervals, stopping as soon as it 788 receives a response from a DNS server or it reaches the small 789 retransmission limit. From that point on, the client does not 790 send any multicast queries, but rather relies on passively 791 discovering additional DNS servers (and DNS servers that fail 792 and subsequently recover) by listening on the the all-site-DNS- 793 clients address for advertisements. 795 The response and advertisement messages would ideally contain only 796 the address of the sending DNS (rather than a list of multiple DNS 797 servers, which which would impose an undesirable requirement for 798 configuration of, or a coordinating protocol among, the servers). 799 That one address could be found either in the Source Address field 800 of the IPv6 header or in the content of the message. Clients 801 would build their lists of candidate DNS servers by taking the 802 union of the responses/advertisements received. 804 To avoid the need for additional packet exchanges, the response 805 and advertisement messages should also carry the other information 806 Draft DDDT Report January 2002 808 required by the client, i.e., the domain name and default domain 809 search list to be used by clients within the site. [Open issue: 810 what ought a client to when not all DNS serves are advertising the 811 same information?] 813 5.5.1. Evaluation 815 Scalability 816 The recommended technique, above, imposes a steady-state 817 traffic load on a site of one multicast packet per DNS server, 818 every (30 second or greater) advertisement transmission 819 interval. Because almost all nodes would be expected to 820 listen to those multicasts, they would effectively be site-wide 821 broadcast messages. However, note that the retransmission 822 interval can safely be made quite large to minimize the 823 overhead of those message, since the technique does not rely on 824 a small interval for its responsiveness; rather, the periodic 825 multicast advertisements serve the role of ensuring long-term 826 consistency and recovering from rare failures (e.g., loss of 827 three packets in a row, or site partitioning). 829 In addition to the overhead of the periodic advertisements, 830 there is also the small (maximum 3 packet) burst load of 831 queries/ responses/advertisements that occur whenever a client 832 or DNS server starts up. Note that these costs are comparable 833 to those incurred by the anycast techniques described in other 834 sections. They can also be further reduced by a more 835 sophisticated design, in which queries and/or responses are 836 delayed for small, randomized time intervals in order to do 837 "suppression" of identical queries or responses that occur very 838 close together, e.g., when a site comes up after a site-wide 839 power-failure. 841 Using this technique requires that all, or almost all, nodes 842 within a site send multicast packets at some point or another. 843 A multicast routing implementation that instantiated state for 844 every active multicast source node would have a state cost on 845 the order of the number of nodes in the site. It may be 846 preferable to use a multicast routing protocol that 847 instantiates state only for each active multicast source 848 *subnet* (which is sufficient to support shortest-path 849 multicast delivery), or for each multicast destination address 850 (so-called "shared-tree" multicast, which does not try to 851 achieve shortest-path delivery, which is not important for this 853 Draft DDDT Report January 2002 855 particular application). 857 Security 858 The security evaluation for all types of multicast is discussed 859 in section 5.4.1. 861 Time to Deploy 862 It is expected that most sites will not have site-wide 863 multicast deployed in the near-term future. As a result, it 864 may be some time before a site-scoped multicast solution could 865 be deployed. 867 Business Motivation 868 Given the perceived extra cost of managing a multicast-enabled 869 infrastructure, when other solutions relying only on unicast 870 routing exist, it is expected that no strong business case for 871 choosing site-scoped multicast exists. 873 Standardization 874 Protocols needed for multicast connectivity are already on the 875 standards track, or in progress. 877 Fate Sharing 878 This mechanism places an extra dependency on the correct 879 functioning of the multicast routing system. There are no 880 dependencies on any extra devices, however, beyond those that 881 are already required for name resolution. 883 Convergence Time 884 When a router or link fails, the convergence time is the 885 convergence time of the multicast routing protocol in the site. 886 When a server fails, this is also the convergence time of DNS 887 server discovery, but not for name resolution. Since unicast 888 is used for actual name resolution, a host with a list of DNS 889 servers may converge faster to another DNS server it previously 890 discovered, when a DNS server fails. 892 Draft DDDT Report January 2002 894 Scenarios 895 This mechanism works on an isolated link with a DNS server but 896 no routers. 898 However, it does not work in a site with no multicast routing 899 enabled, or among hosts connected over an NBMA link. 901 5.6. Hybrid 903 It is possible to combine the above approaches in some situations. 904 For example, the option for link-scoped multicast with router 905 assist requires one of the other options to form a complete 906 solution. 908 It is also possible for one of the above mechanisms to be the 909 default, but allow use of one of the other mechanisms based on 910 local manual configuration, or on configuration obtained 911 information obtained from say Router Advertisements. Of course, 912 if routers can distribute the address to use for discovery, then a 913 router which does not have multicast routing enabled must not 914 distribute a site-scoped multicast address. 916 The disadvantage with router overrides is that devices must be 917 prepared to handle multiple mechanisms, increasing the complexity 918 of the implementations. 920 6. Message Content Mechanisms 922 6.1. DHCP 924 In this mechanism, the messages sent to DNS servers are DHCP- 925 format messages, and the DNS servers send DHCP messages in 926 response. 928 The domain name can be obtained by having the DNS server include a 929 Domain Name option in the response. A DHCP option to obtain a 930 domain search path [DOMSEARCH] is currently being discussed in the 931 DHC WG. Without this option, the search path behavior would be no 932 different from the behavior today, where the search path is simply 933 computed based on the domain name obtained. A list of DNS servers 934 would also require a new DHCP option, which is already required if 935 DHCP for IPv6 is to be implemented. 937 Draft DDDT Report January 2002 939 6.1.1. Evaluation 941 Scalability 942 Only one round trip of messages is required, and there is no 943 need to run any additional servers. In other respects, this 944 mechanism has the same scalability properties as the underlying 945 transport mechanism chosen. 947 Security 948 A means of securing DHCP content that does not rely on IPsec 949 has been proposed in the DHC Working Group [DHCPAUTH]. 951 Time to Deploy 952 This would require time to implement a DHCP parser in DNS 953 servers. In addition, DHCP for IPv6 is still being defined by 954 the DHC Working Group. 956 Business Motivation 957 Devices wanting to resolve names probably already have to 958 implement a DHCP parser and be able to obtain DNS-related 959 configuration information using DHCP messages. As a result, it 960 is expected that little extra work would be required by stack 961 implementers beyond implementing DHCPv6. 963 Standardization 964 The DHCP for IPv6 content format is still being defined by the 965 DHC Working Group. 967 Fate Sharing 968 Good fate sharing would require that DNS servers also implement 969 a DHCP parser. Otherwise, it is necessary to run a DHCP 970 service on the DNS servers which simply responds to requests 971 for DNS information. In such a configuration, an additional 972 dependency on the DHCP service would be introduced by this 973 mechanism. 975 Convergence Time 976 This mechanism has the same convergence time as the underlying 977 transport mechanism chosen. 979 Draft DDDT Report January 2002 981 Scenarios 982 This mechanism works in the same scenarios as the underlying 983 transport mechanism chosen. 985 6.2. DNS 987 DNS itself can be used, as long as the transport mechanism ensures 988 that discovery messages reach DNS servers, to obtain the DNS 989 server list, default domain name, and domain search path. 991 DNS has many record types that could be used. For example, SOA 992 and NS records contain relevant information. However, the name 993 resolution configuration information which an administrator 994 desires that a host should use may not match the usual 995 configuration of the DNS server (e.g., might use a different 996 domain name). Hence, using information encoded in separate 997 records is more flexible. It is also desirable that an 998 administrator can give different configuration information to 999 hosts in different subnets, since this capability exists when a 1000 DHCP server is present. 1002 There are many ways to accomplish the above. On the query side, 1003 the subnet prefix can be encoded in the hostname part of the 1004 query. On the response side, the server list, domain name, and 1005 search path can be encoded in the response, potentially using SRV 1006 records [SRV] with a special encoding, or using TXT records [TXT], 1007 or even defining a new record type. 1009 6.2.1. Evaluation 1011 Scalability 1012 The mechanism has one round trip to the DNS server and the 1013 security overhead. Using Secret Keys, if possible, will 1014 produce no more packets, but some processing on the DNS server 1015 to match the clients secret key using [TSIG]. Using Diffie- 1016 Hellman with [DNSSEC], if many clients attempt this at the same 1017 time will put extreme processing demands on the DNS server. 1018 But it is doubtful that one or a few DNS Servers will handle 1019 1000's of clients. See Security Evaluation below. 1021 Security 1022 If the client can preconfigure a well known private or public 1024 Draft DDDT Report January 2002 1026 key then TSIG or DNSSEC can be used with the same packets 1027 presented for the query. If this is not the case, then either 1028 TSIG keys will have to be negotiated using [TKEY] or a Diffie- 1029 Hellman Key [DIFFSEC] exchange will have to take place using 1030 DNSSEC. After the client has the proper key then the query can 1031 be performed. 1033 Time to Deploy 1034 This mechanism can be deployed now. If the address provided to 1035 the Client is an Anycast address then resolver implementations 1036 would have to not use the present mechanisms to verify the 1037 source address of a QUERY response is equivalent to the 1038 destination address of the QUERY to the DNS Server. Likewise 1039 for Multicast DNS. 1041 Business Motivation 1042 All DNS suppliers are now implementing TSIG and DNSSEC. The 1043 biggest business motivation for this mechanism is that it 1044 requires the least new code of any of the mechanisms evaluated, 1045 and provides the greatest robustness since there are no 1046 dependencies on other protocols or services. 1048 Standardization 1049 If SRV or TXT records are used, there is no standardization 1050 required other than the specific mechanism document in the IPv6 1051 Working Group. If a new record type is required, the DNSEXT 1052 Working Group would be involved. 1054 Fate Sharing 1055 There are no dependencies on other than the normal DNS 1056 processes implemented today, nor are there any new dependencies 1057 created from these content messages. 1059 Convergence Time 1060 There is no degradation in convergence time with this content 1061 set of messages, other than awaiting for a failed network to 1062 respond again or a DNS Server(s) to come back up after reboot. 1063 Once the resolver has done the DNS queries the knowledge from 1064 the server on most implementations becomes stateful and stored 1065 to non-volatile storage. In the case of embedded systems with 1066 no non-volatile storage the DNS Server address would have to be 1067 relearned. 1069 Scenarios 1070 This mechanism should work in all scenarios discussed. 1072 Draft DDDT Report January 2002 1074 6.3. Node Information Query 1076 ICMPv6 node information query [NODEINFO] provides a way to query 1077 IPv6 addresses assigned to a machine. This could be used to query 1078 IPv6 unicast address for a DNS server, from a DNS server IPv6 1079 anycast/multicast address. 1081 To get a local domain name and search path, new query types 1082 (QTypes) would need to be defined for these information types. 1084 6.3.1. Evaluation 1086 Scalability 1087 As ICMPv6 node information query will be handled by the DNS 1088 server node itself, there is no need for running an additional 1089 server. This mechanism has the same scalability properties as 1090 the underlying transport mechanism chosen. 1092 Security 1093 IPsec is the only way to prevent malicious packets. It depends 1094 on the actual transport protocol used with ICMPv6 node 1095 information query, if IPsec is usable or not. For example, it 1096 is rather hard to use IPsec with anycast/multicast, so IPsec 1097 may not work well if we use anycast/multicast. 1099 Time to Deploy 1100 While there exist some implementations of node information 1101 queries, implementation is not ubiquitous. 1103 Business Motivation 1104 There does not seem to be any strong business motivation for 1105 implementing a node information query parser, in preference to 1106 other options. 1108 Standardization 1109 The ICMPv6 node information query has not made it to RFC status 1110 yet, but is owned by the IPv6 Working Group. 1112 Fate Sharing 1113 Depends on how we combine this with other mechanisms, and 1115 Draft DDDT Report January 2002 1117 transport protocols. 1119 Convergence Time 1120 Depends on how we combine this with other mechanisms, and 1121 transport protocols. 1123 Scenarios 1124 This mechanism should work in all scenarios in which the 1125 transport mechanism works. 1127 6.4. RA Extensions 1129 The basic approach is to define a new ND option that would contain 1130 the DNS information. Existing ND transport mechanisms (i.e., 1131 advertisements and solicitations) mechanisms would be used. This 1132 would work in the same way that nodes learn about routers and 1133 prefixes, etc. 1135 A ND new option would be defined that routers could send in router 1136 advertisements. 1138 This approach has two modes of operation. The first is routers 1139 periodically send the DNS Configuration Option in their periodic 1140 router advertisements. 1142 The second mode is that nodes needing DNS information can send a 1143 solicitation to the routers on the link requesting the DNS 1144 Configuration options. 1146 This approach has an issue that the DNS information needs to be 1147 configured in the routers doing the advertisements. There are 1148 several approaches to this: 1150 a) Many routers may already have most of this information 1151 configured. Routers also function as hosts and may have DNS 1152 server addresses, default domain, and list of domains to search 1153 in their configuration file. For example, Cisco IOS [IOS] has 1154 the following commands: 1156 Draft DDDT Report January 2002 1158 ip domain-name name 1159 Define a default domain name that the Cisco IOS software 1160 will use to complete unqualified host names. 1162 ip domain-list name 1163 Define a list of default domain names to complete 1164 unqualified host names. 1166 ip name-server server-addr1 [server-addr2...server-addr6] 1167 Specify one or more hosts that supply name information. 1169 At least in the case of Cisco routers, and probably most 1170 others, no additional work is needed to add the DNS information 1171 to the routers. 1173 b) The next approach, that is consistent with current router 1174 management practice, is to configure the router manually with 1175 the DNS information that they would advertise w/ IPv6 ND. This 1176 could be done by CLI commands as shown above and/or by other 1177 mechanisms normally used to configure routers (e.g., web 1178 interfaces, proprietary tools, etc.) 1180 The work to implement this is minor and part of implementation 1181 the feature in the router. No new management/distribution 1182 protocols. 1184 c) The next approach, also consistent with current router 1185 management practice, is that the router configuration files are 1186 created centrally and remotely installed on the router. This 1187 is done today with a mix to special tools, text editors, pearl 1188 scripts, vendor management systems, etc. It is very common 1189 practice to create files of CLI commands and push them to the 1190 routers. No new management and/or distribution protocols are 1191 required. 1193 d) Create or extend an SNMP MIB (do we have an ND MIB?) that 1194 contains this information and use existing management tools to 1195 set the information in the router. Also common practice and no 1196 new management/distribution protocols. A MIB is required and 1197 extensions to management tools to support the new variables. 1199 Draft DDDT Report January 2002 1201 e) Extend Router Renumbering (RR) to contain this information and 1202 use it to advertise it to the routers. This is mostly 1203 consistent with what RR does and allows control reasonable fine 1204 grained control of to allow different information per router or 1205 even per interface. 1207 Without changing the intended usage of Router Advertisements, the 1208 natural transport mechanism used would be Link-scoped multicast 1209 with router-only response. 1211 6.4.1. Evaluation 1213 Scalability 1214 This mechanism has excellent scalability properties. It scales 1215 as well as ND and DNS does currently. All of the multicast 1216 traffic is local to the link. The periodic advertisement rates 1217 can be tuned to environment including turn it off completely 1218 and relying on the solicitation/advertisement mode. 1220 Security 1221 ND does not currently have authentication mechanisms built in, 1222 but there is ongoing work to investigate using AH with ND. 1223 This approach would use what ever solution is selected for ND 1224 authentication. 1226 Time to Deploy 1227 This approach requires implementation in nodes wishing to learn 1228 DNS information and in routers to provide the information. The 1229 router will need to be configured with the DNS information 1230 needed in the advertisements. 1232 It is a relatively minor amount of work to add a new option to 1233 an existing router and/or node implementations of ND. It 1234 should be possible to deploy it quickly once the details are 1235 scoped out and the implementations are developed. There is no 1236 new network wide services such as multicast or anycast that 1237 need to be deployed. There are no dependencies with other 1238 protocols. 1240 Business Motivation 1241 The business motivation is very good. The implementation, 1243 Draft DDDT Report January 2002 1245 documentation, and support cost are minor and very much in line 1246 with existing ND features. There are no new protocols and/or 1247 transports to deploy, document, and support. 1249 Devices wanting to discover DNS servers already have to have an 1250 RA parser in them. It is expected that implementors would find 1251 it easier to extend an existing parser than to add a new 1252 parser. 1254 Standardization 1255 This mechanism would require a new RA option format to be 1256 standardized. This would be done by the IPv6 Working Group. 1258 Fate Sharing 1259 The only fate sharing issue raised is that it ties the 1260 discovery of DNS information with the operation of routers on a 1261 link. This is very similar to the common practice with IPv4 of 1262 using Bootp relays in routers to communicate with DHCP servers, 1263 so in practical terms the issue is very small. 1265 No changes are made to DNS servers or way nodes communicate 1266 with DNS servers. 1268 Convergence Time 1269 Convergence time is similar to current IPv4 DNS operation using 1270 DHCP for DNS discovery. No new convergence issues are created. 1271 If one of a set of DNS servers is unavailable (e.g., down, 1272 isolated, etc.), then normal DNS recover mechanisms will select 1273 an alternative DNS servers. 1275 If one of a set of routers is unavailable, other routers on the 1276 link will continue providing the DNS information. 1278 If the last DNS server is unavailable, then it is down. If the 1279 last router is unavailable, then new nodes will not be able to 1280 learn DNS information or reach any DNS server through the 1281 router. 1283 Scenarios 1284 This mechanism works over a broad range of scenarios. It 1285 should work as well on links that are high performance (e.g., 1287 Draft DDDT Report January 2002 1289 LANs) and low performance (e.g., wireless). 1291 However, this mechanism relies on routers and does not support 1292 DNS servers on isolated links. Other local DNS server 1293 discovery mechanisms (e.g., multicast DNS) would be needed. 1294 This approach is believed to be compatible with multicast DNS 1295 approach being developed in the IETF. 1297 It can be used in either a periodic multicast advertisement, or 1298 a solicitation/advertisement mode. 1300 6.5. SLP 1302 The Service Location Protocol [RFC 2608] provides a general 1303 framework for service discovery. Services are modeled on the 1304 basis of their type, location, and a set of attributes. 1306 Clients use SLP to request services on the basis of the attributes 1307 required and retrieve both the location and attributes of all 1308 services fulfilling the request. In the case of DNS server 1309 discovery, a DNS client could discover the location, domain name 1310 and search path to use, all in one message round trip 1311 (SrvRqst/SrvRply) if the Attribute List Extension is used, or two 1312 round trips (SrvRqst/SrvRply, AttrRqst/AttrRply) if the Attribute 1313 List extension is not supported. 1315 Without changing the basic SLPv2 protocol, the natural transport 1316 mechanism used would be Site-scoped multicast. 1318 6.5.1. Evaluation 1320 Scalability 1322 This mechanism has the same scalability properties as the 1323 underlying transport mechanism chosen. 1325 Security 1326 SLPv2 provides its own security so that those who obtain 1327 service location and attribute information can verify the 1328 signature over it. These digital signatures are calculated 1329 using keys which are distributed by some external mechanism 1330 (SLPv2 does not provide mechanisms for cryptographic key 1332 Draft DDDT Report January 2002 1334 distribution). 1336 Time to Deploy 1337 SLPv2 for IPv6 is not yet a proposed standard. It will shortly 1338 enter IETF last call. 1340 There are no IPv6 SLPv2 implementations yet. SLPv2 over IPv4 1341 has been implemented by many vendors and is used for a variety 1342 of purposes. 1344 Business Motivation 1345 Rather than each protocol supplying its own service discovery 1346 protocol, SLP can provide a general purpose mechanism which 1347 will minimize the software required and allow for common 1348 operational considerations and management. 1350 Standardization 1351 SLPv2 is a Proposed Standard. SLPv2 over IPv6 and the 1352 Attribute List Extension are both about to enter IETF last call 1353 before being advanced to Proposed Standard. 1355 Fate Sharing 1356 SLP would require an additional protocol to be used to 1357 configure DNS resolvers - namely, a SLP user agent library. 1358 DNS servers would need to be advertised using a SLP service 1359 agent - this functionality could be provided by a library 1360 invoked by a DNS server, or by an additional service running on 1361 the DNS server host (although this is more complicated and less 1362 assured of not advertising the DNS server when it is in fact 1363 not available). 1365 Convergence Time 1366 If no directory agents are deployed, convergence time is on the 1367 order of milliseconds: the only way that a DNS resolver could 1368 discover a DNS server which was not available would be if the 1369 DNS server failed after answering that it was available. 1371 If directory agents are available, convergence depends on the 1372 soft state registration lifetime - which could be of any 1373 granularity on the order of seconds - but typically is on the 1375 Draft DDDT Report January 2002 1377 order of minutes. During this interval it is possible for a 1378 client to discover a service which has gone off line since the 1379 service location has been cached by a directory agent 1380 temporarily. 1382 Scenarios 1384 o Isolated link with a DNS server but no routers 1386 SLP requests multicast on the link would enable DNS clients 1387 to directly discover DNS servers, domain name and search 1388 path. 1390 The DNS clients and servers would have to make use of a SLP 1391 library to accomplish this. Another alternative is a 1392 service advertising process co-resident on the DNS server 1393 host which advertises the DNS server on its behalf. In this 1394 case, no modification of the DNS server would be necessary. 1396 o Site with routers, but no multicast routing enabled 1398 Routers use SLP to discover DNS servers on attached links. 1399 The routers can then use other mechanisms to distribute the 1400 location of the DNS servers (add an anycast routing entry 1401 for each DNS server, send extensions to routing 1402 advertisements, etc.) 1404 DNS clients could use link-scoped multicast SLP discovery, 1405 and routers could answer these requests on behalf of DNS 1406 servers. The problem with this approach is that it does not 1407 specify the way in which DNS server locations are propagated 1408 between routers. 1410 Thus, SLP can be used as a mechanism to provide dynamic and 1411 decentralized service discovery for the system, but only 1412 between the routers and the DNS servers. The mechanism 1413 between the routers to propagate DNS service locations would 1414 have to be satisfied by some additional protocol (such as 1415 OSPF extensions). 1417 In summary, a link-scoped multicast with router-assist 1418 transport mechanism would be needed in this scenario. 1420 Draft DDDT Report January 2002 1422 o NBMA Link 1424 This scenario could not be supported without changing the 1425 SLP protocol to work with anycast addresses. However, it is 1426 not expected that this is a very important scenario. 1428 6.6. Something New 1430 Any number of other mechanisms (e.g., HTTP, SNMP, etc.) could 1431 also be extended, but it is expected that any other mechanism 1432 would take at least as long to deploy, and have no significant 1433 advantage over the other mechanisms evaluated above. 1435 7. Recommendations 1437 Based on team discussion, and WG consensus at IETF 49, the 1438 recommendation for transport mechanism is to use site-scoped 1439 anycast. That is, IANA should allocate a well-known site-local 1440 anycast address for DNS servers. 1442 No specific recommendation is made regarding using anycast for 1443 discovery-only or for actual name resolution. However, we observe 1444 that choice can be made by individual sites as follows. Nodes 1445 will use the anycast address to discover DNS-specific information 1446 such as the domain name, search path, and DNS server list. If the 1447 DNS server list contains just the anycast address itself, the 1448 anycast address will also be used for name resolution. 1450 Based on subsequent team discussion, the recommendation to the WG 1451 regarding the content mechanism is to use DNS. That is, the 1452 recommendation is that the WG should define the details of how the 1453 DNS server list, domain name, and search path, can be encoded in 1454 DNS records. The team's initial recommendation is that the IPv6 1455 WG investigate whether SRV records are sufficient, and if not, 1456 then either TXT records or a new record type should be used. It 1457 is believed that the information should and can be encoded in a 1458 single response message. 1460 Finally, it is recommended that the "Other stateful configuration" 1461 flag in the Router Advertisement be used to control whether to use 1462 DHCP or this mechanism. That is, the analysis and recommendations 1463 in this document apply only to links where the "Other stateful 1464 configuration" flag is zero. 1466 Draft DDDT Report January 2002 1468 8. Appendix A: Summary Grid 1470 Figure 1 summarizes information on transport mechanisms: 1472 |Any(Disc)|Any(Res)|LnkM(Rtr)|LnkM(Gen)|SiteM 1473 -----------------+---------+--------+---------+---------+--------- 1474 SW upgrades |-/S/SR |-/S/SR |R |R |UR 1475 -----------------+---------+--------+---------+---------+--------- 1476 Reconfig changes |S |- |R |S |- 1477 -----------------+---------+--------+---------+---------+--------- 1478 New dependencies |- |- |router, |linkmcast|multicast 1479 | | |linkmcast| |routing, 1480 | | | | |linkmcast 1481 -----------------+---------+--------+---------+---------+--------- 1482 Convergence time |fast |per-rtg |fast |fast |fast 1483 -----------------+---------+--------+---------+---------+--------- 1484 Can use IKE |no |no |no |no |no 1485 -----------------+---------+--------+---------+---------+--------- 1486 Standards work |-/ipngwg |-/ipngwg|ipngwg |ipngwg |- 1487 -----------------+---------+--------+---------+---------+--------- 1488 Deployable "now" |yes |yes |no |no |no 1489 -----------------+---------+--------+---------+---------+--------- 1491 Figure 1: Transport Mechanism Summary 1493 Key: 1494 / separates multiple deployment options 1495 - = No devices 1496 S = All DNS servers 1497 SR = All routers with directly-connected DNS servers 1498 UR = All routers which don't have multicast routing implemented 1499 R = All routers 1501 SW upgrades = what boxes, other than devices wanting to discover 1502 DNS servers, require software upgrades? 1504 Reconfig changes = what boxes need to be reconfigured when the set 1505 of DNS servers changes? 1507 New dependencies = what new dependencies are added? 1509 Convergence Time = how long does it take to contact a new DNS 1510 server when a server/link/router fails? "Fast" = a device can 1511 immediately use an alternate server if reachable. "Per-rtg" = 1512 Device must wait until routing converges for the unreachable 1513 Draft DDDT Report January 2002 1515 address. 1517 Can use IKE = can IKE be used for key negotiation? 1519 Standards work = what WGs would be required to standardize new 1520 items? 1522 Deployable "now" = could a new client using this mechanism be 1523 deployed immediately, without requiring implementation of new code 1524 for routers or servers? 1526 Figure 2 summarizes information on content mechanisms: 1528 |DHCP |DNS |NIQ |RA |SLP 1529 ------------------+----------+---------+---------+---------+--------- 1530 Round trips used |1 |1 |1 |1 |1 1531 ------------------+----------+---------+---------+---------+--------- 1532 Has own signatures|yes |yes |- |no |yes 1533 ------------------+----------+---------+---------+---------+--------- 1534 Has own key dist |- |yes |- |- |- 1535 ------------------+----------+---------+---------+---------+--------- 1536 Standards work |dhc |dnsext? |ipngwg |ipngwg |svrloc 1537 ------------------+----------+---------+---------+---------+--------- 1538 Need addl parser |in servers|- |yes |- |yes 1539 ------------------+----------+---------+---------+---------+--------- 1540 Generalizable |yes |yes |yes |- |yes 1541 ------------------+----------+---------+---------+---------+--------- 1542 Deployable "now" |no |yes |no |no |no 1543 ------------------+----------+---------+---------+---------+--------- 1545 Figure 2: Content Mechanism Summary 1547 Round trips used = How many round trips are required? 1549 Has own signatures? = Does the content have its own signature 1550 facility? (a "no" means it relies on IPsec) 1552 Standards work = what WGs would be required to standardize new 1553 items? 1555 Need addl parser = besides any parsers that a device must already 1556 implement to perform basic name resolution, does the mechanism 1557 introduce a requirement for another parser? 1559 Generalizable = can the mechanism be generalized to allow 1560 Draft DDDT Report January 2002 1562 discovery of other types of information or services? 1564 Deployable "now" = could a new client using this mechanism be 1565 deployed immediately, without requiring implementation of new code 1566 for routers or servers? 1567 Draft DDDT Report January 2002 1569 9. Authors' Addresses 1571 Bernard Aboba 1572 Microsoft 1573 One Microsoft Way 1574 Redmond, WA 98052, USA 1575 Email: aboba@internaut.com 1577 Jim Bound 1578 Compaq Computer Corporation 1579 110 Spitbrook Road ZK3-3/U14 1580 Nashua, NH 03062-2698 1581 Email: bound@zk3.dec.com 1583 Steve Deering 1584 Cisco Systems, Inc. 1585 170 West Tasman Drive 1586 San Jose, CA 95134-1706, USA 1587 Email: deering@cisco.com 1589 Erik Guttman 1590 Sun Microsystems 1591 Bahnstr. 2 1592 74915 Waibstadt, Germany 1593 Email: erik.guttman@sun.com 1595 Jun-ichiro itojun HAGINO 1596 Research Laboratory, Internet Initiative Japan Inc. 1597 Takebashi Yasuda Bldg., 1598 3-13 Kanda Nishiki-cho, 1599 Chiyoda-ku, Tokyo 101-0054, JAPAN 1600 Email: itojun@iijlab.net 1602 Robert M. Hinden 1603 Nokia 1604 313 Fairchild Drive 1605 Mountain View, CA 94043, USA 1606 Email: hinden@iprg.nokia.com 1608 Tatuya JINMEI 1609 Research and Development Center, Toshiba Corporation 1610 1 Komukai Toshiba-cho, Kawasaki-chi 1611 Kanagawa 212-8582 1612 Japan 1613 Email: jinmei@isl.rdc.toshiba.co.jp 1615 Draft DDDT Report January 2002 1617 Atsushi Onoe 1618 Internet Systems Laboratory, IN Laboratories, Sony Corporation 1619 6-7-35 Kitashinagawa, Shinagawa-ku, Tokyo 141-0001 1620 Japan 1621 Email: onoe@sm.sony.co.jp 1623 Hesham Soliman 1624 Ericsson Australia 1625 61 Rigall St., Broadmeadows 1626 Melbourne, Victoria 3047 1627 Australia 1628 Email: Hesham.Soliman@ericsson.com.au 1630 David Thaler 1631 Microsoft 1632 One Microsoft Way 1633 Redmond, WA 98052, USA 1634 Email: dthaler@microsoft.com 1636 10. References 1638 [ANYCAST] 1639 Partridge, C., Mendez, T., and W. Milliken, "Host Anycasting 1640 Service", RFC 1546, November 1993. 1642 [ADDRARCH] 1643 Hinden, R., and S. Deering, "IP Version 6 Addressing 1644 Architecture", RFC 2373, July 1998. 1646 [DHCPAUTH] 1647 Droms, R., and W. Arbaugh, "Authentication for DHCP 1648 Messages", draft-ietf-dhc-authentication-16.txt, January 1649 2001. 1651 [DIFFSEC] 1652 D. Eastlake, "Storage of Diffie-Hellman Keys in the Domain 1653 Name System (DNS)", RFC 2539, March 1999. 1655 [DNSSEC] 1656 D. Eastlake, "Domain Name System Security Extensions", RFC 1657 2535, March 1999. 1659 [DOMSEARCH] 1660 B. Aboba, "DHCP Domain Search Option", draft-aboba-dhc- 1662 Draft DDDT Report January 2002 1664 domsearch-01.txt, December 2000. 1666 [HOST-ANYCAST] 1667 Haberman, B., and D. Thaler, "Host-based Anycast using MLD", 1668 draft-haberman-ipngwg-host-anycast-00.txt, February 2001. 1670 [IOS] 1671 Cisco IOS Release 12.0 Configuration Guides, 1672 http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/12cgcr/cbkixol.htm 1674 [ITOJUN-ANYCAST] 1675 Jun-ichiro Hagino and K. Ettikan, "An analysis of IPv6 1676 anycast", draft-itojun-ipv6-anycast-analysis-02.txt, February 1677 2001. 1679 [MDNS] 1680 Esibov, L., Aboba, B., and D. Thaler, "Multicast DNS", draft- 1681 ietf-dnsext-mdns-00.txt, November 2000. 1683 [ND] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery 1684 for IP Version 6 (IPv6)", RFC 2461, December 1998. 1686 [NODEINFO] 1687 Matt Crawford, "IPv6 Node Information Queries", draft-ietf- 1688 ipngwg-icmp-name-lookups-07.txt, August 2000. 1690 [RFC1034] 1691 P. Mockapetris, "Domain Names - Concepts and Facilities", STD 1692 13, RFC 1034, November 1987. 1694 [RFC1035] 1695 P. Mockapetris, "Domain Names - Implementation and 1696 Specifications", STD 13, RFC 1035, November 1987. 1698 [RIPMD5] 1699 Baker, F., and R. Atkinson, "RIP-2 MD5 Authentication", RFC 1700 2082, January 1997. 1702 [RIPNG] 1703 Malkin, G., and R. Minnear, "RIPng for IPv6", RFC 2080, 1704 January 1997. 1706 [SLPv2] 1707 Guttman, E., Perkins, C., Veizades, J., and M. Day, "Service 1708 Location Protocol, Version 2", RFC 2608, June 1999. 1710 Draft DDDT Report January 2002 1712 [SRV] 1713 Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 1714 specifying the location of services (DNS SRV)", RFC 2782, 1715 February 2000. 1717 [TSIG] 1718 Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington, 1719 "Secret Key Transaction Authentication for DNS (TSIG)", RFC 1720 2845, May 2000. 1722 [TKEY] 1723 D. Eastlake, "Secret Key Establishment for DNS (TKEY RR)" RFC 1724 2930, September 2000 1726 [TXT] 1727 R. Rosenbaum, "Using the Domain Name System To Store 1728 Arbitrary String Attributes", RFC 1464, May 1993. 1730 Draft DDDT Report January 2002 1732 11. Full Copyright Statement 1734 Copyright (C) The Internet Society (2001). All Rights Reserved. 1736 This document and translations of it may be copied and furnished 1737 to others, and derivative works that comment on or otherwise 1738 explain it or assist in its implementation may be prepared, 1739 copied, published and distributed, in whole or in part, without 1740 restriction of any kind, provided that the above copyright notice 1741 and this paragraph are included on all such copies and derivative 1742 works. However, this document itself may not be modified in any 1743 way, such as by removing the copyright notice or references to the 1744 Internet Society or other Internet organizations, except as needed 1745 for the purpose of developing Internet standards in which case the 1746 procedures for copyrights defined in the Internet Standards 1747 process must be followed, or as required to translate it into 1748 languages other than English. 1750 The limited permissions granted above are perpetual and will not 1751 be revoked by the Internet Society or its successors or assigns. 1753 This document and the information contained herein is provided on 1754 an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 1755 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 1756 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1757 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1758 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR 1759 PURPOSE." 1760 Draft DDDT Report January 2002 1762 Table of Contents 1764 1 Introduction .............................................. 2 1765 2 Requirements .............................................. 2 1766 3 Criteria for Evaluation ................................... 3 1767 4 Taxonomy .................................................. 4 1768 5 Transport Mechanisms ...................................... 4 1769 5.1 Anycast for DNS server discovery only ................... 4 1770 5.1.1 Evaluation ............................................ 7 1771 5.2 Anycast for name resolution ............................. 9 1772 5.2.1 Configuration ......................................... 10 1773 5.2.2 Actual use ............................................ 10 1774 5.2.3 Evaluation ............................................ 10 1775 5.3 Link-scoped multicast with router-only responses ........ 13 1776 5.3.1 Evaluation ............................................ 13 1777 5.4 Link-scoped multicast (with router assist) .............. 16 1778 5.4.1 Evaluation ............................................ 16 1779 5.5 Site-scoped multicast ................................... 17 1780 5.5.1 Evaluation ............................................ 19 1781 5.6 Hybrid .................................................. 21 1782 6 Message Content Mechanisms ................................ 21 1783 6.1 DHCP .................................................... 21 1784 6.1.1 Evaluation ............................................ 22 1785 6.2 DNS ..................................................... 23 1786 6.2.1 Evaluation ............................................ 23 1787 6.3 Node Information Query .................................. 25 1788 6.3.1 Evaluation ............................................ 25 1789 6.4 RA Extensions ........................................... 26 1790 6.4.1 Evaluation ............................................ 28 1791 6.5 SLP ..................................................... 30 1792 6.5.1 Evaluation ............................................ 30 1793 6.6 Something New ........................................... 33 1794 7 Recommendations ........................................... 33 1795 8 Appendix A: Summary Grid .................................. 34 1796 9 Authors' Addresses ........................................ 37 1797 10 References ............................................... 38 1798 11 Full Copyright Statement ................................. 41