Re: IPv6 default routes / NM vs. kernel autoconfig

[Dan Williams <dcbw redhat com>]

On Tue, 2012-07-24 at 09:38 -0400, Ross Vandegrift wrote:
> On Mon, 2012-07-23 at 20:12 -0400, Pavel Simerda wrote:
> > > ::/0              fe80::21b:2bff:fec1:dcc1   UG   1   0     0 em1
> > > ::/0              fe80::217:e0ff:fe43:5941   UGDAe 1024 0     0 em1
> > > ::/0              fe80::21b:2bff:fec1:dcc2   UGDAe 1024 0     0 em1
> > > 
> > > Note that the lower-metric route is for the IPv6 host ending in dcc1,
> > > but the two higher-metric routes, which I assume come from the kernel
> > > autoconf, are different hosts - dcc1 and 5941.
> > 
> > The lower-metric route should be from NetworkManager and it should reflect
> > the default route for the device that is used for connectivity. In your
> > case it seems to be nonsense.
> 
> Why does NM do this?  Iv6 autoconf is a dynamic routing protocol that
> chooses the best available default on the network.  *Any* static
> default breaks this mechanism, and should only be used to workaround a
> broken network configuration.
> 
> Though a router did a somewhat surprising thing (coming up with a
> different link-local address), the network here is working perfectly
> well.

It depends.

If there are multiple active interfaces, say perhaps a WiFi connection
and a 3G connection, which one is "better"?  That's a somewhat contrived
example, but not every network is actually under your control, and in
those cases NM needs to make a decision about which network is "better"
or even which network is upstream.

If the user checks the "never default" option in the configuration UI,
then NM should prevent that network from ever getting the default route.

The network is usually right, because it's supposed to be set up in an
intelligent and helpful manner, but that's not always the case, and user
overrides should also be respected.

NM *should* remove any routes it added if the most recent RA for that
router has a lifetime of 0.  That's a bug in NM, and something we should
fix.

> > > We took a look at the router, and found that, before reboot, it had
> > > been
> > > using blahblah:dcc1 as the link-local, but after reboot it started
> > > using
> > > blahblah:dcc2.
> > 
> > Currently, NetworkManager doesn't cope well with changes like this and
> > unfortunately this applies to the Git version of NM as well. I hope
> > to improve this at some point of time but even the kernel is not very
> > helpful here.
> 
> Note that IPv6 autoconf would've handled this absolutely gracefully, if
> NM had not interfered - the box would've expired the default, and the
> other RA would become active. The right thing to do here is to let the
> protocol work as designed.

Right, we should ensure that NM respects the lifetime of the RA.

> > > My main question: What should happen in this situation? Is this a bug
> > > in NM?
> > 
> > NM is working around lack of information from kernel and it works only in
> > basic situations. There are solutions to this.
> 
> NM only lacks information if you require that NM track the state of the
> network stack.  This might be required for DHCP interfaces, since NM
> needs to manage the DHCP agent.  But what is the use-case for autoconf?

Autoconf can imply dhclient usage when the network sets the M or O
flags.  But that's largely irrelevant for the default route.  Here, its
more about respecting user overrides and mediating between two different
network's requests that may conflict.  We're not completely there yet,
and we're always trying to improve that.

> If someone desires different behavior, then the right thing to do is
> disable autoconf and use a different interface configuration method
> (DHCP, static config, etc).

Not necessarily.  Addressing and routing are really two different
things, and can be controlled independently.  Disabling autoconf
disables *both* of those, where perhaps you simply wanted to modify the
routing, but still retain the prefix given to you by the router.  Just
because the network sets something doesn't mean it's *always* right, but
that (a) we should default to what the network says unless we determine
that it's broken, which happens a lot more than you might think, and (b)
we should allow the user to override certain pieces of that information
if they determine that it's necessary to achieve their goals.

Dan