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]
RFC 3102 RSIP: Framework October 2001
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
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]