Re: [IPv6] communicating multiple link (status) to hosts

Philip Homburg <pch-ipv6-ietf-10@u-1.phicoh.com> Thu, 21 March 2024 13:25 UTC

Return-Path: <pch-b538D2F77@u-1.phicoh.com>
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 605D4C18DBA1 for <ipv6@ietfa.amsl.com>; Thu, 21 Mar 2024 06:25:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.906
X-Spam-Level:
X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 sr-_0sKCjMq1 for <ipv6@ietfa.amsl.com>; Thu, 21 Mar 2024 06:25:35 -0700 (PDT)
Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [45.83.6.19]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D2FCC15152B for <ipv6@ietf.org>; Thu, 21 Mar 2024 06:25:34 -0700 (PDT)
Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (TLS version=TLSv1.2 cipher=ECDHE-RSA-CHACHA20-POLY1305) (Smail #158) id m1rnIQF-0000M1C; Thu, 21 Mar 2024 14:25:31 +0100
Message-Id: <m1rnIQF-0000M1C@stereo.hq.phicoh.net>
To: ipv6@ietf.org
Cc: Michael Richardson <mcr+ietf@sandelman.ca>
From: Philip Homburg <pch-ipv6-ietf-10@u-1.phicoh.com>
Sender: pch-b538D2F77@u-1.phicoh.com
In-reply-to: Your message of "Thu, 21 Mar 2024 12:58:41 +1000 ." <186314.1710989921@dyas>
Date: Thu, 21 Mar 2024 14:25:30 +0100
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/2HvVzqsOhuagCUgB6f1R-zq4zZA>
Subject: Re: [IPv6] communicating multiple link (status) to hosts
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: Thu, 21 Mar 2024 13:25:36 -0000

>For networks which are more complex than a home network with a single LAN
>segment (no SNACk ) and two routers... how do hosts find out which egress
>routers are up/down/congested/etc.
>
>I think that this was one of the things which HOMENET failed to do.
>Yes, we could get some of this through routing protocols, but we were trying
>to keep hosts from having to speak those.
>
>It seems like it's new work.... or never quite completed old work.
>
>I don't think it's enough that prefixes can get withdrawn via an absense of
>the RA, and an absense of DHCPv6-PD renewal.  And many enterprises would
>probably like to do some numbering of networks via more static allocation
>rather than DHCPv6-PD. (Even I would prefer to do that at my home office)

Ignoring DHCPv6 for a bit, we basically have 2 signals: the priority of a
default router and the preferred/deprecated/invalid status of a prefix for
use in SLAAC.

If we assume that routers speak some kind of routing protocol, then the trick 
is how to translate the current routing state into RA announcements.

Assuming routers work properly and speak a common routing protocol, then 
default router selection is something that can be ignored because routers
can forward packets to each other and send redirect. We assume routers are
connected by a high speed link, so even if a host selects the wrong router, 
routers should have enough bandwidth to forward traffic to the right router.

So this mainly leaves the question of how to map routing state to prefixes that
can be used for SLAAC. Basically, routers have to answer the question for a
given prefix whether packets with a source address from that prefix can
find a good path to the internet. If the answer is no, then the prefix 
should be deprecated. And if the situation lasts longer than a typical 
route flap, made invalid.

We have RFCs the describe what hosts need to do that are very old. We have
routing protocols. The only thing that may be missing is a document that
decribes how to go from routing state to RA announcements. But that's not
rocket science.