From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: passt.top; dmarc=none (p=none dis=none) header.from=gibson.dropbear.id.au Authentication-Results: passt.top; dkim=pass (2048-bit key; secure) header.d=gibson.dropbear.id.au header.i=@gibson.dropbear.id.au header.a=rsa-sha256 header.s=202606 header.b=ox0UzeZD; dkim-atps=neutral Received: from mail.ozlabs.org (gandalf.ozlabs.org [150.107.74.76]) by passt.top (Postfix) with ESMTPS id 9C08A5A0269 for ; Mon, 22 Jun 2026 05:39:15 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gibson.dropbear.id.au; s=202606; t=1782099552; bh=+ku5fCbMazLeAN03yfE4ykVJel8wYEOGZtAOhUlfUTg=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=ox0UzeZDEQKjDRdM0q3lGdN2+TYWOoPNAh5ZT4Xm1/8cUJUOwkdZhWcDTqyTsAtF6 4dr6JRziGuBtyuwKIEyX1D3MsA7wl+uFUa1czz0Tkj1A4kltgk2GCsgSUCEiTHz5Z+ LJVAIl5+BDJeVrwhrpSixkDmJpiY4K3802KrF2v+wMhSLxBqCssLpEf7ljYYfZA9va X8COAeJ2l2AbgKFCTbAHAePLV8rWVSVQo/btZsS5XlhqJ1NnqPHg6FCloQ37LXYW0J PDKbarbMP8vq1oh0+Ssy60ZECAckiSFXTWTTjsv/kd53xF8ybzLAIkQ3uOYmMEXCRc lFFPOAcim+wSQ== Received: by gandalf.ozlabs.org (Postfix, from userid 1007) id 4gkDTD4zPLz4wSx; Mon, 22 Jun 2026 13:39:12 +1000 (AEST) Date: Mon, 22 Jun 2026 13:39:01 +1000 From: David Gibson To: Stefano Brivio Subject: Re: [PATCH v7 01/13] dhcpv6: Fix reply destination to match client's source address Message-ID: References: <20260413005319.3295910-1-jmaloy@redhat.com> <20260413005319.3295910-2-jmaloy@redhat.com> <20260620001142.0d838714@elisabeth> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="O/Dfg8GIAOQiAH2n" Content-Disposition: inline In-Reply-To: <20260620001142.0d838714@elisabeth> Message-ID-Hash: ONS4YXQCFCA6UA4N3LWRXO534WVAXM5V X-Message-ID-Hash: ONS4YXQCFCA6UA4N3LWRXO534WVAXM5V X-MailFrom: dgibson@gandalf.ozlabs.org X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: Jon Maloy , passt-dev@passt.top X-Mailman-Version: 3.3.8 Precedence: list List-Id: Development discussion and patches for passt Archived-At: Archived-At: List-Archive: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --O/Dfg8GIAOQiAH2n Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Jun 20, 2026 at 12:11:42AM +0200, Stefano Brivio wrote: > On Thu, 14 May 2026 15:21:57 +1000 > David Gibson wrote: >=20 > > 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. =20 > >=20 > > I think there might have been more callers of tap_ip6_daddr() in the > > past, which might have made this not true. > >=20 > > > 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. =20 > >=20 > > 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. >=20 > 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 =3D> 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. >=20 > --=20 > Stefano >=20 --=20 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 --O/Dfg8GIAOQiAH2n Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEO+dNsU4E3yXUXRK2zQJF27ox2GcFAmo4rkoACgkQzQJF27ox 2Geb/w//dZ/MOhr61rZce8w85uGEJvrRWPE5mQbqg3LC4MK4yMmRmXRjdrE1REqA ED7Np7XLsqyYS0rGTL1OJbujoxo5QJhqa2mECpdeYa8CT9EQ9xRzZMLYq0cEH8AA ip4VgxqliShwRPaSJT2OOMWTMp7fa5Lh9n8AzBCoy+tmExvlSz1g5yLLjUTqjXab AthkzFWC2taI8fuDRTqBdgr7iMgjsBOGROVipUr97/Jrn7FmJPF5/vegrn7RhE/u OlXjoN7UopgqdOSXFsCewKoE/WRqANH6EwyV6i5lwEtcDseAqLmgMyFK/V60fEDr rNFulTs9F/BgfZqrA0FvBqxWF6qXy6SdaOUHGKuplcOI3h/FIEA999b6vFE7azcq 78EPjNrbls1tQz/tyltTsVVzqtKomMNgQq7t1DG8oo73g72+amN2B3fEurxHp6YE DMB7yJJSlHbEIE6LErJLjD2SveIKEUQqffLO76FkZy/2z/QRH9JJO6q/EBzPGkBx xz+uLWQEvCg35VDHh2HgljZSHgJJ0N8hoI8OSZ3NN4F+v53qizCkNoKi/JFm4TXG CgHIFuih/e/JfwYNzf4TAWGJjPnqotYCvyweaXyNEUIyAtpcWnPqES/6PtV5mz8G /7eCjPbmAkauj5fXZvCl5MReVV9J6/e9Mc1GM3vCuhFyLMKBccM= =0AjB -----END PGP SIGNATURE----- --O/Dfg8GIAOQiAH2n--