Re: [dhcwg] [Fwd: new issue: LL34 Better transition to routable from v4LL using DHCP]

[Ted Lemon <mellon@nominum.com>]

On Friday 19 September 2003 04:44, Robert Elz wrote:
> That is, my approach to this, which I don't think conflicts with the
> drafts at all, would be to start the DHCP client (let it go do its thing
> just like it does now, ignoring LL addressing), wait a second and a half
> (puerly because of that 1 second boring meaningless non-answered ping delay
> verifying that the address is not assigned) and then see if I have an
> address. If not, configure an LL address as documented, and use that.  Then
> keep monitoring the interface.  If a routable address appears from
> somewhere (most likely from DHCP, but anywhere will do) mark the LL address
> (if the LL process has reached this stage yet) as deprecated - [...]

Right, this is exactly what I had in mind too.

> The issue I was detecting in the issue (LL34) though is that once we're in
> that state, we don't want to remain in it, if a routable address should be
> available - LL34 is trying to tell DHCP to keep trying hard to get a
> routable address.

I don't think this is necessary.   Section 4.1 of RFC2131 is already pretty 
explicit about what the DHCP client is supposed to do - the problem is that 
some popular DHCP clients aren't doing this, because (I presume) their state 
machines have been tweaked to accomodate IPv4ll.

> No, I know that's not there - that's why I used the words "operational
> requirements" in the previous message - LL34 wants to force implementations
> to retry quickly.   2131 doesn't say "wait 5 minutes" but it also doesn't
> say "don't wait 5 minutes", or "try again every 5 seconds" - something like
> the latter is what LL34 seems to be asking of DHCP (though it actually
> says 1 minute, not 5 seconds, but hints that 30 secs would be even better).

Actually, section 4.1 already says that the DHCP client shouldn't back off to 
more than 64 seconds, so the DHCP client should be retrying roughly every 64 
seconds if it's following RFC2131.   Perhaps the IPv4ll spec needs to make 
clear that implementors of IPv4ll that also implement DHCP must still follow 
the recommendations put forth in RFC2131 section 4.1.

> Before LL, networking was simply broken, if no DHCP address could be
> obtained.   That's a simple state - easy to explain - easy for the user
> to handle ("popop box says no dhcp server responded, no address, no
> networking - someone fix the dhcp server please!").   With LL addresses
> getting no routable address is "expected", it isn't an error - the stack
> just configures an LL address and says "I'm ready, use me" - and the user
> believes all is OK - except nothing works.    In this situation we really
> want things to revert to the "fixed" state as quickly as possible, lest
> frustration result "where did I get this stupid useless address instead
> of the one I should have - the network is broken".

Right, and if we just don't let the IPv4ll state machine reach out and touch 
the DHCP state machine, this is precisely what will happen.   That is, the 
DHCP client should never care about IPv4ll.

It is helpful, however, for the IPv4ll agent to notice that the DHCP client 
has timed out in contacting the DHCP server.   In this case, the DHCP client 
will still configure its interface if it has a valid lease.   However, the 
IPv4ll agent at this point should probably also configure an IPv4ll address, 
since the address the DHCP client is using is by no means guaranteed to be 
correct.   So simply watching the interface isn't going to get you the best 
results for IPv4ll, although it's an improvement over having the IPv4ll agent 
reaching out and touching the DHCP client.


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