Re: [PATCH v9] dhcpv6: Fix reply destination to match client's source address

On Fri, 10 Jul 2026 17:58:33 -0400 Jon Maloy wrote:

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 9915 (section 18.3.10) allows clients to use global addresses for DHCPv6, we now correct this, and always respond to the address the client was using.

We also remove a redundant addr_ll_seen assignment, since this is already done by tap.c when processing IPv6 packets.

Note: if the client uses a global source address, our reply will still have a link-local source, creating a scope mismatch. Fixing this properly would require a mechanism to allocate a global address for the DHCPv6 server, which we currently don't have. Responding to the client's actual source address is still a net improvement over the previous behavior of replying to an unrelated cached address.

Note 2: This commit isn't actually a fix to an observed problem, but rather an answer to a theoretical issue, adding completeness to the mechanism and simplifying subsequent changes in this series.

Signed-off-by: Jon Maloy Reviewed-by: David Gibson

--- v8: -Updated commit log, acknowledging concerns expressed by David and Stefano. -Some minor changes also addressing feedback from the same persons. v9: -Broken out of multi-addr series and posted as standalone patch. No code changes.

Applied. -- Stefano