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

From: Mika Liljeberg <[email-masked]>
Date: Fri, 19 Sep 2003 00:38:10 +0300

On Thu, 2003-09-18 at 20:56, Ted Lemon wrote:
> On Thursday 18 September 2003 12:37, Ted Lemon wrote:
> > So I think the right answer to this question is to simply decouple the
> > IPv4LL and DHCP state machines.
> 
> To be clear, I meant here "decouple the DHCP state machine from the IPv4ll 
> state machine," but not "decouple the IPv4LL state machine from the DHCP 
> state machine" - obviously this isn't possible if we do what I've proposed.

I don't think this is a particularly useful distinction.

>From the implementor's point of view the coupling either exists or it
doesn't. If it does exist an explicit interface is required between the
DHCP code and the v4LL code. How that interface is realized is an
implementation issue.

It would be better to have no coupling at all.

	MikaL

---

From: Robert Elz <[email-masked]>
Date: Fri, 19 Sep 2003 16:44:48 +0700

Date:        Thu, 18 Sep 2003 23:38:16 -0500
    From:        Ted Lemon <[email-masked]>
    Message-ID:  <[email-masked]>

  | 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

---

From: Robert Elz <[email-masked]>
Date: Fri, 19 Sep 2003 10:52:57 +0700

Date:        Thu, 18 Sep 2003 12:37:12 -0500
    From:        Ted Lemon <[email-masked]>
    Message-ID:  <[email-masked]>

  | So I think the right answer to this question is to simply decouple
  | the IPv4LL and DHCP state machines.

This is really irrelevant to the issue raised.   What was really being
requested, once all the wrapping is removed, was that this WG make a
change to the DHCP protocol (or perhaps more precisely, to the operational
requirements for DHCP) - that is to force DHCP clients to try harder to
get routable addresses (lower the delay as much as possible if there is
no immediate answer).

The relationship with LL addresses is purely coincidental to this.

That's why this really belongs in the DHCP working group (where apparently,
and I guess you already know, something has been proposed already), and
not here at all.

kre

---

From: Robert Elz <[email-masked]>
Date: Sat, 20 Sep 2003 17:39:35 +0700

Date:        Fri, 19 Sep 2003 14:01:01 -0500
    From:        Ted Lemon <[email-masked]>
    Message-ID:  <[email-masked]>

  | 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

Necessary or not wasn't my point (and I'm not disagreeing with you), just
that if anything were to be done in this area, changes in the LL spec by
the zeroconf WG are not the right way to do it...

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

Agreed.

  | It is helpful, however, for the IPv4ll agent to notice that the DHCP client 
  | has timed out in contacting the DHCP server.

Maybe, I am less sure about that one.

  | In this case, the DHCP client 
  | will still configure its interface if it has a valid lease.

Yes, and in most circumstances where that happens, that address will
work just as well as a LL address (the DHCP client is supposed to
verify that the lease still makes some kind of sense - it needs to do
that to choose between the several valid leases it might have from
past assignments (I've had clients allocated multi-year leases from some
weird servers, and sometimes had several of those simultaneously).  If
the DHCP client checks that the address seems functional before assigning
it, then the LL address would only be useful in the rarest cases.

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

That's true - but no-one knows.   The DHCP client doesn't (if it knew it
was incorrect, it would not configure it, to know it is correct it needs
a DHCP server response, which we are assuming does not happen), the LL
assignment machinery has no idea, it just sees a non-LL address (and perhaps
the DHCP timeout), but more than that, none of the applications that are
to use the address know either.   They're going to be faced with the
situation of having a choice of 2 local addresses to use, and no idea which
one is going to work better.   In most cases, the (old) DHCP address will
work fine, and probably reach more destinations than the LL address, so
in most cases that is what the applications are going to want to use, I
suspect.   Given that, doing the extra work to assign an LL address in this
scenario seems pointless.

  | So simply watching the interface isn't going to get you the best 
  | results for IPv4ll,

If getting the best results for IPv4LL was an objective, I'd probably
agree.   But it isn't.   Rather, IPv4LL is an attempt to get the best
results for the system (or more likely, the system's user).   That is,
it doesn't matter in the slightest if IPv4LL fails miserably, as long
as the end result is correct, and communications get established,
at least in the vast majority of cases.

kre