On Sun, 12 Apr 2026 20:53:07 -0400
Jon Maloy
tap_ip6_daddr() selects the reply destination based on our source address type (link-local), so it always returns addr_ll_seen. But if the client sent from a global address, we would reply to an address different from what the client is expecting. Since RFC 8415 allows clients to use global addresses for DHCPv6, we now correct this, and always respond to the address the client was using.
I don't have much to add on top of David's comments, just two remarks about the commit message: - as far as I understand, you need this patch to simplify the rest of the series, but the way this is written makes it look like you're fixing something concrete. Somebody looking at the revision log in a while (including myself) will think so, at least. Are you actually fixing something you've ever seen in practice? If not, I think you should state that this is theoretical and it's simply needed by further changes, but doesn't fix any practical issue. - I think it's time to start referring to RFC 9915 (it obsoleted RFC 8415 in January 2026) and maybe a reference to section 18.3.10 would be appropriate here, as that's the one clarifying that "[...] the server unicasts the Advertise or Reply message directly to the client using the address in the source address field from the IP datagram in which the original message was received." -- Stefano