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

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.

Op vr 2 dec. 2022 om 01:34 schreef Vasilenko Eduard <vasilenko.eduard=
40huawei.com@dmarc.ietf.org>

> 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:ipv6-bounces@ietf.org] On Behalf Of Michael Richardson
> Sent: Thursday, December 1, 2022 11:02 PM
> To: Brian E Carpenter <brian.e.carpenter@gmail.com>; ipv6@ietf.org
> Subject: Re: [IPv6] PvD (RFC 8801) is not relevant to MHMP
>
>
> Brian E Carpenter <brian.e.carpenter@gmail.com> 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 <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT consulting )
>            Sandelman Software Works Inc, Ottawa and Worldwide
>
>
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>