draft-gont-6man-slaac-dns-config-issues-00.txt

IPv6 maintenance Working Group (6man)                            F. Gont
Internet-Draft                                    SI6 Networks / UTN-FRH
Updates: 6106 (if approved)                                   P. Simerda
Intended status: Standards Track                           June 15, 2012
Expires: December 17, 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 December 17, 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 & Simerda          Expires December 17, 2012               [Page 1]

Internet-Draft       SLAAC DNS Configuration Issues            June 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.  Possible Solutions . . . . . . . . . . . . . . . . . . . . . .  4
     2.1.  Summary of possible solutions  . . . . . . . . . . . . . .  4
     2.2.  Changing the Semantics of the 'Lifetime' field of
           RDNSS and DNSSL options  . . . . . . . . . . . . . . . . .  4
     2.3.  Changing the Default Values of the 'Lifetime' field of
           RDNSS and DNSSL options  . . . . . . . . . . . . . . . . .  6
     2.4.  Use Router Solicitations for active Probing  . . . . . . .  7
     2.5.  Sanitize the received RDNSS/DNSSL 'Lifetime' Values  . . .  7
   3.  Security Considerations  . . . . . . . . . . . . . . . . . . .  9
   4.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
   5.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
     5.1.  Normative References . . . . . . . . . . . . . . . . . . . 11
     5.2.  Informative References . . . . . . . . . . . . . . . . . . 11
   Appendix A.  Additional notes regarding RFC 6106 . . . . . . . . . 12
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14

























Gont & Simerda          Expires December 17, 2012               [Page 2]

Internet-Draft       SLAAC DNS Configuration Issues            June 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
   parameter 'MaxRtrAdvInterval', which specifies the maximum time
   allowed between sending unsolicited multicast Router Advertisements
   from an interface.  The recommended bounds (MaxRtrAdvInterval <=
   Lifetime <= 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 refresh 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.

   Section 2 proposes a number of ALTERNATIVE solutions to the problem,
   such that the 6man wg can discuss both of them.  It is expected that
   once the 6man wg converges on a preferred solution, the other ones
   will be removed from the document.

   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 & Simerda          Expires December 17, 2012               [Page 3]

Internet-Draft       SLAAC DNS Configuration Issues            June 2012


2.  Possible Solutions

   This section describes a number of possible ALTERNATIVE solutions to
   the problem, such that the 6man wg can discuss both of them.  It is
   expected that once the 6man wg converges on a preferred solution, the
   other one will be removed from the document.

2.1.  Summary of possible solutions

   Section 2.2 proposes to change the semantics of the RDNSS/DNSSL
   'Lifetime', thus fixing the 'expiration' problem outlined in
   Section 1 and the potential of 'network configuration oscillation'.
   Section 2.3 proposes to increase the 'Lifetime' value at the sending
   routers, fixing the "expiration" problem outlined in Section 1, but
   without addressing the potential of 'network configuration
   oscillation'.  Section 2.4 proposes to send Router Solicitations when
   expiration of RDNSS/DNSSL information is imminent, to elicit Router
   Advertisement messages.  Section 2.5 proposes to enforce a lower
   limit on the received RDNSS/DNSSL 'Lifetime' values at the client
   side.

2.2.  Changing the Semantics of the 'Lifetime' field of RDNSS and DNSSL
      options

   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.





Gont & Simerda          Expires December 17, 2012               [Page 4]

Internet-Draft       SLAAC DNS Configuration Issues            June 2012


   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
      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
      RDNSSes.  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



Gont & Simerda          Expires December 17, 2012               [Page 5]

Internet-Draft       SLAAC DNS Configuration Issues            June 2012


      the new subnet to which the host has moved.

2.3.  Changing the Default Values of the 'Lifetime' field of RDNSS and
      DNSSL options

   The default RDNSS/DNSSL "Lifetime" value in current the current
   router solutions vary between MaxRtrAdvInterval and
   2*MaxRtrAdvInterval.  This means that common packet loss rates can
   lead to the problem described in this document.

   One possible approach to mitigate this issue would be to avoid
   'Lifetime' values that are on the same order as MaxRtrAdvInterval.
   This solution would require, of course, changes in router software.

   When specifying a better default value, the following aspects should
   be considered:

   o  IPv6 will be used on many links (including IEEE 802.11) that
      experience packet loss.  Therefore losing a few packets in a short
      period of time should not invalidate DNS configuration
      information.

   o  Unsolicited Router Advertisements sent on Ethernet networks result
      in packets that employ multicast Ethernet Destination Addresses.
      A number of network elements (including those that perform
      bridging between wireless networks and wired networks) have
      problems with multicasted Ethernet frames, thus typically leading
      to packet loss of some of those frames.  Therefore, SLAAC
      implementations should be able to cope with devices that can lose
      several multicast packets in a row.

   The default value of AdvRDNSSLifetime and AdvDNSSLLifetime MUST be at
   least 5*MaxRtrAdvInterval so that the probability of hosts receiving
   unsolicited Router Advertisements is increased.

   This solution leaves out the following situations:

   o  In those scenarios in which the involved routers cannot be updated
      this solution will not be applicable.  This also limitation also
      applies to nomadic hosts that can connect to many different
      networks.  This case will be discussed later in this document.

   o  The affected network has a huge multicast packet loss.  This
      unfortunately happens in some real networks.

   o  This solution does not address the potential 'network
      configuration oscillation' issue described in Section 2.2.




Gont & Simerda          Expires December 17, 2012               [Page 6]

Internet-Draft       SLAAC DNS Configuration Issues            June 2012


2.4.  Use Router Solicitations for active Probing

   According to RFC 6106, hosts MAY send Router Solicitations to avoid
   expiry of RDNSS and DNSSL lifetimes.  This technique could be
   employed as a "last resort" when expiration of the RDNSS and DNSSL
   information is imminent.

   Hosts SHOULD start sending multicast Router Solicitation when most of
   the Lifetime of the last RDNSS server is consumed.  The precise time
   should be a randomized value chosen from 70% to 90% of the original
   Lifetime to avoid bursts of packets from other hosts on the network.
   Hosts MAY send up to MAX_RTR_SOLICITATIONS Router Solicitation
   messages, each separated by at least RTR_SOLICITATION_INTERVAL
   seconds (please see Section 6.3.7 of [RFC4861].

   Problems of this approach:

   o  If no IPv6 router responds, all previously connected hosts will
      repeatedly send Router Solicitations and only stop doing so when
      their RDNSS and DNSSL information finally expires.  This could
      disrupt IPv4 networking in larger networks and that must be
      avoided.

   o  If IPv6 router responds with unicast Router Advertisement, it may
      need to respond to many clients.

   o  There is no other SLAAC information that requires or would benefit
      from this kind of "active probing".

   o  This approach does not mitigate the potential 'network
      configuration oscillation' problem described in Section 2.2.

   NOTE: We should either state a very good reason to specialcase DNS
   timeouts or deprecate Router Solicitations in RFC 6106 entirely.
   Deprecation is the more favorable option in our opinion.

2.5.  Sanitize the received RDNSS/DNSSL 'Lifetime' Values

   Another possible approach would be to enforce a lower limit on the
   received RDNSS/DNSSL 'Lifetime' values on the client side.  The
   challenge this technique is the selection of a reasonable value.  On
   the router side, it can be derived from MaxRtrAdvInterval but this
   value is not known to the client side.

   Therefore we would have to assume some maximum value of
   MaxRtrAdvInterval and use it to derive minimum value of lifetimes
   instead of the actual MaxRtrAdvInterval.




Gont & Simerda          Expires December 17, 2012               [Page 7]

Internet-Draft       SLAAC DNS Configuration Issues            June 2012


   It should be noted that this approach would not address the potential
   'network configuration oscillation' issue described in Section 2.2.

















































Gont & Simerda          Expires December 17, 2012               [Page 8]

Internet-Draft       SLAAC DNS Configuration Issues            June 2012


3.  Security Considerations

   This document does not introduce any additional security
   considerations to those documented in the "Security Considerations"
   section of [RFC6106].














































Gont & Simerda          Expires December 17, 2012               [Page 9]

Internet-Draft       SLAAC DNS Configuration Issues            June 2012


4.  Acknowledgements


















































Gont & Simerda          Expires December 17, 2012              [Page 10]

Internet-Draft       SLAAC DNS Configuration Issues            June 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 & Simerda          Expires December 17, 2012              [Page 11]

Internet-Draft       SLAAC DNS Configuration Issues            June 2012


Appendix A.  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.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 & Simerda          Expires December 17, 2012              [Page 12]

Internet-Draft       SLAAC DNS Configuration Issues            June 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.2.












































Gont & Simerda          Expires December 17, 2012              [Page 13]

Internet-Draft       SLAAC DNS Configuration Issues            June 2012


Authors' Addresses

   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


   Pavel Simerda

   Phone: +420 775 996 256
   Email: pavlix@pavlix.net


































Gont & Simerda          Expires December 17, 2012              [Page 14]