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

Robert Elz wrote:
>     Date:        Fri, 27 Aug 2004 08:23:21 +0200
>     From:        Stig Venaas <Stig.Venaas@uninett.no>
>     Message-ID:  <20040827062321.GA15052@sverresborg.uninett.no>
>
>   | 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.
>
> Yes, it is a much bigger issue than just providing a mechanism for
> specifying when a new info request should be attempted.
>
> But it is when we specify that that the problem becomes obvious, and
> we need to have a solution - until now (including in IPv4) we mostly
> just pretended that none of this ever happened, and once learned, all
> of this information was static forever (hence, DNS "servers" (back end
> resolvers really) go in /etc/resolv.conf - that gets updated when the
> info changes, but applications know nothing of that, and simply keep on
> using the old information forever).
>
> All this is something of a quagmire - but is something that needs to be
> addressed, and ought to be addressed along with this new option (if not
> necessarily in the same document).

I agree that this is an issue, but I don't think it's something this document 
should address.  It's a larger part of the dhcp specification, and the 
example you gave could happen in stateful configuration as well.

For the example involving dns and this option, I read the draft as such: when 
the option expires, don't dismiss the configured dns data.  Request new 
information.  When new information is received, replace the existing data 
with the newly obtained.  This prevents the client from being left without 
dns while making an attempt to be current.  Also, if a server returns an 
empty set of dns servers, that is what the client should use.  It doesn't 
make much sense, but misconfigured dhcp servers aren't something a client 
should be programmed to handle.

Generalizing this issue is not simple.  How does a dhcp client update the ntp 
configuration?  And why does it?  The ntp configuration could be pointing to 
a server reachable from multiple networks.  This seems like local policy.

Joe Quanaim.

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