Description of problem: By default, ip6tables is blocking dhcpd6 from receiving any packets. Client requests come from port 546 and are sent to port 547 with address ff02::1:2. Until ip6tables is stopped, nothing is happening. With it stopped, dhcpd6 is responding. Yes, I know that firewalld is comming and will fix everything but this should not be happening. Version-Release number of selected component (if applicable): Fedora 17, iptables-1.4.14-2.fc17.x86_64, dhcp-4.2.4-9.P1.fc17.x86_64 How reproducible: yes Steps to Reproduce: Install Fedora 17, install dhcp, configure dhcpd6 and start it. Start wireshare to monitor the interface, have a client startup an IPv6 network with dhcp specified. Actual results: blocked Expected results: works Additional info: Here are the client request and the server's response (at least the basic descriptions from wireshark) -- Internet Protocol Version 6, Src: fe80::5054:ff:fe96:3670 (fe80::5054:ff:fe96:3670), Dst: ff02::1:2 (ff02::1:2) User Datagram Protocol, Src Port: dhcpv6-client (546), Dst Port: dhcpv6-server (547) Internet Protocol Version 6, Src: fe80::5054:ff:fe16:5ae0 (fe80::5054:ff:fe16:5ae0), Dst: fe80::5054:ff:fe96:3670 (fe80::5054:ff:fe96:3670) User Datagram Protocol, Src Port: dhcpv6-server (547), Dst Port: dhcpv6-client (546) I was going to report this against iptables but decided it made more sense that the dhcp package should have the responsibility. Not many systems will be running dhcpd6 so opening up a system should be something that happens when dhcpd6.service is started. In addition, with the future use of firewalld something will need to work there too. This took more than a couple of hours to figure out since this was the first time I had configured dhcpd6 and thought I had screwed up the configuration. Fortuinately, someone else had the problem and posted a message about it. But, this is a bug and he should have reported it.
(In reply to comment #0) > I was going to report this against iptables but decided it made more sense > that the dhcp package should have the responsibility. Not many systems will > be running dhcpd6 so opening up a system should be something that happens > when dhcpd6.service is started. Yes, I agree that the responsibility for this is not on iptables. On the other side I don't know how to easily and reliably fix this in dhcp. dhcpd6 service could run 'ip6tables -A INPUT -p udp -m state --state NEW -m udp --dport 547 -j ACCEPT'. during start, but the problem occurs when iptables service is restarted, saved rules are read and our open port 547 is closed again. >In addition, with the future use of > firewalld something will need to work there too. Yes, it's possible that this will be much easier with firewalld. That's one of the aims of it. > This took more than a couple of hours to figure out since this was the first > time I had configured dhcpd6 and thought I had screwed up the configuration. I know exactly what you are talking about. I remember myself tearing my hair out for several days trying to figure out what's wrong with my first dhcpd6 configuration. > But, this is a bug and he should have reported it. I don't know any service that itself opens a port(s) in firewall so I wouldn't classify this as a bug. For me it's a feature request and I'm leaving this open as in the future we can see a solution solving this problem not just for dhcpd6 service.
IIRC, a whole bunch of years ago when iptables was first made standard part of the distribution, ntp (ntpd) would blast a whole for itself on port 123. If dhcpd6 is started and stopped by systemctl, I would think that it would be possible a to add a rule when started and remove that rule when stopped. And then there is the question of how serious it is security-wise to just open port 547 for input (546 for input is already allowed). Maybe you caould ask some of the security gurus on Fedora and/or Red Hat. I know some guys who are paid big bucks on computer security ... let me run this question passed them too.
This message is a reminder that Fedora 17 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 17. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '17'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 17's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 17 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior to Fedora 17's end of life. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 17 changed to end-of-life (EOL) status on 2013-07-30. Fedora 17 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.