Network Working Group Editors:
`Request for Comments: 3102 M. Borella
`Category: Experimental CommWorks
` J. Lo
` Candlestick Networks
` Contributors:
` D. Grabelsky
` CommWorks
` G. Montenegro
` Sun Microsystems
` October 2001
`
` Realm Specific IP: Framework
`
`Status of this Memo
`
` This memo defines an Experimental Protocol for the Internet
` community. It does not specify an Internet standard of any kind.
` Discussion and suggestions for improvement are requested.
` Distribution of this memo is unlimited.
`
`Copyright Notice
`
` Copyright (C) The Internet Society (2001). All Rights Reserved.
`
`IESG Note
`
` The IESG notes that the set of documents describing the RSIP
` technology imply significant host and gateway changes for a complete
` implementation. In addition, the floating of port numbers can cause
` problems for some applications, preventing an RSIP-enabled host from
` interoperating transparently with existing applications in some cases
` (e.g., IPsec). Finally, there may be significant operational
` complexities associated with using RSIP. Some of these and other
` complications are outlined in section 6 of RFC 3102, as well as in
` the Appendices of RFC 3104. Accordingly, the costs and benefits of
` using RSIP should be carefully weighed against other means of
` relieving address shortage.
`
`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.
`
`Borella, et al. Experimental [Page 1]
`
`Ex. 1019
`Apple v. MPH Techs. Oy
`IPR2019-00822
`
`

`

`RFC 3102 RSIP: Framework October 2001
`
`Table of Contents
`
`2
`1. Introduction . . . . . . . . . . . . . . . . . . . . . . . .
`1.1. Document Scope . . . . . . . . . . . . . . . . . . . . . . 4
`1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4
`1.3. Specification of Requirements . . . . . . . . . . . . . . . 5
`2. Architecture . . . . . . . . . . . . . . . . . . . . . . . .
`6
`3. Requirements . . . . . . . . . . . . . . . . . . . . . . . .
`7
`3.1. Host and Gateway Requirements . . . . . . . . . . . . . . . 7
`3.2. Processing of Demultiplexing Fields . . . . . . . . . . . . 8
`3.3. RSIP Protocol Requirements and Recommendations . . . . . . 9
`3.4. Interaction with DNS . . . . . . . . . . . . . . . . . . . 10
`3.5. Locating RSIP Gateways . . . . . . . . . . . . . . . . . . 11
`3.6. Implementation Considerations . . . . . . . . . . . . . . . 11
`4. Deployment . . . . . . . . . . . . . . . . . . . . . . . . . 12
`4.1. Possible Deployment Scenarios . . . . . . . . . . . . . . . 12
`4.2. Cascaded RSIP and NAT . . . . . . . . . . . . . . . . . . . 14
`5. Interaction with Layer-Three Protocols . . . . . . . . . . . 17
`5.1. IPSEC . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
`5.2. Mobile IP . . . . . . . . . . . . . . . . . . . . . . . . . 18
`5.3. Differentiated and Integrated Services . . . . . . . . . . 18
`5.4. IP Multicast . . . . . . . . . . . . . . . . . . . . . . . 21
`6. RSIP Complications . . . . . . . . . . . . . . . . . . . . . 23
`6.1. Unnecessary TCP TIME_WAIT . . . . . . . . . . . . . . . . . 23
`6.2. ICMP State in RSIP Gateway . . . . . . . . . . . . . . . . 23
`6.3. Fragmentation and IP Identification Field Collision . . . . 24
`6.4. Application Servers on RSAP-IP Hosts . . . . . . . . . . . 24
`6.5. Determining Locality of Destinations from an RSIP Host. . . 25
`6.6. Implementing RSIP Host Deallocation . . . . . . . . . . . . 26
`6.7. Multi-Party Applications . . . . . . . . . . . . . . . . . 26
`6.8. Scalability . . . . . . . . . . . . . . . . . . . . . . . . 27
`7. Security Considerations . . . . . . . . . . . . . . . . . . . 27
`8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 27
`9. References . . . . . . . . . . . . . . . . . . . . . . . . . 28
`10. Authors’ Addresses . . . . . . . . . . . . . . . . . . . . . 29
`11. Full Copyright Statement . . . . . . . . . . . . . . . . . . 30
`
`1. Introduction
`
` 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.
`
`Borella, et al. Experimental [Page 2]
`
`

`

`RFC 3102 RSIP: Framework October 2001
`
` While NAT does not require a host to be aware of its presence, it
` requires the presence of an application layer gateway (ALG) within
` the NAT router for each application that embeds addressing
` information within the packet payload. For example, most NATs ship
` with an ALG for FTP, which transmits IP addresses and port numbers on
` its control channel. 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 in a different
` addressing realm.
`
` RSIP can be viewed as a "fix", of sorts, to NAT. It may ameliorate
` some IP address shortage problems in some scenarios without some of
` the limitations of NAT. However, it is not a long-term solution to
` the IP address shortage problem. RSIP allows a degree of address
` realm transparency to be achieve between two differently-scoped, or
` completely different addressing realms. This makes it a useful
` architecture for enabling end-to-end packet transparency between
` addressing realms. RSIP is expected to be deployed on privately
` addresses IPv4 networks and used to grant access to publically
` addressed IPv4 networks. However, in place of the private IPv4
` network, there may be an IPv6 network, or a non-IP network. Thus,
` RSIP allows IP connectivity to a host with an IP stack and IP
` applications but no native IP access. As such, RSIP can be used, in
` conjunction with DNS and tunneling, to bridge IPv4 and IPv6 networks,
` such that dual-stack hosts can communicate with local or remote IPv4
` or IPv6 hosts.
`
` It is important to note that, as it is defined here, RSIP does NOT
` require modification of applications. All RSIP-related modifications
` to an RSIP host can occur at layers 3 and 4. However, while RSIP
` does allow end-to-end packet transparency, it may not be transparent
` to all applications. More details can be found in the section "RSIP
` complications", below.
`
`Borella, et al. Experimental [Page 3]
`
`

`

`RFC 3102 RSIP: Framework October 2001
`
`1.1. Document Scope
`
` This document provides a framework for RSIP by focusing on four
` particular areas:
`
` - Requirements of an RSIP host and RSIP gateway.
`
` - Likely initial deployment scenarios.
`
` - Interaction with other layer-three protocols.
`
` - Complications that RSIP may introduce.
`
` 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.
`
` 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.
`
` This document focuses on scenarios that allow privately-addressed
` IPv4 hosts or IPv6 hosts access to publically-addressed IPv4
` networks.
`
`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 globally unique network addresses.
`
` RSIP Host
`
` A host within an addressing realm that uses RSIP to acquire
` addressing parameters from another addressing realm via an RSIP
` gateway.
`
`Borella, et al. Experimental [Page 4]
`
`

`

`RFC 3102 RSIP: Framework October 2001
`
` RSIP Gateway
`
` A router or gateway situated on the boundary between two
` addressing realms that is assigned one or more IP addresses in at
` least one of the realms. 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
` 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.
`
` 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].
`
`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].
`
`Borella, et al. Experimental [Page 5]
`
`

`

`RFC 3102 RSIP: Framework October 2001
`
`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 borrows addressing parameters as the
` "public" realm. However, these realms may both be public or private
` - our notation is for convenience. In fact, address space A may be
` an IPv6 realm or a non-IP address space.
`
` 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.
`
` 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
`
`Borella, et al. Experimental [Page 6]
`
`

`

`RFC 3102 RSIP: Framework October 2001
`
` 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. Requirements
`
`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
`
`Borella, et al. Experimental [Page 7]
`
`

`

`RFC 3102 RSIP: Framework October 2001
`
` 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 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 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 [RFC3104])
`
` - others
`
` Note that these fields may be augmented by source IP address and
` source TCP or UDP port.
`
`Borella, et al. Experimental [Page 8]
`
`

`

`RFC 3102 RSIP: Framework October 2001
`
` 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
`
` - 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:
`
`Borella, et al. Experimental [Page 9]
`
`

`

`RFC 3102 RSIP: Framework October 2001
`
` - 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 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. 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.
`
`Borella, et al. Experimental [Page 10]
`
`

`

`RFC 3102 RSIP: Framework October 2001
`
` 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 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.5. 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 could provide the IP address of an RSIP
` gateway in DHCPOFFER messages. Thus, the host’s startup procedure
` would be as follows: (1) perform DHCP, (2) if an RSIP gateway option
` is present in the DHCPOFFER, record the IP address therein as the
` RSIP gateway.
`
` Alternatively, the RSIP gateway can be discovered via SLP (Service
` Location Protocol) as specified in [SLP-RSIP]. The SLP template
` defined allows for RSIP service provisioning and load balancing.
`
`3.6. Implementation Considerations
`
` 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.
`
`Borella, et al. Experimental [Page 11]
`
`

`

`RFC 3102 RSIP: Framework October 2001
`
` 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 beneath all applications
` that use the stack.
`
`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.
`
`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
`
`Borella, et al. Experimental [Page 12]
`
`

`

`RFC 3102 RSIP: Framework October 2001
`
` 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 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.
`
`Borella, et al. Experimental [Page 13]
`
`

`

`RFC 3102 RSIP: Framework October 2001
`
`4.2. Cascaded RSIP and NAT
`
` It is possible for RSIP to allow for cascading of RSIP gateways as
` well as cascading of RSIP gatewa