[dhcwg] Re: Simplification of DNAv4

"Bernard Aboba" <bernard_aboba@hotmail.com> Wed, 12 October 2005 15:08 UTC

Received: from localhost.localdomain ([] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPiDE-00042b-U5; Wed, 12 Oct 2005 11:08:12 -0400
Received: from odin.ietf.org ([] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EJwPo-0000rx-VQ for dhcwg@megatron.ietf.org; Mon, 26 Sep 2005 13:05:21 -0400
Received: from ietf-mx.ietf.org (ietf-mx []) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24314 for <dhcwg@ietf.org>; Mon, 26 Sep 2005 13:05:18 -0400 (EDT)
Received: from bay106-f18.bay106.hotmail.com ([] helo=hotmail.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EJwWr-0008FE-Tq for dhcwg@ietf.org; Mon, 26 Sep 2005 13:12:40 -0400
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 26 Sep 2005 10:05:08 -0700
Message-ID: <BAY106-F18C5D20591C0FCA6356979938B0@phx.gbl>
Received: from by by106fd.bay106.hotmail.msn.com with HTTP; Mon, 26 Sep 2005 17:05:08 GMT
X-Originating-IP: []
X-Originating-Email: [bernard_aboba@hotmail.com]
X-Sender: bernard_aboba@hotmail.com
From: Bernard Aboba <bernard_aboba@hotmail.com>
To: dhcwg@ietf.org
Date: Mon, 26 Sep 2005 10:05:08 -0700
Mime-Version: 1.0
Content-Type: text/plain; format="flowed"
X-OriginalArrivalTime: 26 Sep 2005 17:05:08.0869 (UTC) FILETIME=[72FC1350:01C5C2BC]
X-Spam-Score: 0.8 (/)
X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8
X-Mailman-Approved-At: Wed, 12 Oct 2005 11:08:00 -0400
Cc: aboba@internaut.com
Subject: [dhcwg] Re: Simplification of DNAv4
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: dhcwg.ietf.org
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
Sender: dhcwg-bounces@ietf.org
Errors-To: dhcwg-bounces@ietf.org

More detail on the proposed changes.

Delete the term "Most Likely Networks" or MLNs from the document,
using the term "networks" instead.

Delete Appendix A, and the references that it cites.

If the host checks most or all of the networks with operable configurations, 
then it doesn't need to estimate likelihood of any particular network being 
attached.  Thus, hints beyond "link up" are not important any more.

Change the last paragraph of Section 2.1.1 to the following:

"  In order to prevent synchronization, ARP Requests are delayed by a
   random interval uniformly distributed on 0 to JITTER_INTERVAL.  If
   the initial ARP Request does not elicit a response, the host waits
   for REACHABILITY_TIMEOUT.  The timeout value is doubled with each
   retransmission.  It is RECOMMENDED that a host retransmit no more
   than twice.  To provide damping in the case of spurious "Link Up"
   indications, it is recommended that the DNAv4 procedure be carried
   out no more than once a second."

The goal of the above paragraph is to mitigate potential issues arising from 
the increased traffic, in situations such as a power failure.

Add the following sentence to Section 3:

   "The default value of JITTER_INTERVAL is 120ms."

Change Section 2 to the following:

"2.  Overview

   On connecting to a new point of attachment, the host responds to a
   "Link Up" indication from the link layer by carrying out the DNAv4

   For each network that it connects to, it is assumed that the host
   saves to stable storage the following parameters:

    [1] The IPv4 and MAC address of the default gateway(s)

    [2] The IPv4 configuration parameters, including
        the assigned address and lease expiration time

   From the set of networks which have operable IPv4 address(es)
   associated with them, the host selects a subset, and attempts to
   confirm the configuration for each network, using the reachability
   test described in Section 2.1.

   If the reachability test is successful, verifying bi-directional
   connectivity to the default gateway(s), the host SHOULD continue to
   use the operable routable IPv4 address associated with the confirmed
   network, without needing to re-acquire it, allowing the host to
   bypass Duplicate Address Detection (DAD).

   If a DHCPv4 client is operational, it is RECOMMENDED that the host
   attempt to obtain IPv4 configuration via DHCPv4 in parallel with the
   reachability tests, with the host using the first answer returned.
   This ensures that the DNAv4 procedure will not result in additional
   delay in the case where reachability test(s) fail, or where sending a
   DHCPREQUEST from the INIT-REBOOT state, as described in [RFC2131]
   Section 3.2 and 4.3.2 completes more quickly than the reachability

   DNAv4 does not increase the likelihood of an address conflict.  The
   reachability test is only carried out for a network when the host has
   previously completed duplicate address detection and obtained an
   operable IPv4 configuration on that network.  Restrictions on sending
   ARP Requests and Responses are described in Section 2.1.1."

Change Section 2.1 to the following:

"  The host skips the reachability test for a network if any of the
   following conditions are true:

   [a] The host does not have an operable routable IPv4
       address on that network. In this case, the reachability
       test cannot confirm that the host has an operable
       routable IPv4 address, so completing the
       reachability test would serve no purpose.
       A host MUST NOT use the reachability test to
       confirm configuration of an IPv4 Link-Local
       address or a statically assigned IPv4 address.

   [b] The host does not know the default gateway(s) on
       that network.  In this case, insufficient information
       is available to carry out the reachability test.

   [c] If secure detection of network attachment is required.
       The reachability test utilizes ARP which is insecure.

   For a particular network, the host MAY test reachability to the
   primary default gateway, or it MAY test reachability to both the
   primary and secondary default gateways, in series or in parallel.  In
   order to ensure configuration validity,  the host SHOULD only
   configure default gateway(s) which pass the reachability test.

   In situations where more than one network is available on a given
   link, or the network configuration has changed, it is possible for
   the host to confirm more than one configuration.  For example, it is
   possible that one or more reachability test(s) succeed, and in
   addition, configuration is provided via DHCPv4.  In this case, a
   DNAv4 implementation SHOULD prefer the configuration provided via

Change the first paragraph of Section 2.2 to the following:

"  If the host has an operable routable IPv4 address on one or more
   networks, and DHCPv4 is enabled on the interface, the host SHOULD
   attempt to acquire an IPv4 configuration using DHCPv4, in parallel
   with one or more reachability tests.  This is accomplished by
   entering the INIT-REBOOT state, and sending a DHCPREQUEST to the
   broadcast address as specified in [RFC2131] Section 4.4.2."

Delete the first two paragraphs of Section 2.4 (now 2.3).

dhcwg mailing list