INTERNET DRAFT                                       Jeffrey Lo
Expires November 1999                                NEC USA

                                                     Michael Borella
                                                     David Grabelsky
                                                     3Com Corp

                     Realm Specific IP: A Framework

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-

   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

   The list of Internet-Draft Shadow Directories can be accessed at


   This document examines the general framework of Realm Specific IP
   (RSIP).  All RSIP solutions must solve the same set of problems, and
   all RSIP-related proposals to date are similar in many ways.  We
   attempt to enumerate the similarities and differences of these
   proposals, and expand the scope of RSIP to include several other
   possible mechanisms.  We do not advocate any one RSIP solution over
   the other; instead, we present these solutions in the hope to clarify
   RSIP issues and generate further discussion towards adoption of RSIP.

1.  Introduction

   While NAT has become a popular mechanism of sharing IP addresses
   amongst a number of hosts, it suffers from a lack of flexibility.  In
   particular, a NAT router must examine and change the network layer,

Lo et. al.                Expires November 1999                 [Page 1]

INTERNET DRAFT        Realm Specific IP: Framework              May 1999

   and possibly the transport layer, headers of each packet to or from
   the NAT subnet(s) sharing its IP address(es).  This causes NAT to
   break the end-to-end nature of Internet connectivity, and disrupts
   protocols requring end-to-end connectivity, such as the network
   security protocols which embody IPSEC.  Furthermore, any application
   that transmits IP address or port content, such as FTP, will require
   a proxy module (application layer gateway) within the NAT router.
   Given these limitations of NAT, RSIP has emerged as an attempt to
   remedy them.

   RSIP is based on the concept of granting host from one realm (e.g.,
   privately addressed realm) a presence in another realm (e.g.,
   publicly addressed realm) by granting it resources from the second
   realm. While this document is limited to the discussion of IPv4
   networks, RSIP is general and may be applied beyond the limitations
   of IPv4 networks and used as a means of IPv4 public address
   assignment to IPv6 subnets.  In this document we discuss the
   approaches of several possible RSIP systems and address the issues
   that any RSIP solution must face.

2.  Terminology

   Private Realm

      A routing realm that uses private IP addresses from the ranges
      (10/8, 172.16/12, 192/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

   RSIP Server

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

   RSIP Client

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

Lo et. al.                Expires November 1999                 [Page 2]

INTERNET DRAFT        Realm Specific IP: Framework              May 1999

   RSA-IP: Realm Specific Address IP

      An RSIP method in which each RSIP client is allocated a unique IP
      address from the public realm.  Dicussed in detail in [NAT-TERM].

   RSAP-IP: Realm Specific Address and Port IP

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

   All other terminology found in this document is consistent with that
   of [NAT-TERM].

3.  Specification of Requirements

   The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   documents are to be interpreted as described in [RFC2119].

4.  Architecture

   In a typical scenario where RSIP is deployed, there are some number
   of hosts within one addressing realm connected to another addressing
   realm by the RSIP server.  This model is diagrammatically represented
   as follows:

      RSIP Client             RSIP Server                    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 server (which may also act as a NAT).
   N has two addresses: 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 addressing realm A.  These
   addresses are not shown above, but they can be denoted as Nb1, Nb2,
   Nb3 and so on. The hosts within address space A are likely to use
   private addresses while the RSIP server is multi-homed with one or
   more private addresses in addition to it's public addresses.

   Using the public parameters assigned by the RSIP server, RSIP clients
   route (usually tunnel) data packets to the RSIP server within address
   space A. If tunneling is used, the RSIP server acts as the end point
   of such tunnels, stripping off the outer headers and routing the

Lo et. al.                Expires November 1999                 [Page 3]

INTERNET DRAFT        Realm Specific IP: Framework              May 1999

   inner packets onto the public realm. An RSIP server maintains a
   mapping of the assigned public parameters as demultiplexing tuples
   for uniquely mapping them to RSIP client private addresses.  When a
   packet from the public realm arrives at the RSIP server and it
   matches a given set of demultiplexing tuples, then the RSIP server
   will tunnel it to the appropriate RSIP client.

5.  RSIP Fundamentals

   This section discusses the issues that all RSIP schemes must address.
   Note that these issues are not orthogonal; thus, by addressing one,
   in some cases another issue is also addressed sufficiently.

   5.1.  Negotiation and/or determination of Demultiplexing Fields

      Assume that an RSIP client within a private realm has transmitted
      a request to a public server within a public realm, and the server
      has sent a response packet that successfully arrived at the RSIP
      server. Based on a pre-arranged mapping, the RSIP server must be
      able to determine the private IP address of the packet's
      destination; i.e., the RSIP client. The only information that the
      RSIP server may use is what is already contained within the
      headers of the inbound data packet. We will refer to these header
      fields as the "demultiplexing fields" as they are used to spread
      the incoming streams of packets to multiple destinations within
      the private realm.

      Depending on the type of mapping used by the RSIP server,
      demultiplexing parameters could either be public IPv4 addresses,
      TCP/UDP ports, IPSEC Security Payload Indexes (SPIs), ISAKMP
      initiator cookies, some combination of the above, or some other
      field(s). Such demultiplexing of incoming traffic resembles a
      decision tree, which could be represented as follows:

      - A unique public IP address is mapped to each RSIP client.
      - If the same IP address is used for more than one RSIP client,
        then subsequent headers must have at least one field that will
        be assigned a unqieu value per client so that it is usable as a
        demultiplexing field.
      - If the subsequent header is TCP or UDP, then destination port
        number can be used. Otherwise, there must exist another field
        usable as a demultiplexing field.
      - If the TCP or UDP port number is the same for more than one RSIP
        client, the payload section of the packet must contain a
        demultiplexing field that is guaranteed to be different for each
        RSIP client.

      In general, it is desirable for all demultiplexing fields to occur

Lo et. al.                Expires November 1999                 [Page 4]

INTERNET DRAFT        Realm Specific IP: Framework              May 1999

      in well-known fixed locations so that an RSIP server can mask out
      and examine the appropriate fields on incoming packets. In some
      cases, for example, where different RSIP methods (RSA-IP, RSAP-IP,
      etc.) are used by the same RSIP client using just one IP address,
      the decision tree approach would be beneficial.

      Demultiplexing of incoming streams of packet requires pre-
      assignment of the demultiplexing fields to RSIP clients. Hence
      there exists a requirement for a negotiation process that enables
      these parameters to be negotiated between RSIP server and RSIP
      clients. Such a negotiation process can be based on the following

      - As an extension of current host configuration or policy protocols
        such as DHCP, COPS, RADIUS, DIAMETER, or SOCKS.
      - During tunnel establishment, for example as an extension to L2TP
        parameter negotiation.
      - As an RSIP specific protocol such as described in [RSIP-PROTO].

   5.2.  Determination of other RSIP parameters

      Apart from negotiation of demultiplexing fields, other information
      pertaining to the assignment of those fields may also need to be
      negotiated. Examples of such parameters are:

         A binding identifier may be assigned for each public parameter
         assignment. The binding identifier serves to uniquely identify
         the resource(s) that has been allocated by an RSIP server. It
         may also be used during lookup to efficiently index existing

         A time duration (lease) may be associated with each bind of
         public parameters to an RSIP client.

         RSIP clients may require that the RSIP server specify how it
         allocates address and port resources (referred to as the RSIP
         method). RSIP servers may only allocate a public IP address to
         each unique host, known as RSA-IP. Or, RSIP-servers may
         distribute a (potentially shared) public IP address and a
         unique port range per that IP address to each host, termed

         The negotiation and assignment mechanism SHOULD be extensible
         and facilitate vendor specific parameters.

   5.3.  Tunnel Use and Establishment

      Once the public demultiplexing fields have been allocated by the

Lo et. al.                Expires November 1999                 [Page 5]

INTERNET DRAFT        Realm Specific IP: Framework              May 1999

      RSIP server, RSIP clients will be able to use them freely.
      However, RSIP implementations generally requires data packets to
      be tunnelled between the RSIP client and server within the private
      realm since public routing information is not advertised in the
      private realm. While it is possible to imagine an RSIP
      implementation that does not require tunneling, it seems that
      tunneling is a flexible method for solving address ambiguity
      problems.  The type of tunnel may be IP-IP, GRE, IPSEC tunnel
      mode, L2TP, or another form of tunnel.

      There is a disadvantage to not using a tunnel between the RSIP
      client and the RSIP server.  It is likely that an RSIP server will
      also act as a firewall or packet filter for the private network.
      In this case, it publically addressed packets are transmitted on
      the private network, the RSIP server may consider these packets
      tobe part of an attack.

      Tunnels may be established statically or dynamically between RSIP
      clients and servers.  A static tunnel is established at host boot
      and remains in service until the host is no longer using the
      network.  A dynamic tunnel is established at the beginning of a
      session or flow and exists only for the lifetime of the session.
      Both types of tunnels may allow for on-the-fly re-negotiation of
      demultiplexing fields and re-assignment of parameters to RSIP
      clients. If tunneling is used to route the publicly addressed
      packet within private realm, public parameter negotiation could be
      associated with tunnel establishment mechanisms. Alternatively, a
      negotiation protocol may enable the negotiation of tunnel type as

6.  Miscellaneous Issues

   The resolution of a number of RSIP issues are still open.  Although
   solutions may exist for these problems, they may have unattractive
   side effects.  In this section we discuss several such issues.

   6.1.  Policy and Accounting

      All RSIP-clients SHOULD have a mechansims of authenticating
      themselves to RSIP-servers, in order to alleviate possible denial
      of service attacks in which a malicious RSIP client attempts to
      utilize the resources assigned to a different RSIP client.

      Any RSIP implementation SHOULD implement accounting of irregular
      event seen by the RSIP-server. Events such as denial of service
      attacks, illegal use of resources (traffic without bindings or
      after binding expirations) and public resource depletion SHOULD be

Lo et. al.                Expires November 1999                 [Page 6]

INTERNET DRAFT        Realm Specific IP: Framework              May 1999

   6.2.  Contacting Internal Servers

      In order for an RSIP implementation to allow private hosts to run
      servers that can be contacted from the public network, these
      servers must be registered with the RSIP server. Registration of
      servers with unique and/or well known listen ports may be limited
      to one per private realm unless other means beyond port number are
      used for demultiplexing (e.g. multiple WWW domains may be
      disambiguated by looking into the HTTP headers).

   6.3.  Determining Locality of Destinations

      In general, an RSIP client must know, for a particular IP address,
      whether it should transmit the packet normally for local delivery,
      or tunnel the packet to the RSIP server.  Since more than one
      subnet may be behind an RSIP server, looking at a local subnet
      mask will not always work.  We'd rather not have to propagate
      routing tables to all RSIP clients.  A simple alternative,
      proposed in [RSIP-PROTO], that will solve this problem is to
      require that the RSIP server knows all of the subnets that are on
      the private network. This information can be manually entered
      because it is not expected to change often.  Then, if an IP
      address in question is not on a host's local subnet, the host can
      query the server with the address.  The RSIP server will return a
      simple "yes or "no" answer - yes, this address is local, or no, it
      is not. As proposed in [RSIP-PROTO], a queried RSIP server may
      respond with the list of subnets supported. An RSIP client may
      cache this information.  However, in large enterprise networks, an
      RSIP server may not be aware of all private subnets.

      Alternatively, RSIP-clients could send all packets for
      destinations without an explicit static route to the RSIP server.
      If they arrive at the RSIP server, it informs the host that it
      should instead tunnel the packet.  The host then acquires the
      necessary public parameters and tunnels the packet, to the RSIP
      server. This approach may require further changes to the TCP/IP
      stack at the host, since, in the case of TCP traffic, a half-open
      TCP socket must be discarded. Likewise, the RSIP client could at
      first tunnel the packets to the RSIP server. If the server
      determines that the destination is local, it would inform the host
      of this fact and the host could then transmit the packet in the
      standard fashion. Regardless of the solution chosen, RSIP clients
      caching the "locality" of recently-contacted IP addresses may be

   6.4.  Implementing RSIP Client Deallocation

      As currently defined in [RSIP-PROTO], an RSIP client MAY free

Lo et. al.                Expires November 1999                 [Page 7]

INTERNET DRAFT        Realm Specific IP: Framework              May 1999

      resources that it has determined that it no longer requires.  For
      example, on a large RSAP-IP subnet with a limited number of public
      IP addresses, locally-unique port numbers may become scarse.
      Thus, if RSIP clients are able to deallocate ports that they no
      longer need, RSIP will be more scalable.

      However, this functionality may require significant modifications
      to a vanilla TCP/IP stack in order to implement properly.  The
      RSIP client must be able to determine which TCP or UDP sessions
      are using RSIP resources.  If those resources are unused for a
      period of time, then the RSIP client may deallocate them.  When an
      open socket's resources are deallocated, it will cause some
      associated applications to fail.  An analogous case would be TCP
      and UDP sessions that must terminate when a PPP interface that
      they are using loses connectivity.

      On the other hand, this issue can be considered a resource
      allocation problem.  It is not recommended that a large number
      (hundreds) of hosts share the same IP address, for performance
      purposes.  Even if, say, 100 hosts each are allocated 100 ports,
      the total number of ports in use by RSIP would be still less than
      one-sixth the total port space for an IP address.  If more hosts
      or more ports are needed, more IP addresses should be used.  Thus,
      it is reasonable, that in many cases, RSIP clients will not have
      to deallocate ports for the lifetime of their activity.

      Similarly, it is non-trivial for an RSIP client to know when to
      allocate ports.  It will have to detect activity on a socket,
      determine if the destination host is local or external, and then
      request the appropriate resources. In cases when the allocation
      requires multiple rounds, for example when more than one public
      resources are to be allocated and multiple assignment requests are
      issued or a request gets denied a number of times, delays may be
      introduced by the resource allocation process.

7.  Cascaded RSIP

   It is possible for RSIP to allow for cascading of RSIP-servers. For
   example, consider an ISP that uses RSIP for address sharing amongst
   its customers.  It might assign resources (e.g., IP addresses and
   ports) to a particular customer. This customer may further subdivide
   the port ranges and address(es) amongst individual end hosts. A
   reference architecture is depicted below.

Lo et. al.                Expires November 1999                 [Page 8]

INTERNET DRAFT        Realm Specific IP: Framework              May 1999

                            |           |
                            |   RSIP    |
                            |  server   +----
                            |     B     |
                            |           |
                   +-----------+  | (
                   |           |  ||    RSIP   +--+
   ----------------+   server  |
                   |      A    +--+
                   |           |  |
                   +-----------+  |
                                  | (
                            |           |
                            |   RSIP    |
                            |  server   +----
                            |     C     |
                            |           |

   RSIP-server A is in charge of the IP addresses of subnet  It distributes these addresses to RSIP-clients and
   RSIP-servers.  In the given configuration, it distributes addresses - to RSIP-server B, and addresses - to RSIP-server C.  Note that the
   subnet broadcast address,, must remain unclaimed, so
   that broadcast packets can be distributed to arbitrary hosts behind
   RSIP-server A.  Also, the subnets between RSIP-server A and RSIP-
   servers B and C will use private addresses.

   Due to the tree-like fashion in which addresses will be cascaded, we
   will refer to RSIP-servers A as the 'parent' of RSIP-servers B and C,
   and RSIP-servers B and C as 'children' of RSIP-servers A. An
   arbitrary number of levels of children may exist under a parent RSIP-

   A parent RSIP-server will not necessarily be aware that the
   address(es) and port blocks that it distributes to a child RSIP-
   server will be further distributed.  Thus, the RSIP-clients MUST
   tunnel their outgoing packets to the nearest RSIP-server.  This
   server will then verify that the sending host has used the proper
   address and port block, and then tunnel the packet on to its parent

Lo et. al.                Expires November 1999                 [Page 9]

INTERNET DRAFT        Realm Specific IP: Framework              May 1999


   For example, in the context of the diagram above, host,
   behind RSIP-server C will use its assigned external IP address (say, and tunnel its packets over the subnet to
   RSIP-server C.  RSIP-server C strips off the outer IP header.  After
   verifying that the source public IP address and source port number is
   valid, RSIP-server C will tunnel the packets over the
   subnet to RSIP-server A.  RSIP-server A strips off the outer IP
   header.  After verifying that the source public IP address and source
   port number is valid, RSIP-server A transmits the packet on the
   public network.

   While it may be more efficient in terms of computation to have a
   RSIP-client tunnel directly to the overall parent of an RSIP-server
   tree, this would introduce significant state and administrative

   A RSIP-server that is a child MUST take into consideration the
   parameter assignment constraints that it inherits from its parent
   when it assigns parameters to its children.  For example, if a child
   RSIP-server is given a lease time of 3600 seconds on an IP address,
   it MUST compare the current time to the lease time and the time that
   the lease was assigned to compute the maximum allowable lease time on
   the address if it is to assign the address to a RSIP-client or child

8.  To Do

   - RSIP impact on ALGs?
   - Pros and cons of RSIP riding on top of existing protocols such as
     DHCP, RADIUS, SOCKS, etc.

9.  Changelog

   00 to 01:

   - Synched up terminology with the latest NAT terminology draft.
   - Changed all instances of "global" to "public"
   - Modified section on "Architecture"
   - Added discussion of demultiplexing parameters tree to the
     "Negotiation and assignment of demultiplexing fields" section
   - Added discussion of subnet list query in "Determining Locality of
     Destination" section
   - Added "RSIP Client Deallocation" discussion section
   - Added more explanation in "Tunnel Use and Establishment" section

10.  Acknowledgements

Lo et. al.                Expires November 1999                [Page 10]

INTERNET DRAFT        Realm Specific IP: Framework              May 1999

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

11.  References

   [RSIP-PROTO] Michael Borella, David Grabelsky, Jeffrey Lo and Kuni
      Taniguchi, "Realm Specific IP: Protocol Specification,"
      <draft-ietf-nat-rsip-protocol-01.txt>, work in progress, Apr. 1999.

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

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

   [NAT-TERM] P. Srisuresh and Matt Holdrege, "IP Network Address
      Translator (NAT) Terminology and Considerations,"
      <draft-ietf-nat-terminology-02.txt>, work in progress, Apr. 1999.

      Authors' Addresses

      Jeffrey Lo
      NEC USA
      C&C Research Labs.
      110 Rio Robles
      San Jose, CA 95134
      (408) 943 3033

      Michael Borella
      3Com Corp.
      1800 W. Central Rd.
      Mount Prospect IL 60056
      (847) 842 6093

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

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

Lo et. al.                Expires November 1999                [Page 11]

INTERNET DRAFT        Realm Specific IP: Framework              May 1999

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

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

      This document and the information contained herein is provided on an

Lo et. al.                Expires November 1999                [Page 12]