idnits 2.17.1 draft-gont-6man-slaac-dns-config-issues-01.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 : ---------------------------------------------------------------------------- ** 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 (February 26, 2015) is 3318 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 216, 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 (==), 1 comment (--). 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 6 Expires: August 30, 2015 W. Liu 7 Huawei Technologies 8 February 26, 2015 10 Current issues with DNS Configuration Options for SLAAC 11 draft-gont-6man-slaac-dns-config-issues-01 13 Abstract 15 RFC 6106 specifies two Neighbor Discovery options that can be 16 included in Router Advertisement messages to convey information about 17 DNS recursive servers and DNS Search Lists. Small lifetime values 18 for the aforementioned options have been found to cause 19 interoperability problems in those network scenarios in which these 20 options are used to convey DNS-related information. This document 21 analyzes the aforementioned problem, and formally updates RFC 6106 22 such that these issues are mitigated. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 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 August 30, 2015. 41 Copyright Notice 43 Copyright (c) 2015 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Changing the Semantics of the 'Lifetime' field of RDNSS and 60 DNSSL options . . . . . . . . . . . . . . . . . . . . . . . . 3 61 3. Changing the Default Values of the 'Lifetime' field of RDNSS 62 and DNSSL options . . . . . . . . . . . . . . . . . . . . . . 4 63 4. Use of Router Solicitations for active Probing . . . . . . . 4 64 5. Sanitize the received RDNSS/DNSSL 'Lifetime' Values . . . . . 5 65 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 66 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 67 8. Normative References . . . . . . . . . . . . . . . . . . . . 5 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 70 1. Introduction 72 RFC 6106 [RFC6106] specifies two Neighbor Discovery (ND) [RFC4861] 73 options that can be included in Router Advertisement messages to 74 convey information about DNS recursive servers and DNS Search Lists. 75 Namely, the Recursive DNS Server (RDNSS) Option specifies the IPv6 76 addresses of recursive DNS servers, while the DNS Search List (DNSSL) 77 Option specifies a "search list" to be used when trying to resolve a 78 name by means of the DNS. 80 Each of this options include a "Lifetime" field which specifies the 81 maximum time, in seconds, during which the information included in 82 the option can be used by the receiving system. The aforementioned 83 "Lifetime" value is set as a function of the Neighbor Discovery 84 parameter 'MaxRtrAdvInterval', which specifies the maximum time 85 allowed between sending unsolicited multicast Router Advertisements 86 from an interface. The recommended bounds (MaxRtrAdvInterval <= 87 Lifetime <= 2*MaxRtrAdvInterval) have been found to be too short for 88 scenarios in which some Router Advertisement messages may be lost. 89 In such scenarios, hosts may fail to receive unsolicited Router 90 Advertisements and therefore fail to refresh the expiration time of 91 the DNS-related information previously learned through the RDNSS and 92 DNSSL options), thus eventually discarding the aforementioned DNS- 93 related information prematurely. 95 Some implementations consider the lack of DNS-related information as 96 a hard failure, thus causing configuration restart. This situation 97 is exacerbated in those implementations in which IPv6 connectivity 98 and IPv4 connectivity are bound together, and hence failure in the 99 configuration of one of them causes the whole link to be restarted. 101 This document formally updates RFC 6106 such that this issue is 102 mitigated. 104 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 105 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 106 document are to be interpreted as described in RFC 2119 [RFC2119]. 108 2. Changing the Semantics of the 'Lifetime' field of RDNSS and DNSSL 109 options 111 The semantics of the 'Lifetime' field of the RDNSS and DNSSL options 112 is updated as follows: 114 o The 'Lifetime' field indicates the amount of time during which the 115 aforementioned DNS-related information is expected to be stable. 116 A node is NOT required to discard the DNS-related information once 117 the Lifetime expires. 119 o If the information received in a RDNSS or DNSSL option is already 120 present in the corresponding local data structures, the 121 corresponding 'Expiration' time should be updated according to the 122 value in the 'Lifetime' field of the received option. A 123 'Lifetime' of '0' causes the corresponding information to be 124 discarded, as already specified in [RFC6106]. 126 o If a host has already gathered a sufficient number of RDNSS 127 addresses (or DNS search domain names), and additional data is 128 received while the existing entries have not yet expired, the 129 received RDNSS addresses (or DNS search domain names) SHOULD be 130 ignored. 132 o If a host receives new RDNSS addresses (or DNS search domain 133 names), and some of the existing entries have expired, the newly- 134 learned information SHOULD be used to replace the expired entries. 136 o A host SHOULD flush configured DNS-related information when it has 137 any reason to believe that its network connectivity has changed in 138 some relevant way (e.g., there has been a "link change event"). 139 When that happens, the host MAY send a Router Solicitation message 140 to re-learn the corresponding DNS-related information. 142 o The most-recently-updated information SHOULD have higher priority 143 over the other DNS-related information already present on the 144 local host. 146 We note that the original motivation for enforcing a short expiration 147 timeout value was to allow mobile nodes to prefer local RDNSSes to 148 remote RDNSSes. However, the above rules already allow for a timely 149 update of the corresponding DNS-related information. 151 3. Changing the Default Values of the 'Lifetime' field of RDNSS and 152 DNSSL options 154 The default RDNSS/DNSSL "Lifetime" value in current the current 155 router solutions vary between MaxRtrAdvInterval and 156 2*MaxRtrAdvInterval. This means that common packet loss rates can 157 lead to the problem described in this document. 159 One possible approach to mitigate this issue would be to avoid 160 'Lifetime' values that are on the same order as MaxRtrAdvInterval. 161 This solution would require, of course, changes in router software. 163 When specifying a better default value, the following aspects should 164 be considered: 166 o IPv6 will be used on many links (including IEEE 802.11) that 167 experience packet loss. Therefore losing a few packets in a short 168 period of time should not invalidate DNS configuration 169 information. 171 o Unsolicited Router Advertisements sent on Ethernet networks result 172 in packets that employ multicast Ethernet Destination Addresses. 173 A number of network elements (including those that perform 174 bridging between wireless networks and wired networks) have 175 problems with multicasted Ethernet frames, thus typically leading 176 to packet loss of some of those frames. Therefore, SLAAC 177 implementations should be able to cope with devices that can lose 178 several multicast packets in a row. 180 [RFC6106] is hereby updated as follows: 182 The default value of AdvRDNSSLifetime and AdvDNSSLLifetime MUST be 183 at least 10*MaxRtrAdvInterval so that the probability of hosts 184 receiving unsolicited Router Advertisements is increased. 186 4. Use of Router Solicitations for active Probing 188 According to RFC 6106, hosts MAY send Router Solicitations to avoid 189 expiry of RDNSS and DNSSL lifetimes. This technique could be 190 employed as a "last resort" when expiration of the RDNSS and DNSSL 191 information is imminent. 193 5. Sanitize the received RDNSS/DNSSL 'Lifetime' Values 195 A host that receives a RDNSS or DNSSL option that has a non-zero 196 Lifetime smaller than 10*MaxRtrAdvInterval should employ 197 10*MaxRtrAdvInterval as the Lifetime value of the corresponding RDNSS 198 or DNSSL option. 200 6. Security Considerations 202 This document does not introduce any additional security 203 considerations to those documented in the "Security Considerations" 204 section of [RFC6106]. 206 7. Acknowledgements 208 The authors would like to thank Erik Nordmark and Mark Smith for 209 their valuable input on the topic covered by this document. 211 8. Normative References 213 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 214 Requirement Levels", BCP 14, RFC 2119, March 1997. 216 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 217 (IPv6) Specification", RFC 2460, December 1998. 219 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 220 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 221 September 2007. 223 [RFC6106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, 224 "IPv6 Router Advertisement Options for DNS Configuration", 225 RFC 6106, November 2010. 227 Authors' Addresses 229 Fernando Gont 230 SI6 Networks / UTN-FRH 231 Evaristo Carriego 2644 232 Haedo, Provincia de Buenos Aires 1706 233 Argentina 235 Phone: +54 11 4650 8472 236 Email: fgont@si6networks.com 237 URI: http://www.si6networks.com 238 Pavel Simerda 240 Phone: +420 775 996 256 241 Email: pavlix@pavlix.net 243 Will Liu 244 Huawei Technologies 245 Bantian, Longgang District 246 Shenzhen 518129 247 P.R. China 249 Email: liushucheng@huawei.com