Initial commit
authorFernando Gont <fgont@si6networks.com>
Mon, 30 Apr 2012 20:16:59 +0000 (22:16 +0200)
committerPavel Šimerda <pavlix@pavlix.net>
Mon, 30 Apr 2012 20:16:59 +0000 (22:16 +0200)
draft-gont-6man-slaac-dns-config-issues-00.txt [new file with mode: 0644]

diff --git a/draft-gont-6man-slaac-dns-config-issues-00.txt b/draft-gont-6man-slaac-dns-config-issues-00.txt
new file mode 100644 (file)
index 0000000..c17e861
--- /dev/null
@@ -0,0 +1,672 @@
+
+
+
+IPv6 maintenance Working Group (6man)                            F. Gont
+Internet-Draft                                    SI6 Networks / UTN-FRH
+Updates: 6106 (if approved)                               April 30, 2012
+Intended status: Standards Track
+Expires: November 1, 2012
+
+
+        Current issues with DNS Configuration Options for SLAAC
+               draft-gont-6man-slaac-dns-config-issues-00
+
+Abstract
+
+   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.
+
+Status of this Memo
+
+   This Internet-Draft is submitted in full conformance with the
+   provisions of BCP 78 and BCP 79.  This document may not be modified,
+   and derivative works of it may not be created, and it may not be
+   published except as an Internet-Draft.
+
+   Internet-Drafts are working documents of the Internet Engineering
+   Task Force (IETF).  Note that other groups may also distribute
+   working documents as Internet-Drafts.  The list of current Internet-
+   Drafts is at http://datatracker.ietf.org/drafts/current/.
+
+   Internet-Drafts are draft documents valid for a maximum of six months
+   and may be updated, replaced, or obsoleted by other documents at any
+   time.  It is inappropriate to use Internet-Drafts as reference
+   material or to cite them other than as "work in progress."
+
+   This Internet-Draft will expire on November 1, 2012.
+
+Copyright Notice
+
+   Copyright (c) 2012 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+
+
+
+Gont                    Expires November 1, 2012                [Page 1]
+\f
+Internet-Draft       SLAAC DNS Configuration Issues           April 2012
+
+
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
+   2.  Solution to the problem  . . . . . . . . . . . . . . . . . . .  4
+   3.  Security Considerations  . . . . . . . . . . . . . . . . . . .  6
+   4.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  7
+   5.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  8
+     5.1.  Normative References . . . . . . . . . . . . . . . . . . .  8
+     5.2.  Informative References . . . . . . . . . . . . . . . . . .  8
+   Appendix A.  Analysis of other possible solutions  . . . . . . . .  9
+   Appendix B.  Additional notes regarding RFC 6106 . . . . . . . . . 10
+   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gont                    Expires November 1, 2012                [Page 2]
+\f
+Internet-Draft       SLAAC DNS Configuration Issues           April 2012
+
+
+1.  Introduction
+
+   RFC 6106 [RFC6106] specifies to Neighbor Discovery (ND) [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 Server (RDNSS) Option specifies the IPv6
+   addresses of recursive DNS servers, while the DNS Search List (DNSSL)
+   Option specifies a "search list" to be used when trying to resolve a
+   name by means of the DNS.
+
+   Each of this 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.  The aforementioned
+   "Lifetime" value is set 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 <=
+   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.
+
+   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.
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in RFC 2119 [RFC2119].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gont                    Expires November 1, 2012                [Page 3]
+\f
+Internet-Draft       SLAAC DNS Configuration Issues           April 2012
+
+
+2.  Solution to the problem
+
+   This document proposes a number of updates to RFC 6106, such that the
+   aforementioned issues can be mitigated.
+
+   The semantics of the 'Lifetime' field of the RDNSS and DNSSL options
+   is updated as follows:
+
+   o  The 'Lifetime' field indicates the amount of time during which the
+      aforementioned DNS-related information is expected to be stable.
+
+   o  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 [RFC6106].
+
+   o  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.
+
+   o  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.
+
+   o  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.
+
+   o  The most-recently-updated information SHOULD have higher priority
+      over the other DNS-related information already present on the
+      local host.
+
+   The rationale for the suggested change is as follows:
+
+   o  It is a backwards-compatible local-policy change that solves the
+      problem described in Section 1 without requiring changes to router
+      software or router configuration in existing deployments (over
+      which the user is likely to have no control at all).
+
+   o  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
+
+
+
+Gont                    Expires November 1, 2012                [Page 4]
+\f
+Internet-Draft       SLAAC DNS Configuration Issues           April 2012
+
+
+      oscillations in network configuration.
+
+         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.
+
+         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.
+
+   o  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 [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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gont                    Expires November 1, 2012                [Page 5]
+\f
+Internet-Draft       SLAAC DNS Configuration Issues           April 2012
+
+
+3.  Security Considerations
+
+   This document does not introduce any additional security
+   considerations to those documented in the "Security Considerations"
+   section of [RFC6106].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gont                    Expires November 1, 2012                [Page 6]
+\f
+Internet-Draft       SLAAC DNS Configuration Issues           April 2012
+
+
+4.  Acknowledgements
+
+   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 Section 2 was
+   envisioned by Fernando Gont.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gont                    Expires November 1, 2012                [Page 7]
+\f
+Internet-Draft       SLAAC DNS Configuration Issues           April 2012
+
+
+5.  References
+
+5.1.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2460]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
+              (IPv6) Specification", RFC 2460, December 1998.
+
+   [RFC4861]  Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
+              "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
+              September 2007.
+
+   [RFC6106]  Jeong, J., Park, S., Beloeil, L., and S. Madanapalli,
+              "IPv6 Router Advertisement Options for DNS Configuration",
+              RFC 6106, November 2010.
+
+5.2.  Informative References
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gont                    Expires November 1, 2012                [Page 8]
+\f
+Internet-Draft       SLAAC DNS Configuration Issues           April 2012
+
+
+Appendix A.  Analysis of other possible solutions
+
+   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 Section 1.  The reasons for which such approach is not
+   recommended in this document are:
+
+   o  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.
+
+   o  This 'solution' does not address the potential network
+      configuration oscillation issue discussed in Section 2 and
+      Appendix B.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gont                    Expires November 1, 2012                [Page 9]
+\f
+Internet-Draft       SLAAC DNS Configuration Issues           April 2012
+
+
+Appendix B.  Additional notes regarding RFC 6106
+
+   Section 5.2 of [RFC6106] states:
+
+      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.
+
+   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.
+
+      As noted in Section 4.2 of [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.
+
+   Therefore, it would be sensible to exclude the 'Router Lifetime
+   information when deciding about the validity or "freshness" of the
+   DNS-related configuration information.
+
+   Section 5.3.1 of [RFC6106] states:
+
+      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.
+
+   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 Section 2.
+
+   Section 6.3 of [RFC6106] states:
+
+      Step (d): For each DNSSL domain name, if it does not exist in the
+      DNS Search List, register the DNSSL domain name and Lifetime with
+      the DNS Search List and then insert the DNSSL domain name in front
+      of the Resolver Repository.  In the case where the data structure
+      for the DNS Search List is full of DNSSL domain name entries (that
+      is, has more DNSSL domain names than the sufficient number
+      discussed in Section 5.3.1), delete from the DNS Server List the
+
+
+
+Gont                    Expires November 1, 2012               [Page 10]
+\f
+Internet-Draft       SLAAC DNS Configuration Issues           April 2012
+
+
+      entry with the shortest Expiration-time (i.e., the entry that will
+      expire first).
+
+   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 Section 2.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gont                    Expires November 1, 2012               [Page 11]
+\f
+Internet-Draft       SLAAC DNS Configuration Issues           April 2012
+
+
+Author's Address
+
+   Fernando Gont
+   SI6 Networks / UTN-FRH
+   Evaristo Carriego 2644
+   Haedo, Provincia de Buenos Aires  1706
+   Argentina
+
+   Phone: +54 11 4650 8472
+   Email: fgont@si6networks.com
+   URI:   http://www.si6networks.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gont                    Expires November 1, 2012               [Page 12]
+\f