On Thu, 14 May 2026 15:21:57 +1000
David Gibson
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