Re: [dhcwg] comments on draft-ietf-dhc-lifetime-01.txt

    Date:        Fri, 20 Aug 2004 08:44:14 -0400
    From:        "Bernie Volz" <volz@cisco.com>
    Message-ID:  <000e01c486b3$66af02b0$6401a8c0@amer.cisco.com>

  | I'm OK to restricting the Lifetime Option to replies to
  | Information-Request's.
  | 
  | The client MUST ignore a Lifetime Option that is in any message other than a
  | REPLY to an INFORMATION-REQUEST. A client MUST NOT include the Lifetime
  | Option number in an ORO except when sending an INFORMATION-REQUEST message.
  | 
  | The server MUST NOT include the Lifetime Option in any message other than a
  | REPLY to an INFORMATION-REQUEST.

I've been reading all of the messages on this topic (catching up) and I
haven't managed to find a reason why anyone would want to add this kind
of restriction, I just don't see the need.

You seem to all be imagining that things have to get much more complex
for the clients if they get two timer values, and they're different.
But that's nonsense.

All of these timers are just upper bounds - a client that wants to be
simple just wants a single timer.   If one option says "the upper bound
is 86400 seconds" and another says "the upper bound is 43200 seconds",
then to the client, it just tries again, for all the info, before the
43200 second timer expires.   This isn't complex, it is trivial.

On the other hand, if the client doesn't need to be quite that simple,
then I see no compelling reason to require it to be so.

In particular, and especially given we're talking about IPv6, I see
no reason why a client shouldn't use very long lease times (well,
comparatively long - in IPv4 I've seen values counted in years - that's
absurd, but values of several weeks for address lifetime should be
reasonable).    If there's no prospect that the prefixes are going to
change anytime soon, there's no reason that an IPv6 node shouldn't be
able to keep using its address for a very long time, even if the DHCP
server is down for an extended period (and that's what the lease timers
are all about really - no-one disputes but that addresses stop being
used when their lifetime expires).

On the other hand, we may want to be able to shift which hosts run various
servers with much time lag, so the "other option lifetime" (or whatever it
ends up being called) might want to be quite a bit smaller (maybe measured
in hours, or a day or so).

A simple client will simply refresh everything when the shorter timer
expires.   A complex one might prefer to just use info requests when the
shorter info timer expires, and only do the full dhcp protocol when the
addresses actually expire - aside from anything else, this allows dhcp-lite
servers to respond, where only a full duchv6 server can handle address 
requests.

Why would anyone really want to forbid this?   That's all the proposed
language is doing, nothing really gets any simpler (in a simple client now
instead of just taking the lower timer value, it instead has to know
to ignore this particular option if it happens to occur in that particular
message type - which I think is a rather unusual case).

kre

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