Who/What is supposed to remove IPv6 address from interface when moving from one network to another ?

Who/What is supposed to remove IPv6 address from interface when moving from one network to another ?

[Sylvain Munaut]

Hi,


In a nutshell, I'm experiencing the same behavior as described here
http://kerneltrap.org/mailarchive/linux-netdev/2010/10/26/6288280 ...
but 2.5 years later ...

When switching network, my interface doesn't necessarily goes down and
so IPv6 prefixes from my old location are kept, causing issues.

I read the thread above, but it just seem to "stop" without really a
solution ...

So what's the proper thing to do ?  How is it supposed to work ?
I searched for a while and except for the thread above, I couldn't
find any reference on whose responsibility it is to cleanup. Given the
kernel added the address itself, I'd tend to agree with the original
poster and that the kernel should handle the cleanup.


Cheers,

     Sylvain

Re: Who/What is supposed to remove IPv6 address from interface when moving from one network to another ?

[Dan Williams]

On Thu, 2013-03-14 at 20:33 +0100, Sylvain Munaut wrote:
> Hi,
> 
> 
> In a nutshell, I'm experiencing the same behavior as described here
> http://kerneltrap.org/mailarchive/linux-netdev/2010/10/26/6288280 ...
> but 2.5 years later ...
> 
> When switching network, my interface doesn't necessarily goes down and
> so IPv6 prefixes from my old location are kept, causing issues.
> 
> I read the thread above, but it just seem to "stop" without really a
> solution ...
> 
> So what's the proper thing to do ?  How is it supposed to work ?
> I searched for a while and except for the thread above, I couldn't
> find any reference on whose responsibility it is to cleanup. Given the
> kernel added the address itself, I'd tend to agree with the original
> poster and that the kernel should handle the cleanup.

The old network prefix should have a lifetime, and when that lifetime
has expired, it should be deleted by the kernel.  However, that lifetime
is specified by the IPv6 router on your network, and may be very large.
Thus when you switch networks, if the lifetime of the old prefix has not
expired, the address is not deleted.

A daemon like NetworkManager usually handles this sort of thing for you
by watching for link/carrier events and retriggering the IP
configuration process when you connect to the new network.  The kernel
does not (and shouldn't) trigger anything on carrier change as that's a
site-specific/user-specific policy.

(if you want to trigger it manually, you should be able to run 'ifconfig
eth0 down' and then 'ifconfig eth0 up' when you have connected to the
new network, which clears out the old addresses and then lets the kernel
listen for new router advertisements from the new network).

Dan

Re: Who/What is supposed to remove IPv6 address from interface when moving from one network to another ?

[Lorenzo Colitti]

On Thu, Mar 14, 2013 at 12:48 PM, Dan Williams <dcbw@redhat.com> wrote:
> The kernel does not (and shouldn't) trigger anything on carrier change as that's a
> site-specific/user-specific policy.

Actually, it *does* trigger events on carrier change: it creates the
addresses when you connect. It just doesn't delete them when you
disconnect. So you can get addresses without a userspace daemon, but
you can never delete them without a userspace daemon.

I tried to argue that that's incorrect, but, well, the archives show
how far I got.

Re: Who/What is supposed to remove IPv6 address from interface when moving from one network to another ?

[Dan Williams]

On Mon, 2013-03-18 at 09:51 -0700, Lorenzo Colitti wrote:
> On Thu, Mar 14, 2013 at 12:48 PM, Dan Williams <dcbw@redhat.com> wrote:
> > The kernel does not (and shouldn't) trigger anything on carrier change as that's a
> > site-specific/user-specific policy.
> 
> Actually, it *does* trigger events on carrier change: it creates the
> addresses when you connect. It just doesn't delete them when you
> disconnect. So you can get addresses without a userspace daemon, but
> you can never delete them without a userspace daemon.
> 
> I tried to argue that that's incorrect, but, well, the archives show
> how far I got.

It does handle them when you connect, but only if you've set accept_ra
to something > 0.  And something has to set that :)  But in reality,
it's not a problem to listen for new addresses.  But *deleting*
addresses is way out of the kernel's responsibility, because a carrier
event doesn't tell the kernel anything about whether it's reconnecting
to the same network or a different one and thus it doesn't know whether
it should delete the old address or keep it around.  And that's where
the userspace stuff and policy comes in, and the kernel doesn't do
policy.

Dan

Re: Who/What is supposed to remove IPv6 address from interface when moving from one network to another ?

[Sylvain Munaut]

Hi,

This might be a dumb idea but, would it make sense for the kernel not
to use as source address, an address generated from a prefix for which
the route has expired ? Like, I get a ra for 2001:1234::/64 prefix
with 2001:1234::1 gateway.  If the gateway is lost, using
2001:1234::my_mac_address as source address with another gateway I got
from another RA with a different prefix is fairely unlikely to work
... (at least most access network I know filter that)


Cheers,

    Sylvain

Re: Who/What is supposed to remove IPv6 address from interface when moving from one network to another ?

[Lorenzo Colitti]

On Mon, Mar 18, 2013 at 11:11 AM, Sylvain Munaut
<s.munaut@whatever-company.com> wrote:
> This might be a dumb idea but, would it make sense for the kernel not
> to use as source address, an address generated from a prefix for which
> the route has expired ?

The route doesn't expire either. (And neither does the default gateway).

Re: Who/What is supposed to remove IPv6 address from interface when moving from one network to another ?

[Sylvain Munaut]

Hi,

>> This might be a dumb idea but, would it make sense for the kernel not
>> to use as source address, an address generated from a prefix for which
>> the route has expired ?
>
> The route doesn't expire either. (And neither does the default gateway).

Ah sorry.

In my case the router lifetime is much shorter ( a few minutes ) and
expired by the time I get home, which is why I was only faced with the
"using bad source address" issue.

In anycase, following Dan's reponse, I just flush all ipv6 on suspend
now ... (NetworkManager was a bit heavy-weight to just sort that
particular issue ...)


Cheers,

   Sylvain

Re: Who/What is supposed to remove IPv6 address from interface when moving from one network to another ?

[Hannes Frederic Sowa]

On Mon, Mar 18, 2013 at 09:51:55AM -0700, Lorenzo Colitti wrote:
> On Thu, Mar 14, 2013 at 12:48 PM, Dan Williams <dcbw@redhat.com> wrote:
> > The kernel does not (and shouldn't) trigger anything on carrier change as that's a
> > site-specific/user-specific policy.
> 
> Actually, it *does* trigger events on carrier change: it creates the
> addresses when you connect. It just doesn't delete them when you
> disconnect. So you can get addresses without a userspace daemon, but
> you can never delete them without a userspace daemon.

Not directly related, but I wonder if we should treat the change of the
mac address as a carrier change in ipv6 to create a new ll address. I
did not find any satisfying answer yet.

Re: Who/What is supposed to remove IPv6 address from interface when moving from one network to another ?

[Lorenzo Colitti]

On Mon, Mar 18, 2013 at 11:34 AM, Hannes Frederic Sowa
<hannes@stressinduktion.org> wrote:
>> Actually, it *does* trigger events on carrier change: it creates the
>> addresses when you connect. It just doesn't delete them when you
>> disconnect. So you can get addresses without a userspace daemon, but
>> you can never delete them without a userspace daemon.
>
> Not directly related, but I wonder if we should treat the change of the
> mac address as a carrier change in ipv6 to create a new ll address. I
> did not find any satisfying answer yet.

Yes, we should - because if we're attaching to a new link, there might
be someone with a duplicate IPv6 address on it, so we'd need to
perform DAD.

I think the kernel does do this though. So in effect, every new link
you attach to gives you new IPv6 addresses, and never deletes them.
The old ones usually don't work on the new link, so you end up with
broken connectivity. Current solutions are either disable IPv6 or
start a userspace daemon to clean up the non-working addresses.

Re: Who/What is supposed to remove IPv6 address from interface when moving from one network to another ?

[Hannes Frederic Sowa]

On Mon, Mar 18, 2013 at 11:39:02AM -0700, Lorenzo Colitti wrote:
> On Mon, Mar 18, 2013 at 11:34 AM, Hannes Frederic Sowa
> <hannes@stressinduktion.org> wrote:
> >> Actually, it *does* trigger events on carrier change: it creates the
> >> addresses when you connect. It just doesn't delete them when you
> >> disconnect. So you can get addresses without a userspace daemon, but
> >> you can never delete them without a userspace daemon.
> >
> > Not directly related, but I wonder if we should treat the change of the
> > mac address as a carrier change in ipv6 to create a new ll address. I
> > did not find any satisfying answer yet.
> 
> Yes, we should - because if we're attaching to a new link, there might
> be someone with a duplicate IPv6 address on it, so we'd need to
> perform DAD.

I think there is a misunderstanding:

I was thinking just about the case where we change the mac address of
some interface without changing anything else (not changing link status):

# ip l a type dummy
# ip l s up dev dummy0
# ip l l dev dummy0
|	14: dummy0: <BROADCAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN mode DEFAULT 
|	    link/ether ca:eb:dd:14:ad:15 brd ff:ff:ff:ff:ff:ff
# ip -6 a l dev dummy0
|	14: dummy0: <BROADCAST,NOARP,UP,LOWER_UP> mtu 1500 
|	    inet6 fe80::c8eb:ddff:fe14:ad15/64 scope link 
|	       valid_lft forever preferred_lft forever
# ip l s a ca:eb:dd:14:ad:16 dev dummy0
# ip l l dev dummy0
|	14: dummy0: <BROADCAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN mode DEFAULT 
|	    link/ether ca:eb:dd:14:ad:16 brd ff:ff:ff:ff:ff:ff
# ip -6 a l dev dummy0
|	14: dummy0: <BROADCAST,NOARP,UP,LOWER_UP> mtu 1500 
|	    inet6 fe80::c8eb:ddff:fe14:ad15/64 scope link 
|	       valid_lft forever preferred_lft forever

Currently we don't generate any new ll address. I wondered if this is
correct.  This e.g. happens if creating bridges with libvirt. It could
also be just a acceptable circumstance, I currently don't know. If people
depend on the mapping from mac address to ipv6 ll address perhaps this
is something that should be addressed.

Re: Who/What is supposed to remove IPv6 address from interface when moving from one network to another ?

[Dan Williams]

On Mon, 2013-03-18 at 19:28 +0100, Sylvain Munaut wrote:
> Hi,
> 
> >> This might be a dumb idea but, would it make sense for the kernel not
> >> to use as source address, an address generated from a prefix for which
> >> the route has expired ?
> >
> > The route doesn't expire either. (And neither does the default gateway).
> 
> Ah sorry.
> 
> In my case the router lifetime is much shorter ( a few minutes ) and
> expired by the time I get home, which is why I was only faced with the
> "using bad source address" issue.
> 
> In anycase, following Dan's reponse, I just flush all ipv6 on suspend
> now ... (NetworkManager was a bit heavy-weight to just sort that
> particular issue ...)

While I'm not an IPv6 expert I would actually expect the kernel to stop
using any IPv6 address or route that had expired, and that was *added
automatically* by the kernel as a result of a router advertisement.
Perhaps that's not how it actually works, but would be nice to hear from
some kernel IPv6 people why that's not how it works, if that's the case.

Dan

Re: Who/What is supposed to remove IPv6 address from interface when moving from one network to another ?

[Mikael Abrahamsson]

On Mon, 18 Mar 2013, Dan Williams wrote:

> While I'm not an IPv6 expert I would actually expect the kernel to stop 
> using any IPv6 address or route that had expired, and that was *added 
> automatically* by the kernel as a result of a router advertisement. 
> Perhaps that's not how it actually works, but would be nice to hear from 
> some kernel IPv6 people why that's not how it works, if that's the case.

It's my experience that the kernel doesn't detect link-down events and do 
anything useful with that information. When I have asked about this, I get 
server-usage scenarios and people don't want the kernel to do anything.

In older Ubuntu, when moving between wifis with different IPv6 subnets on 
them, you after a while were sitting there with IPv6 addresses from 
several different subnets, of which just one worked. Fail. I believe 
enhancements in the connection manager fixed this, because from 12.04 or 
something, this is not a problem anymore. When eth0 or wlan0 goes down, so 
IPv6 addresses and default routes go away just like the IPv4 equivalents.

Before the IPv4 equivalents went away on link-down but IPv6 was on 
autopilot by kernel seeing RAs and they stayed there long after they 
overspent their welcome.

So, my opinion is that the connection manager needs to take care of this, 
because the kernel doesn't do it (intentionally, by design).

I'm sure the kernel will stop using addresses after they expire, but that 
doesn't happen when a link goes down.

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se