This is the result of a combination of factors, all of which involve certain levels of doing the "wrong" thing...
First, OpenWRT's assumption that DHCPv6 from the upstream provider should come from LLA is not valid.
Second, NOBODY should be sending packets with LLA and GUA present in SRC,DST fields. LLA<->LLA or GUA<->GUA, but not LLA<->GUA. In fact, according to the RFCs, any node receiving a packet with both types of address in the header should drop that packet.
Third, OpenWRT's use of fc00::/6 as a catchall for ULA and LLA muddy's the waters and isn't a great choice, either. That prefix encompasses the following addressing classes:
- ULA Coordinated fc00::/8 (an internet draft that never achieved standardization, these addresses should be treated as IETF reserved and not utilized)
- ULA Local (fd00::/8) The addresses are an internet standard. Personally, I think they are a bad idea and utterly unnecessary, but I lost that fight.
- IETF Reserved range fe00::/9 (fe00:: through fe7f:ffff:ffff:ffff:ffff:ffff:ffff:ffff)
- LLA (Link Local fe80::/10) which to spell this out is fe80:: through. febf:ffff:ffff:ffff:ffff:ffff:ffff:ffff)
- IETF Reserved range fec0::/10
- Multicast (ff00::8)
I can only surmise that fc00::/6 was chosen as a lazy way to represent all of ULA+LLA and multicast and the reserved ranges are expected/assumed not to matter in this context (a poor assumption in what is theoretically a secuirty rule).
Unfortunately, since it is perfectly legitimate for an ISP to send DHCPv6 responses from any valid GUA, it's nearly impossible to have any form of address verification in this rule unless you are familiar with the behavior of your particular upstream. Thus, the only rational default for OpenWRT to apply here would be to replace the src_ip and dest_ip options with comments detailing this fact.