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

[Brian E Carpenter <[e-mail]>]

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. 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.

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.
> 
>      > 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?

    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