Hide Forgot
Created attachment 413508 [details] Patch to /etc/sysconfig/ip6tables Description of problem: DHCPv6 reponses are not allowed by the default ruleset as shipped in /etc/sysconfig/ip6tables. This prevents Fedora from supporting IPv6 «out of the box» in network environments that are using DHCPv6. Note that the F12 release notes (point 4.2.2) claimed that this was supported out of the box. Version-Release number of selected component (if applicable): system-config-firewall-1.2.25-1.fc13.noarch How reproducible: 100% Steps to Reproduce: 1. Attempt to connect to a IPv6 network using DHCPv6 on a system using the default /etc/sysconfig/ip6tables file Actual results: The connection fails, due to the DHCPv6 responses being blocked in the firewall. Expected results: The DHCPv6 responses are let through the firewall to the DHCPv6 client, which can then (in cooperation with NetworkManager) configure the system for proper IPv6 operation. Additional info: The default rule that accepts «ESTABLISHED» traffic doesn't work because the initial DHCPv6 request is usually sent to one of two statically assigned multicast addresses (FF02::1:2 and FF05::1:3, see RFC 3315 section 5.1), while the response packets will use one of the DHCPv6 server's unicast addresses as their source. The DHCPv6 client's listening port is defined in RFC 3315 section 5.2 as 546/udp. While the server's listening port is defined in the same place as 547/udp, I don't see anything in the RFC demanding that 547/udp is used as the source port of the outbound packets. I'm therefore attaching a patch to /etc/sysconfig/ip6tables that allows all inbound traffic to port 546/udp without any matching on the source port. "rpm -qf" couldn't tell me which package /etc/sysconfig/ip6tables belonged to. However, the comment header says the file was written by system-config-firewall. I'm therefore assigning it to this package. Please reassign if this is incorrect. Tore
Any plans on fixing this? I just spent a whole day trying to find out why new Fedora system doesn't honor dhcp6 - initial response from community was that it is related to network manager problems and bugs like bug 437953 - well turned out it was all wrong and just ip6tables were to blame. I just disabled ip6tables after discovering what's really going on, but patch from comment 1 fixes problem too.
A few days ago i did a clean Fedora 14 install (x86_64) on my new computer. I also ran in to this problem. I also applied the iptables change from the patch.
This bug remains unfixed in the Fedora 15 Beta Live CD. NetworkManager has begun doing DHCPv6 by default in F15, but this bug prevents NM from ever being able to complete a DHCPv6 transaction. This is a trivial bug with a really simple patch. Please fix it... Tore
A netfilter kernel tracking module for DHCPv6 is in the works, which will help to solve the DHCPv6 unrelated problem. As an interim solution I will add a new trusted service entry to system-config-firewall / lokkit to open the port 546 for udp. But this service entry will not be enabled by default.
Thomas, Please reconsider allowing DHCPv6 responses by default. Because if it's prohibited by default, Fedora cannot be connected to networks that use DHCPv6 in a plug-and-play fashion. That is extremely user unfriendly - ordinary users can not be expected to fiddle around with advanced systems settings in order to get a network connection. Windows has no problems allowing DHCPv6 by default, neither does Ubuntu. And - Fedora has even promised its users that it would work by default already, see <http://docs.fedoraproject.org/en-US/Fedora/12/html/Release_Notes/sect-Release_Notes-Networking.html>. Why being so paranoid about DHCPv6? ICMPv6 Router Advertisements are allowed by default, and those can also be used to auto-configure an IPv6 network (although in a somewhat different and stateless manner). I don't understand why one would disallow one when the other one is already permitted. Tore
Any progress on this? Without allowing DHCPv6 it takes NetworkManager a long time to complete the process of configuring my interface for both IPv4 and IPv6. Although I do see my IPv6 address correctly configured with ifconfig, it comes up instantly but NM fails to get it. The ip6tables rule suggested in #656334: -A INPUT -m state --state NEW -m udp -p udp --dport 546 --sport 547 -s fe80::/10 -d fe80::/10 -j ACCEPT works just fine and NM manages to get my IPv6 address. BTW it seems that we technically do not need DHCPv6 but NM still start it, but I am not fully into IPv6.
I'm using Fedora 15 and I have just tested it at a conference Internet and Technology 2011 in Prague (starting at IPv6 day, BTW). They had an experimental network with RA, stateless autoconfiguration of addresses, but DHCPv6 configuration of DNS. The DNS part failed with NetworkManager (IPv6 set to Automatic, IPv4 set to Disabled). NetworkManager called dhclient, dhclient sent DHCPv6 Information Request and tcpdump showed the host got DHCPv6 reply from the server. But dhclient asked again and again, until it gave up. Bug 552099 seems to be exactly the same bug: https://bugzilla.redhat.com/show_bug.cgi?id=552099
Is there anything going on here?
This is still an issue in F-14 with all updates and F-15. Please address
Any progress on this? This issue is still there with F16 alpha rc5.
Please fix this before F16 is released! IPv6 support is important!!
The'll never fix this!
Related: bug 552099
(In reply to comment #4) > A netfilter kernel tracking module for DHCPv6 is in the works, which will help > to solve the DHCPv6 unrelated problem. I've noted this few days ago http://www.spinics.net/lists/netfilter-devel/msg20765.html
There is no need for stateful tracking of DHCPv6. It uses fixed, well-known, IANA-defined port numbers for both source port and destination port, just like DHCPv4 does, so the problem with high ephemeral port numbers doesn't exist. Nothing but a DHCPv6 client will be listening on UDP port 546. Please don't block this on kernel netfilter tracking module development. If you want to tighten it down later, fine. But don't leave it broken for so long and hurt early adopters of IPv6 until the "perfect" solution is done. Thanks. See also: bug 656334 -A INPUT -m state --state NEW -m udp -p udp --dport 546 --sport 547 -s fe80::/10 -d fe80::/10 -j ACCEPT
Actually, link-local IPv6 is only defined to be fe80::/64, so you can tighten this further: -A INPUT -m state --state NEW -m udp -p udp --dport 546 --sport 547 -s fe80::/64 -d fe80::/64 -j ACCEPT
Accepting link-local answers will enable DHPC servers/relays on link only. The great difference between DHCPv4 and DHCPv6 is the server does not need to be attached to local link. Therefore clients send requests to link-local multicast and to site-scope multicast address. So I think conntracking helper is the long-term ideal solution.
(In reply to comment #17) > Accepting link-local answers will enable DHPC servers/relays on link only. The > great difference between DHCPv4 and DHCPv6 is the server does not need to be > attached to local link. Therefore clients send requests to link-local multicast > and to site-scope multicast address. So I think conntracking helper is the > long-term ideal solution. Actually, the site-scoped multicast address is only used by DHCPv6 relays, not by clients. I just did a test to double-check, and I can confirm that the NetworkManager-0.9.3-0.2.git20120215 + dhclient-4.2.3-6.P2 combination does *not* fail back to the site-scoped multicast address before giving up, it only tries the link-local one. That said, I cannot see anything in RFC 3315 dictating which source port or source address, which means that including "--sport 547 -s fe80::/64" to the ip6tables rule (as was suggested in comment #16) is not certain to work in all cases. The DHCPv6 server embedded in my ZyXEL P2812 DSL router does use ephemeral source ports: 13:40:37.146507 IP6 fe80::21c:bfff:fe02:f2a5.dhcpv6-client > ff02::1:2.dhcpv6-server: dhcp6 inf-req 13:40:37.147883 IP6 fe80::ca6c:87ff:feab:d027.51300 > fe80::21c:bfff:fe02:f2a5.dhcpv6-client: dhcp6 reply RFC 3484, however, says that when choosing source address, matching scopes should be preferred, which would ascertain the use of a link local address from fe80::/64 as the source address of the DHCPv6 replay; however, there is no guarantee that all DHCPv6 servers implement RFC 3484, so I can easily imagine that there is at least one server implementation out there that would use its globally scoped unicast address as the source of replies instead. > So I think conntracking helper is the long-term ideal solution. Fine, but until the ideal solution is ready, could you allow regular traffic to the DHCPv6 client port, so that it actually works? Pretty please with sugar on top? The DHCPv6 client does tracking of transactions and validation of incoming replies all on its own, so it's not like opening the port would let anyone on the internet to just send a unsolicited DHCPv6 reply to the host that would actually be acted upon in any way. And, FWIW, Ubuntu, Windows, iOS, Mac OS X all allow DHCPv6 by default - so it's not like Fedora would be going into uncharted and unsafe territory by allowing it, either. Tore
Proposing as a Fedora 17 Beta Blocker under the Alpha Release Criteria: "19. It must be possible to run the default web browser and a terminal application from all release-blocking desktop environments. The web browser must be able to download files, load extensions, and log into FAS" "20. The installed system must be able to download and install updates with yum and the default graphical package manager in all release-blocking desktops" And: "A bug is considered a Alpha blocker bug if any of the following criteria are met: A bug in a Critical Path package that: Cannot be fixed with a future stable update" with the rationale that attaching a Fedora system to a DHCPv6-only network does not successfully connect to the network out-of-the-box due to poor default firewall rules, and hence cannot download and install updates. IPv6-only networks (probably with some form of translation to reach the IPv4 Internet) are a reality today. There are places in the world where one cannot get an IPv4 address. Asia (APNIC) has already run out. Projected dates of IPv4 exhaustion in the regional registries: IANA Unallocated Address Pool Exhaustion: 03-Feb-2011 Projected RIR Address Pool Exhaustion Dates: RIR Projected Exhaustion Date Remaining Addresses in RIR Pool (/8s) APNIC: 19-Apr-2011 1.1942 RIPENCC: 31-Jul-2012 2.8027 ARIN: 01-Aug-2013 5.6088 LACNIC: 31-Jan-2014 3.8662 AFRINIC: 31-Oct-2014 4.3445 Data from: http://www.potaroo.net/tools/ipv4/index.html
The loosely related bug 496444 breaks users' connections when IPv6 in NetworkManager is enabled. Together with this bug, it makes Fedora IPv6 not-so-ready. I second the beta blocker request. I hope to be able to connect to NIX CZ's testing network on the next IPv6 day with the current Fedora release in default configuration. Cheers, Pavel
Discussed at 2012-03-09 blocker review meeting. Agreed that this is a blocker: the bug infringes criteria cited in the report in the specific case of 'IPv6-only network'. We are making the determination that this is a significant enough case at this point in time to make the bug a blocker. We will report this decision to devel list and FESCo for their review, as it's a pretty significant call. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Thomas, you've commented somewhat on this issue outside of this bug report, but could you please update the bug report with details on your plans? We really need blocker bugs to be updated to be sure they're being handled. An untouched blocker bug raises all kinds of flags. Please note that Beta freeze is next week. I don't know what's going on with firewalld / s-c-f, but whatever's happening, it *needs to be done by Beta freeze*. We won't allow you to switch from s-c-f to firewalld after Beta freeze, I think. So whatever's the default at Beta freeze is going to be the default for Beta, and it needs to be allowing DHCPv6. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Default firewall solution in F17 will most likely [1] be FirewallD [2]. DHCPv6 responses have been by default allowed in FirewallD since this commit: [3] So this problem should be fixed with firewalld >= 0.2.3-1.fc17 and NetworkManager >= 0.9.3.995-0.4.git20120302.fc17. There's a firewalld test day [4] today so if you all have a couple of spare minutes, come and help us test this shiny new dynamic firewall. thanks [1] https://fedorahosted.org/fesco/ticket/805 [2] https://fedoraproject.org/wiki/FirewallD/ [3] http://git.fedorahosted.org/git/?p=firewalld.git;a=commitdiff;h=31189e942132f4df09660bd5e863fad619c0f18f [4] https://fedoraproject.org/wiki/Test_Day:2012-03-19_firewalld
Fixed in Fedora 17 in firewalld-0.2.4-1.fc17 or newer.
firewalld 0.2.4 went stable, so dropping F17 Beta blocking status. leaving open for earlier releases. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
FYI, this is made worse in Fedora 16 with the latest NetworkManager update (NetworkManager-0.9.4-2.git20120403.fc16.x86_64). Previously, NetworkManager would (apparently) tolerate an RA with an O flag but no DHCPv6 response and allow a connection requiring both IPv4 & IPv6 to come up. After upgrading, if the DHCPv6 response isn't seen (e.g., because the firewall is blocking it), it will repeatedly bounce the connection until it gets one. That behavior doesn't seem wrong to me (well, other than this bug), but a less-savvy user is going to be really annoyed.
I'm personally surprised that DHCPv6 replies need firewall rules at all. Isn't stateful firewalling a better way to do this?
(In reply to comment #27) > I'm personally surprised that DHCPv6 replies need firewall rules at all. Isn't > stateful firewalling a better way to do this? Stateful firewall needs conntracking helper to match outgoing multicast request to incoming unicast response. The helper is not yet in kernel.
Naturally. And what is a better solution now? To put this helper in kernel or to add iptables rules? I'm only curious.
system-config-firewall-1.2.29-6.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/system-config-firewall-1.2.29-6.fc17
Package system-config-firewall-1.2.29-6.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 system-config-firewall-1.2.29-6.fc17' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-6335/system-config-firewall-1.2.29-6.fc17 then log in and leave karma (feedback).
I just filed a new bug - #815555 : system-config-firewall is writing the ipv6 rules to the config files for both iptables and ip6tables. The IPv6 rule in iptables config keeps iptables from starting.
Package system-config-firewall-1.2.29-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 system-config-firewall-1.2.29-7.fc17' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-6335/system-config-firewall-1.2.29-7.fc17 then log in and leave karma (feedback).
system-config-firewall-1.2.29-7.fc17 has been pushed to the Fedora 17 stable repository. If problems still persist, please make note of it in this bug report.