Re: WG consensus action: ACCEPT 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 Tuesday, September 30, 2003, at 12:55 PM, Mika Liljeberg wrote: >> I do agree with you. The DHCP client should not be broken or effected >> by IPv4LL. The host stack which uses both will of course be more >> complex than one which does not. > > Are you saying it is ok to run the DHCP and v4LL state machines > independently of each other? I just want to be absolutely clear on > this. This is the meat of the issue. The fact that the IPv4ll draft doesn't explicitly mention IPv4ll interaction with the DHCP state engine doesn't mean that there is no interaction. This is the topic about which I would like to see some dialog, and this is why I'm complaining. Erik, you are correct to say that the draft doesn't explicitly place requirements of any kind on DHCP. However, the draft does say what happens when routable IP addresses appear and disappear. And the problem with this is that we have seen implementors do the wrong thing because of this. The requirements in the draft about not having an IPv4ll address and an IPv4 routable address at the same time exacerbate the situation. So what would satisfy me would be some implementation notes in the document that looks something like this: x.x.x Interaction between DHCPv4 client and IPv4ll state machines A device that implements both IPv4ll and a DHCPv4 client MUST NOT alter the behavior of the DHCPv4 client to accommodate the IPv4ll state machine. Specifically, DHCPv4 specifies an INIT-REBOOT state. If a DHCPv4 client fails to contact a DHCP server while in INIT-REBOOT state, the implementor may be tempted to not configure the IP address from the client's valid DHCPv4 lease, preferring instead to acquire an IPv4ll address and use that address exclusively. This is an incorrect optimization. Instead, the implementor should allow the IPv4ll state machine in this case to acquire and use an IPv4ll address, while at the same time allowing the DHCPv4 client to configure the IP address from its lease. The problem with adding this text is that right now the IPv4ll draft isn't very helpful about how to choose an IP source address when you have both an IPv4ll address and a routable address. The result is that the implementor will have to figure this out on his or her own, through trial and error, or, more likely, will leave the problem unsolved, resulting in poor behavior in cases where both addresses are configured. I think that the draft needs to address this in detail, but whether it addresses this or not, in order for IPv4ll to not break the DHCP client, some text like what I've proposed needs to be added. I don't believe simply not explicitly requiring IPv4ll to break the DHCP INIT-REBOOT case is sufficient.