[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