idnits 2.17.1 draft-ietf-6man-rdnss-rfc6106bis-08.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 2971 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-08 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 . . . . . . . . . . . . . . . . . . . . . . . . 11 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 . . . . . . . . . . . . . . . . . . . . . 13 86 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 87 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 88 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 89 10.1. Normative References . . . . . . . . . . . . . . . . . . . 14 90 10.2. Informative References . . . . . . . . . . . . . . . . . . 14 91 Appendix A. Changes from RFC 6106 . . . . . . . . . . . . . . . . 16 93 1. Introduction 95 The purpose of this document is to standardize an IPv6 Router 96 Advertisement (RA) option for DNS Recursive Server Addresses used for 97 the DNS name resolution in IPv6 hosts. This RA option was originally 98 specified in an earlier Experimental specification [RFC5006] and was 99 later published as a Standards Track in [RFC6106]. This document 100 obsoletes [RFC6106], allowing a higher default value of the lifetime 101 of the RA DNS options to avoid the frequent expiry of the options on 102 links with a relatively high rate of packet loss, and also making 103 additional clarifications, see Appendix B for details. 105 Neighbor Discovery (ND) for IP version 6 and IPv6 Stateless Address 106 Autoconfiguration (SLAAC) provide ways to configure either fixed or 107 mobile nodes with one or more IPv6 addresses, default routers, and 108 some other parameters [RFC4861][RFC4862]. Most Internet names 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 names. 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 recursive name server directly connected to the global DNS. 120 The DNS information can also be provided through DHCPv6 [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 specified in this document and the 158 DHCPv6 options specified 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 defined 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 or resolving PTR records, 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 the 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 satisfies that (Length 368 - 1) % 2 == 0. The value of the Length field in the DNSSL option 369 is greater than or equal to the minimum value (2). Also, the 370 validity of the RDNSS option is checked with the "Addresses of 371 IPv6 Recursive DNS Servers" field; that is, the addresses should 372 be unicast addresses. 374 o If the DNS options are valid, the host SHOULD copy the values of 375 the options into the DNS Repository and the Resolver Repository in 376 order. Otherwise, the host MUST discard the options. Refer to 377 Section 6 for the detailed procedure. 379 In the case where the DNS options of RDNSS and DNSSL can be obtained 380 from multiple sources, such as RA and DHCP, the IPv6 host SHOULD keep 381 some DNS options from all sources. Unless explicitly specified for 382 the discovery mechanism, the exact number of addresses and domain 383 names to keep is a matter of local policy and implementation choice 384 as a local configuration option. However, in the case of multiple 385 sources, the ability to store a total of at least three RDNSS 386 addresses (or DNSSL domain names) from the multiple sources is 387 RECOMMENDED. The DNS options from Router Advertisements and DHCP 388 SHOULD be stored into the DNS Repository and Resolver Repository so 389 that information from DHCP appears there first and therefore takes 390 precedence. Thus, the DNS information from DHCP takes precedence 391 over that from RA for DNS queries. On the other hand, for DNS 392 options announced by RA, if some RAs use the Secure Neighbor 393 Discovery (SEND) protocol [RFC3971] for RA security, they MUST be 394 preferred over those that do not use SEND. Refer to Section 7 for 395 the detailed discussion on SEND for RA DNS options. 397 5.3.2. Warnings for DNS Options Configuration 399 There are two warnings for DNS options configuration: (i) warning for 400 multiple sources of DNS options and (ii) warning for multiple network 401 interfaces. First, in the case of multiple sources for DNS options 402 (e.g., RA and DHCP), an IPv6 host can configure its IP addresses from 403 these sources. In this case, it is not possible to control how the 404 host uses DNS information and what source addresses it uses to send 405 DNS queries. As a result, configurations where different information 406 is provided by different sources may lead to problems. Therefore, 407 the network administrator needs to configure different DNS options in 408 the multiple sources in order to minimize the impact of such problems 409 [DHCPv6-SLAAC]. 411 Second, if different DNS information is provided on different network 412 interfaces, this can lead to inconsistent behavior. The IETF worked 413 on solving this problem for both DNS and other information obtained 414 by multiple interfaces [RFC6418][RFC6419], and standardized the 415 solution for RDNSS selection for multi-interfaced nodes in [RFC6731], 416 which is based on DHCP. 418 6. Implementation Considerations 420 Note: This non-normative section gives some hints for implementing 421 the processing of the RDNSS and DNSSL options in an IPv6 host. 423 For the configuration and management of DNS information, the 424 advertised DNS configuration information can be stored and managed in 425 both the DNS Repository and the Resolver Repository. 427 In environments where the DNS information is stored in user space and 428 ND runs in the kernel, it is necessary to synchronize the DNS 429 information (i.e., RDNSS addresses and DNS search domain names) in 430 kernel space and the Resolver Repository in user space. In these 431 environments, a user space application cannot receive RA via an 432 ICMPv6 socket using the standard advanced socket Application Program 433 Interface (API) in [RFC3542]. For the synchronization, an 434 implementation where ND works in the kernel should provide a write 435 operation for updating DNS information from the kernel to the 436 Resolver Repository. One simple approach is to have a daemon (or a 437 program that is called at defined intervals) that keeps monitoring 438 the Lifetimes of RDNSS addresses and DNS search domain names all the 439 time. Whenever there is an expired entry in the DNS Repository, the 440 daemon can delete the corresponding entry from the Resolver 441 Repository. 443 6.1. DNS Repository Management 445 For DNS repository management, the kernel or user-space process 446 (depending on where RAs are processed) should maintain two data 447 structures: (i) DNS Server List that keeps the list of RDNSS 448 addresses and (ii) DNS Search List that keeps the list of DNS search 449 domain names. Each entry in these two lists consists of a pair of an 450 RDNSS address (or DNSSL domain name) and Expiration-time as follows: 452 o RDNSS address for DNS Server List: IPv6 address of the Recursive 453 DNS Server, which is available for recursive DNS resolution 454 service in the network advertising the RDNSS option. 456 o DNSSL domain name for DNS Search List: DNS suffix domain names, 457 which are used to perform DNS query searches for short, 458 unqualified domain names for the RDNSS address, which is 459 advertised by the same RA message having the DNSSL option, in the 460 network advertising the DNSSL option. 462 o Expiration-time for DNS Server List or DNS Search List: The time 463 when this entry becomes invalid. Expiration-time is set to the 464 value of the Lifetime field of the RDNSS option or DNSSL option 465 plus the current time. Whenever a new RDNSS option with the same 466 address (or DNSSL option with the same domain name) is received on 467 the same interface as a previous RDNSS option (or DNSSL option), 468 this field is updated to have a new Expiration-time. When the 469 current time becomes larger than Expiration-time, this entry is 470 regarded as expired. Note that the DNS information for the RDNSS 471 and DNSSL options need not be dropped if the expiry of the RA 472 router lifetime happens. This is because these options have their 473 own lifetime values. 475 6.2. Synchronization between DNS Server List and Resolver Repository 477 When an IPv6 host receives the information of multiple RDNSS 478 addresses within a network (e.g., campus network and company network) 479 through an RA message with RDNSS option(s), it stores the RDNSS 480 addresses (in order) into both the DNS Server List and the Resolver 481 Repository. The processing of the RDNSS consists of (i) the 482 processing of RDNSS option(s) included in an RA message and (ii) the 483 handling of expired RDNSSes. The processing of RDNSS option(s) is as 484 follows: 486 Step (a): Receive and parse the RDNSS option(s). For the RDNSS 487 addresses in each RDNSS option, perform Steps (b) through (d). 489 Step (b): For each RDNSS address, check the following: If the 490 RDNSS address already exists in the DNS Server List and the RDNSS 491 option's Lifetime field is set to zero, delete the corresponding 492 RDNSS entry from both the DNS Server List and the Resolver 493 Repository in order to prevent the RDNSS address from being used 494 any more for certain reasons in network management, e.g., the 495 termination of the RDNSS or a renumbering situation. That is, the 496 RDNSS can resign from its DNS service because the machine running 497 the RDNSS is out of service intentionally or unintentionally. 498 Also, under the renumbering situation, the RDNSS's IPv6 address 499 will be changed, so the previous RDNSS address should not be used 500 any more. The processing of this RDNSS address is finished here. 501 Otherwise, go to Step (c). 503 Step (c): For each RDNSS address, if it already exists in the DNS 504 Server List, then just update the value of the Expiration-time 505 field according to the procedure specified in the third bullet of 506 Section 6.1. Otherwise, go to Step (d). 508 Step (d): For each RDNSS address, if it does not exist in the DNS 509 Server List, register the RDNSS address and Lifetime with the DNS 510 Server List and then insert the RDNSS address in front of the 511 Resolver Repository. In the case where the data structure for the 512 DNS Server List is full of RDNSS entries (that is, has more 513 RDNSSes than the sufficient number discussed in Section 5.3.1), 514 delete from the DNS Server List the entry with the shortest 515 Expiration-time (i.e., the entry that will expire first). The 516 corresponding RDNSS address is also deleted from the Resolver 517 Repository. For the ordering of RDNSS addresses in an RDNSS 518 option, position the first RDNSS address in the RDNSS option as 519 the first one in the Resolver Repository, the second RDNSS address 520 in the option as the second one in the repository, and so on. 522 This ordering allows the RDNSS addresses in the RDNSS option to be 523 preferred according to their order in the RDNSS option for the DNS 524 name resolution. The processing of these RDNSS addresses is 525 finished here. 527 The handling of expired RDNSSes is as follows: Whenever an entry 528 expires in the DNS Server List, the expired entry is deleted from the 529 DNS Server List, and also the RDNSS address corresponding to the 530 entry is deleted from the Resolver Repository. 532 6.3. Synchronization between DNS Search List and Resolver Repository 534 When an IPv6 host receives the information of multiple DNSSL domain 535 names within a network (e.g., campus network and company network) 536 through an RA message with DNSSL option(s), it stores the DNSSL 537 domain names (in order) into both the DNS Search List and the 538 Resolver Repository. The processing of the DNSSL consists of (i) the 539 processing of DNSSL option(s) included in an RA message and (ii) the 540 handling of expired DNSSLs. The processing of DNSSL option(s) is the 541 same with that of RDNSS option(s) in Section 6.2 except Step (b). 543 In Step (b), if the DNSSL domain name already exists in the DNS 544 Search List and the DNSSL option's Lifetime field is set to zero, 545 delete the corresponding DNSSL entry from both the DNS Search List 546 and the Resolver Repository in order to prevent the DNSSL domain name 547 from being used any more for certain reasons in network management, 548 e.g., the termination of the usage of the DNSSL domain name. That 549 is, the DNSSL domain name may not be used any more by the policy of 550 the network. 552 7. Security Considerations 554 In this section, we analyze security threats related to DNS options 555 and then suggest recommendations to cope with such security threats. 557 7.1. Security Threats 559 For the RDNSS option, an attacker could send an RA with a fraudulent 560 RDNSS address, misleading IPv6 hosts into contacting an unintended 561 DNS server for DNS name resolution. Also, for the DNSSL option, an 562 attacker can let IPv6 hosts resolve a host name without a DNS suffix 563 into an unintended host's IP address with a fraudulent DNS Search 564 List. These attacks are similar to ND attacks specified in [RFC4861] 565 that use Redirect or Neighbor Advertisement messages to redirect 566 traffic to individual addresses of malicious parties. 568 However, the security of these RA options for DNS configuration does 569 not affect ND protocol security [RFC4861]. This is because learning 570 DNS information via the RA options cannot be worse than learning bad 571 router information via the RA options. Therefore, the vulnerability 572 of ND is not worse and is a subset of the attacks that any node 573 attached to a LAN can do. 575 7.2. Recommendations 577 The Secure Neighbor Discovery (SEND) protocol [RFC3971] MAY be used 578 as a security mechanism for ND. In this case, ND can use SEND to 579 allow all the ND options including the RDNSS and DNSSL options to be 580 automatically included in the signatures. Other approaches specified 581 in [RFC4861] can be used for securing the RA options for DNS 582 configuration. 584 It is common for network devices such as switches to include 585 mechanisms to block unauthorized ports from running a DHCPv6 server 586 to provide protection from rogue DHCPv6 servers [RFC7610]. That 587 means that an attacker on other ports cannot insert bogus DNS servers 588 using DHCPv6. The corresponding technique for network devices is 589 RECOMMENDED to block rogue Router Advertisement messages [RFC6104] 590 including the RDNSS and DNSSL options from unauthorized nodes. 592 An attacker may provide a bogus DNS Search List option in order to 593 cause the victim to send DNS queries to a specific DNS server when 594 the victim queries non-FQDNs (fully qualified domain names). For 595 this attack, the DNS resolver in IPv6 hosts can mitigate the 596 vulnerability with the recommendations mentioned in [RFC1535], 597 [RFC1536], and [RFC3646]. 599 8. IANA Considerations 601 The RDNSS option defined in this document uses the IPv6 Neighbor 602 Discovery Option type defined in RFC 6106 [RFC6106], which was 603 assigned by the IANA as follows: 605 Option Name Type 606 Recursive DNS Server Option 25 608 The DNSSL option defined in this document uses the IPv6 Neighbor 609 Discovery Option type defined in RFC 6106 [RFC6106], which was 610 assigned by the IANA as follows: 612 Option Name Type 613 DNS Search List Option 31 615 These options have been registered in the "Internet Control Message 616 Protocol version 6 (ICMPv6) Parameters" registry (http:// 617 www.iana.org/assignments/icmpv6-parameters/ 618 icmpv6-parameters.xhtml#icmpv6-parameters-5). 620 9. Acknowledgements 622 This document has greatly benefited from inputs by Robert Hinden, 623 Pekka Savola, Iljitsch van Beijnum, Brian Haberman, Tim Chown, Erik 624 Nordmark, Dan Wing, Jari Arkko, Ben Campbell, Vincent Roca, Tony 625 Cheneau, Fernando Gont, Jen Linkova, Ole Troan, Mark Smith, Tatuya 626 Jinmei, Lorenzo Colitti, Tore Anderson, David Farmer, and Bing Liu. 627 The authors sincerely appreciate their contributions. 629 10. References 631 10.1. Normative References 633 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 634 Requirement Levels", BCP 14, RFC 2119, March 1997. 636 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. 637 Soliman, "Neighbor Discovery for IP version 6 638 (IPv6)", RFC 4861, September 2007. 640 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 641 Stateless Address Autoconfiguration", RFC 4862, 642 September 2007. 644 [RFC1035] Mockapetris, P., "Domain names - implementation and 645 specification", STD 13, RFC 1035, November 1987. 647 [RFC4007] Deering, S., Haberman, B., Jinmei, T., Nordmark, E., 648 and B. Zill, "IPv6 Scoped Address Architecture", 649 RFC 4007, March 2005. 651 10.2. Informative References 653 [RFC1034] Mockapetris, P., "Domain names - concepts and 654 facilities", STD 13, RFC 1034, November 1987. 656 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, 657 C., and M. Carney, "Dynamic Host Configuration 658 Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003. 660 [RFC3736] Droms, R., "Stateless Dynamic Host Configuration 661 Protocol (DHCP) Service for IPv6", RFC 3736, 662 April 2004. 664 [RFC3646] Droms, R., "DNS Configuration options for Dynamic 665 Host Configuration Protocol for IPv6 (DHCPv6)", 666 RFC 3646, December 2003. 668 [RFC5006] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, 669 "IPv6 Router Advertisement Option for DNS 670 Configuration", RFC 5006, September 2007. 672 [RFC6106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, 673 "IPv6 Router Advertisement Options for DNS 674 Configuration", RFC 6106, November 2010. 676 [RFC4339] Jeong, J., "IPv6 Host Configuration of DNS Server 677 Information Approaches", RFC 4339, February 2006. 679 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, 680 "SEcure Neighbor Discovery (SEND)", RFC 3971, 681 March 2005. 683 [RFC6104] Chown, T. and S. Venaas, "Rogue IPv6 Router 684 Advertisement Problem Statement", RFC 6104, 685 February 2011. 687 [RFC7610] Gont, F., Liu, W., and G. Van de Velde, "DHCPv6- 688 Shield: Protecting against Rogue DHCPv6 Servers", 689 RFC 7610, August 2015. 691 [RFC1535] Gavron, E., "A Security Problem and Proposed 692 Correction With Widely Deployed DNS Software", 693 RFC 1535, October 1993. 695 [RFC1536] Kumar, A., Postel, J., Neuman, C., Danzig, P., and S. 696 Miller, "Common DNS Implementation Errors and 697 Suggested Fixes", RFC 1536, October 1993. 699 [DHCPv6-SLAAC] Liu, B., Jiang, S., Gong, X., Wang, W., and E. Rey, 700 "DHCPv6/SLAAC Interaction Problems on Address and DNS 701 Configuration", Work in Progress, February 2016. 703 [RFC6418] Blanchet, M. and P. Seite, "Multiple Interfaces and 704 Provisioning Domains Problem Statement", RFC 6418, 705 November 2011. 707 [RFC6419] Wasserman, M. and P. Seite, "Current Practices for 708 Multiple-Interface Hosts", RFC 6419, November 2011. 710 [RFC6731] Savolainen, T., Kato, J., and T. Lemon, "Improved 711 Recursive DNS Server Selection for Multi-Interfaced 712 Nodes", RFC 6731, December 2012. 714 [RFC3542] Stevens, W., Thomas, M., Nordmark, E., and T. Jinmei, 715 "Advanced Sockets Application Program Interface (API) 716 for IPv6", RFC 3542, May 2003. 718 Appendix A. Changes from RFC 6106 720 The following changes were made from RFC 6106 "IPv6 Router 721 Advertisement Options for DNS Configuration": 723 o The generation of Router Solicitation to ensure that the RDNSS 724 information is fresh before the expiry of the RDNSS option is 725 removed in order to prevent multicast traffic on the link from 726 increasing. 728 o The lifetime's upper bound of 2 * MaxRtrAdvInterval was shown to 729 lead to the expiry of these options on links with a relatively 730 high rate of packet loss. This revision relaxes the upper bound 731 and sets a higher default value to avoid this problem. 733 o The addresses for recursive DNS servers in the RDNSS option can be 734 not only global addresses, but also link-local addresses. The 735 link-local addresses for RDNSSes should be registered into the 736 resolver repository along with the corresponding link zone 737 indices. 739 o The recommendation that at most three RDNSS addresses to maintain 740 by RDNSS options should be limited is removed. By this removal, 741 the number of RDNSSes to maintain is up to an implementer's local 742 policy. 744 o The recommendation that at most three DNS domains to maintain by 745 DNSSL options should be limited is removed. By this removal, when 746 the set of unique DNSSL values are not equivalent, none of them 747 are ignored for hostname lookups. 749 Authors' Addresses 751 Jaehoon Paul Jeong 752 Department of Software 753 Sungkyunkwan University 754 2066 Seobu-Ro, Jangan-Gu 755 Suwon, Gyeonggi-Do 16419 756 Republic of Korea 758 Phone: +82 31 299 4957 759 Fax: +82 31 290 7996 760 EMail: pauljeong@skku.edu 761 URI: http://iotlab.skku.edu/people-jaehoon-jeong.php 763 Soohong Daniel Park 764 Department of Computer Software 765 Korean Bible University 766 205 SangGye7-Dong, Nowon-Gu 767 Seoul 01757 768 Republic of Korea 770 Phone: +82 2 950 5494 771 EMail: daniel@bible.ac.kr 773 Luc Beloeil 774 France Telecom R&D 775 42, rue des coutures 776 BP 6243 777 14066 CAEN Cedex 4 778 France 780 Phone: +33 2 40 44 97 40 781 EMail: luc.beloeil@orange-ftgroup.com 783 Syam Madanapalli 784 iRam Technologies 785 #H304, Shriram Samruddhi, Thubarahalli 786 Bangalore - 560066 787 India 789 EMail: smadanapalli@gmail.com