Re: Dealing with ICMPv6 network unreachable.

[Alan Barrett <apb%cequrux.com@localhost>]

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.
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.
--apb (Alan Barrett)