Subject: Fwd: The IPv4ll draft updates RFC2131

From: Ted Lemon <[email-masked]>
Date: Wed, 5 Mar 2003 12:55:29 -0600

This is the original message that I sent to Erik, Bernard, Ralph and 
Stuart describing the problem.   TBH, I do not think this is something 
that the zeroconf working group should be discussing - the reason I 
brought it up is that I think the DHC working group needs to discuss 
it.   The Zeroconf WG has already decided to change IPv4ll in such a 
way that it updates RFC2131, as I have explained below, so there's no 
particular reason to continue discussing that here.

Begin forwarded message:

> From: Ted Lemon <[email-masked]>
> Date: Thu Feb 27, 2003  2:05:38  PM America/Chicago
> To: [email-masked], Ralph Droms <[email-masked]>
> Cc: Stuart Cheshire <[email-masked]>, [email-masked]
> Subject: The IPv4ll draft updates RFC2131
> Message-Id: <[email-masked]>
>
> Erik, you have asserted that this draft doesn't update RFC2131 because 
> it does not do so explicitly - it refers to a state where a node has a 
> configured non-IPv4ll address, and a state where a node does not, but 
> doesn't say how transitions between these two states occur.
>
> In a literal reading of both documents, you are correct, but speaking 
> as someone who understands the DHCP standard pretty well, it is 
> obvious to me that there is a clear conflict - that IPv4ll requires 
> DHCP client behavior that is different than what is specified in 
> RFC2131.   I think that this conflict requires that IPv4ll be reviewed 
> by the DHC working group before advancing.
>
> RFC2131 states that when a DHCP client has a valid lease but is not 
> certain that the lease is correct for its network, it can enter the 
> INIT-REBOOT state to reconfirm the lease (it can also just continue to 
> use the lease without checking, except on startup).   This behavior is 
> strongly suggested because without it, a DHCP server outage can 
> disable a network.   DHCP clients that don't have stable storage 
> aren't *required* to implement this behavior, but in general it's 
> expected that most DHCP clients will implement it.
>
> Recent changes to the IPv4ll draft establish an interdependency 
> between IPv4ll and non-IPv4ll addresses - devices that are configured 
> with non-IPv4ll addresses are supposed to give up their IPv4ll 
> addresses.   Such nodes are supposed to re-initiate IPv4ll address 
> selection when they lose their non-IPv4ll addresses.   In practice, 
> whenever a DHCP client notices a network state transition, or is 
> power-cycled, it will enter INIT-REBOOT to check its lease.   The 
> outcome of this, according to RFC2131, is always that it will have a 
> configured address after entering INIT-REBOOT, either because it gives 
> up, or because it succeeds in contacting the DHCP server.
>
> If the DHCP client fails to contact a DHCP server, this can mean one 
> of two things: either it's no longer on a network managed by DHCP, or 
> it is still on that network, but the DHCP server is down or 
> unreachable.   If it is still on the same network, the behavior 
> specified in RFC2131 will work.   If it is not, the behavior specified 
> in RFC2131 will result in the device being unable to benefit from the 
> use of the IP address it got from DHCP, and also unable to use IPv4ll. 
>   So in practice, I would expect any IPv4ll implementor that cares 
> about the dependability of IPv4ll to modify their DHCP client so that 
> if it fails to contact the DHCP server, it stops using its lease.
>
> I have already seen one implementation of a pre-standard version of 
> IPv4ll that modifies the DHCP client's behavior in the INIT-REBOOT 
> state in the way I've described here, and I and one of my co-workers 
> at Nominum have already seen cases where this breaks IPv4 network 
> connectivity.   Whenever a DHCP client sees a network state transition 
> or is power cycled and comes up on a network with no DHCP service, the 
> DHCP client goes into an IPv4ll-only state and gives up its DHCP 
> lease.   As a result of this, existing TCP/IP sessions are 
> disconnected, even though the TCP connection timeout hasn't happened.
>
> We have directly observed this problem in two cases - one where the 
> laptop's connectivity to the base station is intermittent, and the 
> other where a router was rebooted with the DHCP client plugged 
> directly into one of its ports.   This first case is common in 
> wireless deployments when, for example, we take our laptops from our 
> desks to a meeting.   The second case is common in home networking 
> cases, where the router and the hub are frequently the same device.   
> The same thing will also happen if a network state transition occurs 
> or the DHCP client is power-cycled while the DHCP server is not 
> working.
>
> I'm sorry to have to make a point of this now - I'd thought that I'd 
> explained the problems with LL23 sufficiently, but the brevity of the 
> debate meant that the full implications of this only became clear at 
> the last minute, after I'd already argued against LL23 for a variety 
> of other reasons.   Unfortunately I wasn't able to get across to you 
> how serious this problem was before the discussion closed.
>
> I'm not sure how to fix this.   One solution would be to make a 
> specific modification to the draft to specify different behavior in 
> the case where the global address is being managed by DHCP.   Another 
> way would be to advance a separate draft explaining how DHCP clients 
> and IPv4ll agents should interact.   I do not think it is acceptable 
> for this draft to advance without some strategy for dealing with this 
> problem - as has been stated many times by people far more vociferous 
> than me, IPv4ll should not  seriously break existing IP functionality.
>

---

From: Mika Liljeberg <[email-masked]>
Date: 06 Mar 2003 16:14:55 +0200

Ted,

I agree that reviewing/updating RFC2131 is not within the scope of
zeroconf.

However, we can and we should study the problem in the case where a node
has a manually configured routable address. Solving that case would go a
long way towards solving the other problems as well.

	MikaL