Default to enabling IPv6 addresses, but set to optional to bring up devices

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 -- regardless, it's easy for those who know what they are doing to change these settings. IPv6 for most will not be very useful and taken care of by other equipment than the end system running NM.

Den 15. april 2011 15:44, skrev Mathieu Trudel-Lapierre:

> 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

Okay, that's disappointing to learn.

> it's easy for those who know what they are doing to change these
> settings.

Clearly. However, the problem is primarily for people that *don't* know
what they're doing. The non-technical John Q. Public types that just
want stuff to work, and are attempting to connect their computer to a
network that is only able to offer IPv6 service.

> IPv6 for most will not be very useful and taken care of by other
> equipment than the end system running NM.

I don't understand what you mean by this. If Ubuntu cannot connect to an
IPv6 network, sure, that network is obviously "not very useful" to the
end user.

I fail to see which "other equipment" you're talking about, though?
Except if the end user has the possibility to reboot into Microsoft
Windows, or if he has sufficient technical skill to debug the problem
and change the correct advanced settings in the NM connection profile,
he will be left completely without a functioning network connection.
What "other equipment" will help out with this situation?

Best regards,
--
Tore Anderson

What I mean by this is that for most users, switching to IPv6 is a no-op: ISPs will switch, most likely provide v6 addresses from their systems to the CPE, but most local networks for customers will remain IPv4. AFAIK, there are still very few home routers sold with IPv6 support (with the notable exception of the DLink DIR615 at least that I know of).

I hardly think that if you don't know what you're doing, that you'd really be using IPv6 at this time, or need to use it on a local network.

Other equipment was really referring to CPE -- the router your ISP gives you, in other words.

I'm not saying this won't be fixed, just that there's already a way to use IPv6 for a connection even if it's not on by default. I do believe it's discoverable enough, being a separate tab from IPv4, which is always visible when you edit the connection's settings in nm-applet. Another thing to keep in mind is that systems supporting IPv6 (aka, those that didn't get it disabled by manual configuration modifications) should still build IPv6 addresses from router advertisements, since this is not disabled by NM and taken care of by the kernel.

We'll set IPv6 to Automatic by default early in the Oneiric cycle, along with making sure it doesn't block interfaces from coming up. I think this is sufficient to cater for most use cases; whereas changing defaults at this point in the cycle seems to me like risking to introduce issues related to having IPv6, to systems trying to resolve AAAA addresses when they can't (for instance, because their routers don't support it). I tested this relatively early in the cycle, and IIRC it worked just fine.

I understand the importance of exceptional IPv6 support, but I do expect it to be reasonable in its current state for the reasons stated above; which reduces the importance of changing NM's connection defaults at this time (especially considering freeze status and how close we are to release).

Anything I'm missing from the above analysis that would warrant changing this now? I'm open to having my mind changed if there's a compelling reason ;)

Mathieu,

I did not mean to insist on this becoming part of Natty. While that would have been a good thing, I can understand that the release cycle has progressed too far now.

However, I wanted to object to your argument which I interpreted as essentially: «it does not matter if IPv6 is supported out of the box now since only power users need it anyway». In my opinion, that's not the case - a newly established ISP in the Asia-Pacific region will find it extremely difficult to provide IPv4 service as the region simply does not have any more IPv4 addresses available for allocation, and carriers like T-Mobile USA have announced plans to deliver their mobile broadband services as IPv6-only.

Ubuntu, in its current form, would not support such networks, and that would mean that the ISPs in question would either need to simply declare Ubuntu as unsupported and tell people to use Windows instead or figure it out on their own, or they would need to permit Ubuntu's lack of IPv6 support to limit them in how they structure their network. None of these are a good thing, neither for the end user, for the ISPs, or for the internet community at large - which really needs to move towards IPv6 as soon as possible; IPv4 has already reached the end of the road in the Asia-Pacific and it is just a matter of months before Europe and North America will follow suit.

So please make it a priority for Oneiric - the internet community does absolutely not need more devices and implementations that cannot fully support IPv6 networks, as that just makes the whole ordeal of transitioning away from IPv4 even more difficult and painful than what it already is...

Oh, and by the way - I will be happy to help testing the change once you make it in Oneiric, just let me know when.

Best regards,
Tore

Closing as Fix Released, the default for NM 0.9 (which is now in Oneiric) is to enable IPv6 automatically, although it's optional to bring up interfaces.

I'm reopening this bug, as Oneiric Alpha 1 does not appear to be able to connect to IPv6 networks in its default out-of-the-box configuration. See attached (unedited) syslog for a log of the process.

The network in question is managed by an AVM FRITZ!Box 7390 DSL router, which uses SLAAC for IPv6 addressing and information-only DHCPv6 for DNS server signalling. In my test, SLAAC works (thanks to the kernel, which does that by default on its own), however an information-only DHCPv6 transaction is never started and therefore no DNS servers are being learned, leaving me with a rather useless network connection.

After the DHCPv4 transaction times out, NetworkManager also logs it was unable to activate the inferface, and leaves the system in a disconnected state (from NM's point of view). The kernel-assigned address (from SLAAC) remains, probably because I was using a wired interface. If I had tested with a WiFi interface, I think NM would have downed the interface completely after the activation failure, bringing down the IPv6 connectivity in the process.

The GUI of Oneiric A1 was unusable for me (not NM's, the entire X/GNOME UI was crashing) so I could not investigate further, but to me the behaviour observed seems to match that of IPv6 mode «ignore».

Tore

Assigning to Matt Trudel who's working on changing the default.

I just tested Oneiric alpha-2, and there has been no improvement. After booting the Live DVD, it ultimately fails to connect to the network (after repeated attempts), due to the lack of DHCPv4 responses from the network. This happens to be because the default «Wired connection 1» profile has 1) «Require IPv4 addressing for this connection to complete» checked under the IPv4 tab, and 2) the Method set to «Ignore» under the IPv6 tab.

After changing the IPv6 Method to «Automatic», and unchecking the «Require ... for this connection to complete» under both tabs, it successfully connected to the network (from NM's point of view) immediately after I saved the new settings. However, for some reason, it did not perform a DHCPv6 transaction and therefore did not learn any name servers. This might be a separate bug?

Afterwards I disabled and re-enabled networking without any further changes to the settings, and then it connected successfully while correctly performing DHCPv6. At this point I was completely connected to the network and was able to browse the web over IPv6 normally.

I'm attaching the syslog from the attempt. I inserted some markers in the log before 1) changing the network settings, and 2) finally disabling/re-enabling networking and getting properly online. (The markers are prepended with «tore».)

Tore

Dual-stack and single-stack connections are being tested extensively, but at this point the default is already (for an automatically created connection, that is) to have IPv6 at Automatic and optional. This doesn't apply to connections created by clicking the Add button in nm-connection-editor though; see http://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=36db194ae95e35cc7b8f431ab984780dea24656d and http://git.gnome.org/browse/network-manager-applet/commit/?id=7068b0f7052078f101ad1eccc3456492f03fbb8b. Those will get in with the next upload of NM and nm-applet (anytime now).

Syslog looks correct except for the crash you got, and since you confirmed that with the correct settings for the interface the connection comes up properly, I'm not overly concerned by any of this (though the crash still needs fixing).

One thing to keep in mind is that ipv4 will remain *required*, at least for 11.10; and most probably until after the next LTS (because let's face it, IPv6 isn't set up everywhere, and things need to work magically for users who don't have ipv6... and also should fail magically when users don't actually get any dhcp responses). I'll however be happy to be convinced that the automatic failing of v4 interfaces that don't complete DHCP is no necessary. (Though I believe it makes everyone's life easier).

On Thu, 21 Jul 2011 19:30:34 -0000, Mathieu Trudel-Lapierre
<email address hidden> wrote:
> Dual-stack and single-stack connections are being tested extensively,
> but at this point the default is already (for an automatically created
> connection, that is) to have IPv6 at Automatic and optional. This
> doesn't apply to connections created by clicking the Add button in nm-
> connection-editor though; see
>
http://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=36db194ae95e35cc7b8f431ab984780dea24656d
> and http://git.gnome.org/browse/network-manager-
> applet/commit/?id=7068b0f7052078f101ad1eccc3456492f03fbb8b. Those will
> get in with the next upload of NM and nm-applet (anytime now).
>
> Syslog looks correct except for the crash you got, and since you
> confirmed that with the correct settings for the interface the
> connection comes up properly, I'm not overly concerned by any of this
> (though the crash still needs fixing).

If you look closely at the log, you will see that NM does not do anything
at all about IPv6 until I manually change the settings at 15:37:19. Before
that point, the only thing related to IPv6 that is logged at all is from
avahi-daemon saying «Registering new address record for
2001:840:3033:10:230:1bff:febc:7f23 on eth0.*». That is the only thing that
disclose the fact that there is IPv6 service on the network in question.
NM, on the other hand, is ignoring IPv6 completely - in particular, the
«Activation (eth0) Beginning IP6 addrconf» log line never shows up before
the manual settings change.

The connection in question is *not* added manually with
nm-connection-editor, it was automatically created somehow. I don't know
how, precisely; all I did was to pop in the Live CD and boot - «Wired
Connection 1» was there when the system came up, I did not do anything to
create it, and its IPv6 mode was *NOT* «Automatic».

This all appears to run counter to your statement that IPv6 mode Automatic
should now be the default, and it is the reason why I call into question
that the corresponding work item in the desktop-side networking
enhancements blueprint is indeed 100% done.

> One thing to keep in mind is that ipv4 will remain *required*, at least
> for 11.10; and most probably until after the next LTS (because let's
> face it, IPv6 isn't set up everywhere, and things need to work magically
> for users who don't have ipv6... and also should fail magically when
> users don't actually get any dhcp responses). I'll however be happy to
> be convinced that the automatic failing of v4 interfaces that don't
> complete DHCP is no necessary. (Though I believe it makes everyone's
> life easier).

Wait, wait! I am absolutely *NOT* suggesting that things should not «work
magically for users who don't have ipv6»!

I merely suggest leaving the «require» box unchecked by default both for
IPv4 and for IPv6. NM will still require at least one method to succeed in
order for the overall connection to succeed. If the user don't have IPv6,
well, then the IPv6 method will obviously fail every time, in turn making
IPv4 success a necessity for the overall connection to succeed. So for the
IPv4-only users, there will be absolutely *no ...

On Fri, Jul 22, 2011 at 2:46 AM, Tore Anderson <email address hidden> wrote:
> If you look closely at the log, you will see that NM does not do anything
> at all about IPv6 until I manually change the settings at 15:37:19. Before
> that point, the only thing related to IPv6 that is logged at all is from
> avahi-daemon saying «Registering new address record for
> 2001:840:3033:10:230:1bff:febc:7f23 on eth0.*». That is the only thing that
> disclose the fact that there is IPv6 service on the network in question.
> NM, on the other hand, is ignoring IPv6 completely - in particular, the
> «Activation (eth0) Beginning IP6 addrconf» log line never shows up before
> the manual settings change.

My bad, I've just confirmed it is indeed the case: there is something
wrong in the LiveCD, and we'll definitely fix that. Connections should
definitely be set to IPv6 automatic (and optional) in both the LiveCD
and the subsequent install. I could have sworn things were fine in the
install; but the LiveCD case proves it is probably not the case and
needs some more work -- this bug will track that issue.

>> One thing to keep in mind is that ipv4 will remain *required*, at least
>> for 11.10; and most probably until after the next LTS (because let's
>> face it, IPv6 isn't set up everywhere, and things need to work magically
>> for users who don't have ipv6... and also should fail magically when
>> users don't actually get any dhcp responses). I'll however be happy to
>> be convinced that the automatic failing of v4 interfaces that don't
>> complete DHCP is no necessary. (Though I believe it makes everyone's
>> life easier).
>
> Wait, wait! I am absolutely *NOT* suggesting that things should not «work
> magically for users who don't have ipv6»!

That's not what I thought you meant, sorry if there was any confusion;
see below.

> I merely suggest leaving the «require» box unchecked by default both for
> IPv4 and for IPv6. NM will still require at least one method to succeed in
> order for the overall connection to succeed. If the user don't have IPv6,
[...]
> cannot see how leaving both «require» boxes unchecked will cause any
> problems for any user, regardless of whether his network is IPv4, IPv6, or
> dual-stack.

After re-reading this, I also got to the same conclusion (and also
with Stephane's careful analysis and testing); IPv4 could
theoretically be set to "optional" as well, *however*...

> On the other hand, leaving the «require IPv4» box checked will cause
> problems for IPv6 users that have no IPv4 service. While this is perhaps
> not too common today, several carriers have announced plans to deploy
> IPv6-only service (with NAT64/DNS64). I've already mentioned T-Mobile USA,
> and also Network Norway here in my home country and Mobiltel in Slovenia is
> doing the same. Verizon Wireless (USA) is mandating IPv6 support for
> devices on their LTE network, while leaving IPv4 support optional.
>
> I cannot predict exactly how common IPv6-only networks will be in the
> future, but in any case - IPv6-only networks already exist, and I cannot
> see what possible harm could be caused by having Ubuntu/NM support these
> out of the box by having the «require IPv4» box unt...

* Mathieu Trudel-Lapierre

> I've just confirmed it is indeed the case: there is something
> wrong in the LiveCD, and we'll definitely fix that.

Great! :-)

> After re-reading this, I also got to the same conclusion (and also
> with Stephane's careful analysis and testing); IPv4 could
> theoretically be set to "optional" as well, *however*...

Could and should. ;-)

> While I agree that IPv6 deployment is being planned in carriers (and
> ipv6-only also is), I believe majority still will remain, at least
> until Oneiric + 1, that dual-stack IPv4 and IPv6 would be what will
> get deployed if anything. Other networks with specific requirements
> can obviously set a different setting, it's not very far in the
> dialogs.

I don't disagree with this. It's rather unlikely that IPv6-only networks
will outnumber IPv4-only and dual-stacked networks in the forseeable
future.

But, as long as it doesn't cost you anything (in terms of losing any
support for IPv4-only and dual-stacked networks), why not support IPv6-only
networks out of the box as well? I don't understand what the perceived
problem is.

> In other words, let's aim to change that in the release after Oneiric.

I've not given up on making you reconsider... :-)

I'm a primarily a network engineer these days and I work closely with
ISPs, wireless carriers, and others in the industry. (I'm also a old-time
DD and Linux guy, which is why I take an interest in Ubuntu/Fedora/NM
specifically.)

The mood in the industry is that there is a desire to be able to deploy
IPv6-only services, and this goes especially for growth segments where the
shortage of IPv4 addresses are particularly hard felt, especially the
wireless/mobile segment and in the Asian developing economies.

On the other hand, every device and operating system that does not support
IPv6-only operation is an argument against deploying IPv6-only service. Of
course, these have different levels of importance - for example,
non-support by MS Windows would be a non-starter due to its huge market
share, while a Linux distro like Ubuntu is easier to disregard. Of course
it helps if the support can be activated by mucking about in the settings,
but it's not as good as out of the box «plug and play» - anything else
means unwanted support calls and unhappy customers. Fortunately, Apple's
and Microsoft's products support IPv6-only operation out of the box, so we
might very well already be at the point where providing IPv6-only service
is considered viable, but it'd certainly be a good thing for Ubuntu to
catch up.

The more devices that are capable of IPv6-only out of the box, the easier
the IPv6 transition gets. And every organisations that are doing stuff
online, including Ubuntu, have a responsibility and interest in
facilitating the IPv6 transition. For a more in-depth walkthrough of what's
at stake, I recommend you take a look at Geoff Huston's excellent keynote
at Linux.Conf.Au
<http://www.montanalinux.org/videos-lca2011-geoff-huston.html> by the way.

So again, if there's no disadvantage to supporting IPv6-only operation out
of the box, why not do so? And if there is a disadvantage, what is it?

> I was unfortunately bitten by a side-effect...

On Tue, Jul 26, 2011 at 11:00 AM, Tore Anderson <email address hidden> wrote:
> Is that the only concern you have about making IPv4 optional?

It "is", although I'm just stating potential issues so we can make an
informed decision. The next step will be to bring this up to the
NetworkManager mailing list; I'd very much like to avoid making
changes like this directly in Ubuntu when it might be possible to
convince upstream there is substancial benefit in changing the
default.

Mathieu Trudel-Lapierre <email address hidden>
Freenode: cyphermox, Jabber: <email address hidden>
4096R/EE018C93 1967 8F7D 03A1 8F38 732E FF82 C126 33E1 EE01 8C93

I agree completely that it is the best if this change is made upstream so that it will benefit other Linux distributions too!

I actually submitted a bug on NetworkManager in Fedora back in 2009 regarding IPv6 support by default (which was falsely claimed to be implemented in the release notes of Fedora 12), see <https://bugzilla.redhat.com/show_bug.cgi?id=538499>. It's assigned to the (as I understand it) NM upstream developer Dan Williams. The possibility of making IPv4 optional has been mentioned repeatedly, by Pekka Savola and myself, and most recently by Jirka Klimes of Red Hat only six weeks ago. However at no point has there been any feedback from Williams regarding his thoughts on it, which is rather frustrating to be honest.

Hopefully you have better luck at getting his attention to the question than I have so far - I appreciate you raising the issue on the NM list! :-)

Tore

Okay, now I've tested a bit with the Oneiric Alpha 3 live image. Highlights:

- The default Wired connection profile now has set the IPv6 mode to
Automatic by default.
- ...however, it behaves as if it is still set to «Disable» and does no
attempt of configuring IPv6.
- DHCPv6 appears broken, any activation attempt fails with a dhcp-error
- Also, dhclient6 appears to corrupt its own lease file.

Test #1: Wired ethernet, dual-stack network
-------------------------------------------
* Connection profile «Wired connection 1» has by default IPv6 mode
«Automatic».
* However, DHCPv6 is not attempted. Behaves as if IPv6 mode is «Disabled».
* «Require IPv4 for this connection to complete» is set.
* IPv4 DHCP activation succeeds, as do the overall network connectivity.

Test #2: Wired ethernet, single-stack IPv6 network
--------------------------------------------------
* Like test #1 - IPv6 configuration not performed in spite of IPv6 mode
being set to «Automatic».
* See attachment test2.oneiric-a3.wired.singlestack.syslog
* Since IPv4 is required and not present, the overall connection fails
(as expected I guess).

Test #3: Wireless ethernet, dual-stack network
----------------------------------------------
* Same default settings as for the Wired ethernet profiles
* DHCPv6 is attempted, but fails with «DHCPv6 client didn't bind to a
lease».
* Connection attempts loops and fails for 13 iterations until it settles
with only IPv4, no IPv6 configuration active.
* See attachment test3.oneiric-a3.wireless.dualstack.syslog

Test #4: Wireless ethernet, single-stack IPv6 network
-----------------------------------------------------
* Same default settings as for the Wired ethernet profiles
* DHCPv6 is attempted, but fails with «DHCPv6 client didn't bind to a
lease», as in test #3.
* Eventually corrupts the dhclient6-*.wlan0.lease file:
Aug 6 13:01:01 ubuntu dhclient:
/var/lib/dhcp/dhclient6-186b9d3d-e0d2-4fdc-a8a4-54798bef6345-wlan0.lease
line 4: expecting hexadecimal number.
Aug 6 13:01:01 ubuntu dhclient: ia-na "jPb`"
* Connection attempts loops and fails for 4 iterations until it gives up
completely, leaving the network disconnected.
* See attachment test4.oneiric-a3.wireless.singlestack.syslog

--
Tore Anderson

I also found a crash (probably unrelated to IPv6).

In this syslog, I booted the Live CD on a computer connected to a dual-stacked network using wired ethernet. As in test #1 above, it connected only using IPv4, apparently ignoring that the default IPv6 mode was «automatic». I entered the connection editor, looked around, and pressed save/apply/ok (or something like that) - without actually having changed any of the settings. NetworkManager instantly crashed:

Aug 6 13:59:54 ubuntu NetworkManager[1695]: <info> Saved default wired connection 'Wired connect
ion 1' to persistent storage
Aug 6 13:59:54 ubuntu NetworkManager[1695]: nm_connection_duplicate: assertion `NM_IS_CONNECTION
 (connection)' failed
Aug 6 13:59:54 ubuntu NetworkManager[1695]: nm_connection_for_each_setting_value: assertion `NM_
IS_CONNECTION (connection)' failed
Aug 6 13:59:54 ubuntu kernel: [ 77.405230] NetworkManager[1695]: segfault at aaaaaaaa ip 00e4d
6b2 sp bf952e40 error 4 in libgobject-2.0.so.0.2914.0[e19000+4f000]
Aug 6 13:59:54 ubuntu dbus[1420]: [system] Successfully activated service 'org.freedesktop.nm_dispatcher'
Aug 6 13:59:55 ubuntu modem-manager[1463]: <info> Caught signal 15, shutting down...
Aug 6 13:59:55 ubuntu kernel: [ 78.630912] init: network-manager main process (1695) killed by SEGV signal
Aug 6 13:59:55 ubuntu kernel: [ 78.630942] init: network-manager main process ended, respawning

After this, NM automatically restarted, and attempted to re-connect to the network. Now it *DID* attempt DHCPv6 as well, however it failed for four consecutive times with the «didn't bind to a lease» error, until it finally succeeded on the fifth try, this time correctly configuring all IPv6 information.

Tore

I finally could verify/reproduce the issues you were seeing with connections initially never start DHCPv6 even if they are showing "Auto" for the method -- there is another part of network-manager which uses the assumption that a missing method (e.g. for a new device connection, which typically doesn't necessarily have an associated file on the filesystem) means "Ignore", which is obviously false at this point.

I also noted that there is such a check in nm-applet which would write "Ignore" and then include the assigned IPv6 addresses if the above is fixed, so now we have two separate tasks for network-manager and network-manager-applet. I'm working on both, and they should be fixed shortly.

As for your crash, please try to reproduce it with apport enabled. You should see a file in /var/crash about this crash; we'd need this opened as a separate bug in order to be able to debug what is causing it. This is just so we can track each issue separately and know what is fixed and what isn't.

> I finally could verify/reproduce the issues you were seeing with
> connections initially never start DHCPv6 even if they are showing "Auto"
> for the method -- there is another part of network-manager which uses
> the assumption that a missing method (e.g. for a new device connection,
> which typically doesn't necessarily have an associated file on the
> filesystem) means "Ignore", which is obviously false at this point.

I think patch is what you need (maybe the last chunk only):

http://mail.gnome.org/archives/networkmanager-list/2011-August/msg00063.html

> I also noted that there is such a check in nm-applet which would write
> "Ignore" and then include the assigned IPv6 addresses if the above is
> fixed, so now we have two separate tasks for network-manager and
> network-manager-applet. I'm working on both, and they should be fixed
> shortly.

Ok, thanks! I haven't looked into the GUI stuff at all.

> As for your crash, please try to reproduce it with apport enabled. You
> should see a file in /var/crash about this crash; we'd need this opened
> as a separate bug in order to be able to debug what is causing it. This
> is just so we can track each issue separately and know what is fixed and
> what isn't.

I'll do my best, but I can't promise you I find the time before next
week, I'm going away from Friday, and I've got a really busy schedule
today and tomorrow.

Best regards,
--
Tore Anderson

This bug was fixed in the package network-manager - 0.9.0-0ubuntu2

---------------
network-manager (0.9.0-0ubuntu2) oneiric; urgency=low

  * debian/patches/lp761558_default_ip6_setting_auto.patch: default to AUTO for
    IPv6 method if the setting is missing (e.g. default new connection for new
    devices). (LP: #761558)
  * debian/patches/libnl3-support-0fe8c80.patch: fix nm_netlink_route_add() to
    take into account flags already passed (e.g. for replacing routes).
 -- Mathieu Trudel-Lapierre <email address hidden> Fri, 02 Sep 2011 10:28:15 -0400

This bug was fixed in the package network-manager-applet - 0.9.0-0ubuntu2

---------------
network-manager-applet (0.9.0-0ubuntu2) oneiric; urgency=low

  * debian/patches/default-ipv6-auto.patch: don't expect a missing DHCPv6 method
    value to mean "Ignore", when it now means "use DHCP". (LP: #761558)
  * debian/patches/nm-applet-use-indicator.patch: (LP: #819617)
    - rework, drop a lot of unnecessary changes.
    - turn the GtkStatusIcon back on.
    - use custom AppIndicator fallbacks to show/hide the GtkStatusIcon.
 -- Mathieu Trudel-Lapierre <email address hidden> Fri, 02 Sep 2011 15:33:05 -0400

I reopened the bug because the change made in network-manager 0.9.0-0ubuntu2 breaks connections using mobile broadband devices (the connections fail silently). Notified the NM mailing list about the issue on the patch from Tore.

* debian/patches/lp761558_default_ip6_setting_auto.patch: default to AUTO for
    IPv6 method if the setting is missing (e.g. default new connection for new
    devices). (LP: #761558)

This will need more investigation and I'm still looking into it, but mobile broadband connections tend to be useful, so I disabled the patch for the time being.

This should have been closed again some time ago -- the default since Oneiric is to try IPv6 in Automatic mode; although its success is not required to bring up interfaces.

Great!

However, is IPv4 success still required in order to bring up interfaces? If so, that still needs to change before you can say that Ubuntu truly supports IPv6 networks out of the box.

Tore

That's an option that can be changed by the user, so irrelevant to supporting IPv6 networks out of the box. I don't think there are enough IPv6-only networks to warrant shipping IPv4 as optional by default just yet, to me that's likely to cause far more pain for the time being.

Definitely something to revisit after we release Precise.

* Mathieu Trudel-Lapierre

> That's an option that can be changed by the user, so irrelevant to
> supporting IPv6 networks out of the box.

«Plug and Play» is important for most users.

> I don't think there are enough IPv6-only networks to warrant shipping
> IPv4 as optional by default just yet, to me that's likely to cause
> far more pain for the time being.

If there's no IPv6 on the network, as is the case for 99%+ of networks
today, IPv4 *won't* be made optional by such a change. Either IPv4 or
IPv6 must succeed even if neither is marked as "required", and if
there's no IPv6 on the network, the succeeding protocol pretty much has
to be IPv4.

Also, for what it's worth, Microsoft Windows (since Vista, 2006) and
Apple Mac OS X (since Lion, 2011) supports IPv6-only networks in their
default configuration.

With that in mind, it is hard for me to understand what that «far more
pain» concern you have is all about. Could you be more specific?

Best regards,
--
Tore Anderson

On dual-stack networks, which remains the norm rather than ipv6-only so far, and usually still require IPv4 to gain access to a large part of the internet, having IPv4 optional will mean the connection may still be brought up with just IPv6. Then people will wonder what is going on and file bugs here.

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

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 y...

FYI,

The Fedora project has decided to consider IPv6-only network attachment failing out-of-the-box a release blocker for Fedora 17. And the required patches to fix that is hitting the NetworkManager upstream code as we speak. One significant commit is here:

http://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=4abb300c967705b536cb11303f1c8296a6ca32f0

Dan Williams also just informed me that the patch in https://bugzilla.redhat.com/attachment.cgi?id=569078 will also be applied after having been adapted not to apply to WiMAX, mobile broadband, and Bluetooth DUN (because those connection types currently don't support IPv6 anyway). I'll post the commit ID as soon as I see it. That's is all the pieces missing for Ubuntu, as far as I can tell.

I see from the 0.9.3.995+git201203081848.bba834f-0ubuntu1 upload that the network-manager package in Precise is far from frozen, so I'm still hoping that the upstream support for IPv6-only networks, as well as the Fedora project's decision, will persuade you to include the two patches (or simply update to a more recent git snapshot) before Precise goes out the door.

Tore

The second part is now committed, here:

http://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=6b9511f6e98429c01b741754bc58795bf59f693e

Tore