Improved wording and cleanups
authorPavel Šimerda <pavlix@pavlix.net>
Wed, 30 May 2012 09:56:09 +0000 (11:56 +0200)
committerPavel Šimerda <pavlix@pavlix.net>
Wed, 30 May 2012 09:56:09 +0000 (11:56 +0200)
draft-gont-6man-slaac-dns-config-issues-00.xml

index fb9277b..10d4a18 100644 (file)
@@ -8,7 +8,7 @@
 <?rfc symrefs="yes" ?>
 <?rfc strict="no" ?>
 
-<rfc 
+<rfc
        ipr="noDerivativesTrust200902"
        category="std"
        updates="6106"
@@ -29,7 +29,7 @@
        
         <address>
 
-            <postal>    
+            <postal>
                        <street>Evaristo Carriego 2644</street>
                <code>1706</code><city>Haedo</city>
                <region>Provincia de Buenos Aires</region>
@@ -60,7 +60,7 @@
     </author>
 
 
+
     <date year="2012" />
 
     <abstract>
@@ -71,8 +71,8 @@ RFC 6106 specifies two Neighbor Discovery options that can be included in Router
   </front>
 
   <middle>
-  
-   
+
+
 <section title="Introduction" anchor="intro">
 <t>
 RFC 6106 <xref target="RFC6106"/> specifies two 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 Servers (RDNSS) Option specifies the IPv6 addresses of recursive DNS servers, while the DNS Search List (DNSSL) Option specifies a list of DNS suffix domain names to be used when trying to resolve a name by means of the DNS.
@@ -105,58 +105,61 @@ and especially to RFC 6106
 Pavel
 -->
 
-<section title="Solutions to the short RDNSS/DNSSL lifetime problem" anchor="lifetime-too-short">
-    <section title="Avoiding short lifetimes" anchor="avoid-short">
-        <t>The long term solution to this problem is to avoid Lifetime
-        values that are too small when compared to MaxRtrAdvInterval.
-        This solution requires changes in the router software. The default
-        values in the current router solutions vary between MaxRtrAdvInterval
-        and 2*MaxRtrAdvInterval.</t>
+<section title="Solution to the short RDNSS/DNSSL lifetime problem (the server side)" anchor="avoid-short-server">
+    <t>The long term solution to this problem is to avoid Lifetime
+    values that are too small when compared to MaxRtrAdvInterval.
+    This solution requires changes in the router software. The default
+    values in the current router solutions vary between MaxRtrAdvInterval
+    and 2*MaxRtrAdvInterval.</t>
 
-        <t>When specifying a better default value, the following
-        observesions deserve attention:</t>
+    <t>When specifying a better default value, the following
+    observesions deserve attention:</t>
 
-        <list style="symbols">
-            <t>IPv6 will be used on many links (including 802.11) that
-            experience packet loss. Therefore losing several packets
-            is not a reason to invalidate the DNS system.</t>
-
-            <t>Regular Router Advertisements are usually sent to IPv6 link
-            local multicast addresses. These are carried by Ethernet
-            multicast frames. Many active network elements have problems
-            with Ethernet multicast (including those that perform
-            bridging between wireless networks and wired networks).
-            Implementations of SLAAC should be able to cope with devices
-            that can lose several multicast packets in a row.</t>
-        </list>
+    <list style="symbols">
+        <t>IPv6 will be used on many links (including 802.11) that
+        experience packet loss. Therefore losing several packets
+        is not a reason to invalidate the DNS system.</t>
+
+        <t>Regular Router Advertisements are usually sent to IPv6 link
+        local multicast addresses. These are carried by Ethernet
+        multicast frames. Many active network elements have problems
+        with Ethernet multicast (including those that perform
+        bridging between wireless networks and wired networks).
+        Implementations of SLAAC should be able to cope with devices
+        that can lose several multicast packets in a row.</t>
+    </list>
 
-        <t>The default value of AdvRDNSSLifetime and AdvDNSSLLifetime
-        MUST be at least 5*MaxRtrAdvInterval so that there are enough
-        Router Advertisements recieved by the host to avoid this. When
-        the administrator sets a lower value, the system SHOULD issue
-        a warning.</t>
+    <t>The default value of AdvRDNSSLifetime and AdvDNSSLLifetime
+    MUST be at least 5*MaxRtrAdvInterval so that there are enough
+    Router Advertisements recieved by the host to avoid this. When
+    the administrator sets a lower value, the router system SHOULD
+    issue a warning.</t>
 
-        <t>Administrators of implementations not conforming to this
-        document SHOULD change both configuration options to
-        at least 5*MaxRtrAdvInterval to mitigate this problem.</t>
+    <t>Administrators of implementations not conforming to this
+    document SHOULD change both configuration options to
+    at least 5*MaxRtrAdvInterval to mitigate this problem.</t>
 
-        <t>This solution leaves out the following situations:</t>
+    <t>This solution leaves out the following situations:</t>
 
-        <list style="symbols">
-            <t>If you can only update the host and not the routers,
-            you cannot use this solution in the short term. This also
-            applies to nomadic hosts that can connect to many different
-            networks. This case will be discussed later in this
-            document.</t>
-
-            <t>The affected network has a huge multicast packet loss.
-            This unfortunately happens in some real networks. This
-            is very hard to mitigate unless unicast Router Solicitation
-            and Router Advertisement are used. Administrators SHOULD
-            avoid using SLAAC with multicast Router Advertisements
-            on such networks.</t>
-        </list>
-    </section>
+    <list style="symbols">
+        <t>If you can only update the host and not the routers,
+        you cannot use this solution in the short term. This also
+        applies to nomadic hosts that can connect to many different
+        networks. This case will be discussed later in this
+        document.</t>
+
+        <t>The affected network has a huge multicast packet loss.
+        This unfortunately happens in some real networks. This
+        is very hard to mitigate unless unicast Router Solicitation
+        and Router Advertisement are used. Administrators SHOULD
+        avoid using SLAAC with multicast Router Advertisements
+        on such networks.</t>
+    </list>
+</section>
+
+<section title="Solutions to the short RDNSS/DNSSL lifetime problem (the client side)" anchor="avoid-short-client">
+    <t>TODO: It is necessary to agree on at least one host side solutions as it may not be feasible
+    to update the router side in some situations</t>
 
     <section title="Use Router Solicitations as a last resort" anchor="router-solicitations">
         <t>According to RFC 6106, host MAY use Router Solicitation
@@ -178,7 +181,8 @@ Pavel
         <t>TODO: What to do with last DNSSL? Their nature is totally
         different from RDNSS.</t>
 
-        <t>TODO: Router Solicitations should be repeated. At first I
+        <t>TODO: Router Solicitations SHOULD be repeated to avoid
+        packet loss. At first I
         suggested 10-20 seconds but there are other possibilities</t>
 
         <t>Problems of this approach:</t>
@@ -187,8 +191,8 @@ Pavel
             <t>If no IPv6 router responds, all previously connected
             hosts will repeatedly send Router Solicitations and
             only stop doing that when their RDNSS and DNSSL become
-            empty. This could disrupt IPv4 networking in larger
-            networks.</t>
+            empty. This could also disrupt IPv4 networking in larger
+            networks and that must be avoided.</t>
 
             <t>If IPv6 router responds with unicast Router
             Advertisement, it may need to respond so to many
@@ -203,15 +207,14 @@ Pavel
 
         <t>TODO: We should either state a very good reason to
         specialcase DNS timeouts or deprecate Router Solicitations
-        in RFC 6106 entirely.</t>
+        in RFC 6106 entirely. Deprecation is the more favorable
+        option in our opinion.</t>
     </section>
 
-    <section title="Use DNS even after Lifetime" anchor="use-after-lifetime">
-        <t>TODO: This is maybe the most controversial technique
-        presented in this document. See below. It is a workaround
-        because it ignores the basic feature of a lifetime. This
-        effectively destroy both the purpose and *some of* the
-        problems of the Lifetime.</t>
+    <section title="Fallback to expired configuration items" anchor="fallback-to-expired">
+        <t>This solution suggests using expired configuration items
+        when there are no valid items left. Expired items are then
+        replaced with new valid items. </t>
 
         <t>The semantics of the 'Lifetime' field of the RDNSS and DNSSL options is updated as follows:</t>
 
@@ -413,7 +416,7 @@ An RDNSS address or a DNSSL domain name MUST be used only as long as both the RA
 
 <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>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>
 
@@ -423,7 +426,7 @@ Therefore, it would be sensible to exclude the 'Router Lifetime information when
 <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. 
+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>
@@ -442,7 +445,7 @@ When the IPv6 host has gathered a sufficient number (e.g., three) of RDNSS addre
       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). 
+      expire first).
 </t>
 </list>