[15914] in Kerberos_V5_Development
kadmin, GSSRPC, and IPv6
daemon@ATHENA.MIT.EDU (ghudson@mit.edu)
Wed Jun 23 07:30:09 2010
Date: Wed, 23 Jun 2010 07:30:03 -0400 (EDT)
From: ghudson@mit.edu
Message-Id: <201006231130.o5NBU3No020549@outgoing.mit.edu>
To: krbdev@mit.edu
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@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.
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
