Initial commit
[rdnss.git] / draft-gont-6man-slaac-dns-config-issues-00.txt
1
2
3
4 IPv6 maintenance Working Group (6man)                            F. Gont
5 Internet-Draft                                    SI6 Networks / UTN-FRH
6 Updates: 6106 (if approved)                               April 30, 2012
7 Intended status: Standards Track
8 Expires: November 1, 2012
9
10
11         Current issues with DNS Configuration Options for SLAAC
12                draft-gont-6man-slaac-dns-config-issues-00
13
14 Abstract
15
16    RFC 6106 specifies two Neighbor Discovery options that can be
17    included in Router Advertisement messages to convey information about
18    DNS recursive servers and DNS Search Lists.  Small lifetime values
19    for the aforementioned options have been found to cause
20    interoperability problems in those network scenarios in which these
21    options are used to convey DNS-related information.  This document
22    analyzes the aforementioned problem, and formally updates RFC 6106
23    such that these issues are mitigated.
24
25 Status of this Memo
26
27    This Internet-Draft is submitted in full conformance with the
28    provisions of BCP 78 and BCP 79.  This document may not be modified,
29    and derivative works of it may not be created, and it may not be
30    published except as an Internet-Draft.
31
32    Internet-Drafts are working documents of the Internet Engineering
33    Task Force (IETF).  Note that other groups may also distribute
34    working documents as Internet-Drafts.  The list of current Internet-
35    Drafts is at http://datatracker.ietf.org/drafts/current/.
36
37    Internet-Drafts are draft documents valid for a maximum of six months
38    and may be updated, replaced, or obsoleted by other documents at any
39    time.  It is inappropriate to use Internet-Drafts as reference
40    material or to cite them other than as "work in progress."
41
42    This Internet-Draft will expire on November 1, 2012.
43
44 Copyright Notice
45
46    Copyright (c) 2012 IETF Trust and the persons identified as the
47    document authors.  All rights reserved.
48
49    This document is subject to BCP 78 and the IETF Trust's Legal
50    Provisions Relating to IETF Documents
51    (http://trustee.ietf.org/license-info) in effect on the date of
52
53
54
55 Gont                    Expires November 1, 2012                [Page 1]
56 \f
57 Internet-Draft       SLAAC DNS Configuration Issues           April 2012
58
59
60    publication of this document.  Please review these documents
61    carefully, as they describe your rights and restrictions with respect
62    to this document.  Code Components extracted from this document must
63    include Simplified BSD License text as described in Section 4.e of
64    the Trust Legal Provisions and are provided without warranty as
65    described in the Simplified BSD License.
66
67
68 Table of Contents
69
70    1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
71    2.  Solution to the problem  . . . . . . . . . . . . . . . . . . .  4
72    3.  Security Considerations  . . . . . . . . . . . . . . . . . . .  6
73    4.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  7
74    5.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  8
75      5.1.  Normative References . . . . . . . . . . . . . . . . . . .  8
76      5.2.  Informative References . . . . . . . . . . . . . . . . . .  8
77    Appendix A.  Analysis of other possible solutions  . . . . . . . .  9
78    Appendix B.  Additional notes regarding RFC 6106 . . . . . . . . . 10
79    Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111 Gont                    Expires November 1, 2012                [Page 2]
112 \f
113 Internet-Draft       SLAAC DNS Configuration Issues           April 2012
114
115
116 1.  Introduction
117
118    RFC 6106 [RFC6106] specifies to Neighbor Discovery (ND) [RFC4861]
119    options that can be included in Router Advertisement messages to
120    convey information about DNS recursive servers and DNS Search Lists.
121    Namely, the Recursive DNS Server (RDNSS) Option specifies the IPv6
122    addresses of recursive DNS servers, while the DNS Search List (DNSSL)
123    Option specifies a "search list" to be used when trying to resolve a
124    name by means of the DNS.
125
126    Each of this options include a "Lifetime" field which specifies the
127    maximum time, in seconds, during which the information included in
128    the option can be used by the receiving system.  The aforementioned
129    "Lifetime" value is set as a function of the Neighbor Discovery
130    paramenter 'MaxRtrAdvInterval', which specifies the maximum time
131    allowed between sending unsolicited multicast Router Advertisements
132    from an interface.  The recommended bounds (MaxRtrAdvInterval <=
133    Lifetime lt;= 2*MaxRtrAdvInterval) have been found to be too short
134    for scenarios in which some Router Advertisement messages may be
135    lost.  In such scenarios, host may fail to receive unsolicited Router
136    Advertisements and therefore fail to referesh the expiration time of
137    the DNS-related information previously learned through the RDNSS and
138    DNSSL options), thus eventually discarding the aforementioned DNS-
139    related information prematurely.
140
141    Some implementations consider the lack of DNS-related information as
142    a hard failure, thus causing configuration restart.  This situation
143    is exacerbated in those implementations in which IPv6 connectivity
144    and IPv4 connectivity are bound together, and hence failure in the
145    configuration of one of them causes the whole link to be restarted.
146
147    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
148    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
149    document are to be interpreted as described in RFC 2119 [RFC2119].
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167 Gont                    Expires November 1, 2012                [Page 3]
168 \f
169 Internet-Draft       SLAAC DNS Configuration Issues           April 2012
170
171
172 2.  Solution to the problem
173
174    This document proposes a number of updates to RFC 6106, such that the
175    aforementioned issues can be mitigated.
176
177    The semantics of the 'Lifetime' field of the RDNSS and DNSSL options
178    is updated as follows:
179
180    o  The 'Lifetime' field indicates the amount of time during which the
181       aforementioned DNS-related information is expected to be stable.
182
183    o  If the information received in a RDNSS or DNSSL option is already
184       present in the corresponding data structures, the corresponding
185       'Expiration' time should be updated according to the value in the
186       'Lifetime' field of the received option.  A 'Lifetime' of '0'
187       causes the corresponding information to be discarded, as already
188       specified in [RFC6106].
189
190    o  If a host has already gathered a sufficient number of RDNSS
191       addresses (or DNS search domain names), and additional data is
192       received while the existing entries have not yet expired, the
193       received RDNSS addresses (or DNS search domain names) SHOULD be
194       ignored.
195
196    o  If a host receives new RDNSS addresses (or DNS search domain
197       names), and some of the existing entries have expired, the newly-
198       learned information SHOULD be used to replace the expired entries.
199
200    o  A host SHOULD flush configured DNS-related information when it has
201       any reason to believe that its network connectivity has changed in
202       some relevant way (e.g., there has been a "link change event").
203       When that happens, the host MAY send a Router Solicitation message
204       to re-learn the corresponding DNS-related information.
205
206    o  The most-recently-updated information SHOULD have higher priority
207       over the other DNS-related information already present on the
208       local host.
209
210    The rationale for the suggested change is as follows:
211
212    o  It is a backwards-compatible local-policy change that solves the
213       problem described in Section 1 without requiring changes to router
214       software or router configuration in existing deployments (over
215       which the user is likely to have no control at all).
216
217    o  Since different RDNSS and DNSSL information could be sent by the
218       same router in different Router Advertisement messages, the
219       updated semantics of the 'Lifetime' parameter prevents
220
221
222
223 Gont                    Expires November 1, 2012                [Page 4]
224 \f
225 Internet-Draft       SLAAC DNS Configuration Issues           April 2012
226
227
228       oscillations in network configuration.
229
230          This situation could arise for a number of reasons.  For
231          example, if the desire for different 'Lifetime' values warrants
232          the use of different RDNSS or DNSSL options, and because of
233          packet size issues each option must be included in a separate
234          Router Advertisement message, each burst of RAs could cause
235          DNS-related information to be reconfigured.
236
237          Another possible scenario that could lead to the same situation
238          is that in which there is more than one local router, and each
239          of the local routers announces different RDNSS (or DNSSL)
240          information.  If the number of RDNSS addresses (or DNS search
241          domain names) that the local host considers "sufficient"
242          prevents the aggregate set of RDNSS (or DNSSL) information, the
243          local RDNSS (or DNSSL) information would oscillate between that
244          advertised by each of the local routers.
245
246    o  The original motivation for enforcing a short expiration timeout
247       value was to allow mobile nodes to prefer local RDNSSes to remote
248       RDNSes.  However, the recommendation in the last bullet above
249       already allows for a timely update of the corresponding DNS-
250       related information.  Additionally, since it is already
251       recommended by [RFC6106] to maintain some RDNSS addresses (or DNS
252       search domain names) per source, in the typical scenarios in which
253       a single router (per subnet) advertises configuration information,
254       one of this 'slots' will be free (or have expired information) and
255       readily available to be populated with information learned from
256       the new subnet to which the host has moved.
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279 Gont                    Expires November 1, 2012                [Page 5]
280 \f
281 Internet-Draft       SLAAC DNS Configuration Issues           April 2012
282
283
284 3.  Security Considerations
285
286    This document does not introduce any additional security
287    considerations to those documented in the "Security Considerations"
288    section of [RFC6106].
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335 Gont                    Expires November 1, 2012                [Page 6]
336 \f
337 Internet-Draft       SLAAC DNS Configuration Issues           April 2012
338
339
340 4.  Acknowledgements
341
342    The problem discussed in this document was discovered and reported to
343    the 6man wg mailing-list by Pavel Simerda (and also confirmed by
344    Teemu Savolainen thereafter).  The solution proposed in Section 2 was
345    envisioned by Fernando Gont.
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391 Gont                    Expires November 1, 2012                [Page 7]
392 \f
393 Internet-Draft       SLAAC DNS Configuration Issues           April 2012
394
395
396 5.  References
397
398 5.1.  Normative References
399
400    [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
401               Requirement Levels", BCP 14, RFC 2119, March 1997.
402
403    [RFC2460]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
404               (IPv6) Specification", RFC 2460, December 1998.
405
406    [RFC4861]  Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
407               "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
408               September 2007.
409
410    [RFC6106]  Jeong, J., Park, S., Beloeil, L., and S. Madanapalli,
411               "IPv6 Router Advertisement Options for DNS Configuration",
412               RFC 6106, November 2010.
413
414 5.2.  Informative References
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447 Gont                    Expires November 1, 2012                [Page 8]
448 \f
449 Internet-Draft       SLAAC DNS Configuration Issues           April 2012
450
451
452 Appendix A.  Analysis of other possible solutions
453
454    As part of the recent discussion on the 6man mailing-list, it has
455    been suggested that recommended 'Lifetime' value of RDNSS and DNSSL
456    options be increased, as one of the possible solutions to the problem
457    described in Section 1.  The reasons for which such approach is not
458    recommended in this document are:
459
460    o  It would require an update to router software, something that
461       might be harder to perform (if at all possible) than an update to
462       the corresponding host software.
463
464    o  This 'solution' does not address the potential network
465       configuration oscillation issue discussed in Section 2 and
466       Appendix B.
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503 Gont                    Expires November 1, 2012                [Page 9]
504 \f
505 Internet-Draft       SLAAC DNS Configuration Issues           April 2012
506
507
508 Appendix B.  Additional notes regarding RFC 6106
509
510    Section 5.2 of [RFC6106] states:
511
512       An RDNSS address or a DNSSL domain name MUST be used only as long
513       as both the RA router Lifetime (advertised by a Router
514       Advertisement message [RFC4861]) and the corresponding option
515       Lifetime have not expired.
516
517    This requirement could introduce problems in scenarios in which the
518    router advertising the RDNSS or DNSSL options is not expected to be
519    employed as a "default router", and hence the 'Router Lifetime' value
520    of its Router Advertisement messages is set to 0.
521
522       As noted in Section 4.2 of [RFC4861], the Router Lifetime applies
523       only to the router's usefulness as a default router, and it does
524       not apply to information contained in other message fields or
525       options.
526
527    Therefore, it would be sensible to exclude the 'Router Lifetime
528    information when deciding about the validity or "freshness" of the
529    DNS-related configuration information.
530
531    Section 5.3.1 of [RFC6106] states:
532
533       When the IPv6 host has gathered a sufficient number (e.g., three)
534       of RDNSS addresses (or DNS search domain names), it SHOULD
535       maintain RDNSS addresses (or DNS search domain names) by the
536       sufficient number such that the latest received RDNSS or DNSSL is
537       more preferred to the old ones; that is, when the number of RDNSS
538       addresses (or DNS search domain names) is already the sufficient
539       number, the new one replaces the old one that will expire first in
540       terms of Lifetime.
541
542    As noted earlier in this document, this policy could lead (in some
543    scenarios) to network configuration oscillations.  Therefore, it
544    would be sensible to enforce some minimum stability of the configured
545    information, such as that resulting from the update in Section 2.
546
547    Section 6.3 of [RFC6106] states:
548
549       Step (d): For each DNSSL domain name, if it does not exist in the
550       DNS Search List, register the DNSSL domain name and Lifetime with
551       the DNS Search List and then insert the DNSSL domain name in front
552       of the Resolver Repository.  In the case where the data structure
553       for the DNS Search List is full of DNSSL domain name entries (that
554       is, has more DNSSL domain names than the sufficient number
555       discussed in Section 5.3.1), delete from the DNS Server List the
556
557
558
559 Gont                    Expires November 1, 2012               [Page 10]
560 \f
561 Internet-Draft       SLAAC DNS Configuration Issues           April 2012
562
563
564       entry with the shortest Expiration-time (i.e., the entry that will
565       expire first).
566
567    This policy could lead to the same network configuration oscillation
568    problems as described above for the RDNSS addresses.  Therefore, it
569    would be sensible to enforce some minimum stability of the configured
570    information, such as that resulting from the update in Section 2.
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615 Gont                    Expires November 1, 2012               [Page 11]
616 \f
617 Internet-Draft       SLAAC DNS Configuration Issues           April 2012
618
619
620 Author's Address
621
622    Fernando Gont
623    SI6 Networks / UTN-FRH
624    Evaristo Carriego 2644
625    Haedo, Provincia de Buenos Aires  1706
626    Argentina
627
628    Phone: +54 11 4650 8472
629    Email: fgont@si6networks.com
630    URI:   http://www.si6networks.com
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671 Gont                    Expires November 1, 2012               [Page 12]
672 \f