Bug 538499 - IPv6-only network attachment fails, due to IPv4 addressing being considered mandatory
Summary: IPv6-only network attachment fails, due to IPv4 addressing being considered m...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: NetworkManager
Version: 17
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Dan Williams
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: AcceptedBlocker
: 522916 530669 586191 (view as bug list)
Depends On: 587513 587561 587592 587805 588192 588529 588553 588560 588619 591630 591929 634152
Blocks: IPv6Blocker F17Beta, F17BetaBlocker
TreeView+ depends on / blocked
 
Reported: 2009-11-18 17:32 UTC by Tore Anderson
Modified: 2012-03-21 18:47 UTC (History)
18 users (show)

Fixed In Version: NetworkManager-0.9.3.997-0.7.fc17
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-03-21 18:47:38 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
/var/log/messages from NM crash (80.61 KB, application/octet-stream)
2010-04-27 20:00 UTC, Tore Anderson
no flags Details
/var/log/messages from NM hang/crash (19.67 KB, application/octet-stream)
2010-04-27 23:04 UTC, Tore Anderson
no flags Details
Results for most (but not all) combinations of major IPv4 & IPv6 settings (5.72 KB, text/html)
2010-04-28 11:54 UTC, Scott Schmit
no flags Details
Updated results for most (but not all) combinations of IPv4 & IPv6 connection methods (11.16 KB, text/html)
2010-05-02 22:19 UTC, Scott Schmit
no flags Details
Results from IPv4 and IPv6 combination in Network Manager (10.90 KB, text/html)
2010-05-03 02:55 UTC, Steven Whately
no flags Details
Set «Require IPv4 ...» default disabled (1.39 KB, patch)
2012-03-10 10:34 UTC, Tore Anderson
no flags Details | Diff

Description Tore Anderson 2009-11-18 17:32:03 UTC
Description of problem:

Reading point 4.2.2 of the F12 release notes made me very happy:

«For GUI users, a new IPv6 tab will appear in the connection editor which will allow for control if the IPv6 settings similar to control of IPv4 settings already. After selecting the configuration method (auto is the default, which will honor router-advertisements and attempt to retrieve DNS information with DHCPv6 information-only mode) and entering any additional settings they may wish to use, then saving the connection, activating that connection should configure the interface fully with IPv6 as requested by the user.»

Finally, decent IPv6 support!  However after installing F12 I found that the reality is quite different, that «ignore» is the default. This makes default F12/NM pretty much useless in a single-stack IPv6 environment, and not really optimal in a dual-stack environment either as it doesn't handle IPv6 DNS servers nor expires kernel-configured SLAAC addresses as you change between networks (especially important for users that roam between WLANs).

In my opinion, the default should be what the release notes say it is - by default "automatic" for both IPv4 and IPv6.  However there's currently some problems that needs to be fixed before that can happen without breaking stuff for existing users:

Problem 1) NM appears to treat IPv4 and IPv6 connections as both necessary for the connection attempt to be deemed successful.  Considering that the following are all valid network environments:

Single-stack IPv4:  IPv4 DHCP service but no IPv6 RAs
Single-stack IPv6:  IPv6 RAs (SLAAC or DHCPv6), but no IPv4 DHCP
Dualstack:          both IPv4 DHCP service and IPv6 RAs (SLAAC or DHCPv6)

...I suggest that NM is changed to treat IPv4/IPv6 connectivity as a logical OR, that is, if either IPv4 DHCP or IPv6 (SLAAC or DHCPv6) activation is successful, then the entire connection activation is considered a success and the L2 link (especially relevant for a WLAN) is kept up, Firefox is told it's online, etc etc.

This approach would maintain compability with today's common single-stack IPv4 network, dual-stacked transitioning networks, as well as the single-stack IPv6-only networks of tomorrow.

Problem 2) IPv6 "automatic" doesn't really work properly, which will especially be visible for users disconnecting/reconnecting to networks often such as roaming users, more detail in bugs #530669 and #530670.


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

F12 (NetworkManager-0.7.996-6.git20091021.fc12.x86_64)


How reproducible:

100%


Steps to Reproduce:
1. Install F12
2. Attempt to use F12 in a IPv6-only environment with default settings
  

Actual results:

Hardly works, see above.  If you're using wired ethernet you'll get a SLAAC-configured address, but no name servers, and applications like Firefox believing the system is offline.  If you're using WLAN you're SOL as NM will down the interface after failing IPv4 DHCP negotiations.


Expected results:

That F12 has full IPv6 capabilities out of the box, like the release notes say, and that it generally behaves IP version agnostic, handling single-stacked IPv4- or IPv6-only environments as well as dualstacked IPv4+IPv6 environments equally well.


Additional info:

I briefly considered submitting this report on the release-notes package instead of NM.  In my opinion, however, the release notes actually describe how Fedora would work in a perfect world, so it is NM that should be fixed.  Hope that doesn't bother you.

I will be very happy to help by testing out new versions, by the way...

Regards,
Tore

Comment 1 Tore Anderson 2010-03-24 18:55:33 UTC
Ok, now that F13 Alpha is out I thought I'd test out its IPv6 support.  So I configured my home network in three different ways (SLAAC+stateless DHCPv6, stateful DHCPv6, and SLAAC+RDNSS-in-RA) and attempted to connect to it using a completely ordinary F13 Alpha Live media.  I also compared F13a's behaviour to that of a fresh install of Microsoft Windows 7, which is known to have decent IPv6 support.  Same hardware, same network, same everything.

The results are embarrassing, really.  I was completely unable to connect to the network in a usable manner (only kernel-level SLAAC actually worked, but that does not configure a DNS server configured so it's not terribly useful on its own).  Windows 7, on the other hand, performed perfectly in every single setup.

2010 could well be the last full year with IPv4 addresses readily available, and it's been over four months since the F12 release notes falsely claimed that there were full, default-on, support for at least my test scenario #1.  http://fedoraproject.org/wiki/Features/NetworkManagerIPv6 claims the task to «[a]dd full IPv6 support to NetworkManager» was 100% completed.  Which couldn't be further from the truth.  I wonder what is going on here, why all this misinformation?  I cannot imagine how anyone could have actually tested the IPv6 functionality and concluded that it works as advertised.

Anyway, here's the notes from my testing:

Expected results for all tests: IPv6 address, default route, and DNS servers automatically configured (from the correct source).  Browsing to dualstacked web sites like for example http://www.redpill-linpro.com/ works fine.

Test #1 - simplest possible IPv6 home network, SLAAC for IP addressing and routing configuration, DHCPv6 for DNS.
- No IPv4 DHCP service on LAN.
- ICMPv6 RA from router with OtherConfig and AdvAutonomous flags set (F12 radvd.rpm)
- DHCPv6 service with DNS information configured only (F12 dhcp.rpm)
- Out of the box configuration (F13a booted from Live CD, fresh Win7 install)

Win7 results: Works perfectly both for wired and wireless ethernet
F13a results: FAIL.  If wired ethernet being used: configures IPv6 address and default route, but not DNS servers.  NM believes system to be offline.  http://www.redpill-linpro.com does not load due to DNS lookup failure.  If wireless ethernet (w/WPA-PSK) being used: as with wired ethernet, but device set DOWN after after DHCPv4 timeout, so no connectivity whatsoever in the end (ping to internet destinations works while DHCPv4 requests are taking place though).

Test #1b - as #1, only now NM has been configured with "link-local only" for IPv4 and "automatic" for IPv6

Win7 results: identical to test #1.
F13a results: FAIL, just as with test #1.  With wired network the DHCPv6 transaction fails (does it confuse OtherConfig with the AdvManaged R1A flag?), with wireless avahi-autoipd times out.  With wired network I can ping to the internet, but no DNS servers are configured and NM thinks the system is offline.

Test #2 - IPv6 network with stateful DHCPv6 for addressing and DNS configuration, ICMPv6 RA for routing.
- No IPv4 DHCP service on LAN
- ICMPv6 RA with OtherConfig=1, AdvManaged=1, Autonomous=0 (F12 radvd.rpm)
- DHCPv6 with DNS information and a dynamic IP pool range (F12 dhcp.rpm)
- Freshly installed Win7, F13a set up as in test #1b

Win7 reults: Works perfectly both for wired and wireless ethernet.
F13a results: FAIL.  Default route being configured, but no IP address nor any DNS servers, both for wireless and wired.

Test #3 - SLAAC-only network with RDNSS attribute in ICMPv6 RA (RFC 5006 - experimental - no Win7 support).
- No IPv4 DHCP service on LAN
- No IPv6 DHCP service on LAN
- ICMPv6 RA with OtherConfig=0, AdvManaged=0, Autonomous=1, RNSS set (F12 radvd.rpm)
- F13a set up as in test #1b

Win7 results:  Works as expected;  doesn't configure DNS from RA, but falls back on fec0:0:0:ffff::1.  If that is reachable and working, surfing to IPv6-enabled web sites works perfectly, both for wired and wireless connections.
F13a reults: FAIL, same characteristics as with test #1.  For some reason it wants to attempt DHCPv6 negotiations in this case, which fails.  Can ping IPv6 destinations using literal addresses with wired ethernet though.

Tore

Comment 2 Dan Williams 2010-04-13 23:41:04 UTC
Thanks again; I'm working on this issue (ie, IPv6-only) this week.  We'll have something soon.

Comment 3 Steven Whately 2010-04-22 10:32:40 UTC
The /etc/resolv.conf update should combine the responses from DHCPv4 and DHCPv6 queries. This is because DHCPv6 cannot provide a IPv4 address for a DNS server.

DHCPv6 stateless config should work in both dual stack and single stack IPv6. This is where the ip number is provided by routing but the DNS and DOMAIN is provided by DHCPv6. 
DHCPV6C=yes
DHCPV6C_OPTIONS=-S

Steve

Comment 4 Dan Williams 2010-04-23 20:22:36 UTC
*** Bug 522916 has been marked as a duplicate of this bug. ***

Comment 5 Dan Williams 2010-04-23 21:49:13 UTC
*** Bug 530669 has been marked as a duplicate of this bug. ***

Comment 6 Tore Anderson 2010-04-24 14:27:04 UTC
Hi Dan, it's great to hear that improved IPv6 support is being worked on!  As you've probably understood by now, I'm quite the IPv6 advocate, and would really like to see Fedora (and other distributions too) have top-notch IPv6 support;  Large ISPs like for instance Comcast is doing trials of providing IPv6 to end-users at the moment, so I'm sure that IPv6 operating system support will become a crucial feature to have in the near future - I believe some governments have already added it as a hard requirement in their procurement procedures, too.

So if you need developement code to be tested or anything like that, please let me know - I'll be delighted to help out in any way I can.  Unfortunately that doesn't include providing patches - I never was much of a programmer.  :-/

Tore

Comment 7 Dan Williams 2010-04-27 07:04:30 UTC
I would much appreciate testing of the new build when it hits.  It does what I expect for plain RA, RA+DHCP, and DHCP-only cases, but I have limited test environments.  Let me know!

Comment 8 Dan Williams 2010-04-27 07:09:24 UTC
*** Bug 586191 has been marked as a duplicate of this bug. ***

Comment 9 Fedora Update System 2010-04-27 07:56:20 UTC
NetworkManager-0.8.0-8.git20100426.fc13 has been submitted as an update for Fedora 13.
http://admin.fedoraproject.org/updates/NetworkManager-0.8.0-8.git20100426.fc13

Comment 10 Fedora Update System 2010-04-27 07:57:08 UTC
NetworkManager-0.8.0-8.git20100426.fc12 has been submitted as an update for Fedora 12.
http://admin.fedoraproject.org/updates/NetworkManager-0.8.0-8.git20100426.fc12

Comment 11 Scott Schmit 2010-04-27 11:45:22 UTC
I tried the -8.git20100426, but I'm still seeing the behavior from Bug 586191 (NM seems to get DHCPv4 info, but doesn't use it). For what it's worth, /etc/resolv.conf either never got replaced or only contained IPv4 information (I have RA with RDNSS). On the latest in updates (-6.git20100408), /etc/resolv.conf was empty (filled with commented text).

The good news is that NM never times out (or it has a really long timeout), so I'm able to manually configure IPv4 from the commandline, poke around, etc, so let me know how I can help debug the problem.

Comment 12 Steven Whately 2010-04-27 11:54:00 UTC
See if I'm on the right track.
Automatic               : RA
Automatic, address only : RA with the ability to manually enter DNA1 and DOMAIN
Automatic, DHCP only    : DHCPv6 (where ip number is from DHCPv6)

You've covered RA and DHCP-only cases. 
Still missing RA+DHCP. Address from RA, DNA1 and DOMAIN from DHCPv6.
IPV6_AUTOCONF=yes
DHCPV6C=yes
DHCPV6C_OPTIONS=-S

Also the icon spins for a long period that I get "No network connection". Works
fine with the network service.

Comment 13 Dan Williams 2010-04-27 17:48:51 UTC
(In reply to comment #12)
> See if I'm on the right track.
> Automatic               : RA
> Automatic, address only : RA with the ability to manually enter DNA1 and DOMAIN
> Automatic, DHCP only    : DHCPv6 (where ip number is from DHCPv6)
> 
> You've covered RA and DHCP-only cases. 
> Still missing RA+DHCP. Address from RA, DNA1 and DOMAIN from DHCPv6.
> IPV6_AUTOCONF=yes
> DHCPV6C=yes
> DHCPV6C_OPTIONS=-S

DHCP is done if the RA has the "otherconf" or "managed" flags set.  Are there cases where that is not the case, yet you still want to run DHCP?  The whole point of the RA flags was to make this stuff automatic and not have to make the user do it manually...

Comment 14 Dan Williams 2010-04-27 17:56:25 UTC
(In reply to comment #11)
> I tried the -8.git20100426, but I'm still seeing the behavior from Bug 586191
> (NM seems to get DHCPv4 info, but doesn't use it). For what it's worth,
> /etc/resolv.conf either never got replaced or only contained IPv4 information
> (I have RA with RDNSS). On the latest in updates (-6.git20100408),
> /etc/resolv.conf was empty (filled with commented text).
> 
> The good news is that NM never times out (or it has a really long timeout), so
> I'm able to manually configure IPv4 from the commandline, poke around, etc, so
> let me know how I can help debug the problem.    

Scott, can you grab /var/log/messages for me?  Also, does this only seem to happen with DHCPv4, or does it also  happen with static IPv4 configuration?

Thanks!

Comment 15 Tore Anderson 2010-04-27 19:26:48 UTC
Fantastic news, Dan!  Really looking forward to testing this, hopefully I'll have time tonight.  I just installed the RPMs on my F12 box and got the following warnings about an already-existing file:

tore@wrath:~/Nedlasting$ sudo rpm -Uvh NetworkManager-*rpm
Forbereder...               ########################################### [100%]
   1:NetworkManager-glib    ########################################### [ 33%]
   2:NetworkManager         ########################################### [ 67%]
   3:NetworkManager-gnome   ########################################### [100%]
gtk-update-icon-cache: Failed to open file /usr/share/icons/hicolor/.icon-theme.cache : Filen eksisterer
gtk-update-icon-cache: Failed to open file /usr/share/icons/hicolor/.icon-theme.cache : Filen eksisterer
advarsel: %postun(NetworkManager-gnome-1:0.8.0-6.git20100408.fc12.x86_64) scriptlet failed, exit status 1

Maybe this can be safely ignored (the packages have been installed properly it seems), but I thought I'd let you know anyway.

Tore

Comment 16 Tore Anderson 2010-04-27 20:00:27 UTC
Created attachment 409573 [details]
/var/log/messages from NM crash

I've been trying to reproduce my test #1 (No IPv4 DHCP, IPv6 SLAAC + Information-Only DHCPv6).  I think there's something wrong with my DHCPv6 setup because now Windows 7 doesn't work correctly with it either, but in any case I've already managed to make NM chrash twice.  :-)  Basically what I did was to boot up with IPv4 and IPv6 mode set to Automatic for "System eth0", then it failed.  Then I tried to re-activate "System eth0" by selecting it from the systray applet => crash.

I'm attaching /var/log/messages so you can see for yourself what's going on.

Tore

Comment 17 Tore Anderson 2010-04-27 20:22:37 UTC
(In reply to comment #13)
> (In reply to comment #12)
> > See if I'm on the right track.
> > Automatic               : RA
> > Automatic, address only : RA with the ability to manually enter DNA1 and DOMAIN
> > Automatic, DHCP only    : DHCPv6 (where ip number is from DHCPv6)
> > 
> > You've covered RA and DHCP-only cases. 
> > Still missing RA+DHCP. Address from RA, DNA1 and DOMAIN from DHCPv6.
> > IPV6_AUTOCONF=yes
> > DHCPV6C=yes
> > DHCPV6C_OPTIONS=-S
> 
> DHCP is done if the RA has the "otherconf" or "managed" flags set.  Are there
> cases where that is not the case, yet you still want to run DHCP?  The whole
> point of the RA flags was to make this stuff automatic and not have to make the
> user do it manually...    

I believe you're right, Dan.  To sum up my impression of how things should work in the fully «Automatic» mode (which is the only sane default):

- If the «Autonomous» flag is set for a prefix in the RA packet, the host should generate a MAC-address-derived IPv6 address (EUI-64) and configure it.  «SLAAC», in other words.
- If the «Managed» flag is set in the RA packet, the host should attempt to contact a DHCPv6 server and retrieve a lease for a IPv6 address (which could be statically assigned, or from a dynamic pool, just like in DHCPv4).  This is the «Stateful DHCPv6» setup.

I do not know if the standards say that these are mutually exclusive or not.  I don't see why they would be, though - having addresses from both should work fine.  I can try to figure out how Windows 7 does it if you want, though.

In addition, a default route should be configured pointing to the router that originated the RA packet.  So if both the Autonomous and Managed, you'd end up in a situation with a default route but only link-local addresses.  :-)

Furthermore, for retrieval of DNS information and such:

- If the RA packet contains the «OtherConfig» flag the host should attempt to retreive DNS information from a DHCPv6 server.  It should _not_ attempt to retrieve IP addresses from the DHCPv6 server, unless also «Managed» is set.  With «Managed» unset, this is called «Stateless/Information-Only DHCPv6».  The «OtherConfig» flag is independent of the «Autonomous» and «Managed» flags.
- If the RA packet contains the «RDNSS» attribute, the host should configure the nameserver(s) contained in it.  I do not think this option is mutually exclusive with the «OtherConfig» flag, but I do not know how the servers should be ordered if both are set (or if one supersedes the other).  «RDNSS» is also completely independent of «OtherConfig» and «Managed».

It might be interesting to know what to do in the case of partial failures.  Say for instance, if Autonomous and RNDSS is set you'll likely be able to have a working internet connection just from those.  What if «OtherConfig» and/or «Managed» are also set, but the DHCPv6 server is unreachable, though?  I don't know what the standards say here, but I think it would be unwise by NM to shut down the interface (potentially killing the WPA supplicant and so on) in this situation.

I guess the «Automatic, address only» type simply means that NM will ignore RDNSS and OtherConfig and consider them not present or off.  And that the «Automatic, DHCP only» will do the same for Autonomous and RDNSS (not sure if it also forces Managed and OtherConfig to be assumed to be on or not).

Tore

Comment 18 Tore Anderson 2010-04-27 23:04:52 UTC
Created attachment 409611 [details]
/var/log/messages from NM hang/crash

Okay, I've done some more digging now.  First off, the DHCPv6 transaction never succeeded because the DHCP response packets were blocked in my firewall.  I believe this is the default - the ip6tables ESTABLISHED rule doesn't hit because the request is sent to ff02::1:2 but the response comes back from fe80::<lladdr-of-dhcpv6-server>.  So that is something that needs to be fixed (although probably not in NetworkManager) in order for IPv6 to work correctly out of the box.

I also installed the NetworkManager-debuginfo packet so the backtrace in the syslog got probably more useful in this log.  What I did here is my test #1, only this time with IPv4 DHCP active too.  The IPv6 router's (F12 box) /etc/radvd.conf contains the following:

> interface eth0 {
> 	AdvSendAdvert on;
> 	AdvOtherConfigFlag on;
> 	prefix 2001:16d8:ee47::/64 {
> 		AdvAutonomous on;
> 	};
> };

..and /etc/dhcp/dhcpd6.conf the following:

> default-lease-time 2592000;
> preferred-lifetime 604800;
> option dhcp-renewal-time 3600;
> option dhcp-rebinding-time 7200;
> allow leasequery;
> option dhcp6.name-servers  2001:16d8:ee47::d4cb;
> option dhcp6.domain-search "fud.no";
> option dhcp6.info-refresh-time 21600;
> subnet6 2001:16d8:ee47::/64 { }

I then started NetworkManager.  It sat for over five minutes with both applet dots green but not getting anywhere - in particular I thought the line «NetworkManager: <warn> unhandled DHCP event for interface eth0» looked suspicious.  After five minutes I selected "disable networking" from the applet's menu, and then it crashed instantly.

Also I note that even though it got all the IPv4 information instantly, NM didn't actually activate it.  I think it would be best to activate received information as it's being received - or else you will have to wait for e.g. a DHCPv4 transaction to time out before IPv6 service is ready for use in a single-stack IPv6 netowrk.  Perhaps also vice verca, if there's a timeout waiting for RAs in a single-stack IPv4 network.

Tore

Comment 19 Dan Williams 2010-04-28 00:08:40 UTC
(In reply to comment #18)
> Created an attachment (id=409611) [details]
> /var/log/messages from NM hang/crash
> 
> Okay, I've done some more digging now.  First off, the DHCPv6 transaction never
> succeeded because the DHCP response packets were blocked in my firewall.  I
> believe this is the default - the ip6tables ESTABLISHED rule doesn't hit
> because the request is sent to ff02::1:2 but the response comes back from
> fe80::<lladdr-of-dhcpv6-server>.  So that is something that needs to be fixed
> (although probably not in NetworkManager) in order for IPv6 to work correctly
> out of the box.

Yeah, firewall rules will need to be punched for IPv6.  I'd rather not have NM messing with firewall rules for anything other than connection sharing.

> I also installed the NetworkManager-debuginfo packet so the backtrace in the
> syslog got probably more useful in this log.  What I did here is my test #1,
> only this time with IPv4 DHCP active too.  The IPv6 router's (F12 box)
> /etc/radvd.conf contains the following:
> 
> > interface eth0 {
> > 	AdvSendAdvert on;
> > 	AdvOtherConfigFlag on;
> > 	prefix 2001:16d8:ee47::/64 {
> > 		AdvAutonomous on;
> > 	};
> > };
> 
> ..and /etc/dhcp/dhcpd6.conf the following:
> 
> > default-lease-time 2592000;
> > preferred-lifetime 604800;
> > option dhcp-renewal-time 3600;
> > option dhcp-rebinding-time 7200;
> > allow leasequery;
> > option dhcp6.name-servers  2001:16d8:ee47::d4cb;
> > option dhcp6.domain-search "fud.no";
> > option dhcp6.info-refresh-time 21600;
> > subnet6 2001:16d8:ee47::/64 { }
> 
> I then started NetworkManager.  It sat for over five minutes with both applet
> dots green but not getting anywhere - in particular I thought the line
> «NetworkManager: <warn> unhandled DHCP event for interface eth0» looked
> suspicious.  After five minutes I selected "disable networking" from the
> applet's menu, and then it crashed instantly.

Neat, I think I've fixed that upstream in 607f212a7f993842fcd813e6623958976eae6d17.

> Also I note that even though it got all the IPv4 information instantly, NM
> didn't actually activate it.  I think it would be best to activate received
> information as it's being received - or else you will have to wait for e.g. a
> DHCPv4 transaction to time out before IPv6 service is ready for use in a
> single-stack IPv6 netowrk.  Perhaps also vice verca, if there's a timeout
> waiting for RAs in a single-stack IPv4 network.

Maybe, yeah, but there's also the argument of not applying IP configuration until you have *all* of it, since that would allow other programs to access the network via IPv6 and then you just tear it down because IPv4 didn't complete and the user wanted it to.

We'll probably end up adding a "one IP method is sufficient" toggle somewhere that will allow a connection to complete even if one of it's methods doesn't.

Comment 20 Fedora Update System 2010-04-28 01:15:27 UTC
NetworkManager-0.8.0-8.git20100426.fc13 has been pushed to the Fedora 13 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update NetworkManager'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/NetworkManager-0.8.0-8.git20100426.fc13

Comment 21 Fedora Update System 2010-04-28 01:20:12 UTC
NetworkManager-0.8.0-8.git20100426.fc12 has been pushed to the Fedora 12 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update NetworkManager'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/NetworkManager-0.8.0-8.git20100426.fc12

Comment 22 Scott Schmit 2010-04-28 04:02:08 UTC
(In reply to comment #14)
> Scott, can you grab /var/log/messages for me?  Also, does this only seem to
> happen with DHCPv4, or does it also  happen with static IPv4 configuration?
> 
> Thanks!    

After trying a bunch of alternative configs, I finally figured it out -- if IPv6 is set to "Automatic" (which it was), the IPv6 addresses get configured, but the IPv4 addresses do not, and NetworkManager never considers the connection established (but nor does it time out). I'm guessing it's looking for a DHCPv6 response, which it'll never get because I'm not running that (I have radvd, and that's it). As soon as I changed IPv6 to "Ignore," the connection came up without a hitch.

Static/Manual vs Automatic (DHCP) IPv4 didn't make any difference.

I fiddled with other settings for IPv4 & IPv6, and I'm finding the results confusing (link-local IPv6 doesn't result in link-local only, etc), so I'll chalk it up to what Tore is talking about above and wait for the next update.

Comment 23 Tore Anderson 2010-04-28 05:33:32 UTC
(In reply to comment #19)

> Yeah, firewall rules will need to be punched for IPv6.  I'd rather not have NM
> messing with firewall rules for anything other than connection sharing.

Should I open a new bug for this, you think?  I'm not sure if system-config-firewall iptables-ipv6 would be the proper packages?

> > I also installed the NetworkManager-debuginfo packet so the backtrace in the
> > syslog got probably more useful in this log.  What I did here is my test #1,
> > only this time with IPv4 DHCP active too.  The IPv6 router's (F12 box)
> > /etc/radvd.conf contains the following:
> > 
> > > interface eth0 {
> > > 	AdvSendAdvert on;
> > > 	AdvOtherConfigFlag on;
> > > 	prefix 2001:16d8:ee47::/64 {
> > > 		AdvAutonomous on;
> > > 	};
> > > };
> > 
> > ..and /etc/dhcp/dhcpd6.conf the following:
> > 
> > > default-lease-time 2592000;
> > > preferred-lifetime 604800;
> > > option dhcp-renewal-time 3600;
> > > option dhcp-rebinding-time 7200;
> > > allow leasequery;
> > > option dhcp6.name-servers  2001:16d8:ee47::d4cb;
> > > option dhcp6.domain-search "fud.no";
> > > option dhcp6.info-refresh-time 21600;
> > > subnet6 2001:16d8:ee47::/64 { }
> > 
> > I then started NetworkManager.  It sat for over five minutes with both applet
> > dots green but not getting anywhere - in particular I thought the line
> > «NetworkManager: <warn> unhandled DHCP event for interface eth0» looked
> > suspicious.  After five minutes I selected "disable networking" from the
> > applet's menu, and then it crashed instantly.
> 
> Neat, I think I've fixed that upstream in
> 607f212a7f993842fcd813e6623958976eae6d17.

Okay, I'll try to check that out after work today, thanks!  Did you mean that the crash is fixed, or the unhandled DHCP event, by the way?

> Maybe, yeah, but there's also the argument of not applying IP configuration
> until you have *all* of it, since that would allow other programs to access the
> network via IPv6 and then you just tear it down because IPv4 didn't complete
> and the user wanted it to.

This is actually happens already (for SLAAC).  Admittedly though the DNS servers never gets written into /etc/resolv.conf, so temporary IPv6 connectivity (that's there only while the IPv4 DHCP request is in process) is not terribly useful.

> We'll probably end up adding a "one IP method is sufficient" toggle somewhere
> that will allow a connection to complete even if one of it's methods doesn't.    

Yes, this is essential.  And it is the only sane default, too - otherwise users will not be able to move between the three different networks types (ie. single-stack IPv4, single-stack IPv6, and dual-stack) in a «plug and play» manner, nor can all of them work out the box.  But that's what we want here, right?

I got to do my test #3 now though.  That is, No DHCP service (neither v6 or v4), and with the following radvd.conf on the router:

> interface eth0 {
> 	AdvSendAdvert on;
> 	prefix 2001:16d8:ee47::/64 {
> 		AdvAutonomous on;
> 	};
> 	RDNSS 2001:16d8:ee47::5:1aac {};
> };

This does not work if the IPv4 mode is set to «Automatic» - NM downs the interface when the DHCPv4 transaction times out and the IPv6 DNS server never gets written to /etc/resolv.conf.  But from your comments above I gather that this is currently the expected behaviour, so I'm not attaching a log.  Let me know if you want me to, though.

If I set the IPv4 mode to link-local only, or simply activate DHCPv4 service on the LAN, it appears to work perfectly.  So I think I can confirm that bug #530670 is now fixed.  Thanks!  :-)  However I did note the following message in the log:

Apr 28 07:07:22 wrath NetworkManager: <error> [1272431242.392556] [nm-system.c:514] nm_system_device_set_ip6_route(): (eth0): failed to set IPv6 route: Unknown message type 68 (errno = No such file or directory)

Both the default route and the link route to the configured network prefix appears to have been added OK though (by the kernel?), so everything appears to work out in the end.  But perhaps you want to figure out that error anyway.  Let me know if you need the full log!

Tore

Comment 24 Scott Schmit 2010-04-28 11:54:10 UTC
Created attachment 409789 [details]
Results for most (but not all) combinations of major IPv4 & IPv6 settings

Ok, I went through most of the combinations of IPv4 & IPv6 settings. I didn't do IPv4 DHCP, addresses-only (lack of time) and I didn't do IPv6 DHCP (I don't have that configured yet).

Manual IPv6 is broken: I can enter all the information, but when I hit apply, I see it on the connection list briefly, but then it disappears, which I take to mean it was deleted by NetworkManager.

See the attached HTML report for details. I can't promise that there isn't some kind of bleed-over from one configuration to the next that distorts the result, but that would be a bug, right? :-D

(This is all against 0.8.0-8.*.fc12 of NM, though there are VPN plugins still at 0.7.996-4.*.fc12, which shouldn't matter because I didn't use them.)

Hope this helps.

Comment 25 Pekka Savola 2010-04-29 10:43:13 UTC
On a dual-stack network, I'm getting the same thing: IPv4 doesn't get configured (even though there's a DHCPv4 response), and IPv6 isn't configured using SLAAC.

Wrt Dan's comment in #19: "one IP method is sufficient" I'd strongly advise against it. The whole point of IPv6 and IPv4 co-existence has been that hosts are able to support both v4 and v6, and if one of them is intentionally disabled or is missing in a particular network you connect to, you'll just use the other.

The default should definitely be "one IP method is sufficient", but if you want, you could enter a toggle that would enable "both IP methods are required".

Comment 26 Dan Williams 2010-04-29 16:24:18 UTC
(In reply to comment #25)
> On a dual-stack network, I'm getting the same thing: IPv4 doesn't get
> configured (even though there's a DHCPv4 response), and IPv6 isn't configured
> using SLAAC.

Right, we currently expect that if one of the IP methods does not complete successfully, the entire connection fails.  Working on an option for that, which will default to "if either of IPv4 or IPv6 complete, assume we're connected".

> Wrt Dan's comment in #19: "one IP method is sufficient" I'd strongly advise
> against it. The whole point of IPv6 and IPv4 co-existence has been that hosts
> are able to support both v4 and v6, and if one of them is intentionally
> disabled or is missing in a particular network you connect to, you'll just use
> the other.

I think you misunderstood comment #19; it says exactly what you propose.  There's a bug open for this elsewhere.

> The default should definitely be "one IP method is sufficient", but if you
> want, you could enter a toggle that would enable "both IP methods are
> required".    

Its going to be two toggles; one each for IPv4 and IPv6.

Comment 27 Dan Williams 2010-04-29 16:30:26 UTC
https://admin.fedoraproject.org/updates/NetworkManager-0.8.0-9.git20100429.fc12
https://admin.fedoraproject.org/updates/NetworkManager-0.8.0-9.git20100429.fc13

these updates fix the crash when an interface has been IPv6 enabled and is deactivated, but further autoconf events are sent from the kernel.  It has no other fixes, but subsequent builds will address the one-fails-all-fail issue we've been discussing.

Just to set expectations, at this time it's expected that if one of the IP methods fails, the entire connection fails.  That fix is being tracked in bug 567978.

With those expectations set, if people could start filing *new* bugs for specific issues that would be excellent.  Just so we can keep everything cleanly separated which helps the debugging a lot.  Thanks!

Comment 28 Dan Williams 2010-04-29 16:32:11 UTC
(In reply to comment #24)
> Created an attachment (id=409789) [details]
> Results for most (but not all) combinations of major IPv4 & IPv6 settings
> 
> Ok, I went through most of the combinations of IPv4 & IPv6 settings. I didn't
> do IPv4 DHCP, addresses-only (lack of time) and I didn't do IPv6 DHCP (I don't
> have that configured yet).

This is excellent information and should prove very useful.  Thanks!

Comment 29 Tore Anderson 2010-04-30 06:24:14 UTC
(In reply to comment #27)

> https://admin.fedoraproject.org/updates/NetworkManager-0.8.0-9.git20100429.fc12
> https://admin.fedoraproject.org/updates/NetworkManager-0.8.0-9.git20100429.fc13
> 
> these updates fix the crash when an interface has been IPv6 enabled and is
> deactivated, but further autoconf events are sent from the kernel.

Seems to work fine, thanks!

> With those expectations set, if people could start filing *new* bugs for
> specific issues that would be excellent.  Just so we can keep everything
> cleanly separated which helps the debugging a lot.  Thanks!    

OK - I just submitted bug #587513.  I thought it would be a good idea to have this as an "umbrella" bug for IPv6-related issues in NM, so I added it to the dependency list.  Let me know if you don't agree with that.

Tore

Comment 30 Scott Schmit 2010-04-30 12:11:26 UTC
Dan, I'll point out, based on my experience on 587513, all my test results are based on wifi, not Ethernet. Unless you give me a real easy way to clone/reconfigure connections quickly, I'm unlikely to redo that testing with Ethernet (it takes a while to create all the extra test connections).

Bugs I'll file as soon as I can and link to this bug (gotta get to work RSN) unless someone beats me to it:
* Link local (ipv4) doesn't work at all (or at least, not on wireless)
* NM eats manual IPv6 connections (or at least, on wireless)
* Link local (ipv6) doesn't do anything different from Auto (or at least, not on wireless)
* Disabled (IPv4) + Ignore IPv6) waits forever (or at least, on wireless) (arguably this is a degenerate shouldn't work, except that Ignore IPv6 seems to equal Auto? But maybe that's just because auto doesn't work right for me yet -- ignore is currently my working auto)
* When NM disconnects its last network, it should reset /etc/resolv.conf to the way it was before it started (or to empty) -- it confused the heck out of me when I was testing for the /etc/resolv.conf to contain the old state while it was (re)connecting. It makes perfect sense for it to keep /etc/resolv.conf (set up for Conn 1 on IFace 1) while connecting Conn 2 on Iface 2), of course.

Comment 31 Tore Anderson 2010-04-30 12:35:21 UTC
(In reply to comment #30)

> (arguably this is a degenerate shouldn't work, except that Ignore IPv6 seems to
> equal Auto? But maybe that's just because auto doesn't work right for me yet --
> ignore is currently my working auto)

Ignore, as far as I can tell, meanst that NM will not do anything about IPv6.  If you have SLAAC (AdvAutonomous on) on your network, you'll get an IPv6 address configured anyway - but this is done by the Linux kernel, _not_ by NM.  You'll also get the default route, this is also done by the kernel when it receives an ICMPv6 RA.

What NM needs to do (and which it doesn't do when you set IPv6 mode to ignore), is to perform DHCPv6 requests (if the RA contains OtherConfigFlag and/or ManagedFlag), and configure stuff according to the information it retrieves from the DHCPv6 server (DNS/NTP/etc servers, non-SLAAC IPv6 addresses, ..).  In addition NM needs to do the /etc/resolv.conf updating in case the RA contains the RDNSS field, the kernel will not do that).

By the way, I'll be away offline for the weekend, leaving in a few minutes.

Tore

Comment 32 Pekka Savola 2010-04-30 12:47:14 UTC
Tore, what you write is not completely accurate.  As of about 6 months ago, something (NetworkManager) started messing with net.ipv6.conf.eth0.accept_ra (eth0 is the interface in question) settings.  I suppose Ignore means NM sets this to 0, also disabling kernel-level SLAAC.  I haven't been able to figure out the exact pattern here, but something is definitely going on here.

Comment 33 Fedora Update System 2010-04-30 23:49:33 UTC
NetworkManager-0.8.0-9.git20100429.fc13 has been pushed to the Fedora 13 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update NetworkManager'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/NetworkManager-0.8.0-9.git20100429.fc13

Comment 34 Tore Anderson 2010-05-01 08:05:03 UTC
(In reply to comment #32)
> Tore, what you write is not completely accurate.  As of about 6 months ago,
> something (NetworkManager) started messing with net.ipv6.conf.eth0.accept_ra
> (eth0 is the interface in question) settings.  I suppose Ignore means NM sets
> this to 0, also disabling kernel-level SLAAC.  I haven't been able to figure
> out the exact pattern here, but something is definitely going on here.    

Interesting.  My own IPv6 connectivity has been provided by kernel-level SLAAC for years, with NM's IPv6 mode being set to «Ignore» (because more often than not, setting it to something else would just make the entire connection, including IPv4, to fail).  This has worked very well;  I've not had any problems with something changing the accept_ra sysctl and breaking my IPv6 connectivity.  But then again, I'm still on F12 so maybe this is something that's showed up during the F13 developement cycle?  (A thought:  If you enable IPv6 forwarding, RAs aren't processed anymore.  It couldn't be this you're seeing, could it?)

I think that if «ignore» is intended to mean «make the kernel ignore RAs» instead of «make NM ignore any IPv6 stuff», it's a bad name.  Would be easier to call it «Disable» or «Off» and make it set the disable_ipv6 sysctl for the interface.

Tore

Comment 35 Dan Williams 2010-05-02 08:29:32 UTC
(In reply to comment #32)
> Tore, what you write is not completely accurate.  As of about 6 months ago,
> something (NetworkManager) started messing with net.ipv6.conf.eth0.accept_ra
> (eth0 is the interface in question) settings.  I suppose Ignore means NM sets
> this to 0, also disabling kernel-level SLAAC.  I haven't been able to figure
> out the exact pattern here, but something is definitely going on here.    

NM only touches accept_ra when the IPv6 method is *not* ignore.

Comment 36 Dan Williams 2010-05-02 08:32:12 UTC
(In reply to comment #34)
> I think that if «ignore» is intended to mean «make the kernel ignore RAs»
> instead of «make NM ignore any IPv6 stuff», it's a bad name.  Would be easier
> to call it «Disable» or «Off» and make it set the disable_ipv6 sysctl for the
> interface.

"Ignore" just means "don't touch anything IPv6 related on this interface".  There isn't an option yet to completely disable IPv6 on a particular connection, but obviously if the method is "Ignore" NM won't run DHCP or manual configuration on the interface, and it should leave accept_ra alone too.

Comment 37 Dan Williams 2010-05-02 08:34:54 UTC
New updates everyone; these have a ton of fixes for IPv6 connection methods.  Please re-test with autoconf, autoconf+dhcp, dhcp-only, manual, and link-local.  Thanks!

https://admin.fedoraproject.org/updates/NetworkManager-0.8.0-10.git20100502.fc13
https://admin.fedoraproject.org/updates/NetworkManager-0.8.0-10.git20100502.fc12

Note that I'm still working on the capability to allow just one of IPv4/IPv6 to complete even though both are configured (and so obviously these builds do not have that capability), so keep that in mind while testing.

Comment 38 Dan Williams 2010-05-02 08:35:59 UTC
New updates everyone; these have a ton of fixes for IPv6 connection methods.  Please re-test with autoconf, autoconf+dhcp, dhcp-only, manual, and link-local.  Thanks!

https://admin.fedoraproject.org/updates/NetworkManager-0.8.0-10.git20100502.fc13
https://admin.fedoraproject.org/updates/NetworkManager-0.8.0-10.git20100502.fc12

Note that I'm still working on the capability to allow just one of IPv4/IPv6 to complete even though both are configured (and so obviously these builds do not have that capability), so keep that in mind while testing.

Comment 39 Scott Schmit 2010-05-02 15:11:54 UTC
(In reply to comment #38)
> New updates everyone; these have a ton of fixes for IPv6 connection methods. 
> Please re-test with autoconf, autoconf+dhcp, dhcp-only, manual, and link-local.
>  Thanks!

I assume you're taking advantage of the fact that you have a central tracking bug by announcing in one place, but still want us to report problems with specific methods in their respective bugs?

Comment 40 Dan Williams 2010-05-02 18:03:52 UTC
(In reply to comment #39)
> (In reply to comment #38)
> > New updates everyone; these have a ton of fixes for IPv6 connection methods. 
> > Please re-test with autoconf, autoconf+dhcp, dhcp-only, manual, and link-local.
> >  Thanks!
> 
> I assume you're taking advantage of the fact that you have a central tracking
> bug by announcing in one place, but still want us to report problems with
> specific methods in their respective bugs?    

Yeah, that's probably best. Thanks!

Comment 41 Scott Schmit 2010-05-02 22:19:42 UTC
Created attachment 410870 [details]
Updated results for most (but not all) combinations of IPv4 & IPv6 connection methods

This is a major improvement! I've updated my test report to show the latest results, and I list bug numbers where appropriate. The major outstanding issues are:
* Disconnecting an interface can leave IPv6 addresses/routes behind (see Bug 588149)
* Link local IPv6 doesn't set up the route if LL is left behind from a previous connection (see Bug 587836)
* Manual IPv6 picks up SLAAC. (see Bug 588163)
* Link local IPv4 doesn't work. I can't tell if my configuration is causing a problem (I might be missing a package?) or if NM isn't working right, but that's not related to this bug. (see Bug 587845)
* Disabled + Ignore don't finish or configure the interface, but it does leave the connection up, so it's a nice way to play with your network configuration by hand if you have wireless (which is otherwise not easy to do). I call it a feature! :-D

I did most of my testing on wireless, but various spot-checks shows near-identical behavior between wired and wireless.

Comment 42 Steven Whately 2010-05-03 02:55:33 UTC
Created attachment 410889 [details]
Results from IPv4 and IPv6 combination in Network Manager

Environment: DHCPv6 information only on copper.
Domain is not being added to /etc/resolv.conf when IPv4 is disabled.

Comment 43 Pekka Savola 2010-05-03 04:17:51 UTC
(In reply to comment #35)
> (In reply to comment #32)
> > Tore, what you write is not completely accurate.  As of about 6 months ago,
> > something (NetworkManager) started messing with net.ipv6.conf.eth0.accept_ra
> > (eth0 is the interface in question) settings.  I suppose Ignore means NM sets
> > this to 0, also disabling kernel-level SLAAC.  I haven't been able to figure
> > out the exact pattern here, but something is definitely going on here.    
> 
> NM only touches accept_ra when the IPv6 method is *not* ignore.    

Sorry for confusion then.  I have certainly seen this happening, and almost always I use "Ignore".  I have only now and then tested other options; I wonder if in some cases the setting may have "stuck" (e.g.: try some other option in SSID 1, then switch to SSID 2 with Ignore.  Does accept_ra get reset to 1 or does it stay on 0).

Comment 44 Dan Williams 2010-05-03 12:31:18 UTC
Update builds for more testing:

https://admin.fedoraproject.org/updates/NetworkManager-0.8.0-11.git20100503.fc13
https://admin.fedoraproject.org/updates/NetworkManager-0.8.0-11.git20100503.fc12

These *do* implement the feature of allowing IPv4 or IPv6 to fail as long as one completes.

Comment 45 Tore Anderson 2010-05-03 23:11:37 UTC
(In reply to comment #44)

> Update builds for more testing:
> 
> https://admin.fedoraproject.org/updates/NetworkManager-0.8.0-11.git20100503.fc13
> https://admin.fedoraproject.org/updates/NetworkManager-0.8.0-11.git20100503.fc12
> 
> These *do* implement the feature of allowing IPv4 or IPv6 to fail as long as
> one completes.    

Fantastic work, Dan!  NM has made an absolutely tremendous progress with IPv6 over the last few weeks.  There's still a few rough edges, but apart from bug #588560, none that I can see that are really important to fix before the release of F13.

I noticed, though, that the «Require IPvX addressing for this connection to complete» settings were both set default on.  Perhaps that is because I've upgraded instead of making fresh installations, but:  those are _not_ good defaults.  Good defaults would be:

- Require IPv4 addressing for this connection to complete: OFF
- Require IPv6 addressing for this connection to complete: OFF
- IPv4 Method: Automatic (DHCP)
- IPv6 Method: Automatic

If those are confirmed to be the case, and additionally:

- Bug #588560 are fixed
- DHCPv6 reponses are allowed in the default ip6tables ruleset

...I think I would be happy enough with everything to consider Fedora to actually be able to truthfully claim full "out of the box" IPv6 support.  This bug could then be closed - only "rough edge here" bugs would remain, as far as I can tell.

By the way - I'm going away on business Wednesday morning and will be gone for a week.  I'll probably be able to read and reply to e-mail daily, but I won't be able to test anything.

Tore

Comment 46 Pekka Savola 2010-05-04 06:09:36 UTC
(In reply to comment #43)
> (In reply to comment #35)
> > (In reply to comment #32)
> > > Tore, what you write is not completely accurate.  As of about 6 months ago,
> > > something (NetworkManager) started messing with net.ipv6.conf.eth0.accept_ra
> > > (eth0 is the interface in question) settings.  I suppose Ignore means NM sets
> > > this to 0, also disabling kernel-level SLAAC.  I haven't been able to figure
> > > out the exact pattern here, but something is definitely going on here.    
> > 
> > NM only touches accept_ra when the IPv6 method is *not* ignore.    
> 
> Sorry for confusion then.  I have certainly seen this happening, and almost
> always I use "Ignore".  I have only now and then tested other options; I wonder
> if in some cases the setting may have "stuck" (e.g.: try some other option in
> SSID 1, then switch to SSID 2 with Ignore.  Does accept_ra get reset to 1 or
> does it stay on 0).    

More information (with 0502 build). With "Ignore" set on WLAN interface, before hibernate, accept_ra was 1. After resuming from hibernate it was 0 (before I manually re-enabled networking, it had been disabled during hibernate).  So I suspect the hibernate/resume process is mucking with networking settings; not sure to what extent NetworkManager can deal with this, and if not, what would be the right component.  I filed a separate bug #588619 to track this.

Comment 47 Fedora Update System 2010-05-04 06:12:35 UTC
NetworkManager-0.8.0-11.git20100503.fc13 has been pushed to the Fedora 13 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update NetworkManager'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/NetworkManager-0.8.0-11.git20100503.fc13

Comment 48 Fedora Update System 2010-05-04 06:14:28 UTC
NetworkManager-0.8.0-11.git20100503.fc12 has been pushed to the Fedora 12 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update NetworkManager'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/NetworkManager-0.8.0-11.git20100503.fc12

Comment 49 Fedora Update System 2010-05-04 23:50:00 UTC
NetworkManager-0.8.0-11.git20100503.fc13 has been pushed to the Fedora 13 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 50 Fedora Update System 2010-05-05 09:15:37 UTC
NetworkManager-0.8.0-12.git20100504.fc13 has been submitted as an update for Fedora 13.
http://admin.fedoraproject.org/updates/NetworkManager-0.8.0-12.git20100504.fc13

Comment 51 Fedora Update System 2010-05-05 09:18:22 UTC
NetworkManager-0.8.0-12.git20100504.fc12 has been submitted as an update for Fedora 12.
http://admin.fedoraproject.org/updates/NetworkManager-0.8.0-12.git20100504.fc12

Comment 52 Fedora Update System 2010-05-06 07:01:16 UTC
NetworkManager-0.8.0-12.git20100504.fc13 has been pushed to the Fedora 13 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 53 Fedora Update System 2010-05-11 06:54:14 UTC
NetworkManager-0.8.1-0.1.git20100510.fc12 has been submitted as an update for Fedora 12.
http://admin.fedoraproject.org/updates/NetworkManager-0.8.1-0.1.git20100510.fc12

Comment 54 Tore Anderson 2010-05-11 23:35:28 UTC
(In reply to comment #45)

> I noticed, though, that the «Require IPvX addressing for this connection to
> complete» settings were both set default on.  Perhaps that is because I've
> upgraded instead of making fresh installations, but:  those are _not_ good
> defaults.  Good defaults would be:
> 
> - Require IPv4 addressing for this connection to complete: OFF
> - Require IPv6 addressing for this connection to complete: OFF
> - IPv4 Method: Automatic (DHCP)
> - IPv6 Method: Automatic
> 
> If those are confirmed to be the case, and additionally:
> 
> - Bug #588560 are fixed
> - DHCPv6 reponses are allowed in the default ip6tables ruleset
> 
> ...I think I would be happy enough with everything to consider Fedora to
> actually be able to truthfully claim full "out of the box" IPv6 support.  This
> bug could then be closed - only "rough edge here" bugs would remain, as far as
> I can tell.

After confirming that bug #588560 is fixed (by git20100510), I gave the latest F13 beta live image a spin - first I upgraded NM to git20100510 and tried to connect to my home wireless network.  The connection profile that was was automatically created had the following default settings:

IPv4 method: Automatic (DHCP)
Require IPv4 addressing for this connection to complete: ON
IPv6 method: Ignore
Require IPv6 addressing for this connection to complete: ON (though grayed out)

This, as far as I can tell, means that IPv6 is _not_ fully supported out of the box by the most recent NM (git20100510) - the defaults needs to be set as described in comment #45 for that to be the case.  I'm therefore re-opening this bug.

Tore

Comment 55 Fedora Update System 2010-06-10 19:05:48 UTC
NetworkManager-0.8.1-0.1.git20100510.fc12 has been pushed to the Fedora 12 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 56 Tore Anderson 2010-06-11 06:40:02 UTC
This bug isn't quite fixed yet, for the reason stated in comment #54.  Reopening.

Tore

Comment 57 Tore Anderson 2010-07-05 08:59:56 UTC
It's soon been two months since NM got proper IPv6 support finalised.  Unfortunately, it's still disabled by default.  I'm rather confused about this, why stop right before the finish line when so much effort went into getting there?  Is there something I can do to help get this finished?

The urgency of getting IPv6 supported out of the box should be obvious - IANA is projected to run out of free IPv4 space within 12 months, and after that it's just a matter of months until the RIRs do, and after that it won't take long until we'll see ISPs run out of available space.  And of course it would be very unwise to wait until the last possible moment to enable IPv6 support.

T-Mobile has already announced that they're going single-stack IPv6 on the client side (using NAT64 to provide connectivity to the IPv4 internet).  NM in its current form will be completely unable to connect to such a network without mucking about in the settings, and that's a pretty good reason for your average Mom&Pop user to ditch Linux completely as they generally won't have any idea of what IPv4 or IPv6 is (nor should they have to!).  It's only natural to make the comparsion to Windows, which have had full IPv6 support for years (since Vista).

I probably don't have to remind anyone that out-of-the-box support for IPv6 was accepted as a F12 feature, but anyway: https://fedoraproject.org/wiki/Features/NetworkManagerIPv6

Again, if there's still work to be done before the IPv6 support can be enabled by default, please let me know and I'll try my best to help out!

Tore

Comment 58 Tore Anderson 2010-12-04 19:31:43 UTC
We're merely weeks, or even days, away from the depletion of the global IANA IPv4 address pool.  Depressingly however, Fedora 14 (with NetworkManager-0.8.1-10.git20100831.fc14.x86_64) is still unable to connect to a IPv6 network out of the box.

Microsoft Windows have had this capability since the release of Vista, which happened over four years ago.  When will Fedora catch up, I wonder?

Tore

Comment 59 Bill C. Riemers 2010-12-17 05:58:55 UTC
I've been playing around with ipv6 on my home network.  If my dd-wrt router is using tun6to4 then network manager works with IPV6 out of the box.   If on the other hand, if I configure my router to use a tunnel broker like Hurricane Electric then no matter what I try I cannot get network manager to work with the connection over wlan0.

It seem the problem is either way wlan0 is configure with an 6to4 address rather than querying radvd for the 64 bit ip address to use.

Comment 60 Bill C. Riemers 2010-12-17 07:09:06 UTC
(In reply to comment #59)
> It seem the problem is either way wlan0 is configure with an 6to4 address
> rather than querying radvd for the 64 bit ip address to use.

I was wrong about the source of the problem.  My radvd.conf file on my router had an error.  Once I corrected, I find wlan0 pick-ups the correct ipv6 address.  However, routing of packets still fail.

Comment 61 Tore Anderson 2011-04-25 17:32:30 UTC
I've given the F15 Beta a spin now on my laptop (using the wireless interface for testing).

First the good news: The default «IPv6 mode» setting has changed from «Ignore» to «Automatic». «Require IPv6 addressing for this connection to complete» is by default unset, which is sensible. I've confirmed that it by default configures a SLAAC-derived IPv6 address, and also that it adds ICMPv6 RA RDNSS Option-provided name servers to /etc/resolv.conf (this is an improvement since F14).

I did notice, though, that if I change the IPv6 mode to «Ignore», save the connection profile, edit it again and set the IPv6 mode back to «Automatic», «Require IPv6 addressing for this connection to complete» has changed to being set, even though I never touched that setting. Bug?

The bad news is that «Require IPv4 addressing for this connection to complete» appears to continue to default to being set. That means that out-of-the-box Fedora is *still* unable to connect to IPv6-only networks. :-(

But it gets worse! The situation appears to have become much much more problematic than before. In F14 it was easy for a power user to edit the connection profile and change the necessary settings, but with the new GUI I've not been able to figure out how to configure the settings for a network to which I'm not connected. The "Options..." button remains greyed out while the network is in the «Connecting» state, so I end up in a Catch-22 situation: I need to connect to the network in order to make the setting modifications necessary for me to be able to connect to the network. This is really bad! By the way this problem isn't specific to IPv4/IPv6 either - I was also completely unable to make NM connect to a network where static IPv4 configuration would have been necessary, something which was really easy with F14.

Another piece of bad news is that bug #591630 remains unfixed. So while NM will correctly start a DHCPv6 transaction as soon as it sees an ICMPv6 RA that instructs it to do so, the default ip6tables ruleset prevents it from ever seeing the responses. So DHCPv6 still doesn't work out of the box either.

Tore

Comment 62 Jirka Klimes 2011-06-16 10:12:43 UTC
(In reply to comment #61)
> I did notice, though, that if I change the IPv6 mode to «Ignore», save the
> connection profile, edit it again and set the IPv6 mode back to «Automatic»,
> «Require IPv6 addressing for this connection to complete» has changed to being
> set, even though I never touched that setting. Bug?
> 
That was a problem in ifcfg-rh plugin, which didn't read IPV6_FAILURE_FATAL (i.e. "Require Ipv6.."), when IPv6 is ignored. Using keyfile plugin, there's no such problem.
Fixed upstream: c2dbd1f836fd2b2a9bd05cf942b87a51b339d421

> The bad news is that «Require IPv4 addressing for this connection to complete»
> appears to continue to default to being set. That means that out-of-the-box
> Fedora is *still* unable to connect to IPv6-only networks. :-(
> 
"Require IPvX addressing ..." corresponds to  "NOT 'may-fail'" in settings properties (http://projects.gnome.org/NetworkManager/developers/migrating-to-09/ref-settings.html).
'may-fail' is still FALSE for both IPv4 and IPv6 => "Require IPvx ..." is checked.
However when connections are established, the connection is completed and when no method is present, 'may-fail' is set to TRUE for IPv6. Which effectively happens only when you click on WiFi network in applet the first time and new connection is added.

Dan, do you see any problems with defaulting 'may-fail' to TRUE for both IPv4 and IPv6?

> But it gets worse! The situation appears to have become much much more
> problematic than before. In F14 it was easy for a power user to edit the
> connection profile and change the necessary settings, but with the new GUI I've
> not been able to figure out how to configure the settings for a network to
> which I'm not connected. The "Options..." button remains greyed out while the
> network is in the «Connecting» state, so I end up in a Catch-22 situation: I
> need to connect to the network in order to make the setting modifications
> necessary for me to be able to connect to the network. This is really bad! By
> the way this problem isn't specific to IPv4/IPv6 either - I was also completely
> unable to make NM connect to a network where static IPv4 configuration would
> have been necessary, something which was really easy with F14.
> 
This is an issue of Gnome's control-center and there are some bugs on that. I hope it will be addressed in Gnome 3.2
Nonetheless, you are still able to edit connections via nm-connection-editor (run from terminal or Applications->Other->Network Connections)

Comment 63 Paul Wouters 2011-07-29 13:12:03 UTC
One GUI problem is that since i do not complete connecting to the v6only network, I don't have an entry in the wireless network list in "edit connections" so I cannot change any options.

Perhaps a connection "default" could be added to the list so we can change the default settings?

This is on F-14 using NetworkManager-0.8.4-1.fc14.x86_64

Comment 64 Paul Wouters 2011-07-29 13:48:41 UTC
(In reply to comment #63)
> One GUI problem is that since i do not complete connecting to the v6only
> network, I don't have an entry in the wireless network list in "edit
> connections" so I cannot change any options.
> 
> Perhaps a connection "default" could be added to the list so we can change the
> default settings?
> 
> This is on F-14 using NetworkManager-0.8.4-1.fc14.x86_64

It turned out the wifi list is sorted on "last connect". Since the connection failed, it is marked as "never", which is older then "2 years" so this connection, despite having it attempted a few seconds ago, appears at the bottom of the list after all the networks you ever connected to in your lifetime.

I suggest that failure is not a sort item and that networks that we tried but failed to connect to appear high in the sort order, so we can make modifications (like unselecting ipv4) so we can manually fix issues preventing us from connecting.

Comment 65 Tore Anderson 2012-03-10 10:28:33 UTC
Nominating for F17 blocker. According to a post by Adam Williamson: «IPv6 breaking issues tentatively considered blocker for F17», see http://thread.gmane.org/gmane.linux.redhat.fedora.devel/160775.

The remaining problem discussed in this bug report is that by default, NetworkManager will not be able to connect to an IPv6-only network. This is due to the setting «Require IPv4 connectivity for this connection to complete» is enabled by default. Of course, «Require IPv4» means essentially the same as «Don't support IPv6-only».

When attempting to connect to an IPv6-only network, the NetworkManager version in F17 will successfully acquire and commit the IPv6 addressing, routing, and DNS configuration, and for a few seconds everything works well. However, when the DHCPv4 client (which is still running in the background) eventually fails, the entire connection is brought down, and the connection process restarts from the beginning in a (apparantly) endless loop.

Tore

Comment 66 Tore Anderson 2012-03-10 10:34:16 UTC
Created attachment 569076 [details]
Set «Require IPv4 ...» default disabled

This patch fixes the problem by changing the built-in default value of the «Require IPv4 for this connection to complete» setting to disabled.

I want to emphasize that this change does not in any way affect NetworkManager's ability to correctly fail the connection when failing to receive any DHCPv4 offers on an IPv4-only network. With both «Require IPv4» and «Require IPv6» disabled, the result is a logical OR; at least one of the protocols must still succeed in order for the overall connection activation to be considered a success.

Tore

Comment 67 Adam Williamson 2012-03-16 17:15:28 UTC
Dan says this has been pushed to (upstream) git master and it'll show up in the next F17 build.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Comment 68 Adam Williamson 2012-03-16 17:24:07 UTC
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.

Comment 69 Fedora Update System 2012-03-19 21:15:06 UTC
NetworkManager-0.9.3.997-0.7.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/NetworkManager-0.9.3.997-0.7.fc17

Comment 70 Fedora Update System 2012-03-20 06:02:59 UTC
Package NetworkManager-0.9.3.997-0.7.fc17:
* 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-0.9.3.997-0.7.fc17'
as soon as you are able to, then reboot.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2012-4188/NetworkManager-0.9.3.997-0.7.fc17
then log in and leave karma (feedback).

Comment 71 Fedora Update System 2012-03-21 18:47:38 UTC
NetworkManager-0.9.3.997-0.7.fc17 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.