PF Is pf state keeping intelligent enough to handle DHCPv6?

[jem]

With DHCPv6, a client sends Solicit and Request packets from its link-local fe80::/10 address to a multicast ff02::1:2 address that the server listens to, while the server sends its Advertise and Reply responses from it's own link-local address back to the client's link-local address.

Client	Message	Server
[fe80::dead:beef]:546	SOLICIT ->	[ff02::1:2]:547
[fe80::dead:beef]:546	<- ADVERTISE	[fe80::cafe:f00d]:547
[fe80::dead:beef]:546	REQUEST ->	[ff02::1:2]:547
[fe80::dead:beef]:546	<- REPLY	[fe80::cafe:f00d]:547

If a state entry is created for the initial SOLICIT packet like [fe80::dead:beef]:546 <> [ff02::1:2]:547, it would seem that it won't match the ADVERTISE reply from [fe80::cafe:f00d]:547.

Is pf clever enough to handle this, or is it necessary to add two stateless rules, one covering the client->server packets, and another covering the server->client replies?

 

[sko]

IIRC as with classic (i.e. IPv4) DHCP/BOOTP the DHCPREQUEST/-DISCOVER to multicast and the DHCP-server's response is stateless - so it always needs a PF rule, regardless of IPv6 or v4.