Description of problem: If a ifcfg-* file read by NetworkManager lacks the IPV6INIT setting, this is interpreted to have an implicit value of "no". This makes NetworkManager not activate IPv6 on the interface, and in the case of an IPv6-only network, fail to activate the connection completely. This is inconsistent with the defaults used elsewhere. If there is no ifcfg file at all for the network interface being activated, NM will activate IPv6. If it creates a new ifcfg file when connecting to a new network (for example a wireless network), it will contain the value IPV6INIT=yes. Version-Release number of selected component (if applicable): NetworkManager-0.9.4.0-9.git20120521.fc17.x86_64 How reproducible: 100% Steps to Reproduce: 1. Attempt to connect to an IPv6-only network using an ifcfg file that does not contain the IPV6INIT setting (see below for an example). Actual results: The connection activation fails. Expected results: The connection activation should succeed. Additional info: Recent versions of Anaconda creates initial ifcfg-files that looks something like this during installation: UUID="6d68539e-4a58-491e-b0ee-36d435a886dc" NM_CONTROLLED="yes" HWADDR="00:1D:60:48:F5:9E" BOOTPROTO="dhcp" DEVICE="em1" ONBOOT="yes" Note the lack of IPV6INIT=yes. This prevents an freshly installed Fedora system from connecting to an IPv6-only network out of the box. This is a release-blocking problem, cf. <http://lists.fedoraproject.org/pipermail/test/2012-March/106054.html>. Also see the related Anaconda bug report: <https://bugzilla.redhat.com/show_bug.cgi?id=830434>.
I sent a patch to the NM mailing list about a year ago that changes NM's interpretation of the lack of IPV6INIT settings in ifcfg files, it ought to fix this problem: https://mail.gnome.org/archives/networkmanager-list/2011-August/msg00062.html Tore
ifcfg-rh has to interpret the config files the same way the non-NetworkManager-based networking scripts do. (That's its entire reason for existing.) Those scripts only configure IPv6 if "IPV6INIT=yes" is present, so NM must do so as well. To the extent that this is "inconsistent with the defaults used elsewhere", that's anaconda's fault for writing the file that way, and anaconda should be fixed, as you noted in your other bug.