idnits 2.17.1 draft-ietf-dnsop-ipv6-dns-configuration-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1.a on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1259. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1236. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1243. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1249. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == 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 a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 978: '... DHCP client SHOULD require DHCP aut...' 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 (May 5, 2005) is 6924 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '1' is defined on line 1067, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 1070, but no explicit reference was found in the text == Unused Reference: '26' is defined on line 1156, but no explicit reference was found in the text == Unused Reference: '27' is defined on line 1160, but no explicit reference was found in the text == Unused Reference: '28' is defined on line 1164, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3667 (ref. '1') (Obsoleted by RFC 3978) ** Obsolete normative reference: RFC 3668 (ref. '2') (Obsoleted by RFC 3979) ** Obsolete normative reference: RFC 2461 (ref. '3') (Obsoleted by RFC 4861) ** Obsolete normative reference: RFC 2462 (ref. '4') (Obsoleted by RFC 4862) ** Obsolete normative reference: RFC 3315 (ref. '5') (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 3736 (ref. '6') (Obsoleted by RFC 8415) == Outdated reference: A later version (-12) exists of draft-jeong-dnsop-ipv6-dns-discovery-04 -- Obsolete informational reference (is this intentional?): RFC 3513 (ref. '12') (Obsoleted by RFC 4291) -- Obsolete informational reference (is this intentional?): RFC 3633 (ref. '17') (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 2535 (ref. '29') (Obsoleted by RFC 4033, RFC 4034, RFC 4035) == Outdated reference: A later version (-08) exists of draft-ietf-dnsop-dnssec-operational-practices-03 Summary: 13 errors (**), 0 flaws (~~), 9 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DNS Operations WG J. Jeong, Ed. 3 Internet-Draft ETRI/University of Minnesota 4 Expires: November 6, 2005 May 5, 2005 6 IPv6 Host Configuration of DNS Server Information Approaches 7 draft-ietf-dnsop-ipv6-dns-configuration-06.txt 9 Status of this Memo 11 This document is an Internet-Draft and is subject to all provisions 12 of Section 3 of RFC 3667. By submitting this Internet-Draft, each 13 author represents that any applicable patent or other IPR claims of 14 which he or she is aware have been or will be disclosed, and any of 15 which he or she become aware will be disclosed, in accordance with 16 RFC 3668. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on November 6, 2005. 36 Copyright Notice 38 Copyright (C) The Internet Society (2005). 40 Abstract 42 This document describes three approaches for IPv6 recursive DNS 43 server address configuration. It details the operational attributes 44 of three solutions: RA option, DHCPv6 option, and Well-known anycast 45 addresses for recursive DNS servers. Additionally, it suggests the 46 deployment scenarios in four kinds of networks, such as ISP, 47 Enterprise, 3GPP, and Unmanaged networks, considering multi-solution 48 resolution. Therefore, this document will give the audience a 49 guideline for IPv6 host DNS configuration. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 55 3. IPv6 DNS Configuration Approaches . . . . . . . . . . . . . . 7 56 3.1 RA Option . . . . . . . . . . . . . . . . . . . . . . . . 7 57 3.1.1 Advantages . . . . . . . . . . . . . . . . . . . . . . 8 58 3.1.2 Disadvantages . . . . . . . . . . . . . . . . . . . . 8 59 3.1.3 Observations . . . . . . . . . . . . . . . . . . . . . 9 60 3.2 DHCPv6 Option . . . . . . . . . . . . . . . . . . . . . . 9 61 3.2.1 Advantages . . . . . . . . . . . . . . . . . . . . . . 11 62 3.2.2 Disadvantages . . . . . . . . . . . . . . . . . . . . 12 63 3.2.3 Observations . . . . . . . . . . . . . . . . . . . . . 12 64 3.3 Well-known Anycast Addresses . . . . . . . . . . . . . . . 12 65 3.3.1 Advantages . . . . . . . . . . . . . . . . . . . . . . 13 66 3.3.2 Disadvantages . . . . . . . . . . . . . . . . . . . . 14 67 3.3.3 Observations . . . . . . . . . . . . . . . . . . . . . 14 68 4. Interworking among IPv6 DNS Configuration Approaches . . . . . 15 69 5. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 16 70 5.1 ISP Network . . . . . . . . . . . . . . . . . . . . . . . 16 71 5.1.1 RA Option Approach . . . . . . . . . . . . . . . . . . 16 72 5.1.2 DHCPv6 Option Approach . . . . . . . . . . . . . . . . 17 73 5.1.3 Well-known Anycast Addresses Approach . . . . . . . . 17 74 5.2 Enterprise Network . . . . . . . . . . . . . . . . . . . . 17 75 5.3 3GPP Network . . . . . . . . . . . . . . . . . . . . . . . 18 76 5.3.1 Currently Available Mechanisms and Recommendations . . 19 77 5.3.2 RA Extension . . . . . . . . . . . . . . . . . . . . . 19 78 5.3.3 Stateless DHCPv6 . . . . . . . . . . . . . . . . . . . 20 79 5.3.4 Well-known Addresses . . . . . . . . . . . . . . . . . 21 80 5.3.5 Recommendations . . . . . . . . . . . . . . . . . . . 21 81 5.4 Unmanaged Network . . . . . . . . . . . . . . . . . . . . 22 82 5.4.1 Case A: Gateway does not provide IPv6 at all . . . . . 22 83 5.4.2 Case B: A dual-stack gateway connected to a 84 dual-stack ISP . . . . . . . . . . . . . . . . . . . . 22 85 5.4.3 Case C: A dual-stack gateway connected to an 86 IPv4-only ISP . . . . . . . . . . . . . . . . . . . . 22 87 5.4.4 Case D: A gateway connected to an IPv6-only ISP . . . 23 88 6. Security Considerations . . . . . . . . . . . . . . . . . . . 24 89 6.1 RA Option . . . . . . . . . . . . . . . . . . . . . . . . 25 90 6.2 DHCPv6 Option . . . . . . . . . . . . . . . . . . . . . . 25 91 6.3 Well-known Anycast Addresses . . . . . . . . . . . . . . . 25 92 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 26 93 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28 94 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 95 9.1 Normative References . . . . . . . . . . . . . . . . . . . 29 96 9.2 Informative References . . . . . . . . . . . . . . . . . . 29 97 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 31 98 A. Link-layer Multicast Acknowledgements for RA Option . . . . . 32 99 Intellectual Property and Copyright Statements . . . . . . . . 33 101 1. Introduction 103 Neighbor Discovery (ND) for IP Version 6 and IPv6 Stateless Address 104 Autoconfiguration provide the ways to configure either fixed or 105 mobile nodes with one or more IPv6 addresses, default routes and some 106 other parameters [3][4]. To support the access to additional 107 services in the Internet that are identified by a DNS name, such as a 108 web server, the configuration of at least one recursive DNS server is 109 also needed for DNS name resolution. 111 This document describes three approaches of recursive DNS server 112 address configuration for IPv6 host: (a) RA option [8], (b) DHCPv6 113 option [5]-[7], and (c) Well-known anycast addresses for recursive 114 DNS servers [9]. Also, it suggests the applicable scenarios for four 115 kinds of networks: (a) ISP network, (b) Enterprise network, (c) 3GPP 116 network, and (d) Unmanaged network. 118 This document is just an analysis of each possible approach, and does 119 not make any recommendation on a particular one or on a combination 120 of particular ones. Some approaches may even not be adopted at all 121 as a result of further discussion. 123 Therefore, the objective of this document is to help the audience 124 select the approaches suitable for IPv6 host configuration of 125 recursive DNS servers. 127 2. Terminology 129 This document uses the terminology described in [3]-[9]. In 130 addition, a new term is defined below: 132 o Recursive DNS Server (RDNSS): A Recursive DNS Server is a name 133 server that offers the recursive service of DNS name resolution. 135 3. IPv6 DNS Configuration Approaches 137 In this section, the operational attributes of the three solutions 138 are described in detail. 140 3.1 RA Option 142 The RA approach is to define a new ND option called the RDNSS option 143 that contains a recursive DNS server address. Existing ND transport 144 mechanisms (i.e., advertisements and solicitations) are used. This 145 works in the same way that nodes learn about routers and prefixes. 146 An IPv6 host can configure the IPv6 addresses of one or more RDNSSes 147 via RA message periodically sent by a router or solicited by a Router 148 Solicitation (RS) [8]. 150 This approach needs RDNSS information to be configured in the routers 151 doing the advertisements. The configuration of RDNSS addresses can 152 be performed manually by an operator or other ways, such as automatic 153 configuration through a DHCPv6 client running on the router. When 154 advertising more than one RDNSS option, an RA message includes as 155 many RDNSS options as RDNSSes. 157 Through the ND protocol and RDNSS option along with a prefix 158 information option, an IPv6 host can perform its network 159 configuration of its IPv6 address and RDNSS simultaneously [3][4]. 160 The RA option for RDNSS can be used on any network that supports the 161 use of ND. 163 However, it is worth noting that some link layers, such as Wireless 164 LANs (e.g., IEEE 802.11 a/b/g), do not support reliable multicast, 165 which means that they cannot guarantee the timely delivery of RA 166 messages [25]-[28]. This is discussed in Appendix A. 168 The RA approach is useful in some mobile environments where the 169 addresses of the RDNSSes are changing because the RA option includes 170 a lifetime field that allows client to use RDNSSes nearer to the 171 client. This can be configured to a value that will require the 172 client to time out the entry and switch over to another RDNSS address 173 [8]. However, from the viewpoint of implementation, the lifetime 174 field would seem to make matters a bit more complex. Instead of just 175 writing to a DNS configuration file, such as resolv.conf for the list 176 of RDNSS addresses, we have to have a daemon around (or a program 177 that is called at the defined intervals) that keeps monitoring the 178 lifetime of RDNSSes all the time. 180 The preference value of RDNSS, included in the RDNSS option, allows 181 IPv6 hosts to select primary RDNSS among several RDNSSes; this can be 182 used for the load balancing of RDNSSes [8]. 184 3.1.1 Advantages 186 The RA option for RDNSS has a number of advantages. These include: 188 1. The RA option is an extension of existing ND/Autoconfig 189 mechanisms [3][4], and does not require a change in the base ND 190 protocol. 192 2. This approach, like ND, works well on a variety of link types 193 including point-to-point links, point-to-multipoint, and 194 multipoint-to-multipoint (i.e., Ethernet LANs), etc. RFC 2461 195 [3] states, however, that there may be some link types on which 196 ND is not feasible; on such links, some other mechanisms will be 197 needed for DNS configuration. 199 3. All of the information a host needs to run the basic Internet 200 applications such as the email, web, ftp, etc., can be obtained 201 with the addition of this option to ND and address 202 autoconfiguration. The use of a single mechanism is more 203 reliable and easier to provide than when the RDNSS information is 204 learned via another protocol mechanism. Debugging problems when 205 multiple protocol mechanisms are being used is harder and much 206 more complex. 208 4. This mechanism works over a broad range of scenarios and 209 leverages IPv6 ND. This works well on links that support 210 broadcast reliably (e.g., Ethernet LANs) but not necessarily on 211 other links (e.g., Wireless LANs): Refer to Appendix A. Also, 212 this works well on links that are high performance (e.g., 213 Ethernet LANs) and low performance (e.g., Cellular networks). In 214 the latter case, by combining the RDNSS information with the 215 other information in the RA, the host can learn all of the 216 information needed to use most Internet applications, such as the 217 web in a single packet. This not only saves bandwidth where this 218 is an issue, but also minimizes the delay needed to learn the 219 RDNSS information. 221 5. The RA approach could be used as a model for other similar types 222 of configuration information. New RA options for other server 223 addresses, such as NTP server address, that are common to all 224 clients on a subnet would be easy to define. 226 3.1.2 Disadvantages 228 1. ND is mostly implemented in the kernel of operating system. 229 Therefore, if ND supports the configuration of some additional 230 services, such as DNS servers, ND should be extended in the 231 kernel, and complemented by a user-land process. DHCPv6, 232 however, has more flexibility for the extension of service 233 discovery because it is an application layer protocol. 235 2. The current ND framework should be modified to facilitate the 236 synchronization between another ND cache for RDNSSes in the 237 kernel space and the DNS configuration file in the user space. 238 Because it is unacceptable to write and rewrite to the DNS 239 configuration file (e.g., resolv.conf) from the kernel, another 240 approach is needed. One simple approach to solve this is to have 241 a daemon listening to what the kernel conveys, and to have the 242 daemon do these steps, but such a daemon is not needed with the 243 current ND framework. 245 3. It is necessary to configure RDNSS addresses at least at one 246 router on every link where this information needs to be 247 configured via the RA option. 249 3.1.3 Observations 251 The proposed RDNSS RA option along with the IPv6 ND and 252 Autoconfiguration allows a host to obtain all of the information it 253 needs to access the basic Internet services like the web, email, ftp, 254 etc. This is preferable in the environments where hosts use RAs to 255 autoconfigure their addresses and all the hosts on the subnet share 256 the same router and server addresses. If the configuration 257 information can be obtained from a single mechanism, it is preferable 258 because it does not add additional delay, and it uses a minimum of 259 bandwidth. The environments like this include the homes, public 260 cellular networks, and enterprise environments where no per host 261 configuration is needed, but exclude public WLAN hot spots. 263 DHCPv6 is preferable where it is being used for address configuration 264 and if there is a need for host specific configuration [5]-[7]. The 265 environments like this are most likely to be the enterprise 266 environments where the local administration chooses to have per host 267 configuration control. 269 Note 271 The observation section is based on what the proponents of each 272 approach think makes a good overall solution. 274 3.2 DHCPv6 Option 276 DHCPv6 [5] includes the "DNS Recursive Name Server" option, through 277 which a host can obtain a list of IP addresses of recursive DNS 278 servers [7]. The DNS Recursive Name Server option carries a list of 279 IPv6 addresses of RDNSSes to which the host may send DNS queries. 280 The DNS servers are listed in the order of preference for use by the 281 DNS resolver on the host. 283 The DNS Recursive Name Server option can be carried in any DHCPv6 284 Reply message, in response to either a Request or an Information 285 request message. Thus, the DNS Recursive Name Server option can be 286 used either when DHCPv6 is used for address assignment, or when 287 DHCPv6 is used only for other configuration information as stateless 288 DHCPv6 [6]. 290 Stateless DHCPv6 can be deployed either using DHCPv6 servers running 291 on general-purpose computers, or on router hardware. Several router 292 vendors currently implement stateless DHCPv6 servers. Deploying 293 stateless DHCPv6 in routers has the advantage that no special 294 hardware is required, and should work well for networks where DHCPv6 295 is needed for very straightforward configuration of network devices. 297 However, routers can also act as DHCPv6 relay agents. In this case, 298 the DHCPv6 server need not be on the router - it can be on a general 299 purpose computer. This has the potential to give the operator of the 300 DHCPv6 server more flexibility in how the DHCPv6 server responds to 301 individual clients - clients can easily be given different 302 configuration information based on their identity, or for any other 303 reason. Nothing precludes adding this flexibility to a router, but 304 generally in current practice, DHCP servers running on general- 305 purpose hosts tend to have more configuration options than those that 306 are embedded in routers. 308 DHCPv6 currently provides a mechanism for reconfiguring DHCPv6 309 clients that use a stateful configuration assignment. To do this, 310 the DHCPv6 server sends a Reconfigure message to the client. The 311 client validates the Reconfigure message, and then contacts the 312 DHCPv6 server to obtain updated configuration information. Using 313 this mechanism, it is currently possible to propagate new 314 configuration information to DHCPv6 clients as this information 315 changes. 317 The DHC Working Group is currently studying an additional mechanism 318 through which configuration information, including the list of 319 RDNSSes, can be updated. The lifetime option for DHCPv6 [10] assigns 320 a lifetime to configuration information obtained through DHCPv6. At 321 the expiration of the lifetime, the host contacts the DHCPv6 server 322 to obtain updated configuration information, including the list of 323 RDNSSes. This lifetime gives the network administrator another 324 mechanism to configure hosts with new RDNSSes by controlling the time 325 at which the host refreshes the list. 327 The DHC Working Group has also discussed the possibility of defining 328 an extension to DHCPv6 that would allow the use of multicast to 329 provide configuration information to multiple hosts with a single 330 DHCPv6 message. Because of the lack of deployment experience, the WG 331 has deferred consideration of multicast DHCPv6 configuration at this 332 time. Experience with DHCPv4 has not identified a requirement for 333 multicast message delivery, even in large service provider networks 334 with tens of thousands of hosts that may initiate a DHCPv4 message 335 exchange simultaneously. 337 3.2.1 Advantages 339 The DHCPv6 option for RDNSS has a number of advantages. These 340 include: 342 1. DHCPv6 currently provides a general mechanism for conveying 343 network configuration information to clients. So configuring 344 DHCPv6 servers allows the network administrator to configure 345 RDNSSes along with the addresses of other network services, as 346 well as location-specific information like time zones. 348 2. As a consequence, when the network administrator goes to 349 configure DHCPv6, all the configuration information can be 350 managed through a single service, typically with a single user 351 interface and a single configuration database. 353 3. DHCPv6 allows for the configuration of a host with information 354 specific to that host, so that hosts on the same link can be 355 configured with different RDNSSes as well as with other 356 configuration information. This capability is important in some 357 network deployments such as service provider networks or WiFi hot 358 spots. 360 4. A mechanism exists for extending DHCPv6 to support the 361 transmission of additional configuration that has not yet been 362 anticipated. 364 5. Hosts that require other configuration information such as the 365 addresses of SIP servers and NTP servers are likely to need 366 DHCPv6 for other configuration information. 368 6. The specification for configuration of RDNSSes through DHCPv6 is 369 available as an RFC. No new protocol extensions such as new 370 options are necessary. 372 7. Interoperability among independent implementations has been 373 demonstrated. 375 3.2.2 Disadvantages 377 The DHCPv6 option for RDNSS has a few disadvantages. These include: 379 1. Update currently requires message from server (however, see 380 [10]). 382 2. Because DNS information is not contained in RA messages, the host 383 must receive two messages from the router, and must transmit at 384 least one message to the router. On networks where bandwidth is 385 at a premium, this is a disadvantage, although on most networks 386 it is not a practical concern. 388 3. Increased latency for initial configuration - in addition to 389 waiting for an RA message, the client must now exchange packets 390 with a DHCPv6 server; even if it is locally installed on a 391 router, this will slightly extend the time required to configure 392 the client. For clients that are moving rapidly from one network 393 to another, this will be a disadvantage. 395 3.2.3 Observations 397 In the general case, on general-purpose networks, stateless DHCPv6 398 provides significant advantages and no significant disadvantages. 399 Even in the case where bandwidth is at a premium and low latency is 400 desired, if hosts require other configuration information in addition 401 to a list of RDNSSes or if hosts must be configured selectively, 402 those hosts will use DHCPv6 and the use of the DHCPv6 DNS recursive 403 name server option will be advantageous. 405 However, we are aware of some applications where it would be 406 preferable to put the RDNSS information into an RA packet; for 407 example, on a cell phone network, where bandwidth is at a premium and 408 extremely low latency is desired. The final DNS configuration draft 409 should be written so as to allow these special applications to be 410 handled using DNS information in the RA packet. 412 3.3 Well-known Anycast Addresses 414 Anycast uses the same routing system as unicast [11]. However, 415 administrative entities are local ones. The local entities may 416 accept unicast routes (including default routes) to anycast servers 417 from adjacent entities. The administrative entities should not 418 advertise their peers routes to their internal anycast servers, if 419 they want to prohibit external access from some peers to the servers. 420 If some advertisement is inevitable (such as the case with default 421 routes), the packets to the servers should be blocked at the boundary 422 of the entities. Thus, for this anycast, not only unicast routing 423 but also unicast ND protocols can be used as is. 425 First of all, the well-known anycast addresses approach is much 426 different from that discussed at IPv6 Working Group in the past [9]. 427 It should be noted that "anycast" in this memo is simpler than that 428 of RFC 1546 [11] and RFC 3513 [12] where it is assumed to be 429 prohibited to have multiple servers on a single link sharing an 430 anycast address. That is, on a link, an anycast address is assumed 431 to be unique. DNS clients today already have redundancy by having 432 multiple well-known anycast addresses configured as RDNSS addresses. 433 There is no point in having multiple RDNSSes sharing an anycast 434 address on a single link. 436 The approach with well-known anycast addresses is to set multiple 437 well-known anycast addresses in clients' resolver configuration files 438 from the beginning, say, as factory default. Thus, there is no 439 transport mechanism and no packet format [9]. 441 An anycast address is an address shared by multiple servers (in this 442 case, the servers are RDNSSes). A request from a client to the 443 anycast address is routed to a server selected by the routing system. 444 However, it is a bad idea to mandate "site" boundary on anycast 445 addresses, because most users just do not have their own servers and 446 want to access their ISPs' across their site boundaries. Larger 447 sites may also depend on their ISPs or may have their own RDNSSes 448 within "site" boundaries. 450 3.3.1 Advantages 452 The basic advantage of the well-known addresses approach is that it 453 uses no transport mechanism. Thus, 455 1. There is no delay to get the response and no further delay by 456 packet losses. 458 2. The approach can be combined with any other configuration 459 mechanisms, such as the RA-based approach and DHCP based 460 approach, as well as the factory default configuration. 462 3. The approach works over any environment where DNS works. 464 Another advantage is that the approach needs to configure DNS servers 465 as a router, but nothing else. Considering that DNS servers do need 466 configuration, the amount of overall configuration effort is 467 proportional to the number of the DNS servers and scales linearly. 468 It should be noted that, in the simplest case where a subscriber to 469 an ISP does not have any DNS server, the subscriber naturally 470 accesses DNS servers of the ISP even though the subscriber and the 471 ISP do nothing and there is no protocol to exchange DNS server 472 information between the subscriber and the ISP. 474 3.3.2 Disadvantages 476 Well-known anycast addresses approach requires that DNS servers (or 477 routers near it as a proxy) act as routers to advertise their anycast 478 addresses to the routing system, which requires some configuration 479 (see the last paragraph of the previous section on the scalability of 480 the effort). 482 3.3.3 Observations 484 If other approaches are used in addition, the well-known anycast 485 addresses should also be set in RA or DHCP configuration files to 486 reduce the configuration effort of users. 488 The redundancy by multiple RDNSSes is better provided by multiple 489 servers having different anycast addresses than multiple servers 490 sharing the same anycast address because the former approach allows 491 stale servers to still generate routes to their anycast addresses. 492 Thus, in a routing domain (or domains sharing DNS servers), there 493 will be only one server having an anycast address unless the domain 494 is so large that load distribution is necessary. 496 Small ISPs will operate one RDNSS at each anycast address which is 497 shared by all the subscribers. Large ISPs may operate multiple 498 RDNSSes at each anycast address to distribute and reduce load, where 499 the boundary between RDNSSes may be fixed (redundancy is still 500 provided by multiple addresses) or change dynamically. DNS packets 501 with the well-known anycast addresses are not expected (though not 502 prohibited) to cross ISP boundaries, as ISPs are expected to be able 503 to take care of themselves. 505 Because "anycast" in this memo is simpler than that of RFC 1546 [11] 506 and RFC 3513 [12] where it is assumed to be administratively 507 prohibited to have multiple servers on a single link sharing an 508 anycast address, anycast in this memo should be implemented as 509 UNICAST of RFC 2461 [3] and RFC 3513 [12]. As a result, ND-related 510 instability disappears. Thus, anycast in well-known anycast 511 addresses approach can and should use the anycast address as a source 512 unicast (according to RFC 3513 [12]) address of packets of UDP and 513 TCP responses. With TCP, if a route flips and packets to an anycast 514 address are routed to a new server, it is expected that the flip is 515 detected by ICMP or sequence number inconsistency and the TCP 516 connection is reset and retried. 518 4. Interworking among IPv6 DNS Configuration Approaches 520 Three approaches can work together for IPv6 host configuration of 521 RDNSS. This section shows a consideration on how these approaches 522 can interwork each other. 524 For ordering between RA and DHCP approaches, the O (Other stateful 525 configuration) flag in RA message can be used [8][32]. If no RDNSS 526 option is included, an IPv6 host may perform DNS configuration 527 through DHCPv6 [5]-[7] regardless of whether the O flag is set or 528 not. 530 The well-known anycast addresses approach fully interworks with the 531 other approaches. That is, the other approaches can remove the 532 configuration effort on servers by using the well-known addresses as 533 the default configuration. Moreover, the clients preconfigured with 534 the well-known anycast addresses can be further configured to use 535 other approaches to override the well-known addresses, if the 536 configuration information from other approaches is available. 537 Otherwise, all the clients need to have the well-known anycast 538 addresses preconfigured. In order to use the anycast approach along 539 with two other approaches, there are three choices as follows: 541 1. The first choice is that well-known addresses are used as last 542 resort, when an IPv6 host cannot get RDNSS information through RA 543 and DHCP. The well-known anycast addresses have to be 544 preconfigured in all of IPv6 hosts' resolver configuration files. 546 2. The second is that an IPv6 host can configure well-known 547 addresses as the most preferable in its configuration file even 548 though either an RA option or DHCP option is available. 550 3. The last is that the well-known anycast addresses can be set in 551 RA or DHCP configuration to reduce the configuration effort of 552 users. According to either the RA or DHCP mechanism, the well- 553 known addresses can be obtained by an IPv6 host. Because this 554 approach is the most convenient for users, the last option is 555 recommended. 557 Note 559 This section does not necessarily mean this document suggests 560 adopting all these three approaches and making them interwork in the 561 way described here. In fact, some approaches may even not be adopted 562 at all as a result of further discussion. 564 5. Deployment Scenarios 566 Regarding the DNS configuration on the IPv6 host, several mechanisms 567 are being considered at the DNSOP Working Group such as RA option, 568 DHCPv6 option and well-known preconfigured anycast addresses as of 569 today, and this document is a final result from the long thread. In 570 this section, we suggest four applicable scenarios of three 571 approaches for IPv6 DNS configuration. 573 Note 575 In the applicable scenarios, authors do not implicitly push any 576 specific approaches into the restricted environments. No enforcement 577 is in each scenario and all mentioned scenarios are probable. The 578 main objective of this work is to provide a useful guideline for IPv6 579 DNS configuration. 581 5.1 ISP Network 583 A characteristic of ISP network is that multiple Customer Premises 584 Equipment (CPE) devices are connected to IPv6 PE (Provider Edge) 585 routers and each PE connects multiple CPE devices to the backbone 586 network infrastructure [13]. The CPEs may be hosts or routers. 588 In the case where the CPE is a router, there is a customer network 589 that is connected to the ISP backbone through the CPE. Typically, 590 each customer network gets a different IPv6 prefix from an IPv6 PE 591 router, but the same RDNSS configuration will be distributed. 593 This section discusses how the different approaches to distributing 594 DNS information are compared in an ISP network. 596 5.1.1 RA Option Approach 598 When the CPE is a host, the RA option for RDNSS can be used to allow 599 the CPE to get RDNSS information as well as /64 prefix information 600 for stateless address autoconfiguration at the same time when the 601 host is attached to a new subnet [8]. Because an IPv6 host must 602 receive at least one RA message for stateless address 603 autoconfiguration and router configuration, the host could receive 604 RDNSS configuration information in that RA without the overhead of an 605 additional message exchange. 607 When the CPE is a router, the CPE may accept the RDNSS information 608 from the RA on the interface connected to the ISP, and copy that 609 information into the RAs advertised in the customer network. 611 This approach is more valuable in the mobile host scenario, in which 612 the host must receive at least an RA message for detecting a new 613 network, than in other scenarios generally although administrator 614 should configure RDNSS information on the routers. Secure ND [14] 615 can provide extended security when using RA messages. 617 5.1.2 DHCPv6 Option Approach 619 DHCPv6 can be used for RDNSS configuration through the use of the DNS 620 option, and can provide other configuration information in the same 621 message with RDNSS configuration [5]-[7]. The DHCPv6 DNS option is 622 already in place for DHCPv6 as RFC 3646 [7] and DHCPv6-lite or 623 stateless DHCP [6] is nowhere as complex as a full DHCPv6 624 implementation. DHCP is a client-server model protocol, so ISPs can 625 handle user identification on its network intentionally, and also 626 authenticated DHCP [15] can be used for secure message exchange. 628 The expected model for deployment of IPv6 service by ISPs is to 629 assign a prefix to each customer, which will be used by the customer 630 gateway to assign a /64 prefix to each network in the customer's 631 network. Prefix delegation with DHCP (DHCPv6 PD) has already been 632 adopted by ISPs for automating the assignment of the customer prefix 633 to the customer gateway [17]. DNS configuration can be carried in 634 the same DHCPv6 message exchange used for DHCPv6 to efficiently 635 provide that information, along with any other configuration 636 information needed by the customer gateway or customer network. This 637 service model can be useful to Home or SOHO subscribers. The Home or 638 SOHO gateway, which is a customer gateway for ISP, can then pass that 639 RDNSS configuration information to the hosts in the customer network 640 through DHCP. 642 5.1.3 Well-known Anycast Addresses Approach 644 The well-known anycast addresses approach is also a feasible and 645 simple mechanism for ISP [9]. The use of well-known anycast 646 addresses avoids some of the security risks in rogue messages sent 647 through an external protocol like RA or DHCPv6. The configuration of 648 hosts for the use of well-known anycast addresses requires no 649 protocol or manual configuration, but the configuration of routing 650 for the anycast addresses requires intervention on the part of the 651 network administrator. Also, the number of special addresses would 652 be equal to the number of RDNSSes that could be made available to 653 subscribers. 655 5.2 Enterprise Network 657 Enterprise network is defined as a network that has multiple internal 658 links, one or more router connections, to one or more Providers and 659 is actively managed by a network operations entity [16]. An 660 enterprise network can get network prefixes from an ISP by either 661 manual configuration or prefix delegation [17]. In most cases, 662 because an enterprise network manages its own DNS domains, it 663 operates its own DNS servers for the domains. These DNS servers 664 within enterprise network process recursive DNS name resolution 665 requests from IPv6 hosts as RDNSSes. The RDNSS configuration in the 666 enterprise network can be performed like in Section 4, in which three 667 approaches can be used together as follows: 669 1. An IPv6 host can decide which approach is or may be used in its 670 subnet with the O flag in RA message [8][32]. As the first 671 choice in Section 4, well-known anycast addresses can be used as 672 a last resort when RDNSS information cannot be obtained through 673 either an RA option or DHCP option. This case needs IPv6 hosts 674 to preconfigure the well-known anycast addresses in their DNS 675 configuration files. 677 2. When the enterprise prefers the well-known anycast approach to 678 others, IPv6 hosts should preconfigure the well-known anycast 679 addresses like in the first choice. 681 3. The last choice, a more convenient and transparent way, does not 682 need IPv6 hosts to preconfigure the well-known anycast addresses 683 because the addresses are delivered to IPv6 hosts via either the 684 RA option or DHCPv6 option as if they were unicast addresses. 685 This way is most recommended for the sake of user's convenience. 687 5.3 3GPP Network 689 The IPv6 DNS configuration is a missing part of IPv6 690 autoconfiguration and an important part of the basic IPv6 691 functionality in the 3GPP User Equipment (UE). The higher level 692 description of the 3GPP architecture can be found in [18], and 693 transition to IPv6 in 3GPP networks is analyzed in [19] and [20]. 695 In the 3GPP architecture, there is a dedicated link between the UE 696 and the GGSN called the Packet Data Protocol (PDP) Context. This 697 link is created through the PDP Context activation procedure [21]. 698 There is a separate PDP context type for IPv4 and IPv6 traffic. If a 699 3GPP UE user is communicating using IPv6 (having an active IPv6 PDP 700 context), it cannot be assumed that (s)he has simultaneously an 701 active IPv4 PDP context, and DNS queries could be done using IPv4. A 702 3GPP UE can thus be an IPv6 node, and it needs to somehow discover 703 the address of the RDNSS. Before IP-based services (e.g., web 704 browsing or e-mail) can be used, the IPv6 (and IPv4) RDNSS addresses 705 need to be discovered in the 3GPP UE. 707 Section 5.3.1 briefly summarizes currently available mechanisms in 708 3GPP networks and recommendations. 5.3.2 analyzes the Router 709 Advertisement based solution, 5.3.3 analyzes the Stateless DHCPv6 710 mechanism, and 5.3.4 analyzes the Well-known addresses approach. 711 Section 5.3.5 finally summarizes the recommendations. 713 5.3.1 Currently Available Mechanisms and Recommendations 715 3GPP has defined a mechanism, in which RDNSS addresses can be 716 received in the PDP context activation (a control plane mechanism). 717 That is called the Protocol Configuration Options Information Element 718 (PCO-IE) mechanism [22]. The RDNSS addresses can also be received 719 over the air (using text messages), or typed in manually in the UE. 720 Note that the two last mechanisms are not very well scalable. The UE 721 user most probably does not want to type IPv6 RDNSS addresses 722 manually in his/her UE. The use of well-known addresses is briefly 723 discussed in section 5.3.4. 725 It is seen that the mechanisms above most probably are not sufficient 726 for the 3GPP environment. IPv6 is intended to operate in a zero- 727 configuration manner, no matter what the underlying network 728 infrastructure is. Typically, the RDNSS address is needed to make an 729 IPv6 node operational - and the DNS configuration should be as simple 730 as the address autoconfiguration mechanism. It must also be noted 731 that there will be additional IP interfaces in some near future 3GPP 732 UEs, e.g., WLAN, and 3GPP-specific DNS configuration mechanisms (such 733 as PCO-IE [22]) do not work for those IP interfaces. In other words, 734 a good IPv6 DNS configuration mechanism should also work in a multi- 735 access network environment. 737 From a 3GPP point of view, the best IPv6 DNS configuration solution 738 is feasible for a very large number of IPv6-capable UEs (can be even 739 hundreds of millions in one operator's network), is automatic and 740 thus requires no user action. It is suggested to standardize a 741 lightweight, stateless mechanism that works in all network 742 environments. The solution could then be used for 3GPP, 3GPP2, WLAN 743 and other access network technologies. A light, stateless IPv6 DNS 744 configuration mechanism is thus not only needed in 3GPP networks, but 745 also 3GPP networks and UEs would certainly benefit from the new 746 mechanism. 748 5.3.2 RA Extension 750 Router Advertisement extension [8] is a lightweight IPv6 DNS 751 configuration mechanism that requires minor changes in the 3GPP UE 752 IPv6 stack and Gateway GPRS Support Node (GGSN, the default router in 753 the 3GPP architecture) IPv6 stack. This solution can be specified in 754 the IETF (no action needed in the 3GPP) and taken in use in 3GPP UEs 755 and GGSNs 757 In this solution, an IPv6-capable UE configures DNS information via 758 RA message sent by its default router (GGSN), i.e., RDNSS option for 759 recursive DNS server is included in the RA message. This solution is 760 easily scalable for a very large number of UEs. The operator can 761 configure the RDNSS addresses in the GGSN as a part of normal GGSN 762 configuration. The IPv6 RDNSS address is received in the Router 763 Advertisement, and an extra Round Trip Time (RTT) for asking RDNSS 764 addresses can be avoided. 766 If thinking about the cons, this mechanism still requires 767 standardization effort in the IETF, and the end nodes and routers 768 need to support this mechanism. The equipment software update 769 should, however, be pretty straightforward, and new IPv6 equipment 770 could support RA extension already from the beginning. 772 5.3.3 Stateless DHCPv6 774 DHCPv6-based solution needs the implementation of Stateless DHCP [6] 775 and DHCPv6 DNS options [7] in the UE, and a DHCPv6 server in the 776 operator's network. A possible configuration is such that the GGSN 777 works as a DHCP relay. 779 Pros for Stateless DHCPv6-based solution are 781 1. Stateless DHCPv6 is a standardized mechanism. 783 2. DHCPv6 can be used for receiving other configuration information 784 than RDNSS addresses, e.g., SIP server addresses. 786 3. DHCPv6 works in different network environments. 788 4. When DHCPv6 service is deployed through a single, centralized 789 server, the RDNSS configuration information can be updated by the 790 network administrator at a single source. 792 Some issues with DHCPv6 in 3GPP networks are listed below: 794 1. DHCPv6 requires an additional server in the network unless the 795 (Stateless) DHCPv6 functionality is integrated into a router 796 already existing, and that means one box more to be maintained. 798 2. DHCPv6 is not necessarily needed for 3GPP UE IPv6 addressing 799 (3GPP Stateless Address Autoconfiguration is typically used), and 800 not automatically implemented in 3GPP IPv6 UEs. 802 3. Scalability and reliability of DHCPv6 in very large 3GPP networks 803 (with tens or hundreds of millions of UEs) may be an issue, at 804 least the redundancy needs to be taken care of. However, if the 805 DHCPv6 service is integrated into the network elements, such as a 806 router operating system, scalability and reliability is 807 comparable with other DNS configuration approaches. 809 4. It is sub-optimal to utilize the radio resources in 3GPP networks 810 for DHCPv6 messages if there is a simpler alternative available. 812 * The use of Stateless DHCPv6 adds one round trip delay to the 813 case in which the UE can start transmitting data right after 814 the Router Advertisement. 816 5. If the DNS information (suddenly) changes, Stateless DHCPv6 can 817 not automatically update the UE, see [23]. 819 5.3.4 Well-known Addresses 821 Using well-known addresses is also a feasible and a light mechanism 822 for 3GPP UEs. Those well-known addresses can be preconfigured in the 823 UE software and the operator makes the corresponding configuration on 824 the network side. So this is a very easy mechanism for the UE, but 825 requires some configuration work in the network. When using well- 826 known addresses, UE forwards queries to any of the preconfigured 827 addresses. In the current proposal [9], IPv6 anycast addresses are 828 suggested. 830 Note 832 The IPv6 DNS configuration proposal based on the use of well-known 833 site-local addresses developed at the IPv6 Working Group was seen as 834 a feasible mechanism for 3GPP UEs, but opposition by some people in 835 the IETF and finally deprecating IPv6 site-local addresses made it 836 impossible to standardize it. Note that this mechanism is 837 implemented in some existing operating systems today (also in some 838 3GPP UEs) as a last resort of IPv6 DNS configuration. 840 5.3.5 Recommendations 842 It is suggested that a lightweight, stateless DNS configuration 843 mechanism is specified as soon as possible. From a 3GPP UE and 844 network point of view, the Router Advertisement based mechanism looks 845 most promising. The sooner a light, stateless mechanism is 846 specified, the sooner we can get rid of using well-known site-local 847 addresses for IPv6 DNS configuration. 849 5.4 Unmanaged Network 851 There are 4 deployment scenarios of interest in unmanaged networks 852 [24]: 854 1. A gateway which does not provide IPv6 at all; 856 2. A dual-stack gateway connected to a dual-stack ISP; 858 3. A dual-stack gateway connected to an IPv4-only ISP; and 860 4. A gateway connected to an IPv6-only ISP. 862 5.4.1 Case A: Gateway does not provide IPv6 at all 864 In this case, the gateway does not provide IPv6; the ISP may or may 865 not provide IPv6. Automatic or Configured tunnels are the 866 recommended transition mechanisms for this scenario. 868 The case where dual-stack hosts behind an NAT, that need access to an 869 IPv6 RDNSS, cannot be entirely ruled out. The DNS configuration 870 mechanism has to work over the tunnel, and the underlying tunneling 871 mechanism could be implementing NAT traversal. The tunnel server 872 assumes the role of a relay (both for DHCP and Well-known anycast 873 addresses approaches). 875 RA-based mechanism is relatively straightforward in its operation, 876 assuming the tunnel server is also the IPv6 router emitting RAs. 877 Well-known anycast addresses approach seems also simple in operation 878 across the tunnel, but the deployment model using Well-known anycast 879 addresses in a tunneled environment is unclear or not well 880 understood. 882 5.4.2 Case B: A dual-stack gateway connected to a dual-stack ISP 884 This is similar to a typical IPv4 home user scenario, where DNS 885 configuration parameters are obtained using DHCP. Except that 886 Stateless DHCPv6 is used, as opposed to the IPv4 scenario where the 887 DHCP server is stateful (maintains the state for clients). 889 5.4.3 Case C: A dual-stack gateway connected to an IPv4-only ISP 891 This is similar to Case B. If a gateway provides IPv6 connectivity by 892 managing tunnels, then it is also supposed to provide access to an 893 RDNSS. Like this, the tunnel for IPv6 connectivity originates from 894 the dual-stack gateway instead of the host. 896 5.4.4 Case D: A gateway connected to an IPv6-only ISP 898 This is similar to Case B. 900 6. Security Considerations 902 As security requirements depend solely on applications and are 903 different application by application, there can be no generic 904 requirement defined at IP or application layer for DNS. 906 However, it should be noted that cryptographic security requires 907 configured secret information that full autoconfiguration and 908 cryptographic security are mutually exclusive. People insisting on 909 secure full autoconfiguration will get false security, false 910 autoconfiguration or both. 912 In some deployment scenarios [19], where cryptographic security is 913 required for applications, the secret information for the 914 cryptographic security is preconfigured through which application 915 specific configuration data, including those for DNS, can be securely 916 configured. It should be noted that if applications requiring 917 cryptographic security depend on DNS, the applications also require 918 cryptographic security to DNS. Therefore, the full autoconfiguration 919 of DNS is not acceptable. 921 However, with full autoconfiguration, weaker but still reasonable 922 security is being widely accepted and will continue to be acceptable. 923 That is, with full autoconfiguration, which means there is no 924 cryptographic security for the autoconfiguration, it is already 925 assumed that the local environment is secure enough that the 926 information from the local autoconfiguration server has acceptable 927 security even without cryptographic security. Thus, the 928 communication between the local DNS client and local DNS server has 929 acceptable security. 931 In autoconfiguring recursive servers, DNSSEC may be overkill, because 932 DNSSEC [29] needs the configuration and reconfiguration of clients at 933 root key roll-over [30][31]. Even if additional keys for secure key 934 roll-over are added at the initial configuration, they are as 935 vulnerable as the original keys to some forms of attacks, such as 936 social hacking. Another problem of using DNSSEC and 937 autoconfiguration together is that DNSSEC requires secure time, which 938 means secure communication with autoconfigured time servers, which 939 requires configured secret information. Therefore, in order that the 940 autoconfiguration may be secure, it requires configured secret 941 information. 943 If DNSSEC [29] is used and the signatures are verified on the client 944 host, the misconfiguration of a DNS server may be simply denial of 945 service. Also, if local routing environment is not reliable, clients 946 may be directed to a false resolver with the same IP address as the 947 true one. 949 6.1 RA Option 951 The security of RA option for RDNSS is the same as the ND protocol 952 security [3][8]. The RA option does not add any new vulnerability. 954 It should be noted that the vulnerability of ND is not worse and is a 955 subset of the attacks that any node attached to a LAN can do 956 independently of ND. A malicious node on a LAN can promiscuously 957 receive packets for any router's MAC address and send packets with 958 the router's MAC address as the source MAC address in the L2 header. 959 As a result, the L2 switches send packets addressed to the router to 960 the malicious node. Also, this attack can send redirects that tell 961 the hosts to send their traffic somewhere else. The malicious node 962 can send unsolicited RA or NA replies, answer RS or NS requests, etc. 963 All of this can be done independently of implementing ND. Therefore, 964 the RA option for RDNSS does not add to the vulnerability. 966 Security issues regarding the ND protocol were discussed at IETF SEND 967 (Securing Neighbor Discovery) Working Group and RFC 3971 for the ND 968 security has been published [14]. 970 6.2 DHCPv6 Option 972 The DNS Recursive Name Server option may be used by an intruder DHCP 973 server to cause DHCP clients to send DNS queries to an intruder DNS 974 recursive name server [7]. The results of these misdirected DNS 975 queries may be used to spoof DNS names. 977 To avoid attacks through the DNS Recursive Name Server option, the 978 DHCP client SHOULD require DHCP authentication (see section 979 "Authentication of DHCP messages" in RFC 3315 [5]) before installing 980 a list of DNS recursive name servers obtained through authenticated 981 DHCP. 983 6.3 Well-known Anycast Addresses 985 Well-known anycast addresses does not require configuration security 986 since there is no protocol [9]. 988 The DNS server with the preconfigured addresses are still reasonably 989 reliable, if local environment is reasonably secure, that is, there 990 is no active attackers receiving queries to the anycast addresses of 991 the servers and reply to them. 993 7. Contributors 995 Ralph Droms 996 Cisco Systems, Inc. 997 1414 Massachusetts Ave. 998 Boxboro, MA 01719 999 US 1001 Phone: +1 978 936 1674 1002 Email: rdroms@cisco.com 1004 Robert M. Hinden 1005 Nokia 1006 313 Fairchild Drive 1007 Mountain View, CA 94043 1008 US 1010 Phone: +1 650 625 2004 1011 Email: bob.hinden@nokia.com 1013 Ted Lemon 1014 Nominum, Inc. 1015 950 Charter Street 1016 Redwood City, CA 94043 1017 US 1019 Email: Ted.Lemon@nominum.com 1021 Masataka Ohta 1022 Tokyo Institute of Technology 1023 2-12-1, O-okayama, Meguro-ku 1024 Tokyo 152-8552 1025 Japan 1027 Phone: +81 3 5734 3299 1028 Fax: +81 3 5734 3299 1029 Email: mohta@necom830.hpcl.titech.ac.jp 1031 Soohong Daniel Park 1032 Mobile Platform Laboratory, SAMSUNG Electronics 1033 416 Maetan-3dong, Yeongtong-Gu 1034 Suwon, Gyeonggi-Do 443-742 1035 Korea 1036 Phone: +82 31 200 4508 1037 Email: soohong.park@samsung.com 1039 Suresh Satapati 1040 Cisco Systems, Inc. 1041 San Jose, CA 95134 1042 US 1044 Email: satapati@cisco.com 1046 Juha Wiljakka 1047 Nokia 1048 Visiokatu 3 1049 FIN-33720, TAMPERE 1050 Finland 1052 Phone: +358 7180 48372 1053 Email: juha.wiljakka@nokia.com 1055 8. Acknowledgements 1057 This draft has greatly benefited from inputs by David Meyer, Rob 1058 Austein, Tatuya Jinmei, Pekka Savola, Tim Chown, Luc Beloeil, 1059 Christian Huitema, Thomas Narten, Pascal Thubert, and Greg Daley. 1060 Also, Tony Bonanno proofread this draft. The authors appreciate 1061 their contribution. 1063 9. References 1065 9.1 Normative References 1067 [1] Bradner, S., "IETF Rights in Contributions", RFC 3667, 1068 February 2004. 1070 [2] Bradner, S., "Intellectual Property Rights in IETF Technology", 1071 RFC 3668, February 2004. 1073 [3] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery 1074 for IP Version 6 (IPv6)", RFC 2461, December 1998. 1076 [4] Thomson, S. and T. Narten, "IPv6 Stateless Address 1077 Autoconfiguration", RFC 2462, December 1998. 1079 [5] Droms, R., Ed., "Dynamic Host Configuration Protocol for IPv6 1080 (DHCPv6)", RFC 3315, July 2003. 1082 [6] Droms, R., "Stateless Dynamic Host Configuration Protocol (DHCP) 1083 Service for IPv6", RFC 3736, April 2004. 1085 [7] Droms, R., Ed., "DNS Configuration options for Dynamic Host 1086 Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, 1087 December 2003. 1089 9.2 Informative References 1091 [8] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, "IPv6 DNS 1092 Discovery based on Router Advertisement", 1093 draft-jeong-dnsop-ipv6-dns-discovery-04.txt (Work in Progress), 1094 February 2005. 1096 [9] Ohta, M., "Preconfigured DNS Server Addresses", 1097 draft-ohta-preconfigured-dns-01.txt (Work in Progress), 1098 February 2004. 1100 [10] Venaas, S., Chown, T., and B. Volz, "Information Refresh Time 1101 Option for DHCPv6", draft-ietf-dhc-lifetime-03.txt (Work in 1102 Progress), January 2005. 1104 [11] Partridge, C., Mendez, T., and W. Milliken, "Host Anycasting 1105 Service", RFC 1546, November 1993. 1107 [12] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) 1108 Addressing Architecture", RFC 3513, April 2003. 1110 [13] Lind, M., Ed., "Scenarios and Analysis for Introduction IPv6 1111 into ISP Networks", RFC 4029, March 2005. 1113 [14] Arkko, J., Ed., "SEcure Neighbor Discovery (SEND)", RFC 3971, 1114 March 2005. 1116 [15] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages", 1117 RFC 3118, June 2001. 1119 [16] Bound, J., Ed., "IPv6 Enterprise Network Scenarios", 1120 draft-ietf-v6ops-ent-scenarios-05.txt (Work in Progress), 1121 July 2004. 1123 [17] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host 1124 Configuration Protocol (DHCP) version 6", RFC 3633, 1125 December 2003. 1127 [18] Wasserman, M., Ed., "Recommendations for IPv6 in 3GPP 1128 Standards", RFC 3314, September 2002. 1130 [19] Soininen, J., Ed., "Transition Scenarios for 3GPP Networks", 1131 RFC 3574, August 2003. 1133 [20] Wiljakka, J., Ed., "Analysis on IPv6 Transition in 3GPP 1134 Networks", draft-ietf-v6ops-3gpp-analysis-11.txt (Work in 1135 Progress), October 2004. 1137 [21] 3GPP TS 23.060 V5.4.0, "General Packet Radio Service (GPRS); 1138 Service description; Stage 2 (Release 5)", December 2002. 1140 [22] 3GPP TS 24.008 V5.8.0, "Mobile radio interface Layer 3 1141 specification; Core network protocols; Stage 3 (Release 5)", 1142 June 2003. 1144 [23] Chown, T., Venaas, S., and A. Vijayabhaskar, "Renumbering 1145 Requirements for Stateless DHCPv6", 1146 draft-ietf-dhc-stateless-dhcpv6-renumbering-02.txt (Work in 1147 Progress), October 2004. 1149 [24] Huitema, C., Ed., "Unmanaged Networks IPv6 Transition 1150 Scenarios", RFC 3750, April 2004. 1152 [25] ANSI/IEEE Std 802.11, "Part 11: Wireless LAN Medium Access 1153 Control (MAC) and Physical Layer (PHY) Specifications", 1154 March 1999. 1156 [26] IEEE Std 802.11a, "Part 11: Wireless LAN Medium Access Control 1157 (MAC) and Physical Layer (PHY) specifications: High-speed 1158 Physical Layer in the 5 GHZ Band", September 1999. 1160 [27] IEEE Std 802.11b, "Part 11: Wireless LAN Medium Access Control 1161 (MAC) and Physical Layer (PHY) specifications: Higher-Speed 1162 Physical Layer Extension in the 2.4 GHz Band", September 1999. 1164 [28] IEEE P802.11g/D8.2, "Part 11: Wireless LAN Medium Access 1165 Control (MAC) and Physical Layer (PHY) specifications: Further 1166 Higher Data Rate Extension in the 2.4 GHz Band", April 2003. 1168 [29] Eastlake, D., "Domain Name System Security Extensions", 1169 RFC 2535, March 1999. 1171 [30] Kolkman, O. and R. Gieben, "DNSSEC Operational Practices", 1172 draft-ietf-dnsop-dnssec-operational-practices-03.txt (Work in 1173 Progress), December 2004. 1175 [31] Guette, G. and O. Courtay, "Requirements for Automated Key 1176 Rollover in DNSSEC", 1177 draft-ietf-dnsop-key-rollover-requirements-02.txt (Work in 1178 Progress), January 2005. 1180 [32] Park, S., Madanapalli, S., and T. Jinmei, "Considerations on M 1181 and O Flags of IPv6 Router Advertisement", 1182 draft-ietf-ipv6-ra-mo-flags-01.txt (Work in Progress), 1183 March 2005. 1185 Author's Address 1187 Jaehoon Paul Jeong (editor) 1188 ETRI/Department of Computer Science and Engineering 1189 University of Minnesota 1190 117 Pleasant Street SE 1191 Minneapolis, MN 55455 1192 US 1194 Phone: +1 651 587 7774 1195 Fax: +1 612 625 2002 1196 Email: jjeong@cs.umn.edu 1197 URI: http://www.cs.umn.edu/~jjeong/ 1199 Appendix A. Link-layer Multicast Acknowledgements for RA Option 1201 One benefit of an RA option [8] is to be able to multicast the 1202 advertisements, reducing the need for duplicated unicast 1203 communications. 1205 However, some link-layers may not support this as well as others. 1206 Consider, for example, WLAN networks where multicast is unreliable. 1207 The unreliability problem is caused by lack of ACK for multicast, 1208 especially on the path from the Access Point (AP) to the Station 1209 (STA), which is specific to CSMA/CA of WLAN, such as IEEE 802.11 1210 a/b/g [25]-[28]. That is, a multicast packet is unacknowledged on 1211 the path from the AP to the STA, but acknowledged in the reverse 1212 direction from the STA to the AP [25]. For example, when a router is 1213 placed at wired network connected to an AP, a host may sometimes not 1214 receive RA message advertised through the AP. Therefore, the RA 1215 option solution might not work well on a congested medium that uses 1216 unreliable multicast for RA. 1218 The fact that this problem has not been addressed in Neighbor 1219 Discovery [3] indicates that the extra link-layer acknowledgements 1220 have not been considered a serious problem till now. 1222 A possible mitigation technique could be to map all-nodes link- local 1223 multicast address to the link-layer broadcast address, and to rely on 1224 the ND retransmissions for message delivery in order to achieve more 1225 reliability. 1227 Intellectual Property Statement 1229 The IETF takes no position regarding the validity or scope of any 1230 Intellectual Property Rights or other rights that might be claimed to 1231 pertain to the implementation or use of the technology described in 1232 this document or the extent to which any license under such rights 1233 might or might not be available; nor does it represent that it has 1234 made any independent effort to identify any such rights. Information 1235 on the procedures with respect to rights in RFC documents can be 1236 found in BCP 78 and BCP 79. 1238 Copies of IPR disclosures made to the IETF Secretariat and any 1239 assurances of licenses to be made available, or the result of an 1240 attempt made to obtain a general license or permission for the use of 1241 such proprietary rights by implementers or users of this 1242 specification can be obtained from the IETF on-line IPR repository at 1243 http://www.ietf.org/ipr. 1245 The IETF invites any interested party to bring to its attention any 1246 copyrights, patents or patent applications, or other proprietary 1247 rights that may cover technology that may be required to implement 1248 this standard. Please address the information to the IETF at 1249 ietf-ipr@ietf.org. 1251 Disclaimer of Validity 1253 This document and the information contained herein are provided on an 1254 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1255 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1256 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1257 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1258 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1259 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1261 Copyright Statement 1263 Copyright (C) The Internet Society (2005). This document is subject 1264 to the rights, licenses and restrictions contained in BCP 78, and 1265 except as set forth therein, the authors retain all their rights. 1267 Acknowledgment 1269 Funding for the RFC Editor function is currently provided by the 1270 Internet Society.