Comment 31 for bug 761558

Hi Mathieu,

> On dual-stack networks, which remains the norm rather than ipv6-only so
far,

The norm so far is without question IPv4-only, which outnumbers anything
including IPv6 by an enormous amount. According to Google, IPv4-only is the
case for about 99.5% of users world-wide (see
http://www.google.com/intl/en/ipv6/statistics/), and my own data for Norway
puts the number at about 99.75% (see http://fud.no/ipv6).

> having IPv4 optional will mean the connection may still be brought up
with just IPv6.

Of course. However, with IPv4 required in the exact same situation, the
connection will not be brought up *at all*. That is certainly worse than
having to make do with only IPv6. Using IPv6, you'll at least be able to go
to Google and try to figure out how to troubleshoot the problem.

That said, having just IPv6 on a network is also a completely valid
configuration, and when combined with technologies such as NAT64, it does
not mean that you lose access to all the IPv4-only content and services on
the internet either. I would like to look into converting our corporate
WLANs to such a configuration, actually; we are running low on IPv4
addresses, and the IPv4 addresses that are currently used on the WLAN would
be much better spent in one of our data centres. However, since we have the
"Bring Your Own Device" philosophy where people manage their own laptops
(and Ubuntu is very popular OS choice), decommisioning IPv4 is out of the
question until this actually works out of the box with IPv6 only for most
people.

> Then people will wonder what is going on and file bugs here.

Well, considering that http://bugs.launchpad.net is only available over
IPv4, that is a technical impossibility. ;-)

Seriously though, I believe that worry about misdirected bug reports is
entirely unfounded. For the sake of the argument, the potential confused
bug reporters need to match all of these criteria:

1) Have a dual-stacked networks - 0,5% of users world-wide [Google].
2) Have a failure on their network that manifests itself in such a way
that DHCPv4 doesn't work while SLAAC/DHCPv6 does to work. Let's say that is
the case for 1% of networks.
3) Must mis-diagnose the problem and assign the blame to NetworkManager.
Let's say 10% of users?
4) Must actually bother to submit a bug report. 25%?

Result of the above: 0.000125% of all users...of course, that's very
hypothetical, but I'm convinced that the real number is indeed a tiny
fraction of a percent.

Again it's worth noting that Microsoft Windows, Apple Mac OS X, and Apple
iOS (which I forgot to mention in my previous message), *all* consider IPv4
optional. I believe it's relatively safe to assume that the Microsoft and
Apple users are, on average, less technical than Ubuntu users, and would
therefore be even more likely to misdiagnose the
"IPv6-is-working-while-IPv4-doesn't" problem and wrongly assign the blame
to the operating system. Yet, neither Microsoft nor Apple appear to have
any second thoughts about their IPv4-is-optional default behaviour. The
bottom line is: if Microsoft and Apple can make IPv4 optional, then Ubuntu
should not be worried about doing so either.

However, if I've failed to convince you yet that this simply isn't going
to be a problem, and you are still worried about being flooded with
misdirected bug reports as a result of making IPv4 optional, I am quite
willing to join the Ubuntu Bug Squad in order to triage all such bugs filed
on NetworkManager. That way you can be absolutely certain that you won't
have to deal with any of those false bug reports you're worried about.

BTW: I'm willing to bet that you've received way more messages from me in
this very bug report than you'll ever get from these confused users... ;-)

> We'll revisit setting IPv4 to optional after the Precise release.

I've seen you say pretty much exactly that before... :-(

«We're already planning on changing these defaults for Oneiric. However,
they won't be changed for Natty because it's already quite late in the
cycle to do so»

From
https://bugs.launchpad.net/ubuntu/+source/network-manager-applet/+bug/761558/comments/2

Best regards,
--
Tore Anderson