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

On 02-Dec-22 08:20, Michael Richardson wrote:
> 
> Vasilenko Eduard <vasilenko.eduard=40huawei.com@dmarc.ietf.org> wrote:
>      > If the application would use getaddrinfo(), Then the host would still
>      > try to choose the next-hop initially (RFC6724) in a random manner (ND
>      > section 6.3.6).  If the wrong physical or virtual router is chosen then
>      > rule 5.5 RFC 6724 would restrict PIOs applicably (the wrong PIO would
>      > be chosen too).  As a result, the packet would try to access the
>      > "walled garden" from the wrong address pace, it would be dropped.
> 
> I think that the bug is getaddrinfo().
> I think that we need a higher-level API that asks for a socket to a name.

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.

But Eduard also said

> Source address should be chosen by application internal logic.

I do not expect application programmers to be able to solve this
problem, and it isn't *internal* logic anyway - the knowledge to make
the best choice is likely cached elsewhere... by the daemon.

    Brian
> 
> That should result in some IPC to a daemon that knows stuff (like the current
> happy-eyeballs state), and stuff like PvD, and which user is allowed to
> run up bills for which ISP. (For "user" you can now understand "container",
> or "app"...).  The daemon would return one (or maybe more.. for QUIC) sockets.
> 
> The problem is finding someone to do this new work, and to manage to get it
> into major operating systems.  Google has done 80% of this work for Android,
> as I understand it.
> 
>      > I do not see how PvD is helping MHMP at all.  Because multiplying
>      > routers number on the link is not a solution when the host is not
>      > capable to choose which one to use.  The host would still have chances
> 
> I agree.
> 
> I've long thought that PvD is an IPv4 answer to a problem created by
> incompetent marketing people.   There are smarter IPv6 answers, which can
> result in even better marketing options for differentiated levels of service.
> 
> --
> ]               Never tell me the odds!                 | ipv6 mesh networks [
> ]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
> ]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [
> 
> 
> 
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------