Bug 591630 - DHCPv6 responses are not allowed by default ip6tables ruleset
Summary: DHCPv6 responses are not allowed by default ip6tables ruleset
Alias: None
Product: Fedora
Classification: Fedora
Component: system-config-firewall
Version: 15
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Thomas Woerner
QA Contact: Fedora Extras Quality Assurance
Whiteboard: AcceptedBlocker
Depends On:
Blocks: 538499
TreeView+ depends on / blocked
Reported: 2010-05-12 17:54 UTC by Tore Anderson
Modified: 2013-01-23 01:50 UTC (History)
18 users (show)

Fixed In Version: system-config-firewall-1.2.29-7.fc17
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2012-05-02 04:51:15 UTC
Type: ---

Attachments (Terms of Use)
Patch to /etc/sysconfig/ip6tables (419 bytes, patch)
2010-05-12 17:54 UTC, Tore Anderson
no flags Details | Diff

System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 552099 0 low CLOSED system-config-firewall has no simple mechanism to enable IPv6 DHCPv6 client 2021-02-22 00:41:40 UTC

Internal Links: 552099

Description Tore Anderson 2010-05-12 17:54:14 UTC
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):

How reproducible:

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.


Comment 1 Vladimir Mosgalin 2010-08-09 09:54:25 UTC
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.

Comment 2 Eddie Lania 2011-04-24 22:52:56 UTC
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.

Comment 3 Tore Anderson 2011-04-25 17:34:56 UTC
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...


Comment 4 Thomas Woerner 2011-04-26 13:35:08 UTC
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.

Comment 5 Tore Anderson 2011-04-26 14:15:16 UTC

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.


Comment 6 Jurgen Kramer 2011-06-06 13:56:55 UTC
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.

Comment 7 Pavel Šimerda (pavlix) 2011-06-09 16:37:13 UTC
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:


Comment 8 Pavel Šimerda (pavlix) 2011-07-01 22:38:58 UTC
Is there anything going on here?

Comment 9 Paul Wouters 2011-07-29 13:52:09 UTC
This is still an issue in F-14 with all updates and F-15. Please address

Comment 10 Jurgen Kramer 2011-08-17 13:21:07 UTC
Any progress on this? This issue is still there with F16 alpha rc5.

Comment 11 Paul Wouters 2011-09-22 02:42:27 UTC
Please fix this before F16 is released! IPv6 support is important!!

Comment 12 Eddie Lania 2011-11-05 22:24:16 UTC
The'll never fix this!

Comment 13 Pavel Šimerda (pavlix) 2011-12-23 23:29:44 UTC
Related: bug 552099

Comment 14 Jiri Popelka 2012-02-28 09:19:57 UTC
(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

Comment 15 Charles R. Anderson 2012-03-01 20:33:15 UTC
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.


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

Comment 16 Charles R. Anderson 2012-03-01 20:37:34 UTC
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

Comment 17 Petr Pisar 2012-03-02 09:41:16 UTC
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.

Comment 18 Tore Anderson 2012-03-02 12:56:24 UTC
(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.


Comment 19 Charles R. Anderson 2012-03-08 16:34:47 UTC
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"


"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:

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

Comment 20 Pavel Šimerda (pavlix) 2012-03-09 21:38:23 UTC
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.



Comment 21 Adam Williamson 2012-03-10 04:44:38 UTC
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

Comment 22 Adam Williamson 2012-03-16 18:31:27 UTC
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

Comment 23 Jiri Popelka 2012-03-19 09:39:52 UTC
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 >= 

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

Comment 24 Thomas Woerner 2012-03-19 19:58:16 UTC
Fixed in Fedora 17 in firewalld-0.2.4-1.fc17 or newer.

Comment 25 Adam Williamson 2012-03-21 21:54:39 UTC
firewalld 0.2.4 went stable, so dropping F17 Beta blocking status. leaving open for earlier releases.

Fedora Bugzappers volunteer triage team

Comment 26 Scott Schmit 2012-04-20 12:56:19 UTC
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.

Comment 27 Pavel Šimerda (pavlix) 2012-04-20 13:04:54 UTC
I'm personally surprised that DHCPv6 replies need firewall rules at all. Isn't stateful firewalling a better way to do this?

Comment 28 Petr Pisar 2012-04-20 13:31:05 UTC
(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.

Comment 29 Pavel Šimerda (pavlix) 2012-04-20 13:49:40 UTC
Naturally. And what is a better solution now? To put this helper in kernel or to add iptables rules? I'm only curious.

Comment 30 Fedora Update System 2012-04-20 18:33:14 UTC
system-config-firewall-1.2.29-6.fc17 has been submitted as an update for Fedora 17.

Comment 31 Fedora Update System 2012-04-21 21:05:44 UTC
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:
then log in and leave karma (feedback).

Comment 32 Tim Flink 2012-04-23 20:34:08 UTC
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.

Comment 33 Fedora Update System 2012-04-24 03:19:43 UTC
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:
then log in and leave karma (feedback).

Comment 34 Fedora Update System 2012-05-02 04:51:15 UTC
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.

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