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

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

> 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


AVE!
   Philipp S. Tiesel

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