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

[Vasilenko Eduard <[e-mail]>]

> I think that the bug is getaddrinfo().

If you said "A" then you should say "B".
This behavior of getaddrinfo() is fully compliant with RFC6724.
If getaddrinfo() is wrong, then RFC 6724 is wrong too.

I do not believe that it is possible to fix RFC6724 without reverting the order of choices: the packet should be constructed first (source address chosen) before the routing decision would be made (next hop choice).
But it is a different story.
In this thread, I am just claiming that multiplying the number of routers on the link (PvD) is not a solution when the host has a problem choosing properly.

Ed/
-----Original Message-----
From: Michael Richardson [mailto:[e-mail]] 
Sent: Thursday, December 1, 2022 10:21 PM
To: [e-mail]
Cc: Vasilenko Eduard <[e-mail]>
Subject: Re: [IPv6] PvD (RFC 8801) is not relevant to MHMP


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    [