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

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

    Date:        Fri, 19 Sep 2003 14:01:01 -0500
    From:        Ted Lemon <mellon@nominum.com>
    Message-ID:  <200309191401.02029.mellon@nominum.com>

  | 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


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