RE: [dhcwg] Changes to remove "client-link-local-address" from th e DHCPv6 header

Ralph Droms <rdroms@cisco.com> Wed, 29 August 2001 23:50 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 TAA13574; Wed, 29 Aug 2001 19:50:17 -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 TAA00054; Wed, 29 Aug 2001 19:49:03 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA00032 for <dhcwg@ns.ietf.org>; Wed, 29 Aug 2001 19:49:01 -0400 (EDT)
Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13558 for <dhcwg@ietf.org>; Wed, 29 Aug 2001 19:47:41 -0400 (EDT)
Received: from rdroms-w2k.cisco.com (sjc-vpn2-178.cisco.com [10.21.112.178]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id TAA24060; Wed, 29 Aug 2001 19:48:27 -0400 (EDT)
Message-Id: <4.3.2.7.2.20010829194352.01ce3008@funnel.cisco.com>
X-Sender: rdroms@funnel.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Wed, 29 Aug 2001 19:45:29 -0400
To: "Bernie Volz (EUD)" <Bernie.Volz@am1.ericsson.se>
From: Ralph Droms <rdroms@cisco.com>
Subject: RE: [dhcwg] Changes to remove "client-link-local-address" from th e DHCPv6 header
Cc: dhcwg@ietf.org
In-Reply-To: <66F66129A77AD411B76200508B65AC697B34C2@eambunt705.ena-east .ericsson.se>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
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

Bernie,

Thanks for you careful review of the new text.  I made all
of the changes you suggested, except as noted below (RD>)

- Ralph

14.3.1. Creation and sending of Request messages 

   If a client has no valid IPv6 addresses of sufficient scope to 
   communicate with a DHCP server, it may send a Request message to 
BV> Why "communicate with a DHCP server"? And the client could well 
BV> have many addresses of sufficient scope - that's not the point 
BV> of the request. We really should just say that "If the client 
BV> is using stateful address configuration and either needs an 
BV> initial set of address or additional addresses, it MUST send a 
BV> Request message to obtain new addresses." (or something like that) 
   obtain new addresses.  The client includes one or more IAs in the 
   Request message, to which the server assigns new addresses.  The 
   server then returns IA(s) to the client in a Reply message. 

   The client generates a transaction ID and inserts this value in the 
   "transaction-ID" field. 

   The client places the address of the destination server in the 
   "server-address" field. 
BV> How about "The client copies the "server-address" field as received in 
BV> the selected Advertise message to the "server-address" field of the 
BV> Request." 

RD> Why the change?

   The client adds a DUID option to identify itself to the server.  The 
   client adds any other appropriate options, including one or more IA 
   options (if the client is requesting that the server assign it some 
   network addresses).  The list of addresses in each included IA MUST 
   be empty.  If the client is not requesting that the server assign it 
BV> IA MUST be empty? This wasn't what we had been discussing?? Wasn't 
BV> it that people wanted the addresses received in the Advertise to be 
BV> used here? 

RD> I leave this for the IA option and semantics design.

   any addresses, the client omits the IA option. 

   The client sends the Request message to the All DHCP Agents multicast 
   address through the interface for which the client is interested in 
   obtaining configuration information, with the destination port set 
   to 547.  The source port selection can be arbitrary, although it 
   SHOULD be possible using a client configuration facility to set a 
   specific source port value. 

   The server will respond to the Request message with a Reply 
   message.  If no Reply message is received within REP_MSG_TIMEOUT 
   milliseconds, the client retransmits the Request with the same 
   transaction-ID, and doubles the REP_MSG_TIMEOUT value, and waits 
   again.  The client continues this process until a Reply is received 
   or REQUEST_MSG_ATTEMPTS unsuccessful attempts have been made, at 
   which time the client MUST abort the configuration attempt.  The 
   client SHOULD report the abort status to the application layer. 

   Default and initial values for REP_MSG_TIMEOUT and REQ_MSG_ATTEMPTS 
   are documented in section 7.5. 



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