[dhcwg] Changed to DHCPv6 spec

Ralph Droms <rdroms@cisco.com> Wed, 12 June 2002 18:10 UTC

Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07539 for <dhcwg-archive@odin.ietf.org>; Wed, 12 Jun 2002 14:10:39 -0400 (EDT)
Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA16153 for dhcwg-archive@odin.ietf.org; Wed, 12 Jun 2002 14:11:14 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA16086; Wed, 12 Jun 2002 14:09:56 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA16056 for <dhcwg@optimus.ietf.org>; Wed, 12 Jun 2002 14:09:54 -0400 (EDT)
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07468 for <dhcwg@ietf.org>; Wed, 12 Jun 2002 14:09:18 -0400 (EDT)
Received: from rdroms-w2k.cisco.com (dhcp-161-44-149-253.cisco.com [161.44.149.253]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA22466 for <dhcwg@ietf.org>; Wed, 12 Jun 2002 14:09:23 -0400 (EDT)
Message-Id: <4.3.2.7.2.20020612140907.00b72450@funnel.cisco.com>
X-Sender: rdroms@funnel.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Wed, 12 Jun 2002 14:09:12 -0400
To: dhcwg@ietf.org
From: Ralph Droms <rdroms@cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Subject: [dhcwg] Changed to DHCPv6 spec
Sender: dhcwg-admin@ietf.org
Errors-To: dhcwg-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: <dhcwg.ietf.org>
X-BeenThere: dhcwg@ietf.org

Since the DHCPv6 spec went through WG last call, we've received feedback 
from several sources.  The latest draft of the spec, 
draft-ietf-dhc-dhcpv6-26.txt, includes changes based on that feedback.  The 
changes are summarized at the end of the spec; here is a summary of the 
changes that have an impact on the operation of the protocol:

* Deleted definition of the use of anycast from
   the base spec document; use of DHCPv6 over links
   that do not support multicast will be defined
   in separate docs (e.g., "IPv6 over XXX")
* The DUID based on an enterprise identifier now uses
   the Enterprise Number (as recorded by IANA) instead
   of a domain name
* The use of multiple relay agents ("chaining")
   between a client and a server is defined
* If a client does not receive a Reply in response to
   a Solicit message with a Rapid Commit option, it
   may send a Request to a router from which it received
   an Advertise message (received while the client was
   waiting for the Reply message)
* The Confirm message is now used only for checking that
   a client's addresses are "appropriate to the link"
   (the addresses are consistent with the DHCP server's
   knowledge of the network topology, prefix assignment
   and address assignment policies) to which the client
   is attached
* A server can send an identifier, called the
   "reconfigure nonce" to a client to prevent DoS attacks
   through Reconfigure messages sent from off-path attackers;
   the server initially sends the reconfigure nonce in
   a Reply and tags Reconfigure messages with the same
   reconfigure nonce to identify itself as the source
   of the Reconfigure message
* A client now MUST send an Option Request option listing
   all of the options the client wants to receive; a server
   may send other options in addition to those specified
   in the Option Request option
* Adjusted several of the retransmission parameters in
   section 5.6

Please respond to the mailing list if you have questions or comments about 
any of these changes...

- Ralph


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