Re: [IPv6] What should a rule 5.5 implementation actually do?

David 'equinox' Lamparter <equinox@diac24.net> Mon, 20 November 2023 11:38 UTC

Return-Path: <equinox@diac24.net>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD388C151531 for <ipv6@ietfa.amsl.com>; Mon, 20 Nov 2023 03:38:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.909
X-Spam-Level:
X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id of_8eeD8dUvJ for <ipv6@ietfa.amsl.com>; Mon, 20 Nov 2023 03:37:56 -0800 (PST)
Received: from eidolon.nox.tf (eidolon.nox.tf [IPv6:2a07:2ec0:2185::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48056C14CE30 for <ipv6@ietf.org>; Mon, 20 Nov 2023 03:37:51 -0800 (PST)
Received: from equinox by eidolon.nox.tf with local (Exim 4.96.1) (envelope-from <equinox@diac24.net>) id 1r52b3-0041cE-2W; Mon, 20 Nov 2023 12:37:46 +0100
Date: Mon, 20 Nov 2023 12:37:45 +0100
From: David 'equinox' Lamparter <equinox@diac24.net>
To: Lorenzo Colitti <lorenzo@google.com>
Cc: IETF IPv6 Mailing List <ipv6@ietf.org>, Maciej Żenczykowski <maze@google.com>, Tommy Jensen <Jensen.Thomas@microsoft.com>, Ted Lemon <elemon@apple.com>, Jen Linkova <furry@google.com>
Message-ID: <ZVtFCS2VaWBaip1q@eidolon.nox.tf>
References: <CAKD1Yr0n+xhWdT021So_0ofFAosNe0L1284KSw=5YRnebRhOdA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CAKD1Yr0n+xhWdT021So_0ofFAosNe0L1284KSw=5YRnebRhOdA@mail.gmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/jBoZCTHDV--NI-ZZSSsKQg5uLec>
Subject: Re: [IPv6] What should a rule 5.5 implementation actually do?
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 20 Nov 2023 11:38:00 -0000

On Mon, Nov 20, 2023 at 09:07:15AM +0900, Lorenzo Colitti wrote:
[quote shortened]
> The harder part is to ensure packets of that flow continue to go
> through the gateway that serves the prefix in the future. And worse, it's
> not clear whether networks can even rely on hosts to do this.

Sigh.

Yes, purely working off 5.5, after the source address is selected (and
maybe the first packet is sent), anything goes...

> And what happens if Ra goes away? Should the flow be terminated with
> an error? Should it start using Rb? What happens if another router
> appears? And so on.

My approach would be:  all of this is a preference, nothing is
terminated if "its" router(s) goes away, and if the preference becomes
inapplicable just fall back to picking any random viable router.

> It's possible to implement all this using src/dst routing, but that's
> a fair bit of work,

(Linux-specific) As long as the kernel manages the routes, it's actually
fairly simple; just *additionally* install a dst-src route for each PIO
with (S=PIO, D=default) with the same timer as the regular default
route.

The uncontrolled growth of network management tools on Linux that
believe they know better than the kernel and take over this function is
its own problem :(

(Also, what to do with RIO non-default routes is a separate question.)

> +Jen Linkova <furry@google.com> we have a few RFCs based on this behaviour
> already. Do you know what they require the host to do? If a host only
> supports 5.5 for address selection but doesn't keep flows "sticky" to the
> gateway they started with, will they work?

FWIW route selection should be deterministic for a given source +
destination tuple (L3 or L4), which is likely what makes this work in
99% of real-world use cases...  or so I would hope.


-equi (David)