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

[Vasilenko Eduard <[e-mail]>]

Hi Philipp,

1. I still believe that simplified MHMP topology (1 link, 2 routers to different carriers) does not need source routing in principle.
2. DHCP-PD may be used potentially to distribute PA over the complex site. Just 1) it is not standardized, and 2) DHCP is not supported at all on the most popular OS. Hence, the solution for PA distribution over the site does not exist yet. Neither on products nor in standardization.
3. The world already opens the double number of sessions then drop half, thanks to HY. It is a considerable scalability issue for everything stateful (like FW, LB, IPS, etc).
In the MHMP environment, typically would be just 2 PIOs from different Carriers. We could ignore the cases for 3 PIOs and more (small probability).
It is possible to multiply sessions on the internet 2x more (to 4x?).
I do not have a clue about how effective the caching of this information is on the real OSes TCP/IP stack.
Maybe you are right: cashing could be very effective, and session tax could be as low as 1.05. I do not know.

Whatever you propose (including HY next generation) is in reality the function that should be substituted inside getaddrinfo() and RFC 6724 that is behind it. Even in the case if you would propose to replace getaddrinfo() with something else.
I have searched over all your URLs presented in this thread - I have not found a place where a discussion similar to RFC 6724 is going on.
Hence, I have not understood how you propose to replace RFC 6724/getaddrinfo().
"Use HYv3" may be a good idea, but it is difficult to evaluate without details.
Looking at RFC 6724, I am sure: it would be needed to specify many details. MHMP is complex.

Eduard
-----Original Message-----
From: Philipp S. Tiesel [mailto:[e-mail]] 
Sent: Friday, January 6, 2023 7:35 PM
To: Vasilenko Eduard <[e-mail]>
Cc: Brian E Carpenter <[e-mail]>; Michael Richardson <[e-mail]>; 6man <[e-mail]>
Subject: Re: [IPv6] Suggestion for multi homed clients without NAT/NPT



> On 6. Jan 2023, at 16:03, Vasilenko Eduard <[e-mail]> wrote:
> 
> Hi Philipp,
> I need to read the materials that you have supplied but some comments are already possible.
> 
> - Source-Dest-Routing incl. auto-configuration is a pre-requisite for 
> any  endpoint based multi-path or multi-homing solution…
> EV> Double "Nope".
> 1. Source routing is needed only if we have many routing hops on site.
> The simplified topology "Common LAN with 2 separate routers leading to different Carriers" does not need a source routing in principle.

Yes and no… there would be other means to keep multiple uplinks separate at the endpoints, but src-dst-routing is the only way that I am aware of that is
 a) implemented and
 b) works the same on end-hosts and intermediate routers.
Take a look at https://datatracker.ietf.org/doc/draft-ietf-rtgwg-dst-src-routing/ 
  
> 2. Multiple hops on site is not possible in principle yet.
> Because Carriers address space (PA) should be somehow distributed first.
> We do not have any mechanism to do it yet.

Combine src-dst-routing with DHCPv6 Prefix delegation and you have a solution that (with a few hops) works with different PA spaces per Uplink.


> - The Happy Eyeballs (on steroids) approach is one good way to make
>  use of multi-homing on connection establishment.
> EV> I need to read more because I do not understand how HY could help to MHMP.
> Do you propose to open a separate session for every possible <path*source_address> permutation?

I assume each path is represented by a unique prefix that
- provides src addresses for the hosts
- has src-dst-default-route on the routers on-site.

So a client can choose a path/uplink by choosing a src address.

> Search for fastest then drop all other sessions.
> I do not like brute force approach.

That is a good question… in the end, just do HE with a small set of <src*dst> and 
cache the informations (latency, success rate) gathered from connection attempts.


> 
> Ed/
> -----Original Message-----
> From: ipv6 [mailto:[e-mail]] On Behalf Of Philipp S. Tiesel
> Sent: Friday, January 6, 2023 5:09 PM
> To: Brian E Carpenter <[e-mail]>
> Cc: Michael Richardson <[e-mail]>; 6man <[e-mail]>
> Subject: Re: [IPv6] Suggestion for multi homed clients without NAT/NPT
> 
> 
> 
>> On 6. Jan 2023, at 05:17, Brian E Carpenter <[e-mail]> wrote:
>> 
>> On 06-Jan-23 05:06, Michael Richardson wrote:
>>> 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.
>> 
>> From a very superficial dive into those drafts, it seems that there is 
>> no explicit discussion of *why* a transport entity might have several 
>> addresses and how their usage interacts with routing (starting with 
>> choice of default router). I guess TAPS would say that's out of scope, 
>> but I also guess that 6MAN and V6OPS would need convincing that the 
>> TAPS approach will solve our problems.
> 
> Okay… I guess we need to carefully sort things here:
> 
> - Source-Dest-Routing incl. auto-configuration is a pre-requisite for any
>  endpoint based multi-path or multi-homing solution…
> - The Happy Eyeballs (on steroids) approach is one good way to make
>  use of multi-homing on connection establishment.
> - TAPS is an abstract API/architecture that is (among other things) targeted
>  at making Happy Eyeballs (on steroids) seamless for the application and
>  the default for connection establishment
> 
> So all of the above can sum-up to one possible solution.
> 
>> Just saying we'll aggressively use happy eyeballs reminds me of the 
>> practical issues of using SHIM6, which amounts to a different kind of 
>> happy eyeballs. Neither will work unless the site supports source 
>> routing, to put it simply.
> 
> That is true, but sadly not really implemented and active on all major platforms.
> - I just verified that MacOS does it by default,
> - Linux can do it, but last time I checked fails to auto-configure it.
> - I haven’t tried Windows on that recently 
> 
>> 
>> See https://datatracker.ietf.org/doc/html/draft-naderi-ipv6-probing-01
>> 
>>> 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.
> 
> PvDs allow you to decide whether two networks a host is hooked up to are “the same network”, e.g., Wifi and wired access to the same corporate network, and to get some properties about like “It’s a corporate VPN for the following domains”
> or “It’s an expensive cellular fallback”.
> 
> While RA preferences allow our to select one/multiple same-weight defaults, PvDs can give you semantic information that is useful in a network policy.
> In the end, PvDs are useless without an TAPS-like API/architecture that smartly couples name resolution and source+destination address selection.
> 
> So, why do we need to separate DNS replies on a per-PvD basis?
> - Some host names might not be resolvable in public DNS
> - Some dst-addresses are not reachable from every part of the Internet.
>  Especially for CDNs, thats’ fine – I really should not try to use a
>  CDN cache within ISP A from a source served by ISP B.
> 
>>>> 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().
>> 
>> We all agree on that, I think (and also see the discussion on ULA 
>> usability). But the Internet runs on getaddrinfo() and we can't expect 
>> that to change for many years, even if TAPS is a brilliant success.
>> 
>> So Eduard's question remains for the time being: how do we achieve 
>> appropriate source and destination address selection with only the 
>> socket API to help us?
> 
> The answer is depressing: Not at all for the majority off applications.
> Stuck with the BSD socket API and it’s resolver library, there is no way of linking DNS-replies to default-routes/PvDs. 
> 
> There may be one exception: Given the amount of DNS and networking code in modern Web browsers (incl. their own DNS stack), these might be able to make some use of source and destination address selection based on the insight gained from their own internal DNS resolver.
> Once the application has somehow managed to do source and destination address selection and given we have source-dest-routing working, s=socket(); bind(s, src); connect(s, dst); is sufficient.  
> 
> This is a really hard cross-silo problem ;-)
> 
>> 
>>  Brian
>> 
>>>> 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/