Re: [dhcwg] behavior on lifetime expiration (Re: comments ondraft-ietf-dhc-lifetime-01.txt)

[Stig Venaas <[e-mail]>]

On Fri, Aug 27, 2004 at 12:45:02PM +0700, Robert Elz wrote:
>     Date:        Tue, 24 Aug 2004 21:00:45 -0400
>     From:        "Bernie Volz" <[e-mail]>
>     Message-ID:  <001501c48a3e$f4246d90$[e-mail]>
> 
>   | I'd vote for "Refresh Time Option". I have no problem renaming this
> 
> The name of the option isn't really the point.   Jinmei has a valid point,
> but didn't manage to express the real issue perhaps as clearly as should
> have been done.
> 
> The issue isn't really "what happens when the lifetime expires" (whatever
> you call it), the issue is "what happens when the DHCP server doesn't give
> us some information that was given to us before" ?
> 
> You're mostly all thinking (it seems) of the case where the DHCP server
> doesn't reply at all to a later request for information - and so no new
> data is provided.
> 
> The other case, where the dhcp server does reply, and supplies new information.
> We all know what to do in that case.
> 
> But those aren't the only two cases - the problem case is what happens when
> the (a) DHCP server does reply, but only supplies values for some of the
> options that an earlier DHCP response had supplied.
> 
> That is, suppose I ask for NTP servers and DNS servers.   When I boot
> I get told fe80::99 for NTP, and fe80::7 for DNS.   Then later, I ask
> again, and get told 2001:1234:5678::16 for DNS, but get no NTP server
> addresses supplied at all.
> 
> What is the client expected to do in that case?   It seems reasonably clear
> (to me anyway) that the likely cause of this kind of change, is that the
> client is a portable device, that has been moved from one location to
> another, and is now talking to a different DHCP server than it was before
> (though entirely possibly both servers migh just happen to have been
> configured at fe80::9 on their respective LANs).
> 
> Should the client just keep on using the (probably now bogus) NTP server
> address, or should it just give up on NTP, given the local lan most
> likely has no available server?   Does it make a difference if the
> previous "lifetime" has or has not expired?   Or for that matter, whether
> or not there was ever a lifetime option, or whether or not the client
> requested it (and knows anything aboutthis new option) ?

Thanks for making this clear. We just had some discussion on this, but
the problem was perhaps not clearly stated. And this is one of the
things I tried to ask. What would you do if this happened without this
option. As you said, this is a more generic problem, and it makes me
wonder whether people already have thought about this.

> Once you work out the right answer to that problem, it is a minor issue to
> extend that answer to the case where no answers at all are returned.

Is there a theoretical possibility that you get a response, but without
any options? That should possibly be treated differently from not
getting any reply at all.

> kre
> 
> ps: notice here I am not suggesting what the answer should be.

If you get a response from a server, and later a new from the same
server but with some options missing, then I believe the administrator
must have removed the it on purpose and the old information is not
valid.

However, this is not so clear if you get a reply from a new server.
If you're still in the same site, then I think situation is pretty
much like above. But if the client has moved to a new site, the old
information might be valid, but not necessarily.

E.g. if I learn an NTP server at home, I might wish to keep using it
from a new location, even if the administrator in that new location
doesn't care about NTP and hasn't configured anything. Whether I
should continue using the one at home really depends on policy. The
access to the NTP server might for instance be blocked in a firewall
deployed in/around my home site or the site I'm now visiting.

I'm not sure if the answer to these issues need to be described in
the draft since it's a more generic issue. OTOH this draft might be
the most obvious place we have for now.

Stig

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