Bug 798697 - The default IPv6 mode is "Ignore" for implicit/ifcfg-less connection profiles (e.g. wired ethernet)
The default IPv6 mode is "Ignore" for implicit/ifcfg-less connection profiles...
Product: Fedora
Classification: Fedora
Component: NetworkManager (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Dan Williams
Fedora Extras Quality Assurance
Depends On:
Blocks: IPv6Blocker F17Beta/F17BetaBlocker
  Show dependency treegraph
Reported: 2012-02-29 10:44 EST by Tore Anderson
Modified: 2012-03-21 14:47 EDT (History)
5 users (show)

See Also:
Fixed In Version: NetworkManager-
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2012-03-21 14:47:51 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
debug-level syslog from connection activation (8.42 KB, text/plain)
2012-02-29 10:44 EST, Tore Anderson
no flags Details
Change default IPv6 mode for implicit profile to Automatic (520 bytes, patch)
2012-03-10 06:00 EST, Tore Anderson
no flags Details | Diff

  None (edit)
Description Tore Anderson 2012-02-29 10:44:36 EST
Created attachment 566573 [details]
debug-level syslog from connection activation

Description of problem:

When booting the F17 Alpha Live-CD and connecting the computer to a wired ethernet with IPv6 on it (OtherConfig=1 in RA, with nameservers available in DHCPv6), NM does not start the DHCPv6 client at all.

When looking at the connection profile for "Wired connection 1", the IPv6 Method is set to Automatic. However, NM actually behaves as if it was set to Ignore; it does not appear to do anything about IPv6 at all. See attached syslog.

If I attempt to connect to the same network using WiFi, it works just fine.

There is no ifcfg file for eth0 / "Wired connection 1", so I suspect what is going on here is that nm-connection-editor program is intepreting the lack of any config as the default being Automatic, while NM itself interprets it as Ignore. If I'm right about that, you'll need this patch:


Will try to verify in a moment.

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1. Boot a computer using the F17 Alpha Live CD
2. Connect it to a network with some form of IPv6 service
Actual results:

NM doesn't do anything IPv6-related at all. Addressing may be configured by the kernel, in the case of SLAAC.

Expected results:

NM should do the IPv6-related tasks that are expected in mode Automatic. For example invoking DHCPv6, saving IPV6 name servers to /etc/resolv.conf, etc.

Additional info:
Comment 1 Tore Anderson 2012-02-29 11:11:10 EST
My suspicion was correct, the patch in http://mail.gnome.org/archives/networkmanager-list/2011-August/msg00063.html (Which still applies cleanly) does indeed solve the problem. I'll update the title accordingly.

Comment 2 Tore Anderson 2012-02-29 11:26:41 EST
Actually, only the last chunk of the above patch is relevant for this bug.

Comment 3 Tore Anderson 2012-03-10 05:50:51 EST
Nominating for F17 blocker. According to a post by Adam Williamson: «IPv6
breaking issues tentatively considered blocker for F17», see

The issue at hand is that NetworkManager considers the default IPv6 mode for configuration-less profiles to be "ignore". This means that the kernel might configure IPv6 routing and addresses (learned from SLAAC only), however, DHCPv6 will never be started and no IPv6 DNS servers will be added to /etc/resolv.conf. Furthermore, NetworkManager will not consider the IPv6 connection to have been successful.

Even if IPv6 routing and addressing has been configured by the kernel, the lack of configured DNS servers means that the network connection is essentially unusable for almost every use case.

Notably, the default wired ethernet connection profile in Fedora 17 is such an implicit connection profile (no ifcfg file) which triggers this problem.

It is worth noting that apart for the obvious lack of support for IPv6 network, the bug also leads to an inconsistent user experience for the following two reasons:

- The nm-connection-editor utility shows that the IPv6 mode is "Automatic" for the implicit connection profile in question.
- When connecting to wireless networks by clicking on their SSID in the nm-applet's drop-down list (and optionally entering a PSK), the resulting IPv6 mode is by default "Automatic".

Comment 4 Tore Anderson 2012-03-10 06:00:14 EST
Created attachment 569078 [details]
Change default IPv6 mode for implicit profile to Automatic

This patch changes the default IPv6 mode for configuration-less/implicit connection profiles from Ignore to Automatic.

This brings it in line with the defaults in nm-connection-editor as well as the default for wireless networks.

Comment 5 Adam Williamson 2012-03-16 13:26:27 EDT
Discussed at 2012-03-16 blocker review meeting. Accepted as a blocker bug per
criterion "The installed system must be able to download and install updates
with yum and the default graphical package manager in all release-blocking
desktops" in the context of an IPv6-only connection.

Dan says that he is going to accept this patch, but rework it not to apply to mobile broadband connections.

Fedora Bugzappers volunteer triage team
Comment 6 Fedora Update System 2012-03-19 17:15:16 EDT
NetworkManager- has been submitted as an update for Fedora 17.
Comment 7 Fedora Update System 2012-03-20 02:03:09 EDT
Package NetworkManager-
* should fix your issue,
* was pushed to the Fedora 17 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing NetworkManager-'
as soon as you are able to, then reboot.
Please go to the following url:
then log in and leave karma (feedback).
Comment 8 Fedora Update System 2012-03-21 14:47:51 EDT
NetworkManager- has been pushed to the Fedora 17 stable repository.  If problems still persist, please make note of it in this bug report.

Note You need to log in before you can comment on or make changes to this bug.