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

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

> On 7. Jan 2023, at 11:54, Vasilenko Eduard <[e-mail]> wrote:
> 
> The application could use:
> 1) bind() to choose the source address first then it should have a complex logic comparable to RFC 6724 or use human intelligence (for a manual source address appointment). It is typically used by servers.
> 2) getaddrinfo() that would choose the next hop first (construct the packet later). It is typically used by clients

No, getaddrinfo() has no means to choose the first hop or communicate that choice back.
Which mechanism do you assume is used to pass that the first-hop choice?  

What could be implemented for 2) is some sort of getaddrinfo2() that also returns a src 
address along with each dst candidate. 
When doing that, this src address choice also has to obey RFC6724.
As next step, we use RFC 8028 to choose the first hop and src-dst-routing to reach the right uplink (the one that fits the src).

Be aware: I want to do src-dst-routing as defined in https://datatracker.ietf.org/doc/draft-ietf-rtgwg-dst-src-routing/, not any kind of header based client chosen src-routing! 

> RFC 8028 stated in the abstract that it assumes source address choice first. If you read it carefully, you would see that it follows this assumption throughout the whole text. RFC 8028 is just not relevant to the second case (when the next hop is chosen first).
> RFC 8028 is important because it fixes the case for bind().
> 
> But the second case (getaddrinfo()) is the more popular in the wild.
> The exercise to fix MHMP is primarily related to the attempt to fix RFC 6724/getaddrinfo() and maybe ND itself (RFC 4861). 

I really prefer to realise both cases the same way, otherwise the slightest inconsistency in routing / ND breaks everything.

> In general, RFC 6724 is redundant because it is a "local decision".
> I hear already that "vendor X already abandoned getaddrinfo()/RFC 6724 - they use their proprietary logic - lets everybody do the same".
> It is effectively a mild request to deprecate RFC 6724.
> Well, it is possible. I am not sure that it is the right way in such a complex matter (to cut the number of people discussing it).

It is not as these implementations still obey RFC6724 – they just combine the functionality of getaddrinfo (with a per-pvd/default-route and happy eyeballs. 

AVE!
  Philipp

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

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