Re: [PATCH v7 01/13] dhcpv6: Fix reply destination to match client's source address

[Stefano Brivio <sbrivio@redhat.com>]

On Thu, 14 May 2026 15:21:57 +1000
David Gibson <david@gibson.dropbear.id.au> wrote:

> On Sun, Apr 12, 2026 at 08:53:07PM -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.  
> 
> I think there might have been more callers of tap_ip6_daddr() in the
> past, which might have made this not true.
> 
> > 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.  
> 
> Responding to the same address the client used is a good idea in
> general.  However, for this specific case, I don't think it will quite
> do what we want.  The problem is that we're still always using
> our_tap_ll (link local) as the source address.  So if the client used
> a global address we'll send a packet with mismatched address scopes.
> AFAIU that won't usually work.

At least for TCP on Linux that actually works. I haven't tried DHCPv6.

Regardless of that, indeed, it doesn't look like a good idea, and we
shouldn't start doing that if we weren't doing it before.

-- 
Stefano