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

["Bernie Volz" <[e-mail]>]

Jinmei:

You'd prefer IPv4 based information over IPv6?

And DHCPv4, if Inform was used, doesn't have *ANY* time to expire the
information - so I don't think you'd want to use this information in
preference to DHCPv6 information with a time?

If you can't obtain newer information, you're always free to take whatever
steps you like on the client - ie, start a local recursive server daemon
(e.g., run BIND named on my laptop and specify ::1 in /etc/resolv.conf).


The issue of not receiving some information that was previously received is
a good one and we probably should give some advice in the draft as to
possible options that a client could chose (based on "local" policy). My own
feeling is that I'd discard the old information and use the new, especially
if the source can be trusted (ie, authentication was used). There may be
valid reasons why some options are no longer available; in other cases it
could be a configuration error and in that case it may be good for
administrators to know about it sooner than later. The worst is if it is a
Denial of Service attack, but in that case they can just as easily send you
bogus information.

- Bernie

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] 
> On Behalf Of JINMEI Tatuya / _–¾’BÆ
> Sent: Tuesday, August 24, 2004 8:12 AM
> To: Ted Lemon
> Cc: [e-mail]
> Subject: Re: [dhcwg] behavior on lifetime expiration (Re: 
> commentson draft-ietf-dhc-lifetime-01.txt)
> 
> 
> >>>>> On Mon, 23 Aug 2004 10:28:12 -0400,
> >>>>> Ted Lemon <[e-mail]> said:
> 
> >> - even if the clients cannot get a response by the expiration, it 
> >> should continue sending Information-requests.  However, it 
> can also 
> >> invalidate the expired information in some way, e.g., by 
> preferring a 
> >> "last resort" default or by using other means of configuration.
> 
> > Can you think of a real-world scenario where this would be 
> the right 
> > thing to do?   I can't come up with one.
> 
> 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 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.
> 
> Aside from the scenarios, I'm also concerned about a 
> (possible) pitfall with the "update timer" semantics.
> 
> 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?
> 
> If the former is the intent, it seems a bit odd to me that 
> the behavior is different based on whether the replied set is 
> empty or not (at least the specification is not very clear on 
> this).  If the latter is the intent, doesn't it almost mean 
> we invalidate the expired information X?
> 
> Anyway...so far, others do not seem to be very happy with the 
> idea of invalidating expired information.  If the above 
> explanation is still not so convincing, I won't stick to the 
> idea.  I can live with the "update timer" semantics as long 
> as the specification is clear enough to implement.
> 
> 					JINMEI, Tatuya
> 					Communication Platform Lab.
> 					Corporate R&D Center, 
> Toshiba Corp.
> 					[e-mail]
> 
> 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.
> 
> _______________________________________________
> dhcwg mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/dhcwg
> 


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