DHCPv6 *still* broken for F17 alpha

[Dan Williams]

On Fri, 2012-03-02 at 14:52 +0100, Tore Anderson wrote:
> * Dan Williams
> 
> > 0.9.4 snapshots do not require both methods to complete (with either
> > success or failure) before saying the machine is connected.  Thus if
> > IPv4 completes first, NM will say it's connected, and continue IPv6 in
> > the background.  And vice versa.
> 
> That is true, however, if IPv6 completes first, and IPv4 (still running
> in the background) eventually ends up failing, the *entire connection*
> will be torn down - including the perfectly working IPv6 connectivity.
> So the successfully connected state only lasts for about 20 seconds.
> 
> A trivial patch that fixes this problem is attached, please apply.

I've gone back and forth on this last week; since it changes the
default, it would break the case where somebody depends on the current
behavior, ie that by default IPv4 may not fail.  After this patch is
applied, a network where IPv6 connectivity is available but broken (or
where the router sends RAs with private prefixes like fdxx::) and IPv4
is for some reason also broken, will make NM show "connected" when in
fact we aren't really.  The new connectivity detection will help that
somewhat, but we haven't enabled it by default yet for a few reasons.

I ran into a network when testing this that caused me to think harder
about this patch.  It's an Actiontec router attached to Comcast (I
think) but has no upstream IPv6 connectivity.  It sends RAs for the
fdxx:: address space and NM dutifully picks that up.  So now we've got
IPv6 connectivity to a "private" prefix that's not routable.  If, in
this case, the router's DHCP server died, which sometimes happens on
crappy consumer hardware, an upgraded NM would report connected while
old NMs would fail the connection.

Whether we care enough about this regression (if you want to call it
that) versus enabling default IPv6 connectivity I don't know, I tend to
think we suck up the regression.  But I'm still interested in the
failure cases.

Next up, since AFAIK fdxx:: is a non-routable private network (like 10/8
right?) should NM say that we're only connected to a site-local network
here?  That would at least help the situation above, and indicate that
something went wrong instead of NM saying we're connected to the
internet and nothing working.

Dan