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

[Robert Elz <kre@munnari.OZ.AU>]

    Date:        Thu, 18 Sep 2003 23:38:16 -0500
    From:        Ted Lemon <mellon@fugue.com>
    Message-ID:  <200309182338.16364.mellon@fugue.com>

  | The correct fix is to make sure that the DHCP client does not in
  | fact modify its behaviour to make IPv4ll work, but rather to modify
  | IPv4ll so that it doesn't interfere with the operation of the DHCP client.

I have no problem with that, that's what I'd do.   The problem that we have
is that everyone wants everything to fall into the perfect state instantly.
Any time that we're in an unexpected state is "broken", even if there's
nothing the implementation could really have done about that.

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 - and yes, this means
borrowing some (more) IPv6 innovation and terminology for v4 (which is
really needed anyway to make dhcp work correctly - currently on the stack
I use, if dhcp gives me a v4 address, then the lease expires, dhcp will then
take away the address again - just as it should - but I can trivially avoid
that just by killing my dhcp process, the IP stack has no concept at all
of a lifetime for v4 addresses, if the dhcp process doesn't remove the
address, it is permanent, it should have a valid time, just as v6 addresses do).

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.

  | Lest you conclude that I am off my rocker, a way to check this would be to 
  | look for the place in RFC2131 where it says that the DHCP client should
  | wait for five minutes after failing (that is, having retried and timed out)
  | to  contact a DHCP server, before reinitiating an attempt to contact one.

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).

That's why I see this issue as an attempt to change DHCP from the zeroconf WG.
The LL processing happens just the same, other than wrt absolute times,
whatever the DHCP server does, but people want it to happen quickly, not
slowly...

This is exacerbated with LL addresses existing (the problem is made worse),
so now there's a greater incentive to fix it.

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".

kre


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