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

[Ted Lemon <[e-mail]>]

I think it's actually unrealistic to expect routers to forward packets to
each other in many of the settings we care about, e.g. home networks.
"Routing protocol in the home" is pretty much the hill that homenet died
on. Not because it's hard, but because it's hard to do automatically and
nobody wanted to agree on a single protocol (we did finally agree on Babel,
but tell me where I can buy a router with Babel in it?).

It's been said that it's unreasonable to expect hosts to correctly pick the
next-hop router. I don't think that's true. We know how to do it, and we
have a clear path to hosts actually doing it. There are a lot of hosts that
already do it. Unless we're proposing to forbid networks with more than one
router advertising an RA, hosts pretty much have to do it; the question is
only whether they do it well or badly.

On Apple devices we track reachability in the network API (Network
Framework). I won't say that this is trivially easy, but it's doable. We
really need to stop thinking of the sockets API as the state of the art in
how applications use the network. It's not. This seems hard if you are
using the sockets API. This is not a hard limitation on what is possible or
doable.

On Thu, Mar 21, 2024 at 11:25 PM Philip Homburg <
[e-mail]> wrote:

> >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.
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>