kadmin, GSSRPC, and IPv6

[ghudson@MIT.EDU]

We ship a libgssrpc based on Sun's old ONC RPC code and use it in our
kadmin protocol.  The ONC RPC API is IPv4 specific in the following
respects:

  * clnttcp_create() and clntudp_create() accept struct sockaddr_in *
    addresses.

  * svc_getcaller() is a macro returning a pointer to a struct
    sockaddr_in * contained within the SVCXPRT structure.  (This has
    ABI as well as API implications.)

  * The SVCXPRT structure is exposed to the caller and contains struct
    sockaddr_in * fields for the remote and local address.  However,
    the structure is not caller-allocated and I believe is generally
    treated as opaque by RPC code.

  * get_myaddress() and bindresvport() use struct sockaddr_in *
    arguments.

The best long-term solution is to ship a TIRPC implementation,
probably based on OpenSolaris code.  However, I believe there is a
more minimal path to making kadmin work over IPv6 which would only
take a week or two of effort.  The idea would be to make GSSRPC apps
work over IPv6 provided that they:

  * Create their own sockets.  We do this for the kadmin server
    already, and could do so on the client.  This also implies not
    using the portmapper.

  * Don't call svc_getcaller(), get_myaddress(), or bindresvport().
    (We already don't use any of those in kadmin.)

Does that seem sane?  For the server, my plan is to create separate
IPv4 and IPv6 listener sockets, but if I run into trouble with having
two RPC listeners, I might fall back to relying on dual-stack support
as we currently do in kpropd.