Red Hat Bugzilla – Bug 522916
NetworkManager does not recognize auto IPv6 configuration
Last modified: 2013-02-21 20:38:05 EST
Description of problem:
NetworkManager does not recognize the IPv6 state of an interface auto configured by the kernel
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Start Fedora in an IPv6 only network with radvd active on a router.
2. See that IPv4 DHCP will not configure an IPv4 addresssing scheme.
3. On the desktop Fedora reports no network connection.
4. Open a terminal session and do "ifconfig eth0".
5. See that IPv6 addresses are configured according to the radvd settings.
It is not possible to switch off IPv4. Every boot DHCP wants to find an IPv4 address and it will fail. And I know in advance it will not find IPv4 info.
Although there is network connectivity NM reports "no network" and the IPv6 tab in the wired interface section of NM reports "Ignore". Switching to "Automatic" is not possible. NM always comes back with "Ignore".
resolv.conf has no entry, so name lookup is not possible. When I manually add an IPv6 nameserver address to resolv.conf I can lookup names and applikations like firefox operate as expected.
When booting in an IPv6 only network IPv4 should be switched off and IPv6 should be configured/recognized and name resolution should be possible. NM must be able to configure IPv6 instead of ignoring it.
Please try with latest Fedora rawhide updates! There have been a few fixes to IPv6 support in NetworkManager that may fix your issue. Let me know, thanks!
I used 0.7.996-6.git20091021.fc12 and "Selecting IPv6 Settings -> Automatic -> Apply -> Edit -> IPv6 Settings -> Boom! It is on "Ignore", not "Automatic"!
My status report as off today NM-applet version 07.7.996:
At this moment I can change to IPv6 tab and change "ignore" to "Manual". After selecting the button "add" I can type a IPv6 address and prefix. This makes the "apply" button to change from grey (inselectable) to normal selectable. When I hit the apply button it seems that NM is accepting my IPv6 address. But when I reselect the IPv6 tab the screen is back on "Ignore" again.
I also do not see the given IPv6 address in the output of "ifconfig eth0" command. So cosmetically it looks like the function is working, but it gives no real effect.
Sorry, forgot to list my installed NetworkManager rpm's. Here they are:
This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle.
Changing version to '12'.
More information and reason for this action is here:
Is this bug still an issue with https://admin.fedoraproject.org/updates/NetworkManager-0.7.998-1.git20100106.fc12 ?
I still see the same behaviour with NetworkManager-0.7.999 from rawhide.
The network icon at the top of the screen reports no network, but over IPv6 I can still browse IPv6 capable websites and ifconfig eth0 also reports IPv6 auto configured addresses.
Network Manager reports 'Ignore' in the 'IPv6 settings'-tab.
It looks like NetworkManager is not reading the IPV6 data that is autoconfigured by the kernel.
Actually, these days the IPv6 method should be set to "automatic", which will handle all the autoconf stuff including udpating /etc/resolv.conf with nameservers from your router. If you make that change, does that cause NM to report the right state?
Seems that NetworkManager (latest in Fedora 12), setting a connection to automatic, does not respect radvd to request an IP by DHCPv6. May not be related to this bug report, but...
I will try to debug NetworkManager when I will have time.
(In reply to comment #9)
> Seems that NetworkManager (latest in Fedora 12), setting a connection to
> automatic, does not respect radvd to request an IP by DHCPv6. May not be
> related to this bug report, but...
> I will try to debug NetworkManager when I will have time.
Updated builds support radvd-requested DHCPv6; I think they are in F12 updates-testing and are already in F13. It's still a bit rough but it should work. Testing of:
would be appreciated!
You still can't turn off IPv4 though, so the original bug report is not yet fixed.
*** This bug has been marked as a duplicate of bug 538499 ***