IPv6 Extensions to RPC Sumandra Majee Sun Microsystems Inc.

Design Considerations Backward compatibility for both source and binary No function prototype change RPC selects IPv6 transparently

RPC Overview " Client side - Contact the portmapper/rpcbind of the remote server to get the port # or the universal address for a particular RPC program. Often this step is preceded by a call to name lookup service. - Send RPC request using the port #/ universal address from above to the remote server. " Server side -Contact portmapper/rpcbind to register the service which allocates a port number. - Bind to the port and listen for incoming request. Service the request upon receipt.

ONC+ RPC Two different RPC Implementation • TI(Transport Independent) RPC • TS(socket based) RPC, popular choice

IPv6 Issues With RPC Transport selection, IPv6 or IPv4? RPC address lookup and registration service TS-RPC is affected by larger space requirement of IPv6 socket.

Transport selection in TI-RPC Two new netids for UDP/IPv6(udp6) and TCP/IPv6(tcp6). The order determines which transport will be picked up first -udp6 tpi_clts v inet6 udp /dev/udp6 - -tcp6 tpi_cots_ord v inet6 tcp /dev/tcp6 -

Transport selection in TS-RPC — Uses name lookup routine, getipnodebyname() to get IPv6 address first. Falls back to IPv4. - Existing binaries are unable to select IPv6. TI-RPC nicely provides that.

RPC address Lookup and Registration — RPC uses a well known service to resolve remote RPC server's port number and address. - Early version known as PORTMAPPER ==> port number - Newer version known as RPCBIND ==> universal address(ua) ua -> addr.porthi.portlo

Issues with PORTMAPPER Widely used. Commonly used by TS-RPC implementation. - Can't distinguish between IPv6 and IPv4 - protocol - {UDP, TCP}

Solving PORTMAPPER problem Most clients still first use UDP to contact PORTMAPPER. - Server Side, Restrict both IPv6 and IPv4 based service to use same port. Easy. - IPv6 enabled client side probes remote portmapper with NULL RPC request. Then probe the remote RPC server. - UDP based requests should get ICMP port unreachable indication( not guaranteed). Use this as a hint to fall back on IPv4. - RPC library provides this mechanism

Using RPCBIND ˜ This is the preferred service to use. Don't have to implement full TI-RPC, implement RPCBIND. – ==> universal address – Universal address for Ipv6 based services — 2::a8:a00:20ff:fe8c: port #23 – The right way is to use RPCBIND, failing that use PORTMAPPER

New Control Options Client side control - Get/Set Traffic class and Flow label clnt_control(clnt_handle, CLSET_TAFFIC_CLASS, info) A set of well defined traffic class is desirable. Presently this the application gets the server address from client handle and stuffs it back with traffic class and flow label info Server side control(?) - No such thing at present - Can be used for server side control e.g bandwidth allocation etc. Need to be looked into.

RPC API TI-RPC API is not exposed to sockaddr_in6 - However library is exposed to transport specific address in many places. TS-RPC API is exposed to socket address in some cases - clntudp_create(struct sockaddr_in *sockp,....) - Determine the socket type by looking at sin_family - if (sockp == RPC_ANYSOCK) then choose AF_INET6 type socket. Use mapped address for IPv4 only server.

TS-RPC API contd. Server side API change - svcudp_create(int sock_fd,...) OR svctcp_create(). - if (sock_fd == RPC_ANYSOCK) then create an IPv6 socket with appropriate address.

Summary Use RPCBIND at least. Questions? Comments?