Explicit expiration
authorPavel Šimerda <pavlix@pavlix.net>
Tue, 8 May 2012 23:09:58 +0000 (01:09 +0200)
committerPavel Šimerda <pavlix@pavlix.net>
Tue, 8 May 2012 23:09:58 +0000 (01:09 +0200)
draft-gont-6man-slaac-dns-config-issues-00.xml

index 41a41b0..0802efc 100644 (file)
@@ -105,7 +105,7 @@ and especially to RFC 6106
 Pavel
 -->
 
-<section title="Solutions to the short RDNSS/DNSSL lifetime problem" anchor="solutions">
+<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.
@@ -260,7 +260,25 @@ Pavel
         RDNSS records, the network can have for example up to three routers
         advertising two RDNSS each with no DHCP-configured nameservers.</t>
     </section>
+</section>
 
+<section title="Explicit expiration">
+    <t>TODO: Zero lifetimes are often used to perform explicit
+    expiration of configured items (including items in RDNSS and DNSSL lists).
+    The current practice is to advertise a zero lifetime in one Router
+    Advertisement and then continue as usual. This technique also suffers
+    from packet loss. A single lost packet cause that hosts do not
+    recieve this reconfiguration request.</t>
+
+    <t>Network operators SHOULD NOT rely on zero lifetimes at all. Routers
+    SHOULD send zero lifetimes in at least 5 subsequent unsolicited Router
+    Advertisements and in all solicited Router Advertisement during this
+    period.</t>
+
+    <t>TODO: Failure to deliver explicit expiration requests may cause
+    problems with reconfiguration. Another solution would be to deprecate
+    and discourage this technique altogether.</t>
+</section>
 
 
 <t>The semantics of the 'Lifetime' field of the RDNSS and DNSSL options is updated as follows: