6

Why do we need to have an ip6tables rule for DHCP6? (IPv4 does not require it by contrast)

Here's minimal IPv4 rules written by me, you see no special DHCPv4 (Wikipedia) rule:

IPv4: iptables --list-rules INPUT

-P INPUT DROP -A INPUT -i lo -m comment --comment loopback -j ACCEPT -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -m comment --comment traffic4 -j ACCEPT

Here's minimal IPv6 rules written by me, you see a special DHCPv6 (Wikipedia) rule:

IPv6: ip6tables --list-rules INPUT

-P INPUT DROP -A INPUT -i lo -m comment --comment loopback -j ACCEPT -A INPUT -p ipv6-icmp -m limit --limit 10/sec --limit-burst 30 -m comment --comment icmp6 -j ACCEPT -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -m comment --comment traffic6 -j ACCEPT -A INPUT -d fe80::/64 -p udp -m conntrack --ctstate NEW -m udp --dport 546 -m comment --comment dhcp6 -j ACCEPT

Question

I want to understand why IPv6 requires special rule for DHCPv6 to work under Linux using ip6tables, as opposed to IPv4 (iptables), where no rule is needed for DHCPv4 to work?

Improve this question

1 Answer 1

Reset to default
8

In DHCPv4, the initial discover/offer/request/ack exchange happens using broadcast addresses, and is initiated by the client, so iptables connection tracking has no problems following it on the client. Any subsequent renewals may be unicast, but they are client-initiated, so tracking them is no problem either. And because the DHCPv4 client needs to use source IP address 0.0.0.0 which is not normally allowed, it must use raw sockets for the exchange, and that will bypass much of iptables anyway.

In IPv6 there are no broadcasts, so the client sends a multicast packet to the "all DHCPv6 servers and relay agents in range" address. But the server may send an unicast response to a multicast request, so the association between the client request and the server response is not quite as straightforward and obvious as with DHCPv4.

Also, raw sockets are not needed with DHCPv6, because in IPv6, every interface will have a link-local IPv6 address by default, and it can be used as the source address for the DHCPv6 multicast. This allows the DHCPv6 exchange to be completely controlled by iptables since it basically just uses the regular UDP + IPv6 facilities.

Furthermore, a DHCPv6 server has the ability to ask the client to keep listening for Reconfigure messages. If the server has negotiated for that option in the initial DHCPv6 exchange, then the server may initiate a DHCPv6 reconfiguration. Because the reconfiguration begins with a packet sent by the server to the client, there will be no established connection (in the conntrack sense) at that point, and an explicit iptables rule is needed at the client to accept the inbound reconfiguration message.

Improve this answer
3
  • @A.B Yeah, after a bit of thinking I realized I went into the weeds. DHCPv4 is tricky. Commented Jun 17, 2020 at 9:04
  • @A.B: Looks like you're correct. Things have changed since the days of pre-2.2 kernels, which was when I was learning about DHCP and basics of tcpdump. Always surprising when something you originally took as gospel is no longer so... :-) Commented Jun 17, 2020 at 9:12
  • indeed at this time it was possible to send source Ip 0.0.0.0 and there was no raw socket needed Commented Jun 17, 2020 at 9:12

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.