RE: [dhcwg] dhc wg last call on dhcpv6-reconfigure-rebind

Oh, good point about the tables at the end of the RFC ... I stopped
looking there as I'd found them to be less than accurate a number of
times.

That table also points out that Reconfigure Accept is allowed on
Information-Request. This is interesting because in order for the server
to ever send a Reconfigure to a stateless client, it would have to
retain information about the client. And, for a stateless client how
long should the server hold onto this information (reconfigure key,
client identifier, and address (or relay path) at a minimum)? Though I
guess one could tie this to the Information Refresh Time Option (RFC
4242) as that would set an upper bound as to how long to retain the
information. In that case, (for stateless clients) sending the
Reconfigure Accept in all Information-Request messages is likely
appropriate?

So, I guess this means that there isn't a specific reason to disallow
Reconfigure Accept for Information-Request, but it may have marginal
value depending on whether the server retains the requisite information
to ever issue a Reconfigure. Note that this is different than sending a
Reconfigure with a Reconfigure Message of Information-Request to a
stateful client.

And,
>In my mind the Reconfigure Accept is part of the lease. A server may
require
>clients use Reconfigure Accept or not issue a lease, for instance.

Fully agree. Policy in the server can dictate whether to offer leases to
clients that don't send Reconfigure Accept.

- Bernie 

-----Original Message-----
From: Shane Kerr [mailto:Shane_Kerr@isc.org] 
Sent: Tuesday, March 06, 2007 11:05 AM
To: Bernie Volz (volz)
Cc: dhcwg
Subject: Re: [dhcwg] dhc wg last call on dhcpv6-reconfigure-rebind

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Bernie Volz (volz) wrote:
> Since it looks like this draft will need a revision, might we also
want
> to address the following issues?
> 
> 1. When should a Client send a Reconfigure Accept (and the server
> respond with Reconfigure Accept). RFC 3315 only mentions this for the
> Solicit/Advertise and Request/Reply exchanges. Not for a Renew or
> Rebind.
> 
> Should this be prohibited on a Renew/Rebind? Is it optional? If
allowed,
> what should a client do if the client previously received a
Reconfigure
> Accept (Request/Reply) but fails to in the Renew/Reply or Rebind/Reply
> exchange? Should it disable Reconfigure support?

In my mind the Reconfigure Accept is part of the lease. A server may
require
clients use Reconfigure Accept or not issue a lease, for instance.

While the server could check the presence of this in Renew or Rebind
messages, I
think it would be simpler to always omit the option, and use the value
from the
original Reply.

This doesn't match what the table in 3315 says, because the table allows
Reconfigure Accept in Renew or Rebind. But if we allow it, we should
make it
clear that the server has to re-evaluate the lease based on a possible
change of
the Reconfigure Accept value.

> 2. The text in RFC 3315 isn't clear about when the server sends a
> Reconfigure Accept? In 18.2.1 (Receipt of Request Messages) in RFC
3315,
> is written:
>  
>     The server includes a Reconfigure Accept option if the server
wants
>     to require that the client accept Reconfigure messages.
>  
> Does this apply even if the client has not sent a Reconfigure Accept
> option in the Request message? That seems likely to be useless since
the
> client probably won't accept Reconfigure Accept (since if it did, it
> would have sent the option in the Request).
> 
> In a brief private exchange with Ralph, he thought that a qualifying
> clause is needed:
> 
>     The server includes a Reconfigure Accept option if the server
wants
>     to require that the client accept Reconfigure messages, if the
> client
>     sent a Reconfigure Accept option in the Request.

Makes sense to me.

- --
Shane
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFF7ZEzMsfZxBO4kbQRAv7ZAKDtgsk79hV0yH83939oTsEEuvOj8QCg1Gp7
AIuB3YNhA8X8vwTb0F/V2r8=
=HzzE
-----END PGP SIGNATURE-----

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