Shorter lifetime, RS, something about ignoring lifetimes
[rdnss.git] / draft-gont-6man-slaac-dns-config-issues-00.xml
1 <?xml version="1.0" encoding="UTF-8"?>
2
3 <!DOCTYPE rfc SYSTEM "rfc2629.dtd">
4
5 <?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
6
7 <?rfc toc="yes" ?>
8 <?rfc symrefs="yes" ?>
9 <?rfc strict="no" ?>
10
11 <rfc 
12         ipr="noDerivativesTrust200902"
13         category="std"
14         updates="6106"
15         docName="draft-gont-6man-slaac-dns-config-issues-00">
16   <front>
17     <title abbrev="SLAAC DNS Configuration Issues">Current issues with DNS Configuration Options for SLAAC</title>
18     <area>Internet</area>
19     <workgroup>IPv6 maintenance Working Group (6man)</workgroup>
20
21
22 <author
23         fullname="Fernando Gont"
24         initials="F."
25         surname="Gont">
26     <!-- abbrev not needed but can be used for the header
27          if the full organization name is too long -->
28         <organization abbrev="SI6 Networks / UTN-FRH">SI6 Networks / UTN-FRH</organization>
29         
30         <address>
31
32             <postal>    
33                         <street>Evaristo Carriego 2644</street>
34                 <code>1706</code><city>Haedo</city>
35                 <region>Provincia de Buenos Aires</region>
36                 <country>Argentina</country>
37             </postal>
38             <phone>+54 11 4650 8472</phone>
39
40             <email>fgont@si6networks.com</email>
41 <!--            <email>fernando@gont.com.ar</email> -->
42
43 <!--
44 <uri>http://www.cpni.gov.uk</uri>
45 <uri>http://www.gont.com.ar</uri>
46 -->
47 <uri>http://www.si6networks.com</uri>
48         <!--            If I had a phone, fax machine, and a URI, I could add the following: --->
49
50         </address>
51     </author>
52     <author
53         fullname="Pavel ┼áimerda"
54         initials="P."
55         surname="┼áimerda">
56         <address>
57             <phone>+420 775 996 256</phone>
58             <email>pavlix@pavlix.net</email>
59         </address>
60     </author>
61
62
63  
64     <date year="2012" />
65
66     <abstract>
67     <t>
68 RFC 6106 specifies two Neighbor Discovery options that can be included in Router Advertisement messages to convey information about DNS recursive servers and DNS Search Lists. Small lifetime values for the aforementioned options have been found to cause interoperability problems in those network scenarios in which these options are used to convey DNS-related information. This document analyzes the aforementioned problem, and formally updates RFC 6106 such that these issues are mitigated.
69     </t>
70     </abstract>
71   </front>
72
73   <middle>
74   
75    
76 <section title="Introduction" anchor="intro">
77 <t>
78 RFC 6106 <xref target="RFC6106"/> specifies two Neighbor Discovery (ND) <xref target="RFC4861"/> options that can be included in Router Advertisement messages to convey information about DNS recursive servers and DNS Search Lists. Namely, the Recursive DNS Servers (RDNSS) Option specifies the IPv6 addresses of recursive DNS servers, while the DNS Search List (DNSSL) Option specifies a list of DNS suffix domain names to be used when trying to resolve a name by means of the DNS.
79 </t>
80
81 <t>Each of these options include a "Lifetime" field which specifies the maximum time, in seconds, during which the information included in the option can be used by the receiving system. RFC 6106 specifies that both RDNSS and DNSSL should be bounded as a function of the Neighbor Discovery paramenter 'MaxRtrAdvInterval', which specifies the maximum time allowed between sending unsolicited multicast Router Advertisements from an interface. The recommended bounds (MaxRtrAdvInterval &lt;= Lifetime &lt;= 2*MaxRtrAdvInterval) have been found to be too short for scenarios in which some Router Advertisement messages may be lost. In such scenarios, host may fail to receive unsolicited Router Advertisements and therefore fail to referesh the expiration time of the DNS-related information previously learned through the RDNSS and DNSSL options), thus eventually discarding the aforementioned DNS-related information prematurely.
82 </t>
83
84 <t>Some implementations consider the lack of DNS-related information as a hard failure, thus causing configuration restart. This situation is exacerbated in those implementations in which IPv6 connectivity and IPv4 connectivity are bound together, and hence failure in the configuration of one of them causes the whole link to be restarted.
85 </t>
86
87 <t>This document proposes a number of updates to RFC 6106, such that the aforementioned issues can be mitigated.</t>
88
89 <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
90    NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
91    "OPTIONAL" in this document are to be interpreted as described in
92    RFC 2119 <xref target="RFC2119"/>.</t>
93
94 </section>
95
96 <!--
97 Fernando,
98
99 I added several sections that should be later merged with your text
100 and formatted in accordance with the RFC format.
101
102 I wrote most of the text in a train without access to the Internet
103 and especially to RFC 6106
104
105 Pavel
106 -->
107
108 <section title="Solutions to the short RDNSS/DNSSL lifetime problem" anchor="solutions">
109     <section title="Avoiding short lifetimes" anchor="avoid-short">
110         <t>The long term solution to this problem is to avoid Lifetime
111         values that are too small when compared to MaxRtrAdvInterval.
112         This solution requires changes in the router software. The default
113         values in the current router solutions vary between MaxRtrAdvInterval
114         and 2*MaxRtrAdvInterval.</t>
115
116         <t>When specifying a better default value, the following
117         observesions deserve attention:</t>
118
119         <list style="symbols">
120             <t>IPv6 will be used on many links (including 802.11) that
121             experience packet loss. Therefore losing several packets
122             is not a reason to invalidate the DNS system.</t>
123
124             <t>Regular Router Advertisements are usually sent to IPv6 link
125             local multicast addresses. These are carried by Ethernet
126             multicast frames. Many active network elements have problems
127             with Ethernet multicast (including those that perform
128             bridging between wireless networks and wired networks).
129             Implementations of SLAAC should be able to cope with devices
130             that can lose several multicast packets in a row.</t>
131         </list>
132
133         <t>The default value of AdvRDNSSLifetime and AdvDNSSLLifetime
134         MUST be at least 5*MaxRtrAdvInterval so that there are enough
135         Router Advertisements recieved by the host to avoid this. When
136         the administrator sets a lower value, the system SHOULD issue
137         a warning.</t>
138
139         <t>Administrators of implementations not conforming to this
140         document SHOULD change both configuration options to
141         at least 5*MaxRtrAdvInterval to mitigate this problem.</t>
142
143         <t>This solution leaves out the following situations:</t>
144
145         <list style="symbols">
146             <t>If you can only update the host and not the routers,
147             you cannot use this solution in the short term. This also
148             applies to nomadic hosts that can connect to many different
149             networks. This case will be discussed later in this
150             document.</t>
151
152             <t>The affected network has a huge multicast packet loss.
153             This unfortunately happens in some real networks. This
154             is very hard to mitigate unless unicast Router Solicitation
155             and Router Advertisement are used. Administrators SHOULD
156             avoid using SLAAC with multicast Router Advertisements
157             on such networks.</t>
158         </list>
159     </section>
160
161     <section title="Use Router Solicitations as a last resort">
162         <t>According to RFC 6106, host MAY use Router Solicitation
163         to avoid expiry of RDNSS and DNSSL lifetimes. This technique
164         can be already used as a last resort.</t>
165
166         <t>TODO: We should either specify when and how should this
167         technique be used or specify that it should not be used at
168         all. For the rest of this section I will assume that we
169         want to encourage its use and document the possible problems
170         with this method.</t>
171
172         <t>Hosts SHOULD start sending multicast Router Solicitation when
173         most of the Lifetime of the last RDNSS server is consumed.
174         The precise time should be
175         a randomized value chosen from 70% to 90% of the original Lifetime
176         to avoid bursts of packets from other hosts on the network.</t>
177
178         <t>TODO: What to do with last DNSSL? Their nature is totally
179         different from RDNSS.</t>
180
181         <t>TODO: Router Solicitations should be repeated. At first I
182         suggested 10-20 seconds but there are other possibilities</t>
183
184         <t>Problems of this approach:</t>
185
186         <list style="symbols">
187             <t>If no IPv6 router responds, all previously connected
188             hosts will repeatedly send Router Solicitations and
189             only stop doing that when their RDNSS and DNSSL become
190             empty. This could disrupt IPv4 networking in larger
191             networks.</t>
192
193             <t>If IPv6 router responds with unicast Router
194             Advertisement, it may need to respond so to many
195             clients. Therefore it is advisable to let the
196             router respond in multicast (or maybe both?).</t>
197         </list>
198
199         <t>TODO: Appart from RFC 6106, Router Solicitation
200         is only used to avoid waiting for timed Router Advertisement
201         when connected to a network. No other timeouts are
202         being avoided using Router Solicitations.</t>
203
204         <t>TODO: We should either state a very good reason to
205         specialcase DNS timeouts or deprecate Router Solicitations
206         in RFC 6106 entirely.</t>
207     </section>
208
209     <section title="Use DNS even after Lifetime">
210         <t>TODO: This is maybe the most controversial technique
211         presented in this document. See below. It is a workaround
212         because it ignores the basic feature of a lifetime. This
213         effectively destroy both the purpose and *some of* the
214         problems of the Lifetime.</t>
215     </section>
216 <section>
217
218 <section title="Unnecessary configuration circulation">
219     <t>TODO: DNS configurations lists have a unique feature that they
220     are limited to very short lists. Newest items push out the
221     oldest ones. This can cause unneeded circulation of records if more
222     hosts store less configuration items than it recieves from the
223     network.</t>
224
225     <t>Hosts need the DNS system to allow the users to access Internet
226     and Intranet resources by name. If these information change
227     during the running connection, there are several approaches we can
228     choose from:</t>
229
230     <list style="symbols">
231         <t>Use the latest valid information. If the repository is full
232         and new item is recieved, drop the oldest one. This causes
233         changes to the ordered list on every recieved RA that doesn't
234         match the previous one.</t>
235
236         <t>Use the 
237
238         <t>Don't import new information when repository is full.
239         Use the latest available valid item (not the latest valid
240         recieved). This approach may drop older items after
241         ignoring the newer and eventually expire.</t>
242
243         <t>Deprecate the Lifetimes and treat them as always infinity.
244         Always use the latest info or the oldest working info. Maybe
245         drop defunct RDNSS</t>
246
247     <t>Hosts with automatically configured DNS SHOULD use DNS servers
248     provided by the current local network (RA or DHCPv6). It MUST NOT
249     use servers automatically configured in other networks.</t>
250
251     <section title="Do not provide excessive amount of information to hosts">
252         </t>The easiest possible solution can be performed by the network
253         administrators. Network administrators SHOULD NOT configure
254         network routers and DHCP servers in a way that causes hosts
255         to recieve repeatedly more RDNSS or DNSSL options they can actually
256         use.</t>
257
258         <t>TODO: Unfortunately, this solution depends on some minimum value
259         hosts are required to support. If hosts are required to keep six
260         RDNSS records, the network can have for example up to three routers
261         advertising two RDNSS each with no DHCP-configured nameservers.</t>
262     </section>
263
264
265
266 <t>The semantics of the 'Lifetime' field of the RDNSS and DNSSL options is updated as follows:
267 <list style="symbols">
268 <t>The 'Lifetime' field indicates the amount of time during which the aforementioned DNS-related information is expected to be stable.</t>
269 <t>If the information received in a RDNSS or DNSSL option is already present in the corresponding data structures, the corresponding 'Expiration' time should be updated according to the value in the 'Lifetime' field of the received option. A 'Lifetime' of '0' causes the corresponding information to be discarded, as already specified in <xref target="RFC6106"/>.
270 </t>
271 <t>If a host has already gathered a sufficient number of RDNSS addresses (or DNS search domain names), and additional data is received while the existing entries have not yet expired, the received RDNSS addresses (or DNS search domain names) SHOULD be ignored.
272 </t>
273 <t>If a host receives new RDNSS addresses (or DNS search domain names), and some of the existing entries have expired, the newly-learned information SHOULD be used to replace the expired entries.
274 </t>
275 <t>A host SHOULD flush configured DNS-related information when it has any reason to believe that its network connectivity has changed in some relevant way (e.g., there has been a "link change event"). When that happens, the host MAY send a Router Solicitation message to re-learn the corresponding DNS-related information. 
276 </t>
277 <t>The most-recently-updated information SHOULD have higher priority over the other DNS-related information already present on the local host.</t>
278 </list>
279 </t>
280
281 <t>The rationale for the suggested change is as follows:
282 <list style="symbols">
283 <t>It is a backwards-compatible local-policy change that solves the problem described in <xref target="intro"/> without requiring changes to router software or router configuration in existing deployments (over which the user is likely to have no control at all).</t>
284 <!--
285 <t>The change in the semantics of the 'Lifetime' field of RDNSS and DNSSL options</t>
286 -->
287 <t>Since different RDNSS and DNSSL information could be sent by the same router in different Router Advertisement messages, the updated semantics of the 'Lifetime' parameter prevents oscillations in network configuration.
288 <list style="hanging">
289 <t>This situation could arise for a number of reasons. For example, if the desire for different 'Lifetime' values warrants the use of different RDNSS or DNSSL options, and because of packet size issues each option must be included in a separate Router Advertisement message, each burst of RAs could cause DNS-related information to be reconfigured.
290 </t>
291 <t>Another possible scenario that could lead to the same situation is that in which there is more than one local router, and each of the local routers announces different RDNSS (or DNSSL) information. If the number of RDNSS addresses (or DNS search domain names) that the local host considers "sufficient" prevents the aggregate set of RDNSS (or DNSSL) information, the local RDNSS (or DNSSL) information would oscillate between that advertised by each of the local routers.
292 </t>
293 </list>
294 </t>
295
296 <t>The original motivation for enforcing a short expiration timeout value was to allow mobile nodes to prefer local RDNSSes to remote RDNSes. However, the recommendation in the last bullet above already allows for a timely update of the corresponding DNS-related information. Additionally, since it is already recommended by <xref target="RFC6106"/> to maintain some RDNSS addresses (or DNS search domain names) per source, in the typical scenarios in which a single router (per subnet) advertises configuration information, one of this 'slots' will be free (or have expired information) and readily available to be populated with information learned from the new subnet to which the host has moved.</t>
297 </list>
298 </t>
299 </section>
300
301
302     <section title="Security Considerations">
303
304         <t>This document does not introduce any additional security considerations to those documented in the "Security Considerations" section of <xref target="RFC6106"/>.</t>
305
306     </section>
307
308     <section title="Acknowledgements">
309 <t>The problem discussed in this document was discovered and reported to the 6man wg mailing-list by Pavel Simerda (and also confirmed by Teemu Savolainen thereafter). The solution proposed in <xref target="solution"/> was envisioned by Fernando Gont.</t> 
310
311 <!--
312 <t>The author would like to thank (in alphabetical order) XXX for providing valuable comments on earlier versions of this document.</t>
313 -->
314     </section>
315
316
317   </middle>
318
319   <back>
320   <references title='Normative References'>
321         <?rfc include="reference.RFC.2119" ?>
322         <?rfc include="reference.RFC.2460" ?>
323         <?rfc include="reference.RFC.4861" ?>
324         <?rfc include="reference.RFC.6106" ?>
325   </references>
326
327   <references title='Informative References'>
328
329 </references>
330
331 <section title="Analysis of other possible solutions" anchor="alt-solutions">
332
333
334 <t>As part of the recent discussion on the 6man mailing-list, it has been suggested that recommended 'Lifetime' value of RDNSS and DNSSL options be increased, as one of the possible solutions to the problem described in <xref target="intro"/>. The reasons for which such approach is not recommended in this document are:
335 <list style="symbols">
336 <t>It would require an update to router software, something that might be harder to perform (if at all possible) than an update to the corresponding host software.</t>
337 <t>This 'solution' does not address the potential network configuration oscillation issue discussed in <xref target="solution"/> and <xref target="additional-notes"/>.</t>
338 </list>
339 </t>
340 </section>
341
342 <section title="Additional notes regarding RFC 6106" anchor="additional-notes">
343 <t>Section 5.2 of <xref target="RFC6106"/> states:
344 <list style="hanging">
345 <t>
346 An RDNSS address or a DNSSL domain name MUST be used only as long as both the RA router Lifetime (advertised by a Router Advertisement message [RFC4861]) and the corresponding option Lifetime have not expired.
347 </t>
348 </list>
349 </t>
350
351 <t>This requirement could introduce problems in scenarios in which the router advertising the RDNSS or DNSSL options is not expected to be employed as a "default router", and hence the 'Router Lifetime' value of its Router Advertisement messages is set to 0.
352 <list style="hanging">
353 <t>As noted in Section 4.2 of <xref target="RFC4861"/>, the Router Lifetime applies only to the router's usefulness as a default router, and it does not apply to information contained in other message fields or options. 
354 </t>
355 </list>
356
357 Therefore, it would be sensible to exclude the 'Router Lifetime information when deciding about the validity or "freshness" of the DNS-related configuration information.
358 </t>
359
360 <t>Section 5.3.1 of <xref target="RFC6106"/> states:
361 <list style="hanging">
362 <t>
363 When the IPv6 host has gathered a sufficient number (e.g., three) of RDNSS addresses (or DNS search domain names), it SHOULD maintain RDNSS addresses (or DNS search domain names) by the sufficient number such that the latest received RDNSS or DNSSL is more preferred to the old ones; that is, when the number of RDNSS addresses (or DNS search domain names) is already the sufficient number, the new one replaces the old one that will expire first in terms of Lifetime. 
364 </t>
365 </list>
366 </t>
367 <t>As noted earlier in this document, this policy could lead (in some scenarios) to network configuration oscillations. Therefore, it would be sensible to enforce some minimum stability of the configured information, such as that resulting from the update in <xref target="solution"/>.
368 </t>
369
370
371 <t>Section 6.3 of <xref target="RFC6106"/> states:
372 <list style="hanging">
373 <t>
374       Step (d): For each DNSSL domain name, if it does not exist in the
375       DNS Search List, register the DNSSL domain name and Lifetime with
376       the DNS Search List and then insert the DNSSL domain name in front
377       of the Resolver Repository.  In the case where the data structure
378       for the DNS Search List is full of DNSSL domain name entries (that
379       is, has more DNSSL domain names than the sufficient number
380       discussed in Section 5.3.1), delete from the DNS Server List the
381       entry with the shortest Expiration-time (i.e., the entry that will
382       expire first). 
383 </t>
384 </list>
385
386 This policy could lead to the same network configuration oscillation problems as described above for the RDNSS addresses. Therefore, it would be sensible to enforce some minimum stability of the configured information, such as that resulting from the update in <xref target="solution"/>.
387 </t>
388 </section>
389
390   </back>
391 </rfc>