DHCPv6 *still* broken for F17 alpha

[Petr Pisar]

On 2012-03-14, Dan Williams <dcbw at redhat.com> wrote:
> 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.
>
How does fd00::/16 differes from 10.0.0.0/8? Why getting site scope
address in IPv4 is Ok, while getting such address in IPv6 is considered
as failure?

Unfortunatelly companies expect deploying NAT66 (network multihoming
while missing access to BGP).

Also user may expect installation from local mirror or through proxy.

I think you are doing the installer to much smart resulting in crappy
behaviour in special cases.

If you want to check connectivy, let's ping official Fedora mirror.
Present the ping result to user as a hint, but do not prevent him from
proceding.

-- Petr