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.