IPv6 Extensions to RPC

Sumandra MajeeSun Microsystems Inc.smajee@eng.sun.com

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 <prog_number, version, protocol> ==> port number

- Newer version known as RPCBIND <prog_number, version, netid> ==> 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

- <prog_num, version, protocol> 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.

<prog_num, vers, netid> ==> universal address Universal address for Ipv6 based services 2::a8:a00:20ff:fe8c:0.23 - 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?