Typos
authorPavel Šimerda <pavlix@pavlix.net>
Tue, 1 May 2012 13:05:22 +0000 (15:05 +0200)
committerPavel Šimerda <pavlix@pavlix.net>
Tue, 8 May 2012 16:53:44 +0000 (18:53 +0200)
draft-gont-6man-slaac-dns-config-issues-00.xml

index 005e06d..8ba7fae 100644 (file)
 
         </address>
     </author>
+    <author
+        fullname="Pavel Šimerda"
+        initials="P."
+        surname="Šimerda">
+        <address>
+            <phone>+420 775 996 256</phone>
+            <email>pavlix@pavlix.net</email>
+        </address>
+    </author>
+
 
  
     <date year="2012" />
@@ -65,10 +75,10 @@ RFC 6106 specifies two Neighbor Discovery options that can be included in Router
    
 <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.
+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.
 </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>Each of these 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. RFC 6106 specifies that both RDNSS and DNSSL should be bounded 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.