[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 RFC 3103

INTERNET DRAFT                                             M. Borella
Expires May 2000                                           D. Grabelsky
                                                           3Com Corp.

                                                           J. Lo
                                                           K. Tuniguchi
                                                           NEC USA

                                                           October 1999


               Realm Specific IP: Protocol Specification
                 <draft-ietf-nat-rsip-protocol-04.txt>

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

Abstract

   This document presents a protocol with which to implement Realm
   Specific IP (RSIP).  The protocol defined herein allows negotiation
   of resources between an RSIP client and server.  This protocol is
   designed to operate as an application and to use its own TCP or UDP
   port.  In particular, the protocol allows a server to allocate
   addressing and control parameters to a client such that a flow policy
   can be enforced at the server.

1.  Introduction

   Network Address Translation (NAT) has gained popularity as a method



Borella et al.              Expires May 2000                    [Page 1]

INTERNET-DRAFT  Realm Specific IP: Protocol Specification  November 1999


   of separating public and private address spaces, and alleviating
   network address shortages.  A NAT translates the addresses of packets
   leaving a first routing realm to an address from a second routing
   realm, and performs the reverse function for packets entering the
   first routing realm from the second routing realm.  This translation
   is performed transparently to the hosts in either space, and may
   include modification of TCP/UDP port numbers and IP addresses in
   packets that traverse the NAT.

   While a NAT does not require hosts to be aware of the translation, it
   will require an application layer gateway (ALG) for any protocol that
   transmits IP addresses or port numbers in packet payloads (such as
   FTP).  Additionally, a NAT will not work with protocols that require
   IP addresses and ports to remain unmodified between the source and
   destination hosts, or protocols that prevent such modifications to
   occur (such as some IPSEC modes, or application-layer end-to-end
   encryption).

   An alternative to a NAT is an architecture that allows the clients
   within the first (e.g., private) routing realm to directly use
   addresses and other routing parameters from the second (e.g., public)
   routing realm.  Thus, RSIP [RSIP-FRAME] has been defined a method for
   address sharing that exhibits more transparency than NAT.  In
   particular, RSIP requires that an RSIP server (a router or gateway
   between the two realms) assign at least one address from the second
   routing realm, and perhaps some other resources, to each RSIP client.
   An RSIP client is a host in the first routing realm that needs to
   establish end-to-end connectivity to a host, entity or device in the
   second routing realm. Thus, the second routing realm is not directly
   accessible from RSIP client, but this system allows packets to
   maintain their integrity from RSIP client to their destination.  ALGs
   are not required in the RSIP server.

   RSIP requires that hosts be modified so that they place some number
   of layer three, layer four or other values from those assigned by the
   RSIP server in each packet bound for the second routing realm.

   This draft discusses a method for assigning parameters to an RSIP
   client from an RSIP server.  The requirements, scope, and
   applicability of RSIP, as well as its interaction with other layer 3
   protocols, are discussed in a companion framework draft [RSIP-FRAME].
   RSIP interaction with IPSEC is discussed in [RSIP-IPSEC].

2.  Specification of Requirements

   The keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT",
   "SHALL", "SHALL NOT", "MAY" and "MAY NOT" that appear in this
   document are to be interpreted as described in [RFC2119].



Borella et al.              Expires May 2000                    [Page 2]

INTERNET-DRAFT  Realm Specific IP: Protocol Specification  November 1999


3.  Terminology

   Private Realm

      A routing realm that uses private IP addresses from the ranges
      (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) specified in
      [RFC1918], or addresses that are non-routable from the Internet.

   Public Realm

      A routing realm with unique network addresses assigned by the
      Internet Assigned Number Authority (IANA) or an equivalent address
      registry.

   RSIP Server

      A router situated on the boundary between a private realm and a
      public realm and owns one or more public IP addresses. An RSIP
      server is responsible for public parameter management and
      assignment to RSIP clients. An RSIP server may act as a normal NAT
      router for hosts within the private realm that are not RSIP
      enabled.

   RSIP Client

      A host within the private realm that acquires publicly unique
      parameters from an RSIP server through the use of RSIP.

   RSA-IP: Realm Specific Address IP

      An RSIP method in which each RSIP client is allocated a unique IP
      address from the public realm.  Discussed in detail in [RFC2663]

   RSAP-IP: Realm Specific Address and Port IP

      An RSIP method in which each RSIP client is allocated an IP
      address (possibly shared with other RSIP clients) and some number
      of per-address unique ports from the public realm.  Discussed in
      detail in [RFC2663]

   Binding

      An association of some combination of a local IP address, one or
      more local ports, a remote IP address, and a remote port with an
      RSIP client.

   All other terminology found in this document is consistent with that
   of [RFC2663] and [RSIP-FRAME].



Borella et al.              Expires May 2000                    [Page 3]

INTERNET-DRAFT  Realm Specific IP: Protocol Specification  November 1999


4.  Architecture

   For simplicity, for the remainder of this document we will assume
   that the RSIP clients in the first routing realm (network) use
   private (e.g. see [RFC1918]) IP addresses, and that the second
   routing realm (network) uses public IP addresses.  The RSIP server
   connects the public and private realms and contains interfaces to
   both.  Other NAT terminology found in this document is defined in
   [RFC2663].

   The diagram below describes an exemplary reference architecture for
   RSIP. Some number of RSIP clients are attached via a private network
   to an RSIP server, which also acts as a router or gateway between the
   private and public networks. This router has been assigned some
   number of public addresses that it may use or allocate for use on the
   public network.

   +-------------+
   | RSIP client |
   |       1     +--+
   |   10.0.0.2  |  |                 +-------------+
   +-------------+  |        10.0.0.1 |             |   149.112.240.0/24
                    +-----------------+ RSIP server +-------------------
   +-------------+  |                 |             |
   | RSIP client |  |                 +-------------+
   |       2     +--+     private                     public
   |   10.0.0.3  |  |     network                     network
   +-------------+  |
                    |
                    |                ...

5.  Transport Protocol

   RSIP is an application layer protocol that requires the use of a
   transport layer protocol for end-to-end delivery of packets.

   RSIP servers MUST support TCP, and SHOULD support UDP.  Due to the
   fact that RSIP may be deployed across a wide variety of network
   links, RSIP clients SHOULD support TCP.  However, RSIP clients MAY
   support UDP instead.  For RSIP clients and servers using UDP, timeout
   and retransmissions MUST occur.  We recommend a binary exponential
   backoff scheme with an initial duration of 12.5 ms, and a maximum of
   six retries (seven total attempts before failure).

   Once a client and server have established a registration using either
   TCP or UDP, they may not switch between the two protocols for the
   duration of the registration.




Borella et al.              Expires May 2000                    [Page 4]

INTERNET-DRAFT  Realm Specific IP: Protocol Specification  November 1999


6.  Client / Server Relationships

   An RSIP client can be in exactly one of three fundamental
   relationships with respect to an RSIP server:

      Unregistered: The RSIP server does not know of the RSIP client's
         existence, and it will not forward or deliver packets on behalf
         of the client.  The only valid RSIP-related action for a client
         to perform in this state is to request registration with an
         RSIP server.

      Registered: The RSIP server knows of the RSIP client and has
         assigned it a client ID and has specified the flow policies
         that it requires of the client.  However, no resources, such as
         addresses or ports, have been allocated to the client, and the
         server will not forward or deliver packets on behalf of the
         client.

      Assigned: The RSIP server has granted one or more bindings of
         resources to the client.  The server will forward and deliver
         packets on behalf of the client.

   Architectures in which an RSIP client is associated with more than
   one RSIP server are possible.  In such cases, an RSIP client may be
   simultaneously in different relationships with different RSIP
   servers.

7.  Server Flow Policy and State

   Since an RSIP server is likely to reside on the boundary between two
   or more different administrative domains, it is desirable to enable
   an RSIP server to be able to enforce flow-based policy.  In other
   words, an RSIP server should have the ability to explicitly control
   which local addresses and ports are used to communicate with remote
   addresses and ports.

   In the following, macro-flow policy refers to controlling flow policy
   at the granularity level of IP addresses, while micro-flow policy
   refers to controlling flow policy at the granularity of IP address
   and port tuples.  Of course there may be no policy at all, which
   indicates that the RSIP server does not care about the flow
   parameters used by RSIP clients. We consider two levels of local flow
   policy and three levels of remote flow policy.

   7.1.  Local Flow Policy

      Local flow policy determines the granularity of control that an
      RSIP server has over the addressing parameters that an RSIP client



Borella et al.              Expires May 2000                    [Page 5]

INTERNET-DRAFT  Realm Specific IP: Protocol Specification  November 1999


      uses for particular sessions.

      Since an RSIP client must use at least an IP address allocated by
      the server, the loosest level of local flow policy is macro-flow
      based.  Under local macro-flow policy, an RSIP client is allocated
      an IP address (RSA-IP) or an IP address and one or more ports to
      use with it (RSAP-IP).  However, the client may use the ports as
      it desires for establishing sessions with public hosts.

      Under micro-flow policy, a client is allocated exactly one port at
      a time.  The client may request more ports, also one at a time.
      This policy gives the server very tight control over local port
      use, although it affords the client less flexibility.

      Note that only local macro-flow policy can be used with RSA-IP,
      while either local macro-flow or local micro-flow policy may be
      used with RSAP-IP.

      Examples of how RSIP flow policy operates are given in Appendix C.

   7.2.  Remote Flow Policy

      Remote flow policy determines the granularity of control that an
      RSIP server has over the remote (public) hosts with which an RSIP
      client communicates.  In particular, remote flow policy dictates
      what level of detail that a client must specify addressing
      parameters of a remote host before the RSIP server allows the
      client to communicate with that host.

      The simplest and loosest form of flow policy is no policy at all.
      In other words, the RSIP server allocates addressing parameters to
      the client, and the client may use these parameters to communicate
      with any remote host, without specifically notifying the server.

      Macro-flow policy requires that the client identify the remote
      address of the host that it wishes to communicate with as part of
      its request for local addressing parameters.  If the request is
      granted, the client MUST use the specified local parameters only
      with the remote address specified, and MUST NOT communicate with
      the remote address using any local parameters but the ones
      allocated.  However, the client may contact any port number at the
      remote host without explicitly informing the server.

      Micro-flow policy requires that the client identify the remote
      address and port of the host that it wishes to communicate with as
      part of its request for local addressing parameters.  If the
      request is granted, the client MUST use the specified local
      parameters only with the remote address and port specified, and



Borella et al.              Expires May 2000                    [Page 6]

INTERNET-DRAFT  Realm Specific IP: Protocol Specification  November 1999


      MUST NOT communicate with the remote address and port using any
      local parameters but the ones allocated.

      Remote flow policy is implemented in both the ingress and egress
      directions, with respect to the location of the RSIP server.

  7.3.  Server State

      An RSIP server must maintain state for all RSIP clients and their
      assigned resources.  The amount and type of state maintained
      depends on the local and remote flow policy.  The required RSIP
      server state will vary based on the RSIP method, but will always
      include the chosen method's demultiplexing parameters.

      7.3.1.  RSA-IP State

         An RSIP server serving an RSIP client using the RSA-IP method
         MUST maintain the following minimum state to ensure proper
         mapping of incoming packets to RSIP clients:

            - Client's private address
            - Client's assigned public address(es)

      7.3.2.  RSAP-IP State

         An RSIP server serving an RSIP client using the RSAP-IP method
         MUST maintain the following minimum state to ensure proper
         mapping of incoming packets to RSIP clients:

         - Client's private address
         - Client's assigned public address(es)
         - Client's assigned port(s)

      7.3.3.  Flow State

         Regardless of whether the server is using RSA-IP or RSAP-IP,
         additional state is necessary if either micro-flow based or
         macro-flow based remote policy is used.

         If the server is using macro-flow based remote policy, the
         following state must be maintained:

            - Remote host's address

         If the server is using micro-flow based remote policy, the
         following state must be maintained:

            - Remote host's address



Borella et al.              Expires May 2000                    [Page 7]

INTERNET-DRAFT  Realm Specific IP: Protocol Specification  November 1999


            - Remote host's port

         More state MAY be used by an RSIP server if desired.  For
         example, ToS/DS bytes may be recorded in order to facilitate
         quality of service support.

8.  Parameter Specification and Formats

   In this section we define the formats for RSIP parameters.  Each RSIP
   message contains one or more parameters that encode the information
   passed between the client and server.  The general format of all
   parameters consists of a 1-byte code followed by a 2-byte length as
   shown below.

    1 byte   2 bytes  'Length' bytes
   +------+----------+--------------
   | Code |  Length  | ...
   +------+----------+--------------

   The length field determines the length, in bytes, of the rest of the
   parameter.

   8.1.  Address

         Code    Length    Type    Value
      +-------+---------+--------+--------+
      |   1   | 2 bytes | 1 byte | varies |
      +-------+---------+--------+--------+

      The address parameter contains addressing information, either an
      IPv4 address or netmask, an IPv6 address or netmask, or a fully
      qualified domain name (FQDN).  The type field is 1 byte in length,
      indicating the type of address.

      Defined types are:

                 Type           Length of value field (in bytes)
                 ----           --------------------------------
          0      Reserved       0
          1      IPv4           4
          2      IPv4 netmask   4
          3      IPv6           16
          4      IPv6 netmask   16
          5      FQDN           varies

      For FQDN, the length of the value field will be one less than the
      value of the length field.




Borella et al.              Expires May 2000                    [Page 8]

INTERNET-DRAFT  Realm Specific IP: Protocol Specification  November 1999


      In some cases, it is necessary to specify a "don't care" value for
      an address.  This is signified by a setting the length field to 1
      and omitting the value field.

   8.2.  Ports

         Code    Length   Number     Port            Port
      +-------+---------+--------+---------+     +---------+
      |   2   | 2 bytes | 1 byte | 2 bytes | ... | 2 bytes |
      +-------+---------+--------+---------+     +---------+

      The ports parameter encodes one or more TCP or UDP ports.  When a
      single port is specified, the value of the number field is 1 and
      there is one port field following the number field.  When more
      than one port is specified, the value of the number field will
      indicate the total number of ports contained, and the parameter
      may take one of two forms.  If there is one port field, the ports
      specified are considered to be contiguous starting at the port
      number specified in the port field.  Alternatively, there may be a
      number of port fields equal to the value of the number field.  The
      number of port fields can be extrapolated from the length field.

      In some cases, it is necessary to specify a don't care value for
      one or more ports.  This is accomplished by setting the length
      field to 1, setting the number field to the number of ports
      necessary, and omitting all port fields.  The value of the number
      field MUST be greater than or equal to one.

      This parameter is not used with RSA-IP.

   8.3.  Lease Time

        Code    Length    Value
      +-------+--------+---------+
      |   3   |    4   | 4 bytes |
      +-------+--------+---------+

      The lease time parameter specifies the length, in seconds, of an
      RSIP client parameter binding.

   8.4.  Client ID

        Code    Length    Value
      +-------+--------+---------+
      |   4   |    4   | 4 bytes |
      +-------+--------+---------+

      The client ID parameter specifies an RSIP client ID.



Borella et al.              Expires May 2000                    [Page 9]

INTERNET-DRAFT  Realm Specific IP: Protocol Specification  November 1999


   8.5.  Bind ID

        Code    Length    Value
      +-------+--------+---------+
      |   5   |    4   | 4 bytes |
      +-------+--------+---------+

      The bind ID parameter specifies an RSIP bind ID.

   8.6.  Tunnel Type

        Code    Length   Value
      +-------+--------+--------+
      |   6   |    1   | 1 byte |
      +-------+--------+--------+

      The tunnel type parameter specifies the type of tunnel used
      between an RSIP client and an RSIP server.  Defined tunnel types
      are:

                 Tunnel Type
                 -----------
          0      Reserved
          1      IP-IP
          2      GRE
          3      L2TP

   8.7.  RSIP Method

        Code    Length   Value
      +-------+--------+--------+
      |   7   |    1   | 1 byte |
      +-------+--------+--------+

      The RSIP method parameter specifies an RSIP method.  Defined RSIP
      methods are:

                 RSIP method
                 -----------
          0      Reserved
          1      RSA-IP
          2      RSAP-IP
          3      RSA-IP with IPSEC
          4      RSAP-IP with IPSEC

   8.8.  Error





Borella et al.              Expires May 2000                   [Page 10]

INTERNET-DRAFT  Realm Specific IP: Protocol Specification  November 1999


        Code    Length    Value
      +-------+--------+---------+
      |   8   |    2   | 2 bytes |
      +-------+--------+---------+

      The error parameter specifies an error.  The currently defined
      error values are presented in Appendix A.

   8.9.  Flow Policy

        Code    Length   Local    Remote
      +-------+--------+--------+--------+
      |   9   |    2   | 1 byte | 1 byte |
      +-------+--------+--------+--------+

      The flow policy parameter specifies both the local and remote flow
      policy.

      Defined local flow policies are:

                 Local Flow Policy
                 -----------------
          0      Reserved
          1      Macro flows
          2      Micro flows

      Defined remote flow policies are:

                 Remote Flow Policy
                 ------------------
          0      Reserved
          1      Macro flows
          2      Micro flows
          3      No policy

   8.10.  Vendor Specific Parameter

        Code    Length    Vendor ID   Subcode   Value
      +-------+---------+-----------+---------+--------+
      |  10   | 2 bytes |  2 bytes  | 2 bytes | varies |
      +-------+---------+-----------+---------+--------+

      The vendor specific parameter is used to encode parameters that
      are defined by a particular vendor.  The vendor ID field is the
      vendor-specific ID assigned by IANA.  Subcodes are defined and
      used by each vendor as necessary.  An RSIP client or server SHOULD
      silently ignore vendor-specific messages that it does not
      understand.



Borella et al.              Expires May 2000                   [Page 11]

INTERNET-DRAFT  Realm Specific IP: Protocol Specification  November 1999


9.  Message Types

   RSIP messages consist of three mandatory fields, version, message
   type, and overall length, followed by one or more required
   parameters, followed in turn by zero or more optional parameters.  In
   an RSIP message, all required parameters MUST appear in the exact
   order specified below.  Optional parameters MAY appear in any order.

   The version number field is a single byte and specifies the RSIP
   version number that is being used.  The current RSIP version number
   is 1.

   The message type field is a single byte and specifies the message
   contained in the current packet.  There may be only one message per
   packet.  Message types given numerical assignments in Appendix B.

   The overall length field is two bytes and contains the number of
   bytes in the RSIP message, including the three mandatory fields.

   Most parameters are only allowed to appear once in each message.  The
   exceptions are as follows:

   - Multiple address parameters MUST appear in ASSIGN_REQUEST_RSA-IP,
     ASSIGN_RESPONSE_RSA-IP, ASSIGN_REQUEST_RSAP-IP,
     ASSIGN_RESPONSE_RSAP-IP, LISTEN_REQUEST and LISTEN_RESPONSE.

   - Multiple ports parameters MUST appear in ASSIGN_REQUEST_RSAP-IP,
     ASSIGN_RESPONSE_RSAP-IP, LISTEN_REQUEST and LISTEN_RESPONSE.

   - Multiple RSIP method and tunnel type parameters MAY appear in
     RESISTER_RESPONSE.

   - Multiple address parameters MAY appear in QUERY_REQUEST and
     QUERY_RESPONSE.

   The following message types are defined in simple BNF.  Required
   parameters are enclosed in <> and MUST appear.  Optional parameters
   are enclosed in [] and MAY appear.  Not all message types need to be
   implemented in order to be RSIP compliant.  For example, an RSIP
   client and/or server may not support LISTEN_REQUEST and
   LISTEN_RESPONSE, or may only support RSA-IP or RSAP-IP.

   9.1.  ERROR_RESPONSE

      An ERROR_RESPONSE is used to provide error messages from an RSIP
      server to an RSIP client.  Usually, errors indicate that the RSIP
      server cannot or will not perform an action or allocate resources
      on behalf of the client.  If the error is related to a particular



Borella et al.              Expires May 2000                   [Page 12]

INTERNET-DRAFT  Realm Specific IP: Protocol Specification  November 1999


      client ID or bind ID, these associated parameters MUST be
      included.  Multiple errors MAY NOT be reported in the same
      ERROR_RESPONSE.

      <ERROR_RESPONSE> ::= <Version>
                           <Message Type>
                           <Overall Length>
                           <Error>
                           [Client ID]
                           [Bind ID]

   9.2.  REGISTER_REQUEST

      The REGISTER_REQUEST message is used by an RSIP client to
      establish registration with an RSIP server.  An RSIP client MUST
      register before it requests resources or services from an RSIP
      server.  Once an RSIP client has registered with an RSIP server,
      it may not register again until it has de-registered from that
      server.

      <REGISTER_REQUEST> ::= <Version>
                             <Message Type>
                             <Overall Length>

   9.3.  REGISTER_RESPONSE

      The REGISTER_RESPONSE message is used by an RSIP server to confirm
      the registration of an RSIP client, and to provide a client ID and
      flow policy.  The RSIP server MAY respond with one or more RSIP
      methods and tunnel types that it supports.

      <REGISTER_RESPONSE> ::= <Version>
                              <Message Type>
                              <Overall Length>
                              <Client ID>
                              <Flow Policy>
                              [RSIP Method]...
                              [Tunnel Type]...

   9.4.  DE-REGISTER_REQUEST

      The DE-REGISTER_REQUEST message is used by an RSIP client to de-
      register with an RSIP server.  If a client de-registers from the
      assigned state, all of the client's bindings are revoked.  The
      client SHOULD NOT de-register from the unregistered state.






Borella et al.              Expires May 2000                   [Page 13]

INTERNET-DRAFT  Realm Specific IP: Protocol Specification  November 1999


      <DE-REGISTER_REQUEST> ::= <Version>
                                <Message Type>
                                <Overall Length>
                                <Client ID>

   9.5.  DE-REGISTER_RESPONSE

      The DE-REGISTER_RESPONSE message is used by an RSIP server to
      confirm the de-registration of an RSIP client.

      <DE-REGISTER_RESPONSE> ::= <Version>
                                 <Message Type>
                                 <Overall Length>
                                 <Client ID>

   9.6.  ASSIGN_REQUEST_RSA-IP

      The ASSIGN_REQUEST_RSA-IP message is used by an RSIP client to
      request resources to use with RSA-IP.  Note that RSA-IP cannot be
      used in combination with micro-flow based local policy.

      The RSIP client specifies two address parameters.  The RSIP client
      may request a particular local address by placing that address in
      the first address parameter.  To indicate that it has no
      preference for local address, the RSIP client may place a "don't
      care" value of all zeros in the address parameter.

      If macro-flow based remote policy is used, the client MUST specify
      the remote address that it will use this binding (if granted) to
      contact; however, the remote port number MAY remain unspecified.
      If micro-flow based remote policy is used, the client MUST specify
      the remote address and port number that it will use this binding
      (if granted) to contact.  If no flow policy is used, the RSIP
      client may place a "don't care" value of all zeros in the value
      fields of the respective address and ports parameters.

      <ASSIGN_REQUEST_RSA-IP> ::= <Version>
                                  <Message Type>
                                  <Overall Length>
                                  <Client ID>
                                  <Address (local)>
                                  <Address (remote)>
                                  <Ports (remote)>
                                  [Lease Time]
                                  [Tunnel Type]

   9.7.  ASSIGN_RESPONSE_RSA-IP




Borella et al.              Expires May 2000                   [Page 14]

INTERNET-DRAFT  Realm Specific IP: Protocol Specification  November 1999


      The ASSIGN_RESPONSE_RSA-IP message is used by an RSIP server to
      deliver parameter assignments to an RSIP client using RSA-IP.  A
      client-wise unique bind ID, lease time, and tunnel type must be
      provided for every assignment.

      If no remote flow policy is used, the RSIP server MUST use "don't
      care" values for the remote address and ports parameters.  If
      macro-flow based remote policy is used, the remote address
      parameter MUST contain the address specified in the associated
      request, and the remote ports parameter MUST contain a "don't
      care" value.  If micro-flow based remote policy is used, the
      remote address and remote ports parameters MUST contain the
      address and port information specified in the associated request.

      <ASSIGN_RESPONSE_RSA-IP> ::= <Version>
                                   <Message Type>
                                   <Overall Length>
                                   <Client ID>
                                   <Bind ID>
                                   <Address (local)>
                                   <Address (remote)>
                                   <Ports (remote)>
                                   <Lease Time>
                                   <Tunnel Type>

   9.8.  ASSIGN_REQUEST_RSAP-IP

      The ASSIGN_REQUEST_RSAP-IP message is used by an RSIP client to
      request resources to use with RSAP-IP.  The RSIP client specifies
      two address and two port parameters, the first of each,
      respectively, refer to the local address and port(s) that will be
      used, and the second of each, respectively, refer to the remote
      address and port(s) that will be contacted.

      An RSIP client may request a particular local address by placing
      that address in the value field of the first address parameter.
      The RSIP client may request particular local ports by placing them
      in the first port parameter.  To indicate that it has no
      preference for local address or ports, the RSIP client may place a
      "don't care" value of zeros in the respective address or ports
      parameters.

      If macro-flow based remote policy is used, the client MUST specify
      the remote address that it will use this binding (if granted) to
      contact; however, the remote port number(s) MAY remain
      unspecified.  If micro-flow based remote policy is used, the
      client MUST specify the remote address and port number(s) that it
      will use this binding (if granted) to contact. If no flow policy



Borella et al.              Expires May 2000                   [Page 15]

INTERNET-DRAFT  Realm Specific IP: Protocol Specification  November 1999


      is used, the RSIP client may place a value of all 0's in the value
      fields of the respective address or port parameters.

      <ASSIGN_REQUEST_RSAP-IP> ::= <Version>
                                   <Message Type>
                                   <Overall Length>
                                   <Client ID>
                                   <Address (local)>
                                   <Ports (local)>
                                   <Address (remote)>
                                   <Ports (remote)>
                                   [Lease Time]
                                   [Tunnel Type]

   9.9.  ASSIGN_RESPONSE_RSAP-IP

      The ASSIGN_RESPONSE_RSAP-IP message is used by an RSIP server to
      deliver parameter assignments to an RSIP client.  A client-wise
      unique bind ID, lease time, and tunnel type must be provided for
      every assignment.

      Regardless of local flow policy, a local address and port(s) MUST
      be assigned to the client.  If macro-flow based local policy is
      used, the client is assigned an address and one or more ports.  If
      micro-flow based local policy is used, the client is assigned an
      address and exactly one port.

      If no remote flow policy is used, the RSIP server MUST use "don't
      care" values for the remote address and ports parameters.  If
      macro-flow based remote policy is used, the remote address
      parameter MUST contain the address specified in the associated
      request, and the remote ports parameter must contain a "don't
      care" value.  If micro-flow based remote policy is used, the
      remote address and remote ports parameters MUST contain the
      address and port information specified in the associated request.

      <ASSIGN_RESPONSE_RSAP-IP> ::= <Version>
                                    <Message Type>
                                    <Overall Length>
                                    <Client ID>
                                    <Bind ID>
                                    <Address (local)>
                                    <Ports (local)>
                                    <Address (remote)>
                                    <Ports (remote)>
                                    <Lease Time>
                                    <Tunnel Type>




Borella et al.              Expires May 2000                   [Page 16]

INTERNET-DRAFT  Realm Specific IP: Protocol Specification  November 1999


   9.10.  EXTEND_REQUEST

      The EXTEND_REQUEST message is used to request a lease extension to
      a current bind.  It may be used with both RSA-IP and RSAP-IP.  The
      client MUST specify its client ID and the bind ID in question, and
      it MAY suggest a lease time to the server.

      <EXTEND_REQUEST> ::= <Version>
                           <Message Type>
                           <Overall Length>
                           <Client ID>
                           <Bind ID>
                           [Lease Time]

   9.11.  EXTEND_RESPONSE

      The EXTEND_RESPONSE message is used by an RSIP server to grant a
      requested lease extension.  The server MUST specify the client ID
      of the client, the bind ID in question, and the new assigned lease
      time.

      <EXTEND_RESPONSE> ::= <Version>
                            <Message Type>
                            <Overall Length>
                            <Client ID>
                            <Bind ID>
                            <Lease Time>

   9.12.  FREE_REQUEST

      The FREE_REQUEST message is used by an RSIP client to free a
      binding.  The given bind ID identifies the bind to be freed.
      Resources may only be freed using the granularity of a bind ID.

      <FREE_REQUEST> ::= <Version>
                         <Message Type>
                         <Overall Length>
                         <Client ID>
                         <Bind ID>

   9.13.  FREE_RESPONSE

      The FREE_RESPONSE message is used by an RSIP server to acknowledge
      a FREE_REQUEST sent by an RSIP client.







Borella et al.              Expires May 2000                   [Page 17]

INTERNET-DRAFT  Realm Specific IP: Protocol Specification  November 1999


      <FREE_RESPONSE> ::= <Version>
                          <Message Type>
                          <Overall Length>
                          <Client ID>
                          <Bind ID>

   9.14.  QUERY_REQUEST

      A QUERY_REQUEST message is used by an RSIP client to ask an RSIP
      server whether or not a particular address or network is local or
      remote.  The client uses this information to determine whether to
      contact the host(s) directly (in the local case), or via RSIP (in
      the remote case).  If the client needs to specify a subnet, it
      must use two address parameters - the first indicates the network
      and the second indicates the subnet mask.

      <QUERY_REQUEST> ::= <Version>
                          <Message Type>
                          <Overall Length>
                          <Client ID>
                          <Address>
                          [Address (netmask)]

   9.15.  QUERY_RESPONSE

      A QUERY_RESPONSE message is used by an RSIP server to answer a
      QUERY_REQUEST from an RSIP client.  The RSIP server MAY respond
      with a list of all networks and/or addresses that are on the
      private side of the network.  If the server needs to specify a
      subnet, it must use two address parameters - the first indicates
      the network and the second indicates the subnet mask.  An address
      with a "don't care" value indicates that address queried is not
      local.

      <QUERY_RESPONSE> ::= <Version>
                           <Message Type>
                           <Overall Length>
                           <Client ID>
                           <Address>
                           [Address (netmask)]

   9.16.  DEALLOCATE

      A DEALLOCATE message is used by an RSIP server to force an RSIP
      client to relinquish a specified binding.  The client ID of the
      client and the bind ID of the resources to be relinquished MUST be
      included.  Upon receiving a DEALLOCATE message, an RSIP client
      MUST stop all use of the said resources and immediately send an OK



Borella et al.              Expires May 2000                   [Page 18]

INTERNET-DRAFT  Realm Specific IP: Protocol Specification  November 1999


      response to the server.

      <DEALLOCATE> ::= <Version>
                       <Message Type>
                       <Overall Length>
                       <Client ID>
                       <Bind ID>

   9.17.  OK

      An OK message MAY be used by an RSIP client to positively
      acknowledge the receipt of a message from the RSIP server.  The OK
      message MUST be used to respond to a DEALLOCATE message from an
      RSIP server.  If the OK is in reference to a particular bind ID,
      then that bind ID MUST appear in the message.

      <OK> ::= <Version>
               <Message Type>
               <Overall Length>
               <Client ID>
               [Bind ID]

   9.18.  LISTEN_REQUEST

      A LISTEN_REQUEST message is sent by an RSIP client that wants to
      register a service on a particular IP address and port number. The
      client must include its client ID, local address parameter and
      ports parameters, and remote address and ports parameters. The
      client MAY suggest a lease time and one or more tunnel types.

      If the client wants to listen on a particular address or port, it
      may specify these in the address and ports parameters.  Otherwise
      it may leave one or both of these parameters with "don't care"
      values.

      If no remote flow policy is being used, the client MUST fill both
      the remote address and ports parameters with "don't care" values.
      If macro-flow based remote policy is used, the client MUST specify
      the remote address, but MAY or MAY NOT specify the remote port(s).
      If micro-flow based remote policy is used, the client MUST specify
      the remote address and ports parameter.

      Once a LISTEN_REQUEST has been granted, the RSIP server MUST
      forward all packets destined to the address and port in question
      to the client, even if the remote host address and port tuple has
      not been previously contacted by the client.

      LISTEN_REQUEST is not necessary for RSA-IP.



Borella et al.              Expires May 2000                   [Page 19]

INTERNET-DRAFT  Realm Specific IP: Protocol Specification  November 1999


      <LISTEN_REQUEST> ::= <Version>
                           <Message Type>
                           <Overall Length>
                           <Client ID>
                           <Address (local)>
                           <Ports (local)>
                           <Address (remote)>
                           <Ports (remote)>
                           [Lease Time]
                           [Tunnel Type]...

   9.19.  LISTEN_RESPONSE

      A LISTEN_RESPONSE message is used by an RSIP server to respond to
      a LISTEN_REQUEST message from an RSIP client.  The RSIP server
      MUST issue a bind ID, and specify the address and port which have
      been granted to the client.  The server must also specify a tunnel
      type and lease time.

      If no remote flow policy is being used, the server MUST fill both
      the remote address and ports parameters with "don't care" values.
      If macro-flow based remote policy is used, the server MUST specify
      the remote address, but MAY or MAY NOT specify the remote port(s).
      If micro-flow based remote policy is used, the server MUST specify
      the remote address and ports parameter.

      <LISTEN_RESPONSE> ::= <Version>
                            <Message Type>
                            <Overall Length>
                            <Client ID>
                            <Bind ID>
                            <Address (local)>
                            <Ports (local)>
                            <Address (remote)>
                            <Ports (remote)>
                            <Tunnel Type>
                            <Lease Time>

10.  Discussion

   10.1.  General Server Policy

      There is a significant amount of RSIP server policy that may be
      implemented, but is beyond the scope of this draft.  We expect
      that most of this policy will be site-specific or implementation-
      specific and therefore do not make any recommendations.  Examples
      of general server policy include:




Borella et al.              Expires May 2000                   [Page 20]

INTERNET-DRAFT  Realm Specific IP: Protocol Specification  November 1999


      - How ports are allocated to RSIP clients.
      - Preferred length of lease times.
      - How flow policy is applied to which clients.

   10.2.  Default Tunnel Type and RSIP Method

      If an RSIP server does not specify a tunnel type or RSIP method as
      part of a REGISTER_RESPONSE, the client MUST assume a tunnel type
      of IP-IP and an RSIP method of RSAP-IP.

   10.3.  Address and Port Requests and Allocation

      Regardless of local flow policy, an RSIP client may "suggest" that
      it would like to use a particular local address and/or port number
      in a particular binding.  An RSIP server that cannot grant such a
      request, because the specified resources are already in use, MAY
      either (1) deny the request with an appropriate error message, or
      (2) approve the request but with different values than those
      suggested.

   10.4.  Local Servers and Flow Policy Interaction

      An RSIP client may initialize a publically accessible server (such
      as an FTP or HTTP server) by transmitting a LISTEN_REQUEST message
      to an RSIP server and receiving a LISTEN_RESPONSE.  However,
      unless no remote flow policy is used, the server will have to
      specify the address or address and port of a single remote host
      that will be allowed to contact it.  Obviously, such as
      restriction is not very useful for clients that require their
      servers to be accessible by any remote host.

      This indicates that there is a conflict between flow-based policy
      and support for servers.  The main purpose of enforcing flow-based
      policy for LISTEN_REQUESTs is that it allows an RSIP server tight
      control over how an RSIP client uses ports and the associated
      accounting.  For example, an RSIP client, operating under remote
      micro-flow based policy and using a protocol such as FTP, will
      have to specify the address and port that it will receive FTP data
      on, as well as the address and port that the server will transmit
      data from, in a LISTEN_REQUEST.

      In general, an RSIP server may not allow arbitrary clients to
      start public servers because of the traffic and security concerns.
      Thus, we recommend that if remote micro-flow based policy is used,
      that an RSIP server only allow public servers on RSIP clients via
      administrative override.

11.  Security Considerations



Borella et al.              Expires May 2000                   [Page 21]

INTERNET-DRAFT  Realm Specific IP: Protocol Specification  November 1999


   RSIP, in and of itself, does not provide security.  It may provide
   the illusion of security or privacy by hiding a private address
   space, but security can only be ensured by the proper use of security
   protocols and cryptographic techniques.

   RSIP messages send between a client and server SHOULD be
   authenticated.  Further discussion of such authentication can be
   found in [RSIP-FRAME].

   Discussion of RSIP support for end-to-end IPSEC can be found in
   [RSIP-IPSEC].

12.  IANA Considerations

   All of the below are tentative.

   - RSIP port number: 4455.
   - RSIP error codes (see Appendix A).
   - RSIP message type codes (see Appendix B).

13.  Changelog

   03 to 04
         - Changed "client / server state" to "client / server relationship"
           in order to not overload the word "state".
         - Added section on transport protocol support.
         - Reduced the size of "don't care" value for Address and Port parameters.
         - Removed message IDs.
         - Addition of overall length field in all messages.
         - Added example of an RSA-IP session.
         - Divided error numbers by category.

   02 to 03
         - Overall re-write and editing.
         - Removed a number of extraneous details that are now covered in the
           framework draft.
         - Moved parameter and message type codes to appendices.
         - Added section on flow policy.
         - Modified address and port parameters to simplify and generalize.

   01 to 02:
         - Added section on server state.
         - Re-wrote section on parameter negotiation.
         - Added details to ICMP Handling section.
         - Added LISTEN_REQUEST and LISTEN_RESPONSE messages.
         - Added appendix with client state diagram.
         - Updated references with respect to RFC 2663.
         - Clarified use/non-use of message IDs between clients and servers.



Borella et al.              Expires May 2000                   [Page 22]

INTERNET-DRAFT  Realm Specific IP: Protocol Specification  November 1999


         - Added recommendation that RSIP use port 4455 for initial
           implementation and testing, until further notice.
         - Bumped code values up by 1, made code value of 0 reserved.
         - Expanded ASSIGN_REQUEST into ASSIGN_REQUEST_ADDR for RSA-IP,
           ASSIGN_REQUEST_PORT for RSAP-IP and ASSIGN_REQUEST_EXT for lease
           extensions.  The same expansion applies for ASSIGN_RESPONSE.
         - Indicated that all RSIP parameters must not appear more than once
           except for tunnel type and RSIP method in ASSIGN_REQUEST messages.
         - Exactly one error is now reported in each ERROR_RESPONSE message.

   00 to 01:
         - Eliminated number of IP addresses and IP address range
           parameters and fixed other parameters to reflect this change.
         - Added IP address request message.
         - Added discussion on authentication to Security Considerations
           section.
         - Added Miscellaneous Issues section.
         - Changed all mention of "sequence number" to "message ID".
         - Reformatted References section.
         - Added reference to RSIP framework draft.
         - Separated request and response messages, then renumbered them.
         - Required that all RSIP implementations support IP-IP tunneling
           and RSA-IP.
         - Modified message semantics slightly.
         - Added appendix with protocol example.
         - Added address and port resource error messages.
         - Specified that multiple error responses may be returned in the
           same ERROR_RESPONSE message.
         - RSIP method may now be specified per binding, so that different
           methods can be used when connecting to different external systems.
         - Synched up terminology with the latest NAT terminology draft.
         - Added mention of RSIP servers also implementing a NAT as a
           fallback.
         - Added DEALLOCATE and OK messages.
         - Tunneling now negotiated per bind rather than per-registration.

14.  Acknowledgements

   The authors would like to specifically thank Gabriel Montenegro, Pyda
   Srisuresh, Dan Nessett, Gary Jaszewski, and Rick Cobb for their
   input.  The IETF NAT working group as a whole has been extremely
   helpful in the ongoing development of RSIP.

15.  Appendix A: RSIP Error Numbers

   This section provides descriptions for the error values in the RSIP
   error parameter. These error values are preliminary and are very
   likely to change over time as implementations are tested.



Borella et al.              Expires May 2000                   [Page 23]

INTERNET-DRAFT  Realm Specific IP: Protocol Specification  November 1999


   All errors are grouped into the following categories:

   100's: General errors.

      101: UNKNOWN_ERROR.  An error that cannot be identified has
         occurred.  This error should be used when all other error
         messages are inappropriate.

      102: USE_TCP.  A client has attempted to use UDP on a server that
         only supports TCP.

   200's: Parameter and message errors.  The server uses these errors
      when it detects that a parameter or message is malformed, as well
      as when it does not understand a parameter or message.

      201: MISSING_PARAM. The request does not contain a required
         parameter.

      202: DUPLICATE_PARAM. The request contains an illegal duplicate
         parameter.

      203: EXTRA_PARAM. The request contains a parameter that it should
         not.

      204: ILLEGAL_PARAM. The server does not understand a parameter
         code.  not.

      205: BAD_PARAM. A parameter is malformed.

      206: ILLEGAL_MESSAGE. The server does not understand the message
         type.

      207: BAD_MESSAGE. A message is malformed.

   300's: Permission and policy errors.  The server uses these errors
      when a client has attempted to do something that it is not
      permitted to do, or something that violated server policy.

      301: REGISTER_FIRST. The RSIP client has attempted to request or
         use resources without registering.

      302: ALREADY_REGISTERED. The client has attempted to register
         again without first de-registering.

      303: ALREADY_UNREGISTERED. The client has attempted to de-register
         but it is already in the unregistered state.

      304: BAD_CLIENT_ID. The client has referred to itself with the



Borella et al.              Expires May 2000                   [Page 24]

INTERNET-DRAFT  Realm Specific IP: Protocol Specification  November 1999


         wrong Client ID.

      305: BAD_BIND_ID. The request refers to a Bind ID that is not
         valid for the client.

      306: REMOTE_ADDR_UNALLOWED.  The server will not allow the client
         to establish a session to the specified remote address.

      307: REMOTE_ADDRPORT_UNALLOWED.  The server will not allow the
         client to establish a session to the specified remote address /
         port tuple.

   400's: Resource allocation errors.  The server uses these errors when
      it needs to indicate to a client that a particular resource is not
      available.  These errors MUST NOT be used when a client attempts
      to use resources that it does not have permission to use - in such
      a case, a 300 error is to be used.

      401: ADDR_UNAVAILABLE. The server was not able to allocate a local
         IP address.

      402: PORT_UNAVAILABLE. The server was not able to allocate
         port(s).

      403: REQUESTED_ADDR_UNAVAILABLE. The server was not able to
         allocate the local IP address specified by the client.

      404: REQUESTED_PORT_UNAVAILABLE. The server was not able to
         allocate the port or ports specified by the client.

   500's: IPSEC errors.  All errors specific to RSIP / IPSEC operation.
      See [RSIP-IPSEC].

16.  Appendix B: Message Type Values

   This section defines the values assigned to RSIP message types.
   These values are preliminary and are very likely to change over time
   as implementations are tested.

    1  ERROR_RESPONSE
    2  REGISTER_REQUEST
    3  REGISTER_RESPONSE
    4  DE-REGISTER_REQUEST
    5  DE-REGISTER_RESPONSE
    6  ASSIGN_REQUEST_RSA-IP
    7  ASSIGN_RESPONSE_RSA-IP
    8  ASSIGN_REQUEST_RSAP-IP
    9  ASSIGN_RESPONSE_RSAP-IP



Borella et al.              Expires May 2000                   [Page 25]

INTERNET-DRAFT  Realm Specific IP: Protocol Specification  November 1999


   10  EXTEND_REQUEST
   11  EXTEND_RESPONSE
   12  FREE_REQUEST
   13  FREE_RESPONSE
   14  QUERY_REQUEST
   15  QUERY_RESPONSE
   16  DEALLOCATE
   17  OK
   18  LISTEN_REQUEST
   19  LISTEN_RESPONSE

17.  Appendix C: Example RSIP client/server transactions

   In this appendix, we present an exemplary series of annotated
   transactions between an RSIP client and an RSIP server.  All client
   to server traffic is denote by `C --> S' and all server to client
   traffic is denoted by `S --> C'.  Parameter values are denoted inside
   of parentheses. Versions, message types, and overall lengths are not
   included in order to save space.  "Don't care" values are indicated
   by 0's.

   A ports parameter is represented by the number of ports followed by
   the port numbers, separated by dashes.  For example, 2-1012-1013
   indicates two ports, namely 1012 and 1013, while 16-10000 indicates
   16 ports, namely 10000-10015, and 4-0 indicates four ports, but the
   sender doesn't care where they are.

   IPv4 addresses are assumed.

   17.1.  RSAP-IP with Local Macro-flow Based Policy and No Remote Flow
      Policy

      This example exhibits the loosest policy framework for RSA-IP.

      C --> S: REGISTER_REQUEST ()

         The client attempts to register with the server.

      S --> C: REGISTER_RESPONSE (Client ID = 1, Local Flow Policy =
         Macro, Remote Flow policy = None)

         The server responds, assigning a Client ID of 1, local macro-
         flow based policy and no remote flow policy.  No RSIP method is
         indicated, so RSAP-IP is assumed.  No tunnel type is indicated,
         so IP-IP is assumed.

      C --> S: ASSIGN_REQUEST_RSAP-IP: (Client ID = 1, Address (local) =
         0, Ports (local) = 4-0, Address (remote) = 0, Ports (remote) =



Borella et al.              Expires May 2000                   [Page 26]

INTERNET-DRAFT  Realm Specific IP: Protocol Specification  November 1999


         0, Lease Time = 3600)

         The client requests an address and four ports to use with it,
         but doesn't care which address or ports are assigned.  The
         client does not specify the remote address or ports either.
         The client suggests a lease time of 3600 seconds.


      S --> C: ASSIGN_RESPONSE_RSAP-IP: (Client ID = 1, Bind ID = 1,
         Address (local) = 149.112.240.156, Ports (local) = 4-1234,
         Address (remote) = 0, Ports (remote) = 0, Lease Time = 1800,
         Tunnel Type = IP-IP)

         The server responds by indicating that a bind ID of 1 has been
         assigned to IP address 149.112.240.156 with ports 1234-1237.
         Any remote host may be communicated with, using any remote port
         number.  The lease time has been assigned to be 1800 seconds,
         and the tunnel type is confirmed to be IP-IP.

         The client is now able to communicate with any host on the
         public network using these resources.

      C --> S: QUERY_REQUEST: (Client ID = 1, Address = 10.20.60.0,
         Address (netmask) 255.255.255.0)

         The client asks the server if the network 10.20.60.0 is local.

      S --> C: QUERY_RESPONSE: (Client ID = 1, Address = 10.20.60.0,
         Address (netmask) = 255.255.255.0)

         The server responds indicating that the network in question is
         local.

      C --> S: ASSIGN_REQUEST_RSAP-IP: (Client ID = 1, Address (local) =
         149.112.240.156, Ports (local) = 8-1238, Address (remote) = 0,
         Ports (remote) = 0, Lease Time = 1800)

         The client requests eight more particular ports for use with
         RSAP-IP with the same address.  A lease of 1800 seconds is
         requested.  IP-IP tunneling is implied by default.

      S --> C: ASSIGN_RESPONSE_RSAP-IP: (Client ID = 1, Bind ID = 2,
         Address (local) = 149.112.240.156, Ports (local) = 8-1305,
         Address (remote) = 0, Ports (remote) = 0, Lease Time = 1800)

         The server grants the request with the same address, but with a
         different set of ports. IP-IP tunneling is implied by default.




Borella et al.              Expires May 2000                   [Page 27]

INTERNET-DRAFT  Realm Specific IP: Protocol Specification  November 1999


      C --> S: FREE_REQUEST (Client ID = 1, Bind ID = 1)

         The client frees bind ID 1; i.e., ports 1234-1237 from IP
         address 149.112.240.156.  Note that the address itself is still
         assigned to the client because the client is still assigned
         ports 1305-1314.

      S --> C: FREE_RESPONSE (Client ID = 1, Bind ID = 1)

         The server acknowledges that Bind ID 1 has been freed.

      C --> S: EXTEND_REQUEST (Client ID = 1, Bind ID = 2, Lease Time =
         1800)

         The client request that the lease on bind ID 1 be extended for
         1800 seconds.

      S --> C: EXTEND_RESPONSE (Client ID = 1, Bind ID = 2, Lease Time =
         1800)

         The server confirms the request.

      S --> C: DEALLOCATE (Client ID = 1, Bind ID = 2)

         The server forces the client to deallocate the resources of
         bind ID 2.

      C --> S: OK (Client ID = 1, Bind ID 2)

         The client acknowledges that the resources have been
         deallocated.

      C --> S: DE-REGISTER_REQUEST (Client ID = 1)

         The client de-registers with the sever.

      S --> C: REGISTER_RESPONSE (Client ID = 1)

         The server acknowledges that the client has de-registered.

   17.2.  RSAP-IP with Local Micro-flow Based Policy and Remote Micro-
      flow Based Policy

      This example exhibits the strictest policy framework for RSAP-IP.

      C --> S: REGISTER_REQUEST ()

         The client attempts to register with the server.



Borella et al.              Expires May 2000                   [Page 28]

INTERNET-DRAFT  Realm Specific IP: Protocol Specification  November 1999


      S --> C: REGISTER_RESPONSE (Client ID = 5, Local Flow Policy =
         Micro, Remote Flow policy = Micro, RSIP Method = RSAP-IP, RSIP
         Method = RSA-IP, Tunnel Type = IP-IP, Tunnel Type = GRE)

         The server responds, assigning a Client ID of 5, local micro-
         flow based policy and remote micro-flow based policy.  Both
         RSAP-IP and RSA-IP are supported.  Both IP-IP and GRE tunnel
         types are supported.

      C --> S: ASSIGN_REQUEST_RSAP-IP: (Client ID = 5, Address (local) =
         0, Ports (local) = 0, Address (remote) = 38.196.73.6, Ports
         (remote) = 21, Lease Time = 600, Tunnel Type = IP-IP)

         The client requests a local address and a port assignment to
         use with it.  The client indicates that it wants to contact
         host 38.196.73.6 at port 21 (FTP control).  The client requests
         a lease time of 600 seconds and a tunnel type of IP-IP.

      S --> C: ASSIGN_RESPONSE_RSAP-IP: (Client ID = 5, Bind ID = 1,
         Address (local) = 149.112.240.156, Ports (local) = 2049,
         Address (remote) = 38.196.73.6, Ports (remote) = 21, Lease Time
         = 600, Tunnel Type = IP-IP)

         The server responds by indicating that a bind ID of 1 has been
         assigned to IP address 149.112.240.156 with port 2049.  Only
         host 38.196.73.6 at port 21 may be contacted.  The lease time
         has been assigned to be 600 seconds, and the tunnel type is
         confirmed to be IP-IP.

      C --> S: LISTEN_REQUEST: (Client ID = 5, Address (local) =
         149.112.240.156, Ports (local) = 2050, Address (remote) =
         38.196.73.6, Ports (remote) = 20)

         The client requests a listen port 2050 at the same address that
         it has been assigned.  Only host 38.196.73.6 from ports 20 (FTP
         data) will be able to contact it.

      S --> C: LISTEN_RESPONSE: (Client ID = 5, Address (local) =
         149.112.240.156, Ports (local) = 2050, Address (remote) =
         38.196.73.6, Ports (remote) = 20, Lease Time = 600, Tunnel Type
         = IP-IP)

         The server confirms the request and assigns a lease time of 600
         seconds and a tunnel type of IP-IP.

      C --> S:  DE-REGISTER_REQUEST (Client ID = 5)

         The client de-registers with the sever.



Borella et al.              Expires May 2000                   [Page 29]

INTERNET-DRAFT  Realm Specific IP: Protocol Specification  November 1999


      S --> C: REGISTER_RESPONSE (Client ID = 5)

         The server acknowledges that the client has de-registered.  All
         of the client's bindings have been implicitly revoked.

   17.3.  RSA-IP with Local Macro-flow Based Policy and Remote Macro-
      flow based Policy

      This example exhibits a medium level of control for RSA-IP.

      C --> S: REGISTER_REQUEST ()

         The client attempts to register with the server.

      S --> C: REGISTER_RESPONSE (Client ID = 3, Local Flow Policy =
         Macro, Remote Flow policy = Macro, RSIP Method = RSAP-IP, RSIP
         Method = RSA-IP, Tunnel Type = IP-IP, Tunnel Type = L2TP)

         The server responds, assigning a Client ID of 3, local macro-
         flow based policy and remote macro-flow based policy.  Both
         RSAP-IP and RSA-IP are supported.  Both IP-IP and L2TP tunnel
         types are supported.

      C --> S: ASSIGN_REQUEST_RSA-IP: (Client ID = 3, Address (local) =
         0, Address (remote) = www.foo.com, Ports (remote) = 0, Lease
         Time = 3600, Tunnel Type = IP-IP)

         The client requests a local address and indicates that it wants
         to contact host www.foo.com.

      S --> C: ERROR_RESPONSE: (Error = REMOTE_ADDR_UNALLOWED, Client ID
         = 3)

         The server indicates that the client is not permitted to
         establish communication with www.foo.com.

      C --> S: ASSIGN_REQUEST_RSA-IP: (Client ID = 3, Address (local) =
         0, Address (remote) = www.bar.com, Ports (remote) = 0, Lease
         Time = 3600, Tunnel Type = IP-IP)

         The client requests a local address and indicates that it wants
         to contact host www.bar.com.

      S --> C: ASSIGN_RESPONSE_RSA-IP: (Client ID = 3, Bind ID = 1,
         Address (local) = 149.112.240.17, Address (remote) =
         www.bar.com, Ports (remote) = 0, Lease Time = 3600, Tunnel Type
         = IP-IP)




Borella et al.              Expires May 2000                   [Page 30]

INTERNET-DRAFT  Realm Specific IP: Protocol Specification  November 1999


         The server responds by granting local IP address 149.112.240.17
         to the client, and permitting it to communicate with
         www.bar.com, at any port.  Requested lease time and tunnel type
         are also granted.

      C --> S:  DE-REGISTER_REQUEST (Client ID = 3)

         The client de-registers with the sever.

      S --> C: REGISTER_RESPONSE (Client ID = 3)

         The server acknowledges that the client has de-registered.  All
         of the client's bindings have been implicitly revoked.

18.  Appendix D: Example RSIP client state diagram

   This appendix provides an exemplary diagram of RSIP client state.
   The client begins in the unregistered state.  We assume that for UDP,
   if a message is lost, the client will timeout and retransmit another
   copy of it.  We recommend a 7-fold binary exponential backoff timer
   for retransmissions, with the first timeout occurring after 12.5 ms.
   This diagram does not include transitions for the LISTEN_REQUEST
   message or the DEALLOCATE message.


                          send
     +------------+ REGISTER_REQUEST +------------+
     |            |----------------->|Registration|<-- timeout/send
+--->|Unregistered|<-----------------|  Pending   |--- REGISTER_REQUEST
|    |            | 7th timeout/recv +------------+
|    +------------+  ERROR_RESPONSE        |
|          ^                               |
|          |7th timeout/recv               |recv               timeout/send
|          |DE-REGISTER_RESPONSE           |REGISTER_RESPONSE  QUERY_REQUEST
|          |                               |                        ^  |
|          |            send DE-           v        send            |  |
| +----------------+ REGISTER_REQUEST+----------+QUERY_REQUEST  +----------+
| |   Registered   |<----------------|          |-------------->|Registered|
| | De-registration|                 |Registered|               |   Query  |
| |    Pending     |---------------->|          |<--------------|  Pending |
| +----------------+      recv       +----------+  7th timeout/ +----------+
|         | ^        ERROR_RESPONSE        ^  |        recv
|         | |                              |  |  QUERY_RESPONSE or
|    timeout/send                          |  |    ERROR_RESPONSE
| DE-REGISTER_REQUEST      7th timeout/recv|  |
|                           ERROR_RESPONSE |  |
| +----------------+                       |  |
| |Go to Registered|                       |  |send



Borella et al.              Expires May 2000                   [Page 31]

INTERNET-DRAFT  Realm Specific IP: Protocol Specification  November 1999


| +----------------+                       |  |ASSIGN_REQUEST
|         ^                   timeout/send |  |
|         |Yes                FREE_REQUEST |  |
|         +                       |  |     |  |
|       +   +                     v  |     |  v
|     +       +   7th timeout/ +--------+ +----------+
|   +  Are all  +      recv    |  Free  | |Assignment|<--timeout/send
| +   resources   +<-----------|Pending | |  Pending |---ASSIGN_REQUEST
|   +   freed?  + FREE_RESPONSE+--------+ +----------+
|     +       +                    ^ |         |
|       +   +                      | |         |
|         +                        | |         |recv
|         |No                 send | |recv     |ASSIGN_RESPONSE
|         v           ERROR_REQUEST| |ERROR_   |
| +---------------+                | |RESPONSE |
| | Go to Assigned|                | |         |
| +---------------+                | |         | 7th timeout/recv
|                       recv       | |         | QUERY_RESPONSE or
| +---------------+ERROR_RESPONSE  | v         v ERROR_RESPONSE+-------------+
| |    Assigned   |-------------->+-------------+------------->|   Assigned  |
+>|De-registration|               |   Assigned  |              |    Query    |
  |    Pending    |<--------------+-------------+<-------------|   Pending   |
  +---------------+      send            ^  |         send     +-------------+
        ^  |       DE-REGISTER_REQUEST   |  |     QUERY_REQUEST     ^  |
        |  |                             |  |                       |  |
    timeout/send        7th/timeout/recv |  |send                   |  |
    DE-REGISTER_         ASSIGN_RESPONSE |  |ASSIGN_REQUEST      timeout/send
      REQUEST           or ERROR_RESPONSE|  |                    QUERY_REQUEST
                                         |  |
                                         |  v
                                     +----------+
                                     | Assigned |
                                     |Assignment|
                                     | Pending  |
                                     +----------+
                                         ^  |
                                         |  |
                                     timeout/send
                                    ASSIGN_REQUEST

19.  References

   [RFC1918] Y. Rekhter, B. Moskowitz, D. Karrenberg, G. J. de Groot,
      and E. Lear, "Address Allocation for Private Internets," RFC 1918,
      Feb. 1996.

   [RFC2119] S. Bradner, "Key words for use in RFCs to indicate
      requirement levels," RFC 2119, Mar. 1997.



Borella et al.              Expires May 2000                   [Page 32]

INTERNET-DRAFT  Realm Specific IP: Protocol Specification  November 1999


   [RFC2663] P. Srisuresh and M. Holdrege, "IP Network Address
      Translator (NAT) Terminology and Considerations," RFC 2663, Aug.
      1999.

   [RSIP-FRAME] M. Borella, J. Lo, D. Grabelsky, and G. Montenegro,
      "Realm Specific IP: Framework," Internet Draft <draft-ietf-nat-
      rsip-framework-02.txt>, Oct. 1999 (work in progress).

   [RSIP-IPSEC] G. Montenegro and M. Borella, "RSIP Support for End-to-
      end IPSEC," <draft-ietf-nat-rsip-ipsec-01.txt>, work in progress,
      Oct. 1999.

20.  Authors' Addresses

   Michael Borella
   3Com Corp.
   1800 W. Central Rd.
   Mount Prospect IL 60056
   (847) 342-6093
   mike_borella@3com.com

   David Grabelsky
   3Com Corp.
   1800 W. Central Rd.
   Mount Prospect IL 60056
   (847) 222-2483
   david_grabelsky@3com.com

   Jeffrey Lo
   NEC USA
   C&C Research Labs.
   110 Rio Robles
   San Jose, CA 95134
   (408) 943-3033
   jlo@ccrl.sj.nec.com

   Kunihiro Taniguchi
   NEC USA
   C&C Research Labs.
   110 Rio Robles
   San Jose, CA 95134
   (408) 943-3031
   taniguti@ccrl.sj.nec.com

21.  Copyright Statement

   Copyright (c) The Internet Society (1999). All Rights Reserved.




Borella et al.              Expires May 2000                   [Page 33]

INTERNET-DRAFT  Realm Specific IP: Protocol Specification  November 1999


   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works. However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.




























Borella et al.              Expires May 2000                   [Page 34]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/