Return to Answer

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.

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.

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.

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.

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.

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.

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 at that point, and an explicit iptables rule is needed at the client to accept the inbound reconfiguration message.

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.

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.

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.

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.

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.

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 send by the server to the client, there will be no established connection at that point, and an explicit iptables rule is needed at the client to accept the inbound reconfiguration message.

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.

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.

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 at that point, and an explicit iptables rule is needed at the client to accept the inbound reconfiguration message.