INTERNET DRAFT Editors:
Expires April 2000 M. Borella
3Com Corp.
J. Lo
NEC USA
Contributors:
D. Grabelsky
3Com Corp
G. Montenegro
Sun Microsystems
October 1999
Realm Specific IP: Framework
<draft-ietf-nat-rsip-framework-02.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 draft 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 document RSIP's
interaction with other layer-three protocols and discuss the
tradeoffs between different methods for implementing RSIP.
1. Introduction
Borella et. al. Expires April 2000 [Page 1]
INTERNET DRAFT Realm Specific IP: Framework October 1999
Network Address Translation (NAT) has become a popular mechanism of
enabling private addressing and 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 such end-to-end
connectivity, such as the network security protocols which embody
IPSEC.
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). Given these limitations, RSIP has emerged as a
alternative to remedy them.
RSIP is based on the concept of granting 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. RSIP requires ability of the RSIP server to
grant such resources to RSIP clients. Hosts requiring end-to-end
connectivity from the first addressing realm to the second also has
to be RSIP aware. ALGs are not required on the RSIP server for
communications between an RSIP client 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 smooth the IPv6 transition process.
Upcoming documents will explain this transition in more detail.
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 Server
Borella et. al. Expires April 2000 [Page 2]
INTERNET DRAFT Realm Specific IP: Framework October 1999
A router situated on the boundary between a private realm and a
public realm and owns one or more public IP addresses. An RSIP
server is responsible for public parameter management and
assignment to RSIP clients. An RSIP server may act as a normal NAT
router for hosts within the private realm that are not RSIP
enabled.
RSIP Client
A host within the private realm that assumes publicly unique
parameters from an RSIP server through the use of RSIP.
RSA-IP: Realm Specific Address IP
An RSIP method in which each RSIP client is allocated a unique IP
address from the public realm. Discussed in detail in [RFC2663]
RSAP-IP: Realm Specific Address and Port IP
An RSIP method in which each RSIP client is allocated an IP
address (possibly shared with other RSIP clients) and some number
of per-address unique ports from the public realm. Discussed in
detail in [RFC2663]
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 server, 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-
Borella et. al. Expires April 2000 [Page 3]
INTERNET DRAFT Realm Specific IP: Framework October 1999
enabled mobile nodes. This router may or may not use RSIP on its
local network.
All other terminology found in this document is consistent with that
of [RFC2663] and [RFC2002].
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].
4. Architecture
In a typical scenario where RSIP is deployed, there are some number
of hosts within one addressing realm connected to another addressing
realm by the RSIP server. This model is diagrammatically represented
as follows:
RSIP Client RSIP Server Host
Xa Na Nb Yb
[X]------( Addr sp. A )----[N]-----( Addr sp. B )-------[Y]
( Network ) ( Network )
Hosts X and Y belong to different addressing realms A and B,
respectively, and N is an RSIP server (which may also act as a NAT
router). 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
server is multi-homed with one or more private addresses from address
space A in addition to it's public addresses from address space B.
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 server. Upon assignment
of these parameters, the RSIP server creates a mapping, known as a
bind, of X's addressing information and the assigned resources. This
binding enables the RSIP server to correctly de-multiplex and forward
inbound traffic generated by Y for X. If permitted by the RSIP
server, X may create multiple such bindings on the same RSIP server.
A lease time SHOULD be associated with each bind.
Using the public parameters assigned by the RSIP server, RSIP clients
Borella et. al. Expires April 2000 [Page 4]
INTERNET DRAFT Realm Specific IP: Framework October 1999
route (usually tunnel) data packets to the RSIP server within address
space A. If tunneling is used, the RSIP server acts as the end point
of such tunnels, stripping off the outer headers and routing the
inner packets onto the public realm. As mentioned above, an RSIP
server maintains a mapping of the assigned public parameters as
demultiplexing tuples for uniquely mapping them to RSIP client
private addresses. When a packet from the public realm arrives at
the RSIP server and it matches a given set of demultiplexing tuples,
then the RSIP server will tunnel it to the appropriate RSIP client.
A disadvantage of RSIP is that it requires modification of RSIP
clients to enable RSIP client-server negotiation, usage of the
assigned resources and in the case when tunneling is used, to tunnel
the data packets to the RSIP server.
5. Client and Server Requirements
An RSIP client must be able to maintain one or more virtual
interfaces for the IP address(es) that it leases from an RSIP server.
The client must also support tunneling and be able to serve as an
end-point for one or more tunnels to RSIP servers. An RSIP client
MUST NOT respond to ARPs for a public realm address that it leases.
An RSIP server is a multi-homed host that routes packets between two
or more realms. It must also support tunneling and be able to serve
as an end-point for tunnels to RSIP clients. The RSIP server 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
server must reassemble all incoming packet fragments from the public
network in order to be able to route and tunnel them to the proper
client. As is necessary for all fragment reassembly, an RSIP server
must timeout fragments that are never fully reassembled.
6. Demultiplexing Fields
Assume that an RSIP client within a private realm has transmitted a
request to a public server within a public realm, and the public
server has sent a response packet that successfully arrived at the
RSIP server. Based on a pre-arranged mapping, the RSIP server must be
able to determine the private IP address of the packet's destination;
i.e., the RSIP client. The only information that the RSIP server may
use is what is already contained within the headers of the inbound
data packet, or in the payload of the packet if said payload is not
encrypted. We will refer to these header fields as the
"demultiplexing fields" as they are used to spread the incoming
streams of packets to multiple destinations within the private realm.
Depending on the type of mapping used by the RSIP server,
Borella et. al. Expires April 2000 [Page 5]
INTERNET DRAFT Realm Specific IP: Framework October 1999
demultiplexing fields have been defined in [RSIP-PROTO] 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 IKE payload (see [RSIP-IPSEC])
- others
Demultiplexing of incoming traffic could be logically thought of as a
decision tree, which could be represented as follows :
- In the case where a public IP address is assigned for each client,
a unique public IP address is mapped to each RSIP client.
- If the same IP address is used for more than one RSIP client,
then subsequent headers must have at least one field that will
be assigned a unique value per client 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 and UDP port number is
the same for more than one RSIP client, the payload section of
the packet must contain a demultiplexing field that is guaranteed
to be different for each RSIP client.
- If the subsequent header is anything other than TCP or UDP, there
must exist other fields within the IP payload usable as a
demultiplexing fields.
It is desirable for all demultiplexing fields to occur in well-known
fixed locations so that an RSIP server can mask out and examine the
appropriate fields on incoming packets.
7. Negotiation Protocol
7.1. Encapsulation
Demultiplexing of incoming streams of packet requires pre-
assignment of the demultiplexing fields to RSIP clients. Hence
there exists a requirement for a negotiation protocol that enables
these parameters to be negotiated between RSIP server and RSIP
clients. Such a negotiation can be based on the following
approaches.
- As an extension of current host configuration or policy protocols
such as DHCP, COPS, RADIUS, DIAMETER, or SOCKS.
- During tunnel establishment, for example as an extension to L2TP
Borella et. al. Expires April 2000 [Page 6]
INTERNET DRAFT Realm Specific IP: Framework October 1999
parameter negotiation.
- As an RSIP specific protocol such as described in [RSIP-PROTO].
In order to ease initial deployment of RSIP, the protocol
described in [RSIP-PROTO] is the recommended approach.
The demultiplexing fields to be negotiated may actually differ
depending on the data traffic type that the RSIP client is
negotiating for. For example, for IPSEC data traffic using
Security Payload Index (SPI) as the demultiplexing field, the
assignment of SPI value has to be negotiated. Hence it is
necessary to have a mechanism built into the negotiation protocol
that enables RSIP client to indicate to the RSIP server which data
type it is negotiating the parameters for. Using this information,
the RSIP server would be able to associate the binding information
to the appropriate location on the decision tree.
7.2. Transport
The RSIP protocol defined in [RSIP-PROTO] has been defined to
operate over either UDP or TCP. Despite the well-known advantages
and disadvantages of each of these protocols, it is important to
consider the particular characteristic of RSIP before deciding on
a transport for the negotiation protocol.
RSIP is likely to be a candidate for thin clients and embedded
systems. These devices are typically implemented on hardware that
is processing and memory constrained. Thus, UDP is a natural
candidate. However, UDP adds additional complexity to the
application layer implementation, because both client and server
must perform timeouts and retransmissions. Furthermore, it is
easier for the client and server to fall out of synchronization
with each other.
A TCP implementation not only has the advantage of reliability,
and therefore a simpler application design, but also it is easier
for a server to audit and authenticate a TCP stream. In large
deployments, however, such as large enterprise networks with
thousands of potential RSIP clients, the number of TCP sessions
available at the RSIP server may become a bottleneck. In this
case, use of UDP may be necessary.
TCP is the recommended transport protocol for RSIP. RSIP servers
SHOULD support both TCP and UDP for RSIP transport because not all
client devices will have a TCP module available and UDP may be
more desirable than TCP in some scenarios.
It should be noted that if RSIP is to be used by remote access
Borella et. al. Expires April 2000 [Page 7]
INTERNET DRAFT Realm Specific IP: Framework October 1999
concentrators, then the RSIP protocol will likely be implemented
on top on IPCP.
7.3. Control Parameters
Apart from negotiation of demultiplexing fields, other information
pertaining to the assignment of those fields may also need to be
negotiated. Examples of such control parameters are:
- Client ID: The negotiation protocol MAY support registration of the
RSIP client with the RSIP server. Upon a successful registration, a
client ID unique to the RSIP client entity is generated. The client ID
facilitates the association of an RSIP client record on an RSIP
server with its established bindings. After the registration,
further communication between the RSIP client and server MAY use the
client ID as an identifier. The client ID is removed upon client
de-registration.
- Bind ID: A binding identifier MAY be assigned for each public
parameter assignment. The binding identifier serves to uniquely
identify the resource(s) that has been allocated by an RSIP server. It
may also be used during lookup to efficiently index existing bindings.
- Lease time: A duration may be associated with each bind of public
parameters to an RSIP client.
- RSIP method: RSIP clients MAY require that the RSIP server specify
how it allocates address and port resources (referred to as the RSIP
method). RSIP servers may only allocate a public IP address to each
unique host, known as RSA-IP. Or, RSIP-servers may distribute a
(potentially shared) public IP address and a unique port range per
that IP address to each host, termed RSAP-IP. In addition, RSIP
extension for a new protocol may define a new RSIP method such that
RSIP server could assign protocol specific demultiplexing fields
based on the new RSIP methods.
- Tunnel Type: The type of tunnel to use between an RSIP client and
RSIP server. For example, IP-IP, GRE, L2TP, and so on.
The negotiation and assignment mechanism SHOULD be extensible and
facilitate vendor specific parameters.
8. Tunnel Use and Establishment on the Private Network
Once the public demultiplexing fields have been allocated by the RSIP
server, RSIP clients will be able to use them freely. However, RSIP
requires data packets to be tunneled between the RSIP client and
server within the private realm since public routing information is
not advertised in the private realm. The type of tunnel may be IP-IP,
GRE, IPSEC tunnel mode, L2TP, or other forms. IP-IP tunneling is the
preferred mode and MUST be implemented by all RSIP devices that use
UDP or TCP.
Borella et. al. Expires April 2000 [Page 8]
INTERNET DRAFT Realm Specific IP: Framework October 1999
The tunneling requirement allows the RSIP server to be able to
transmit a packet it receives from the public network to the
appropriate RSIP client on the private network. While tunneling is
not absolutely necessary in order to transmit packets from the RSIP
client to the RSIP server, it is advantageous to establish a tunnel
in this direction as well since it is likely that an RSIP server will
also act as a firewall or packet filter for the private network. In
this case, if publically addressed packets are transmitted on the
private network, the RSIP server may consider these packets to be
part of an attack.
Tunnels may be established statically or dynamically between RSIP
clients and servers. A static tunnel is established at RSIP
initiation and remains in service until the host is no longer using
the public network. A dynamic tunnel is established at the beginning
of a session or flow and exists only for the lifetime of the session.
Both types of tunnels may allow for on-the-fly re-negotiation of
demultiplexing fields and re-assignment of parameters to RSIP
clients. If tunneling is used to route the publicly addressed packet
within private realm, public parameter negotiation could be
associated with tunnel establishment mechanisms. Alternatively, a
negotiation protocol may enable the negotiation of tunnel type as
well.
9. MTU Limitation to Prevent Fragmentation and ID Collision
RSIP clients MUST limit their MTU so that packets transmitted by an
RSIP server are not fragmented. If two or more RSIP clients on the
same private network transmit outbound packets that get fragmented to
the same public server, the public server 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 work
properly. For UDP packets, an artificially small MTU, such as 512
bytes, is required. We expect that the impact of this limitation
will be small since UDP packets found on a public network should be
typically less than a few hundred bytes.
10. Servers on RSAP-IP Clients
RSAP-IP clients are limited by the same constraints as NAT with
respect to hosting servers that use a well-known port. Since
destination port numbers are used as routing information to uniquely
identify an RSAP-IP client, typically no two RSAP-IP clients sharing
the same public IP address can simultaneously operate publically-
available servers on the same port. For protocols that operate on
well-known ports, this implies that only one public server per RSAP-
IP IP address / port tuple is used simultaneously. However, more
Borella et. al. Expires April 2000 [Page 9]
INTERNET DRAFT Realm Specific IP: Framework October 1999
than one server per RSAP-IP IP address / port tuple may be used
simultaneously if and only if there is a unique token within the
payload of all packets that will determine the identity of the RSAP-
IP client, and this token is known by the RSIP server (see [RSIP-
IPSEC]).
In order for an RSAP-IP client to operate a publically-available
server, the client must inform the RSIP server 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 client. See [RSIP-PROTO] for an example of the
signaling required in order to enable such a mechanism.
11. Determining Locality of Destinations from an RSIP Client
In general, an RSIP client must know, for a particular IP address,
whether it should transmit the packet normally for local delivery, or
tunnel the packet to the RSIP server. Since more than one subnet may
be behind an RSIP server, looking at a local subnet mask will not
always work. We'd rather not have to propagate routing tables to all
RSIP clients. A simple alternative, proposed in [RSIP-PROTO], that
will solve this problem is to require that the RSIP server knows all
of the subnets that are on the private network. This information can
be manually entered because it is not expected to change often.
Then, if an IP address in question is not on a host's local subnet,
the host can query the server with the address. The RSIP server will
return a simple "yes or "no" answer - yes, this address is local, or
no, it is not. As proposed in [RSIP-PROTO], a queried RSIP server may
respond with the list of subnets supported. An RSIP client may cache
this information. However, in large enterprise networks, an RSIP
server may not be aware of all private subnets.
Alternatively, RSIP-clients could send all packets for destinations
without an explicit static route to the RSIP server. If they arrive
at the RSIP server, it informs the host that it should instead tunnel
the packet. The host then acquires the necessary public parameters
and tunnels the packet, to the RSIP server. This approach may require
further changes to the TCP/IP stack at the host, since, in the case
of TCP traffic, a half-open TCP socket must be discarded. Likewise,
the RSIP client could at first tunnel the packets to the RSIP server.
If the server determines that the destination is local, it would
inform the host of this fact and the host could then transmit the
packet in the standard fashion. Regardless of the solution chosen,
RSIP clients caching the "locality" of recently-contacted IP
addresses may be beneficial.
12. Implementing RSIP Client Deallocation
Borella et. al. Expires April 2000 [Page 10]
INTERNET DRAFT Realm Specific IP: Framework October 1999
As currently defined in [RSIP-PROTO], an RSIP client MAY free
resources that it has determined it no longer requires. For example,
on a large RSAP-IP subnet with a limited number of public IP
addresses, locally-unique port numbers may become scarce. Thus, if
RSIP clients are able to deallocate ports that they no longer need,
RSIP will be more scalable.
However, this functionality may require significant modifications to
a vanilla TCP/IP stack in order to implement properly. The RSIP
client must be able to determine which TCP or UDP sessions are using
RSIP resources. If those resources are unused for a period of time,
then the RSIP client may deallocate them. When an open socket's
resources are deallocated, it will cause some associated applications
to fail. An analogous case would be TCP and UDP sessions that must
terminate when a PPP interface that they are using loses
connectivity.
On the other hand, this issue can be considered a resource allocation
problem. It is not recommended that a large number (hundreds) of
hosts share the same IP address, for performance purposes. Even if,
say, 100 hosts each are allocated 100 ports, the total number of
ports in use by RSIP would be still less than one-sixth the total
port space for an IP address. If more hosts or more ports are
needed, more IP addresses should be used. Thus, it is reasonable,
that in many cases, RSIP clients will not have to deallocate ports
for the lifetime of their activity.
Similarly, it is non-trivial for an RSIP client to know when to
allocate ports. It will have to detect activity on a socket,
determine if the destination host is local or external, and then
request the appropriate resources. In cases when the allocation
requires multiple rounds, for example when more than one public
resources are to be allocated and multiple assignment requests are
issued or a request gets denied a number of times, delays may be
introduced by the resource allocation process.
13. RSIP Deployment
Although the goal of this draft is to consider the general issues
related to RSIP, there are specific issues that will need to be
addressed when RSIP is deployed in different scenarios.
13.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.
Borella et. al. Expires April 2000 [Page 11]
INTERNET DRAFT Realm Specific IP: Framework October 1999
13.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 server. This RSIP
server may control only one, or perhaps several, public IP
addresses. The RSIP server may also perform firewall
functions, as well as routing inbound traffic to particular
destination ports on to a small number of dedicated servers on
the private network.
13.1.2. Large Enterprise
From several hundred to hundreds of thousands of hosts reside
behind multiple RSIP servers and gateways to the public
network. Each RSIP server may control multiple IP addresses
and perform firewall functions as well as routing traffic to
particular destination ports on to a small number of dedicated
servers on the private network. Each of these servers MUST
register their service port number with all RSIP servers.
Server redundancy, replication and failover mechanisms MUST be
provided.
13.1.3. 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 server's resources. In
particular, many of these devices may be thin clients or so-
called "network appliances" and therefore not require access to
the public Internet frequently. The RSIP server 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 servers on the private network.
It is likely that only one gateway to the public network will
be present and that this gateway's RSIP server will control
only one IP address. Support for secure end-to-end VPN access
to corporate intranets will be important.
13.1.4. 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 server's resources. The
RSIP server may be implemented as part of a firewall, and it
will probably not be used to route traffic to particular
Borella et. al. Expires April 2000 [Page 12]
INTERNET DRAFT Realm Specific IP: Framework October 1999
destination ports on to dedicated servers on the private
network. It is likely that only one gateway to the public
network will be present and that this gateway's RSIP server
will control only one IP address. Support for secure end-to-
end VPN access to corporate intranets will be important.
13.1.5. Dialup Remote Access
RSIP servers 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 server's
resources. The RSIP server 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 servers
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 server will control a small number of
IP addresses. Support for secure end-to-end VPN access to
corporate intranets will be important. The RSIP protocol will
be just between the client host and the remote access server,
and therefore use IPCP instead of UDP or TCP.
13.1.6. 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 server for a short period of time. At
most several hundred hosts will share the server's resources.
The RSIP server 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 servers on the private
network. It is likely that only one gateway to the public
network will be present and that this gateway's RSIP server
will control a small number of IP addresses. Support for
secure end-to-end VPN access to corporate intranets will be
important.
13.2. Multi-homed Private Realms
In the case where a private realm has multiple connections to the
public realm, one RSIP server will be necessary for each gateway.
It is essential for these RSIP servers to exchange state
information so that if the inbound packets get routed to different
RSIP servers, they would possess the correct state information to
tunnel the packets to the appropriate RSIP clients. Similarly, if
one of the RSIP servers fails, the others would be able to take
Borella et. al. Expires April 2000 [Page 13]
INTERNET DRAFT Realm Specific IP: Framework October 1999
over.
However, having multiple RSIP servers within a single private
realm may give rise to the risk of state inconsistency. To
minimize such risk, three architectures are worth considering.
13.2.1. Centralized Global Address Management and Assignment
In this architecture, the global parameter management and
assignment functions are logically separated from the parameter
binding management and tunneling functions. For benefit of
discussion in this section, an RSIP controller refers to an
entity in charge of the global parameter management and
assignment functions while an RSIP gateway refers to an entity
carrying out the parameter binding management and tunneling
functions.
A multi-homed private realm would normally be configured with
an RSIP controller and more than one RSIP gateway. If an RSIP
client needs to connect to a public realm, it will obtain the
global parameters from the RSIP controller. The RSIP controller
may relay addressing information of the RSIP gateway which acts
as the tunnel end-point together with the parameter assignment.
In such a case, the RSIP controller would have to resume
responsibility of tunnel management.
Establishment of parameter binding information on the RSIP
gateway could either be controller initiated, gateway
initiated, or a mixture of both. In the first case, RSIP
controller would relay the new global parameter assignment and
binding information to all RSIP gateways within the private
realm when new assignments are made. Similarly, when
assignments are freed, such information are relayed to all RSIP
gateways. In the second case, new binding information would
only be relayed to the RSIP gateways once they encounter the
tunneled packets from the RSIP clients and send queries to the
RSIP controller. RSIP controllers maintain records on the
existence of mapping information for a particular bind on the
RSIP gateways. If the binding is later freed, all relevant RSIP
gateways are informed. In the third case, the RSIP controller
will relay the new binding information to the RSIP gateway
which the RSIP client has been informed to tunnel outbound
packets to. If the inbound packets for the session arrived at
an RSIP gateway other than the one which a parameter mapping
has been established, the RSIP controller could be queried to
obtain the existing bindings. Regardless of which approach is
being adopted, it is essential for all RSIP gateways to have
knowledge of all the global parameters managed by the RSIP
Borella et. al. Expires April 2000 [Page 14]
INTERNET DRAFT Realm Specific IP: Framework October 1999
controller.
13.2.2. Splitting of Global Parameter Management
Each RSIP server could be configured to manage and assign a
subset of the global parameters for a private realm. An RSIP
client could contact any of the RSIP server and be assigned
global parameters. In the case when an RSIP server returns "no
resources available" type error response, the RSIP client is
free to contact another RSIP server. If a packet is routed to
an RSIP server which does not possess the required mapping, it
could either drop the packet or contact the relevant server for
mapping information. If the latter option were to be adopted,
there is a need for an RSIP server to be aware of the global
parameter ranges that the other servers are responsible for.
Issues of how the RSIP clients could be informed of the list of
RSIP servers, and how RSIP servers learn of the global
parameter ranges that the other servers are responsible for,
are implementation dependent.
13.2.3. Master and Slave RSIP Server
This is the case where the private realm possesses multiple
RSIP servers capable of global parameter assignment. There is a
need to maintain state consistency on all RSIP servers. In the
case when there is a conflict, state mapping on the master
server could be used to resolve the conflict. If the master
server fails, the remaining servers could elect to have a new
master.
14. Cascaded RSIP and NAT
It is possible for RSIP to allow for cascading of RSIP servers as
well as cascading of RSIP servers 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 further subdivide the
port ranges and address(es) amongst individual end hosts
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.
14.1. RSIP Behind RSIP
A reference architecture is depicted below.
Borella et. al. Expires April 2000 [Page 15]
INTERNET DRAFT Realm Specific IP: Framework October 1999
+-----------+
| |
| RSIP |
| server +---- 10.0.0.0/8
| B |
| |
+-----+-----+
|
| 10.0.1.0/24
+-----------+ | (149.112.240.0/25)
| | |
149.112.240.0/24| RSIP +--+
----------------+ server |
| A +--+
| | |
+-----------+ | 10.0.2.0/24
| (149.112.240.128/25)
|
+-----+-----+
| |
| RSIP |
| server +---- 10.0.0.0/8
| C |
| |
+-----------+
RSIP-server A is in charge of the IP addresses of subnet
149.112.240.0/24. It distributes these addresses to RSIP-clients
and RSIP-servers. In the given configuration, it distributes
addresses 149.112.240.0 - 149.112.240.127 to RSIP-server B, and
addresses 149.112.240.128 - 149.112.240.254 to RSIP-server 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-server A. Also, the subnets between
RSIP-server A and RSIP- servers B and C will use private
addresses.
Due to the tree-like fashion in which addresses will be cascaded,
we will refer to RSIP-servers A as the 'parent' of RSIP-servers B
and C, and RSIP-servers B and C as 'children' of RSIP-servers A.
An arbitrary number of levels of children may exist under a parent
RSIP- server.
A parent RSIP-server will not necessarily be aware that the
address(es) and port blocks that it distributes to a child RSIP-
server will be further distributed. Thus, the RSIP-clients MUST
tunnel their outgoing packets to the nearest RSIP-server. This
server will then verify that the sending host has used the proper
Borella et. al. Expires April 2000 [Page 16]
INTERNET DRAFT Realm Specific IP: Framework October 1999
address and port block, and then tunnel the packet on to its
parent RSIP-server.
For example, in the context of the diagram above, host 10.0.0.1,
behind RSIP-server 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-server C. RSIP-server C strips off the outer IP
header. After verifying that the source public IP address and
source port number is valid, RSIP-server C will tunnel the packets
over the 10.0.2.0/8 subnet to RSIP-server A. RSIP-server A strips
off the outer IP header. After verifying that the source public
IP address and source port number is valid, RSIP-server A
transmits the packet on the public network.
While it may be more efficient in terms of computation to have a
RSIP-client tunnel directly to the overall parent of an RSIP-
server tree, this would introduce significant state and
administrative difficulties.
A RSIP-server that is a child MUST take into consideration the
parameter assignment constraints that it inherits from its parent
when it assigns parameters to its children. For example, if a
child RSIP-server is given a lease time of 3600 seconds on an IP
address, it MUST compare the current time to the lease time and
the time that the lease was assigned to compute the maximum
allowable lease time on the address if it is to assign the address
to a RSIP-client or child RSIP-server.
14.2. NAT Behind RSIP
+--------+ +--------+
| NAT w/ | | RSIP |
clients ----+ RSIP +------+ server +----- public network
| client | | |
+--------+ +--------+
In this architecture, an RSIP server is between a NAT box and the
public network. The NAT is also equipped with an RSIP client.
The NAT dynamically requests resources from the RSIP server as the
clients establish sessions to the public network. The clients are
not aware of the RSIP manipulation. This configuration does not
enable the clients to have end-to-end transparency and thus the
NAT still requires ALGs and the architecture cannot support IPSEC.
14.3. RSIP Behind NAT
Borella et. al. Expires April 2000 [Page 17]
INTERNET DRAFT Realm Specific IP: Framework October 1999
+--------+ +--------+
RSIP | RSIP | | |
clients ----+ server +------+ NAT +----- public network
| | | |
+--------+ +--------+
In this architecture, The RSIP clients and server reside behind a
NAT. This configuration does not enable the clients to have end-
to-end transparency and thus the NAT still requires ALGs and the
architecture cannot support IPSEC. The clients may have
transparency if there is another gateway to the public network
besides the NAT box, and this gateway supports cascaded RSIP
behind RSIP.
14.4. RSIP Through NAT
+--------+ +--------+
RSIP | | | RSIP |
clients ----+ NAT +------+ server +----- public network
| | | |
+--------+ +--------+
In this architecture, the RSIP clients are separated from the RSIP
server 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.
15. Integration with Mobile IP
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 servers, 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.
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
Borella et. al. Expires April 2000 [Page 18]
INTERNET DRAFT Realm Specific IP: Framework October 1999
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.
15.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.
15.2. Data Flow
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.
Borella et. al. Expires April 2000 [Page 19]
INTERNET DRAFT Realm Specific IP: Framework October 1999
15.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].
15.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:
ne 4
+-------------+---------+
| 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.
+--------------+-------------+---------+
| RMNb -> RFAb | RMNp -> PNp | payload |
+--------------+-------------+---------+
15.3. Control Flow
Borella et. al. Expires April 2000 [Page 20]
INTERNET DRAFT Realm Specific IP: Framework October 1999
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:
+--------------+--------------+---------+
| RFAp -> RHAp | RMNa -> RHAa | payload |
+--------------+--------------+---------+
From RHA to RFA:
+--------------+--------------+---------+
| RHAp -> RFAp | RHAa -> RMNa | payload |
+--------------+--------------+---------+
Borella et. al. Expires April 2000 [Page 21]
INTERNET DRAFT Realm Specific IP: Framework October 1999
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 server 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.
16. To Do
- Interaction with multicast
- Interaction with QoS
- Session authentication
- Mobile IP section is very preliminary. Needs work on terminology
and requirements.
17. Changelog
01 to 02:
- Added section on Mobile IP integration
- Added to section on cascaded RSIP
- Added section on client and server requirements
- Added RSIP for multi-homed network
- Added deployment scenarios
- Added section on RSAP-IP support for servers
- 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 client and server
- Editorial changes
00 to 01:
- Synched up terminology with the latest NAT terminology draft.
- Changed all instances of "global" to "public"
Borella et. al. Expires April 2000 [Page 22]
INTERNET DRAFT Realm Specific IP: Framework October 1999
- Modified section on "Architecture"
- Added discussion of demultiplexing parameters tree to the
"Negotiation and assignment of demultiplexing fields" section
- Added discussion of subnet list query in "Determining Locality of
Destination" section
- Added "RSIP Client Deallocation" discussion section
- Added more explanation in "Tunnel Use and Establishment" section
18. 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.
All Mobile IP and RSIP control messages SHOULD be authenticated to
prevent denial of service, spoofing and hijacking attacks.
19. Acknowledgements
The authors would like to thank Pyda Srisuresh, Dan Nessett, Gary
Jaszewski, Aja Bakre, and Rick Cobb for their input.
20. References
[RSIP-IPSEC] G. Montenegro and M. Borella, "RSIP Support for End-to-
end IPSEC," <draft-ietf-nat-rsip-ipsec-00.txt>, work in progress,
May 1999.
[RSIP-PROTO] M. Borella, D. Grabelsky, J. Lo and K. Taniguchi,
"Realm Specific IP: Protocol Specification," <draft-ietf-nat-rsip-
protocol-02.txt>, work in progress, Aug. 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.
21. Authors' Addresses
Borella et. al. Expires April 2000 [Page 23]
INTERNET DRAFT Realm Specific IP: Framework October 1999
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
22. 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.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
Borella et. al. Expires April 2000 [Page 24]
INTERNET DRAFT Realm Specific IP: Framework October 1999
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 April 2000 [Page 25]
