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.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.