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

From: "Bernie Volz \(volz\)" <[email-masked]>
Date: Tue, 6 Mar 2007 08:52:03 -0500

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?

Note: Keeping the number of times that the Reconfigure Key is sent (in
the Auth option) to a minimum is a benefit since it makes it more
difficult for rogue clients to discover the key (possibly by snooping
traffic).

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.

- Bernie

_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: Shane Kerr <[email-masked]>
Date: Tue, 06 Mar 2007 17:05:07 +0100

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

>     sent a Reconfigure Accept option in the Request.

Makes sense to me.

- --
Shane

---

From: "Bernie Volz \(volz\)" <[email-masked]>
Date: Tue, 6 Mar 2007 11:36:54 -0500

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,
>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:[email-masked]] 
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

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

Makes sense to me.

- --
Shane