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

["Philipp S. Tiesel" <[e-mail]>]

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.

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/