Shorter lifetime, RS, something about ignoring lifetimes
authorPavel Šimerda <pavlix@pavlix.net>
Tue, 1 May 2012 16:53:00 +0000 (18:53 +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 8ba7fae..92f6b8f 100644 (file)
@@ -84,6 +84,8 @@ RFC 6106 <xref target="RFC6106"/> specifies two Neighbor Discovery (ND) <xref ta
 <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>This document proposes a number of updates to RFC 6106, such that the aforementioned issues can be mitigated.</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
@@ -91,9 +93,175 @@ RFC 6106 <xref target="RFC6106"/> specifies two Neighbor Discovery (ND) <xref ta
 
 </section>
 
-<section title="Solution to the problem" anchor="solution">
+<!--
+Fernando,
+
+I added several sections that should be later merged with your text
+and formatted in accordance with the RFC format.
+
+I wrote most of the text in a train without access to the Internet
+and especially to RFC 6106
+
+Pavel
+-->
+
+<section title="Solutions to the short RDNSS/DNSSL lifetime problem" anchor="solutions">
+    <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>
+
+        <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>
+
+        <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>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>
+
+        <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="Use Router Solicitations as a last resort">
+        <t>According to RFC 6106, host MAY use Router Solicitation
+        to avoid expiry of RDNSS and DNSSL lifetimes. This technique
+        can be already used as a last resort.</t>
+
+        <t>TODO: We should either specify when and how should this
+        technique be used or specify that it should not be used at
+        all. For the rest of this section I will assume that we
+        want to encourage its use and document the possible problems
+        with this method.</t>
+
+        <t>Hosts SHOULD start sending multicast Router Solicitation when
+        most of the Lifetime of the last RDNSS server is consumed.
+        The precise time should be
+        a randomized value chosen from 70% to 90% of the original Lifetime
+        to avoid bursts of packets from other hosts on the network.</t>
+
+        <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
+        suggested 10-20 seconds but there are other possibilities</t>
+
+        <t>Problems of this approach:</t>
+
+        <list style="symbols">
+            <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>
+
+            <t>If IPv6 router responds with unicast Router
+            Advertisement, it may need to respond so to many
+            clients. Therefore it is advisable to let the
+            router respond in multicast (or maybe both?).</t>
+        </list>
+
+        <t>TODO: Appart from RFC 6106, Router Solicitation
+        is only used to avoid waiting for timed Router Advertisement
+        when connected to a network. No other timeouts are
+        being avoided using Router Solicitations.</t>
+
+        <t>TODO: We should either state a very good reason to
+        specialcase DNS timeouts or deprecate Router Solicitations
+        in RFC 6106 entirely.</t>
+    </section>
+
+    <section title="Use DNS even 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>
+<section>
+
+<section title="Unnecessary configuration circulation">
+    <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
+    network.</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
+    choose from:</t>
+
+    <list style="symbols">
+        <t>Use the latest valid information. If the repository is full
+        and new item is recieved, drop the oldest one. This causes
+        changes to the ordered list on every recieved RA that doesn't
+        match the previous one.</t>
+
+        <t>Use the 
+
+        <t>Don't import new information when repository is full.
+        Use the latest available valid item (not the latest valid
+        recieved). This approach may drop older items after
+        ignoring the newer and eventually expire.</t>
+
+        <t>Deprecate the Lifetimes and treat them as always infinity.
+        Always use the latest info or the oldest working info. Maybe
+        drop defunct RDNSS</t>
+
+    <t>Hosts with automatically configured DNS SHOULD use DNS servers
+    provided by the current local network (RA or DHCPv6). It MUST NOT
+    use servers automatically configured in other networks.</t>
+
+    <section title="Do not provide excessive amount of information to hosts">
+        </t>The easiest possible solution can be performed by the network
+        administrators. Network administrators SHOULD NOT configure
+        network routers and DHCP servers in a way that causes hosts
+        to recieve repeatedly more RDNSS or DNSSL options they can actually
+        use.</t>
+
+        <t>TODO: Unfortunately, this solution depends on some minimum value
+        hosts are required to support. If hosts are required to keep six
+        RDNSS records, the network can have for example up to three routers
+        advertising two RDNSS each with no DHCP-configured nameservers.</t>
+    </section>
+
 
-<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">