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

[Stefano Brivio <sbrivio@redhat.com>]

On Fri, 10 Jul 2026 17:58:33 -0400
Jon Maloy <jmaloy@redhat.com> 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 <jmaloy@redhat.com>
> Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
> 
> ---
> 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