[dhcwg] DNAv4 Issue 5: IPv4LL -> DHCP Transition

[Bernard Aboba <aboba@internaut.com>]

Issue 5: IPv4LL -> DHCP transition
Submitter: Robert Elz
Submitter email address: kre@munnari.OZ.AU
Date first submitted: September 10, 2003
Reference:
Document: DNAv4-00
Comment type: T
Priority: S
Section: 2.3
Rationale/Explanation of issue:

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 [and allocated an IPv4LL address is] 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.


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