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

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

Mika Liljeberg wrote:
> On Thu, 2003-09-11 at 15:35, Robert Elz wrote:
> 
>>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).
> 
> 
> 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
> 

_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: Erik Guttman <[email-masked]>
Date: Tue, 23 Sep 2003 12:19:28 +0200

The text supplied by Bernard has the property that it does not
specify any new behavior for DHCP.  The new text makes it clear
that an implementation of IPv4LL must attempt to obtain configuration
via DHCP according to the DHCP specification, even if it has failed
to in the past.  I think this satisfies Ted's concern:

Ted Lemon wrote:
 > 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.

Erik