From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from ms.lwn.net (ms.lwn.net [45.79.88.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 2E8973612DB; Tue, 14 Jul 2026 13:01:14 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=45.79.88.28 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784034077; cv=none; b=mxOLyjkTZodjzf5lQfEmmSAkTmFSuzfLXx38bUjbzdwct0Xf67jeMpgNDemtUvXKYmi6MJzPjy1xd+Jl1VjjyWjDTCUcecMDitj8bQE1czQCFPso+Y/s6ODtEGiIx1v7TRwPqI3YDmMsxy6XU9IK4bzWwT17lyA1HMS3AW4GJnU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784034077; c=relaxed/simple; bh=7CeV2JqxygSEcV7QVYtBYJkoFG8rn1xPd64XyHQGA9g=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=M532kVrTeyogswW3xuOpqqnoVi4qwYSW8G//M3vAnLsNO6OpcHKVZhgqZr4ApO9y7FPy61I477ptYUIH4+FhSPRxEmgXTYg4ZXxxeRdEx2apr0+Z8uG+XMoRBm5skF0BaKblxj6R1ecwSPLhKe0rlS4ioWqtGuBgYKB7cA4Ly7g= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=lwn.net; spf=pass smtp.mailfrom=lwn.net; dkim=pass (2048-bit key) header.d=lwn.net header.i=@lwn.net header.b=rZ/lK5jD; arc=none smtp.client-ip=45.79.88.28 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=lwn.net Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=lwn.net Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=lwn.net header.i=@lwn.net header.b="rZ/lK5jD" DKIM-Filter: OpenDKIM Filter v2.11.0 ms.lwn.net 3C6D3410E2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lwn.net; s=20201203; t=1784034074; bh=N7EMk0B6AUtZUiM/QA5lBMqbPP1I3abAcQ9/YZ6+Tzk=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=rZ/lK5jDFFbj57Sl/24gU1iFuYlaluvoVZ5Ug1idxSk24WOPCmZ88zIRW5f+YEzVX OzhkNgXiPh9OlddACJ4HW/nAE0hrweCLvZ3Br47g8RTMD/2YI7NWfraTs/0jrI5bfA wxL1aA/kuV0bUH9ibIbKx8O5AkiBKjJbp6cqIqHf+4LNGJdlv4surZ7bloLjRvWGDB gXaXax69FImiTwDeRIWMhBVy8YdBnFw7wCtTCrrj/dpLNvTlQrRPsZ3LTIwCxxYc0E X363mMGut+t5vLTp43fHZdEuLl9FLOjoLmIz4ZpDAr5I/3Uz8a9+z0JZRgQeW/b/we S28cEuHBv0YFQ== Received: from localhost (unknown [IPv6:2601:280:4600:27b::1fe]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (prime256v1) server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by ms.lwn.net (Postfix) with ESMTPSA id 3C6D3410E2; Tue, 14 Jul 2026 13:01:14 +0000 (UTC) From: Jonathan Corbet To: David 'equinox' Lamparter , Paolo Abeni , Jakub Kicinski , Ido Schimmel Cc: David Ahern , "David S. Miller" , Eric Dumazet , Simon Horman , Shuah Khan , Fernando Fernandez Mancera , Lorenzo Colitti , Maciej =?utf-8?Q?=C5=BBenczykowski?= , Patrick Rohr , netdev@vger.kernel.org, linux-doc@vger.kernel.org, linux-kselftest@vger.kernel.org, David 'equinox' Lamparter Subject: Re: [PATCH net-next 9/9] net: document RFC6724 rule 5.5 implementation In-Reply-To: <20260714094030.136317-10-equinox@diac24.net> References: <20260714094030.136317-1-equinox@diac24.net> <20260714094030.136317-10-equinox@diac24.net> Date: Tue, 14 Jul 2026 07:01:13 -0600 Message-ID: <87zeztg1ye.fsf@trenco.lwn.net> Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain David 'equinox' Lamparter writes: > RFC6724 rule 5.5 is anything but obvious, especially if trying to do it > well. (RFC8028 and its errata kinda proves the point.) > > This documents what exactly the Linux kernel does for RFC6724 rule 5.5, > especially what the routing table needs to look like for it to work. > > Signed-off-by: David 'equinox' Lamparter > --- > Documentation/networking/ipv6-addrsel.rst | 75 +++++++++++++++++++++++ > MAINTAINERS | 1 + > 2 files changed, 76 insertions(+) > create mode 100644 Documentation/networking/ipv6-addrsel.rst You need to add this new document to the index.rst file or it won't be part of the docs build...you should have seen a warning when you built the docs. > diff --git a/Documentation/networking/ipv6-addrsel.rst b/Documentation/networking/ipv6-addrsel.rst > new file mode 100644 > index 000000000000..bed032e69570 > --- /dev/null > +++ b/Documentation/networking/ipv6-addrsel.rst > @@ -0,0 +1,75 @@ > +.. SPDX-License-Identifier: GPL-2.0 > + > +==================================== > +IPv6 source address selection trivia > +==================================== > + > + > +RFC6724 rule 5.5 support > +------------------------ Please stick with the section markup guidelines in Documentation/doc-guide/sphinx.rst. > +RFC6724 rule 5.5 is a very short paragraph in a complex RFC that has turned > +out quite tricky, but also immensely useful in multihoming scenarios. For > +reference, it says: > + > +:: You'll likely get more visually pleasing results if you just leave out the "::" here; you don't need literal formatting. > + Rule 5.5: Prefer addresses in a prefix advertised by the next-hop. > + If SA or SA's prefix is assigned by the selected next-hop that will > + be used to send to D and SB or SB's prefix is assigned by a different > + next-hop, then prefer SA. Similarly, if SB or SB's prefix is > + assigned by the next-hop that will be used to send to D and SA or > + SA's prefix is assigned by a different next-hop, then prefer SB. > + > +The way this works on Linux is as follows: > + > +- prior to any source address selection happening, when receiving a RA, more > + than the installation of a default route (or ::/128 route) needs to happen: > + for each PIO, a source-specific (subtree) route is *additionally* installed. > + The effect of this is that *after* a source address has been selected, one > + of the routers that advertised it will remain in use (this is *not* RFC 6724 > + related, but rather RFC 8028.) At the same time, these extra routes serve > + to remember which router advertised what. > + > +- per usual, a route lookup for the IPv6 destination address in consideration > + is done first. This is passed around in kernel as a dst_entry. > + > +- the source address selection code iterates through the various rules in > + RFC 6724. > + > +- if/when rule 5.5 is reached, first of all, there is a check if *any* source > + specific routes exist in the routing table. If there are none, the entire > + code for 5.5 is skipped because it cannot have any effect, but is not free > + to execute (can involve multiple routing lookups.) **In applications that > + use a lot of unbound (e.g. UDP) sockets, installing subtree routes should > + therefore be avoided to not incur this cost on each source address selection > + pass.** Alternatively, applications should bind their sockets to a specific > + source address such that the selection code is never hit. > + > +- if subtree routes do exist, the source address selection code now repeats > + the routing lookup done before source address selection is entered, except > + with the source address under consideration filled in. This lookup will hit > + the subtree routes that were installed (see first item), giving a fresh > + dst_entry. If the new dst_entry matches the original dst_entry, that means > + the original router has in fact sent RAs with PIOs for this source address, > + so it is preferred. Otherwise it is not. > + > + > +There are a few caveats to consider: > + > +- the kernel currently does not create the subtree routes mentioned in the > + first item. This is a separate work item, partially done at the time of > + writing this. But this can equally well be performed in userspace processing > + of RAs, e.g. NetworkManager or plain static configuration. > + > +- since addresses can also be acquired from DHCPv6, even RA/PIO combinations > + that didn't result in the creation of any addresses (e.g. A=0) should have > + subtree routes added. Those routes *may* be relevant for DHCPv6-generated > + addresses. > + > +- the "announce check" lookup does not backtrack. Only the destination prefix > + that provided the "unspecific" (::/128) match is checked for source prefixes > + to see what routers advertised what. This means that for e.g. RIOs, subtree > + routes also have to be created. (Backtracking for this case would further > + increase the cost of source address selection, for a pretty rare situation > + that has an easy fix/workaround.) > diff --git a/MAINTAINERS b/MAINTAINERS > index f3218abefd0c..4edf48362a07 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -18912,6 +18912,7 @@ F: Documentation/netlink/specs/rt-addr.yaml > F: Documentation/netlink/specs/rt-neigh.yaml > F: Documentation/netlink/specs/rt-route.yaml > F: Documentation/netlink/specs/rt-rule.yaml > +F: Documentation/networking/ipv6-addrsel.rst It seems weird to add this one file here - I wonder why there isn't just an entry for Documentation/networking ? Thanks, jon