Re: [IPv6] PvD (RFC 8801) is not relevant to MHMP

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

Ted,
On 03-Dec-22 03:30, Ted Lemon wrote:
> The reality is that the APIs most developers are using are already asynchronous. This is not new. Eg Apple’s Network Framework, but also the various happy eyeballs implementations in browsers, and various system libraries not written in C. Writing new code now that uses synchronous getaddrinfo is just silly. Whether the IETF writes a new document or not is sort of irrelevant.

I don't think so. We aren't here to encourage the use of proprietary libraries, which work against code portability. It's still unclear to me that the Internet as whole benefits from our having handed over the socket API to POSIX, and I don't see how it benefits from ducking this question now.

How about trying to write down the desirable properties for an asynch replacement for getaddrinfo() ?

(Whatever people may sometimes say, there is no rule that "the IETF doesn't do APIs.")

     Brian

> 
> Op vr 2 dec. 2022 om 01:34 schreef Vasilenko Eduard <vasilenko.eduard=[e-mail] <mailto:[e-mail]>>
> 
>     What you are talking about is very powerful but the same disruptive. It would need a separate API that would be used with the current API for ages.
>     It is not RFC 6724bis. It is a completely new RFC for a separate API.
>     By the way, you have to choose the source address first anyway because if you would choose the next hop then you are restricted by the PIO announced by this router.
> 
>     What we have proposed in draft-vv-6man-nd-support-mhmp is much less disruptive.
>     Reverse choice: source address first only then next hop,
>     Then it is possible to use many simple mechanisms for source address choice (section 5):
> 
>     1.      The same policies could be formatted differently and fed to the host by two mechanisms at the same time: 1) “Routing Information Options” of [Route Preferences] and 2) [Policy by DHCP] to modify policies in [Default Address] selection algorithm. Then the current priority of mechanisms could be preserved the same: initially [ND] or routing would choose the next-hop, then [Default Address] would choose a proper source address. It is the method that is assumed in [MHMP]. This method is complicated and costly, and the probability of acceptance is very low. Moreover, [Policy by DHCP] was not adopted by the market – it is not available on the major operating systems and home gateways.
>     2.      Application developed may use bind() to choose a source address based on many different parameters (including anything from the list below). It would effectively revert the default logic of [Default Address]. Unfortunately, it is difficult to expect it from the client side, which would probably call getaddrinfo() which has a good probability to choose the wrong source address.
>     3.      Only policies could be supplied by [Policy by DHCP] to the [Default Address] selection algorithm. This method has a low probability of implementation because of not wide support of DHCPv6 in the industry. Maybe this method would have more acceptance in the future.
>     4.      It is possible to check the longest match between the source and the destination address to choose the potentially closest address. This method looks most promising, it is partially discussed in [Default Address] section 7.
>     5.      The host could use DNS requests with different source addresses to understand what is visible for a particular source address.
>     6.      URL for configuration information could be supplied in RA – see [Provisioning domains].
>     7.      The host may have local performance management capabilities (packet loss, delay, jitter, etc) to choose the best source for the application.
> 
>     Ed/
>     -----Original Message-----
>     From: ipv6 [mailto:[e-mail] <mailto:[e-mail]>] On Behalf Of Michael Richardson
>     Sent: Thursday, December 1, 2022 11:02 PM
>     To: Brian E Carpenter <[e-mail] <mailto:[e-mail]>>; [e-mail] <mailto:[e-mail]>
>     Subject: Re: [IPv6] PvD (RFC 8801) is not relevant to MHMP
> 
> 
>     Brian E Carpenter <[e-mail] <mailto:[e-mail]>> wrote:
>          > True, getaddrinfo() is a weak solution, but I think the weakness is not
>          > really in the "level". There's no reason that gai itself couldn't
>          > interrogate a daemon instead of a table.
> 
>     Yes, you are right.
> 
>     We certainly can do something smarter behind the scenes, and we can certainly put an synchronous getaddrinfo() on top of it.
> 
>     But, the problem is that it returns a single sockaddr(), and it needs to return something with the source address selected (for each destination), or
>     at least strongly hinted.   Returning a socket/file descriptor would be
>     better.  That also allows for things like PvD to be implemented as seperate network namespaces or VRFs.
> 
> 
>     --
>     Michael Richardson <[e-mail] <mailto:[e-mail]>>   . o O ( IPv6 IøT consulting )
>                 Sandelman Software Works Inc, Ottawa and Worldwide
> 
> 
> 
> 
>     --------------------------------------------------------------------
>     IETF IPv6 working group mailing list
>     [e-mail] <mailto:[e-mail]>
>     Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 <https://www.ietf.org/mailman/listinfo/ipv6>
>     --------------------------------------------------------------------
>