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

Versions: 00 01 02 03 04 05 06 RFC 3103

INTERNET DRAFT                                       Michael Borella
Expires October 1999                                 David Grabelsky
                                                     3Com Corp.

                                                     Jeffrey Lo
                                                     Kunihiro Tuniguchi
                                                     NEC USA

                                                     April 1999




               Realm Specific IP: Protocol Specification
                 <draft-ietf-nat-rsip-protocol-01.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 draft presents a protocol that enables an alternative to network
   address translation (NAT).  Realm-Specific IP (RSIP) defines an
   architecture in which an RSIP server is a multi-homed host connecting
   two routing realms.  An RSIP client in the first routing realm may be
   assigned a plurality of routing parameters from the second routing
   realm.  The RSIP client will be allowed to create packets using these
   parameters, and tunnel them across the first routing realm.  For
   example, more than one host from a private address space using RSIP
   may share one or more public address.  Unlike NAT, RSIP does not



Borella et al.            Expires October 1999                  [Page 1]

INTERNET-DRAFT  Realm Specific IP: Protocol Specification     April 1999


   break the end-to-end integrity of protocols.  We present a general,
   extensible negotiation protocol to be operated between RSIP clients
   and servers which facilitates the assignment of parameters and
   resources from the server to the client.

1.  Introduction

   Network Address Translation (NAT) has gained popularity as a method
   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 as well as IP addresses.

   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).

   An alternative to a transparent 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.  This form of Realm-Specific IP (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 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 transparent to RSIP client, but this
   system allows packets to maintain their integrity from RSIP client to
   destination.  In order to resolve addressing and routing ambiguities
   in the first routing realm, all publicly routed packets are tunneled
   between RSIP client and the RSIP server, or tunneled such that the
   RSIP server can perform a NAT function on the outer IP header only.
   ALGs are not required in the RSIP server.

   A disadvantage to RSIP is that it requires that hosts be modified so
   that they tunnel externally-bound packets and 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



Borella et al.            Expires October 1999                  [Page 2]

INTERNET-DRAFT  Realm Specific IP: Protocol Specification     April 1999


   applicability of RSIP are discussed in a companion framework draft
   [RSIP-FRAME].

   1.1.  Specification of Requirements

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

2.  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 RFC 1918) 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 [NAT-TERM].

   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
   +-------------+  |
                    |
                    |
                   ...

   RSIP MAY be based on either the Basic NAT or the NAPT model.  In the
   Basic NAT model, a unique public IP address is assigned to each
   private NAT client that is actively communicating with the public
   network.  Only one NAT client uses a given public address.  In the
   NAPT model, one public address is shared by one or more NAT clients.
   One or more NAT clients may use the same public address by limiting
   the ports that they use to disjoint subsets of the port space.  The
   NAT server assigns these disjoint port sets to each host, along with



Borella et al.            Expires October 1999                  [Page 3]

INTERNET-DRAFT  Realm Specific IP: Protocol Specification     April 1999


   the public IP address.  For the remainder of this document we will
   assume the NAPT model unless otherwise stated.  With respect to RSIP,
   we refer to these models as the Realm Specific Address IP (RSA-IP)
   method (NAT) and Realm Specific Address and Port IP (RSAP-IP) method
   (NAPT).  The RSIP method determines the demultiplexing field of the
   packets coming from the public network to the private network.  The
   RSIP method is extensible to other yet-to-be-defined demultiplexing
   fields.  A demultiplexing field must be able to uniquely identify an
   RSIP client.

   RSIP may be deployed incrementally.  An RSIP server may be co-located
   with a NAT router such that RSIP clients can use the RSIP server, but
   non-RSIP clients can use the NAT.

   For purposes of illustration, we will provide a brief example of the
   transport operation of RSIP with respect to the above architecture.
   We assume that RSIP client 10.0.0.2 has been assigned public address
   149.112.240.10 and port set 10000-10015 (the actual mechanism for
   this assignment is discussed below).  Packets transmitted from this
   client to a WWW server at the external address of 128.153.4.3 will
   appear as follows on the private network:

            Outer IP        Inner IP      TU Ports
        +--------------+----------------+----------+
   Src: |   10.0.0.2   | 149.112.240.10 |  10000   |
        +--------------+----------------+----------+
   Dst: |   10.0.0.1   |   128.153.4.3  |    80    |
        +--------------+----------------+----------+

   Note that 10000 was chosen arbitrarily from the port set by the
   kernel port selection code of the RSIP client.  Upon reaching the
   RSIP server, the outer IP header is stripped off, and the remaining
   packet is transmitted on the public network.  Incoming packets to the
   RSIP client are demultiplexed based on the RSIP method and tunneled
   from the RSIP server to the RSIP client.

   Note that the architecture and protocols for RSIP may allow for
   cascading of RSIP servers.  For example, RSIP server A may assign
   some number of public IP addresses and port sets to RSIP server B,
   which is entirely inside of the private network.  RSIP server B will
   then assign some of these addresses and port sets to private hosts.
   This architecture conforms to the model in which a corporation (in
   charge of RSIP server B) buys public network access from an ISP (in
   charge of RSIP server A). In this scenario, RSIP server B and end
   hosts within the corporation could be considered the RSIP client of
   RSIP server A and RSIP server B respectively.

   2.1.  RSIP Parameter Negotiation



Borella et al.            Expires October 1999                  [Page 4]

INTERNET-DRAFT  Realm Specific IP: Protocol Specification     April 1999


      An RSIP client initiates a binding request with an RSIP server by
      transmitting a REGISTER_REQUEST message.  This allows the RSIP
      server to become aware of the RSIP client.  The RSIP server will
      assign a unique identifier to the RSIP client.

      An RSIP client must then use one of the ASSIGN_REQUEST messages to
      request an IP address, port set and/or other parameters from the
      public realm.  Negotiation of tunnel type may also occur. These
      parameters will be assigned with a lease time, after which their
      assignment must be renewed.  After parameters have been assigned,
      the RSIP client may use the parameters to transmit packets to the
      public network.  The RSIP method is also specified in the
      ASSIGN_REQUEST message.

      If an RSIP client no longer needs some parameters that it has been
      assigned, it may release them by transmitting a FREE_REQUEST
      message to the RSIP server, and specifying the parameters to
      release within that message.

      If an RSIP client no longer needs to communicate with the public
      network, it may use the DE-REGISTER_REQUEST message to notify the
      RSIP server of such.  Use of the DE-REGISTER_REQUEST message
      effectively releases all of the RSIP client's parameters.  It must
      register and be assigned parameters once more before it transmits
      packets to the public network again.

      The ERROR_RESPONSE message may be used at any time by the RSIP
      server to indicate that an RSIP client's request was denied or
      malformed.

      All *_REQUEST messages from an RSIP client are replied to by with
      either the appropriate *_RESPONSE message, or and ERROR_RESPONSE
      by the RSIP server.

      An RSIP server may deallocate the parameters of a given client
      with the DEALLOCATE message.

   2.2.  Operation

      In the case of RSA-IP, an RSIP client MUST request an IP address,
      but not any ports.  In RSAP-IP method, an RSIP client MUST request
      an IP address and a port range in the same ASSIGN_REQUEST message.

      If the resources requested are temporarily unavailable, an RSIP
      server MAY either commit a subset of the resources requested or
      return an ERROR message indicating that the requested resource was
      temporarily unavailable.  An RSIP client is free to attempt
      another ASSIGN_REQUEST for the same or other resources after an



Borella et al.            Expires October 1999                  [Page 5]

INTERNET-DRAFT  Realm Specific IP: Protocol Specification     April 1999


      interval of time.  An RSIP server MUST NOT allocate ports without
      an associated IP address.

      An RSIP server MAY allow freeing to be done on a subset of an
      assigned port range for RSAP-IP. Child ranges as a result of a
      subset free MUST retain the same binding.  If an RSIP server
      receives a FREE_REQUEST message that refers to parameters not
      assigned to the originating RSIP client, an ERROR_RESPONSE message
      indicating that the parameter range was invalid MUST be returned.
      If an RSIP server receives a FREE message referring to an unknown
      binding, an ERROR_RESPONSE message indicating that the binding is
      unknown MUST be returned.

      If an RSIP client wishes to extend the duration of an existing
      binding, an ASSIGN_REQUEST with the same Bind ID and the desired
      extension duration MAY be sent. The RSIP server SHOULD either
      grant the request, grant a smaller duration than that requested or
      deny the request. If a smaller duration is granted, this duration
      MUST be included in the response message to the ASSIGN_REQUEST. In
      the case when the request is denied, the appropriate
      ERROR_RESPONSE MUST be sent.

      RSIP servers SHOULD NOT forward packets from a RSIP client without
      checking the validity of the packets' demultiplexing parameters.
      Other necessary policy based routing checks SHOULD also be made.
      Improper use of demultiplexing parameters or other parameters, or
      any RSIP client using a resource or parameter assigned to a
      different RSIP client are auditable events.

      Note that the RSIP control protocol operates on a simple
      request/response basis, as described above.  However, an RSIP
      client MAY transmit an OK message upon receiving a response from
      an RSIP server. Such OK messages serve to complete a three-way
      handshake and are useful for verifying the authenticity of a
      request.  However, use of a three-way handshake over an unreliable
      transport mechanism leads to more complicated client and server
      state maintenance.


      If an RSIP server must deallocate the resources associated with an
      RSIP client's Bind ID, it may do so with a DEALLOCATE message.
      This message must be followed by an OK message from the RSIP
      client.

   2.3.  Subnet Query

      In some cases it is not possible for an RSIP client to know
      whether a packet should be tunneled to the RSIP server or



Borella et al.            Expires October 1999                  [Page 6]

INTERNET-DRAFT  Realm Specific IP: Protocol Specification     April 1999


      transmitted using the local (private) routing realm only. The RSIP
      protocol provides a subnet query mechanism through which an RSIP
      client may query an RSIP server to ask whether a particular subnet
      falls within the private domain.  An RSIP client queries the
      server using the QUERY_REQUEST message with the subnet included in
      the IP address field of the message. The RSIP server uses the
      QUERY_RESPONSE to reply to this message.  The RSIP server MAY
      confirm the subnet queried or MAY return the whole range of
      subnets supported so as to enable the RSIP client to cache the
      entries.  The RSIP server may be manually configured to know the
      topology of the private domain.

   2.4.  Unreliable Transport

      A message ID field SHOULD be included in all messages if UDP, or
      some other unreliable transport mechanism, is used. The message ID
      starts with zero in the client's REGISTER_REQUEST message and end
      with a maximum value in the server's DE-REGISTER_RESPONSE message.
      This field SHOULD be incremented by one for every request issued.
      Responses MUST include the same message ID as that of the request
      which it acknowledges.

      If an RSIP client does not receive a response from the RSIP server
      for a request, a new request with the same message ID MAY be
      issued after an interval of time.  An RSIP server receiving a
      request with a message ID smaller than what it previously received
      (within a REGISTERed session) SHOULD ignore the request.
      Pipelining of requests and aggregation of responses MUST NOT be
      allowed.

      Message ID wraparound is highly unlikely, however it must be
      considered in both the RSIP clients and servers.

   2.5.  Parameter Assignment Transport and Mechanisms

      In order to assign parameters to the RSIP client from the RSIP
      server, a transport protocol and an assignment mechanism must be
      used. Design of the RSIP protocol aims to be transport
      independent, so that existing transport protocols such as UDP or
      TCP can be used.

      The assignment mechanisms MAY be DHCP, COPS, DIAMETER or some
      similar protocol.  While these protocols would allow nearly-
      arbitrary parameters to be assigned to the RSIP clients, our
      current goal is to determine the parameters that are necessary for
      RSIP to operate in full generality, and define a basic protocol
      with which these parameters can be negotiated and assigned.  Once
      the fundamental requirements of RSIP parameter assignment are



Borella et al.            Expires October 1999                  [Page 7]

INTERNET-DRAFT  Realm Specific IP: Protocol Specification     April 1999


      specified, it may either be integrated into an existing protocol
      or left alone as its own protocol.

      Extending DHCP to support RSIP parameter assignment is
      particularly advantageous because it would implicitly support
      router pass through of RSIP requests to RSIP servers that are not
      present on an RSIP client's local network.

3.  General Message and Parameter Formats

   In this section we define the general message and parameter format.
   Codes for each parameter and message types will be discussed the
   following sections.  Within an RSIP control packet, the parameters
   MAY appear in any order, but it is recommended that required
   parameters precede all optional parameters.

   The general message format is shown below.

       1 byte      Variable        Variable
   +-----------+---------------+-------------------
   |    Type   |  Parameter 1  |  Parameter 2 ...
   +-----------+---------------+-------------------

   The type field indicates how the parameters are to be interpreted
   (e.g., request, response, error, etc.).

   The general format of all parameters is shown below.

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

   All parameters consist of a fixed portion and a variable portion.
   The fixed portion is a 1 byte code value and a 2 byte length. The
   remaining portion of the parameter is the parameter value, the length
   which is the number of bytes indicated by the length field.

4.  Parameter Types and Formats

   4.1.  IP Address Request

        Code   Length
      +------+--------+
      |  0   |    0   |
      +------+--------+

      Used in ASSIGN_REQUEST messages to request an IP address.



Borella et al.            Expires October 1999                  [Page 8]

INTERNET-DRAFT  Realm Specific IP: Protocol Specification     April 1999


   4.2.  Number of Ports

        Code   Length    Number of Ports
      +------+--------+-------------------+
      |  1   |    1   |      (1 byte)     |
      +------+--------+-------------------+

      Used in ASSIGN_REQUEST messages to request a particular number of
      ports to be assigned.

   4.3.  IP Address

        Code   Length        IP Address
      +------+--------+-----------------------+
      |  2   |    4   |      (4 bytes)        |
      +------+--------+-----------------------+

      This field represents the IPv4 address negotiated. Used in
      ASSIGN_RESPONSE, QUERY_REQUEST and QUERY_RESPONSE messages.

   4.4.  Port Range

        Code   Length    Low Port    High Port
      +------+--------+-----------+-----------+
      |  3   |    4   | (2 bytes) | (2 bytes) |
      +------+--------+-----------+-----------+

      The range of ports allocated to an RSIP client.  The port range
      MUST be contiguous and is inclusive.

   4.5.  Lease Time

        Code   Length         Lease Time
      +------+--------+-----------------------+
      |  4   |    4   |       (4 bytes)       |
      +------+--------+-----------------------+

      Number of seconds that an RSIP client may retain the parameters
      assigned by an RSIP server.

   4.6.  Error

        Code   Length     Error
      +------+--------+-----------+
      |  5   |    2   | (2 bytes) |
      +------+--------+-----------+

      These error codes allow an RSIP server to inform an RSIP client



Borella et al.            Expires October 1999                  [Page 9]

INTERNET-DRAFT  Realm Specific IP: Protocol Specification     April 1999


      why a particular request has failed.

      0 Unknown error - An error that cannot be identified has occurred
      1 Bind ID not found -  The request refers to an invalid Bind ID.
      2 Client ID not found - The request refers to an invalid Client ID.
      3 Invalid message - The request does not contain an mandatory
           parameter or cannot be parsed.
      4 RSIP method not supported - The request refers to an RSIP method not
           supported by the RSIP server.
      5 Not authorized - The RSIP client is not authorized to make the
           request.
      6 Tunnel type not supported - The request refers to a tunnel type
           that the RSIP server does not support.
      7 Wrong message ID - The request used a message ID that
           the RSIP server did not expect.
      8 Address resource unavailable: The RSIP server was not able to
           allocate an IP address.
      9 Port resource unavailable: The RSIP server was not able to allocate
              port(s).

   4.7.  Client ID

        Code   Length        Client ID
      +------+--------+-------------------+
      |  6   |    4   |      (4 bytes)    |
      +------+--------+-------------------+

      A unique number assigned by an RSIP server when an RSIP client
      registers with the server. It is used to identify the RSIP client.

   4.8.  Bind ID

        Code   Length        Bind ID
      +------+--------+-------------------+
      |  7   |    4   |      (4 bytes)    |
      +------+--------+-------------------+

      The Bind ID is a unique number allocated for each new assignment.
      It is returned as part of an ASSIGN_RESPONSE to a successful
      ASSIGN_REQUEST.  Subsequent message exchanges pertaining a bind
      MUST include its Bind ID.  When a or range of parameters is
      assigned to an RSIP client, the parameter is said to be 'bound' to
      that client. More than one bind with different Bind IDs may be
      established between an RSIP client and RSIP server pair. A binding
      will expire when its lease time runs out or when the RSIP client
      de-registers itself with the RSIP server.

   4.9.  Message ID



Borella et al.            Expires October 1999                 [Page 10]

INTERNET-DRAFT  Realm Specific IP: Protocol Specification     April 1999


      Code    Length       Message ID
      +------+--------+-------------------+
      |  8   |    1   |      (1 byte)     |
      +------+--------+-------------------+

      If the transport protocol is connectionless. such as UDP, the
      sequence number field MUST be included as a means to order the
      messages and/or match requests and responses.

   4.10.  Tunnel Type

        Code   Length   Tunnel Type
      +------+--------+------------+
      |  9   |    1   |  (1 byte)  |
      +------+--------+------------+

      The type of tunnel used between an RSIP client and an RSIP server.
      Values are assigned as follows:

      0  Reserved
      1  IP-IP
      2  GRE
      3  L2TP

   4.11.  RSIP Method

        Code   Length    RSIP Method
      +------+--------+-------------+
      |  10  |    1   |  (1 byte)   |
      +------+--------+-------------+

      The RSIP method that the server will support.

      1 Realm Specific Address IP (RSA-IP) method.
      2 Realm Specific Address and Port IP (RSAP-IP) method.

   4.12.  Vendor Specific Parameter

        Code    Length    Vendor ID     Subcode    Parameter
      +------+----------+------------+-----------+-----------+
      |  11  |   n+4    | (2 bytes)  | (2 bytes) | (n bytes) |
      +------+----------+------------+-----------+-----------+

      This parameter allows vendors to specify vendor specific
      information. The Vendor ID field the vendor-specific ID assigned
      by IANA.  Subcodes are defined and used by each vendor.





Borella et al.            Expires October 1999                 [Page 11]

INTERNET-DRAFT  Realm Specific IP: Protocol Specification     April 1999


5.  Message Type

   Apart from the message type field, which MUST appear at the beginning
   of each message, other parameters MAY appear in any order.  Note that
   message sequencing MAY need to be introduced depending on the
   transport.  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.  Message type numbers
   are defined below.

5.1.  Message Type Numbers

   Numbers are assigned to message types as follows:

    1 ERROR_RESPONSE
    2 REGISTER_REQUEST
    3 REGISTER_RESPONSE
    4 DE-REGISTER_REQUEST
    5 DE-REGISTER_RESPONSE
    6 ASSIGN_REQUEST
    7 ASSIGN_RESPONSE
    8 FREE_REQUEST
    9 FREE_RESPONSE
   10 QUERY_REQUEST
   11 QUERY_RESPONSE
   12 DEALLOCATE
   13 OK


   5.2.  ERROR_RESPONSE

      An ERROR_RESPONSE is used to provide error messages to an RSIP
      client message.  If the error is related to a particular Client ID
      or Bind ID, these parameters MUST be included.  Multiple errors
      MAY be reported in the same ERROR_RESPONSE.

         <ERROR_RESPONSE>::= <Message Type> <Error Parameter>
                             [<Message ID>][<Client ID>]
                             [<Bind ID>]

   5.3.  REGISTER_REQUEST

      The REGISTER_REQUEST message is used by an RSIP client to register
      with an RSIP server.  An RSIP client MUST register before it
      requests parameters from the RSIP server.






Borella et al.            Expires October 1999                 [Page 12]

INTERNET-DRAFT  Realm Specific IP: Protocol Specification     April 1999


         <REGISTER_REQUEST> ::= <Message Type> [<Message ID>]

   5.4.  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.

         <REGISTER_RESPONSE> ::= <Message Type> <Client ID> [<Message ID>]

   5.5.  DE-REGISTER_REQUEST

      The DE-REGISTER_REQUEST message is used by an RSIP client to de-
      register with an RSIP server.

         <DE-REGISTER_REQUEST> ::= <Message Type> <Client ID> [<Message ID>]


   5.6.  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> ::= <Message Type> <Client ID> [<Message ID>]


   5.7.  ASSIGN_REQUEST

      The ASSIGN_REQUEST message is used by an RSIP client to request
      parameter assignments. In RSA-IP method, ASSIGN_REQUEST_ADDR
      format MUST be used and an IP address MUST be requested. For RSAP-
      IP, ASSIGN_REQUEST_PORT format MUST be used, and a port range MUST
      be requested for every IP address requested.  When requesting a
      renewal of a previously-assigned, but not yet expired lease,
      ASSIGN_REQUEST_EXT format MUST be used, and a valid Bind ID MUST
      be specified.  All types of ASSIGN_REQUEST message share the same
      message type. The RSIP client MAY list all of the tunnel types
      supported.  The default tunnel type is IP-IP; thus, if no tunnel
      type is specified, the RSIP server MUST assume that IP-IP
      tunneling will be used, unless a different type of tunnel is
      implied by the RSIP method.  All RSIP implementations MUST support
      IP-IP tunneling.










Borella et al.            Expires October 1999                 [Page 13]

INTERNET-DRAFT  Realm Specific IP: Protocol Specification     April 1999


         <ASSIGN_REQUEST_ADDR> ::= <Message Type> <Client ID>
                                   <RSIP method = RSA-IP> <IP Addr Req>
                                   [<Lease Time>] [<TunnelType>...]
                                   [<Message ID>]

         <ASSIGN_REQUEST_PORT> ::= <Message Type> <Client ID>
                                   <RSIP method = RSAP-IP> <IP Addr Req>
                                   <Number of Ports> [<Lease Time>]
                                   [<TunnelType>...] [<Message ID>]

         <ASSIGN_REQUEST_EXT> ::= <Message Type> <Client ID>
                                  <Bind ID> [<Lease Time>] [<Message ID>]

   5.8.  ASSIGN_RESPONSE

      The ASSIGN_RESPONSE message is used by an RSIP server to deliver
      parameter assignments to an RSIP client.  A client-wise unique
      Bind ID must be provided for every assignment.  If a lease time is
      not requested by an RSIP client, an RSIP server MUST assign a
      default lease time.  If an ASSIGN_REQUEST is not granted, the
      appropriate ERROR_RESPONSE message(s) MUST be generated,
      specifying all reasons why the ASSIGN_REQUEST failed.  If the
      requested RSIP method is not supported, the RSIP server MUST NOT
      allocate any resources.  For RSA-IP, ASSIGN_RESPONSE_ADDR is used.
      For RSAP-IP, ASSIGN_RESPONSE_PORT is used.  When a lease extension
      is granted, ASSIGN_RESPONSE_EXT is used.  All types of
      ASSIGN_RESPONSE message share the same message type.  Note that
      the chosen tunnel type MUST be included in the message, except for
      extension requests and when the RSIP method implies that a
      particular type of tunnel must be used.

         <ASSIGN_RESPONSE_ADDR> ::= <Message Type> <Client ID> <Bind ID>
                                    <RSIP method = RSA-IP>  <IP Address>
                                    <Lease Time> <Tunnel Type> [<Message ID>]

         <ASSIGN_RESPONSE_PORT> ::= <Message Type> <Client ID> <Bind ID>
                                    <RSIP method = RSAP-IP> <IP Address>
                                    <Port Range> <Lease Time> <Tunnel Type>
                                    [<Message ID>]

         <ASSIGN_RESPONSE_EXT> ::= <Message Type> <Client ID>
                                   <Bind ID> <Lease Time>
                                   [<Message ID>]

   5.9.  FREE_REQUEST

      The FREE_REQUEST message is used by an RSIP client to free
      parameter assignments.  The given Bind ID identifies the IP



Borella et al.            Expires October 1999                 [Page 14]

INTERNET-DRAFT  Realm Specific IP: Protocol Specification     April 1999


      address and/or port range being freed.  Resources may only be
      freed using the granularity of a Bind ID.

         <FREE_REQUEST> ::= <Message Type> <Client ID> <Bind ID>
                            [<Message ID>]


   5.10.  FREE_RESPONSE

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

         <FREE_RESPONSE> ::= <Message Type> <Client ID> <Bind ID>
                             [<Message ID>]


   5.11.  QUERY_REQUEST

      A QUERY_REQUEST message is used by an RSIP client to request if a
      subnet or IP address is supported by an RSIP server.  If a subnet
      is queried, it is placed in an IP address parameter.

         <QUERY_REQUEST> ::= <Message Type> <Client ID> <IP address>
                             [<Message ID>]

   5.12.  QUERY_RESPONSE

      A QUERY_RESPONSE message is used by an RSIP server to answer a
      QUERY_REQUEST from an RSIP client.  The RSIP server SHOULD respond
      with a list of all subnets and/or addresses that are on the
      private side of the network.

         <QUERY_RESPONSE> ::= <Message Type> <Client ID> <IP address>
                              [<IP address>...] [<Message ID>]

   5.13.  DEALLOCATE

      A DEALLOCATE message is used by an RSIP server to force an RSIP
      client to relinquish specified resources (e.g., in the case of a
      lease expiration).  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 response to the server.

         <DEALLOCATE> ::= <Message Type> <Client ID> <Bind ID>
                          [<Message ID>]

   5.14.  OK



Borella et al.            Expires October 1999                 [Page 15]

INTERNET-DRAFT  Realm Specific IP: Protocol Specification     April 1999


      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.

         <OK> ::= <Message Type> <Client ID> [<Message ID>]



6.  Miscellaneous Issues

   TCP TIME_WAIT at external servers: When a TCP server disconnects a
      socket, it enters the TCP TIME_WAIT state for a period of time.
      While it is in this state it will refuse to accept new connections
      using the same socket (i.e., the same source address/port and
      destination address/port).  Consider the circumstance in which an
      RSIP client terminates a connection with an external server, and
      immediately frees the port that it was using to source the
      connection (alternatively, the port may be deallocated by the RSIP
      server).  If the RSIP server immediately allocates this port to
      another RSIP client, and this client uses the same port to contact
      the same external server while that server is still in TIME_WAIT,
      then the client's connection may be rejected by the server.  In
      order to mitigate this problem, it is recommended that RSIP
      servers hold recently deallocated ports for at least two minutes,
      which is the greatest duration of TIME_WAIT that is commonly
      implemented [STEV94].  In situations where ports are scarce, the
      RSIP server MAY choose to allocate ports in a FIFO fashion from
      the pool of recently deallocated ports.

   Split DNS: RSIP requires that DNS traffic from the private network
      not be propagation on the public network.  This issue is not
      specific to RSIP - it also occurs in NAT.

   ICMP: Like NAT, RSIP server are required to remember recent ICMP
      packets for which responses cannot be demultiplexed by port number
      (i.e., echo request packets).  This issue is not specific to RSIP
      - it also occurs in NAT.

   External access to internal servers: RSIP does not resolve how
      external hosts are able to access internal servers.  This issue is
      not specific to RSIP - it also occurs in NAT. See [RSIP-FRAME].


7.  Security Considerations

   RSIP, in and of itself, does not provide security.  It may provide
   the illusion of security or privacy by hiding a private address



Borella et al.            Expires October 1999                 [Page 16]

INTERNET-DRAFT  Realm Specific IP: Protocol Specification     April 1999


   space, but security can only be ensured by the proper use of security
   protocols and cryptographic techniques.

   An RSIP implementation must be guarded against potential denial- of-
   service attacks.  A malicious RSIP client may be able to determine
   the parameters associated with another RSIP client via packet
   sniffing.  An attacker could use or free the resources allocated by
   the RSIP server by spoofing a data packet or a FREE request,
   respectively.  It is desirable to secure negotiation between an RSIP
   client and RSIP server with an appropriate authentication mechanism.
   This general problem is not specific to RSIP - DHCP suffers from the
   same lack of authentication.  However, this security hole is
   mitigated to some extent by the following: (1) It is much more
   difficult to sniff packets if the RSIP clients are on a switched LAN,
   and this is the direction that the industry is moving towards, (2)
   use of the RSIP Bind ID and message IDs prevents some simple attacks
   such as packet replay, and (3) all RSIP clients must answer to the
   authority to which they are borrowing resources from; therefore, once
   detected, an attacker can be dealt with administratively.  Note that
   although IPSEC could be used for securing the channel between the
   RSIP client and the RSIP server, it would require implementations on
   both the client and the server, and may prove to be too heavyweight
   for practical purposes.

8.  To Do
      - Domains with multiple RSIP servers.
      - Bi-directional RSIP w/ DNS.

9.  Changelog

   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.



Borella et al.            Expires October 1999                 [Page 17]

INTERNET-DRAFT  Realm Specific IP: Protocol Specification     April 1999


         - 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.

10.  Acknowledgements

   The authors would like to thank Gabriel Montenegro, Pyda Srisuresh,
   Dan Nessett, Gary Jaszewski, and Rick Cobb for their input.


11.  Appendix: Example RSIP client/server transactions

   In this appendix, we present an exemplary series of 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'.  Message types and message ID's are not
   included in order to save space.

   C --> S: REGISTER_REQUEST ()

      The client attempts to register with the server.

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

      The server responds, assigning a Client ID of 1.

   C --> S: ASSIGN_REQUEST_PORT: (Client ID = 1, RSIP method = RSAP-IP,
      IP Address Request, Num Ports = 16, Lease Time = 3600 Tunnel type
      = IP-IP, Tunnel type = GRE)

      The client requests an IP address and 16 ports to use with it with
      RSAP-IP.  The client indicates that it would like to use these
      resources for 3600 seconds with either IP-IP and GRE tunneling.

   S --> C: ASSIGN_RESPONSE_PORT: (Client ID = 1, RSIP method = RSAP-IP,
      Bind ID = 0, IP address = 149.112.240.156, Port range = 9000-9015,
      Lease time = 1800, Tunnel type = IP-IP)

      The server responds by indicating that a Bind ID of 0 has been
      assigned to the resources of an IP address of 149.112.240.156 and
      a port range of 9000-9015 to be used for RSAP-IP.  The server also
      indicates that it will grant a lease time of only 1800 seconds,
      and indicates that IP-IP tunneling will be used.




Borella et al.            Expires October 1999                 [Page 18]

INTERNET-DRAFT  Realm Specific IP: Protocol Specification     April 1999


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

   C --> S: QUERY_REQUEST: (Client ID = 1, IP address = 10.20.60.0)

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

   S --> C: QUERY_RESPONSE: (Client ID = 1, IP address = 10.20.60.0, IP
      address = 10.20.66.0, IP address = 10.20.68.0)

      The server responds with a list of local subnets, implicitly
      informing the client that subnet 10.20.60.0 is local.

   C --> S: ASSIGN_REQUEST_PORT: (Client ID = 1, RSIP method = RSAP-IP,
      IP Address Request, Num Ports = 8, Lease Time = 1800)

      The client requests 8 more ports for use with RSAP-IP.  A lease of
      1800 seconds is requested.  IP-IP tunneling is implied by default.

   S --> C: ASSIGN_RESPONSE_PORT: (Client ID = 1, RSIP method = RSAP-IP,
      Bind ID = 1, IP address = 149.112.240.156, Port range = 9074-9081,
      Lease time = 1800)

      The server grants the request, assigning ports 9074-9081 from IP
      address 149.112.240.156. IP-IP tunneling is implied by default.

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

      The client frees Bind ID 0; i.e., ports 9000-9015 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
      9074-9081.

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

      The server acknowledges that Bind ID 0 has been freed.

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

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

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

      The server confirms the request.




Borella et al.            Expires October 1999                 [Page 19]

INTERNET-DRAFT  Realm Specific IP: Protocol Specification     April 1999


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

      The server forces the client to deallocate the resources of Bind
      ID 1.

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

      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.

12.  References

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

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

   [NAT-TERM] P. Srisuresh and M. Holdrege, "NAT: Terminology and
      considerations," Internet Draft <draft-ietf-nat-
      terminology-02.txt>, Apr. 1999 (work in progress).

   [STEV94] W. R. Stevens, "TCP/IP Illustrated, Vol. 1," Addison-Wesley,
      1994.



13.  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



Borella et al.            Expires October 1999                 [Page 20]

INTERNET-DRAFT  Realm Specific IP: Protocol Specification     April 1999


   (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


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

      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 October 1999                 [Page 21]


Html markup produced by rfcmarkup 1.108, available from http://tools.ietf.org/tools/rfcmarkup/