XML source
authorFernando Gont <fgont@si6networks.com>
Tue, 1 May 2012 10:25:12 +0000 (12:25 +0200)
committerPavel Šimerda <pavlix@pavlix.net>
Tue, 8 May 2012 16:53:35 +0000 (18:53 +0200)
draft-gont-6man-slaac-dns-config-issues-00.txt [deleted file]
draft-gont-6man-slaac-dns-config-issues-00.xml [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
deleted file mode 100644 (file)
index c17e861..0000000
+++ /dev/null
@@ -1,672 +0,0 @@
-
-
-
-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
diff --git a/draft-gont-6man-slaac-dns-config-issues-00.xml b/draft-gont-6man-slaac-dns-config-issues-00.xml
new file mode 100644 (file)
index 0000000..005e06d
--- /dev/null
@@ -0,0 +1,213 @@
+<?xml version="1.0" encoding="UTF-8"?>
+
+<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
+
+<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
+
+<?rfc toc="yes" ?>
+<?rfc symrefs="yes" ?>
+<?rfc strict="no" ?>
+
+<rfc 
+       ipr="noDerivativesTrust200902"
+       category="std"
+       updates="6106"
+       docName="draft-gont-6man-slaac-dns-config-issues-00">
+  <front>
+    <title abbrev="SLAAC DNS Configuration Issues">Current issues with DNS Configuration Options for SLAAC</title>
+    <area>Internet</area>
+    <workgroup>IPv6 maintenance Working Group (6man)</workgroup>
+
+
+<author
+        fullname="Fernando Gont"
+        initials="F."
+        surname="Gont">
+    <!-- abbrev not needed but can be used for the header
+         if the full organization name is too long -->
+        <organization abbrev="SI6 Networks / UTN-FRH">SI6 Networks / UTN-FRH</organization>
+       
+        <address>
+
+            <postal>    
+                       <street>Evaristo Carriego 2644</street>
+               <code>1706</code><city>Haedo</city>
+               <region>Provincia de Buenos Aires</region>
+               <country>Argentina</country>
+            </postal>
+            <phone>+54 11 4650 8472</phone>
+
+            <email>fgont@si6networks.com</email>
+<!--            <email>fernando@gont.com.ar</email> -->
+
+<!--
+<uri>http://www.cpni.gov.uk</uri>
+<uri>http://www.gont.com.ar</uri>
+-->
+<uri>http://www.si6networks.com</uri>
+        <!--            If I had a phone, fax machine, and a URI, I could add the following: --->
+
+        </address>
+    </author>
+
+    <date year="2012" />
+
+    <abstract>
+    <t>
+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.
+    </t>
+    </abstract>
+  </front>
+
+  <middle>
+  
+   
+<section title="Introduction" anchor="intro">
+<t>
+RFC 6106 <xref target="RFC6106"/> specifies to 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 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.
+</t>
+
+<t>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 &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.
+</t>
+
+<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.
+</t>
+
+<t>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 <xref target="RFC2119"/>.</t>
+
+</section>
+
+<section title="Solution to the problem" anchor="solution">
+
+<t>This document proposes a number of updates to RFC 6106, such that the aforementioned issues can be mitigated.</t>
+
+<t>The semantics of the 'Lifetime' field of the RDNSS and DNSSL options is updated as follows:
+<list style="symbols">
+<t>The 'Lifetime' field indicates the amount of time during which the aforementioned DNS-related information is expected to be stable.</t>
+<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"/>.
+</t>
+<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.
+</t>
+<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.
+</t>
+<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. 
+</t>
+<t>The most-recently-updated information SHOULD have higher priority over the other DNS-related information already present on the local host.</t>
+</list>
+</t>
+
+<t>The rationale for the suggested change is as follows:
+<list style="symbols">
+<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>
+<!--
+<t>The change in the semantics of the 'Lifetime' field of RDNSS and DNSSL options</t>
+-->
+<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.
+<list style="hanging">
+<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.
+</t>
+<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.
+</t>
+</list>
+</t>
+
+<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>
+</list>
+</t>
+</section>
+
+
+    <section title="Security Considerations">
+
+       <t>This document does not introduce any additional security considerations to those documented in the "Security Considerations" section of <xref target="RFC6106"/>.</t>
+
+    </section>
+
+    <section title="Acknowledgements">
+<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> 
+
+<!--
+<t>The author would like to thank (in alphabetical order) XXX for providing valuable comments on earlier versions of this document.</t>
+-->
+    </section>
+
+
+  </middle>
+
+  <back>
+  <references title='Normative References'>
+       <?rfc include="reference.RFC.2119" ?>
+       <?rfc include="reference.RFC.2460" ?>
+       <?rfc include="reference.RFC.4861" ?>
+       <?rfc include="reference.RFC.6106" ?>
+  </references>
+
+  <references title='Informative References'>
+
+</references>
+
+<section title="Analysis of other possible solutions" anchor="alt-solutions">
+
+
+<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:
+<list style="symbols">
+<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>
+<t>This 'solution' does not address the potential network configuration oscillation issue discussed in <xref target="solution"/> and <xref target="additional-notes"/>.</t>
+</list>
+</t>
+</section>
+
+<section title="Additional notes regarding RFC 6106" anchor="additional-notes">
+<t>Section 5.2 of <xref target="RFC6106"/> states:
+<list style="hanging">
+<t>
+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.
+</t>
+</list>
+</t>
+
+<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.
+<list style="hanging">
+<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. 
+</t>
+</list>
+
+Therefore, it would be sensible to exclude the 'Router Lifetime information when deciding about the validity or "freshness" of the DNS-related configuration information.
+</t>
+
+<t>Section 5.3.1 of <xref target="RFC6106"/> states:
+<list style="hanging">
+<t>
+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. 
+</t>
+</list>
+</t>
+<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"/>.
+</t>
+
+
+<t>Section 6.3 of <xref target="RFC6106"/> states:
+<list style="hanging">
+<t>
+      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
+      entry with the shortest Expiration-time (i.e., the entry that will
+      expire first). 
+</t>
+</list>
+
+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"/>.
+</t>
+</section>
+
+  </back>
+</rfc>