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

[David Gibson <david@gibson.dropbear.id.au>]

[-- Attachment #1: Type: text/plain, Size: 2856 bytes --]

On Sat, Jun 20, 2026 at 12:11:42AM +0200, Stefano Brivio wrote:
> 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.

Yeah.. I haven't really managed to get my head around what works and
what doesn't when mixing scopes.  It seems unsafe to send from a
link-local to a global address unless you know the owner of that
global address is on the same link as you.  Linux will (at least
sometimes) know this from the routing table, but of course such a
packet could never be routed.

A similar rule applies in theory for site-local => global, except that
the sending host has no obvious way of knowing if the destination
address is at the same site.  This may well be one of the reasons that
site-local unicast was deprecated.

In the other direction, I guess you can accept packets that come from
a global address to a *-local address - and even reply to them - on
the grounds that they couldn't have reached you if the peer wasn't in
the same link/site/whatever.

I suppose, then, you could make the argument that actually you *can*
send from a *-local address to a global address on the grounds that if
it's not on the same link, an intervening router will either drop it
or NAT it for you.  I think that seems to be the assumption used for
IPv4 link-local addresses, at least; or they'd be near useless.

> 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
> 

-- 
David Gibson (he or they)	| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you, not the other way
				| around.
http://www.ozlabs.org/~dgibson

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]