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

Versions: 00 01 02 03 04 05 06 RFC 3103

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

                                                           J. Lo
                                                           K. Tuniguchi
                                                           NEC USA

                                                           March 2000


               Realm Specific IP: Protocol Specification
                 <draft-ietf-nat-rsip-protocol-06.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 host and gateway, so that the host can
   lease some of the gateway's addressing parameters in order to
   establish a global network presence.  This protocol is designed to
   operate on the application layer and to use its own TCP or UDP port.
   In particular, the protocol allows a gateway to allocate addressing
   and control parameters to a host such that a flow policy can be
   enforced at the gateway.

1.  Introduction



Borella et al.           Expires September 2000                 [Page 1]

INTERNET-DRAFT  Realm Specific IP: Protocol Specification     March 2000


   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 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 hosts
   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 gateway (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 host.
   An RSIP host 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 host, but this system allows packets to maintain
   their integrity from RSIP host to their destination.  ALGs are not
   required in the RSIP gateway.

   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 gateway in each packet bound for the second routing realm.

   This draft discusses a method for assigning parameters to an RSIP
   host from an RSIP gateway.  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].
   Extensions to this protocol that enable end-to-end IPSEC are
   discussed in [RSIP-IPSEC].

2.  Specification of Requirements

   The keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT",



Borella et al.           Expires September 2000                 [Page 2]

INTERNET-DRAFT  Realm Specific IP: Protocol Specification     March 2000


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

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 Host

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

   RSIP Gateway

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

   RSIP Client

      An application program that performs the client portion of the
      RSIP client/server protocol.  An RSIP client application MUST
      exist on all RSIP hosts, and MAY exist on RSIP gateways.

   RSIP Server

      An application program that performs the server portion of the
      RSIP client/server protocol.  An RSIP server application MUST
      exist on all RSIP gateways.

   RSA-IP: Realm Specific Address IP

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



Borella et al.           Expires September 2000                 [Page 3]

INTERNET-DRAFT  Realm Specific IP: Protocol Specification     March 2000


   RSAP-IP: Realm Specific Address and Port IP

      An RSIP method in which each RSIP host is allocated an IP address
      (possibly shared with other RSIP hosts) 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 address, one or more
      local ports, a remote address, and a remote port with an RSIP
      host.

   Resource

      A general way to refer to an item that an RSIP host leases from an
      RSIP gateway; e.g., an address or port.

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

4.  Architecture

   For simplicity, in the remainder of this document we will assume that
   the RSIP hosts 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. (This assumption is made without
   loss of generality and the ensuing discussion applies to more general
   cases.) The RSIP gateway 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.

         RSIP Host             RSIP Gateway                    Host

            Xa                    Na   Nb                      Yb
         [X]------( Addr sp. A )----[N]-----( Addr sp. B )-------[Y]
                  (  Network   )            (  Network   )

   Hosts X and Y belong to different addressing realms A and B,
   respectively, and N is an RSIP gateway (which may also perform NAT
   functions).  N has two interfaces: Na on address space A, and Nb on
   address space B. N may have a pool of addresses in address space B
   which it can assign to or lend to X and other hosts in address space
   A.  These addresses are not shown above, but they can be denoted as
   Nb1, Nb2, Nb3 and so on.



Borella et al.           Expires September 2000                 [Page 4]

INTERNET-DRAFT  Realm Specific IP: Protocol Specification     March 2000


   Host X, needing to establish an end-to-end connection to a network
   entity Y situated within address space B, first negotiates and
   obtains assignment of the resources from the RSIP gateway. Upon
   assignment of these parameters, the RSIP gateway creates a mapping,
   of X's addressing information and the assigned resources. This
   binding enables the RSIP gateway to correctly de-multiplex and
   forward inbound traffic generated by Y for X. A lease time is
   associated with each bind.

   Using the public parameters assigned by the RSIP gateway, RSIP hosts
   tunnel data packets across address space A to the RSIP gateway. The
   RSIP gateway acts as the end point of such tunnels, stripping off the
   outer headers and routing the inner packets onto the public realm. As
   mentioned above, an RSIP gateway maintains a mapping of the assigned
   public parameters as demultiplexing fields for uniquely mapping them
   to RSIP host private addresses.  When a packet from the public realm
   arrives at the RSIP gateway and it matches a given set of
   demultiplexing fields, then the RSIP gateway will tunnel it to the
   appropriate RSIP host.  The tunnel headers of outbound packets from X
   to Y, given that X has been assigned Nb, are as follows:

   +---------+---------+---------+
   | X -> Na | Nb -> Y | payload |
   +---------+---------+---------+

   There are two basic flavors of RSIP: RSA-IP and RSAP-IP.  RSIP hosts
   and gateways MUST support RSAP-IP and MAY support RSA-IP.  Details of
   RSA-IP and RSAP-IP are found in [RSIP-FRAME].

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 gateways MUST support TCP, and SHOULD support UDP.  Due to the
   fact that RSIP may be deployed across a wide variety of network
   links, RSIP hosts SHOULD support TCP.  However, RSIP hosts MAY
   support UDP instead.  For RSIP hosts and gateways 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 host and gateway have established a registration using either
   TCP or UDP, they may not switch between the two protocols for the
   duration of the registration.

6.  Host / Gateway Relationships




Borella et al.           Expires September 2000                 [Page 5]

INTERNET-DRAFT  Realm Specific IP: Protocol Specification     March 2000


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

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

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

      Assigned: The RSIP gateway has granted one or more bindings of
         resources to the host.  The gateway will forward and deliver
         globally addressed packets on behalf of the host.

   Architectures in which an RSIP host is simultaneously registered with
   more than one RSIP gateway are possible.  In such cases, an RSIP host
   may be in different relationships with different RSIP gateways at the
   same time.

7.  Gateway Flow Policy and State

   Since an RSIP gateway is likely to reside on the boundary between two
   or more different administrative domains, it is desirable to enable
   an RSIP gateway to be able to enforce flow-based policy.  In other
   words, an RSIP gateway 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 gateway does not care about the flow
   parameters used by RSIP hosts. 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 gateway has over the local addressing parameters that an RSIP
      host uses for particular sessions.




Borella et al.           Expires September 2000                 [Page 6]

INTERNET-DRAFT  Realm Specific IP: Protocol Specification     March 2000


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

      Under micro-flow policy, a host is allocated exactly one port at a
      time.  The host may request more ports, also one at a time.  This
      policy gives the gateway very tight control over local port use,
      although it affords the host 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 gateway has over the remote (public) hosts with which an RSIP
      host communicates.  In particular, remote flow policy dictates
      what level of detail that a host must specify addressing
      parameters of a remote host or application before the RSIP gateway
      allows the host to communicate with that host or application.

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

      Macro-flow policy requires that the host 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 host 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 host may contact any port number at the
      remote host without explicitly notifying the gateway.

      Micro-flow policy requires that the host 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 host MUST use the specified local
      parameters only with the remote address and port specified, and
      MUST NOT communicate with the remote address and port using any
      local parameters but the ones allocated.



Borella et al.           Expires September 2000                 [Page 7]

INTERNET-DRAFT  Realm Specific IP: Protocol Specification     March 2000


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

  7.3.  Gateway State

      An RSIP gateway must maintain state for all RSIP hosts and their
      assigned resources.  The amount and type of state maintained
      depends on the local and remote flow policy.  The required RSIP
      gateway 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 gateway serving an RSIP host using the RSA-IP method
         MUST maintain the following minimum state to ensure proper
         mapping of incoming packets to RSIP hosts:

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

      7.3.2.  RSAP-IP State

         An RSIP gateway serving an RSIP host using the RSAP-IP method
         MUST maintain the following minimum state to ensure proper
         mapping of incoming packets to RSIP hosts:

         - Host's private address
         - Host's assigned public address(es)
         - Host's assigned port(s) per address

      7.3.3.  Flow State

         Regardless of whether the gateway 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 gateway is using macro-flow based remote policy, the
         following state must be maintained:

            - Remote host's address

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

            - Remote host's address
            - Remote host's port

         More state MAY be used by an RSIP gateway if desired.  For



Borella et al.           Expires September 2000                 [Page 8]

INTERNET-DRAFT  Realm Specific IP: Protocol Specification     March 2000


         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 host and gateway.  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, such that the total length of a parameter is the value of
   the length field plus 3.

   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.

      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



Borella et al.           Expires September 2000                 [Page 9]

INTERNET-DRAFT  Realm Specific IP: Protocol Specification     March 2000


      and omitting the value field.

      It is not valid for a host to request an address with an FQDN type
      as its local address (See specification of ASSIGN_REQUEST_RSA-IP
      and ASSIGN_REQUEST_RSAP-IP, below).

   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 (e.g., when a client application is using
      ephemeral source 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.

      If micro-flow based policy applies to a given ports parameter, it
      MUST contain exactly one port field.

      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 host parameter binding.

   8.4.  Client ID




Borella et al.           Expires September 2000                [Page 10]

INTERNET-DRAFT  Realm Specific IP: Protocol Specification     March 2000


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

      The client ID parameter specifies an RSIP client ID.

   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 host and an RSIP gateway.  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



Borella et al.           Expires September 2000                [Page 11]

INTERNET-DRAFT  Realm Specific IP: Protocol Specification     March 2000


          2      RSAP-IP

   8.8.  Error

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

        Code    Length    Value
      +-------+---------+--------+
      |  10   | 2 bytes | varies |
      +-------+---------+--------+

      An indicator parameter is a general-purpose parameter, the use of
      which is defined by the message that it appears in.  An RSIP



Borella et al.           Expires September 2000                [Page 12]

INTERNET-DRAFT  Realm Specific IP: Protocol Specification     March 2000


      message that uses an indicator parameter MUST define the meaning
      and interpretation of all of the indicator's possible values.


   8.11.  Vendor Specific Parameter

        Code    Length    Vendor ID   Subcode   Value
      +-------+---------+-----------+---------+--------+
      |  240  | 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 host or gateway SHOULD
      silently ignore vendor-specific messages that it does not
      understand.

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



Borella et al.           Expires September 2000                [Page 13]

INTERNET-DRAFT  Realm Specific IP: Protocol Specification     March 2000


     RESISTER_RESPONSE.

   - Multiple address parameters and multiple indicator 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 host
   and/or gateway may not support LISTEN_REQUEST and LISTEN_RESPONSE, or
   may only support RSAP-IP and not RSA-IP.

   9.1.  ERROR_RESPONSE

      9.1.1.  Description

         An ERROR_RESPONSE is used to provide error messages from an
         RSIP gateway to an RSIP host.  Usually, errors indicate that
         the RSIP gateway cannot or will not perform an action or
         allocate resources on behalf of the host.  If the error is
         related to a particular host ID or bind ID, these associated
         parameters MUST be included.  Multiple errors MAY NOT be
         reported in the same ERROR_RESPONSE.  In situations where more
         than one error has occurred, the RSIP gateway MUST choose only
         one error to report.

      9.1.2.  Format

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

      9.1.3.  Behavior

         An ERROR_RESPONSE message MUST only be transmitted by an RSIP
         gateway.  An RSIP host that detects an error in a message
         received from an RSIP gateway MUST silently discard the
         message.  There are no error conditions that can be caused by
         an ERROR_RESPONSE.  An ERROR_RESPONSE is typically transmitted
         in response to a request from an RSIP host.

   9.2.  REGISTER_REQUEST

      9.2.1.  Description




Borella et al.           Expires September 2000                [Page 14]

INTERNET-DRAFT  Realm Specific IP: Protocol Specification     March 2000


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


      9.2.2.  Format

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

      9.2.3.  Behavior

         The following message-specific error conditions exist:

         - If the host is already registered with the gateway, the
           gateway MUST respond with an ERROR_RESPONSE containing the
           ALREADY_REGISTERED error.

         - If the gateway's policy will not allow the host to register,
           the gateway MUST respond with an ERROR_RESPONSE containing
           the REGISTRATION_DENIED error.

   9.3.  REGISTER_RESPONSE

      9.3.1.  Description

         The REGISTER_RESPONSE message is used by an RSIP gateway to
         confirm the registration of an RSIP host, and to provide a
         client ID, flow policy, and possibly an RSIP method and tunnel
         type.

      9.3.2.  Format

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

      9.3.3.  Behavior

         An RSIP gateway MUST assign a different client ID to each host



Borella et al.           Expires September 2000                [Page 15]

INTERNET-DRAFT  Realm Specific IP: Protocol Specification     March 2000


         that is simultaneously registered with it.  The RSIP gateway
         MAY respond with one or more RSIP methods and tunnel types that
         it supports.  If an RSIP method is not specified, RSAP-IP MUST
         be assumed.  If a tunnel type is not specified, IP-IP MUST be
         assumed.

   9.4.  DE-REGISTER_REQUEST

      9.4.1.  Description

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

      9.4.2.  Format


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

      9.4.3.  Behavior

         The following message-specific error conditions exist:

         - If the host is not registered with the gateway, the gateway
           MUST respond with an ERROR_RESPONSE containing the
           REGISTER_FIRST error.

         - If the message contains an incorrect client ID, the gateway
           MUST respond with an ERROR_RESPONSE containing the
           BAD_CLIENT_ID error.

         If there are no errors that result from this message, the
         gateway MUST respond with an appropriate DE-REGISTER_RESPONSE.
         Upon de-registering a host, an RSIP gateway must delete all
         binds associated with that host and return their resources to
         the pool of free resources.  Once a host has de-registered, it
         may not use any of the RSIP gateway's resources without
         registering again.

   9.5.  DE-REGISTER_RESPONSE

      9.5.1.  Description

         The DE-REGISTER_RESPONSE message is used by an RSIP gateway to



Borella et al.           Expires September 2000                [Page 16]

INTERNET-DRAFT  Realm Specific IP: Protocol Specification     March 2000


         confirm the de-registration of an RSIP host or to force an RSIP
         host to relinquish all of its bindings and terminate its
         relationship with the RSIP gateway. Upon receiving a DE-
         REGISTER_RESPONSE message, an RSIP host MUST stop all use of
         the resources that have been allocated to it by the gateway.

      9.5.2.  Format


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

      9.5.3.  Behavior

         An RSIP gateway MUST send a DE-REGISTER_RESPONSE in response to
         a valid DE-REGISTER_REQUEST. An RSIP gateway SHOULD send a DE-
         REGISTER_RESPONSE if it detects that it will no longer be able
         to perform RSIP functionality for a given host.  An RSIP host
         MUST be ready to accept a DE-REGISTER_RESPONSE at any moment.

   9.6.  ASSIGN_REQUEST_RSA-IP

      9.6.1.  Description

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

      9.6.2.  Format

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

      9.6.3.  Behavior

         The RSIP host specifies two address parameters.  The RSIP host
         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 host may place a "don't



Borella et al.           Expires September 2000                [Page 17]

INTERNET-DRAFT  Realm Specific IP: Protocol Specification     March 2000


         care" value in the address parameter.

         If macro-flow based remote policy is used, the host 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
         host 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 host may place a "don't care" value in
         the value fields of the respective address and ports
         parameters.

         The following message-specific error conditions exist:

         - If the host is not registered with the gateway, the gateway
           MUST respond with an ERROR_RESPONSE containing the
           REGISTER_FIRST error.

         - If the message contains an incorrect client ID, the gateway
           MUST respond with an ERROR_RESPONSE containing the
           BAD_CLIENT_ID error.

         - If the local address parameter is a don't care value and the
           RSIP gateway cannot allocate ANY addresses, the RSIP gateway
           MUST respond with an ERROR_RESPONSE containing the
           LOCAL_ADDR_UNAVAILABLE error.

         - If the local address parameter is not a don't care value
           there are three possible error conditions:

           o If the RSIP gateway cannot allocate ANY addresses, it MUST
             respond with an ERROR_RESPONSE containing the
             LOCAL_ADDR_UNAVAILABLE error.

           o If the RSIP gateway cannot allocate the requested address
             because it is in use, the RSIP gateway MUST respond with an
             ERROR_RESPONSE containing the LOCAL_ADDR_INUSE error.

           o If the RSIP gateway cannot allocate the requested address
             because it is not allowed by policy, the RSIP gateway MUST
             respond with an ERROR_RESPONSE containing the
             LOCAL_ADDR_UNALLOWED error.

         - If macro-flow based remote policy is used and the requested
           remote address is not allowed by the RSIP gateway's policy,
           the RSIP gateway MUST respond with an ERROR_RESPONSE
           containing the REMOTE_ADDR_UNALLOWED error.




Borella et al.           Expires September 2000                [Page 18]

INTERNET-DRAFT  Realm Specific IP: Protocol Specification     March 2000


         - If micro-flow based remote policy is used and the requested
           remote address / port pair is not allowed by the RSIP
           gateway's policy, the RSIP gateway MUST respond with an
           ERROR_RESPONSE containing the REMOTE_ADDRPORT_UNALLOWED
           error.

         - If an unsupported or unallowed tunnel type is specified, the
           RSIP gateway MUST respond with an ERROR_RESPONSE containing
           the BAD_TUNNEL_TYPE error.

         - If the host has not specified local or remote address or port
           information in enough detail, the RSIP gateway MUST respond
           with an ERROR_RESPONSE containing the FLOW_POLICY_VIOLATION
           error.

   9.7.  ASSIGN_RESPONSE_RSA-IP

      9.7.1.  Description

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

      9.7.2.  Format


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

      9.7.3.  Behavior

         If no remote flow policy is used, the RSIP gateway 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



Borella et al.           Expires September 2000                [Page 19]

INTERNET-DRAFT  Realm Specific IP: Protocol Specification     March 2000


         associated request.

         If the host detects an error or otherwise does not "understand"
         the gateway's response, it SHOULD send a FREE_REQUEST with the
         bind ID from the said ASSIGN_RESPONSE_RSA-IP.  This will serve
         to help synchronize the states of the host and gateway.

   9.8.  ASSIGN_REQUEST_RSAP-IP

      9.8.1.  Description

         The ASSIGN_REQUEST_RSAP-IP message is used by an RSIP host to
         request resources to use with RSAP-IP.  The RSIP host 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.

      9.8.2.  Format

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

      9.8.3.  Behavior

         An RSIP host may request a particular local address by placing
         that address in the value field of the first address parameter.
         The RSIP host 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 host may place
         a "don't care" value in the respective address or ports
         parameters.

         If macro-flow based remote policy is used, the host 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 host MUST specify the remote address and port number(s)
         that it will use this binding (if granted) to contact. If no
         flow policy is used, the RSIP host may place a value of all 0's



Borella et al.           Expires September 2000                [Page 20]

INTERNET-DRAFT  Realm Specific IP: Protocol Specification     March 2000


         in the value fields of the respective address or port
         parameters.

         The following message-specific error conditions exist:

         - If the host is not registered with the gateway, the gateway
           MUST respond with an ERROR_RESPONSE containing the
           REGISTER_FIRST error.

         - If the message contains an incorrect client ID, the gateway
           MUST respond with an ERROR_RESPONSE containing the
           BAD_CLIENT_ID error.

         - If the local address parameter is a don't care value and the
           RSIP gateway cannot allocate ANY addresses, the RSIP gateway
           MUST respond with an ERROR_RESPONSE containing the
           LOCAL_ADDR_UNAVAILABLE error.

         - If the local address parameter is not a don't care value
           there are five possible error conditions:

           o If the RSIP gateway cannot allocate ANY addresses, it MUST
             respond with an ERROR_RESPONSE containing the
             LOCAL_ADDR_UNAVAILABLE error.

           o If the RSIP gateway cannot allocate the requested address
             because it is in use, the RSIP gateway MUST respond with an
             ERROR_RESPONSE containing the LOCAL_ADDR_INUSE error.

           o If the RSIP gateway cannot allocate the requested address
             because it is not allowed by policy, the RSIP gateway MUST
             respond with an ERROR_RESPONSE containing the
             LOCAL_ADDR_UNALLOWED error.

           o If the RSIP gateway cannot allocate a requested address /
             port tuple because it is in use, the RSIP gateway MUST
             respond with an ERROR_RESPONSE containing the
             LOCAL_ADDRPORT_INUSE error.

           o If the RSIP gateway cannot allocate a requested address /
             port tuple because it is not allowed by policy, the RSIP
             gateway MUST respond with an ERROR_RESPONSE containing the
             LOCAL_ADDRPORT_UNALLOWED error.

         - If the RSIP host requests a number of ports (greater that
           one), but does not specify particular port numbers (i.e.,
           uses "don't care" values) the RSIP gateway cannot grant the
           entire request, the RSIP gateway MUST return an



Borella et al.           Expires September 2000                [Page 21]

INTERNET-DRAFT  Realm Specific IP: Protocol Specification     March 2000


           ERROR_RESPONSE containing the LOCAL_ADDRPORT_UNAVAILABLE
           error.

         - If macro-flow based remote policy is used and the requested
           remote address is not allowed by the RSIP gateway's policy,
           the RSIP gateway MUST respond with an ERROR_RESPONSE
           containing the REMOTE_ADDR_UNALLOWED error.

         - If micro-flow based remote policy is used and the requested
           remote address / port pair is not allowed by the RSIP
           gateway's policy, the RSIP gateway MUST respond with an
           ERROR_RESPONSE containing the REMOTE_ADDRPORT_UNALLOWED
           error.

         - If an unsupported or unallowed tunnel type is specified, the
           RSIP gateway MUST respond with an ERROR_RESPONSE containing
           the BAD_TUNNEL_TYPE error.

         - If the host has not specified local or remote address or port
           information in enough detail, the RSIP gateway MUST respond
           with an ERROR_RESPONSE containing the FLOW_POLICY_VIOLATION
           error.

   9.9.  ASSIGN_RESPONSE_RSAP-IP

      9.9.1.  Description

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

      9.9.2.  Format

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

      9.9.3.  Behavior




Borella et al.           Expires September 2000                [Page 22]

INTERNET-DRAFT  Realm Specific IP: Protocol Specification     March 2000


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

         If no remote flow policy is used, the RSIP gateway 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.

         If the host detects an error or otherwise does not "understand"
         the gateway's response, it SHOULD send a FREE_REQUEST with the
         bind ID from the said ASSIGN_RESPONSE_RSAP-IP.  This will serve
         to help synchronize the states of the host and gateway.

   9.10.  EXTEND_REQUEST

      9.10.1.  Description

         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 host MUST specify its client ID and the bind ID in
         question, and it MAY suggest a lease time to the gateway.

      9.10.2.  Format

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

      9.10.3.  Behavior

         The following message-specific error conditions exist:

         - If the host is not registered with the gateway, the gateway
           MUST respond with an ERROR_RESPONSE containing the
           REGISTER_FIRST error.

         - If the message contains an incorrect client ID, the gateway



Borella et al.           Expires September 2000                [Page 23]

INTERNET-DRAFT  Realm Specific IP: Protocol Specification     March 2000


           MUST respond with an ERROR_RESPONSE containing the
           BAD_CLIENT_ID error.

         - If the message contains an incorrect bind ID, the gateway
           MUST respond with an ERROR_RESPONSE containing the
           BAD_BIND_ID error.

         If the RSIP gateway grants an extension to the host's lease, it
         MUST RESPOND with an appropriate EXTEND_RESPONSE message.  If
         the lease is not renewed, the RSIP gateway MAY let it
         implicitly expire by doing nothing or make it explicitly expire
         by sending an appropriate FREE_RESPONSE message.

   9.11.  EXTEND_RESPONSE

      9.11.1.  Description

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

      9.11.2.  Format

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

      9.11.3.  Behavior

         The RSIP gateway will determine lease time as per its local
         policy.  The returned time is to be interpreted as the number
         of seconds before the lease expires, counting from the time at
         which the message is sent/received.

   9.12.  FREE_REQUEST

      9.12.1.  Description

         The FREE_REQUEST message is used by an RSIP host 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.






Borella et al.           Expires September 2000                [Page 24]

INTERNET-DRAFT  Realm Specific IP: Protocol Specification     March 2000


      9.12.2.  Format

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

      9.12.3.  Behavior

         The following message-specific error conditions exist:

         - If the host is not registered with the gateway, the gateway
           MUST respond with an ERROR_RESPONSE containing the
           REGISTER_FIRST error.

         - If the message contains an incorrect client ID, the gateway
           MUST respond with an ERROR_RESPONSE containing the
           BAD_CLIENT_ID error.

         - If the message contains an incorrect bind ID, the gateway
           MUST respond with an ERROR_RESPONSE containing the
           BAD_BIND_ID error.

         If a host receives an error in response to a FREE_REQUEST, this
         may indicate that the host and gateway's states have become
         unsynchronized. Therefore, the host SHOULD make an effort to
         resynchronize, such as freeing resources then re-requesting
         them, or de-registering then re-registering.

   9.13.  FREE_RESPONSE

      9.13.1.  Description

         The FREE_RESPONSE message is used by an RSIP gateway to
         acknowledge a FREE_REQUEST sent by an RSIP host, and to
         asynchronously deallocate resources granted to an RSIP host..

      9.13.2.  Format

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

      9.13.3.  Behavior




Borella et al.           Expires September 2000                [Page 25]

INTERNET-DRAFT  Realm Specific IP: Protocol Specification     March 2000


         An RSIP host must always be ready to accept a FREE_RESPONSE,
         even if its lease on the specified bind ID is not yet expired.

   9.14.  QUERY_REQUEST

      9.14.1.  Description

         A QUERY_REQUEST message is used by an RSIP host to ask an RSIP
         gateway whether or not a particular address or network is local
         or remote.  The host uses this information to determine whether
         to contact the host(s) directly (in the local case), or via
         RSIP (in the remote case).

         This message defines an indicator parameter with a 1-byte value
         field and 2 defined values:

         - 1 address
         - 2 network

      9.14.2.  Format

         <QUERY_REQUEST> ::= <Version>
                             <Message Type>
                             <Overall Length>
                             <Client ID>
                             [Address Tuple]...
                             [Network Tuple]...

         where

         <Address Tuple> ::= <Indicator (address)>
                             <Address>

         <Network Tuple> ::= <Indicator (network)>
                             <Address (network)>
                             <Address (netmask)>

      9.14.3.  Behavior

         One or more address or network tuples may be specified.  Each
         tuple encodes a request regarding the locality (local or
         remote) of the encoded address or network.  If no tuple is
         specified, the RSIP gateway should interpret the message as a
         request for all tuples that it is willing to provide.  Note
         that the FQDN form of the address parameter cannot be used to
         specify the address of a network, and only the netmask form of
         the address parameter can be used to specify the netmask of a
         network.



Borella et al.           Expires September 2000                [Page 26]

INTERNET-DRAFT  Realm Specific IP: Protocol Specification     March 2000


         If an RSIP gateway cannot determine whether a queried host or
         network is local or remote, it SHOULD transmit a QUERY_RESPONSE
         with no response specified for the said host or network.

         The following message-specific error conditions exist:

         - If the host is not registered with the gateway, the gateway
           MUST respond with an ERROR_RESPONSE containing the
           REGISTER_FIRST error.

         - If the message contains an incorrect client ID, the gateway
           MUST respond with an ERROR_RESPONSE containing the
           BAD_CLIENT_ID error.



   9.15.  QUERY_RESPONSE

      9.15.1.  Description

         A QUERY_RESPONSE message is used by an RSIP gateway to answer a
         QUERY_REQUEST from an RSIP host.

         This message defines an indicator parameter with a 1-byte value
         field and 4 defined values:

         - 1 local address
         - 2 local network
         - 3 remote address
         - 4 remote network

      9.15.2.  Format

         <QUERY_RESPONSE> ::= <Version>
                              <Message Type>
                              <Overall Length>
                              <Client ID>
                              [Local Address Tuple]...
                              [Local Network Tuple]...
                              [Remote Address Tuple]...
                              [Remote Network Tuple]...

         where

         <Local Address Tuple> ::= <Indicator (local address)>
                                   <Address>

         <Local Network Tuple> ::= <Indicator (local network)>



Borella et al.           Expires September 2000                [Page 27]

INTERNET-DRAFT  Realm Specific IP: Protocol Specification     March 2000


                                   <Address (network)>
                                   <Address (netmask)>

         <Remote Address Tuple> ::= <Indicator (remote address)>
                                    <Address>

         <Remote Network Tuple> ::= <Indicator (remote network)>
                                    <Address (network)>
                                    <Address (netmask)>

      9.15.3.  Behavior

         An RSIP gateway has some leeway in how it responds to a
         QUERY_REQUEST.  It may just provide the information requested,
         if it can provide such information.  It may provide its
         complete list of address and networks, in order to minimize the
         number of requests that the host needs to perform in the
         future.  How an RSIP gateway responds may depend on network
         traffic considerations as well.

         If an RSIP gateway sends a QUERY_RESPONSE that does not contain
         any tuples, or a QUERY_RESPONSE that does not contain a tuple
         that applies to an associated tuple in the associated
         QUERY_REQUEST, this should be interpreted that the RSIP gateway
         does not know whether the queried host or network is local or
         remote.  Appropriate host behavior upon receipt of such a
         message is to assume that the queried host or network is
         remote.

         Note that an RSIP gateway is not expected to maintain a
         complete list of all remote hosts and networks.  In fact, a
         typical RSIP gateway will only maintain a list of the networks
         and hosts that it knows are local (private with respect to the
         RSIP host).

   9.16.  LISTEN_REQUEST

      9.16.1.  Description

         A LISTEN_REQUEST message is sent by an RSIP host that wants to
         register a service on a particular address and port number. The
         host 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.







Borella et al.           Expires September 2000                [Page 28]

INTERNET-DRAFT  Realm Specific IP: Protocol Specification     March 2000


      9.16.2.  Format

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

      9.16.3.  Behavior

         If the host 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 host MUST fill both
         the remote address and ports parameters with "don't care"
         values.  If macro-flow based remote policy is used, the host
         MUST specify the remote address, but MAY or MAY NOT specify the
         remote port(s).  If micro-flow based remote policy is used, the
         host MUST specify the remote address and ports parameter.

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

         LISTEN_REQUEST is not necessary for RSA-IP.

         The following message-specific error conditions exist:

         - If the host is not registered with the gateway, the gateway
           MUST respond with an ERROR_RESPONSE containing the
           REGISTER_FIRST error.

         - If the message contains an incorrect client ID, the gateway
           MUST respond with an ERROR_RESPONSE containing the
           BAD_CLIENT_ID error.

         - If the local address parameter is a don't care value and the
           RSIP gateway cannot allocate ANY addresses, the RSIP gateway
           MUST respond with an ERROR_RESPONSE containing the
           LOCAL_ADDR_UNAVAILABLE error.



Borella et al.           Expires September 2000                [Page 29]

INTERNET-DRAFT  Realm Specific IP: Protocol Specification     March 2000


         - If the local address parameter is not a don't care value
           there are five possible error conditions:

           o If the RSIP gateway cannot allocate ANY addresses, it MUST
             respond with an ERROR_RESPONSE containing the
             LOCAL_ADDR_UNAVAILABLE error.

           o If the RSIP gateway cannot allocate the requested address
             because it is in use, the RSIP gateway MUST respond with an
             ERROR_RESPONSE containing the LOCAL_ADDR_INUSE error.

           o If the RSIP gateway cannot allocate the requested address
             because it is not allowed by policy, the RSIP gateway MUST
             respond with an ERROR_RESPONSE containing the
             LOCAL_ADDR_UNALLOWED error.

           o If the RSIP gateway cannot allocate the requested address /
             port tuple because it is in use, the RSIP gateway MUST
             respond with an ERROR_RESPONSE containing the
             LOCAL_ADDRPORT_INUSE error.

           o If the RSIP gateway cannot allocate the requested address /
             port tuple because it is not allowed by policy, the RSIP
             gateway MUST respond with an ERROR_RESPONSE containing the
             LOCAL_ADDRPORT_UNALLOWED error.

         - If macro-flow based remote policy is used and the requested
           remote address is not allowed by the RSIP gateway's policy,
           the RSIP gateway MUST respond with an ERROR_RESPONSE
           containing the REMOTE_ADDR_UNALLOWED error.

         - If micro-flow based remote policy is used and the requested
           remote address / port pair is not allowed by the RSIP
           gateway's policy, the RSIP gateway MUST respond with an
           ERROR_RESPONSE containing the REMOTE_ADDRPORT_UNALLOWED
           error.

         - If an unsupported or unallowed tunnel type is specified, the
           RSIP gateway MUST respond with an ERROR_RESPONSE containing
           the BAD_TUNNEL_TYPE error.

         - If the host has not specified local or remote address or port
           information in enough detail, the RSIP gateway MUST respond
           with an ERROR_RESPONSE containing the FLOW_POLICY_VIOLATION
           error.

   9.17.  LISTEN_RESPONSE




Borella et al.           Expires September 2000                [Page 30]

INTERNET-DRAFT  Realm Specific IP: Protocol Specification     March 2000


      9.17.1.  Description

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

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

      9.17.2.  Format

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

      9.17.3.  Behavior

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

10.  Discussion

   10.1.  General Gateway Policy

      There is a significant amount of RSIP gateway 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 gateway policy include:




Borella et al.           Expires September 2000                [Page 31]

INTERNET-DRAFT  Realm Specific IP: Protocol Specification     March 2000


      - How ports are allocated to RSIP hosts.
      - Preferred length of lease times.
      - How flow policy is applied to which hosts.
      - How an RSIP gateway with multiple public IP addresses that may
        be leased by RSIP clients determines how to partition and/or lease
        these addresses.

   10.2.  Errors Not From the RSIP Protocol

      Once an RSIP host and gateway have established a relationship and
      the host is assigned resources to use, error may occur due to the
      host's misuse of the resources or its attempting to use unassigned
      resources.  The following error behavior is defined:

      - If a host attempts to use a local address which it has not been
        allocated, the RSIP gateway MUST drop the associated packet(s)
        and send the host an ERROR_RESPONSE containing the
        LOCAL_ADDR_UNALLOWED error.

      - If a host attempts to use a local address / port tuple which it
        has not been allocated, the RSIP gateway MUST drop the
        associated packet(s) and send the host an ERROR_RESPONSE
        containing the LOCAL_ADDRPORT_UNALLOWED error.

      - If a host attempts to contact a remote address which has not
        been properly specified or otherwise approved (e.g., via an
        ASSIGN_RESPONSE_RSAP-IP and macro or micro based remote flow
        policy), the RSIP gateway MUST drop the associated packet(s) and
        send the host an ERROR_RESPONSE containing the
        REMOTE_ADDR_UNALLOWED error.

      - If a host attempts to contact a remote address / port tuple
        which has not been properly specified or otherwise approved
        (e.g., via an ASSIGN_RESPONSE_RSAP-IP and micro based remote
        flow policy), the RSIP gateway MUST drop the associated
        packet(s) and send the host an ERROR_RESPONSE containing the
        REMOTE_ADDRPORT_UNALLOWED error.

      - If a host attempts to establish or use an improper tunnel type,
        the RSIP gateway MUST respond with an ERROR_RESPONSE containing
        the BAD_TUNNEL_TYPE error.

      - If the RSIP gateway's detects a local fault which prevents its
        RSIP server module from continuing operation, the RSIP gateway
        MUST respond with an ERROR_RESPONSE containing the
        INTERNAL_SERVER_ERROR error.





Borella et al.           Expires September 2000                [Page 32]

INTERNET-DRAFT  Realm Specific IP: Protocol Specification     March 2000


   10.3.  Default Tunnel Type and RSIP Method

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

   10.4.  Address and Port Requests and Allocation

      Regardless of local flow policy, an RSIP host may "suggest" that
      it would like to use a particular local address and/or port number
      in a particular binding.  An RSIP gateway that cannot grant such a
      request, because the specified resources are already in use, MUST
      respond with an ERROR_RESPONSE containing the LOCAL_ADDR_INUSE or
      LOCAL_ADDRPORT_INUSE values.

   10.5.  Local Gateways and Flow Policy Interaction

      An RSIP host may initialize a publically accessible gateway (such
      as an FTP or HTTP gateway) by transmitting a LISTEN_REQUEST
      message to an RSIP gateway and receiving a LISTEN_RESPONSE.
      However, unless no remote flow policy is used, the gateway 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 hosts that require their
      gateways to be accessible by any remote host.

      This indicates that there is a conflict between flow-based policy
      and support for gateways.  The main purpose of enforcing flow-
      based policy for LISTEN_REQUESTs is that it allows an RSIP gateway
      tight control over how an RSIP host uses ports and the associated
      accounting.  For example, an RSIP host, 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 gateway will transmit
      data from, in a LISTEN_REQUEST.

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

      Currently, RSIP hosts can only be identified by their local IP
      address or MAC address.

11.  Security Considerations

   RSIP, in and of itself, does not provide security.  It may provide



Borella et al.           Expires September 2000                [Page 33]

INTERNET-DRAFT  Realm Specific IP: Protocol Specification     March 2000


   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.

   An RSIP gateway should take all measures deemed necessary to prevent
   its hosts from performing intentional or unintentional denial-of-
   service attacks by request large sets of resources.

   Currently, RSIP hosts can only be identified by their local IP
   address or MAC address.  It is desirable to allow RSIP messages sent
   between a host and gateway to 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 designations below are tentative.

   - RSIP port number: 4455 (pending approval).
   - RSIP error codes (see Appendix A).
   - RSIP message type codes (see Appendix B).
   - RSIP tunnel types, methods, and flow policies.

   RSIP parameter values are designated as follows:
   - 0       Reserved
   - 1-240   Assigned by IANA
   - 241-255 Reserved for private use

   New registrations for the above namespaces are recommended to be
   allocated via the Specification Required method documented in
   [RFC2434].

13.  Changelog

   05 to 06
         - Terminology change.  An "RSIP client" now refers to the application
           that performs RSIP client duties -- i.e., running the client
           side of the RSIP protocol.  The physical device on which the RSIP
           client runs is now called the "RSIP host".  An "RSIP server" now
           refers to the application that performs RSIP server duties --
           i.e., running the server side of the RSIP protocol.  The physical
           device on which the RSIP server runs is now called the "RSIP
           gateway".
         - Specifying how to lease multiple public IPs is a policy issue and
           beyond the scope of the draft.
         - Fixed ambiguity with "don't care" value formats.



Borella et al.           Expires September 2000                [Page 34]

INTERNET-DRAFT  Realm Specific IP: Protocol Specification     March 2000


         - Addressed the scenario in which a host request n ports but the server
           cannot grant all n.
         - Noted that client applications that use ephemeral source ports will
           find it useful to specify "don't care" values for local ports.
         - Correction of numerous minor typos.

   04 to 05
         - Depreciated the OK message.  DEALLOCATE message replaced by
           FREE_RESPONSE, which had evolved into the same exact message
           as DEALLOCATE.
         - Categorized all RSIP messages as either client or server and
           mandatory or optional.
         - Added discussion of behavior and error conditions to all RSIP
           messages.
         - Re-worked error messages as per the above.
         - Noted that for micro-flow policy, a ports parameter MUST contain
           exactly one port field.
         - Fixed IANA Considerations section
         - Added indicator parameter
         - Set aside parameter codes 241-255 for private use
         - Major revision of QUERY_REQUEST and QUERY_RESPONSE
         - Added discussion of error that occur from data flow

   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.



Borella et al.           Expires September 2000                [Page 35]

INTERNET-DRAFT  Realm Specific IP: Protocol Specification     March 2000


         - Clarified use/non-use of message IDs between clients and servers.
         - 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, Naveen Rajanikantha, Sudhakar
   Ramakrishna, 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



Borella et al.           Expires September 2000                [Page 36]

INTERNET-DRAFT  Realm Specific IP: Protocol Specification     March 2000


   error parameter. These error values are preliminary and are very
   likely to change over time as implementations are tested.

   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 host has attempted to use UDP on a server that
         only supports TCP.

      103: FLOW_POLICY_VIOLATION: A host has not specified address or
         port information in enough detail for its assigned flow policy.

      104: INTERNAL_SERVER_ERROR: An RSIP server application has
         detected an unrecoverable error within itself or the RSIP
         gateway.

   200's: Parameter and message errors.  The gateway 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 gateway does not understand a parameter
         code.

      205: BAD_PARAM. A parameter is malformed.

      206: ILLEGAL_MESSAGE. The gateway does not understand the message
         type.  The message type is neither mandatory nor optional.

      207: BAD_MESSAGE. A message is malformed and gateway parsing
         failed.

      208: UNSUPPORTED_MESSAGE: The host has transmitted an optional
         message that the gateway does not support.




Borella et al.           Expires September 2000                [Page 37]

INTERNET-DRAFT  Realm Specific IP: Protocol Specification     March 2000


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

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

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

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

      304: REGISTRATION_DENIED: The gateway will not allow the host to
         register.

      305: BAD_CLIENT_ID. The host has referred to itself with the wrong
         client ID.

      306: BAD_BIND_ID. The request refers to a bind ID that is not
         valid for the host.

      307: BAD_TUNNEL_TYPE. The request refers to a tunnel type that is
         not valid for the host.

      308: LOCAL_ADDR_UNAVAILABLE. The gateway is currently not able to
         allocate ANY local address, but the host may try again later.

      309: LOCAL_ADDRPORT_UNAVAILABLE.  The gateway is currently not
         able to allocate ANY local IP address / port tuple of the
         requested magnitude (i.e., number of ports), but the host may
         try again later.

      310: LOCAL_ADDR_INUSE. The gateway was not able to allocate the
         requested local address because it is currently used by another
         entity.

      311: LOCAL_ADDRPORT_INUSE.  The gateway was not able to allocate
         the requested local address / port tuple because it is
         currently used by another entity.

      312: LOCAL_ADDR_UNALLOWED. The gateway will not let the host use
         the specified local IP address due to policy.

      313: LOCAL_ADDRPORT_UNALLOWED. The gateway will not let the host
         use the specified local address / port pair due to policy.

      314: REMOTE_ADDR_UNALLOWED.  The gateway will not allow the host



Borella et al.           Expires September 2000                [Page 38]

INTERNET-DRAFT  Realm Specific IP: Protocol Specification     March 2000


         to establish a session to the specified remote address.

      315: REMOTE_ADDRPORT_UNALLOWED.  The gateway will not allow the
         host to establish a session to the specified remote address /
         port tuple.

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

16.  Appendix B: Message Types

   This section defines the values assigned to RSIP message types.
   These values are preliminary and are likely to change over time as
   implementations are tested.  We also indicate which RSIP entity, host
   or gateway, produces each messages, and whether it is mandatory or
   optional.  All *_REQUEST messages are only to be implemented on
   hosts, while all *_RESPONSE messages are only to be implemented on
   gateways.  RSIP implementations (both host and gateway) MUST support
   all mandatory messages in order to be considered "RSIP compliant".

   Value    Message                 Implementation     Status
   ------------------------------------------------------------
    1     ERROR_RESPONSE                gateway        mandatory
    2     REGISTER_REQUEST              host           mandatory
    3     REGISTER_RESPONSE             gateway        mandatory
    4     DE-REGISTER_REQUEST           host           mandatory
    5     DE-REGISTER_RESPONSE          gateway        mandatory
    6     ASSIGN_REQUEST_RSA-IP         host           optional
    7     ASSIGN_RESPONSE_RSA-IP        gateway        optional
    8     ASSIGN_REQUEST_RSAP-IP        host           mandatory
    9     ASSIGN_RESPONSE_RSAP-IP       gateway        mandatory
   10     EXTEND_REQUEST                host           mandatory
   11     EXTEND_RESPONSE               gateway        mandatory
   12     FREE_REQUEST                  host           mandatory
   13     FREE_RESPONSE                 gateway        mandatory
   14     QUERY_REQUEST                 host           optional
   15     QUERY_RESPONSE                gateway        mandatory
   16     LISTEN_REQUEST                host           optional
   17     LISTEN_RESPONSE               gateway        optional

17.  Appendix C: Example RSIP host/gateway transactions

   In this appendix, we present an exemplary series of annotated
   transactions between an RSIP host and an RSIP gateway.  All host to
   gateway traffic is denote by `C --> S' and all gateway to host
   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



Borella et al.           Expires September 2000                [Page 39]

INTERNET-DRAFT  Realm Specific IP: Protocol Specification     March 2000


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

      C --> S: REGISTER_REQUEST ()

         The host attempts to register with the gateway.

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

         The gateway 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) =
         0, Lease Time = 3600)

         The host requests an address and four ports to use with it, but
         doesn't care which address or ports are assigned.  The host
         does not specify the remote address or ports either.  The host
         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 gateway 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.




Borella et al.           Expires September 2000                [Page 40]

INTERNET-DRAFT  Realm Specific IP: Protocol Specification     March 2000


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

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

         The host asks the gateway if the network 10.20.60.0/24 is
         local.

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

         The gateway 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 host 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 gateway grants the request with the same address, but with
         a different set of ports. IP-IP tunneling is implied by
         default.

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

         The host 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 host because the host is still assigned ports
         1305-1314.

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

         The gateway acknowledges that Bind ID 1 has been freed.

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

         The host request that the lease on bind ID 1 be extended for



Borella et al.           Expires September 2000                [Page 41]

INTERNET-DRAFT  Realm Specific IP: Protocol Specification     March 2000


         1800 seconds.

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

         The gateway confirms the request.

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

         The gateway forces the host to free the resources of bind ID 2.

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

         The host de-registers with the sever.

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

         The gateway acknowledges that the host 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 host attempts to register with the gateway.

      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 gateway 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 host requests a local address and a port assignment to use
         with it.  The host indicates that it wants to contact host
         38.196.73.6 at port 21 (FTP control).  The host 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,



Borella et al.           Expires September 2000                [Page 42]

INTERNET-DRAFT  Realm Specific IP: Protocol Specification     March 2000


         Address (remote) = 38.196.73.6, Ports (remote) = 21, Lease Time
         = 600, Tunnel Type = IP-IP)

         The gateway 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 host 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 gateway 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 host de-registers with the sever.

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

         The gateway acknowledges that the host has de-registered.  All
         of the host'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 host attempts to register with the gateway.

      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 gateway responds, assigning a Client ID of 3, local macro-



Borella et al.           Expires September 2000                [Page 43]

INTERNET-DRAFT  Realm Specific IP: Protocol Specification     March 2000


         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 host 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 gateway indicates that the host 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 host 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)

         The gateway responds by granting local IP address
         149.112.240.17 to the host, 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 host de-registers with the sever.

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

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

18.  Appendix D: Example RSIP host state diagram

   This appendix provides an exemplary diagram of RSIP host state.  The
   host begins in the unregistered state.  We assume that for UDP, if a
   message is lost, the host will timeout and retransmit another copy of



Borella et al.           Expires September 2000                [Page 44]

INTERNET-DRAFT  Realm Specific IP: Protocol Specification     March 2000


   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.


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



Borella et al.           Expires September 2000                [Page 45]

INTERNET-DRAFT  Realm Specific IP: Protocol Specification     March 2000


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

   [RFC2434] T. Narten and H. Alvestrand, "Guidelines for Writing an
      IANA Considerations Section in RFCs," RFC 2434, Oct. 1998.

   [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-03.txt>, Dec. 1999 (work in progress).

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

20.  Authors' Addresses

   Michael Borella



Borella et al.           Expires September 2000                [Page 46]

INTERNET-DRAFT  Realm Specific IP: Protocol Specification     March 2000


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



Borella et al.           Expires September 2000                [Page 47]

INTERNET-DRAFT  Realm Specific IP: Protocol Specification     March 2000


   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 September 2000                [Page 48]


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