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

[Ted Lemon <[e-mail]>]

On Aug 24, 2004, at 8:12 AM, JINMEI Tatuya / 神明達哉 wrote:
> The scenario I thought of is that if the "lifetime" of a DNS
> (recursive) server expires with no update I'd stop using the server
> and start a local recursive server daemon (e.g., run BIND named on my
> laptop and specify ::1 in /etc/resolv.conf) as a last resort.  I'm
> quite sure that this is a "real world" scenario because I, for one,
> would like to have this feature and I'm living in the real world of
> the Internet.  I admit this might be a niche demand though.

I would never want to suggest that your needs as a network user are not 
representative of the average user, of course!   :')

However, let's consider your scenario a little more closely.   You 
acquire some information from the DHCP server.   Subsequently, for some 
reason, it becomes impossible for the server to respond to the client.

I have a couple of observations about this.   First, the time at which 
it becomes impossible for the server to respond is not the same as the 
time at which the client attempts to refresh its configuration 
information.   The two events are unrelated.

Second, we should consider why the DHCP server is no longer able to 
respond.   I would say the most likely scenario is that I am no longer 
connected to the same link, so that my routing information is stale.   
But in this case I am going to notice that I am no longer on the same 
link because of RA messages, or because of a physical network link 
state transition.   And this will happen at the time when it becomes 
impossible to contact the DHCP server, *not* at the time that the 
refresh time comes.   So I would say in this case that you will already 
have invalidated the refresh timer and the information covered by the 
refresh timer, so we have no need to say what you would do when the 
refresh timer expired, because it will not ever expire.

Another scenario that might occur is that the DHCP server might be 
turned off, and then it wouldn't reply because it's not available.   In 
this case, I can think of two basic reasons why this might have 
happened.   One is that the server needs some kind of maintenance.   
The other is that DHCP service is no longer wanted on the link.

In the first case, you want to continue using the configuration 
information, because it's still valid.   It would be somewhat 
disastrous to stop using it.   In the second case, which I would argue 
is unlikely on a production network, it would be nice if there was some 
way to indicate that the information was no longer valid.

I would say that if you want to address the concern you've raised, this 
is the scenario that you need to address, and that the solution you've 
proposed doesn't fit the scenario you've described, because in the most 
common case where you care, the solution isn't needed, and in the 
second-most-common case, the proposed solution would result in the 
network becoming unusable to the average user.

> I can also think of a scenario where I'll then prefer information
> from DHCPv4 (over the expired information from DHCPv6).  But I don't
> know this makes sense in the real world.

This is a fertile area of DHCP research.   :')

> Assume that we have a reply to Information-request containing a DNS
> server address X with update timer (or lifetime) T.  T seconds later,
> the client will restart Information-request/reply exchanges.  If we
> then get a different DNS server address Y, we'll stop using the old
> address X and switch to Y.  This should exactly be the "renumbering
> scenario", and the behavior looks reasonable.  But what if the reply
> does not contain any new DNS server address?  Can we still continue to
> use address X, or will we then lose any usable DNS server address?

It's a good question.   I think that it's unlikely that the DNS server 
address would be missing unless the server had been configured to no 
longer send it, so I think it would indeed make sense to stop using the 
stale information.   This could be the answer to the scenario you 
proposed initially - if you want to turn off the DHCP server, you 
configure it to send an empty information reply message.   You leave it 
configured this way for the duration of the refresh time.   Then you 
turn it off, because you can be confident that any client that was 
connected to the network during the interval when it was sending empty 
information reply messages will no longer be relying on DHCP for the 
information the DHCP server had been providing.

This implies that if we *start up* on a link to which we were 
previously connected, we should immediately attempt to contact the DHCP 
server.   In this case, if we are not able to contact the DHCP server 
by the time the refresh time has passed, we can assume that it is no 
longer active on the link, and that any information we have cached is 
no longer valid.   This would be analogous to the INIT-REBOOT state in 
DHCPv4.

> p.s. I'm afraid I won't be able to be very active on the list this
> week.  I'd apologize in advance for future delay of my responses.

I would like to defer making a decision on this point until you have 
time to respond, so if that's next week, let's wait until next week to 
resolve these issues.


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