Re: [PATCH] Don't allow Managed DHCPv6 to short-circuit SLAAC

[Tore Anderson <tore fud no>]

Hi Dan,

* Dan Williams

> On Sat, 2011-08-20 at 13:03 +0200, Tore Anderson wrote:
>> I think NM needs to differentiate between the case when the RA is
>> indicating SLAAC should be used (i.e. when it contains a Prefix
>> Information with Autonomous=1), and when it doesn't. IPv6 addrconf (the
>> stateless kind) should only be done (and waited for) in the former case.
>> (Completely independent of DHCPv6 being used or not.)
> 
> Ok, so if it doesn't include A=1 then we just wait longer for one that
> does, or...?

I'd say no.

As I understand it, NM is currently operating on the following assumptions:

1) If we've seen an RA, we're supposed to do SLAAC.
2) If the RA has M=1, scratch assumption #1 - don't do SLAAC after all.
3) If the RA has M=1, do stateful DHCPv6.

In my opinion, #1 and #2 are incorrect.

Most of the information in an RA is entirely optional. In it's most
basic (and meaningless) form, a RA can essentialy say «hi, I'm a router,
but don't use me as a router». This would be the case if the RA included
no options and had the RA lifetime set to 0.

Ideally NetworkManager would not read more into the «got-ra» state than
that. That we got an RA is fine and all, but it does automatically imply
that we have access to any useful configuration information. It means we
can start looking for all sorts of optional information, though. Some
obvious things to look for and do include:

* If the RA lifetime is greater than 0, a default route should be added
  (using the router's link-local address as the next-hop).
* One or more Prefix Information Options:
  - If A=1, expect SLAAC to be performed for the prefix.
  - If L=1, a direct interface route to the prefix should be added
* If M=1, do stateful DHCPv6.
* If M=0, look for O=1. If present, do stateless DHCPv6.
  (If M=1, simply do stateful DHCPv6 and ignore the O flag.)
* One or more RDNSS Options. If present, add servers to /etc/resolv.conf
* One or more Route Information Options. If present, add routes.
* The MTU Option, if present, adjust MTU accordingly.
* And so on for any other options that might be present and that are
  supported by NM.

Question is, what is minimum configuration necessary in order for the
IPv6 connection activation to be considered a success by NM? You could
say that if you receive an RA that only has options for, say, RDNSS and
MTU, it is a «success» if we act upon those options and configure the
host accordingly. After all, we successfully did all the network
administrator asked us to do...

However, such «connectivity» isn't likely to be very useful to the end
user, so the minimum config necessary might be defined as having learned
a non-link-local address, perhaps? If so, I'd say that if we receive an
RA with M=0 and no A=1 PIO, then we instantly fail the connection
attempt. The network administrator has in this case clearly indicated
that there is no automatic addressing config to be had, so that's the
end of it - don't leave the systray icon spinning or anything like that.

However, NM should still listen in the background and react if an RA is
received at a later stage containing addressing information. I believe
this is somewhat buggy at the moment, at least when I first activated a
device using SLAAC only (M=0), and later changed the router config so
that subsequent RAs contained M=1, NM did *not* start DHCPv6 - I needed
to restart the device completely in order for it to pick up the
DHCPv6-provided address.

The M=1, A=1 bug I'm experiencing is also uncovering another weakness in
NM's current model by the way - IPv6 failures affects IPv4 connectivity
(and perhaps vice verca). When IPv6 fails after the device has completed
activation, for example because the lifetime of a SLAAC-learned address
expires, then the *entire connection* is brought down, not only the IPv6
address family. That would only make sense if the «Require IPv6» setting
was enabled, which it was not.

>> I was thinking that a possible quick fix would be to set the device's
>> target state to got-ra if the RA received didn't contain any PIOs with
>> A=1 (since the got-address state seems to mean «SLAAC completed»), but
>> I'm stuck at figuring out how to determine if that is the case. From
>> what I can tell, the RA flags looks identical in both cases. Any
>> suggestions?
> 
> got-ra means we got the RA from the link, while got-address means that
> we've checked and ensured that the kernel has added the right address to
> the network interface.  After we get the RA, we have to wait for the
> kernel to send the netlink notification of address addition on the
> interface, and then make sure we've got the right address there, before
> we can proceed.

Okay. Finishing DHCPv6 does not set the device state to got-address,
does it? I don't think it does, at least, but that appears a bit
counter-intuitive to me.

> I think here you want struct prefixmsg * -> flags and look for
> IF_PREFIX_AUTOCONF, though I could be wrong.  See addrconf_prefix_rcv()
> in net/ipv6/autoconf.c where I think that flag gets stuffed into struct
> prefixmsg directly from the prefix option in the RA.

I'll do my best, but I fear that my programming skills might be too
limited to be able to come up with something good. I'm primarily a
networking guy, not a programmer. :-|

In any case, enjoy your holiday! ;-)

Best regards,
-- 
Tore Anderson