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

The whole idea of prefix lifetimes is to avoid flash renumbering. It sounds
like you're proposing to standardize flash renumbering.

Is there existing practice about having hosts choose routers based on which
is most congested? This isn't something I've heard of.

On Thu, Mar 21, 2024 at 12:59 PM Michael Richardson <mcr+ietf@sandelman.ca>
wrote:

>
> {trying to start a new thread}
>
> Lorenzo Colitti <lorenzo=40google.com@dmarc.ietf.org> wrote:
>     > And that's bad. The network does not have the capability to leverage
>     > multiple paths by using multipath protocols. Only the hosts do.
>
>     > Hiding multihoming from the hosts using NPTv6 will prevent hosts from
>     > leveraging these protocols to improve bandwidth and resilience.
>
>     > While MPTCP is difficult to deploy due to middleboxes, MP-QUIC does
> not
>     > have this problem, and interest in MP-QUIC is building. Even without
>     > MP-QUIC, even today QUIC already supports client-initiated session
>     > migration. That can be leveraged to maintain existing connections
> alive
>     > when one of the uplinks fails - the client can just migrate the
>     > connection to a new source address which will use a new uplink. If we
>     > hide the uplinks from the client using NPTv6, we cannot do that.
>
> 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)
>
> --
> Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
>  -= IPv6 IoT consulting =-                      *I*LIKE*TRAINS*
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>