I have been looking into v6ifying the RPC library. Looking at "prior"
art (like the Inria code), and previously published comments on this,
the consensus seems to be that there should be no interface change,
and backwards compatibility whereever possible.

The most authorative document on this (a pre-ietf draft I got from
its author) does indeed stress this, and does not change the
interface. This is fine, except for one thing: for svctcp_create
and svcudp_create, you can specify RPC_ANYSOCK, leaving it up
to the library to create the socket. No address family identifier
is specified.

Now, the pre-draft says that the library should, to be compatible,
just create a v6 socket, which will listen to v4 traffic using
mapped v4 addresses. However, as was discussed at the end of last year,
people don't like receiving v4 traffic on v6 sockets, and it is now
switched off by default in NetBSD (but can be switched on globally
via a sysctl, or per-socket via a sockopt).

What to do here? The easy way out is to make the RPC library switch
off BINDV6ONLY, but that does not seem like a solution that we want.
svc*_create could also create a v6 socket, but this is not backward
compatible, and we'd have to version the calls, and go through
the all of our RPC-using sources to check if it uses RPC_ANYSOCK.
There's also the possibility of extending the interface of
svc*_create to include the address family, renaming the call. But
if we adopt that approach, we'd better make sure that this is included
in the standard.

In other words, I'd like to reach a consensus about what we want
to do for NetBSD. If it doesn't match the current draft standard,
we'll have to push for it to be included. I did already inform
the author of this problem.

- Frank