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

[Michael Richardson <[e-mail]>]

Vasilenko Eduard <vasilenko.eduard=[e-mail]> 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.

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   [
]     [e-mail]  http://www.sandelman.ca/        |   ruby on rails    [