On 2018 Jul 22 (Sun) at 18:19:01 +0200 (+0200), Florian Obser wrote:
:When one is connected to a network, suspends or hibernates, moves to a
:different network and wakes up one ends up with ip addresses from both
:networks and things probably go sideways. There is a good chance that
:source address selection picks the wrong IP.
:
:One common suggestion is that slaacd should just delete old addresses
:when it sees a new prefix announced. I'm afraid that's too simplistic.
:I'm aware of networks where two routers announce two different
:prefixes. We would flip flop between them.
:
:claudio@ recently suggested to delete addresses on link state change.
:I'm kinda worried that there might be still scenarios where we would
:flip flop between prefixes.
:
:So I hit the literature, but I couldn't find anything in the RFCs or
:in drafts on how to handle this. The stance in the RFCs is, if pltime
:> 0 the address is good, that's it.
:
:I was toying with the idea to solve this in the kernel, namely in the
:address selection algorithm and found this in RFC 6724:
:
: 2. Added Rule 5.5 to allow choosing a source address from a prefix
: advertised by the chosen next-hop for a given destination. This
: allows better connectivity in the presence of BCP 38 [RFC2827]
: ingress filtering and egress filtering. Previously, RFC 3484 had
: issues with multiple egress networks reached via the same
: interface, as discussed in [RFC5220].
:
:But that seems difficult to implement. We don't track the router for
:the prefix in the kernel.
:
:I note that my jesus laptop deletes old addresses. But I have no idea
:what heuristic they employ.
:
:So, how about we steer the address selection away from old addresses
:on link state change?
:
:If the link goes down deprecate all addresses by setting the pltime to
:0. The addresses are still valid, but will not be used for new connections.
:
:When the link comes back up we send a solicitation. If we are in a new
:network we get new addresses, the old addresses are deprecated and
:will no longer be used. Upper layers should take care of terminating
:existing connections with the old addresses.
:
:Thoughts? Tests? OKs?
:
:p.s. if someone knows of some documentation (RFC, draft, some writing
:what other implementations do) I'd be very interested.
:
I've done a little bit of testing of this. So far, it does what it says
on the tin, changes addresses to deprecated and sets the pltime to 0.
When link comes back, and it's the same prefix, our expected soii address
is re-established.
OK
Noticed while testing, but can be a different diff:
However, at home I do not have any IPv6. So while the IPv6 default route
is installed, my laptop will still try to use the deprecated addresses.
I think it would be best if we treated the default router the same way
as we treat the autoconf addresses, so change the lifetime to 0. When
the link comes back, a default router can be learned and installed.
--
A general leading the State Department resembles a dragon commanding
ducks.
-- New York Times, Jan. 20, 1981
