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

[Ted Lemon <[e-mail]>]

To be clear, I wasn't arguing that the IETF shouldn't define an API. I was
pointing out that the IETF hasn't defined an API, and the market has moved
on from the sockets API. It's perfectly possible to build a good
asynchronous API on top of sockets, and I suspect many of us have done it
at least once (I certainly have).

What we were talking about was a slightly different thing, though:
getaddrinfo() as defined in the POSIX world is synchronous and doesn't have
a way to specify a context for the lookup, so it handles multi-home
situations really poorly, just as an example. Fixing this requires an API
that's higher-level than the sockets API anyway. If we want to describe
that API, I think that's fine, but historically we've gotten substantial
pushback when we've tried. We did actually at one point try to define an
MPvD API, but got a lot of pushback on it and never finished the work. It's
a pretty hard problem to do this well.

On Fri, Dec 2, 2022 at 2:36 PM Brian E Carpenter <
[e-mail]> wrote:

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