Subject: new issue: LL34 Better transition to routable from v4LL using DHCP

From: Erik Guttman <[email-masked]>
Date: Thu, 11 Sep 2003 11:14:02 +0200

Description of Issue: Better transition to routable from v4LL using DHCP
Submitter Name  Bernard Aboba
Submitter Email Address  [email-masked]
Date first submitted  11 Sep 03
Reference
Comment Type  Technical
Priority  S (must change)
Section  2.11 (new section)
Rationale/Explanation of issue:

(a)  We need to ensure an orderly method for recovering a routable
      address given LLv4 addressing.  Much of the time an LLv4 address
      is allocated inappropriately,  and so it's important to be able
      to obtain a routable address via DHCP if one is available.  The
      current LLv4 spec doesn't address this, and the current default
      retry interval of 5 minutes is way too long.

(b) Interactions of DHCP with LLv4. The LLv4 specification seems to
     imply that an LLv4 address should be allocated when a DHCPREQUEST
     or DHCPDISCOVER does not obtain an answer.  Existing implementations
     show that this behavior is problematic since the lack of response is
     most likely a temporary phenomena or the result of a bug of some
     kind rather than the lack of a DHCP server on the link.

     5 minutes is too long. I'd suggest 1 minute or even less (I've
     seen a Linux implementation which retries every 30 seconds with
     jitter and that works a lot better).

Lengthy description of problem:

Requested change:

Create a new section:
2.11  Repeatedly Attempt to Obtain A Routable Address

   As per Section 1.7, use a routable address is preferred to use of
   a link-local address.  In many cases, a link-local address is
   configured because a DHCP server failed to respond to an initial
   query, or is inoperative for some time.  Experience has shown that
   five minutes (see Appendix A.2 for example) was too long an
   interval to wait and try to configure with DHCP.

   A host which has been configured with an IPv4 link-local address
   SHOULD periodically attempt to obtain an IPv4 address via DHCP.
   The recommended policy is to attempt to configure using DHCP after
   waiting for RECONF_INTERVAL, plus a random number of seconds,
   uniformly distributed, between zero to RECONF_JITTER seconds.

Modify:
9.  Constants

Add:

    RECONF_INTERVAL      25 seconds
    RECONF_JITTER        10 seconds

---

From: Robert Elz <[email-masked]>
Date: Thu, 11 Sep 2003 19:35:42 +0700

I think you need to run that change past the dhcp WG to see
what opinions there are, as this is really a requirement being
added to dhcp clients (changing the dhcp client timers) and
not really anything specific to LL addressing.

I certainly agree that the long waits that dhcp clients usually
fall into after their initial few attempts to contact a dhcp
server can be most annoying, and that retrying more often would
be nicer from the end user's viewpoint.

On the other hand, I'm not sure that I'd be happy to have a LAN
with perhaps hundreds of hosts (maybe thousands) all sending
continuous streams of broadcast packets looking for a DHCP server.
(A thousand hosts, with a 25 second (avg) delay is 40 broadcast
packets a second, which is starting to get too high - make that
5000 hosts, which is not unreasonable in some switched environments,
and you're at 200 broadcast packets a second - which is beyond
inconvenient and into extremely annoying).

It may be that the correct strategy here is for hosts that have
failed to contact the DHCP server, to remain on a "slow retry"
regime, but always set the "broadcast reply" bit in dhcp requests.

Then, upon noticing a DHCP reply, hosts could (after a short random
delay to avoid a packet deluge) try again to get an address (no requirement
to request a broadcast reply, if not needed, after seeing one) - the
observed reply would indicate that the DHCP server has returned to life.

If there are just a few hosts that aren't getting replies, perhaps
because the DHCP server is ignoring them deliberately, having them
set the broadcast reply request bit (unnecessarily) will be harmless,
there won't be replies.

If the DHCP server has really gone absent, and there are lots of people
looking for replies, this would allow the hosts to avoid sending much
traffic until there is evidence that there's a reasonable chance of
achieving a result.

Ideally, the slow down rate would depend upon the number of clients
around to make requests (what is really wanted is one client at random
making a request every few seconds, and all the others staying quiet until
they observe a reply) but with DHCP, knowing how many other clients there
are would mean listening to request packets, that clients don't usually
want to do (and on some OS's is hard, without precluding the client from
also being a server on a different LAN).   So, probably there just needs
to be a reasonable compromise rate set.

But this is all DHCP, not LL addressing, and needs the DHCP experts
to give advice on - it is possible that they have considered, and
rejected, this kind of approach in the past.

kre

---

From: Mika Liljeberg <[email-masked]>
Date: Thu, 11 Sep 2003 20:34:27 +0300

> inconvenient and into extremely annoying).

Frequent polling is also a very bad idea from the standpoint of power
efficiency. Not all devices are tethered to a power outlet.

This is really a DHCP issue but it would seem preferable to have DHCP
servers announce their presence (and readines to assign addresses) with
a periodic broadcast, rather than have all the clients broadcasting in
an effort to locate a server.

A new DHCPADVERTISE message could easily be specified in a way that is
fully compatible with current DHCP usage.

Alternatively, I suppose servers could just periodically broadcast an
unsolicited DHCPOFFER, but I haven't really thought this through. There
may be reasons why this would not be a good idea.

	MikaL

---

From: Erik Guttman <[email-masked]>
Date: Thu, 11 Sep 2003 21:11:51 +0200

Mika,

I agree.  However, all we can do is suggest this as useful to the
DHC WG.  I am cc:ing the dhcwg on my reply.  I don't mean to start
a long sequence of cross posts, but in this particular area it may
be a good idea.

Thanks,

Erik

---

From: Robert Elz <[email-masked]>
Date: Fri, 12 Sep 2003 21:06:06 +0700

Date:        Thu, 11 Sep 2003 20:34:27 +0300
    From:        Mika Liljeberg <[email-masked]>
    Message-ID:  <1063301667.777.22.camel@hades>

  | Frequent polling is also a very bad idea from the standpoint of power
  | efficiency. Not all devices are tethered to a power outlet.

Yes.

  | This is really a DHCP issue but it would seem preferable to have DHCP
  | servers announce their presence (and readines to assign addresses) with
  | a periodic broadcast, rather than have all the clients broadcasting in
  | an effort to locate a server.

This is real hard to achieve - the clients can be almost anywhere, they're
not all on the same LAN as the DHCP server.   For this to be practical, the
DHCP server would need to know where all its possible relay agents were
located, and enlist their help in sending that kind of message.   That's
not something that a typical dhcp server knows now.

  | Alternatively, I suppose servers could just periodically broadcast an
  | unsolicited DHCPOFFER,

Same problem.

That's why watching for responses to someone else's queries can possibly
be a help.   Where it falls down is when there is no-one else to make
queries, that is, there's just one node.   If there was a way for a node
to know how many other clients existed (on the same LAN at least) then
nodes could backoff to a fixed query/second rate (for the LAN), but as
things are currently, there's no good way I know of to perform that count.

kre

---

From: Mika Liljeberg <[email-masked]>
Date: Fri, 12 Sep 2003 19:58:44 +0300

> not something that a typical dhcp server knows now.

Hmm. The relay agents know where the DHCP server is. Why not have the
relays poll the server and broadcast a DHCPADVERTISE on their local
link. It still better than having the clients poll the server through
the relays. Am I missing something?

	MikaL

---

From: John Schnizlein <[email-masked]>
Date: Fri, 12 Sep 2003 13:58:42 -0400

>the relays. Am I missing something?

The ZeroConf list is a strange place to be re-designing DHCP.
You might want to study the current design of discover, offer,
request and acknowledge before proposing dhcp-advertise on 
the DHC mailing list.

John