Re: [Fwd: new issue: LL34 Better transition to routable from v4LL using DHCP]
Ted Lemon <[email protected]>
| Newsgroups | gmane.ietf.dhc,gmane.ietf.zeroconf |
|---|---|
| Message-ID | <[email protected]> |
On Thursday 18 September 2003 22:52, Robert Elz wrote: > 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). That's one way to read it, yes. However, the reason for wanting this is that IPv4LL places a requirement on the network stack that it quickly *give up* trying to acquire an address, and several IPv4LL+DHCP implementations have in fact done this. And now we are being asked to put a bandaid on this by making it *re-acquire* an address quickly. So the root of the problem is, in fact, that the DHCP client is being made to act differently because of IPv4ll. 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. 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. I would direct your attention particularly to section 4.1, which says nothing like this.