Re: [dhcwg] I-D ACTION:draft-ietf-dhc-dhcpv6-reconfigure-rebind-00.txt

[Ralph Droms <rdroms at cisco.com>]

Bernie - Good point about filing an errata for RFC 3315 clarifying that the
Renew can be sent to the server sending the Reconfigure as well as the
server from which the IA_* was originally assigned.

Stig and I spoke with Jari yesterday to get his IESG input. Jari advised us
that, as a practical matter, the IETF process for filing errata is in a
state of flux and that publishing this update as an RFC would be the better
process to follow.

The DOCSIS 3.0 spec team is of the opinion that being able to request a
Rebind is useful, as it doesn't require the configuration of the DHCPv6
client to a particular behavior (send Renew to original server or to server
from which the Reconfigure was received) and it allows more flexibility in
deployment of servers.

- Ralph


On 8/18/06 9:32 AM, "Bernie Volz (volz)" <volz at cisco.com> wrote:

> Wouldn't it be easier just to clarify RFC 3315 to state that the
> Reconfigure causes the client to Renew to the server that sent the
> (authenticated) Reconfigure?
> 
> RFC 3315 doesn't state where the RENEW should be sent. Implementations
> could do either - send the Renew to the original server or the server
> that sent the Reconfigure. The Reconfigure includes the
> server-identifier option, so the client has available all it needs to
> send the renewal to the server that initiated the Reconfigure.
> 
> We could address this immediately by filing an errata for RFC 3315 and
> incorporate that into an eventual RFC 3315-bis. I think doing this even
> if you wanted to proceed with this draft would be good otherwise client
> behavior will be unpredictable.
> 
> Or, are there other reasons why you feel strongly that REBIND should be
> allowed? (Perhaps you envision a system that can initiate client
> Reconfigures that isn't a DHCP server for that client -- but obviously
> it must be able to communicate with the DHCP servers to obtain the
> Reconfigure key or this system and the server must have a means to
> generate the same Reconfigure key for a client.)
> 
> - Bernie 
> 
> -----Original Message-----
> From: Internet-Drafts at ietf.org [mailto:Internet-Drafts at ietf.org]
> Sent: Tuesday, August 15, 2006 3:50 PM
> To: i-d-announce at ietf.org
> Cc: dhcwg at ietf.org
> Subject: [dhcwg] I-D
> ACTION:draft-ietf-dhc-dhcpv6-reconfigure-rebind-00.txt
> 
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Dynamic Host Configuration Working
> Group of the IETF.
> 
> Title  : Rebind Capability in DHCPv6 Reconfigure
> Messages
> Author(s) : D. Evans, R. Droms
> Filename :
> draft-ietf-dhc-dhcpv6-reconfigure-rebind-00.txt
> Pages  : 4
> Date  : 2006-9-15
> 
>    The Rebind message type in the Reconfigure Message option of a
>    Reconfigure message allows DHCPv6 servers to instruct clients to
>    perform a Rebind operation.
> 
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-reconfigure-re
> bind-00.txt
> 
> To remove yourself from the I-D Announcement list, send a message to
> i-d-announce-request at ietf.org with the word unsubscribe in the body of
> the message. 
> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
> to change your subscription settings.
> 
> Internet-Drafts are also available by anonymous FTP. Login with the
> username "anonymous" and a password of your e-mail address. After
> logging in, type "cd internet-drafts" and then
> "get draft-ietf-dhc-dhcpv6-reconfigure-rebind-00.txt".
> 
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> 
> Internet-Drafts can also be obtained by e-mail.
> 
> Send a message to:
> mailserv at ietf.org.
> In the body type:
> "FILE
> /internet-drafts/draft-ietf-dhc-dhcpv6-reconfigure-rebind-00.txt".
> 
> NOTE: The mail server at ietf.org can return the document in
> MIME-encoded form by using the "mpack" utility.  To use this
> feature, insert the command "ENCODING mime" before the "FILE"
> command.  To decode the response(s), you will need "munpack" or
> a MIME-compliant mail reader.  Different MIME-compliant mail
> readers
> exhibit different behavior, especially when dealing with
> "multipart" MIME messages (i.e. documents which have been split
> up into multiple messages), so check your local documentation on
> how to manipulate these messages.
> 
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.

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