Re: [IPv6] Suggestion for multi homed clients without NAT/NPT

[Klaus Frank <[e-mail]>]

On 05.01.2023 14:20, Philipp S. Tiesel wrote:
> Hi.
>
>
>> On 4. Jan 2023, at 11:17, Vasilenko Eduard <vasilenko.eduard=[e-mail]> wrote:
>>
>> Hi Michael,
>> Opposite.
>> The solution is not needed for a server. The server typically uses bind() then RFC 8028 fixed the problem (for the bind() use case it proposes "choose next-hop only among routers that advertise the respective PIO").
>> The solution is needed for clients because clients typically use getaddrinfo() which is broken in MHMP (in full compliance with RFC 6724).
> I am convinced RFC 8028 would also be a great start for clients with multiple default routes, e.g., enabling stuff like multi-path TCP to work correctly, but it will not be sufficient for meaningful multi-homing / source address selection.
>
> In addition, to avoiding problems with CDNs, it is also  required to separately keep track of DNS on a per-router/PvD basis and only use the matching source addresses for new connections, so RDNSS should also be treated analog to the source address in RFC 8028.

I think we can neglect DNS, there are enough people running their own 
resolvers (or use a random public one) and it doesn't cause a loss of 
connectivity. Also even if complex, someone is able to fix it with 
little resources right now without additional standards (at least for 
the active-passive fallback scenario). Have two internal dns resolvers 
(the one on the CPE) and one that is advertised with higher priority 
that just forwards queries to these without caching (caching would be 
done by the ones in the CPE).

This way even if kinda hacky one could have a DNS server for each 
uplink. However most would just deploy an internal recursive resolver or 
just have both CPEs advertise their DNS servers and use both without 
worrying about the suboptimal choices for some CDNs.

> Having tried to manage traffic from within getaddrinfo() I can only recommend to abandon that idea.
> A lengthly write-up why can be found here in Section 6 of this expired draft: https://datatracker.ietf.org/doc/html/draft-tiesel-taps-socketintents-bsdsockets-02
>
> The only way forward I see is something like TAPS and Appel’s implementation is already pretty close what it would needs to make use of multi-homing here. They just need a litte more aggressive/opportunistic happy eyeball candidate selection.
>
> AVE!
>     Philipp
>
>
> AVE!
>     Philipp S. Tiesel
>
> --
> Philipp S. Tiesel
> https://philipp.tiesel.net/
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------