Re: Dealing with ICMPv6 network unreachable.

[Roy Marples <roy%marples.name@localhost>]

On Sun, 2015-04-05 at 16:47 +0200, Alan Barrett wrote:
> On Fri, 03 Apr 2015, Roy Marples wrote:
> > On Fri, 2015-04-03 at 11:20 -0400, Mouse wrote:
> >>> There is no guarantee the same network will be plugged back 
> >>> in.
> >>
> >> True.  But the time to deal with that is when you discover 
> >> another network was plugged in, not when the original network 
> >> is unplugged.
> 
> I strongly agree with Mouse.  A cable being unplugged should be 
> treated as a temporary condition, until such time as you have 
> better information, such as "it's been unplugged for a long time 
> now", or "it's plugged in again, but looks like a different 
> network".
> 
> > So lets say that we are plugged back into a new network, but it 
> > shares the same subnet and your existing IP address conflicts 
> > with a server on the network.
> 
> Two different networks that use the same address range?  Like two 
> distinct instances of 192.168.1.0/24?
> 
> Yes, that can happen, but dealing with should be done in a 
> way that does not punish people who simply remove a cable and 
> re-attach it seconds later, or power cycle a switch or access 
> point to have it come back up a minute or two later.
> 
> > However, I would rather be notified right away that something 
> > was awry with the connection rather than waiting for a long 
> > timeout on switching networks.
> 
> People who connect to multiple disjoint networks that happen to 
> share the same IP address range are unusual, and should have the 
> lowest priority in considering tradeoffs where making things work 
> better for one class of user causes trouble for another class of 
> user.
> 
> Here are a few scenarios:
> 
> 1. Disconnected and re-connected to the same network after a short 
> delay: Don't remove addresses on disconnect, but perhaps mark 
> them as deprecated, or not to be used for initiating new outbound 
> comnnections; On re-connect, verify that we appear to be on the 
> same network, and mark addresses as fully usable again.

IPv4 would need to grow IN_IFF_DETATCHED, IN_IFF_TENTATIVE and
IN_IFF_DUPLICATED and work in the same way as the IPv6 counterparts.

> 2. Disconnected and re-connected to the same network after a long 
> delay: Perhaps the addresses can be removed after a timeout, and 
> then re-connection can be handled like the very first connection 
> after reboot.  (The timeout could be a configuration option, and 
> I'd suggest between 5 and 15 minutes: long enough to reboot a 
> router or switch, but short enough that the user is unlikely to 
> be able to travel to a different site and plug in to a different 
> network that happens to share so many qualities that dhcpcd is 
> unable to distinguish the two, as in case 5 below.)
> 
> 3. Disconnected and re-connected to a different network after a 
> short delay: On re-connect, notice that the network is different, 
> remove the old addresses, and add new addresses.
> 
> 4. Disconnected and re-connected to a different network after 
> a long delay: Same as case 3, or perhaps the old addresses had 
> already been removed as for case 2.
> 
> 5. Disconnected and then re-connected to a network that is really 
> different, but that is somehow mis-identified as being the same: 
> The user loses, unless the old addresses had been removed after a 
> timeout as in case 2.  The user can manually initiate some sort 
> of "repair" process, which removes old addresses and requests new 
> addresses.
> 
> If you can do something to make the user in case 5 happier, while 
> not making the user in case 1 sadder, then please do so.  If you 
> can improve the mechanism for distinguishing between "the same" 
> and "different" networks, then please do so.  But I think that 
> being nice to the user in case 1 is much more important than being 
> nice to the user in case 5.

No need for any of the above if the kernel can grow IPv6 like address
static semantics for IPv4. The natural DHCP/DHCPv6 process will take
care of the rest.

Please understand that dhcpcd works the way it does because no kernel
bothers to re-check existing addresses on the network on carrier up.
It has to be the kernel that does this, because dhcpcd cannot stop the
kernel from announcing "I own this address" and causing the potential
DoS I described earlier. It was only recently I patched the NetBSD
kernel to do this for IPv6, but will be quite a bigger for for IPv4.
If you're happy with the above idea then we can move forward with
changing dhcpcd to persist the address on carrier down. But this will be
for NetBSD only.

Roy