INTERNET DRAFT                                       Jeffrey Lo
Expires July 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 and

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

INTERNET DRAFT        Realm Specific IP: Framework         February 1999

   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 network
   layer]] security protocols, such as IPSec.  Furthermore, any
   application that transmits IP address or port content, such as FTP,
   will require a proxy module within the NAT router.  Given these
   limitations, RSIP has emerged as an attempt to avoid the worst
   complications of NAT.

   RSIP is based on the concept of granting host from one realm (e.g.,
   privately addressed realm) a presence in another realm (e.g.,
   globally 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 well beyond the
   limitations of IPv4 networks, such as IPv4/IPv6 translators.  In this
   document we discuss the approaches of several possible RSIP systems
   and address the issues that any RSIP solution must face. Since, at
   this preliminary stage, we most likely have missed out certain issues
   in the implementation of RSIP, we welcome thoughts and comments from
   the experienced.

2.  Terminology

   Private Realm

      A routing realm in which RSIP hosts assumes temporary presence in
      another realm, the global realm. Examples of private realms are
      privately addressed (10/8, 172.16/12, 192.168/16) IPv4 realms or
      private IPv4 realms within IPv6 networks.

   Global Realm

      A routing realm with unique network addressed assigned by Internet
      Assigned Number Authority (IANA) or an equivalent address


      An entity situated on the boundary between a private realm and a
      global realm which is responsible for global parameter management
      and assignment to RSIP-clients. In all cases, an RSIP-server may
      act as a normal NAT box at the same time for hosts within the
      private realm that are not RSIP enabled.


      An entity within the private realm that assumes globally unique
      parameters from the RSIP server through the use of RSIP.

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

INTERNET DRAFT        Realm Specific IP: Framework         February 1999

   All other terminology found in this document is consistent with that
   of [1].

3.  Specification of Requirements

   The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   documents are to be interpreted as described in RFC 2119.

4.  Architecture

   In a typical scenario where RSIP is deployed, there is some number of
   hosts in the private realm without globally-routable IP addresses
   connected to the global realm by the RSIP server.  The hosts are
   likely to use private addresses from the range assigned by IANA
   (10/8, 172.16/12 and 192.168/16), while the RSIP server is multi-
   homed with one or more private addresses from this range and one or
   more publicly-routable addresses.

   The RSIP-server may act as a normal NAT device while at the same time
   facilitating RSIP implementations by dynamically carrying out global
   resource and/or parameter negotiation and assignments with RSIP-
   clients.  Using the global parameters assigned by the RSIP-server,
   RSIP-clients route (usually tunnel) data packets to the RSIP-server
   within the private realm. If tunneling is used, the RSIP-server acts
   as the end point of such tunnels, stripping off the outer headers and
   routing the inner packets onto the global realm. An RSIP-server
   maintains a mapping of the demultiplexing tuples to RSIP-client
   private addresses, such the mapping can be used to demultiplex data
   traffic to RSIP-clients.

5.  RSIP Fundamentals

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

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

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

INTERNET DRAFT        Realm Specific IP: Framework         February 1999

      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 global IPv4
      addresses or port.

      Demultiplexing of incoming streams of packet require pre-
      assignment of the demultiplexing fields to RSIP clients. Hence
      there exist a requirement for a negotiation process that enable
      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 a specialized RSIP-specific protocolm such as described in

   5.2.  Determination of other RSIP parameters

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

         A binding identifier may be assigned for each global parameter
         assignment. The binding identifier serves to uniquely identify
         the resource that has been allocated by an RSIP server. It may
         also be used during lookup to efficiently index existing
         bindings.  A time duration may be associated with each bind of
         global parameters to a RSIP clients. If such time information
         are used, it has to be negotiated.

         RSIP-clients may require that the RSIP-server specify how it
         allocates address and port resources.  RSIP-servers may only
         allocate a global IP address to each unique host, resulting in
         a Basic-NAT-like operation.  Or, RSIP-servers may distribute a
         (potentially shared) global IP address and a unique port range
         per that IP address to eachhost, resulting in a NAPT-like

         The negotiation and assignment mechanism SHOULD facilitate
         vendor specific parameters.

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

INTERNET DRAFT        Realm Specific IP: Framework         February 1999

   5.3.  Tunnel Use and Establishment

      RSIP generally requires the use of tunnels within the private
      realm, between the RSIP clients and the RSIP server.  While it is
      possibly to imagine an RSIP implementation that does not require
      tunneling, it seems that tunneling is a flexible method for
      solving a address ambiguity problems.  The type of tunnel may be
      IP-IP, GRE, an IPSEC mode, L2TP, or another form of tunnel.

      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 globally addressed
      packet within private realm, global parameter negotiation could be
      associated with tunnel establishment mechanisms. Alternatively, a
      negotiation protocol may enable the negotiation of tunnel type as

   5.4.  Policy and Accounting

      Having an RSIP MIB may be useful as a means of pre-configuring
      RSIP-clients at set up and as a method for introducing RSIP
      policy. It is particularly valuable in large-scale implementations
      with thousands of RSIP-clients. In such cases, push technology
      could be used to update RSIP-clients with the configuration and
      policy information.

      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
      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 global resource depletion SHOULD be

6.  Open Problems

   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.

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

INTERNET DRAFT        Realm Specific IP: Framework         February 1999

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

   6.2.  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 work.  We'd rather not have to propagate routing
      tables to all RSIP-clients.  A simple alternative, proposed in
      [2], 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.

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

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 August 1999                  [Page 6]

INTERNET DRAFT        Realm Specific IP: Framework         February 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 August 1999                  [Page 7]

INTERNET DRAFT        Realm Specific IP: Framework         February 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.  References

   [1] P. Srisuresh and Matt Holdrege, "IP Network Address Translator
      (NAT) Terminology and Considerations," <draft-ietf-nat-
      terminology-01.txt>, Work in progress

   [2] Michael Borella, David Grabelsky, Jeffrey Lo and Kuni Taniguchi,
      "Realm Specific IP: Protocol Specification," <draft-ietf-nat-rsip-
      protocol-00.txt>, Work in progress.

9.  Authors' Addresses

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

   Michael Borella

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

INTERNET DRAFT        Realm Specific IP: Framework         February 1999

   3Com Corp.
   Advanced Technologies Research Center
   1800 W. Central Rd.
   Mount Prospect IL 60056
   (847) 842 6093

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

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

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

      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 August 1999                  [Page 9]