idnits 2.17.1 draft-ietf-6man-rdnss-rfc6106bis-07.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 : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 6, 2016) is 2966 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 (~~), 2 warnings (==), 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 Korean Bible University 6 Expires: September 7, 2016 L. Beloeil 7 France Telecom R&D 8 S. Madanapalli 9 iRam Technologies 10 March 6, 2016 12 IPv6 Router Advertisement Options for DNS Configuration 13 draft-ietf-6man-rdnss-rfc6106bis-07 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 September 7, 2016. 48 Copyright Notice 49 Copyright (c) 2016 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 . . . . . . . . . . . . . . . . . . . 12 84 7.1. Security Threats . . . . . . . . . . . . . . . . . . . . . 12 85 7.2. Recommendations . . . . . . . . . . . . . . . . . . . . . 12 86 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 87 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 88 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 89 10.1. Normative References . . . . . . . . . . . . . . . . . . . 14 90 10.2. Informative References . . . . . . . . . . . . . . . . . . 14 91 Appendix A. Changes from RFC 5006 . . . . . . . . . . . . . . . . 15 92 Appendix B. Changes from RFC 6106 . . . . . . . . . . . . . . . . 16 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, for 140 networks that need to distribute additional information, DHCPv6 is 141 likely to be employed. In these networks, RA-based DNS configuration 142 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. 150 The advantages and disadvantages of the RA-based approach are 151 discussed in [RFC4339] along with other approaches, such as the DHCP 152 and well-known anycast address approaches. 154 1.2. Coexistence of RA Options and DHCP Options for DNS Configuration 156 Two protocols exist to configure the DNS information on a host, the 157 Router Advertisement options described in this document and the 158 DHCPv6 options described in [RFC3646]. They can be used together. 159 The rules governing the decision to use stateful configuration 160 mechanisms are specified in [RFC4861]. Hosts conforming to this 161 specification MUST extract DNS information from Router Advertisement 162 messages, unless static DNS configuration has been specified by the 163 user. If there is DNS information available from multiple Router 164 Advertisements and/or from DHCP, the host MUST maintain an ordered 165 list of this information as specified in Section 5.3.1. 167 2. Requirements Language 169 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 170 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 171 document are to be interpreted as described in [RFC2119]. 173 3. Terminology 175 This document uses the terminology described in [RFC4861] and 176 [RFC4862]. In addition, four new terms are defined below: 178 o Recursive DNS Server (RDNSS): Server that provides a recursive DNS 179 resolution service for translating domain names into IP addresses 180 as defined in [RFC1034] and [RFC1035]. 182 o RDNSS Option: IPv6 RA option to deliver the RDNSS information to 183 IPv6 hosts [RFC4861]. 185 o DNS Search List (DNSSL): The list of DNS suffix domain names used 186 by IPv6 hosts when they perform DNS query searches for short, 187 unqualified domain names. 189 o DNSSL Option: IPv6 RA option to deliver the DNSSL information to 190 IPv6 hosts. 192 o DNS Repository: Two data structures for managing DNS Configuration 193 Information in the IPv6 protocol stack in addition to Neighbor 194 Cache and Destination Cache for Neighbor Discovery [RFC4861]. The 195 first data structure is the DNS Server List for RDNSS addresses 196 and the second is the DNS Search List for DNS search domain names. 198 o Resolver Repository: Configuration repository with RDNSS addresses 199 and a DNS Search List that a DNS resolver on the host uses for DNS 200 name resolution; for example, the Unix resolver file (i.e., /etc/ 201 resolv.conf) and Windows registry. 203 4. Overview 205 This document standardizes the ND option called the RDNSS option 206 defined in [RFC6106] that contains the addresses of recursive DNS 207 servers. This document also standardizes the ND option called the 208 DNSSL option defined in [RFC6106] that contains the Domain Search 209 List. This is to maintain parity with the DHCPv6 options and to 210 ensure that there is necessary functionality to determine the search 211 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 ND 232 options in Neighbor Discovery: (i) the Recursive DNS Server (RDNSS) 233 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 received) 270 over which these RDNSS addresses 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 addresses 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-local addresses MAY be 289 represented with their link zone indices in the textual format for 290 scoped addresses as described in [RFC4007]. When a resolver sends 291 a DNS query message to an RDNSS with a link-local address, it MUST 292 use the 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 received) 329 over which these DNSSL domain names 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 names 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 as described in Section 3.1 of [RFC1035]. 341 By this technique, each domain name is represented as 342 a sequence of labels ending in a zero octet, defined 343 as domain name representation. For more than one 344 domain name, the corresponding domain name 345 representations are concatenated as they are. Note 346 that for the simple decoding, the domain names MUST 347 NOT be encoded in a compressed form, as described in 348 Section 4.1.4 of [RFC1035]. Because the size of this 349 field MUST be a multiple of 8 octets, for the minimum 350 multiple including the domain name representations, 351 the remaining octets other than the encoding parts of 352 the domain name representations MUST be padded with 353 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 worked 408 on solving this problem for both DNS and other information obtained 409 by multiple interfaces [RFC6418][RFC6419], and standardized the 410 solution for RDNSS selection for multi-interfaced nodes in [RFC6731], 411 which is based on DHCP. 413 6. Implementation Considerations 415 Note: This non-normative section gives some hints for implementing 416 the processing of the RDNSS and DNSSL options in an IPv6 host. 418 For the configuration and management of DNS information, the 419 advertised DNS configuration information can be stored and managed in 420 both the DNS Repository and the Resolver Repository. 422 In environments where the DNS information is stored in user space and 423 ND runs in the kernel, it is necessary to synchronize the DNS 424 information (i.e., RDNSS addresses and DNS search domain names) in 425 kernel space and the Resolver Repository in user space. In these 426 environments, a user space application cannot receive RA via an 427 ICMPv6 socket using the standard advanced socket application program 428 interface (API) in [RFC3542]. For the synchronization, an 429 implementation where ND works in the kernel should provide a write 430 operation for updating DNS information from the kernel to the 431 Resolver Repository. One simple approach is to have a daemon (or a 432 program that is called at defined intervals) that keeps monitoring 433 the Lifetimes of RDNSS addresses and DNS search domain names all the 434 time. Whenever there is an expired entry in the DNS Repository, the 435 daemon can delete the corresponding entry from the Resolver 436 Repository. 438 6.1. DNS Repository Management 440 For DNS repository management, the kernel or user-space process 441 (depending on where RAs are processed) should maintain two data 442 structures: (i) DNS Server List that keeps the list of RDNSS 443 addresses and (ii) DNS Search List that keeps the list of DNS search 444 domain names. Each entry in these two lists consists of a pair of an 445 RDNSS address (or DNSSL domain name) and Expiration-time as follows: 447 o RDNSS address for DNS Server List: IPv6 address of the Recursive 448 DNS Server, which is available for recursive DNS resolution 449 service in the network advertising the RDNSS option. 451 o DNSSL domain name for DNS Search List: DNS suffix domain names, 452 which are used to perform DNS query searches for short, 453 unqualified domain names in the network advertising the DNSSL 454 option. 456 o Expiration-time for DNS Server List or DNS Search List: The time 457 when this entry becomes invalid. Expiration-time is set to the 458 value of the Lifetime field of the RDNSS option or DNSSL option 459 plus the current system time. Whenever a new RDNSS option with 460 the same address (or DNSSL option with the same domain name) is 461 received on the same interface as a previous RDNSS option (or 462 DNSSL option), this field is updated to have a new Expiration- 463 time. When Expiration-time becomes less than the current system 464 time, this entry is regarded as expired. 466 6.2. Synchronization between DNS Server List and Resolver Repository 468 When an IPv6 host receives the information of multiple RDNSS 469 addresses within a network (e.g., campus network and company network) 470 through an RA message with RDNSS option(s), it stores the RDNSS 471 addresses (in order) into both the DNS Server List and the Resolver 472 Repository. The processing of the RDNSS consists of (i) the 473 processing of RDNSS option(s) included in an RA message and (ii) the 474 handling of expired RDNSSes. The processing of RDNSS option(s) is as 475 follows: 477 Step (a): Receive and parse the RDNSS option(s). For the RDNSS 478 addresses in each RDNSS option, perform Steps (b) through (d). 480 Step (b): For each RDNSS address, check the following: If the 481 RDNSS address already exists in the DNS Server List and the RDNSS 482 option's Lifetime field is set to zero, delete the corresponding 483 RDNSS entry from both the DNS Server List and the Resolver 484 Repository in order to prevent the RDNSS address from being used 485 any more for certain reasons in network management, e.g., the 486 termination of the RDNSS or a renumbering situation. That is, the 487 RDNSS can resign from its DNS service because the machine running 488 the RDNSS is out of service intentionally or unintentionally. 489 Also, under the renumbering situation, the RDNSS's IPv6 address 490 will be changed, so the previous RDNSS address should not be used 491 any more. The processing of this RDNSS address is finished here. 492 Otherwise, go to Step (c). 494 Step (c): For each RDNSS address, if it already exists in the DNS 495 Server List, then just update the value of the Expiration-time 496 field according to the procedure specified in the third bullet of 497 Section 6.1. Otherwise, go to Step (d). 499 Step (d): For each RDNSS address, if it does not exist in the DNS 500 Server List, register the RDNSS address and Lifetime with the DNS 501 Server List and then insert the RDNSS address in front of the 502 Resolver Repository. In the case where the data structure for the 503 DNS Server List is full of RDNSS entries (that is, has more 504 RDNSSes than the sufficient number discussed in Section 5.3.1), 505 delete from the DNS Server List the entry with the shortest 506 Expiration-time (i.e., the entry that will expire first). The 507 corresponding RDNSS address is also deleted from the Resolver 508 Repository. For the ordering of RDNSS addresses in an RDNSS 509 option, position the first RDNSS address in the RDNSS option as 510 the first one in the Resolver Repository, the second RDNSS address 511 in the option as the second one in the repository, and so on. 512 This ordering allows the RDNSS addresses in the RDNSS option to be 513 preferred according to their order in the RDNSS option for the DNS 514 name resolution. The processing of these RDNSS addresses is 515 finished here. 517 The handling of expired RDNSSes is as follows: Whenever an entry 518 expires in the DNS Server List, the expired entry is deleted from the 519 DNS Server List, and also the RDNSS address corresponding to the 520 entry is deleted from the Resolver Repository. 522 6.3. Synchronization between DNS Search List and Resolver Repository 524 When an IPv6 host receives the information of multiple DNSSL domain 525 names within a network (e.g., campus network and company network) 526 through an RA message with DNSSL option(s), it stores the DNSSL 527 domain names (in order) into both the DNS Search List and the 528 Resolver Repository. The processing of the DNSSL consists of (i) the 529 processing of DNSSL option(s) included in an RA message and (ii) the 530 handling of expired DNSSLs. The processing of DNSSL option(s) is the 531 same with that of RDNSS option(s) in Section 6.2 except Step (b). 533 In Step (b), if the DNSSL domain name already exists in the DNS 534 Search List and the DNSSL option's Lifetime field is set to zero, 535 delete the corresponding DNSSL entry from both the DNS Search List 536 and the Resolver Repository in order to prevent the DNSSL domain name 537 from being used any more for certain reasons in network management, 538 e.g., the termination of the usage of the DNSSL domain name. That 539 is, the DNSSL domain name may not be used any more by the policy of 540 the network. 542 7. Security Considerations 544 In this section, we analyze security threats related to DNS options 545 and then suggest recommendations to cope with such security threats. 547 7.1. Security Threats 549 For the RDNSS option, an attacker could send an RA with a fraudulent 550 RDNSS address, misleading IPv6 hosts into contacting an unintended 551 DNS server for DNS name resolution. Also, for the DNSSL option, an 552 attacker can let IPv6 hosts resolve a host name without a DNS suffix 553 into an unintended host's IP address with a fraudulent DNS Search 554 List. These attacks are similar to ND attacks specified in [RFC4861] 555 that use Redirect or Neighbor Advertisement messages to redirect 556 traffic to individual addresses of malicious parties. 558 However, the security of these RA options for DNS configuration does 559 not affect ND protocol security [RFC4861]. This is because learning 560 DNS information via the RA options cannot be worse than learning bad 561 router information via the RA options. Therefore, the vulnerability 562 of ND is not worse and is a subset of the attacks that any node 563 attached to a LAN can do independently of ND. 565 7.2. Recommendations 567 The Secure Neighbor Discovery (SEND) protocol [RFC3971] MAY be used 568 as a security mechanism for ND. In this case, ND can use SEND to 569 allow all the ND options including the RDNSS and DNSSL options to be 570 automatically included in the signatures. Other approaches specified 571 in [RFC4861] can be used for securing the RA options for DNS 572 configuration. 574 It is common for network devices such as switches to include 575 mechanisms to block unauthorized ports from running a DHCPv6 server 576 to provide protection from rogue DHCPv6 servers [RFC7610]. That 577 means that an attacker on other ports cannot insert bogus DNS servers 578 using DHCPv6. The corresponding technique for network devices is 579 RECOMMENDED to block rogue Router Advertisement messages [RFC6104] 580 including the RDNSS and DNSSL options from unauthorized nodes. 582 An attacker may provide a bogus DNS Search List option in order to 583 cause the victim to send DNS queries to a specific DNS server when 584 the victim queries non-FQDNs (fully qualified domain names). For 585 this attack, the DNS resolver in IPv6 hosts can mitigate the 586 vulnerability with the recommendations mentioned in [RFC1535], 587 [RFC1536], and [RFC3646]. 589 8. IANA Considerations 591 The RDNSS option defined in this document uses the IPv6 Neighbor 592 Discovery Option type defined in RFC 6106 [RFC6106], which was 593 assigned by the IANA as follows: 595 Option Name Type 596 Recursive DNS Server Option 25 598 The DNSSL option defined in this document uses the IPv6 Neighbor 599 Discovery Option type defined in RFC 6106 [RFC6106], which was 600 assigned by the IANA as follows: 602 Option Name Type 603 DNS Search List Option 31 605 These options have been registered in the "Internet Control Message 606 Protocol version 6 (ICMPv6) Parameters" registry (http:// 607 www.iana.org/assignments/icmpv6-parameters/ 608 icmpv6-parameters.xhtml#icmpv6-parameters-5). 610 9. Acknowledgements 612 This document has greatly benefited from inputs by Robert Hinden, 613 Pekka Savola, Iljitsch van Beijnum, Brian Haberman, Tim Chown, Erik 614 Nordmark, Dan Wing, Jari Arkko, Ben Campbell, Vincent Roca, Tony 615 Cheneau, Fernando Gont, Jen Linkova, Ole Troan, Mark Smith, Tatuya 616 Jinmei, Lorenzo Colitti, Tore Anderson, David Farmer, and Bing Liu. 617 The authors sincerely appreciate their contributions. 619 10. References 621 10.1. Normative References 623 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 624 Requirement Levels", BCP 14, RFC 2119, March 1997. 626 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 627 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 628 September 2007. 630 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 631 Address Autoconfiguration", RFC 4862, September 2007. 633 [RFC1035] Mockapetris, P., "Domain names - implementation and 634 specification", STD 13, RFC 1035, November 1987. 636 [RFC4007] Deering, S., Haberman, B., Jinmei, T., Nordmark, E., and 637 B. Zill, "IPv6 Scoped Address Architecture", RFC 4007, 638 March 2005. 640 10.2. Informative References 642 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 643 STD 13, RFC 1034, November 1987. 645 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 646 and M. Carney, "Dynamic Host Configuration Protocol for 647 IPv6 (DHCPv6)", RFC 3315, July 2003. 649 [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol 650 (DHCP) Service for IPv6", RFC 3736, April 2004. 652 [RFC3646] Droms, R., "DNS Configuration options for Dynamic Host 653 Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, 654 December 2003. 656 [RFC5006] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, 657 "IPv6 Router Advertisement Option for DNS Configuration", 658 RFC 5006, September 2007. 660 [RFC6106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, 661 "IPv6 Router Advertisement Options for DNS Configuration", 662 RFC 6106, November 2010. 664 [RFC4339] Jeong, J., "IPv6 Host Configuration of DNS Server 665 Information Approaches", RFC 4339, February 2006. 667 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 668 Neighbor Discovery (SEND)", RFC 3971, March 2005. 670 [RFC6104] Chown, T. and S. Venaas, "Rogue IPv6 Router Advertisement 671 Problem Statement", RFC 6104, February 2011. 673 [RFC7610] Gont, F., Liu, W., and G. Van de Velde, "DHCPv6-Shield: 674 Protecting against Rogue DHCPv6 Servers", RFC 7610, 675 August 2015. 677 [RFC1535] Gavron, E., "A Security Problem and Proposed Correction 678 With Widely Deployed DNS Software", RFC 1535, 679 October 1993. 681 [RFC1536] Kumar, A., Postel, J., Neuman, C., Danzig, P., and S. 682 Miller, "Common DNS Implementation Errors and Suggested 683 Fixes", RFC 1536, October 1993. 685 [RFC6418] Blanchet, M. and P. Seite, "Multiple Interfaces and 686 Provisioning Domains Problem Statement", RFC 6418, 687 November 2011. 689 [RFC6419] Wasserman, M. and P. Seite, "Current Practices for 690 Multiple-Interface Hosts", RFC 6419, November 2011. 692 [RFC6731] Savolainen, T., Kato, J., and T. Lemon, "Improved 693 Recursive DNS Server Selection for Multi-Interfaced 694 Nodes", RFC 6731, December 2012. 696 [RFC3542] Stevens, W., Thomas, M., Nordmark, E., and T. Jinmei, 697 "Advanced Sockets Application Program Interface (API) for 698 IPv6", RFC 3542, May 2003. 700 Appendix A. Changes from RFC 5006 702 The following changes were made from RFC 5006 "IPv6 Router 703 Advertisement Option for DNS Configuration": 705 o Added the DNS Search List (DNSSL) option to support the 706 advertisement of DNS suffixes used in the DNS search along with 707 RDNSS option in RFC 5006. 709 o Clarified the coexistence of RA options and DHCP options for DNS 710 configuration. 712 o Modified the procedure in IPv6 host: 714 * Clarified the procedure for DNS options in an IPv6 host. 716 * Specified a sufficient number of RDNSS addresses or DNS search 717 domain names as three. 719 * Specified a way to deal with DNS options from multiple sources, 720 such as RA and DHCP. 722 o Modified the implementation considerations for DNSSL option 723 handling. 725 o Modified the security considerations to consider more attack 726 scenarios and the corresponding possible solutions. 728 o Modified the IANA considerations to require another IPv6 Neighbor 729 Discovery Option type for the DNSSL option. 731 Appendix B. Changes from RFC 6106 733 The following changes were made from RFC 6106 "IPv6 Router 734 Advertisement Options for DNS Configuration": 736 o The generation of Router Solicitation to ensure that the RDNSS 737 information is fresh before the expiry of the RDNSS option is 738 removed in order to prevent multicast traffic on the link from 739 increasing. 741 o The lifetime's upper bound of 2 * MaxRtrAdvInterval was shown to 742 lead to the expiry of these options on links with a relatively 743 high rate of packet loss. This revision relaxes the upper bound 744 and sets a higher default value to avoid this problem. 746 o The lifetimes of RDNSS and DNSSL options are decoupled from Router 747 Lifetime. An RA router lifetime of zero does not cause the RDNSS 748 and DNSSL options to be considered invalid because these options 749 have their own lifetime values. Thus, due to the expiry of the RA 750 router lifetime, the lists in the RDNSS and DNSSL options are not 751 guaranteed to be reachable at any point in time. 753 o The addresses for recursive DNS servers in the RDNSS option can be 754 not only global addresses, but also link-local addresses. The 755 link-local addresses for RDNSSes should be registered into the 756 resolver repository along with the corresponding link zone 757 indices. 759 o The recommendation that at most three RDNSS addresses to maintain 760 by RDNSS options should be limited is removed. By this removal, 761 the number of RDNSSes to maintain is up to an implementer's local 762 policy. 764 o The recommendation that at most three DNS domains to maintain by 765 DNSSL options should be limited is removed. By this removal, when 766 the set of unique DNSSL values are not equivalent, none of them 767 are ignored for hostname lookups. 769 Authors' Addresses 771 Jaehoon Paul Jeong 772 Department of Software 773 Sungkyunkwan University 774 2066 Seobu-Ro, Jangan-Gu 775 Suwon, Gyeonggi-Do 16419 776 Republic of Korea 778 Phone: +82 31 299 4957 779 Fax: +82 31 290 7996 780 EMail: pauljeong@skku.edu 781 URI: http://iotlab.skku.edu/people-jaehoon-jeong.php 783 Soohong Daniel Park 784 Department of Computer Software 785 Korean Bible University 786 205 SangGye7-Dong, Nowon-Gu 787 Seoul 01757 788 Republic of Korea 790 Phone: +82 2 950 5494 791 EMail: daniel@bible.ac.kr 793 Luc Beloeil 794 France Telecom R&D 795 42, rue des coutures 796 BP 6243 797 14066 CAEN Cedex 4 798 France 800 Phone: +33 2 40 44 97 40 801 EMail: luc.beloeil@orange-ftgroup.com 802 Syam Madanapalli 803 iRam Technologies 804 #H304, Shriram Samruddhi, Thubarahalli 805 Bangalore - 560066 806 India 808 EMail: smadanapalli@gmail.com