doc: Add RFC documents

1 files changed, 787 insertions, 0 deletions

diff --git a/doc/rfc/rfc1833.txt b/doc/rfc/rfc1833.txt
new file mode 100644
index 0000000..b2cc274
--- /dev/null
+++ b/doc/rfc/rfc1833.txt
@@ -0,0 +1,787 @@
+
+
+
+
+
+
+Network Working Group                                      R. Srinivasan
+Request for Comments: 1833                              Sun Microsystems
+Category: Standards Track                                    August 1995
+
+
+                Binding Protocols for ONC RPC Version 2
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+ABSTRACT
+
+   This document describes the binding protocols used in conjunction
+   with the ONC Remote Procedure Call (ONC RPC Version 2) protocols.
+
+TABLE OF CONTENTS
+
+   1. Introduction                                               1
+   2. RPCBIND Program Protocol                                   2
+   2.1 RPCBIND Protocol Specification (in RPC Language)          3
+   2.2 RPCBIND Operation                                         9
+   2.2.1 RPCBIND Version 3                                       9
+   2.2.2 RPCBIND, Version 4                                     10
+   3. Port Mapper Program Protocol                              11
+   3.1 Port Mapper Protocol Specification (in RPC Language)     11
+   3.2 Port Mapper Operation                                    13
+   References                                                   14
+   Security Considerations                                      14
+   Author's Address                                             14
+
+1. Introduction
+
+   This document specifies the binding protocols used in conjunction
+   with ONC RPC Version 2.  As a prerequisite, the reader is expected to
+   be familiar with [1] and [2] which describe the ONC RPC Version 2 and
+   XDR (eXternal Data Representation) protocols.
+
+   An RPC service is identified by its RPC program number, version
+   number, and the transport address where it may be reached.  The
+   transport address, in turn, consists of a network address and a
+   transport selector.  In the case of a service available over TCP/IP
+   or UDP/IP, the network address will be an IP address, and the
+   transport selector will be a TCP or UDP port number.
+
+
+
+Srinivasan                  Standards Track                     [Page 1]
+
+RFC 1833        Binding Protocols for ONC RPC Version 2      August 1995
+
+
+   A client program needs to know the RPC program number, version
+   number, and the transport address corresponding to a service in order
+   to utilize the service.  Of these, the RPC program number and version
+   number are usually built into the client program, as part of the
+   service definition.  The network address component of the transport
+   address is usually available in a name service, or is given as a
+   parameter to the client program.  The transport selector (ie., the
+   TCP or UDP port) is usually determined dynamically, and varies with
+   each invocation of the service.  Server programs allocate a transport
+   address, and register it with a well-known lookup service (well-known
+   because it uses a fixed transport selector, and resides at the same
+   network address as the server).  Client programs consult the lookup
+   service in order to obtain the server's transport address.
+
+   Such a lookup service is very desirable because the range of well-
+   known transport selectors is very small for some transports and the
+   number of services is potentially very large.  By running only the
+   lookup service on a well-known transport selector, the transport
+   addresses of other remote programs can be ascertained by querying the
+   lookup service.
+
+   This document describes three versions of a lookup service, all of
+   which use the same RPC program number (100000).  They all use port
+   111 over TCP and UDP transports.  Versions 3 and 4 are described in
+   Section 2 ("RPCBIND Program Protocol").  Version 2 is described in
+   Section 3 ("Port Mapper Program Protocol").
+
+   The distinguishing characteristic of RPCBIND (versions 3 and 4) is
+   that this protocol uses a transport-independent format for the
+   transport address, known as the universal address format.  An address
+   in universal address format is an ASCII string representation of the
+   transport dependent address.  String representation of addresses
+   corresponding to a transport are defined by the addressing authority
+   for the transport.  The RPCBIND protocol can be used for binding ONC
+   RPC clients and servers over any transport.
+
+   The Port Mapper (version 2), on the other hand, is an older protocol
+   that is specific to TCP and UDP.  It handles TCP and UDP ports
+   directly.
+
+2. RPCBIND Program Protocol
+
+   The RPCBIND program maps RPC program and version numbers to universal
+   addresses, thus making dynamic binding of remote programs possible.
+
+   The RPCBIND program is bound to a well-known address of each
+   supported transport, and other programs register their dynamically
+   allocated transport address with it.  The RPCBIND program then makes
+
+
+
+Srinivasan                  Standards Track                     [Page 2]
+
+RFC 1833        Binding Protocols for ONC RPC Version 2      August 1995
+
+
+   those addresses publicly available.
+
+   The RPCBIND program also aids in broadcast RPC.  A given RPC program
+   will usually have different transport address bindings on different
+   machines, so there is no way to directly broadcast to all of these
+   programs. The RPCBIND program, however, does have a well-known
+   address.  So, to broadcast to a given program, the client actually
+   sends its message to the RPCBIND program located at the broadcast
+   address. Each instance of the RPCBIND program that picks up the
+   broadcast then calls the local service specified by the client.  When
+   the RPCBIND program gets the reply from the local service, it sends
+   the reply back to the client.
+
+2.1 RPCBIND Protocol Specification (in RPC Language)
+
+/*
+ * rpcb_prot.x
+ * rpcbind protocol, versions 3 and 4, in RPC Language
+ */
+
+/*
+ * rpcbind address for TCP/UDP
+ */
+const RPCB_PORT = 111;
+
+/*
+ * A mapping of (program, version, network ID) to address
+ *
+ * The network identifier  (r_netid):
+ * This is a string that represents a local identification for a
+ * network. This is defined by a system administrator based on local
+ * conventions, and cannot be depended on to have the same value on
+ * every system.
+ */
+struct rpcb {
+ unsigned long r_prog;    /* program number */
+ unsigned long r_vers;    /* version number */
+ string r_netid<>;        /* network id */
+ string r_addr<>;         /* universal address */
+ string r_owner<>;        /* owner of this service */
+};
+
+struct rp__list {
+ rpcb rpcb_map;
+ struct rp__list *rpcb_next;
+};
+
+
+
+
+
+Srinivasan                  Standards Track                     [Page 3]
+
+RFC 1833        Binding Protocols for ONC RPC Version 2      August 1995
+
+
+typedef rp__list *rpcblist_ptr;        /* results of RPCBPROC_DUMP */
+
+
+/*
+ * Arguments of remote calls
+ */
+struct rpcb_rmtcallargs {
+ unsigned long prog;        /* program number */
+ unsigned long vers;        /* version number */
+ unsigned long proc;        /* procedure number */
+ opaque args<>;             /* argument */
+};
+
+
+/*
+ * Results of the remote call
+ */
+struct rpcb_rmtcallres {
+ string addr<>;            /* remote universal address */
+ opaque results<>;         /* result */
+};
+
+
+/*
+ * rpcb_entry contains a merged address of a service on a particular
+ * transport, plus associated netconfig information.  A list of
+ * rpcb_entry items is returned by RPCBPROC_GETADDRLIST.  The meanings
+ * and values used for the r_nc_* fields are given below.
+ *
+ * The network identifier  (r_nc_netid):
+
+ *   This is a string that represents a local identification for a
+ *   network.  This is defined by a system administrator based on
+ *   local conventions, and cannot be depended on to have the same
+ *   value on every system.
+ *
+ * Transport semantics (r_nc_semantics):
+ *  This represents the type of transport, and has the following values:
+ *     NC_TPI_CLTS     (1)      Connectionless
+ *     NC_TPI_COTS     (2)      Connection oriented
+ *     NC_TPI_COTS_ORD (3)      Connection oriented with graceful close
+ *     NC_TPI_RAW      (4)      Raw transport
+ *
+ * Protocol family (r_nc_protofmly):
+ *   This identifies the family to which the protocol belongs.  The
+ *   following values are defined:
+ *     NC_NOPROTOFMLY   "-"
+ *     NC_LOOPBACK      "loopback"
+
+
+
+Srinivasan                  Standards Track                     [Page 4]
+
+RFC 1833        Binding Protocols for ONC RPC Version 2      August 1995
+
+
+ *     NC_INET          "inet"
+ *     NC_IMPLINK       "implink"
+ *     NC_PUP           "pup"
+ *     NC_CHAOS         "chaos"
+ *     NC_NS            "ns"
+ *     NC_NBS           "nbs"
+ *     NC_ECMA          "ecma"
+ *     NC_DATAKIT       "datakit"
+ *     NC_CCITT         "ccitt"
+ *     NC_SNA           "sna"
+ *     NC_DECNET        "decnet"
+ *     NC_DLI           "dli"
+ *     NC_LAT           "lat"
+ *     NC_HYLINK        "hylink"
+ *     NC_APPLETALK     "appletalk"
+ *     NC_NIT           "nit"
+ *     NC_IEEE802       "ieee802"
+ *     NC_OSI           "osi"
+ *     NC_X25           "x25"
+ *     NC_OSINET        "osinet"
+ *     NC_GOSIP         "gosip"
+ *
+ * Protocol name (r_nc_proto):
+ *   This identifies a protocol within a family.  The following are
+ *   currently defined:
+ *      NC_NOPROTO      "-"
+ *      NC_TCP          "tcp"
+ *      NC_UDP          "udp"
+ *      NC_ICMP         "icmp"
+ */
+struct rpcb_entry {
+ string          r_maddr<>;            /* merged address of service */
+ string          r_nc_netid<>;         /* netid field */
+ unsigned long   r_nc_semantics;       /* semantics of transport */
+ string          r_nc_protofmly<>;     /* protocol family */
+ string          r_nc_proto<>;         /* protocol name */
+};
+
+/*
+ * A list of addresses supported by a service.
+ */
+struct rpcb_entry_list {
+ rpcb_entry rpcb_entry_map;
+ struct rpcb_entry_list *rpcb_entry_next;
+};
+
+typedef rpcb_entry_list *rpcb_entry_list_ptr;
+
+
+
+
+Srinivasan                  Standards Track                     [Page 5]
+
+RFC 1833        Binding Protocols for ONC RPC Version 2      August 1995
+
+
+/*
+ * rpcbind statistics
+ */
+
+const rpcb_highproc_2 = RPCBPROC_CALLIT;
+const rpcb_highproc_3 = RPCBPROC_TADDR2UADDR;
+const rpcb_highproc_4 = RPCBPROC_GETSTAT;
+
+const RPCBSTAT_HIGHPROC = 13; /* # of procs in rpcbind V4 plus one */
+const RPCBVERS_STAT     = 3; /* provide only for rpcbind V2, V3 and V4 */
+const RPCBVERS_4_STAT   = 2;
+const RPCBVERS_3_STAT   = 1;
+const RPCBVERS_2_STAT   = 0;
+
+/* Link list of all the stats about getport and getaddr */
+struct rpcbs_addrlist {
+ unsigned long prog;
+ unsigned long vers;
+ int success;
+ int failure;
+ string netid<>;
+ struct rpcbs_addrlist *next;
+};
+
+/* Link list of all the stats about rmtcall */
+struct rpcbs_rmtcalllist {
+ unsigned long prog;
+ unsigned long vers;
+ unsigned long proc;
+ int success;
+ int failure;
+ int indirect;    /* whether callit or indirect */
+ string netid<>;
+ struct rpcbs_rmtcalllist *next;
+};
+
+typedef int rpcbs_proc[RPCBSTAT_HIGHPROC];
+typedef rpcbs_addrlist *rpcbs_addrlist_ptr;
+typedef rpcbs_rmtcalllist *rpcbs_rmtcalllist_ptr;
+
+struct rpcb_stat {
+ rpcbs_proc              info;
+ int                     setinfo;
+ int                     unsetinfo;
+ rpcbs_addrlist_ptr      addrinfo;
+ rpcbs_rmtcalllist_ptr   rmtinfo;
+};
+
+
+
+
+Srinivasan                  Standards Track                     [Page 6]
+
+RFC 1833        Binding Protocols for ONC RPC Version 2      August 1995
+
+
+/*
+ * One rpcb_stat structure is returned for each version of rpcbind
+ * being monitored.
+ */
+
+typedef rpcb_stat rpcb_stat_byvers[RPCBVERS_STAT];
+
+/*
+ * netbuf structure, used to store the transport specific form of
+ * a universal transport address.
+ */
+struct netbuf {
+ unsigned int maxlen;
+ opaque buf<>;
+};
+
+
+/*
+ * rpcbind procedures
+ */
+program RPCBPROG {
+ version RPCBVERS {
+     bool
+     RPCBPROC_SET(rpcb) = 1;
+
+     bool
+     RPCBPROC_UNSET(rpcb) = 2;
+
+     string
+     RPCBPROC_GETADDR(rpcb) = 3;
+
+     rpcblist_ptr
+     RPCBPROC_DUMP(void) = 4;
+
+     rpcb_rmtcallres
+     RPCBPROC_CALLIT(rpcb_rmtcallargs) = 5;
+
+     unsigned int
+     RPCBPROC_GETTIME(void) = 6;
+
+     netbuf
+     RPCBPROC_UADDR2TADDR(string) = 7;
+
+     string
+     RPCBPROC_TADDR2UADDR(netbuf) = 8;
+ } = 3;
+
+
+
+
+
+Srinivasan                  Standards Track                     [Page 7]
+
+RFC 1833        Binding Protocols for ONC RPC Version 2      August 1995
+
+
+ version RPCBVERS4 {
+     bool
+     RPCBPROC_SET(rpcb) = 1;
+
+     bool
+     RPCBPROC_UNSET(rpcb) = 2;
+
+     string
+     RPCBPROC_GETADDR(rpcb) = 3;
+
+     rpcblist_ptr
+     RPCBPROC_DUMP(void) = 4;
+
+     /*
+      * NOTE: RPCBPROC_BCAST has the same functionality as CALLIT;
+      * the new name is intended to indicate that this
+      * procedure should be used for broadcast RPC, and
+      * RPCBPROC_INDIRECT should be used for indirect calls.
+      */
+     rpcb_rmtcallres
+     RPCBPROC_BCAST(rpcb_rmtcallargs) = RPCBPROC_CALLIT;
+
+     unsigned int
+
+     RPCBPROC_GETTIME(void) = 6;
+
+     netbuf
+     RPCBPROC_UADDR2TADDR(string) = 7;
+
+     string
+     RPCBPROC_TADDR2UADDR(netbuf) = 8;
+
+     string
+     RPCBPROC_GETVERSADDR(rpcb) = 9;
+
+     rpcb_rmtcallres
+     RPCBPROC_INDIRECT(rpcb_rmtcallargs) = 10;
+
+     rpcb_entry_list_ptr
+     RPCBPROC_GETADDRLIST(rpcb) = 11;
+
+     rpcb_stat_byvers
+     RPCBPROC_GETSTAT(void) = 12;
+ } = 4;
+} = 100000;
+
+
+
+
+
+
+Srinivasan                  Standards Track                     [Page 8]
+
+RFC 1833        Binding Protocols for ONC RPC Version 2      August 1995
+
+
+2.2 RPCBIND Operation
+
+   RPCBIND is contacted by way of an assigned address specific to the
+   transport being used.  For TCP/IP and UDP/IP, for example, it is port
+   number 111.  Each transport has such an assigned, well-known address.
+   The following is a description of each of the procedures supported by
+   RPCBIND.
+
+2.2.1 RPCBIND Version 3
+
+   RPCBPROC_SET:
+
+   When a program first becomes available on a machine, it registers
+   itself with RPCBIND running on the same machine.  The program passes
+   its program number "r_prog", version number "r_vers", network
+   identifier "r_netid", universal address "r_addr", and the owner of
+   the service "r_owner".  The procedure returns a boolean response
+   whose value is TRUE if the procedure successfully established the
+   mapping and FALSE otherwise.  The procedure refuses to establish a
+   mapping if one already exists for the ordered set ("r_prog",
+   "r_vers", "r_netid").  Note that neither "r_netid" nor "r_addr" can
+   be NULL, and that "r_netid" should be a valid network identifier on
+   the machine making the call.
+
+   RPCBPROC_UNSET:
+
+   When a program becomes unavailable, it should unregister itself with
+   the RPCBIND program on the same machine.  The parameters and results
+   have meanings identical to those of RPCBPROC_SET.  The mapping of the
+   ("r_prog", "r_vers", "r_netid") tuple with "r_addr" is deleted.  If
+   "r_netid" is NULL, all mappings specified by the ordered set
+   ("r_prog", "r_vers", *) and the corresponding universal addresses are
+   deleted.  Only the owner of the service or the super-user is allowed
+   to unset a service.
+
+   RPCBPROC_GETADDR:
+
+   Given a program number "r_prog", version number "r_vers", and network
+   identifier  "r_netid", this procedure returns the universal address
+   on which the program is awaiting call requests.  The "r_netid" field
+   of the argument is ignored and the "r_netid" is inferred from the
+   network identifier of the transport on which the request came in.
+
+   RPCBPROC_DUMP:
+
+   This procedure lists all entries in RPCBIND's database.  The
+   procedure takes no parameters and returns a list of program, version,
+   network identifier, and universal addresses.
+
+
+
+Srinivasan                  Standards Track                     [Page 9]
+
+RFC 1833        Binding Protocols for ONC RPC Version 2      August 1995
+
+
+   RPCBPROC_CALLIT:
+
+   This procedure allows a caller to call another remote procedure on
+   the same machine without knowing the remote procedure's universal
+   address.  It is intended for supporting broadcasts to arbitrary
+   remote programs via RPCBIND's universal address.  The parameters
+   "prog", "vers", "proc", and args are the program number, version
+   number, procedure number, and parameters of the remote procedure.
+
+   Note - This procedure only sends a response if the procedure was
+   successfully executed and is silent (no response) otherwise.
+
+   The procedure returns the remote program's universal address, and the
+   results of the remote procedure.
+
+   RPCBPROC_GETTIME:
+
+   This procedure returns the local time on its own machine in seconds
+   since the midnight of the First day of January, 1970.
+
+   RPCBPROC_UADDR2TADDR:
+
+   This procedure converts universal addresses to transport specific
+   addresses.
+
+   RPCBPROC_TADDR2UADDR:
+
+   This procedure converts transport specific addresses to universal
+   addresses.
+
+2.2.2 RPCBIND, Version 4
+
+   Version 4 of the RPCBIND protocol includes all of the above
+   procedures, and adds several additional ones.
+
+   RPCBPROC_BCAST:
+
+   This procedure is identical to the version 3 RPCBPROC_CALLIT
+   procedure.  The new name indicates that the procedure should be used
+   for broadcast RPCs only.  RPCBPROC_INDIRECT, defined below, should be
+   used for indirect RPC calls.
+
+   RPCBPROC_GETVERSADDR:
+
+   This procedure is similar to RPCBPROC_GETADDR.  The difference is the
+   "r_vers" field of the rpcb structure can be used to specify the
+   version of interest.  If that version is not registered, no address
+   is returned.
+
+
+
+Srinivasan                  Standards Track                    [Page 10]
+
+RFC 1833        Binding Protocols for ONC RPC Version 2      August 1995
+
+
+   RPCBPROC_INDIRECT:
+
+   Similar to RPCBPROC_CALLIT.  Instead of being silent about errors
+   (such as the program not being registered on the system), this
+   procedure returns an indication of the error.  This procedure should
+   not be used for broadcast RPC. It is intended to be used with
+   indirect RPC calls only.
+
+   RPCBPROC_GETADDRLIST:
+
+   This procedure returns a list of addresses for the given rpcb entry.
+   The client may be able use the results to determine alternate
+   transports that it can use to communicate with the server.
+
+   RPCBPROC_GETSTAT:
+
+   This procedure returns statistics on the activity of the RPCBIND
+   server.  The information lists the number and kind of requests the
+   server has received.
+
+   Note - All procedures except RPCBPROC_SET and RPCBPROC_UNSET can be
+   called by clients running on a machine other than a machine on which
+   RPCBIND is running.  RPCBIND only accepts RPCBPROC_SET and
+   RPCBPROC_UNSET requests by clients running on the same machine as the
+   RPCBIND program.
+
+3. Port Mapper Program Protocol
+
+   The port mapper program maps RPC program and version numbers to
+   transport- specific port numbers.  This program makes dynamic binding
+   of remote programs possible.  The port mapper protocol differs from
+   the newer RPCBIND protocols in that it is transport specific in its
+   address handling.
+
+3.1 Port Mapper Protocol Specification (in RPC Language)
+
+      const PMAP_PORT = 111;      /* portmapper port number */
+
+   A mapping of (program, version, protocol) to port number:
+
+      struct mapping {
+         unsigned int prog;
+         unsigned int vers;
+         unsigned int prot;
+         unsigned int port;
+      };
+
+
+
+
+
+Srinivasan                  Standards Track                    [Page 11]
+
+RFC 1833        Binding Protocols for ONC RPC Version 2      August 1995
+
+
+   Supported values for the "prot" field:
+
+      const IPPROTO_TCP = 6;      /* protocol number for TCP/IP */
+      const IPPROTO_UDP = 17;     /* protocol number for UDP/IP */
+
+   A list of mappings:
+
+      struct *pmaplist {
+         mapping map;
+         pmaplist next;
+      };
+
+   Arguments to callit:
+
+      struct call_args {
+         unsigned int prog;
+         unsigned int vers;
+         unsigned int proc;
+         opaque args<>;
+      };
+
+   Results of callit:
+
+      struct call_result {
+         unsigned int port;
+         opaque res<>;
+      };
+
+   Port mapper procedures:
+
+      program PMAP_PROG {
+         version PMAP_VERS {
+            void
+            PMAPPROC_NULL(void)         = 0;
+
+            bool
+            PMAPPROC_SET(mapping)       = 1;
+
+            bool
+            PMAPPROC_UNSET(mapping)     = 2;
+
+            unsigned int
+            PMAPPROC_GETPORT(mapping)   = 3;
+
+            pmaplist
+            PMAPPROC_DUMP(void)         = 4;
+
+            call_result
+
+
+
+Srinivasan                  Standards Track                    [Page 12]
+
+RFC 1833        Binding Protocols for ONC RPC Version 2      August 1995
+
+
+            PMAPPROC_CALLIT(call_args)  = 5;
+         } = 2;
+      } = 100000;
+
+3.2 Port Mapper Operation
+
+   The portmapper program currently supports two protocols (UDP and
+   TCP).  The portmapper is contacted by talking to it on assigned port
+   number 111 (SUNRPC) on either of these protocols.
+
+   The following is a description of each of the portmapper procedures:
+
+   PMAPPROC_NULL:
+
+   This procedure does no work.  By convention, procedure zero of any
+   protocol takes no parameters and returns no results.
+
+   PMAPPROC_SET:
+
+   When a program first becomes available on a machine, it registers
+   itself with the port mapper program on the same machine.  The program
+   passes its program number "prog", version number "vers", transport
+   protocol number "prot", and the port "port" on which it awaits
+   service request.  The procedure returns a boolean reply whose value
+   is "TRUE" if the procedure successfully established the mapping and
+   "FALSE" otherwise.  The procedure refuses to establish a mapping if
+   one already exists for the tuple "(prog, vers, prot)".
+
+   PMAPPROC_UNSET:
+
+   When a program becomes unavailable, it should unregister itself with
+   the port mapper program on the same machine.  The parameters and
+   results have meanings identical to those of "PMAPPROC_SET".  The
+   protocol and port number fields of the argument are ignored.
+
+   PMAPPROC_GETPORT:
+
+   Given a program number "prog", version number "vers", and transport
+   protocol number "prot", this procedure returns the port number on
+   which the program is awaiting call requests.  A port value of zeros
+   means the program has not been registered.  The "port" field of the
+   argument is ignored.
+
+   PMAPPROC_DUMP:
+
+   This procedure enumerates all entries in the port mapper's database.
+   The procedure takes no parameters and returns a list of program,
+   version, protocol, and port values.
+
+
+
+Srinivasan                  Standards Track                    [Page 13]
+
+RFC 1833        Binding Protocols for ONC RPC Version 2      August 1995
+
+
+   PMAPPROC_CALLIT:
+
+   This procedure allows a client to call another remote procedure on
+   the same machine without knowing the remote procedure's port number.
+   It is intended for supporting broadcasts to arbitrary remote programs
+   via the well-known port mapper's port.  The parameters "prog",
+   "vers", "proc", and the bytes of "args" are the program number,
+   version number, procedure number, and parameters of the remote
+   procedure.  Note:
+
+      (1) This procedure only sends a reply if the procedure was
+      successfully executed and is silent (no reply) otherwise.
+
+      (2) The port mapper communicates with the remote program using UDP
+      only.
+
+   The procedure returns the remote program's port number, and the reply
+   is the reply of the remote procedure.
+
+References
+
+   [1]  Srinivasan, R., "Remote Procedure Call Protocol Version 2",
+        RFC 1831, Sun Microsystems, Inc., August 1995.
+
+   [2]  Srinivasan, R., "XDR: External Data Representation Standard",
+        RFC 1832, Sun Microsystems, Inc., August 1995.
+
+Security Considerations
+
+   Security issues are not discussed in this memo.
+
+Author's Address
+
+   Raj Srinivasan
+   Sun Microsystems, Inc.
+   ONC Technologies
+   2550 Garcia Avenue
+   M/S MTV-5-40
+   Mountain View, CA  94043
+   USA
+
+   Phone: 415-336-2478
+   Fax:   415-336-6015
+   EMail: raj@eng.sun.com
+
+
+
+
+
+
+
+Srinivasan                  Standards Track                    [Page 14]
+