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

Versions: 00 01 02 03 04 RFC 3102

INTERNET DRAFT                                       Editors:
Expires September 2000                                 M. Borella
                                                         3Com Corp.
                                                       J. Lo
                                                         NEC USA

                                                     Contributors:
                                                       D. Grabelsky
                                                         3Com Corp.
                                                       G. Montenegro
                                                         Sun Microsystems

                                                     March 2000

                      Realm Specific IP: Framework
                 <draft-ietf-nat-rsip-framework-04.txt>

Status of this Memo

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

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

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

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

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

Abstract

   This document examines the general framework of Realm Specific IP
   (RSIP). RSIP is intended as a alternative to NAT in which the end-to-
   end integrity of packets is maintained.  We focus on implementation
   issues, deployment scenarios, and interaction with other layer-three
   protocols.

1.  Introduction




Borella et. al.          Expires September 2000                 [Page 1]

INTERNET DRAFT        Realm Specific IP: Framework            March 2000


   Network Address Translation (NAT) has become a popular mechanism of
   enabling the separation of addressing spaces. A NAT router must
   examine and change the network layer, and possibly the transport
   layer, header of each packet crossing the addressing domains that the
   NAT router is connecting. This causes the mechanism of NAT to violate
   the end-to-end nature of the Internet connectivity, and disrupts
   protocols requiring or enforcing end-to-end integrity of packets.

   While NAT does not require a host to be aware of its presence, it
   requires the presence of a proxy module, the application layer
   gateway (ALG), within the NAT router for each application that embeds
   addressing information, IP address or port content, within the packet
   payload (e.g., FTP). RSIP (Realm Specific IP) provides an alternative
   to remedy these limitations.

   RSIP is based on the concept of granting a host from one addressing
   realm a presence in another addressing realm by allowing it to use
   resources (e.g., addresses and other routing parameters) from the
   second addressing realm. An RSIP gateway replaces the NAT router, and
   RSIP-aware hosts on the private network are referred to as RSIP
   hosts.  RSIP requires ability of the RSIP gateway to grant such
   resources to RSIP hosts. ALGs are not required on the RSIP gateway
   for communications between an RSIP host and a host on a different
   addressing realm.

   It is important to note that RSIP is not a replacement for IPv6.  We
   fully advocate the adoption and deployment of IPv6.  RSIP has been
   designed to restore some of the end-to-end transparency that NAT has
   taken away from the Internet, and it may smooth the IPv6 transition
   process.

   1.1.  Document Scope

      This document provides a framework for RSIP by focusing on three
      particular areas:

      - Implementation issues that are not specific to the RSIP protocol
        defined in [RSIP-PROTO].

      - Likely initial deployment scenarios.

      - Interaction with other layer-three protocols.

      The interaction sections will be at an overview level.  Detailed
      modifications that would need to be made to RSIP and/or the
      interacting protocol are left for separate documents to discuss in
      detail.




Borella et. al.          Expires September 2000                 [Page 2]

INTERNET DRAFT        Realm Specific IP: Framework            March 2000


      Beyond the scope of this document is discussion of RSIP in large,
      multiple-gateway networks, or in environments where RSIP state
      would need to be distributed and maintained across multiple
      redundant entities.

      Discussion of RSIP solutions that do not use some form of tunnel
      between the RSIP host and RSIP gateway are also not considered in
      this document.

   1.2.  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 an addressing realm that uses RSIP to acquire
         addressing parameters from another addressing realm via an RSIP
         gateway.

      RSIP Gateway

         A router situated on the boundary between two addressing realms
         and owns one or more IP addresses. An RSIP gateway is
         responsible for parameter management and assignment from one
         realm to RSIP hosts in the other realm. An RSIP gateway may act
         as a normal NAT router for hosts within the a 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



Borella et. al.          Expires September 2000                 [Page 3]

INTERNET DRAFT        Realm Specific IP: Framework            March 2000


         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.

      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.

      RSIP-enabled Mobile Node (RMN)

         A host that uses RSIP for connectivity to the public network,
         and also uses Mobile IP for roaming support.

      RSIP Home Network (RHN)

         A network on which a number of hosts use RSIP to share one or
         more public IP addresses.

      RSIP Home Agent (RHA)

         A router, running an RSIP gateway, that manages Mobile IP
         connectivity for RSIP-enabled mobile nodes belonging to an RSIP
         home network.

      RSIP Foreign Network (RFN)

         A network which can support RSIP-enabled mobile nodes as they
         roam.

      RSIP Foreign Agent (RFA)

         A router that manages Mobile IP connectivity for roaming RSIP-
         enabled mobile nodes.  This router may or may not use RSIP on
         its local network.

      Demultiplexing Fields

         Any set of packet header or payload fields that an RSIP gateway
         uses to route an incoming packet to an RSIP host.

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



Borella et. al.          Expires September 2000                 [Page 4]

INTERNET DRAFT        Realm Specific IP: Framework            March 2000


   1.3.  Specification of Requirements

      The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
      "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
      this documents are to be interpreted as described in [RFC2119].

2.  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 an RSIP gateway.  This model is diagrammatically represented
   as follows:

         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.

   As is often the case, the hosts within address space A are likely to
   use private addresses while the RSIP gateway is multi-homed with one
   or more private addresses from address space A in addition to its
   public addresses from address space B.  Thus, we typically refer to
   the realm in which the RSIP host resides as "private" and the realm
   from which the RSIP host borrow addressing parameters as the "public"
   realm.  However, these realms may both be public or private - our
   notation is for convenience.

   Host X, wishing 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 (e.g., addresses and other
   routing parameters of address space B) from the RSIP gateway. Upon
   assignment of these parameters, the RSIP gateway creates a mapping,
   referred as a "bind", 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. If
   permitted by the RSIP gateway, X may create multiple such bindings on
   the same RSIP gateway, or across several RSIP gateways. A lease time
   SHOULD be associated with each bind.




Borella et. al.          Expires September 2000                 [Page 5]

INTERNET DRAFT        Realm Specific IP: Framework            March 2000


   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 MAY support RSA-IP, RSAP-IP, or both.

   When using RSA-IP, an RSIP gateway maintains a pool of IP addresses
   to be leased by RSIP hosts.  Upon host request, the RSIP gateway
   allocates an IP address to the host.  Once an address is allocated to
   a particular host, only that host may use the address until the
   address is returned to the pool.  Hosts MAY NOT use addresses that
   have not been specifically assigned to them.  The hosts may use any
   TCP/UDP port in combination with their assigned address.  Hosts may
   also run gateway applications at any port and these applications will
   be available to the public network without assistance from the RSIP
   gateway.  A host MAY lease more than one address from the same or
   different RSIP gateways.  The demultiplexing fields of an RSA-IP
   session MUST include the IP address leased to the host.

   When using RSAP-IP, an RSIP gateway maintains a pool of IP addresses
   as well as pools of port numbers per address.  RSIP hosts lease an IP
   address and one or more ports to use with it.  Once an address / port
   tuple has been allocated to a particular host, only that host may use
   the tuple until it is returned to the pool(s). Hosts MAY NOT use
   address / port combinations that have not been specifically assigned
   to them.  Hosts may run gateway applications bound to an allocated
   tuple, but their applications will not be available to the public
   network unless the RSIP gateway has agreed to route all traffic
   destined to the tuple to the host. A host MAY lease more than one
   tuple from the same or different RSIP gateways.  The demultiplexing
   fields of an RSAP-IP session MUST include the tuple(s) leased to the
   host.

3.  Implementation Considerations




Borella et. al.          Expires September 2000                 [Page 6]

INTERNET DRAFT        Realm Specific IP: Framework            March 2000


   RSIP can be accomplished by any one of a wide range of implementation
   schemes.  For example, it can be built into an existing configuration
   protocol such as DHCP or SOCKS, or it can exist as a separate
   protocol.  This section discusses implementation issues of RSIP in
   general, regardless of how the RSIP mechanism is implemented.

   Note that on a host, RSIP is associated with a TCP/IP stack
   implementation.  Modifications to IP tunneling and routing code, as
   well as driver interfaces may need to be made to support RSA-IP.
   Support for RSAP-IP requires modifications to ephemeral port
   selection code as well.  If a host has multiple TCP/IP stacks or
   TCP/IP stacks and other communication stacks, RSIP will only operate
   on the packets / sessions that are associated with the TCP/IP
   stack(s) that use RSIP.  RSIP is not application specific, and if it
   is implemented in a stack, it will operate transparently to all
   applications that use the stack.

   3.1.  Host and Gateway Requirements

      An RSIP host must be able to maintain one or more virtual
      interfaces for the IP address(es) that it leases from an RSIP
      gateway.  The host must also support tunneling and be able to
      serve as an end-point for one or more tunnels to RSIP gateways.
      An RSIP host MUST NOT respond to ARPs for a public realm address
      that it leases.

      An RSIP host supporting RSAP-IP MUST be able to maintain a set of
      one or more ports assigned by an RSIP gateway from which choose
      ephemeral source ports.  If the host's pool does not have any free
      ports and the host needs to open a new communication session with
      a public host, it MUST be able to dynamically request one or more
      additional ports via its RSIP mechanism.

      An RSIP gateway is a multi-homed host that routes packets between
      two or more realms.  Often, an RSIP gateway is a boundary router
      between two or more administrative domains.  It must also support
      tunneling and be able to serve as an end-point for tunnels to RSIP
      hosts.  The RSIP gateway MAY be a policy enforcement point, which
      in turn may require it to perform firewall and packet filtering
      duties in addition to RSIP.  The RSIP gateway must reassemble all
      incoming packet fragments from the public network in order to be
      able to route and tunnel them to the proper host.  As is necessary
      for all fragment reassembly, an RSIP gateway must timeout
      fragments that are never fully reassembled.

      An RSIP gateway MAY include NAT functionality so that hosts on the
      private network that are not RSIP-enabled can still communicate
      with the public network.  An RSIP gateway must manage all



Borella et. al.          Expires September 2000                 [Page 7]

INTERNET DRAFT        Realm Specific IP: Framework            March 2000


      resources that are assigned to RSIP hosts.  This management MAY be
      done according to local policy.

   3.2.  Processing of Demultiplexing Fields

      Each active RSIP host must have a unique set of demultiplexing
      fields assigned to it so that an RSIP gateway can route incoming
      packets appropriately.  Depending on the type of mapping used by
      the RSIP gateway, demultiplexing fields have been defined to be
      one or more of the following:

      - destination IP address

      - IP protocol

      - destination TCP or UDP port

      - IPSEC SPI present in ESP or AH header (see [RSIP-IPSEC])

      - ISAKMP initiator cookie present in an IKE payload (see [RSIP-
        IPSEC])

      - others

      Demultiplexing of incoming traffic can be based on a decision
      tree.  The process begins with the examination of the IP header of
      the incoming packet, and proceeds to subsequent headers and then
      the payload.

      - In the case where a public IP address is assigned for each host,
        a unique public IP address is mapped to each RSIP host.

      - If the same IP address is used for more than one RSIP host, then
        subsequent headers must have at least one field that will be
        assigned a unique value per host so that it is usable as a
        demultiplexing field. The IP protocol field SHOULD be used to
        determine what in the subsequent headers these demultiplexing
        fields ought to be.

      - If the subsequent header is TCP or UDP, then destination port
        number can be used. However, if the TCP/UDP port number is the
        same for more than one RSIP host, the payload section of the
        packet must contain a demultiplexing field that is guaranteed to
        be different for each RSIP host. Typically this requires
        negotiation of said fields between the RSIP host and gateway so
        that the RSIP gateway can guarantee that the fields are unique
        per-host




Borella et. al.          Expires September 2000                 [Page 8]

INTERNET DRAFT        Realm Specific IP: Framework            March 2000


      - If the subsequent header is anything other than TCP or UDP,
        there must exist other fields within the IP payload usable as
        demultiplexing fields.  In other words, these fields must be
        able to be set such that they are guaranteed to be unique per-
        host.  Typically this requires negotiation of said fields
        between the RSIP host and gateway so that the RSIP gateway can
        guarantee that the fields are unique per-host.

      It is desirable for all demultiplexing fields to occur in well-
      known fixed locations so that an RSIP gateway can mask out and
      examine the appropriate fields on incoming packets.
      Demultiplexing fields that are encrypted MUST NOT be used for
      routing.

   3.3.  RSIP Protocol Requirements and Recommendations

      RSIP gateways and hosts must be able to negotiate IP addresses
      when using RSA-IP, IP address / port tuples when using RSAP-IP,
      and possibly other demultiplexing fields for use in other modes.
      In this section we discuss the requirements and implementation
      issues of an RSIP negotiation protocol.

      For each required demultiplexing field, an RSIP protocol MUST, at
      the very least, allow for:

      - RSIP hosts to request assignments of demultiplexing fields

      - RSIP gateways to assign demultiplexing fields with an associated
        lease time

      - RSIP gateways to reclaim assigned demultiplexing fields

      Additionally, it is desirable, though not mandatory, for an RSIP
      protocol to negotiate an RSIP method (RSA-IP or RSAP-IP) and the
      type of tunnel to be used across the private network.  The
      protocol SHOULD be extensible and facilitate vendor-specific
      extensions.

      If an RSIP negotiation protocol is implemented at the application
      layer, a choice of transport protocol must be made.  RSIP hosts
      and gateways may communicate via TCP or UDP.  TCP support is
      required in all RSIP gateways, while UDP support is optional.  In
      RSIP hosts, TCP, UDP, or both may be supported.  However, once an
      RSIP host and gateway have begun communicating using either TCP or
      UDP, they MAY NOT switch to the other transport protocol.  For
      RSIP implementations and deployments considered in this document,
      TCP is the recommended transport protocol, because TCP is known to
      be robust across a wide range of physical media types and traffic



Borella et. al.          Expires September 2000                 [Page 9]

INTERNET DRAFT        Realm Specific IP: Framework            March 2000


      loads.

      It is recommended that all communication between an RSIP host and
      gateway be authenticated.  Authentication, in the form of a
      message hash appended to the end of each RSIP protocol packet, can
      serve to authenticate the RSIP host and gateway to one another,
      provide message integrity, and (with an anti-replay counter) avoid
      replay attacks.  In order for authentication to be supported, each
      RSIP host and the RSIP gateway must either share a secret key
      (distributed, for example, by Kerberos) or have a private/public
      key pair.  In the latter case, an entity's public key can be
      computed over each message and a hash function applied to the
      result to form the message hash.

   3.4.  TCP TIME_WAIT at Public Peers

      When a TCP gateway disconnects a socket, it enters the TCP
      TIME_WAIT state for a period of time.  While it is in this state
      it will refuse to accept new connections using the same socket
      (i.e., the same source address/port and destination address/port).
      Consider the case in which an RSIP host (using RSAP-IP) is leased
      an address/port tuple and uses this tuple to contact a public
      address/port tuple.  Suppose that the host terminates the session
      with the public tuple and immediately returns its leased tuple to
      the RSIP gateway.  If the RSIP gateway immediately allocates this
      tuple to another RSIP host (or to the same host), and this second
      host uses the tuple to contact the same public tuple while the
      socket is still in the TIME_WAIT phase, then the host's connection
      may be rejected by the public host.  In order to mitigate this
      problem, it is recommended that RSIP gateways hold recently
      deallocated tuples for at least two minutes, which is the greatest
      duration of TIME_WAIT that is commonly implemented [STEV94].  In
      situations where port space is scarce, the RSIP gateway MAY choose
      to allocate ports in a FIFO fashion from the pool of recently
      deallocated ports.

   3.5.  ICMP Handling

      Like NAT, RSIP gateways running RSAP-IP are required to remember
      recent ICMP packets for which responses cannot be demultiplexed by
      port number (i.e., echo request packets).  ICMP request packets
      originating on the private network will typically consist of echo
      request, timestamp request and address mask request.  These
      packets and their responses can be identified by the tuple of
      source IP address, ICMP identifier, ICMP sequence number, and
      destination IP address.  An RSIP host sending an ICMP request
      packet tunnels it to the RSIP gateway, just as it does TCP and UDP
      packets.  The RSIP gateway must use this tuple to map incoming



Borella et. al.          Expires September 2000                [Page 10]

INTERNET DRAFT        Realm Specific IP: Framework            March 2000


      ICMP responses to the private address of the appropriate RSIP
      host.  Once it has done so, it will tunnel the ICMP response to
      the host.  Note that it is possible for two RSIP hosts to use the
      same values for the tuples listed above, and thus create an
      ambiguity.  However, this occurrence is likely to be quite rare,
      and is not addressed further in this draft.

      Incoming ICMP error response messages can be forwarded to the
      appropriate RSIP host by examining the IP header and port numbers
      embedding within the packet.  In the case of RSA-IP, only the
      source IP address is necessary to determine the RSIP host.  In the
      case of RSAP-IP, the source IP address and source port number is
      necessary to determine the RSIP host.

      Occasionally, an RSIP host will have to send an ICMP response
      (e.g., port unreachable).  These responses are tunneled to the
      RSIP gateway, as is done for TCP and UDP packets.  All ICMP
      requests (e.g., echo request) arriving at the RSIP gateway MUST be
      processed by the RSIP gateway and MUST NOT be forwarded to an RSIP
      host.


   3.6.  MTU Limitation to Prevent Fragmentation and ID Collision

      RSIP hosts MUST limit their MTU so that packets transmitted by an
      RSIP gateway are not fragmented.  If two or more RSIP hosts on the
      same private network transmit outbound packets that get fragmented
      to the same public gateway, the public gateway may experience a
      reassembly ambiguity if the IP header ID fields of these packets
      are identical.

      For TCP packets, this is not an issue if path MTU discovery works
      properly.  For non-TCP packets, an artificially small MTU, such is
      required.  The setting of this MTU, however, may depend on the
      applications being run.
   3.7.  Gateways on RSAP-IP Hosts

      RSAP-IP hosts are limited by the same constraints as NAT with
      respect to hosting gateways that use a well-known port.  Since
      destination port numbers are used as routing information to
      uniquely identify an RSAP-IP host, typically no two RSAP-IP hosts
      sharing the same public IP address can simultaneously operate
      publically-available gateways on the same port.  For protocols
      that operate on well-known ports, this implies that only one
      public gateway per RSAP-IP IP address / port tuple is used
      simultaneously.  However, more than one gateway per RSAP-IP IP
      address / port tuple may be used simultaneously if and only if
      there is a demultiplexing field within the payload of all packets



Borella et. al.          Expires September 2000                [Page 11]

INTERNET DRAFT        Realm Specific IP: Framework            March 2000


      that will uniquely determine the identity of the RSAP-IP host, and
      this field is known by the RSIP gateway.

      In order for an RSAP-IP host to operate a publically-available
      gateway, the host must inform the RSIP gateway that it wishes to
      receive all traffic destined to that port number, per its IP
      address.  Such a request MUST be denied if the port in question is
      already in use by another host.

   3.8.  Determining Locality of Destinations from an RSIP Host

      In general, an RSIP host must know, for a particular IP address,
      whether it should address the packet for local delivery on the
      private network, or if it has to use an RSIP interface to tunnel
      to an RSIP gateway (assuming that it has such an interface
      available).

      If the RSIP hosts are all on a single subnet, one hop from an RSIP
      gateway, then examination of the local network and subnet mask
      will provide the appropriate information.  However, this is not
      always the case.

      An alternative that will work in general for statically addressed
      private networks is to store a list of the network and subnet
      masks of every private subnet at the RSIP gateway.  RSIP hosts may
      query the gateway with a particular target IP address, or for the
      entire list.

      If the subnets on the local side of the network are changing more
      rapidly than the lifetime of a typical RSIP session, the RSIP host
      may have to query the location of every destination that it tries
      to communicate with.

      If an RSIP host transmits a packet addressed to a public host
      without using RSIP, then the RSIP gateway will apply NAT to the
      packet (if it supports NAT) or it may discard the packet and
      respond with and appropriate ICMP message.

   3.9.  Implementing RSIP Host Deallocation

      An RSIP host MAY free resources that it has determined it no
      longer requires.  For example, on an RSAP-IP subnet with a limited
      number of public IP addresses, port numbers may become scarce.
      Thus, if RSIP hosts are able to dynamically deallocate ports that
      they no longer need, more hosts can be supported.

      However, this functionality may require significant modifications
      to a vanilla TCP/IP stack in order to implement properly.  The



Borella et. al.          Expires September 2000                [Page 12]

INTERNET DRAFT        Realm Specific IP: Framework            March 2000


      RSIP host 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 host 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 an 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 hosts will not have to
      deallocate ports for the lifetime of their activity.

      Since RSIP demultiplexing fields are leased to hosts, an
      appropriately chosen lease time can alleviate some port space
      scarcity issues.

   3.10.  Interaction with DNS

      An RSIP-enabled network has three uses for DNS: (1) public DNS
      services to map its static public IP addresses (i.e., the public
      address of the RSIP gateway) and for lookups of public hosts, (2)
      private DNS services for use only on the private network, and (3)
      dynamic DNS services for RSIP hosts.

      With respect to (1), public DNS information MUST be propagated
      onto the private network.  With respect to (2), private DNS
      information MUST NOT be propagated into the public network.

      With respect to (3), an RSIP-enabled network MAY allow for RSIP
      hosts with FQDNs to have their A and PTR records updated in the
      public DNS.  These updates are based on address assignment
      facilitated by RSIP, and should be performed in a fashion similar
      to DHCP updates to dynamic DNS [DHCP-DNS].  In particular, RSIP
      hosts should be allowed to update their A records but not PTR
      records, while RSIP gateways can update both.  In order for the
      RSIP gateway to update DNS records on behalf on an RSIP host, the
      host must provide the gateway with its FQDN.

      Note that when using RSA-IP, the interaction with DNS is
      completely analogous to that of DHCP because the RSIP host "owns"
      an IP address for a period of time.  In the case of RSAP-IP, the
      claim that an RSIP host has to an address is only with respect to



Borella et. al.          Expires September 2000                [Page 13]

INTERNET DRAFT        Realm Specific IP: Framework            March 2000


      the port(s) that it has leased along with an address.  Thus, two
      or more RSIP hosts' FQDNs may map to the same IP address.
      However, a public host may expect that all of the applications
      running at a particular address are owned by the same logical
      host, which would not be the case.  It is recommended that RSAP-IP
      and dynamic DNS be integrated with some caution, if at all.

   3.11.  Locating RSIP Gateways

      When an RSIP host initializes, it requires (among other things)
      two critical pieces of information.  One is a local (private) IP
      address to use as its own, and the other is the private IP address
      of an RSIP gateway. This information can be statically configured
      or dynamically assigned.

      In the dynamic case, the host's private address is typically
      supplied by DHCP.  A DHCP option has been proposed to provide the
      IP address of an RSIP gateway in DHCPOFFER messages (the Next
      Gateway option) [DHC-NS].  Thus, the host's startup procedure
      would be as follows: (1) perform DHCP, (2) if the Next Gateway
      option is present in the DHCPOFFER, record the IP address therein
      as the RSIP gateway.

4.  Deployment

   When RSIP is deployed in certain scenarios, the network
   characteristics of these scenarios will determine the scope of the
   RSIP solution, and therefore impact the requirements of RSIP.  In
   this section, we examine deployment scenarios, and the impact that
   RSIP may have on existing networks.

   4.1.  Possible Deployment Scenarios

      In this section we discuss a number of potential RSIP deployment
      scenarios. The selection below are not comprehensive and other
      scenarios may emerge.

      4.1.1.  Small / Medium Enterprise

         Up to several hundred hosts will reside behind an RSIP-enabled
         router. It is likely that there will be only one gateway to the
         public network and therefore only one RSIP gateway.  This RSIP
         gateway may control only one, or perhaps several, public IP
         addresses.  The RSIP gateway may also perform firewall
         functions, as well as routing inbound traffic to particular
         destination ports on to a small number of dedicated gateways on
         the private network.




Borella et. al.          Expires September 2000                [Page 14]

INTERNET DRAFT        Realm Specific IP: Framework            March 2000


      4.1.2.  Residential Networks

         This category includes both networking within just one
         residence, as well as within multiple-dwelling units.  At most
         several hundred hosts will share the gateway's resources.  In
         particular, many of these devices may be thin hosts or so-
         called "network appliances" and therefore not require access to
         the public Internet frequently.  The RSIP gateway is likely to
         be implemented as part of a residential firewall, and it may be
         called upon to route traffic to particular destination ports on
         to a small number of dedicated gateways on the private network.
         It is likely that only one gateway to the public network will
         be present and that this gateway's RSIP gateway will control
         only one IP address.  Support for secure end-to-end VPN access
         to corporate intranets will be important.

      4.1.3.  Hospitality Networks

         A hospitality network is a general type of "hosting" network
         that a traveler will use for a short period of time (a few
         minutes or a few hours).  Examples scenarios include hotels,
         conference centers and airports and train stations. At most
         several hundred hosts will share the gateway's resources.  The
         RSIP gateway may be implemented as part of a firewall, and it
         will probably not be used to route traffic to particular
         destination ports on to dedicated gateways on the private
         network. It is likely that only one gateway to the public
         network will be present and that this gateway's RSIP gateway
         will control only one IP address.  Support for secure end-to-
         end VPN access to corporate intranets will be important.

      4.1.4.  Dialup Remote Access

         RSIP gateways may be placed in dialup remote access
         concentrators in order to multiplex IP addresses across dialup
         users.  At most several hundred hosts will share the gateway's
         resources.  The RSIP gateway may or may not be implemented as
         part of a firewall, and it will probably not be used to route
         traffic to particular destination ports on to dedicated
         gateways on the private network. Only one gateway to the public
         network will be present (the remote access concentrator itself)
         and that this gateway's RSIP gateway will control a small
         number of IP addresses.  Support for secure end-to-end VPN
         access to corporate intranets will be important.

      4.1.5.  Wireless Remote Access Networks

         Wireless remote access will become very prevalent as more PDA



Borella et. al.          Expires September 2000                [Page 15]

INTERNET DRAFT        Realm Specific IP: Framework            March 2000


         and IP / cellular devices are deployed.  In these scenarios,
         hosts may be changing physical location very rapidly -
         therefore Mobile IP will play a role.  Hosts typically will
         register with an RSIP gateway for a short period of time.  At
         most several hundred hosts will share the gateway's resources.
         The RSIP gateway may be implemented as part of a firewall, and
         it will probably not be used to route traffic to particular
         destination ports on to dedicated gateways on the private
         network. It is likely that only one gateway to the public
         network will be present and that this gateway's RSIP gateway
         will control a small number of IP addresses.  Support for
         secure end-to-end VPN access to corporate intranets will be
         important.

   4.2.  Cascaded RSIP and NAT

      It is possible for RSIP to allow for cascading of RSIP gateways as
      well as cascading of RSIP gateways with NAT boxes. 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 use RSIP to
      further subdivide the port ranges and address(es) amongst
      individual end hosts.  No matter how many levels of RSIP
      assignment exists, RSIP MUST only assign public IP addresses.

      Note that some of the architectures discussed below may not be
      useful or desirable.  The goal of this section is to explore the
      interactions between NAT and RSIP as RSIP is incrementally
      deployed on systems that already support NAT.

      4.2.1.  RSIP Behind RSIP

         A reference architecture is depicted below.


















Borella et. al.          Expires September 2000                [Page 16]

INTERNET DRAFT        Realm Specific IP: Framework            March 2000


                                     +-----------+
                                     |           |
                                     |   RSIP    |
                                     |  gateway  +---- 10.0.0.0/8
                                     |     B     |
                                     |           |
                                     +-----+-----+
                                           |
                                           | 10.0.1.0/24
                            +-----------+  | (149.112.240.0/25)
                            |           |  |
            149.112.240.0/24|   RSIP    +--+
            ----------------+  gateway  |
                            |     A     +--+
                            |           |  |
                            +-----------+  | 10.0.2.0/24
                                           | (149.112.240.128/25)
                                           |
                                     +-----+-----+
                                     |           |
                                     |   RSIP    |
                                     |  gateway  +---- 10.0.0.0/8
                                     |     C     |
                                     |           |
                                     +-----------+

         RSIP-gateway A is in charge of the IP addresses of subnet
         149.112.240.0/24.  It distributes these addresses to RSIP-hosts
         and RSIP-gateways.  In the given configuration, it distributes
         addresses 149.112.240.0 - 149.112.240.127 to RSIP-gateway B,
         and addresses 149.112.240.128 - 149.112.240.254 to RSIP-gateway
         C.  Note that the subnet broadcast address, 149.112.240.255,
         must remain unclaimed, so that broadcast packets can be
         distributed to arbitrary hosts behind RSIP-gateway A.  Also,
         the subnets between RSIP-gateway A and RSIP- gateways B and C
         will use private addresses.

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

         A parent RSIP-gateway will not necessarily be aware that the
         address(es) and port blocks that it distributes to a child
         RSIP- gateway will be further distributed.  Thus, the RSIP-
         hosts MUST tunnel their outgoing packets to the nearest RSIP-
         gateway.  This gateway will then verify that the sending host



Borella et. al.          Expires September 2000                [Page 17]

INTERNET DRAFT        Realm Specific IP: Framework            March 2000


         has used the proper address and port block, and then tunnel the
         packet on to its parent RSIP-gateway.

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

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

         A RSIP-gateway 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-gateway 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-host or child RSIP-gateway.

      4.2.2.  NAT Behind RSIP

                     +--------+      +--------+
                     | NAT w/ |      |  RSIP  |
         hosts ------+ RSIP   +------+ gate-  +----- public network
                     | host   |      |  way   |
                     +--------+      +--------+

         In this architecture, an RSIP gateway is between a NAT box and
         the public network.  The NAT is also equipped with an RSIP
         host.  The NAT dynamically requests resources from the RSIP
         gateway as the hosts establish sessions to the public network.
         The hosts are not aware of the RSIP manipulation.  This
         configuration does not enable the hosts to have end-to-end
         transparency and thus the NAT still requires ALGs and the
         architecture cannot support IPSEC.

      4.2.3.  RSIP Behind NAT




Borella et. al.          Expires September 2000                [Page 18]

INTERNET DRAFT        Realm Specific IP: Framework            March 2000


                     +--------+      +--------+
         RSIP        |  RSIP  |      |        |
         hosts ------+ gate-  +------+   NAT  +----- public network
                     |  way   |      |        |
                     +--------+      +--------+

         In this architecture, The RSIP hosts and gateway reside behind
         a NAT.  This configuration does not enable the hosts to have
         end-to-end transparency and thus the NAT still requires ALGs
         and the architecture cannot support IPSEC.  The hosts may have
         transparency if there is another gateway to the public network
         besides the NAT box, and this gateway supports cascaded RSIP
         behind RSIP.

      4.2.4.  RSIP Through NAT

                     +--------+      +--------+
         RSIP        |        |      |  RSIP  |
         hosts ------+   NAT  +------+ gate-  +----- public network
                     |        |      |  way   |
                     +--------+      +--------+

         In this architecture, the RSIP hosts are separated from the
         RSIP gateway by a NAT.  RSIP signaling may be able to pass
         through the NAT if an RSIP ALG is installed.  The RSIP data
         flow, however, will have its outer IP address translated by the
         NAT.  The NAT must not translate the port numbers in order for
         RSIP to work properly.  Therefore, only traditional NAT will
         make sense in this context.


5.  Interaction with Other Layer-Three Protocols

   Since RSIP affects layer-three objects, it has an impact on other
   layer three protocols.  In this section, we outline the impact of
   RSIP on these protocols, and in each case, how RSIP, the protocol, or
   both, can be extended to support interaction.

   Each of these sections is an overview and not a complete technical
   specification.  If a full technical specification of how RSIP
   interacts with a layer-three protocol is necessary, a separate
   document will contain it.

   5.1.  IPSEC

      RSIP is a mechanism for allowing end-to-end IPSEC with sharing of
      IP addresses.  Full specification of RSIP/IPSEC details are in
      [RSIP-IPSEC].  This section provides a brief summary.



Borella et. al.          Expires September 2000                [Page 19]

INTERNET DRAFT        Realm Specific IP: Framework            March 2000


      Since IPSEC may encrypt TCP/UDP port numbers, these objects cannot
      be used as demultiplexing fields.  However, IPSEC inserts an AH or
      ESP header following the IP header in all IPSEC-protected packets
      (packets that are transmitted on an IPSEC Security Association
      (SA)).  These headers contain a 32-bit Security Parameter Index
      (SPI) field, the value of which is determined by the receiving
      side.  The SPI field is always in the clear.  Thus, during SA
      negotiation, an RSIP host can instruct their public peer to use a
      particular SPI value.  This SPI value, along with the assigned IP
      address, can be used by an RSIP gateway to uniquely identify and
      route packets to an RSIP host.  In order to guarantee that RSIP
      hosts use SPIs that are unique per address, it is necessary for
      the RSIP gateway to allocate unique SPIs to hosts along with their
      address/port tuple.

      IPSEC SA negotiation takes place using the Internet Key Exchange
      (IKE) protocol.  IKE is designated to use port 500 on at least the
      destination side.  Some host IKE implementations will use source
      port 500 as well, but this behavior is not mandatory.  If two or
      more RSIP hosts are running IKE at source port 500, they MUST use
      different initiator cookies (the first eight bytes of the IKE
      payload) per assigned IP address.  The RSIP gateway will be able
      to route incoming IKE packets to the proper host based on
      initiator cookie value.  Initiator cookies can be negotiated, like
      ports and SPIs. However, since the likelihood of two hosts
      assigned the same IP address attempting to simultaneously use the
      same initiator cookie is very small, the RSIP gateway can
      guarantee cookie uniqueness by dropping IKE packets with a cookie
      value that is already in use.

   5.2.  Mobile IP

      ** NOTE WELL: This section may change significantly in the next
      rev **

      RSIP can be used as a configuration tool for coarse-grained
      mobility (nomadicity).  For example, a laptop or handheld device
      may use RSIP to temporarily register on a local network.  However,
      once the host de-registers from this network, or otherwise
      terminates its associated with the network, all ongoing
      communication between the host and its peers must also terminate.
      It is desirable for RSIP to support fine-grained mobility; i.e.,
      the ability to move between networks, and register and de-register
      with RSIP gateways, without tearing down any communications
      sessions.  Pragmatically speaking, this means that socket
      parameters, such as the host's IP address and port number(s) must
      remain the same as it roams.




Borella et. al.          Expires September 2000                [Page 20]

INTERNET DRAFT        Realm Specific IP: Framework            March 2000


      Mobile IP [RFC2002] provides the necessary mechanisms for a mobile
      host to maintain its sessions and socket parameters while it moves
      between its home network and foreign networks.  The goal of this
      draft is to discuss the architecture, requirements, and
      feasibility of integrating RSIP and Mobile IP.  In doing so we
      expect that the impact on both protocols will be minimal.  In
      particular, the modifications that we suggest below require minor
      messaging changes to both RSIP and Mobile IP.

      5.2.1.  Mobility Architecture

         The general architecture that we will consider is illustrated
         below: This architecture is similar to that discussed in
         Section 4, but has been annotated specifically for mobility.

         RMNa         RHAa     RHAp            RFAp     RFAb     RMNb

         RMN]------------[RHA]--------------------[RFA]-------------[RMN]

              (RSIP home       (public network "p")     (RSIP foreign
              network "a")                               network "b")

         In this diagram, an RMN roams between an RHN "a" and an RFN
         "b".  On RHN "a" the RMN uses private address RMNa, and on RFN
         "b" the RMN uses private address RMNb.  The RHA on the RHN uses
         private address RHAa and public address RHAp.  The RFA on the
         RFN uses private address RFAb and public address RFAp.  Note
         that the RFN may also act as an RHN for its RMNs, and the RHN
         may also act as an RFN for roaming RMNs.  In order so that the
         RMN can communicate with peers on the public network, the RHA
         assigns the RMN address RMNp (not shown).  RMNp may be
         identical to RHAp.

         Note that until standard Mobile IP, the address RMNa is not
         guaranteed to be unique.  This address is likely to be from the
         private space, so when the RMN is on RFN "b", RMNa may collide
         with other RMNs in the RFN, or with stationary nodes on the
         network.  Thus, it is necessary that the RMN be allocated RMNb
         when it is on RMN "b".  The recommended mechanism to do this
         with is DHCP.

         We assume that the RHA and RFA will always be on the boundary
         between public and private address spaces.  Thus RMNs can
         always be uniquely identified by the tuple (RMNa, RMNp),
         although other identification mechanisms may also be used.

      5.2.2.  Data Flow




Borella et. al.          Expires September 2000                [Page 21]

INTERNET DRAFT        Realm Specific IP: Framework            March 2000


         This section presents the flow of data between the participants
         in RSIP / Mobile IP transaction.  We ignore both RSIP and
         Mobile IP control flow and signaling for now - it is discussed
         in the next section.

         5.2.2.1.  Non-Roaming RMN

            When the RMN is not roaming; i.e., it is on the RHN, it
            operates just as if it were a stationary node.  All data
            flows according to [RSIP-PROTO].

         5.2.2.2.  Roaming RMN

            When the RMN is roaming, the typical routing scheme of
            Mobile IP is used.  In particular, if the RMN is
            communicating with a public node (PN) which has address PNp,
            the RMN will be known to the PN as RMNp. On the RFN, the RMN
            will have a local IP address of RMNb. In the case of RSAP-
            IP, the RMN will also be using ports allocated by the RHA.
            Packets sent from the RN to the RMN will be addressed
            identically to standard Mobile IP operation:

            +-------------+---------+
            | PNp -> RMNp | payload |
            +-------------+---------+

            Since the RHA will be advertising a route to RMNp, this
            packet will be received by the RHA.  The RHA will determine
            that the RMN is not on the RHN, and forward the packet to
            the RMN's care-of address, RFAp, via an IP-IP tunnel.

            +--------------+-------------+---------+
            | RHAp -> RFAp | PNp -> RMNp | payload |
            +--------------+-------------+---------+

            Once the packet arrives at the RFA, it terminates the IP-IP
            tunnel from the RHA and initiates a new IP-IP tunnel to the
            RMN, as shown below.

            +--------------+-------------+---------+
            | RFAb -> RMNb | PNp -> RMNp | payload |
            +--------------+-------------+---------+

            Packets from the RMN are transmitted via the same tunnel
            back to the RFA, and then on to the PN.






Borella et. al.          Expires September 2000                [Page 22]

INTERNET DRAFT        Realm Specific IP: Framework            March 2000


            +--------------+-------------+---------+
            | RMNb -> RFAb | RMNp -> PNp | payload |
            +--------------+-------------+---------+

      5.2.3.  Control Flow

         In this section, we illustrate the control flow (signaling)
         requirements for RSIP / Mobile IP.

         The RMN is always listening for the ICMP Mobile IP Agent
         Advertisement messages.  Upon receipt of such a message the RMN
         determines whether or not it is on the RHN.  The RMN may also
         transmit Agent Solicitation messages, as per Mobile IP.

         When the RMN determines that it has moved from a RHN to a RFN,
         or from a RFN to another RFN, it requests a local address
         (e.g., RMNb from above) then performs the Mobile IP
         registration process.  This process includes informing the RHA
         of the RMN's new care-of address.  Note that the RMN must
         identify itself uniquely to the RHA.  Since RMNp may be in use
         by more than one RMN at a time, the RMN must use either RMNa or
         a combination of RMNp and a port number or range of port
         numbers (in the case of RSAP-IP) that it has been allocated by
         the RHA.

         All RSIP messages that would normally flow between the RMN and
         the RHA must be forwarded by the RFA.  The RMN may request more
         resources from or return resources to the RHA.  The RMN must
         also be prepared to accept DEALLOCATE messages from the RHA
         which would force it to discontinue use of certain resources.
         Note that if the RMN de-registers from the RHA, it may lose
         connectivity entirely.

         All RSIP control messages must be tunneled between the RMN and
         the RFA, as well as between the RFA and the RHA.  The form of
         these tunnels is illustrated below.

         From RMN to RFA:

         +--------------+--------------+---------+
         | RMNb -> RFAb | RMNa -> RHAa | payload |
         +--------------+--------------+---------+

         From RFA to RHA:







Borella et. al.          Expires September 2000                [Page 23]

INTERNET DRAFT        Realm Specific IP: Framework            March 2000


         +--------------+--------------+---------+
         | RFAp -> RHAp | RMNa -> RHAa | payload |
         +--------------+--------------+---------+

         From RHA to RFA:

         +--------------+--------------+---------+
         | RHAp -> RFAp | RHAa -> RMNa | payload |
         +--------------+--------------+---------+

         From RFA to RMN:

         +--------------+--------------+---------+
         | RFAb -> RMNb | RHAa -> RMNa | payload |
         +--------------+--------------+---------+

         Since the RMN has a presence, in the form of an address (RMNb)
         on the RFN, it must reply to all ARP messages for RMNb.
         However, it MUST NOT respond to ARPs for RMNa or RMNp.  The RMN
         may communicate with other nodes on the RFN by using RMNb, and
         is thus not constrained to use port numbers allocated by the
         RHA (in the case of RSAP-IP) when communicating locally.

         The RHA must perform all RSIP gateway functions as defined in
         [RSIP-PROTO].  The RHA must also perform all home agent Mobile
         IP functions as defined in [RFC2002].

         The RFA must perform all foreign agent Mobile IP functions as
         defined in [RFC2002].  It must also maintain an IP-IP tunnel to
         all RMNs so that they can pass control and data flow packets.

   5.3.  Differentiated and Integrated Services

      To attain the capability of providing quality of service between
      two communicating hosts in different realms, it is important to
      consider the interaction of RSIP with different quality of service
      provisioning models and mechanisms. In the section, RSIP
      interaction with the integrated service and differentiated service
      frameworks is discussed.

      5.3.1.  Differentiated Services

         The differentiated services architecture defined in [RFC2475]
         allows networks to support multiple levels of best-effort
         service through the use of "markings" of the IP Type-of-Service
         (now DS) byte.  Each value of the DS byte is termed a
         differntiated services code point (DSCP) and represents a
         particular per-hop behavior.  This behavior may not be the same



Borella et. al.          Expires September 2000                [Page 24]

INTERNET DRAFT        Realm Specific IP: Framework            March 2000


         in all administrative domains.  No explicit signaling is
         necessary to support differentiated services.

         For outbound packets from an edge network, DSCP marking is
         typically performed and/or enforced on a boundary router.  The
         marked packet is then forwarded onto the public network.  In an
         RSIP-enabled network, a natural place for DSCP marking is the
         RSIP gateway.  In the case of RSAP-IP, the RSIP gateway can
         apply its micro-flow (address/port tuple) knowledge of RSIP
         assignments in order to provide different service levels to
         different RSIP host.  For RSA-IP, the RSIP gateway will not
         necessarily have knowledge of micro-flows, so it must rely on
         markings made by the RSIP hosts (if any) or apply a default
         policy to the packets.

         When differentiated services is to be performed between RSIP
         hosts and gateways, it must be done over the tunnel between
         these entities.  Differentiated services over a tunnel is
         considered in detail in [DS-TUNN], the key points that need to
         be addressed here are the behaviors of tunnel ingress and
         egress for both incoming and going packets.

         For incoming packets arriving at an RSIP gateway tunnel
         ingress, the RSIP gateway may either copy the DSCP from the
         inner header to the outer header, leave the inner header DSCP
         untouched, but place a different DSCP in the outer header, or
         change the inner header DSCP while applying either the same or
         a different DSCP to the outer header.

         For incoming packets arriving at an RSIP host tunnel egress,
         behavior with respect to the DSCP is not necessarily important
         if the RSIP host not only terminates the tunnel, but consumes
         the packet as well.  If this is not the case, as per some
         cascaded RSIP scenarios, the RSIP host must apply local policy
         to determine whether to leave the inner header DSCP as is,
         overwrite it with the outer header DSCP, or overwrite it with a
         different value.

         For outgoing packets arriving at an RSIP host tunnel ingress,
         the host  may either copy the DSCP from the inner header to the
         outer header, leave the inner header DSCP untouched, but place
         a different DSCP in the outer header, or change the inner
         header DSCP while applying either the same or a different DSCP
         to the outer header.

         For outgoing packets arriving at an RSIP gateway tunnel egress,
         the RSIP gateway must apply local policy to determine whether
         to leave the inner header DSCP as is, overwrite it with the



Borella et. al.          Expires September 2000                [Page 25]

INTERNET DRAFT        Realm Specific IP: Framework            March 2000


         outer header DSCP, or overwrite it with a different value.

         It is reasonable to assume that in most cases, the diffserv
         policy applicable on a site will be the same for RSIP and non-
         RSIP hosts. For this reason, a likely policy is that the DSCP
         will always be copied between the outer and inner headers in
         all of the above cases.  However, implementations should allow
         for the more general case.

      5.3.2.  Integrated Services

         The integrated services model as defined by [RFC2205] requires
         signalling using RSVP to setup a resource reservation in
         intermediate nodes between the communicating endpoints. In the
         most common scenario in which RSIP is deployed, receivers
         located within the private realm initiate communication
         sessions with senders located within the public realm. In this
         section, we discuss the interaction of RSIP architecture and
         RSVP in such a scenario. The less common case of having senders
         within the private realm and receivers within the public realm
         is not discussed although concepts mentioned here may be
         applicable.

         With senders in the public realm, RSVP PATH messages flow
         downstream from sender to receiver, inbound with respect to the
         RSIP gateway, while RSVP RESV messages flow in the opposite
         direction.  Since RSIP uses tunneling between the RSIP host and
         gateway within the private realm, how the RSVP messages are
         handled within the RSIP tunnel depends on situations elaborated
         in [RSVP-Tunnel].

         Following the terminology of [RSVP-Tunnel], if Type 1 tunnels
         exist between the RSIP host and gateway, all intermediate nodes
         inclusive of the RSIP gateway will be treated as a non-RSVP
         aware cloud without QoS reserved on these nodes. The tunnel
         will be viewed as a single (logical) link on the path between
         the source and destination. End-to-end RSVP messages will be
         forwarded through the tunnel encapsulated in the same way as
         normal IP packets.  We see this as the most common and
         applicable deployment scenario.

         However, should Type 2 or 3 tunnels be deployed between the
         tunneling endpoints , end-to-end RSVP session has to be
         statically mapped (Type 2) or dynamically mapped (Type 3) into
         the tunnel sessions. While the end-to-end RSVP messages will be
         forwarded through the tunnel encapsulated in the same way as
         normal IP packets, a tunnel session is established between the
         tunnel endpoints to ensure QoS reservation within the tunnel



Borella et. al.          Expires September 2000                [Page 26]

INTERNET DRAFT        Realm Specific IP: Framework            March 2000


         for the end-to-end session. Data traffic needing special QoS
         assurance will be encapsulated in a UDP/IP header while normal
         traffic will be encapsulated using the normal IP-IP
         encapsulation. In the type 2 deployment scenario where all data
         traffic flowing to the RSIP host receiver are given QoS
         treatment, UDP/IP encapsulation will be rendered in the RSIP
         gateway for all data flows. The tunnel between the RSIP host
         and gateway could be seen as a "hard pipe". Traffic exceeding
         the QoS guarantee of the "hard pipe" would fall back to the
         best effort IP-IP tunneling.

         In the type 2 deployment scenario where data traffic could be
         selectively channeled into the UDP/IP or normal IP-IP tunnel,
         or for type 3 deployment where end-to-end sessions could be
         dynamically mapped into tunnel sessions, integration with the
         RSIP model could be complicated and tricky. (Note that these
         are the cases where the tunnel link could be seen as a
         expandable soft pipe). Two main issues are worth considering.

         - For RSIP gateway implementations that does encapsulation of
           the incoming stream before passing to the IP layer for
           forwarding, the RSVP daemon has to be explicitly signaled
           upon reception of incoming RSVP PATH messages. The RSIP
           implementation has to recognize RSVP PATH messages and pass
           them to the RSVP daemon instead of doing the default
           tunneling. Handling of other RSVP messages would be as
           described in [RSVP-Tunnel].

         - RSIP enables an RSIP host to have a temporary presence at the
           RSIP gateway by assuming one of the RSIP gateway's global
           interfaces. As a result, the RSVP PATH messages would be
           addressed to the RSIP gateway. Also, the RSVP SESSION object
           within an incoming RSVP PATH would carry the global
           destination address, destination port (and protocol) tuples
           that were leased by the RSIP gateway to the RSIP host. Hence
           the realm unaware RSVP daemon running on the RSIP gateway has
           to be presented with a translated version of the RSVP
           messages. Other approaches are possible, for example making
           the RSVP daemon realm aware.

         A simple mechanism would be to have the RSIP module handle the
         necessary RSVP message translation. For an incoming RSVP
         signalling flow, the RSIP module does a packet translation of
         the IP header and RSVP SESSION object before handling the
         packet over to RSVP. The global address leased to the host is
         translated to the true private address of the host. (Note that
         this mechanism works with both RSA-IP and RSAP-IP). The RSIP
         module also has to do an opposite translation from private to



Borella et. al.          Expires September 2000                [Page 27]

INTERNET DRAFT        Realm Specific IP: Framework            March 2000


         global parameter (plus tunneling) for end-to-end PATH messages
         generated by the RSVP daemon towards the RSIP host receiver. A
         translation on the SESSION object also has to be done for RSVP
         outbound control messages. Once the RSVP daemon gets the
         message, it maps them to an appropriate tunnel sessions.

         Encapsulation of the inbound data traffic needing QoS treatment
         would be done using UDP-IP encapsulation designated by the
         tunnel session. For this reason, the RSIP module has to be
         aware of the UDP-IP encapsulation to use for a particular end-
         to-end session. Classification and scheduling of the QoS
         guaranteed end-to-end flow on the output interface of the RSIP
         gateway would be based on the UDP/IP encapsulation.  Mapping
         between the tunnel session and end-to-end session could
         continue to use the mechanisms proposed in [RSVP-Tunnel].
         Although [RSVP-Tunnel] proposes a number of approaches for this
         purpose, we propose using the SESSION_ASSOC object introduced
         because of its simplicity.

   5.4.  IP Multicast

      The amount of specific RSIP/multicast support that is required in
      RSIP hosts and gateways is dependent on the scope of multicasting
      in the RSIP-enabled network, and the roles that the RSIP hosts
      will play.  In this section, we discuss RSIP and multicast
      interactions in a number of scenarios.

      Note that in all cases, the RSIP gateway MUST be multicast aware
      because it is on an administrative boundary between two domains
      that will not be sharing their all of their routing information.
      The RSIP gateway MUST NOT allow private IP addresses to be
      propagated on the public network as part of any multicast message
      or as part of a routing table.

      5.4.1.  Receiving-Only Private Hosts, No Multicast Routing on
         Private Network

         In this scenario, private hosts will not source multicast
         traffic, but they may join multicast groups as recipients.  In
         the private network, there are no multicast-aware routers,
         except for the RSIP gateway.

         Private hosts may join and leave multicast groups by sending
         the appropriate IGMP messages to an RSIP gateway (there may be
         IGMP proxy routers between RSIP hosts and gateways).  The RSIP
         gateway will coalesce these requests and perform the
         appropriate actions, whether they be to perform a multicast WAN
         routing protocol, such as PIM, or to proxy the IGMP messages to



Borella et. al.          Expires September 2000                [Page 28]

INTERNET DRAFT        Realm Specific IP: Framework            March 2000


         a WAN multicast router.  In other words, if one or more private
         hosts request to join a multicast group, the RSIP gateway MUST
         join in their stead, using one of its own public IP addresses.

         Note that private hosts do not need to acquire demultiplexing
         fields and use RSIP to receive multicasts.  They may receive
         all multicasts using their private addresses, and by private
         address is how the RSIP gateway will keep track of their group
         membership.

      5.4.2.  Sending and Receiving Private Hosts, No Multicast Routing
         on Private Network

         This scenarios operates identically to the previous scenario,
         except that when a private host becomes a multicast source, it
         MUST use RSIP and acquire a public IP address (note that it
         will still receive on its private address).  A private host
         sending a multicast will use a public source address and tunnel
         the packets to the RSIP gateway.  The RSIP gateway will then
         perform typical RSIP functionality, and route the resulting
         packets onto the public network, as well as back to the private
         network, if there are any listeners on the private network.

         If there is more than one sender on the private network, then,
         to the public network it will seem as if all of these senders
         share the same IP address.  If a downstream multicasting
         protocol identifies sources based on IP address alone and not
         port numbers, then it is possible that these protocols will not
         be able to distinguish between the senders.

6.  Changelog

      03 to 04
      - 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".
      - Noted that limiting the MTU size for non-TCP-using applications
        is application dependent.
      - Modified diffserv section to note that most site will probably
        copy the DSCP between headers, but implementations should be
        flexible.
      - Noted that the Mobile IP section will change soon.




Borella et. al.          Expires September 2000                [Page 29]

INTERNET DRAFT        Realm Specific IP: Framework            March 2000


      02 to 03
      - Added section on interaction with Integrated and Differentiated
        Services
      - Added section on document scope.
      - Reorganized draft into three main areas: implementation, deployment,
        and interaction with other protocols.
      - Added section on protocol requirements and recommendations, which
        replaces several old sections with much more concise verbiage, and
        now contains a discussion of authentication.
      - Added section on interaction with DNS
      - Added section on locating RSIP gateways
      - Added overview of RSIP/IPSEC
      - Added overview of integration with diffserv
      - Added section on interaction with multicast

      01 to 02:
      - Added section on Mobile IP integration
      - Added to section on cascaded RSIP
      - Added section on host and gateway requirements
      - Added RSIP for multi-homed network
      - Added deployment scenarios
      - Added section on RSAP-IP support for gateways
      - Added section on MTU limitations
      - Elaborated on discussion in the Architecture section
      - Elaborated on discussion under demultiplexing fields
      - Elaborated on discussion on Negotiation Protocol
      - Clarified section on tunneling between the host and gateway
      - Editorial changes

      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 Host Deallocation" discussion section
      - Added more explanation in "Tunnel Use and Establishment" section

7.  Security Considerations

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

8.  Acknowledgements



Borella et. al.          Expires September 2000                [Page 30]

INTERNET DRAFT        Realm Specific IP: Framework            March 2000


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

9.  References

   [DHC-NS] J. Privat and M. Borella, "DHCP Next Server Option," <draft-
      xxxx-nextserver-00.txt>, to be submitted, Dec. 1999.

   [DHCP-DNS] M. Stapp and Y. Rekhter, "Interaction Between DHCP and
      DNS," <draft-ietf-dhc-dhcp-dns-11.txt>, work in progress, Oct.
      1999.

   [DS-TUNN] D. Black, "Differentiated Services and Tunnels," <draft-
      black-diffserv-tunnels-00.txt>, work in progress, Oct. 1999.

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

   [RSIP-PROTO] M. Borella, D. Grabelsky, J. Lo and K.  Taniguchi,
      "Realm Specific IP: Protocol Specification," <draft-ietf-nat-rsip-
      protocol-04.txt>, work in progress, Nov. 1999.

   [RSVP-Tunnel] A. Terzis, J. Krawczyk, J. Wroclawski, L. Zhang, "RSVP
      Operation Over IP Tunnels," <draft-ietf-rsvp-tunnel-04.txt>, work-
      in-progress, Nov. 1999

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

   [RFC2002] C. Perkins, "IP Mobility Support," RFC 2002, Oct. 1996.

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

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

   [RFC2205] R. Braden, L. Zhang, S. Berson, S. Herzog, S. Jamin,
      "Resource Reservation Protocol (RSVP)," RFC 2205, Sep. 1997

   [RFC2475] S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, W.
      Weiss, "An Architecture for Differentiated Services," RFC 2475,
      Dec. 1998



Borella et. al.          Expires September 2000                [Page 31]

INTERNET DRAFT        Realm Specific IP: Framework            March 2000


10.  Authors' Addresses

   Michael Borella
   3Com Corp.
   1800 W. Central Rd.
   Mount Prospect IL 60056
   (847) 342-6093
   mike_borella@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

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

   Gabriel E. Montenegro
   Sun Microsystems, Inc.
   15 Network Circle
   Menlo Park CA 94025
   650 786 6288
   gab@sun.com

11.  Copyright Statement

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




Borella et. al.          Expires September 2000                [Page 32]

INTERNET DRAFT        Realm Specific IP: Framework            March 2000


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

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










































Borella et. al.          Expires September 2000                [Page 33]


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