idnits 2.17.1 draft-ietf-6man-rdnss-rfc6106bis-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 8, 2015) is 3120 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Obsolete informational reference (is this intentional?): RFC 3315 (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 3736 (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 5006 (Obsoleted by RFC 6106) -- Obsolete informational reference (is this intentional?): RFC 6106 (Obsoleted by RFC 8106) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Jeong 3 Internet-Draft Sungkyunkwan University 4 Obsoletes: 6106 (if approved) S. Park 5 Intended status: Standards Track SAMSUNG Electronics 6 Expires: April 10, 2016 L. Beloeil 7 France Telecom R&D 8 S. Madanapalli 9 iRam Technologies 10 October 8, 2015 12 IPv6 Router Advertisement Options for DNS Configuration 13 draft-ietf-6man-rdnss-rfc6106bis-05 15 Abstract 17 This document specifies IPv6 Router Advertisement options to allow 18 IPv6 routers to advertise a list of DNS recursive server addresses 19 and a DNS Search List to IPv6 hosts. 21 This document obsoletes RFC 6106 and allows a higher default value of 22 the lifetime of the RA DNS options to avoid the frequent expiry of 23 the options on links with a relatively high rate of packet loss. 25 Status of This Memo 27 This Internet-Draft is submitted to IETF in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF), its areas, and its working groups. Note that 32 other groups may also distribute working documents as Internet- 33 Drafts. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 The list of current Internet-Drafts can be accessed at 41 http://www.ietf.org/ietf/1id-abstracts.txt. 43 The list of Internet-Draft Shadow Directories can be accessed at 44 http://www.ietf.org/shadow.html. 46 This Internet-Draft will expire on April 10, 2016. 48 Copyright Notice 49 Copyright (c) 2015 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 1.1. Applicability Statements . . . . . . . . . . . . . . . . . 3 66 1.2. Coexistence of RA Options and DHCP Options for DNS 67 Configuration . . . . . . . . . . . . . . . . . . . . . . 4 68 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 69 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 70 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 71 5. Neighbor Discovery Extension . . . . . . . . . . . . . . . . . 5 72 5.1. Recursive DNS Server Option . . . . . . . . . . . . . . . 6 73 5.2. DNS Search List Option . . . . . . . . . . . . . . . . . . 7 74 5.3. Procedure of DNS Configuration . . . . . . . . . . . . . . 8 75 5.3.1. Procedure in IPv6 Host . . . . . . . . . . . . . . . . 8 76 5.3.2. Warnings for DNS Options Configuration . . . . . . . . 9 77 6. Implementation Considerations . . . . . . . . . . . . . . . . 9 78 6.1. DNS Repository Management . . . . . . . . . . . . . . . . 10 79 6.2. Synchronization between DNS Server List and Resolver 80 Repository . . . . . . . . . . . . . . . . . . . . . . . . 10 81 6.3. Synchronization between DNS Search List and Resolver 82 Repository . . . . . . . . . . . . . . . . . . . . . . . . 12 83 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 84 7.1. Security Threats . . . . . . . . . . . . . . . . . . . . . 13 85 7.2. Recommendations . . . . . . . . . . . . . . . . . . . . . 14 86 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 87 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 88 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 89 10.1. Normative References . . . . . . . . . . . . . . . . . . . 15 90 10.2. Informative References . . . . . . . . . . . . . . . . . . 15 91 Appendix A. Changes from RFC 5006 . . . . . . . . . . . . . . . . 17 92 Appendix B. Changes from RFC 6106 . . . . . . . . . . . . . . . . 17 94 1. Introduction 96 The purpose of this document is to standardize an IPv6 Router 97 Advertisement (RA) option for DNS Recursive Server Addresses used for 98 the DNS name resolution in IPv6 hosts. This RA option was originally 99 specified in an earlier Experimental specification [RFC5006]. This 100 document obsoletes [RFC6106], allowing a higher default value of the 101 lifetime of the RA DNS options to avoid the frequent expiry of the 102 options on links with a relatively high rate of packet loss, and also 103 making additional clarifications, see Appendix B for details. 105 Neighbor Discovery (ND) for IP version 6 and IPv6 stateless address 106 autoconfiguration provide ways to configure either fixed or mobile 107 nodes with one or more IPv6 addresses, default routers, and some 108 other parameters [RFC4861][RFC4862]. Most Internet services are 109 identified by using a DNS name. The two RA options defined in this 110 document provide the DNS information needed for an IPv6 host to reach 111 Internet services. 113 It is infeasible to manually configure nomadic hosts each time they 114 connect to a different network. While a one-time static 115 configuration is possible, it is generally not desirable on general- 116 purpose hosts such as laptops. For instance, locally defined name 117 spaces would not be available to the host if it were to run its own 118 name server software directly connected to the global DNS. 120 The DNS information can also be provided through DHCP [RFC3315] 121 [RFC3736][RFC3646]. However, the access to DNS is a fundamental 122 requirement for almost all hosts, so IPv6 stateless autoconfiguration 123 cannot stand on its own as an alternative deployment model in any 124 practical network without any support for DNS configuration. 126 These issues are not pressing in dual-stack networks as long as a DNS 127 server is available on the IPv4 side, but they become more critical 128 with the deployment of IPv6-only networks. As a result, this 129 document defines a mechanism based on IPv6 RA options to allow IPv6 130 hosts to perform the automatic DNS configuration. 132 1.1. Applicability Statements 134 RA-based DNS configuration is a useful alternative in networks where 135 an IPv6 host's address is autoconfigured through IPv6 stateless 136 address autoconfiguration and where there is either no DHCPv6 137 infrastructure at all or some hosts do not have a DHCPv6 client. The 138 intention is to enable the full configuration of basic networking 139 information for hosts without requiring DHCPv6. However, when in 140 many networks some additional information needs to be distributed, 141 those networks are likely to employ DHCPv6. In these networks, RA- 142 based DNS configuration may not be needed. 144 RA-based DNS configuration allows an IPv6 host to acquire the DNS 145 configuration (i.e., DNS recursive server addresses and DNS Search 146 List) for the link(s) to which the host is connected. Furthermore, 147 the host learns this DNS configuration from the same RA message that 148 provides configuration information for the link, thereby avoiding 149 also running DHCPv6. 151 The advantages and disadvantages of the RA-based approach are 152 discussed in [RFC4339] along with other approaches, such as the DHCP 153 and well-known anycast address approaches. 155 1.2. Coexistence of RA Options and DHCP Options for DNS Configuration 157 Two protocols exist to configure the DNS information on a host, the 158 Router Advertisement options described in this document and the 159 DHCPv6 options described in [RFC3646]. They can be used together. 160 The rules governing the decision to use stateful configuration 161 mechanisms are specified in [RFC4861]. Hosts conforming to this 162 specification MUST extract DNS information from Router Advertisement 163 messages, unless static DNS configuration has been specified by the 164 user. If there is DNS information available from multiple Router 165 Advertisements and/or from DHCP, the host MUST maintain an ordered 166 list of this information as specified in Section 5.3.1. 168 2. Requirements Language 170 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 171 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 172 document are to be interpreted as described in [RFC2119]. 174 3. Terminology 176 This document uses the terminology described in [RFC4861] and 177 [RFC4862]. In addition, four new terms are defined below: 179 o Recursive DNS Server (RDNSS): Server that provides a recursive DNS 180 resolution service for translating domain names into IP addresses 181 as defined in [RFC1034] and [RFC1035]. 183 o RDNSS Option: IPv6 RA option to deliver the RDNSS information to 184 IPv6 hosts [RFC4861]. 186 o DNS Search List (DNSSL): The list of DNS suffix domain names used 187 by IPv6 hosts when they perform DNS query searches for short, 188 unqualified domain names. 190 o DNSSL Option: IPv6 RA option to deliver the DNSSL information to 191 IPv6 hosts. 193 o DNS Repository: Two data structures for managing DNS Configuration 194 Information in the IPv6 protocol stack in addition to Neighbor 195 Cache and Destination Cache for Neighbor Discovery [RFC4861]. The 196 first data structure is the DNS Server List for RDNSS addresses 197 and the second is the DNS Search List for DNS search domain names. 199 o Resolver Repository: Configuration repository with RDNSS addresses 200 and a DNS Search List that a DNS resolver on the host uses for DNS 201 name resolution; for example, the Unix resolver file (i.e., /etc/ 202 resolv.conf) and Windows registry. 204 4. Overview 206 This document standardizes the ND option called the RDNSS option 207 defined in [RFC5006] that contains the addresses of recursive DNS 208 servers. This document also defines a new ND option called the DNSSL 209 option for the Domain Search List. This is to maintain parity with 210 the DHCPv6 options and to ensure that there is necessary 211 functionality to determine the search domains. 213 The existing ND message (i.e., Router Advertisement) is used to carry 214 this information. An IPv6 host can configure the IPv6 addresses of 215 one or more RDNSSes via RA messages. Through the RDNSS and DNSSL 216 options, along with the prefix information option based on the ND 217 protocol ([RFC4861] and [RFC4862]), an IPv6 host can perform the 218 network configuration of its IPv6 address and the DNS information 219 simultaneously without needing DHCPv6 for the DNS configuration. The 220 RA options for RDNSS and DNSSL can be used on any network that 221 supports the use of ND. 223 This approach requires the manual configuration or other automatic 224 mechanisms (e.g., DHCPv6 or vendor proprietary configuration 225 mechanisms) to configure the DNS information in routers sending the 226 advertisements. The automatic configuration of RDNSS addresses and a 227 DNS Search List in routers is out of scope for this document. 229 5. Neighbor Discovery Extension 231 The IPv6 DNS configuration mechanism in this document needs two new 232 ND options in Neighbor Discovery: (i) the Recursive DNS Server 233 (RDNSS) option and (ii) the DNS Search List (DNSSL) option. 235 5.1. Recursive DNS Server Option 237 The RDNSS option contains one or more IPv6 addresses of recursive DNS 238 servers. All of the addresses share the same Lifetime value. If it 239 is desirable to have different Lifetime values, multiple RDNSS 240 options can be used. Figure 1 shows the format of the RDNSS option. 242 0 1 2 3 243 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 245 | Type | Length | Reserved | 246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 247 | Lifetime | 248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 249 | | 250 : Addresses of IPv6 Recursive DNS Servers : 251 | | 252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 Figure 1: Recursive DNS Server (RDNSS) Option Format 256 Fields: 257 Type 8-bit identifier of the RDNSS option type as assigned 258 by the IANA: 25 260 Length 8-bit unsigned integer. The length of the option 261 (including the Type and Length fields) is in units of 262 8 octets. The minimum value is 3 if one IPv6 address 263 is contained in the option. Every additional RDNSS 264 address increases the length by 2. The Length field 265 is used by the receiver to determine the number of 266 IPv6 addresses in the option. 268 Lifetime 32-bit unsigned integer. The maximum time, in 269 seconds (relative to the time the packet is sent), 270 over which this RDNSS address MAY be used for name 271 resolution. The value of Lifetime SHOULD by default 272 be at least 3 * MaxRtrAdvInterval where 273 MaxRtrAdvInterval is the Maximum RA Interval defined 274 in [RFC4861]. A value of all one bits (0xffffffff) 275 represents infinity. A value of zero means that the 276 RDNSS address MUST no longer be used. 278 Addresses of IPv6 Recursive DNS Servers 279 One or more 128-bit IPv6 addresses of the recursive 280 DNS servers. The number of addresses is determined 281 by the Length field. That is, the number of 282 addresses is equal to (Length - 1) / 2. 284 Note: The addresses for recursive DNS servers in the RDNSS option 285 MAY be link-local addresses. Such link-local addresses SHOULD be 286 registered into the resolver repository along with the 287 corresponding link zone indices of the links that receive the 288 RDNSS option(s) for them. The link zone indices SHOULD be 289 represented in the textual format for scoped addresses as 290 described in [RFC4007]. When a resolver sends a DNS query message 291 to an RDNSS with a link-local address, it MUST use the 292 corresponding link. 294 5.2. DNS Search List Option 296 The DNSSL option contains one or more domain names of DNS suffixes. 297 All of the domain names share the same Lifetime value. If it is 298 desirable to have different Lifetime values, multiple DNSSL options 299 can be used. Figure 2 shows the format of the DNSSL option. 301 0 1 2 3 302 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 304 | Type | Length | Reserved | 305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 306 | Lifetime | 307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 308 | | 309 : Domain Names of DNS Search List : 310 | | 311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 313 Figure 2: DNS Search List (DNSSL) Option Format 315 Fields: 316 Type 8-bit identifier of the DNSSL option type as assigned 317 by the IANA: 31 319 Length 8-bit unsigned integer. The length of the option 320 (including the Type and Length fields) is in units of 321 8 octets. The minimum value is 2 if at least one 322 domain name is contained in the option. The Length 323 field is set to a multiple of 8 octets to accommodate 324 all the domain names in the field of Domain Names of 325 DNS Search List. 327 Lifetime 32-bit unsigned integer. The maximum time, in 328 seconds (relative to the time the packet is sent), 329 over which this DNSSL domain name MAY be used for 330 name resolution. The Lifetime value has the same 331 semantics as with the RDNSS option. That is, 332 Lifetime SHOULD by default be at least 333 3 * MaxRtrAdvInterval. A value of all one bits 334 (0xffffffff) represents infinity. A value of zero 335 means that the DNSSL domain name MUST no longer be 336 used. 338 Domain Names of DNS Search List 339 One or more domain names of DNS Search List that MUST 340 be encoded using the technique described in Section 341 3.1 of [RFC1035]. By this technique, each domain 342 name is represented as a sequence of labels ending in 343 a zero octet, defined as domain name representation. 344 For more than one domain name, the corresponding 345 domain name representations are concatenated as they 346 are. Note that for the simple decoding, the domain 347 names MUST NOT be encoded in a compressed form, as 348 described in Section 4.1.4 of [RFC1035]. Because the 349 size of this field MUST be a multiple of 8 octets, 350 for the minimum multiple including the domain name 351 representations, the remaining octets other than the 352 encoding parts of the domain name representations 353 MUST be padded with zeros. 355 5.3. Procedure of DNS Configuration 357 The procedure of DNS configuration through the RDNSS and DNSSL 358 options is the same as with any other ND option [RFC4861]. 360 5.3.1. Procedure in IPv6 Host 362 When an IPv6 host receives DNS options (i.e., RDNSS option and DNSSL 363 option) through RA messages, it processes the options as follows: 365 o The validity of DNS options is checked with the Length field; that 366 is, the value of the Length field in the RDNSS option is greater 367 than or equal to the minimum value (3), and the value of the 368 Length field in the DNSSL option is greater than or equal to the 369 minimum value (2). 371 o If the DNS options are valid, the host SHOULD copy the values of 372 the options into the DNS Repository and the Resolver Repository in 373 order. Otherwise, the host MUST discard the options. Refer to 374 Section 6 for the detailed procedure. 376 In the case where the DNS options of RDNSS and DNSSL can be obtained 377 from multiple sources, such as RA and DHCP, the IPv6 host SHOULD keep 378 some DNS options from all sources. Unless explicitly specified for 379 the discovery mechanism, the exact number of addresses and domain 380 names to keep is a matter of local policy and implementation choice. 381 However, the ability to store at least three RDNSS addresses (or 382 DNSSL domain names) from at least two different sources is 383 RECOMMENDED. The DNS options from Router Advertisements and DHCP 384 SHOULD be stored into the DNS Repository and Resolver Repository so 385 that information from DHCP appears there first and therefore takes 386 precedence. Thus, the DNS information from DHCP takes precedence 387 over that from RA for DNS queries. On the other hand, for DNS 388 options announced by RA, if some RAs use the Secure Neighbor 389 Discovery (SEND) protocol [RFC3971] for RA security, they MUST be 390 preferred over those that do not use SEND. Refer to Section 7 for 391 the detailed discussion on SEND for RA DNS options. 393 5.3.2. Warnings for DNS Options Configuration 395 There are two warnings for DNS options configuration: (i) warning for 396 multiple sources of DNS options and (ii) warning for multiple network 397 interfaces. First, in the case of multiple sources for DNS options 398 (e.g., RA and DHCP), an IPv6 host can configure its IP addresses from 399 these sources. In this case, it is not possible to control how the 400 host uses DNS information and what source addresses it uses to send 401 DNS queries. As a result, configurations where different information 402 is provided by different sources may lead to problems. Therefore, 403 the network administrator needs to configure DNS options in multiple 404 sources in order to prevent such problems from happening. 406 Second, if different DNS information is provided on different network 407 interfaces, this can lead to inconsistent behavior. The IETF is 408 working on solving this problem for both DNS and other information 409 obtained by multiple interfaces [MIF-PROBLEM][MIF-PRACTICE]. 411 6. Implementation Considerations 413 Note: This non-normative section gives some hints for implementing 414 the processing of the RDNSS and DNSSL options in an IPv6 host. 416 For the configuration and management of DNS information, the 417 advertised DNS configuration information can be stored and managed in 418 both the DNS Repository and the Resolver Repository. 420 In environments where the DNS information is stored in user space and 421 ND runs in the kernel, it is necessary to synchronize the DNS 422 information (i.e., RDNSS addresses and DNS search domain names) in 423 kernel space and the Resolver Repository in user space. For the 424 synchronization, an implementation where ND works in the kernel 425 should provide a write operation for updating DNS information from 426 the kernel to the Resolver Repository. One simple approach is to 427 have a daemon (or a program that is called at defined intervals) that 428 keeps monitoring the Lifetimes of RDNSS addresses and DNS search 429 domain names all the time. Whenever there is an expired entry in the 430 DNS Repository, the daemon can delete the corresponding entry from 431 the Resolver Repository. 433 6.1. DNS Repository Management 435 For DNS repository management, the kernel or user-space process 436 (depending on where RAs are processed) should maintain two data 437 structures: (i) DNS Server List that keeps the list of RDNSS 438 addresses and (ii) DNS Search List that keeps the list of DNS search 439 domain names. Each entry in these two lists consists of a pair of an 440 RDNSS address (or DNSSL domain name) and Expiration-time as follows: 442 o RDNSS address for DNS Server List: IPv6 address of the Recursive 443 DNS Server, which is available for recursive DNS resolution 444 service in the network advertising the RDNSS option. 446 o DNSSL domain name for DNS Search List: DNS suffix domain names, 447 which are used to perform DNS query searches for short, 448 unqualified domain names in the network advertising the DNSSL 449 option. 451 o Expiration-time for DNS Server List or DNS Search List: The time 452 when this entry becomes invalid. Expiration-time is set to the 453 value of the Lifetime field of the RDNSS option or DNSSL option 454 plus the current system time. Whenever a new RDNSS option with 455 the same address (or DNSSL option with the same domain name) is 456 received on the same interface as a previous RDNSS option (or 457 DNSSL option), this field is updated to have a new Expiration- 458 time. When Expiration-time becomes less than the current system 459 time, this entry is regarded as expired. 461 6.2. Synchronization between DNS Server List and Resolver Repository 463 When an IPv6 host receives the information of multiple RDNSS 464 addresses within a network (e.g., campus network and company network) 465 through an RA message with RDNSS option(s), it stores the RDNSS 466 addresses (in order) into both the DNS Server List and the Resolver 467 Repository. The processing of the RDNSS consists of (i) the 468 processing of RDNSS option(s) included in an RA message and (ii) the 469 handling of expired RDNSSes. The processing of RDNSS option(s) is as 470 follows: 472 Step (a): Receive and parse the RDNSS option(s). For the RDNSS 473 addresses in each RDNSS option, perform Steps (b) through (d). 475 Step (b): For each RDNSS address, check the following: If the 476 RDNSS address already exists in the DNS Server List and the RDNSS 477 option's Lifetime field is set to zero, delete the corresponding 478 RDNSS entry from both the DNS Server List and the Resolver 479 Repository in order to prevent the RDNSS address from being used 480 any more for certain reasons in network management, e.g., the 481 termination of the RDNSS or a renumbering situation. That is, the 482 RDNSS can resign from its DNS service because the machine running 483 the RDNSS is out of service intentionally or unintentionally. 484 Also, under the renumbering situation, the RDNSS's IPv6 address 485 will be changed, so the previous RDNSS address should not be used 486 any more. The processing of this RDNSS address is finished here. 487 Otherwise, go to Step (c). 489 Step (c): For each RDNSS address, if it already exists in the DNS 490 Server List, then just update the value of the Expiration-time 491 field according to the procedure specified in the third bullet of 492 Section 6.1. Otherwise, go to Step (d). 494 Step (d): For each RDNSS address, if it does not exist in the DNS 495 Server List, register the RDNSS address and Lifetime with the DNS 496 Server List and then insert the RDNSS address in front of the 497 Resolver Repository. In the case where the data structure for the 498 DNS Server List is full of RDNSS entries (that is, has more 499 RDNSSes than the sufficient number discussed in Section 5.3.1), 500 delete from the DNS Server List the entry with the shortest 501 Expiration-time (i.e., the entry that will expire first). The 502 corresponding RDNSS address is also deleted from the Resolver 503 Repository. For the ordering of RDNSS addresses in an RDNSS 504 option, position the first RDNSS address in the RDNSS option as 505 the first one in the Resolver Repository, the second RDNSS address 506 in the option as the second one in the repository, and so on. 507 This ordering allows the RDNSS addresses in the RDNSS option to be 508 preferred according to their order in the RDNSS option for the DNS 509 name resolution. The processing of these RDNSS addresses is 510 finished here. 512 The handling of expired RDNSSes is as follows: Whenever an entry 513 expires in the DNS Server List, the expired entry is deleted from the 514 DNS Server List, and also the RDNSS address corresponding to the 515 entry is deleted from the Resolver Repository. 517 6.3. Synchronization between DNS Search List and Resolver Repository 519 When an IPv6 host receives the information of multiple DNSSL domain 520 names within a network (e.g., campus network and company network) 521 through an RA message with DNSSL option(s), it stores the DNSSL 522 domain names (in order) into both the DNS Search List and the 523 Resolver Repository. The processing of the DNSSL consists of (i) the 524 processing of DNSSL option(s) included in an RA message and (ii) the 525 handling of expired DNSSLs. The processing of DNSSL option(s) is as 526 follows: 528 Step (a): Receive and parse the DNSSL option(s). For the DNSSL 529 domain names in each DNSSL option, perform Steps (b) through (d). 531 Step (b): For each DNSSL domain name, check the following: If the 532 DNSSL domain name already exists in the DNS Search List and the 533 DNSSL option's Lifetime field is set to zero, delete the 534 corresponding DNSSL entry from both the DNS Search List and the 535 Resolver Repository in order to prevent the DNSSL domain name from 536 being used any more for certain reasons in network management, 537 e.g., the termination of the RDNSS or a renaming situation. That 538 is, the RDNSS can resign from its DNS service because the machine 539 running the RDNSS is out of service intentionally or 540 unintentionally. Also, under the renaming situation, the DNSSL 541 domain names will be changed, so the previous domain names should 542 not be used any more. The processing of this DNSSL domain name is 543 finished here. Otherwise, go to Step (c). 545 Step (c): For each DNSSL domain name, if it already exists in the 546 DNS Server List, then just update the value of the Expiration-time 547 field according to the procedure specified in the third bullet of 548 Section 6.1. Otherwise, go to Step (d). 550 Step (d): For each DNSSL domain name, if it does not exist in the 551 DNS Search List, register the DNSSL domain name and Lifetime with 552 the DNS Search List and then insert the DNSSL domain name in front 553 of the Resolver Repository. In the case where the data structure 554 for the DNS Search List is full of DNSSL domain name entries (that 555 is, has more DNSSL domain names than the sufficient number 556 discussed in Section 5.3.1), delete from the DNS Server List the 557 entry with the shortest Expiration-time (i.e., the entry that will 558 expire first). The corresponding DNSSL domain name is also 559 deleted from the Resolver Repository. For the ordering of DNSSL 560 domain names in a DNSSL option, position the first DNSSL domain 561 name in the DNSSL option as the first one in the Resolver 562 Repository, the second DNSSL domain name in the option as the 563 second one in the repository, and so on. This ordering allows the 564 DNSSL domain names in the DNSSL option to be preferred according 565 to their order in the DNSSL option for the DNS domain name used by 566 the DNS query. The processing of these DNSSL domain name is 567 finished here. 569 The handling of expired DNSSLs is as follows: Whenever an entry 570 expires in the DNS Search List, the expired entry is deleted from 571 the DNS Search List, and also the DNSSL domain name corresponding 572 to the entry is deleted from the Resolver Repository. 574 7. Security Considerations 576 In this section, we analyze security threats related to DNS options 577 and then suggest recommendations to cope with such security threats. 579 7.1. Security Threats 581 For the RDNSS option, an attacker could send an RA with a fraudulent 582 RDNSS address, misleading IPv6 hosts into contacting an unintended 583 DNS server for DNS name resolution. Also, for the DNSSL option, an 584 attacker can let IPv6 hosts resolve a host name without a DNS suffix 585 into an unintended host's IP address with a fraudulent DNS Search 586 List. 588 These attacks are similar to Neighbor Discovery attacks that use 589 Redirect or Neighbor Advertisement messages to redirect traffic to 590 individual addresses of malicious parties. That is, as a rogue 591 router, a malicious node on a LAN can promiscuously receive packets 592 for any router's Media Access Control (MAC) address and send packets 593 with the router's MAC address as the source MAC address in the Layer 594 2 (L2) header. As a result, L2 switches send packets addressed to 595 the router to the malicious node. Also, this attack can send 596 redirects that tell the hosts to send their traffic somewhere else. 597 The malicious node can send unsolicited RA or Neighbor Advertisement 598 (NA) replies, answer RS or Neighbor Solicitation (NS) requests, etc. 599 Thus, the attacks related to RDNSS and DNSSL are similar to both 600 Neighbor Discovery attacks and attacks against unauthenticated DHCP, 601 as both can be used for both "wholesale" traffic redirection and more 602 specific attacks. 604 However, the security of these RA options for DNS configuration does 605 not affect ND protocol security [RFC4861]. This is because learning 606 DNS information via the RA options cannot be worse than learning bad 607 router information via the RA options. Therefore, the vulnerability 608 of ND is not worse and is a subset of the attacks that any node 609 attached to a LAN can do independently of ND. 611 7.2. Recommendations 613 The Secure Neighbor Discovery (SEND) protocol [RFC3971] is used as a 614 security mechanism for ND. It is RECOMMENDED that ND use SEND to 615 allow all the ND options including the RDNSS and DNSSL options to be 616 automatically included in the signatures. Through SEND, the 617 transport for the RA options is integrity protected; that is, SEND 618 can prevent the spoofing of these DNS options with signatures. Also, 619 SEND enables an IPv6 host to verify that the sender of an RA is 620 actually a router authorized to act as a router. However, since any 621 valid SEND router can still insert RDNSS and DNSSL options, the 622 current SEND cannot verify which one is or is not authorized to send 623 the options. Thus, this verification of the authorized routers for 624 ND options will be required. [CSI-SEND-CERT] specifies the usage of 625 extended key for the certificate deployed in SEND. This document 626 defines the roles of routers (i.e., routers acting as proxy and 627 address owner) and explains the authorization of the roles. The 628 mechanism in this document can be extended to verify which routers 629 are authorized to insert RDNSS and DNSSL options. 631 It is common for network devices such as switches to include 632 mechanisms to block unauthorized ports from running a DHCPv6 server 633 to provide protection from rogue DHCP servers. That means that an 634 attacker on other ports cannot insert bogus DNS servers using DHCPv6. 635 The corresponding technique for network devices is RECOMMENDED to 636 block rogue Router Advertisement messages [RFC6104] including the 637 RDNSS and DNSSL options from unauthorized nodes. 639 An attacker may provide a bogus DNS Search List option in order to 640 cause the victim to send DNS queries to a specific DNS server when 641 the victim queries non-FQDNs (fully qualified domain names). For 642 this attack, the DNS resolver in IPv6 hosts can mitigate the 643 vulnerability with the recommendations mentioned in [RFC1535], 644 [RFC1536], and [RFC3646]. 646 8. IANA Considerations 648 The RDNSS option defined in this document uses the IPv6 Neighbor 649 Discovery Option type defined in RFC 5006 [RFC5006], which was 650 assigned by the IANA as follows: 652 Option Name Type 653 Recursive DNS Server Option 25 655 The DNSSL option defined in this document uses the IPv6 Neighbor 656 Discovery Option type defined in RFC 6106 [RFC6106], which was 657 assigned by the IANA as follows: 659 Option Name Type 660 DNS Search List Option 31 662 These options have been registered in the "Internet Control Message 663 Protocol version 6 (ICMPv6) Parameters" registry (http://www.iana. 664 org/assignments/icmpv6-parameters/icmpv6-parameters.xhtml#icmpv6- 665 parameters-5). 667 9. Acknowledgements 669 This document has greatly benefited from inputs by Robert Hinden, 670 Pekka Savola, Iljitsch van Beijnum, Brian Haberman, Tim Chown, Erik 671 Nordmark, Dan Wing, Jari Arkko, Ben Campbell, Vincent Roca, Tony 672 Cheneau, Fernando Gont, Jen Linkova, Ole Troan, Mark Smith, Tatuya 673 Jinmei, Lorenzo Colitti, Tore Anderson, and David Farmer. The 674 authors sincerely appreciate their contributions. 676 10. References 678 10.1. Normative References 680 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 681 Requirement Levels", BCP 14, RFC 2119, March 1997. 683 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. 684 Soliman, "Neighbor Discovery for IP version 6 685 (IPv6)", RFC 4861, September 2007. 687 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 688 Stateless Address Autoconfiguration", RFC 4862, 689 September 2007. 691 [RFC1035] Mockapetris, P., "Domain names - implementation and 692 specification", STD 13, RFC 1035, November 1987. 694 [RFC4007] Deering, S., Haberman, B., Jinmei, T., Nordmark, E., 695 and B. Zill, "IPv6 Scoped Address Architecture", 696 RFC 4007, March 2005. 698 10.2. Informative References 700 [RFC1034] Mockapetris, P., "Domain names - concepts and 701 facilities", STD 13, RFC 1034, November 1987. 703 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, 704 C., and M. Carney, "Dynamic Host Configuration 705 Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003. 707 [RFC3736] Droms, R., "Stateless Dynamic Host Configuration 708 Protocol (DHCP) Service for IPv6", RFC 3736, 709 April 2004. 711 [RFC3646] Droms, R., "DNS Configuration options for Dynamic 712 Host Configuration Protocol for IPv6 (DHCPv6)", 713 RFC 3646, December 2003. 715 [RFC5006] Jeong, J., Park, S., Beloeil, L., and S. 716 Madanapalli, "IPv6 Router Advertisement Option for 717 DNS Configuration", RFC 5006, September 2007. 719 [RFC6106] Jeong, J., Park, S., Beloeil, L., and S. 720 Madanapalli, "IPv6 Router Advertisement Options for 721 DNS Configuration", RFC 6106, November 2010. 723 [RFC4339] Jeong, J., "IPv6 Host Configuration of DNS Server 724 Information Approaches", RFC 4339, February 2006. 726 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, 727 "SEcure Neighbor Discovery (SEND)", RFC 3971, 728 March 2005. 730 [RFC6104] Chown, T. and S. Venaas, "Rogue IPv6 Router 731 Advertisement Problem Statement", RFC 6104, 732 February 2011. 734 [RFC1535] Gavron, E., "A Security Problem and Proposed 735 Correction With Widely Deployed DNS Software", 736 RFC 1535, October 1993. 738 [RFC1536] Kumar, A., Postel, J., Neuman, C., Danzig, P., and 739 S. Miller, "Common DNS Implementation Errors and 740 Suggested Fixes", RFC 1536, October 1993. 742 [MIF-PROBLEM] Blanchet, M. and P. Seite, "Multiple Interfaces 743 Problem Statement", Work in Progress, August 2010. 745 [MIF-PRACTICE] Wasserman, M. and P. Seite, "Current Practices for 746 Multiple Interface Hosts", Work in Progress, 747 August 2010. 749 [CSI-SEND-CERT] Gagliano, R., Krishnan, S., and A. Kukec, 750 "Certificate profile and certificate management for 751 SEND", Work in Progress, October 2010. 753 Appendix A. Changes from RFC 5006 755 The following changes were made from RFC 5006 "IPv6 Router 756 Advertisement Option for DNS Configuration": 758 o Added the DNS Search List (DNSSL) option to support the 759 advertisement of DNS suffixes used in the DNS search along with 760 RDNSS option in RFC 5006. 762 o Clarified the coexistence of RA options and DHCP options for DNS 763 configuration. 765 o Modified the procedure in IPv6 host: 767 * Clarified the procedure for DNS options in an IPv6 host. 769 * Specified a sufficient number of RDNSS addresses or DNS search 770 domain names as three. 772 * Specified a way to deal with DNS options from multiple sources, 773 such as RA and DHCP. 775 o Modified the implementation considerations for DNSSL option 776 handling. 778 o Modified the security considerations to consider more attack 779 scenarios and the corresponding possible solutions. 781 o Modified the IANA considerations to require another IPv6 Neighbor 782 Discovery Option type for the DNSSL option. 784 Appendix B. Changes from RFC 6106 786 The following changes were made from RFC 6106 "IPv6 Router 787 Advertisement Options for DNS Configuration": 789 o The generation of Router Solicitation to ensure that the RDNSS 790 information is fresh before the expiry of the RDNSS option is 791 removed in order to prevent multicast traffic on the link from 792 increasing. 794 o The lifetime's upper bound of 2 * MaxRtrAdvInterval was shown to 795 lead to the expiry of these options on links with a relatively 796 high rate of packet loss. This revision relaxes the upper bound 797 and sets a higher default value to avoid this problem. 799 o The lifetimes of RDNSS and DNSSL options are decoupled from Router 800 Lifetime. An RA router lifetime of zero does not cause the RDNSS 801 and DNSSL options to be considered invalid because these options 802 have their own lifetime values. Thus, due to the expiry of the RA 803 router lifetime, the lists in the RDNSS and DNSSL options are not 804 guaranteed to be reachable at any point in time. 806 o The addresses for recursive DNS servers in the RDNSS option can be 807 not only global addresses, but also link-local addresses. The 808 link-local addresses for RDNSSes should be registered into the 809 resolver repository along with the corresponding link zone 810 indices. 812 o The recommendation that at most three RDNSS addresses to maintain 813 by RDNSS options should be limited is removed. By this removal, 814 the number of RDNSSes to maintain is up to an implementer's local 815 policy. 817 o The recommendation that at most three DNS domains to maintain by 818 DNSSL options should be limited is removed. By this removal, when 819 the set of unique DNSSL values are not equivalent, none of them 820 are ignored for hostname lookups. 822 Authors' Addresses 824 Jaehoon Paul Jeong 825 Department of Software 826 Sungkyunkwan University 827 2066 Seobu-Ro, Jangan-Gu 828 Suwon, Gyeonggi-Do 440-746 829 Republic of Korea 831 Phone: +82 31 299 4957 832 Fax: +82 31 290 7996 833 EMail: pauljeong@skku.edu 834 URI: http://cpslab.skku.edu/people-jaehoon-jeong.php 836 Soohong Daniel Park 837 Software R&D Center 838 SAMSUNG Electronics 839 129 Samsung-Ro, Yeongtong-Gu 840 Suwon, Gyeonggi-Do 443-742 841 Republic of Korea 843 Phone: +82 31 279 8876 844 EMail: soohong.park@samsung.com 845 Luc Beloeil 846 France Telecom R&D 847 42, rue des coutures 848 BP 6243 849 14066 CAEN Cedex 4 850 France 852 Phone: +33 2 40 44 97 40 853 EMail: luc.beloeil@orange-ftgroup.com 855 Syam Madanapalli 856 iRam Technologies 857 #H304, Shriram Samruddhi, Thubarahalli 858 Bangalore - 560066 859 India 861 EMail: smadanapalli@gmail.com