[dhcwg] Re: Simplification of DNAv4
"Bernard Aboba" <bernard_aboba@hotmail.com> Wed, 12 October 2005 15:08 UTC
Received: from localhost.localdomain ([127.0.0.1] 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 ([132.151.1.176] 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 [132.151.6.1]) 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 ([65.54.161.28] 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 65.54.161.200 by by106fd.bay106.hotmail.msn.com with HTTP; Mon, 26 Sep 2005 17:05:08 GMT
X-Originating-IP: [65.54.161.200]
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 procedure. 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 test(s). 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 DHCPv4." 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 dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg
- [dhcwg] Re: Simplification of DNAv4 Bernard Aboba