Re: [dhcwg] Simplification of DNAv4 specification

Stuart Cheshire <cheshire@apple.com> Thu, 13 October 2005 23:09 UTC

Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQCCM-0008Ul-3S; Thu, 13 Oct 2005 19:09:18 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQCCK-0008UM-Ng for dhcwg@megatron.ietf.org; Thu, 13 Oct 2005 19:09:16 -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 TAA00891 for <dhcwg@ietf.org>; Thu, 13 Oct 2005 19:09:12 -0400 (EDT)
Received: from mail-out3.apple.com ([17.254.13.22]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQCMu-0006Tn-5m for dhcwg@ietf.org; Thu, 13 Oct 2005 19:20:14 -0400
Received: from relay5.apple.com (a17-128-113-35.apple.com [17.128.113.35]) by mail-out3.apple.com (8.12.11/8.12.11) with ESMTP id j9DN95NU021591 for <dhcwg@ietf.org>; Thu, 13 Oct 2005 16:09:05 -0700 (PDT)
Received: from [17.202.44.119] (chesh7.apple.com [17.202.44.119]) by relay5.apple.com (Apple SCV relay) with SMTP id 09BB4324013 for <dhcwg@ietf.org>; Thu, 13 Oct 2005 16:09:05 -0700 (PDT)
Subject: Re: [dhcwg] Simplification of DNAv4 specification
Date: Thu, 13 Oct 2005 16:09:12 -0700
x-sender: cheshire@mail.apple.com
x-mailer: Claris Emailer 2.0v3, January 22, 1998
From: Stuart Cheshire <cheshire@apple.com>
To: DHCP discussion list <dhcwg@ietf.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <20051013230905.09BB4324013@relay5.apple.com>
X-Brightmail-Tracker: AAAAAA==
X-Spam-Score: 0.0 (/)
X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024
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

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.
--------------

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.

   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.
--------------

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
   recipt 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).
--------------

Stuart Cheshire <cheshire@apple.com>
 * Wizard Without Portfolio, Apple Computer, Inc.
 * www.stuartcheshire.org


_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg