Merge text from both authors
authorFernando Gont <fgont@si6networks.com>
Tue, 15 May 2012 09:31:33 +0000 (11:31 +0200)
committerPavel Šimerda <pavlix@pavlix.net>
Tue, 15 May 2012 09:31:33 +0000 (11:31 +0200)
I'm keeping Fernando as the author
of this change because I'm just moving around pieces
of his text.

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

index 0802efc..2b850ca 100644 (file)
@@ -212,16 +212,92 @@ Pavel
         because it ignores the basic feature of a lifetime. This
         effectively destroy both the purpose and *some of* the
         problems of the Lifetime.</t>
+
+        <t>The semantics of the 'Lifetime' field of the RDNSS and DNSSL options is updated as follows:</t>
+
+        <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>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.</t>
+        <list style="hanging">
     </section>
 <section>
 
-<section title="Unnecessary configuration circulation">
+<section title="Unnecessary configuration oscillation">
     <t>TODO: DNS configurations lists have a unique feature that they
     are limited to very short lists. Newest items push out the
-    oldest ones. This can cause unneeded circulation of records if more
-    hosts store less configuration items than it recieves from the
+    oldest ones. This can cause unneeded oscillation or circulation
+    of records if more hosts store less configuration items than it
+    recieves from the
     network.</t>
 
+    <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>
+
+    <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>
+
     <t>Hosts need the DNS system to allow the users to access Internet
     and Intranet resources by name. If these information change
     during the running connection, there are several approaches we can
@@ -281,55 +357,22 @@ Pavel
 </section>
 
 
-<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 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="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> 
+<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>
+</section>
 
 
   </middle>