Re: IPv6 default routes / NM vs. kernel autoconfig

[Stuart Gathman <stuart gathman org>]

Long ago, Nostradamus foresaw that on 07/31/2012 07:26 AM, Tore Anderson
would write:
> * Stuart D Gathman
>
>> While it doesn't actually break, I have a related issue with DHCP6. When
>> RA enables DHCP6 (and NM set to "Automatic"), I end up with *both* the
>> RA and DHCP addresses.   And it keeps accumulating more IPs over time! 
>>
> Actually, this looks completely normal (except for the "prefixlen 64"
> for the DHCPv6-assigned address, something which was recently fixed in
> NM). The 2001:db8:dead:beef:20c:f1ff:fed9:97b4 one is the permanent
> EUI-64-derived address obtained through SLAAC, and the others are
> privacy addresses. Your OS will probably generate a new one every 24
> hours. However, the old ones will remain valid for quite some time
> before they are removed, so it is normal to see them accumulate up until
> a certain point. You should look for a tool which tells you the
> remaining valid lifetime for each individual address. On Linux, this
> would be "ip -6 address list", but I guess you're running something else.
The problem is, I don't want the auto IP, *or* the private IPs.  I just
want the DHCP6 IP.  But when I select "DHCP only" in NM, it then assigns
only the DHCP IP, but no route!   The behaviour I expect with DHCP only
is to still assign the route from RA.  But perhaps the routes cannot be
separated from the IPs in the kernel?  I don't see why not, since the RA
routes are *link* scope IPs, and don't depend on what global scope IPs
are assigned.  I.e., shouldn't setting accept_ra = 0 and
accept_ra_defrtr =1 work?

Here are my default routes:

default via fe80::21a:a0ff:fe3a:a6ff dev wlan0  proto static  metric 1
default via fe80::21a:a0ff:fe3a:a6ff dev wlan0  proto kernel  metric
1024  expires 1781sec

The static one is created by NM - and seems to be what the OP is
complaining about, as it takes priority over the automatic route, which
breaks things when the router changes (although nothing a
disconnect-connect won't fix).  In either case, they don't depend on any
global IP.