Re: IPv4 Address Flags

[Dennis Ferguson <dennis.c.ferguson%gmail.com@localhost>]

On 19 May, 2015, at 12:27 , David Laight <david%l8s.co.uk@localhost> wrote:
> On Tue, Apr 21, 2015 at 05:48:46PM -0700, Dennis Ferguson wrote:
>> 
>> On 21 Apr, 2015, at 01:46 , Roy Marples <roy%marples.name@localhost> wrote:
>>> As discussed here [1], a few people voiced their opinion that they
>>> didn't like address removal when the carrier drops and would rather
>>> re-negotiate at carrier up. The first step of doing this is to add IPv6
>>> address flag semantics to IPv4 addresses.
> 
> Dropping ip addresses and connections on 'carrier down' seems pointless
> to me.
> You can't detect the cable being unplugged 'one switch back', so
> why do you care about the local cable being unplugged.
> All it does is give people an incorrect view of how fast TCP will
> detect neteork outages.

Dropping connections when IP addresses go away seems pointless to me.
If they are allowed to persist they will either go away on their own
eventually, like they would if the cable one switch away was unplugged,
or they can pick up where they left off if the addresses come back.  If it
works this way then there's not a lot of reason to care whether the
addresses go away temporarily or not and the things that manage your
interface configuration can do what is convenient for them.

>> To tell the truth I think this is fixing the problem in the wrong
>> spot.  I don't see a big difference between unplugging the ethernet
>> cable and plugging it back in, and unplugging the USB or Thunderbolt
>> ethernet dongle and plugging it back in, or hot-swapping the ethernet
>> line card out and replacing it with another.  If I have active protocol
>> connections I would like them to survive the interface itself going
>> away and coming back just as much as I would like them to survive
>> the special case of the carrier dropping and coming back.  Adding
>> complexity to deal only with the latter doesn't seem worth it.
> ...
> 
> On linux we've had to use a 'bond' of one interface in order to stop
> USB interface interface disappearing due to electrical transients.

That's the problem with tying connection persistence to interface
configuration: you have to invent a new workaround for every kind of
event that might make the configuration go away temporarily, and it
will probably break if the change is actually permanent.

It is the case that the asymmetry you are pointing out, that different
things happen when local kernel notices a problem than when something
a few hops away notices the same problem, has always bothered me.  Does
it make sense to report an error when the output queue on the local box
is full, but nothing when it is the output queue on the next hop router
that is full?  Or to respond immediately when the local kernel tells you
a destination is unreachable, but to ignore it entirely when the next hop
router tells you the same thing?

Dennis Ferguson