routing table.
5.4.1. Receiving-Only Private Hosts, No Multicast Routing on
Private Network
In this scenario, private hosts will not source multicast traffic,
but they may join multicast groups as recipients. In the private
network, there are no multicast-aware routers, except for the RSIP
gateway.
Private hosts may join and leave multicast groups by sending the
appropriate IGMP messages to an RSIP gateway (there may be IGMP proxy
routers between RSIP hosts and gateways). The RSIP gateway will
coalesce these requests and perform the appropriate actions, whether
they be to perform a multicast WAN routing protocol, such as PIM, or
to proxy the IGMP messages to a WAN multicast router. In other
words, if one or more private hosts request to join a multicast
group, the RSIP gateway MUST join in their stead, using one of its
own public IP addresses.
Note that private hosts do not need to acquire demultiplexing fields
and use RSIP to receive multicasts. They may receive all multicasts
using their private addresses, and by private address is how the RSIP
gateway will keep track of their group membership.
5.4.2. Sending and Receiving Private Hosts, No Multicast Routing
on Private Network
This scenarios operates identically to the previous scenario, except
that when a private host becomes a multicast source, it MUST use RSIP
and acquire a public IP address (note that it will still receive on
its private address). A private host sending a multicast will use a
public source address and tunnel the packets to the RSIP gateway.
The RSIP gateway will then perform typical RSIP functionality, and
route the resulting packets onto the public network, as well as back
to the private network, if there are any listeners on the private
network.
If there is more than one sender on the private network, then, to the
public network it will seem as if all of these senders share the same
IP address. If a downstream multicasting protocol identifies sources
based on IP address alone and not port numbers, then it is possible
that these protocols will not be able to distinguish between the
senders.
6. RSIP Complications
In this section we document the know complications that RSIP may
cause. While none of these complications should be considered "show
stoppers" for the majority of applications, they may cause unexpected
or undefined behavior. Where it is appropriate, we discuss potential
remedial procedures that may reduce or eliminate the deleterious
impact of a complication.
6.1. Unnecessary TCP TIME_WAIT
When TCP disconnects a socket, it enters the TCP TIME_WAIT state for
a period of time. While it is in this state it will refuse to accept
new connections using the same socket (i.e., the same source
address/port and destination address/port). Consider the case in
which an RSIP host (using RSAP-IP) is leased an address/port tuple
and uses this tuple to contact a public address/port tuple. Suppose
that the host terminates the session with the public tuple and
immediately returns its leased tuple to the RSIP gateway. If the
RSIP gateway immediately allocates this tuple to another RSIP host
(or to the same host), and this second host uses the tuple to contact
the same public tuple while the socket is still in the TIME_WAIT
phase, then the host's connection may be rejected by the public host.
In order to mitigate this problem, it is recommended that RSIP
gateways hold recently deallocated tuples for at least two minutes,
which is the greatest duration of TIME_WAIT that is commonly
implemented. In situations where port space is scarce, the RSIP
gateway MAY choose to allocate ports in a FIFO fashion from the pool
of recently deallocated ports.
6.2. ICMP State in RSIP Gateway
Like NAT, RSIP gateways providing RSAP-IP must process ICMP responses
from the public network in order to determine the RSIP host (if any)
that is the proper recipient. We distinguish between ICMP error
packets, which are transmitted in response to an error with an
associated IP packet, and ICMP response packets, which are
transmitted in response to an ICMP request packet.
ICMP request packets originating on the private network will
typically consist of echo request, timestamp request and address mask
request. These packets and their responses can be identified by the
tuple of source IP address, ICMP identifier, ICMP sequence number,
and destination IP address. An RSIP host sending an ICMP request
packet tunnels it to the RSIP gateway, just as it does TCP and UDP
packets. The RSIP gateway must use this tuple to map incoming ICMP
responses to the private address of the appropriate RSIP host. Once
it has done so, it will tunnel the ICMP response to the host. Note
that it is possible for two RSIP hosts to use the same values for the
tuples listed above, and thus create an ambiguity. However, this
occurrence is likely to be quite rare, and is not addressed further
in this document.
Incoming ICMP error response messages can be forwarded to the
appropriate RSIP host by examining the IP header and port numbers
embedded within the ICMP packet. If these fields are not present,
the packet should be silently discarded.
Occasionally, an RSIP host will have to send an ICMP response (e.g.,
port unreachable). These responses are tunneled to the RSIP gateway,
as is done for TCP and UDP packets. All ICMP requests (e.g., echo
request) arriving at the RSIP gateway MUST be processed by the RSIP
gateway and MUST NOT be forwarded to an RSIP host.
6.3. Fragmentation and IP Identification Field Collision
If two or more RSIP hosts on the same private network transmit
outbound packets that get fragmented to the same public gateway, the
public gateway may experience a reassembly ambiguity if the IP header
ID fields of these packets are identical.
For TCP packets, a reasonably small MTU can be set so that
fragmentation is guaranteed not to happen, or the likelihood or
fragmentation is extremely small. If path MTU discovery works
properly, the problem is mitigated. For UDP, applications control
the size of packets, and the RSIP host stack may have to fragment UDP
packets that exceed the local MTU. These packets may be fragmented
by an intermediate router as well.
The only completely robust solution to this problem is to assign all
RSIP hosts that are sharing the same public IP address disjoint
blocks of numbers to use in their IP identification fields. However,
whether this modification is worth the effort of implementing is
currently unknown.
6.4. Application Servers on RSAP-IP Hosts
RSAP-IP hosts 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 host, typically no two RSAP-IP hosts sharing the same public
IP address can simultaneously operate publically-available gateways
on the same port. For protocols that operate on well-known ports,
this implies that only one public gateway per RSAP-IP IP address /
port tuple is used simultaneously. However, more than one gateway
per RSAP-IP IP address / port tuple may be used simultaneously if and
only if there is a demultiplexing field within the payload of all
packets that will uniquely determine the identity of the RSAP-IP
host, and this field is known by the RSIP gateway.
In order for an RSAP-IP host to operate a publically-available
gateway, the host must inform the RSIP gateway that it wishes to
receive all traffic destined to that port number, per its IP address.
Such a request MUST be denied if the port in question is already in
use by another host.
In general, contacting devices behind an RSIP gateway may be
difficult. A potential solution to the general problem would be an
architecture that allows an application on an RSIP host to register a
public IP address / port pair in a public database. Simultaneously,
the RSIP gateway would initiate a mapping from this address / port
tuple to the RSIP host. A peer application would then be required to
contact the database to determine the proper address / port at which
to contact the RSIP host's application.
6.5. Determining Locality of Destinations from an RSIP Host
In general, an RSIP host must know, for a particular IP address,
whether it should address the packet for local delivery on the
private network, or if it has to use an RSIP interface to tunnel to
an RSIP gateway (assuming that it has such an interface available).
If the RSIP hosts are all on a single subnet, one hop from an RSIP
gateway, then examination of the local network and subnet mask will
provide the appropriate information. However, this is not always the
case.
An alternative that will work in general for statically addressed
private networks is to store a list of the network and subnet masks
of every private subnet at the RSIP gateway. RSIP hosts may query
the gateway with a particular target IP address, or for the entire
list.
If the subnets on the local side of the network are changing more
rapidly than the lifetime of a typical RSIP session, the RSIP host
may have to query the location of every destination that it tries to
communicate with.
If an RSIP host transmits a packet addressed to a public host without
using RSIP, then the RSIP gateway will apply NAT to the packet (if it
supports NAT) or it may discard the packet and respond with and
appropriate ICMP message.
A robust solution to this problem has proven difficult to develop.
Currently, it is not known how severe this problem is. It is likely
that it will be more severe on networks where the routing information
is changing rapidly that on networks with relatively static routes.
6.6. Implementing RSIP Host Deallocation
An RSIP host MAY free resources that it has determined it no longer
requires. For example, on an RSAP-IP subnet with a limited number of
public IP addresses, port numbers may become scarce. Thus, if RSIP
hosts are able to dynamically deallocate ports that they no longer
need, more hosts can be supported.
However, this functionality may require significant modifications to
a vanilla TCP/IP stack in order to implement properly. The RSIP host
must be able to determine which TCP or UDP sessions are using RSIP
resources. If those resources are unused for a period of time, then
the RSIP host may deallocate them. When an open socket's resources
are deallocated, it will cause some associated applications to fail.
An analogous case would be TCP and UDP sessions that must terminate
when an interface that they are using loses connectivity.
On the other hand, this issue can be considered a resource allocation
problem. It is not recommended that a large number (hundreds) of
hosts share the same IP address, for performance purposes. Even if,
say, 100 hosts each are allocated 100 ports, the total number of
ports in use by RSIP would be still less than one-sixth the total
port space for an IP address. If more hosts or more ports are
needed, more IP addresses should be used. Thus, it is reasonable,
that in many cases, RSIP hosts will not have to deallocate ports for
the lifetime of their activity.
Since RSIP demultiplexing fields are leased to hosts, an
appropriately chosen lease time can alleviate some port space
scarcity issues.
6.7. Multi-Party Applications
Multi-party applications are defined to have at least one of the
following characteristics:
- A third party sets up sessions or connections between two
hosts.
- Computation is distributed over a number of hosts such that the
individual hosts may communicate with each other directly.
RSIP has a fundamental problem with multi-party applications. If
some of the parties are within the private addressing realm and
others are within the public addressing realm, an RSIP host may not
know when to use private addresses versus public addresses. In
particular, IP addresses may be passed from party to party under the
assumption that they are global endpoint identifiers. This may cause
multi-party applications to fail.
There is currently no known solution to this general problem.
Remedial measures are available, such as forcing all RSIP hosts to
always use public IP addresses, even when communicating only on to
other RSIP hosts. However, this can result in a socket set up
between two RSIP hosts having the same source and destination IP
addresses, which most TCP/IP stacks will consider as intra-host
communication.
6.8. Scalability
The scalability of RSIP is currently not well understood. While it
is conceivable that a single RSIP gateway could support hundreds of
RSIP hosts, scalability depends on the specific deployment scenario
and applications used. In particular, three major constraints on
scalability will be (1) RSIP gateway processing requirements, (2)
RSIP gateway memory requirements, and (3) RSIP negotiation protocol
traffic requirements. It is advisable that all RSIP negotiation
protocol implementations attempt to minimize these requirements.
7. Security Considerations
RSIP, in and of itself, does not provide security. It may provide
the illusion of security or privacy by hiding a private address
space, but security can only be ensured by the proper use of security
protocols and cryptographic techniques.
8. Acknowledgements
The authors would like to thank Pyda Srisuresh, Dan Nessett, Gary
Jaszewski, Ajay Bakre, Cyndi Jung, and Rick Cobb for their input.
The IETF NAT working group as a whole has been extremely helpful in
the ongoing development of RSIP.
9. References
[DHCP-DNS] Stapp, M. and Y. Rekhter, "Interaction Between DHCP and
DNS", Work in Progress.
[RFC2983] Black, D., "Differentiated Services and Tunnels", RFC
2983, October 2000.
[RFC3104] Montenegro, G. and M. Borella, "RSIP Support for End-to-
End IPSEC", RFC3104, October 2001.
[RFC3103] Borella, M., Grabelsky, D., Lo, J. and K. Taniguchi,
"Realm Specific IP: Protocol Specification", RFC3103,
October 2001.
[RFC2746] Terzis, A., Krawczyk, J., Wroclawski, J. and L. Zhang,
"RSVP Operation Over IP Tunnels", RFC2746, January 2000.
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.J.
and E. Lear, "Address Allocation for Private Internets",
BCP 5, RFC1918, February 1996.
[RFC2002] Perkins, C., "IP Mobility Support", RFC2002, October
1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to indicate
requirement levels", BCP 14, RFC2119, March 1997.
[RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address
Translator (NAT) Terminology and Considerations", RFC
2663, August 1999.
[RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, S. and S.
Jamin, "Resource Reservation Protocol (RSVP)", RFC2205,
September 1997.
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.
and W. Weiss, "An Architecture for Differentiated
Services", RFC2475, December 1998.
[RFC3105] Kempf, J. and G. Montenegro, "Finding an RSIP Server with
SLP", RFC3105, October 2001.
10. Authors' Addresses
Michael Borella
CommWorks
3800 Golf Rd.
Rolling Meadows IL 60008
Phone: (847) 262-3083
EMail: mike_borella@commworks.com
Jeffrey Lo
Candlestick Networks, Inc
70 Las Colinas Lane,
San Jose, CA 95119
Phone: (408) 284 4132
EMail: yidarlo@yahoo.com
David Grabelsky
CommWorks
3800 Golf Rd.
Rolling Meadows IL 60008
Phone: (847) 222-2483
EMail: david_grabelsky@commworks.com
Gabriel E. Montenegro
Sun Microsystems
Laboratories, Europe
29, chemin du Vieux Chene
38240 Meylan
FRANCE
Phone: +33 476 18 80 45
EMail: gab@sun.com
11. Full Copyright Statement
Copyright (C) The Internet Society (2001). 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.
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.
Acknowledgement
Funding for the RFCEditor function is currently provided by the
Internet Society.