Added 'Pad Lifetime to reasonable value' solution
[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="Solution to the short RDNSS/DNSSL lifetime problem (the server side)" anchor="avoid-short-server">
109     <t>The long term solution to this problem is to avoid Lifetime
110     values that are too small when compared to MaxRtrAdvInterval.
111     This solution requires changes in the router software. The default
112     values in the current router solutions vary between MaxRtrAdvInterval
113     and 2*MaxRtrAdvInterval.</t>
114
115     <t>When specifying a better default value, the following
116     observesions deserve attention:</t>
117
118     <list style="symbols">
119         <t>IPv6 will be used on many links (including 802.11) that
120         experience packet loss. Therefore losing several packets
121         is not a reason to invalidate the DNS system.</t>
122
123         <t>Regular Router Advertisements are usually sent to IPv6 link
124         local multicast addresses. These are carried by Ethernet
125         multicast frames. Many active network elements have problems
126         with Ethernet multicast (including those that perform
127         bridging between wireless networks and wired networks).
128         Implementations of SLAAC should be able to cope with devices
129         that can lose several multicast packets in a row.</t>
130     </list>
131
132     <t>The default value of AdvRDNSSLifetime and AdvDNSSLLifetime
133     MUST be at least 5*MaxRtrAdvInterval so that there are enough
134     Router Advertisements recieved by the host to avoid this. When
135     the administrator sets a lower value, the router system SHOULD
136     issue a warning.</t>
137
138     <t>Administrators of implementations not conforming to this
139     document SHOULD change both configuration options to
140     at least 5*MaxRtrAdvInterval to mitigate this problem.</t>
141
142     <t>This solution leaves out the following situations:</t>
143
144     <list style="symbols">
145         <t>If you can only update the host and not the routers,
146         you cannot use this solution in the short term. This also
147         applies to nomadic hosts that can connect to many different
148         networks. This case will be discussed later in this
149         document.</t>
150
151         <t>The affected network has a huge multicast packet loss.
152         This unfortunately happens in some real networks. This
153         is very hard to mitigate unless unicast Router Solicitation
154         and Router Advertisement are used. Administrators SHOULD
155         avoid using SLAAC with multicast Router Advertisements
156         on such networks.</t>
157     </list>
158 </section>
159
160 <section title="Solutions to the short RDNSS/DNSSL lifetime problem (the client side)" anchor="avoid-short-client">
161     <t>TODO: It is necessary to agree on at least one host side solutions as it may not be feasible
162     to update the router side in some situations</t>
163
164     <section title="Use Router Solicitations as a last resort" anchor="router-solicitations">
165         <t>According to RFC 6106, host MAY use Router Solicitation
166         to avoid expiry of RDNSS and DNSSL lifetimes. This technique
167         can be already used as a last resort.</t>
168
169         <t>TODO: We should either specify when and how should this
170         technique be used or specify that it should not be used at
171         all. For the rest of this section I will assume that we
172         want to encourage its use and document the possible problems
173         with this method.</t>
174
175         <t>Hosts SHOULD start sending multicast Router Solicitation when
176         most of the Lifetime of the last RDNSS server is consumed.
177         The precise time should be
178         a randomized value chosen from 70% to 90% of the original Lifetime
179         to avoid bursts of packets from other hosts on the network.</t>
180
181         <t>TODO: What to do with last DNSSL? Their nature is totally
182         different from RDNSS.</t>
183
184         <t>TODO: Router Solicitations SHOULD be repeated to avoid
185         packet loss. At first I
186         suggested 10-20 seconds but there are other possibilities</t>
187
188         <t>Problems of this approach:</t>
189
190         <list style="symbols">
191             <t>If no IPv6 router responds, all previously connected
192             hosts will repeatedly send Router Solicitations and
193             only stop doing that when their RDNSS and DNSSL become
194             empty. This could also disrupt IPv4 networking in larger
195             networks and that must be avoided.</t>
196
197             <t>If IPv6 router responds with unicast Router
198             Advertisement, it may need to respond so to many
199             clients. Therefore it is advisable to let the
200             router respond in multicast (or maybe both?).</t>
201         </list>
202
203         <t>TODO: Appart from RFC 6106, Router Solicitation
204         is only used to avoid waiting for timed Router Advertisement
205         when connected to a network. No other timeouts are
206         being avoided using Router Solicitations.</t>
207
208         <t>TODO: We should either state a very good reason to
209         specialcase DNS timeouts or deprecate Router Solicitations
210         in RFC 6106 entirely. Deprecation is the more favorable
211         option in our opinion.</t>
212     </section>
213
214     <section title="Pad Lifetime to reasonable values" anchor="pad-lifetime">
215         <t>Another approach is to pad small lifetimes to a reasonable value
216         on the client side. The problem of this technique is the selection
217         of a reasonable value. On the router side, it can be derived from
218         MaxRtrAdvInterval but this value is not known to the client side.</t>
219
220         <t>Therefore we would have to assume some maximum value of MaxRtrAdvInterval
221         and use it to derive minimum value of lifetimes instead of the actual
222         MaxRtrAdvInterval.</t>
223     </section>
224
225     <section title="Fallback to expired configuration items" anchor="fallback-to-expired">
226         <t>This solution suggests using expired configuration items
227         when there are no valid items left. Expired items are then
228         replaced with new valid items. </t>
229
230         <t>The semantics of the 'Lifetime' field of the RDNSS and DNSSL options is updated as follows:</t>
231
232         <list style="symbols">
233             <t>The 'Lifetime' field indicates the amount of time during which
234             the aforementioned DNS-related information is expected to be stable.</t>
235
236             <t>If the information received in a RDNSS or DNSSL option is
237             already present in the corresponding data structures, the
238             corresponding 'Expiration' time should be updated according to
239             the value in the 'Lifetime' field of the received option.
240             A 'Lifetime' of '0' causes the corresponding information to be
241             discarded, as already specified in <xref target="RFC6106"/>.</t>
242
243             <t>If a host has already gathered a sufficient number of RDNSS
244             addresses (or DNS search domain names), and additional data is
245             received while the existing entries have not yet expired, the
246             received RDNSS addresses (or DNS search domain names) SHOULD be
247             ignored.</t>
248
249             <t>If a host receives new RDNSS addresses (or DNS search domain names),
250             and some of the existing entries have expired, the newly-learned
251             information SHOULD be used to replace the expired entries.</t>
252
253             <t>A host SHOULD flush configured DNS-related information when it
254             has any reason to believe that its network connectivity has changed
255             in some relevant way (e.g., there has been a "link change event").
256             When that happens, the host MAY send a Router Solicitation message
257             to re-learn the corresponding DNS-related information.</t>
258
259             <t>The most-recently-updated information SHOULD have higher
260             priority over the other DNS-related information already present on
261             the local host.</t>
262         </list>
263
264         <t>The rationale for the suggested change is as follows:</t>
265
266         <list style="symbols">
267             <t>It is a backwards-compatible local-policy change that solves the
268             problem described in <xref target="intro"/> without requiring changes
269             to router software or router configuration in existing deployments
270             (over which the user is likely to have no control at all).</t>
271             <!--
272             <t>The change in the semantics of the 'Lifetime' field of RDNSS and DNSSL options</t>
273             -->
274             <t>Since different RDNSS and DNSSL information could be sent by the
275             same router in different Router Advertisement messages, the updated
276             semantics of the 'Lifetime' parameter prevents oscillations in network
277             configuration.</t>
278         </list>
279     </section>
280 </section>
281
282 <section title="Unnecessary configuration oscillation" anchor="oscillations">
283     <t>TODO: DNS configurations lists have a unique feature that they
284     are limited to very short lists. Newest items push out the
285     oldest ones. This can cause unneeded oscillation or circulation
286     of records if more hosts store less configuration items than it
287     recieves from the
288     network.</t>
289
290     <t>This situation could arise for a number of reasons. For example,
291     if the desire for different 'Lifetime' values warrants the use of
292     different RDNSS or DNSSL options, and because of packet size issues
293     each option must be included in a separate Router Advertisement message,
294     each burst of RAs could cause DNS-related information to be reconfigured.</t>
295
296     <t>Another possible scenario that could lead to the same situation is that
297     in which there is more than one local router, and each of the local routers
298     announces different RDNSS (or DNSSL) information. If the number of RDNSS
299     addresses (or DNS search domain names) that the local host considers
300     "sufficient" prevents the aggregate set of RDNSS (or DNSSL) information,
301     the local RDNSS (or DNSSL) information would oscillate between that
302     advertised by each of the local routers.</t>
303
304     <t>The original motivation for enforcing a short expiration timeout
305     value was to allow mobile nodes to prefer local RDNSSes to remote
306     RDNSes. However, the recommendation in the last bullet above already
307     allows for a timely update of the corresponding DNS-related information.
308     Additionally, since it is already recommended by <xref target="RFC6106"/>
309     to maintain some RDNSS addresses (or DNS search domain names) per source,
310     in the typical scenarios in which a single router (per subnet) advertises
311     configuration information, one of this 'slots' will be free (or have
312     expired information) and readily available to be populated with
313     information learned from the new subnet to which the host has moved.</t>
314
315     <t>Hosts need the DNS system to allow the users to access Internet
316     and Intranet resources by name. If these information change
317     during the running connection, there are several approaches we can
318     choose from:</t>
319
320     <list style="symbols">
321         <t>Use the latest valid information. If the repository is full
322         and new item is recieved, drop the oldest one. This causes
323         changes to the ordered list on every recieved RA that doesn't
324         match the previous one.</t>
325
326         <t>Don't import new information when repository is full. Drop
327         expired items. Use the latest available items. Active items
328         can unfortunately expire, because new ones are being ignored.
329         This can be mitigated by a relaxed approach to the lifetimes.
330         Expired items would be still used, which is a bit unusal,
331         but they would replaced as soon as new valid items arrive.</t>
332
333         <t>Deprecate the Lifetimes and treat them as always infinity.
334         Always use the latest items or the oldest working items.</t>
335     </list>
336
337     <t>Hosts with automatically configured DNS SHOULD use DNS servers
338     provided by the current local network (RA or DHCPv6). It MUST NOT
339     use servers automatically configured in other networks.</t>
340
341     <section title="Do not provide excessive amount of information to hosts">
342         <t>The easiest possible solution can be performed by the network
343         administrators. Network administrators SHOULD NOT configure
344         network routers and DHCP servers in a way that causes hosts
345         to recieve repeatedly more RDNSS or DNSSL options they can actually
346         use.</t>
347
348         <t>TODO: Unfortunately, this solution depends on some minimum value
349         hosts are required to support. If hosts are required to keep six
350         RDNSS records, the network can have for example up to three routers
351         advertising two RDNSS each with no DHCP-configured nameservers.</t>
352     </section>
353 </section>
354
355 <section title="Explicit expiration" anchor="explicit-expiration">
356     <t>TODO: Zero lifetimes are often used to perform explicit
357     expiration of configured items (including items in RDNSS and DNSSL lists).
358     The current practice is to advertise a zero lifetime in one Router
359     Advertisement and then continue as usual. This technique also suffers
360     from packet loss. A single lost packet cause that hosts do not
361     recieve this reconfiguration request.</t>
362
363     <t>Network operators SHOULD NOT rely on zero lifetimes at all. Routers
364     SHOULD send zero lifetimes in at least 5 subsequent unsolicited Router
365     Advertisements and in all solicited Router Advertisement during this
366     period.</t>
367
368     <t>TODO: Failure to deliver explicit expiration requests may cause
369     problems with reconfiguration. Another solution would be to deprecate
370     and discourage this technique altogether.</t>
371 </section>
372
373
374
375 <section title="Security Considerations">
376     <t>This document does not introduce any additional security considerations
377     to those documented in the "Security Considerations" section of <xref target="RFC6106"/>.</t>
378 </section>
379
380 <section title="Acknowledgements">
381     <t>The problem with short lifetimes discussed in this document
382     was discovered and reported to the 6man
383     wg mailing-list by Pavel Simerda. Teemu Savolainen presented the solution
384     with longer lifetimes and randomized Router Solicitations. Fernando Gont
385     discovered the configuration oscillation problem and proposed
386     a solution to both of these problems that features using DNS configuration
387     items after their lifetime.</t>
388
389 <!--
390 <t>The author would like to thank (in alphabetical order) XXX for providing valuable comments on earlier versions of this document.</t>
391 -->
392 </section>
393
394
395   </middle>
396
397   <back>
398   <references title='Normative References'>
399         <?rfc include="reference.RFC.2119" ?>
400         <?rfc include="reference.RFC.2460" ?>
401         <?rfc include="reference.RFC.4861" ?>
402         <?rfc include="reference.RFC.6106" ?>
403   </references>
404
405   <references title='Informative References'>
406
407 </references>
408
409 <section title="Analysis of other possible solutions" anchor="alt-solutions">
410
411 <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:
412 <list style="symbols">
413 <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>
414 <t>This 'solution' does not address the potential network configuration oscillation issue discussed in <xref target="oscillations"/> and <xref target="additional-notes"/>.</t>
415 </list>
416 </t>
417 </section>
418
419 <section title="Additional notes regarding RFC 6106" anchor="additional-notes">
420 <t>Section 5.2 of <xref target="RFC6106"/> states:
421 <list style="hanging">
422 <t>
423 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.
424 </t>
425 </list>
426 </t>
427
428 <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.
429 <list style="hanging">
430 <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.
431 </t>
432 </list>
433
434 Therefore, it would be sensible to exclude the 'Router Lifetime information when deciding about the validity or "freshness" of the DNS-related configuration information.
435 </t>
436
437 <t>Section 5.3.1 of <xref target="RFC6106"/> states:
438 <list style="hanging">
439 <t>
440 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.
441 </t>
442 </list>
443 </t>
444 <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="alt-solutions"/>.
445 </t>
446
447
448 <t>Section 6.3 of <xref target="RFC6106"/> states:
449 <list style="hanging">
450 <t>
451       Step (d): For each DNSSL domain name, if it does not exist in the
452       DNS Search List, register the DNSSL domain name and Lifetime with
453       the DNS Search List and then insert the DNSSL domain name in front
454       of the Resolver Repository.  In the case where the data structure
455       for the DNS Search List is full of DNSSL domain name entries (that
456       is, has more DNSSL domain names than the sufficient number
457       discussed in Section 5.3.1), delete from the DNS Server List the
458       entry with the shortest Expiration-time (i.e., the entry that will
459       expire first).
460 </t>
461 </list>
462
463 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="oscillations"/>.
464 </t>
465 </section>
466
467   </back>
468 </rfc>