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

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

Hi,

> On 6. Jan 2023, at 16:43, Vasilenko Eduard <[e-mail]> wrote:
> 
> PvD has no value for 1)ND, 2)source routing,
> That may be needed in a multihoming environment.

We don’t need 2) when we follow RFC 8028
I am not sure why you need 1)

> But PvD has a value for 3) DNS,
> If RDNSS is received from the same router in a situation where it may have a different context (different PIOs).
> 
> Strictly speaking, all 3 solutions are needed for a complete multihoming package.

Agreed!

> 
> I am not aware of any PvD alternative on how to inform from the same router that "this DNS is for this PIO, but that DNS is for a different PIO".
> 
> PS: if the host is receiving different RDNSSes (with respective PIOs) from different routers then PvD is not needed.
> 
> Eduard
> -----Original Message-----
> From: ipv6 [mailto:[e-mail]] On Behalf Of Michael Richardson
> Sent: Thursday, January 5, 2023 7:07 PM
> To: Philipp S. Tiesel <[e-mail]>; 6man <[e-mail]>
> Subject: Re: [IPv6] Suggestion for multi homed clients without NAT/NPT
> 
> 
> Philipp S. Tiesel <[e-mail]> wrote:
>> I did my Ph.D. on that topic and called it Happy Eyeballs on Steroids.
> 
>> Most results went into the TAPS WG… maybe have a look at
>> - https://datatracker.ietf.org/doc/draft-ietf-taps-arch/
>> - https://datatracker.ietf.org/doc/draft-ietf-taps-interface/
>> - https://datatracker.ietf.org/doc/draft-ietf-taps-impl/
> 
> Very cool.  I will read them. I didn't know TAPS was doing this, and I suspect that few in 6man know either.  Maybe a 5 minute presentation is in order.
> 
> Philipp S. Tiesel <[e-mail]> wrote:
>> 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.
> 
> Do your IDs explain why?
> 
>> 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'm surprised to hear this.  I'm not convinced that PvD are a good idea, I think that they represent IPv4 thinking, and I think that there are better ways to do this in IPv6.  So I'm curious to understand how they are connected.
> 
>> 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
> 
> Thank you. I agree that it can't be done properly in getaddrinfo().
> 
>> 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.
> 
> Is there a FAQ on how to play with this code?
> 
> 
> --
> Michael Richardson <[e-mail]>   . o O ( IPv6 IøT consulting )
>           Sandelman Software Works Inc, Ottawa and Worldwide
> 
> 
> 
> 

--  
Philipp S. Tiesel
https://philipp.tiesel.net/