[dhcwg] Re: Issue 37: Technical NITs
Bernard Aboba <aboba@internaut.com> Fri, 14 October 2005 21:35 UTC
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQXCy-0003Am-L3; Fri, 14 Oct 2005 17:35:20 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQXCw-0003Ae-Mm for dhcwg@megatron.ietf.org; Fri, 14 Oct 2005 17:35:18 -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 RAA27676 for <dhcwg@ietf.org>; Fri, 14 Oct 2005 17:35:14 -0400 (EDT)
Received: from outbound.mailhop.org ([63.208.196.171] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQXNk-0007Vm-4B for dhcwg@ietf.org; Fri, 14 Oct 2005 17:46:28 -0400
Received: from c-67-182-139-247.hsd1.wa.comcast.net ([67.182.139.247] helo=internaut.com) by outbound.mailhop.org with esmtpa (Exim 4.51) id 1EQXCv-0001wJ-C4; Fri, 14 Oct 2005 17:35:17 -0400
Received: by internaut.com (Postfix, from userid 1000) id 46BD25C1A3; Fri, 14 Oct 2005 14:35:19 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by internaut.com (Postfix) with ESMTP id 337FC34FF4; Fri, 14 Oct 2005 14:35:19 -0700 (PDT)
X-Mail-Handler: MailHop Outbound by DynDNS
X-Originating-IP: 67.182.139.247
X-Report-Abuse-To: abuse@dyndns.com (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information)
X-MHO-User: aboba
Date: Fri, 14 Oct 2005 14:35:19 -0700
From: Bernard Aboba <aboba@internaut.com>
To: dhcwg@ietf.org
Message-ID: <Pine.LNX.4.61.0510141433410.5653@internaut.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"
X-Spam-Score: 0.1 (/)
X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86
Cc: cheshire@apple.com
Subject: [dhcwg] Re: Issue 37: Technical NITs
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
These changes also generally look ok to me, with some modifications as proposed below. -------------------------------------------------------------------------- Issue 37: Technical NITs Submitter name: Stuart Cheshire Submitter email address: cheshire@apple.com Date first submitted: October 12, 2005 Reference: http://www1.ietf.org/mail-archive/web/dhcwg/current/msg05498.html Document: DNA-16 Comment type: T Priority: S Section: Various Rationale/Explanation of issue: I propose the following technical edits relative to <http://www.drizzle.com/~aboba/DNA/draft-ietf-dhc-dna-ipv4-17.txt> 2 lines changed at 189 (INIT-REBOOT does not actually require the host to do Duplicate Address Detection) -- OLD TEXT -- network, without needing to re-acquire it, allowing the host to bypass Duplicate Address Detection (DAD). -- NEW TEXT -- network, without needing to re-acquire it. -------------- [BA] Suggest "bypass Duplicate Address Detection (DAD) in situations where a DHCP NAK would be received." 5 lines changed at 201 (DNAv4 does in fact slightly increase the likelihood of an address conflict) -- OLD TEXT -- 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. -- NEW TEXT -- DNAv4 does not significantly increase the likelihood of an address conflict. The reachability test is only carried out for a network when the host has previously completed address conflict detection [ACD] and obtained an operable IPv4 configuration on that network. Restrictions on sending ARP Requests and Responses are described in Section 2.1.1. [BA] I'd prefer to use the term "DAD" so as not to create a dependency on the ACD document. One case where DNAv4 does increase the likelihood of an address conflict is when: o a DHCP server hands out an address lease o the host with that lease leaves the network o the DHCP server is power-cycled, or crashes and is rebooted o the DHCP server, having failed to save its lease table to persistent storage, assigns that same address to some other host o the first host returns, and having a still-valid lease with time remaining, proceeds to use its assigned address, conflicting with the new host that is now using that same address DHCP servers are supposed to save their lease tables in persistent storage, but almost no consumer-grade NAT gateway does so. Use of short DHCP lease lifetimes can mitigate this risk, though use of short DHCP lease lifetimes also limits the situations where DNAv4 has operable candidate configurations available to try. -------------- [BA] This looks ok. 10 lines changed at 268 (remove special-case distinction for "private addresses") -- OLD TEXT -- Duplicate Address Detection on the former network does not provide assurance against an address conflict on the new network. Until a host with a private address has confirmed the operability of its IPv4 configuration, it SHOULD NOT respond to ARP Requests, and SHOULD NOT broadcast ARP Requests containing its address within the sender protocol address field (ar$spa). However, where the host has an operable routable non-private address on a network, it MAY send ARP Requests using its address within the sender protocol address field (ar$spa) prior to confirming its IPv4 configuration, and MAY respond to ARP Requests. -- NEW TEXT -- address conflict detection [ACD] on the former network does not provide assurance against an address conflict on the new network. Until a host has confirmed the operability of its IPv4 configuration by receipt of the expected ARP response from the gateway, it SHOULD NOT respond to ARP Requests, and SHOULD NOT broadcast ARP Requests containing its address within the sender protocol address field (ar$spa). [BA] Prefer to keep the term "DAD" here, but otherwise this is ok. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg
- [dhcwg] Re: Issue 37: Technical NITs Bernard Aboba