idnits 2.17.1 draft-gont-6man-slaac-dns-config-issues-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- -- The document has an IETF Trust Provisions (28 Dec 2009) Section 6.c(ii) Publication Limitation clause. If this document is intended for submission to the IESG for publication, this constitutes an error. 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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 15, 2012) is 4304 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC2460' is defined on line 323, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 6106 (Obsoleted by RFC 8106) Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPv6 maintenance Working Group (6man) F. Gont 3 Internet-Draft SI6 Networks / UTN-FRH 4 Updates: 6106 (if approved) P. Simerda 5 Intended status: Standards Track June 15, 2012 6 Expires: December 17, 2012 8 Current issues with DNS Configuration Options for SLAAC 9 draft-gont-6man-slaac-dns-config-issues-00 11 Abstract 13 RFC 6106 specifies two Neighbor Discovery options that can be 14 included in Router Advertisement messages to convey information about 15 DNS recursive servers and DNS Search Lists. Small lifetime values 16 for the aforementioned options have been found to cause 17 interoperability problems in those network scenarios in which these 18 options are used to convey DNS-related information. This document 19 analyzes the aforementioned problem, and formally updates RFC 6106 20 such that these issues are mitigated. 22 Status of this Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. This document may not be modified, 26 and derivative works of it may not be created, and it may not be 27 published except as an Internet-Draft. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on December 17, 2012. 41 Copyright Notice 43 Copyright (c) 2012 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Possible Solutions . . . . . . . . . . . . . . . . . . . . . . 4 60 2.1. Summary of possible solutions . . . . . . . . . . . . . . 4 61 2.2. Changing the Semantics of the 'Lifetime' field of 62 RDNSS and DNSSL options . . . . . . . . . . . . . . . . . 4 63 2.3. Changing the Default Values of the 'Lifetime' field of 64 RDNSS and DNSSL options . . . . . . . . . . . . . . . . . 6 65 2.4. Use Router Solicitations for active Probing . . . . . . . 7 66 2.5. Sanitize the received RDNSS/DNSSL 'Lifetime' Values . . . 7 67 3. Security Considerations . . . . . . . . . . . . . . . . . . . 9 68 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 69 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 70 5.1. Normative References . . . . . . . . . . . . . . . . . . . 11 71 5.2. Informative References . . . . . . . . . . . . . . . . . . 11 72 Appendix A. Additional notes regarding RFC 6106 . . . . . . . . . 12 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 75 1. Introduction 77 RFC 6106 [RFC6106] specifies to Neighbor Discovery (ND) [RFC4861] 78 options that can be included in Router Advertisement messages to 79 convey information about DNS recursive servers and DNS Search Lists. 80 Namely, the Recursive DNS Server (RDNSS) Option specifies the IPv6 81 addresses of recursive DNS servers, while the DNS Search List (DNSSL) 82 Option specifies a "search list" to be used when trying to resolve a 83 name by means of the DNS. 85 Each of this options include a "Lifetime" field which specifies the 86 maximum time, in seconds, during which the information included in 87 the option can be used by the receiving system. The aforementioned 88 "Lifetime" value is set as a function of the Neighbor Discovery 89 parameter 'MaxRtrAdvInterval', which specifies the maximum time 90 allowed between sending unsolicited multicast Router Advertisements 91 from an interface. The recommended bounds (MaxRtrAdvInterval <= 92 Lifetime <= 2*MaxRtrAdvInterval) have been found to be too short for 93 scenarios in which some Router Advertisement messages may be lost. 94 In such scenarios, host may fail to receive unsolicited Router 95 Advertisements and therefore fail to refresh the expiration time of 96 the DNS-related information previously learned through the RDNSS and 97 DNSSL options), thus eventually discarding the aforementioned DNS- 98 related information prematurely. 100 Some implementations consider the lack of DNS-related information as 101 a hard failure, thus causing configuration restart. This situation 102 is exacerbated in those implementations in which IPv6 connectivity 103 and IPv4 connectivity are bound together, and hence failure in the 104 configuration of one of them causes the whole link to be restarted. 106 Section 2 proposes a number of ALTERNATIVE solutions to the problem, 107 such that the 6man wg can discuss both of them. It is expected that 108 once the 6man wg converges on a preferred solution, the other ones 109 will be removed from the document. 111 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 112 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 113 document are to be interpreted as described in RFC 2119 [RFC2119]. 115 2. Possible Solutions 117 This section describes a number of possible ALTERNATIVE solutions to 118 the problem, such that the 6man wg can discuss both of them. It is 119 expected that once the 6man wg converges on a preferred solution, the 120 other one will be removed from the document. 122 2.1. Summary of possible solutions 124 Section 2.2 proposes to change the semantics of the RDNSS/DNSSL 125 'Lifetime', thus fixing the 'expiration' problem outlined in 126 Section 1 and the potential of 'network configuration oscillation'. 127 Section 2.3 proposes to increase the 'Lifetime' value at the sending 128 routers, fixing the "expiration" problem outlined in Section 1, but 129 without addressing the potential of 'network configuration 130 oscillation'. Section 2.4 proposes to send Router Solicitations when 131 expiration of RDNSS/DNSSL information is imminent, to elicit Router 132 Advertisement messages. Section 2.5 proposes to enforce a lower 133 limit on the received RDNSS/DNSSL 'Lifetime' values at the client 134 side. 136 2.2. Changing the Semantics of the 'Lifetime' field of RDNSS and DNSSL 137 options 139 The semantics of the 'Lifetime' field of the RDNSS and DNSSL options 140 is updated as follows: 142 o The 'Lifetime' field indicates the amount of time during which the 143 aforementioned DNS-related information is expected to be stable. 145 o If the information received in a RDNSS or DNSSL option is already 146 present in the corresponding data structures, the corresponding 147 'Expiration' time should be updated according to the value in the 148 'Lifetime' field of the received option. A 'Lifetime' of '0' 149 causes the corresponding information to be discarded, as already 150 specified in [RFC6106]. 152 o If a host has already gathered a sufficient number of RDNSS 153 addresses (or DNS search domain names), and additional data is 154 received while the existing entries have not yet expired, the 155 received RDNSS addresses (or DNS search domain names) SHOULD be 156 ignored. 158 o If a host receives new RDNSS addresses (or DNS search domain 159 names), and some of the existing entries have expired, the newly- 160 learned information SHOULD be used to replace the expired entries. 162 o A host SHOULD flush configured DNS-related information when it has 163 any reason to believe that its network connectivity has changed in 164 some relevant way (e.g., there has been a "link change event"). 165 When that happens, the host MAY send a Router Solicitation message 166 to re-learn the corresponding DNS-related information. 168 o The most-recently-updated information SHOULD have higher priority 169 over the other DNS-related information already present on the 170 local host. 172 The rationale for the suggested change is as follows: 174 o It is a backwards-compatible local-policy change that solves the 175 problem described in Section 1 without requiring changes to router 176 software or router configuration in existing deployments (over 177 which the user is likely to have no control at all). 179 o Since different RDNSS and DNSSL information could be sent by the 180 same router in different Router Advertisement messages, the 181 updated semantics of the 'Lifetime' parameter prevents 182 oscillations in network configuration. 184 This situation could arise for a number of reasons. For 185 example, if the desire for different 'Lifetime' values warrants 186 the use of different RDNSS or DNSSL options, and because of 187 packet size issues each option must be included in a separate 188 Router Advertisement message, each burst of RAs could cause 189 DNS-related information to be reconfigured. 191 Another possible scenario that could lead to the same situation 192 is that in which there is more than one local router, and each 193 of the local routers announces different RDNSS (or DNSSL) 194 information. If the number of RDNSS addresses (or DNS search 195 domain names) that the local host considers "sufficient" 196 prevents the aggregate set of RDNSS (or DNSSL) information, the 197 local RDNSS (or DNSSL) information would oscillate between that 198 advertised by each of the local routers. 200 o The original motivation for enforcing a short expiration timeout 201 value was to allow mobile nodes to prefer local RDNSSes to remote 202 RDNSSes. However, the recommendation in the last bullet above 203 already allows for a timely update of the corresponding DNS- 204 related information. Additionally, since it is already 205 recommended by [RFC6106] to maintain some RDNSS addresses (or DNS 206 search domain names) per source, in the typical scenarios in which 207 a single router (per subnet) advertises configuration information, 208 one of this 'slots' will be free (or have expired information) and 209 readily available to be populated with information learned from 210 the new subnet to which the host has moved. 212 2.3. Changing the Default Values of the 'Lifetime' field of RDNSS and 213 DNSSL options 215 The default RDNSS/DNSSL "Lifetime" value in current the current 216 router solutions vary between MaxRtrAdvInterval and 217 2*MaxRtrAdvInterval. This means that common packet loss rates can 218 lead to the problem described in this document. 220 One possible approach to mitigate this issue would be to avoid 221 'Lifetime' values that are on the same order as MaxRtrAdvInterval. 222 This solution would require, of course, changes in router software. 224 When specifying a better default value, the following aspects should 225 be considered: 227 o IPv6 will be used on many links (including IEEE 802.11) that 228 experience packet loss. Therefore losing a few packets in a short 229 period of time should not invalidate DNS configuration 230 information. 232 o Unsolicited Router Advertisements sent on Ethernet networks result 233 in packets that employ multicast Ethernet Destination Addresses. 234 A number of network elements (including those that perform 235 bridging between wireless networks and wired networks) have 236 problems with multicasted Ethernet frames, thus typically leading 237 to packet loss of some of those frames. Therefore, SLAAC 238 implementations should be able to cope with devices that can lose 239 several multicast packets in a row. 241 The default value of AdvRDNSSLifetime and AdvDNSSLLifetime MUST be at 242 least 5*MaxRtrAdvInterval so that the probability of hosts receiving 243 unsolicited Router Advertisements is increased. 245 This solution leaves out the following situations: 247 o In those scenarios in which the involved routers cannot be updated 248 this solution will not be applicable. This also limitation also 249 applies to nomadic hosts that can connect to many different 250 networks. This case will be discussed later in this document. 252 o The affected network has a huge multicast packet loss. This 253 unfortunately happens in some real networks. 255 o This solution does not address the potential 'network 256 configuration oscillation' issue described in Section 2.2. 258 2.4. Use Router Solicitations for active Probing 260 According to RFC 6106, hosts MAY send Router Solicitations to avoid 261 expiry of RDNSS and DNSSL lifetimes. This technique could be 262 employed as a "last resort" when expiration of the RDNSS and DNSSL 263 information is imminent. 265 Hosts SHOULD start sending multicast Router Solicitation when most of 266 the Lifetime of the last RDNSS server is consumed. The precise time 267 should be a randomized value chosen from 70% to 90% of the original 268 Lifetime to avoid bursts of packets from other hosts on the network. 269 Hosts MAY send up to MAX_RTR_SOLICITATIONS Router Solicitation 270 messages, each separated by at least RTR_SOLICITATION_INTERVAL 271 seconds (please see Section 6.3.7 of [RFC4861]. 273 Problems of this approach: 275 o If no IPv6 router responds, all previously connected hosts will 276 repeatedly send Router Solicitations and only stop doing so when 277 their RDNSS and DNSSL information finally expires. This could 278 disrupt IPv4 networking in larger networks and that must be 279 avoided. 281 o If IPv6 router responds with unicast Router Advertisement, it may 282 need to respond to many clients. 284 o There is no other SLAAC information that requires or would benefit 285 from this kind of "active probing". 287 o This approach does not mitigate the potential 'network 288 configuration oscillation' problem described in Section 2.2. 290 NOTE: We should either state a very good reason to specialcase DNS 291 timeouts or deprecate Router Solicitations in RFC 6106 entirely. 292 Deprecation is the more favorable option in our opinion. 294 2.5. Sanitize the received RDNSS/DNSSL 'Lifetime' Values 296 Another possible approach would be to enforce a lower limit on the 297 received RDNSS/DNSSL 'Lifetime' values on the client side. The 298 challenge this technique is the selection of a reasonable value. On 299 the router side, it can be derived from MaxRtrAdvInterval but this 300 value is not known to the client side. 302 Therefore we would have to assume some maximum value of 303 MaxRtrAdvInterval and use it to derive minimum value of lifetimes 304 instead of the actual MaxRtrAdvInterval. 306 It should be noted that this approach would not address the potential 307 'network configuration oscillation' issue described in Section 2.2. 309 3. Security Considerations 311 This document does not introduce any additional security 312 considerations to those documented in the "Security Considerations" 313 section of [RFC6106]. 315 4. Acknowledgements 316 5. References 318 5.1. Normative References 320 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 321 Requirement Levels", BCP 14, RFC 2119, March 1997. 323 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 324 (IPv6) Specification", RFC 2460, December 1998. 326 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 327 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 328 September 2007. 330 [RFC6106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, 331 "IPv6 Router Advertisement Options for DNS Configuration", 332 RFC 6106, November 2010. 334 5.2. Informative References 335 Appendix A. Additional notes regarding RFC 6106 337 Section 5.2 of [RFC6106] states: 339 An RDNSS address or a DNSSL domain name MUST be used only as long 340 as both the RA router Lifetime (advertised by a Router 341 Advertisement message [RFC4861]) and the corresponding option 342 Lifetime have not expired. 344 This requirement could introduce problems in scenarios in which the 345 router advertising the RDNSS or DNSSL options is not expected to be 346 employed as a "default router", and hence the 'Router Lifetime' value 347 of its Router Advertisement messages is set to 0. 349 As noted in Section 4.2 of [RFC4861], the Router Lifetime applies 350 only to the router's usefulness as a default router, and it does 351 not apply to information contained in other message fields or 352 options. 354 Therefore, it would be sensible to exclude the 'Router Lifetime 355 information when deciding about the validity or "freshness" of the 356 DNS-related configuration information. 358 Section 5.3.1 of [RFC6106] states: 360 When the IPv6 host has gathered a sufficient number (e.g., three) 361 of RDNSS addresses (or DNS search domain names), it SHOULD 362 maintain RDNSS addresses (or DNS search domain names) by the 363 sufficient number such that the latest received RDNSS or DNSSL is 364 more preferred to the old ones; that is, when the number of RDNSS 365 addresses (or DNS search domain names) is already the sufficient 366 number, the new one replaces the old one that will expire first in 367 terms of Lifetime. 369 As noted earlier in this document, this policy could lead (in some 370 scenarios) to network configuration oscillations. Therefore, it 371 would be sensible to enforce some minimum stability of the configured 372 information, such as that resulting from the update in Section 2.2. 374 Section 6.3 of [RFC6106] states: 376 Step (d): For each DNSSL domain name, if it does not exist in the 377 DNS Search List, register the DNSSL domain name and Lifetime with 378 the DNS Search List and then insert the DNSSL domain name in front 379 of the Resolver Repository. In the case where the data structure 380 for the DNS Search List is full of DNSSL domain name entries (that 381 is, has more DNSSL domain names than the sufficient number 382 discussed in Section 5.3.1), delete from the DNS Server List the 383 entry with the shortest Expiration-time (i.e., the entry that will 384 expire first). 386 This policy could lead to the same network configuration oscillation 387 problems as described above for the RDNSS addresses. Therefore, it 388 would be sensible to enforce some minimum stability of the configured 389 information, such as that resulting from the update in Section 2.2. 391 Authors' Addresses 393 Fernando Gont 394 SI6 Networks / UTN-FRH 395 Evaristo Carriego 2644 396 Haedo, Provincia de Buenos Aires 1706 397 Argentina 399 Phone: +54 11 4650 8472 400 Email: fgont@si6networks.com 401 URI: http://www.si6networks.com 403 Pavel Simerda 405 Phone: +420 775 996 256 406 Email: pavlix@pavlix.net