As per Relevance of the word framework, we have this rfc below:
Network Working Group Editors
Request for Comments: 3102 M.
Category: Experimental
J.
Candlestick
Contributors
D.
G.
Sun
October 2001
Realm Specific IP:
Status of this
This memo defines an Experimental Protocol for the
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
Copyright (C) The Internet Society (2001). All Rights Reserved
IESG
The IESG notes that the set of documents describing the
technology imply significant host and gateway changes for a
implementation. In addition, the floating of port numbers can
problems for some applications, preventing an RSIP-enabled host
interoperating transparently with existing applications in some
(e.g., IPsec). Finally, there may be significant
complexities associated with using RSIP. Some of these and
complications are outlined in section 6 of RFC 3102, as well as
the Appendices of RFC 3104. Accordingly, the costs and benefits
using RSIP should be carefully weighed against other means
relieving address shortage
This document examines the general framework of Realm Specific
(RSIP). RSIP is intended as a alternative to NAT in which the end
to-end integrity of packets is maintained. We focus
implementation issues, deployment scenarios, and interaction
other layer-three protocols
Borella, et al. Experimental [Page 1]
RFC 3102 RSIP: Framework October 2001
Table of
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.
Network Address Translation (NAT) has become a popular mechanism
enabling the separation of addressing spaces. A NAT router
examine and change the network layer, and possibly the
layer, header of each packet crossing the addressing domains that
NAT router is connecting. This causes the mechanism of NAT
violate the end-to-end nature of the Internet connectivity,
disrupts protocols requiring or enforcing end-to-end integrity
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,
requires the presence of an application layer gateway (ALG)
the NAT router for each application that embeds
information within the packet payload. For example, most NATs
with an ALG for FTP, which transmits IP addresses and port numbers
its control channel. RSIP (Realm Specific IP) provides
alternative to remedy these limitations
RSIP is based on the concept of granting a host from one
realm a presence in another addressing realm by allowing it to
resources (e.g., addresses and other routing parameters) from
second addressing realm. An RSIP gateway replaces the NAT router
and RSIP-aware hosts on the private network are referred to as
hosts. RSIP requires ability of the RSIP gateway to grant
resources to RSIP hosts. ALGs are not required on the RSIP
for communications between an RSIP host and a host in a
addressing realm
RSIP can be viewed as a "fix", of sorts, to NAT. It may
some IP address shortage problems in some scenarios without some
the limitations of NAT. However, it is not a long-term solution
the IP address shortage problem. RSIP allows a degree of
realm transparency to be achieve between two differently-scoped,
completely different addressing realms. This makes it a
architecture for enabling end-to-end packet transparency
addressing realms. RSIP is expected to be deployed on
addresses IPv4 networks and used to grant access to
addressed IPv4 networks. However, in place of the private IPv
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
applications but no native IP access. As such, RSIP can be used,
conjunction with DNS and tunneling, to bridge IPv4 and IPv6 networks
such that dual-stack hosts can communicate with local or remote IPv
or IPv6 hosts
It is important to note that, as it is defined here, RSIP does
require modification of applications. All RSIP-related
to an RSIP host can occur at layers 3 and 4. However, while
does allow end-to-end packet transparency, it may not be
to all applications. More details can be found in the section "
complications", below
Borella, et al. Experimental [Page 3]
RFC 3102 RSIP: Framework October 2001
1.1. Document
This document provides a framework for RSIP by focusing on
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.
modifications that would need to be made to RSIP and/or
interacting protocol are left for separate documents to discuss
detail
Beyond the scope of this document is discussion of RSIP in large
multiple-gateway networks, or in environments where RSIP state
need to be distributed and maintained across multiple
entities
Discussion of RSIP solutions that do not use some form of
between the RSIP host and RSIP gateway are also not considered
this document
This document focuses on scenarios that allow privately-
IPv4 hosts or IPv6 hosts access to publically-addressed IPv
networks
1.2.
Private
A routing realm that uses private IP addresses from the
(10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) specified
[RFC1918], or addresses that are non-routable from the Internet
Public
A routing realm with globally unique network addresses
RSIP
A host within an addressing realm that uses RSIP to
addressing parameters from another addressing realm via an
gateway
Borella, et al. Experimental [Page 4]
RFC 3102 RSIP: Framework October 2001
RSIP
A router or gateway situated on the boundary between
addressing realms that is assigned one or more IP addresses in
least one of the realms. An RSIP gateway is responsible
parameter management and assignment from one realm to RSIP
in the other realm. An RSIP gateway may act as a normal
router for hosts within the a realm that are not RSIP enabled
RSIP
An application program that performs the client portion of
RSIP client/server protocol. An RSIP client application
exist on all RSIP hosts, and MAY exist on RSIP gateways
RSIP
An application program that performs the server portion of
RSIP client/server protocol. An RSIP server application
exist on all RSIP gateways
RSA-IP: Realm Specific Address
An RSIP method in which each RSIP host is allocated a unique
address from the public realm
RSAP-IP: Realm Specific Address and Port
An RSIP method in which each RSIP host is allocated an IP
(possibly shared with other RSIP hosts) and some number of per
address unique ports from the public realm
Demultiplexing
Any set of packet header or payload fields that an RSIP
uses to route an incoming packet to an RSIP host
All other terminology found in this document is consistent with
of [RFC2663].
1.3. Specification of
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
documents are to be interpreted as described in [RFC2119].
Borella, et al. Experimental [Page 5]
RFC 3102 RSIP: Framework October 2001
2.
In a typical scenario where RSIP is deployed, there are some
of hosts within one addressing realm connected to another
realm by an RSIP gateway. This model is diagrammatically
as follows
RSIP Host RSIP Gateway
Xa Na Nb
[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
functions). N has two interfaces: Na on address space A, and Nb
address space B. N may have a pool of addresses in address space
which it can assign to or lend to X and other hosts in address
A. These addresses are not shown above, but they can be denoted
Nb1, Nb2, Nb3 and so on
As is often the case, the hosts within address space A are likely
use private addresses while the RSIP gateway is multi-homed with
or more private addresses from address space A in addition to
public addresses from address space B. Thus, we typically refer
the realm in which the RSIP host resides as "private" and the
from which the RSIP host borrows addressing parameters as
"public" realm. However, these realms may both be public or
- our notation is for convenience. In fact, address space A may
an IPv6 realm or a non-IP address space
Host X, wishing to establish an end-to-end connection to a
entity Y situated within address space B, first negotiates
obtains assignment of the resources (e.g., addresses and
routing parameters of address space B) from the RSIP gateway.
assignment of these parameters, the RSIP gateway creates a mapping
referred as a "bind", of X's addressing information and the
resources. This binding enables the RSIP gateway to correctly de
multiplex and forward inbound traffic generated by Y for X.
permitted by the RSIP gateway, X may create multiple such bindings
the same RSIP gateway, or across several RSIP gateways. A lease
SHOULD be associated with each bind
Using the public parameters assigned by the RSIP gateway, RSIP
tunnel data packets across address space A to the RSIP gateway.
RSIP gateway acts as the end point of such tunnels, stripping off
outer headers and routing the inner packets onto the public realm
As mentioned above, an RSIP gateway maintains a mapping of
Borella, et al. Experimental [Page 6]
RFC 3102 RSIP: Framework October 2001
assigned public parameters as demultiplexing fields for
mapping them to RSIP host private addresses. When a packet from
public realm arrives at the RSIP gateway and it matches a given
of demultiplexing fields, then the RSIP gateway will tunnel it to
appropriate RSIP host. The tunnel headers of outbound packets from
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
and gateways MAY support RSA-IP, RSAP-IP, or both
When using RSA-IP, an RSIP gateway maintains a pool of IP
to be leased by RSIP hosts. Upon host request, the RSIP
allocates an IP address to the host. Once an address is allocated
a particular host, only that host may use the address until
address is returned to the pool. Hosts MAY NOT use addresses
have not been specifically assigned to them. The hosts may use
TCP/UDP port in combination with their assigned address. Hosts
also run gateway applications at any port and these applications
be available to the public network without assistance from the
gateway. A host MAY lease more than one address from the same
different RSIP gateways. The demultiplexing fields of an RSA-
session MUST include the IP address leased to the host
When using RSAP-IP, an RSIP gateway maintains a pool of IP
as well as pools of port numbers per address. RSIP hosts lease an
address and one or more ports to use with it. Once an address /
tuple has been allocated to a particular host, only that host may
the tuple until it is returned to the pool(s). Hosts MAY NOT
address / port combinations that have not been specifically
to them. Hosts may run gateway applications bound to an
tuple, but their applications will not be available to the
network unless the RSIP gateway has agreed to route all
destined to the tuple to the host. A host MAY lease more than
tuple from the same or different RSIP gateways. The
fields of an RSAP-IP session MUST include the tuple(s) leased to
host
3.
3.1. Host and Gateway
An RSIP host MUST be able to maintain one or more virtual
for the IP address(es) that it leases from an RSIP gateway. The
MUST also support tunneling and be able to serve as an end-point
Borella, et al. Experimental [Page 7]
RFC 3102 RSIP: Framework October 2001
one or more tunnels to RSIP gateways. An RSIP host MUST NOT
to ARPs for a public realm address that it leases
An RSIP host supporting RSAP-IP MUST be able to maintain a set of
or more ports assigned by an RSIP gateway from which choose
source ports. If the host's pool does not have any free ports
the host needs to open a new communication session with a
host, it MUST be able to dynamically request one or more
ports via its RSIP mechanism
An RSIP gateway is a multi-homed host that routes packets between
or more realms. Often, an RSIP gateway is a boundary router
two or more administrative domains. It MUST also support
and be able to serve as an end-point for tunnels to RSIP hosts.
RSIP gateway MAY be a policy enforcement point, which in turn
require it to perform firewall and packet filtering duties
addition to RSIP. The RSIP gateway MUST reassemble all
packet fragments from the public network in order to be able to
and tunnel them to the proper host. As is necessary for
reassembly, an RSIP gateway MUST timeout fragments that are
fully reassembled
An RSIP gateway MAY include NAT functionality so that hosts on
private network that are not RSIP-enabled can still communicate
the public network. An RSIP gateway MUST manage all resources
are assigned to RSIP hosts. This management MAY be done according
local policy
3.2. Processing of Demultiplexing
Each active RSIP host must have a unique set of demultiplexing
assigned to it so that an RSIP gateway can route incoming
appropriately. Depending on the type of mapping used by the
gateway, demultiplexing fields have been defined to be one or more
the following
- destination IP
- IP
- destination TCP or UDP
- IPSEC SPI present in ESP or AH header (see [RFC3104])
-
Note that these fields may be augmented by source IP address
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
incoming packet, and proceeds to subsequent headers and then
payload
- In the case where a public IP address is assigned for
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
be assigned a unique value per host so that it is usable as
demultiplexing field. The IP protocol field SHOULD be used
determine what in the subsequent headers these
fields ought to be
- If the subsequent header is TCP or UDP, then destination
number can be used. However, if the TCP/UDP port number is
same for more than one RSIP host, the payload section of
packet must contain a demultiplexing field that is
to be different for each RSIP host. Typically this
negotiation of said fields between the RSIP host and gateway
that the RSIP gateway can guarantee that the fields are
per-
- If the subsequent header is anything other than TCP or UDP
there must exist other fields within the IP payload usable
demultiplexing fields. In other words, these fields must
able to be set such that they are guaranteed to be unique per
host. Typically this requires negotiation of said
between the RSIP host and gateway so that the RSIP gateway
guarantee that the fields are unique per-host
It is desirable for all demultiplexing fields to occur in well-
fixed locations so that an RSIP gateway can mask out and examine
appropriate fields on incoming packets. Demultiplexing fields
are encrypted MUST NOT be used for routing
3.3. RSIP Protocol Requirements and
RSIP gateways and hosts MUST be able to negotiate IP addresses
using RSA-IP, IP address / port tuples when using RSAP-IP,
possibly other demultiplexing fields for use in other modes
In this section we discuss the requirements and implementation
of an RSIP negotiation protocol
For each required demultiplexing field, an RSIP protocol MUST, at
very least, allow for
Borella, et al. Experimental [Page 9]
RFC 3102 RSIP: Framework October 2001
- RSIP hosts to request assignments of demultiplexing
- RSIP gateways to assign demultiplexing fields with
associated lease
- RSIP gateways to reclaim assigned demultiplexing
Additionally, it is desirable, though not mandatory, for an
protocol to negotiate an RSIP method (RSA-IP or RSAP-IP) and the
of tunnel to be used across the private network. The protocol
be extensible and facilitate vendor-specific extensions
If an RSIP negotiation protocol is implemented at the
layer, a choice of transport protocol MUST be made. RSIP hosts
gateways may communicate via TCP or UDP. TCP support is required
all RSIP gateways, while UDP support is optional. In RSIP hosts
TCP, UDP, or both may be supported. However, once an RSIP host
gateway have begun communicating using either TCP or UDP, they
NOT switch to the other transport protocol. For RSIP
and deployments considered in this document, TCP is the
transport protocol, because TCP is known to be robust across a
range of physical media types and traffic loads
It is recommended that all communication between an RSIP host
gateway be authenticated. Authentication, in the form of a
hash appended to the end of each RSIP protocol packet, can serve
authenticate the RSIP host and gateway to one another,
message integrity, and (with an anti-replay counter) avoid
attacks. In order for authentication to be supported, each RSIP
and the RSIP gateway MUST either share a secret key (distributed,
example, by Kerberos) or have a private/public key pair. In
latter case, an entity's public key can be computed over each
and a hash function applied to the result to form the message hash
3.4. Interaction with
An RSIP-enabled network has three uses for DNS: (1) public
services to map its static public IP addresses (i.e., the
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
the private network. With respect to (2), private DNS
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
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
dynamic DNS [DHCP-DNS]. In particular, RSIP hosts should be
to update their A records but not PTR records, while RSIP
can update both. In order for the RSIP gateway to update DNS
on behalf on an RSIP host, the host must provide the gateway with
FQDN
Note that when using RSA-IP, the interaction with DNS is
analogous to that of DHCP because the RSIP host "owns" an IP
for a period of time. In the case of RSAP-IP, the claim that an
host has to an address is only with respect to the port(s) that
has leased along with an address. Thus, two or more RSIP hosts
FQDNs may map to the same IP address. However, a public host
expect that all of the applications running at a particular
are owned by the same logical host, which would not be the case.
is recommended that RSAP-IP and dynamic DNS be integrated with
caution, if at all
3.5. Locating RSIP
When an RSIP host initializes, it requires (among other things)
critical pieces of information. One is a local (private) IP
to use as its own, and the other is the private IP address of an
gateway. This information can be statically configured
dynamically assigned
In the dynamic case, the host's private address is typically
by DHCP. A DHCP option could provide the IP address of an
gateway in DHCPOFFER messages. Thus, the host's startup
would be as follows: (1) perform DHCP, (2) if an RSIP gateway
is present in the DHCPOFFER, record the IP address therein as
RSIP gateway
Alternatively, the RSIP gateway can be discovered via SLP (
Location Protocol) as specified in [SLP-RSIP]. The SLP
defined allows for RSIP service provisioning and load balancing
3.6. Implementation
RSIP can be accomplished by any one of a wide range of
schemes. For example, it can be built into an existing
protocol such as DHCP or SOCKS, or it can exist as a
protocol. This section discusses implementation issues of RSIP
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
implementation. Modifications to IP tunneling and routing code,
well as driver interfaces may need to be made to support RSA-IP
Support for RSAP-IP requires modifications to ephemeral
selection code as well. If a host has multiple TCP/IP stacks
TCP/IP stacks and other communication stacks, RSIP will only
on the packets / sessions that are associated with the TCP/
stack(s) that use RSIP. RSIP is not application specific, and if
is implemented in a stack, it will operate beneath all
that use the stack
4.
When RSIP is deployed in certain scenarios, the
characteristics of these scenarios will determine the scope of
RSIP solution, and therefore impact the requirements of RSIP.
this section, we examine deployment scenarios, and the impact
RSIP may have on existing networks
4.1. Possible Deployment
In this section we discuss a number of potential RSIP
scenarios. The selection below are not comprehensive and
scenarios may emerge
4.1.1. Small / Medium
Up to several hundred hosts will reside behind an RSIP-
router. It is likely that there will be only one gateway to
public network and therefore only one RSIP gateway. This
gateway may control only one, or perhaps several, public
addresses. The RSIP gateway may also perform firewall functions,
well as routing inbound traffic to particular destination ports on
a small number of dedicated gateways on the private network
4.1.2. Residential
This category includes both networking within just one residence,
well as within multiple-dwelling units. At most several
hosts will share the gateway's resources. In particular, many
these devices may be thin hosts or so-called "network appliances"
therefore not require access to the public Internet frequently.
RSIP gateway is likely to be implemented as part of a
firewall, and it may be called upon to route traffic to
destination ports on to a small number of dedicated gateways on
private network. It is likely that only one gateway to the
Borella, et al. Experimental [Page 12]
RFC 3102 RSIP: Framework October 2001
network will be present and that this gateway's RSIP gateway
control only one IP address. Support for secure end-to-end
access to corporate intranets will be important
4.1.3. Hospitality
A hospitality network is a general type of "hosting" network that
traveler will use for a short period of time (a few minutes or a
hours). Examples scenarios include hotels, conference centers
airports and train stations. At most several hundred hosts
share the gateway's resources. The RSIP gateway may be
as part of a firewall, and it will probably not be used to
traffic to particular destination ports on to dedicated gateways
the private network. It is likely that only one gateway to
public network will be present and that this gateway's RSIP
will control only one IP address. Support for secure end-to-end
access to corporate intranets will be important
4.1.4. Dialup Remote
RSIP gateways may be placed in dialup remote access concentrators
order to multiplex IP addresses across dialup users. At most
hundred hosts will share the gateway's resources. The RSIP
may or may not be implemented as part of a firewall, and it
probably not be used to route traffic to particular destination
on to dedicated gateways on the private network. Only one gateway
the public network will be present (the remote access
itself) and that this gateway's RSIP gateway will control a
number of IP addresses. Support for secure end-to-end VPN access
corporate intranets will be important
4.1.5. Wireless Remote Access
Wireless remote access will become very prevalent as more PDA and
/ cellular devices are deployed. In these scenarios, hosts may
changing physical location very rapidly - therefore Mobile IP
play a role. Hosts typically will register with an RSIP gateway
a short period of time. At most several hundred hosts will share
gateway's resources. The RSIP gateway may be implemented as part
a firewall, and it will probably not be used to route traffic
particular destination ports on to dedicated gateways on the
network. It is likely that only one gateway to the public
will be present and that this gateway's RSIP gateway will control
small number of IP addresses. Support for secure end-to-end
access to corporate intranets will be important
Borella, et al. Experimental [Page 13]
RFC 3102 RSIP: Framework October 2001
4.2. Cascaded RSIP and
It is possible for RSIP to allow for cascading of RSIP gateways
well as cascading of RSIP gateways with NAT boxes. For example
consider an ISP that uses RSIP for address sharing amongst
customers. It might assign resources (e.g., IP addresses and ports
to a particular customer. This customer may use RSIP to
subdivide the port ranges and address(es) amongst individual
hosts. No matter how many levels of RSIP assignment exists,
MUST only assign public IP addresses
Note that some of the architectures discussed below may not be
or desirable. The goal of this section is to explore
interactions between NAT and RSIP as RSIP is incrementally
on systems that already support NAT
4.2.1. RSIP Behind
A reference architecture is depicted below
+-----------+
| |
| RSIP |
| gateway +---- 10.0.0.0/8
| B |
| |
+-----+-----+
|
| 10.0.1.0/24
+-----------+ | (149.112.240.0/25)
| | |
149.112.240.0/24| RSIP +--+
----------------+ gateway |
| A +--+
| | |
+-----------+ | 10.0.2.0/24
| (149.112.240.128/25)
|
+-----+-----+
| |
| RSIP |
| gateway +---- 10.0.0.0/8
| C |
| |
+-----------+
Borella, et al. Experimental [Page 14]
RFC 3102 RSIP: Framework October 2001
RSIP gateway A is in charge of the IP addresses of
149.112.240.0/24. It distributes these addresses to RSIP hosts
RSIP gateways. In the given configuration, it distributes
149.112.240.0 - 149.112.240.127 to RSIP gateway B, and
149.112.240.128 - 149.112.240.254 to RSIP gateway C. Note that
subnet broadcast address, 149.112.240.255, must remain unclaimed,
that broadcast packets can be distributed to arbitrary hosts
RSIP gateway A. Also, the subnets between RSIP gateway A and
gateways B and C will use private addresses
Due to the tree-like fashion in which addresses will be cascaded,
will refer to RSIP gateways A as the 'parent' of RSIP gateways B
C, and RSIP gateways B and C as 'children' of RSIP gateways A.
arbitrary number of levels of children may exist under a parent
gateway
A parent RSIP gateway will not necessarily be aware that
address(es) and port blocks that it distributes to a child
gateway will be further distributed. Thus, the RSIP hosts
tunnel their outgoing packets to the nearest RSIP gateway.
gateway will then verify that the sending host has used the
address and port block, and then tunnel the packet on to its
RSIP gateway
For example, in the context of the diagram above, host 10.0.0.1,
behind RSIP gateway C will use its assigned external IP address (say
149.112.240.130) and tunnel its packets over the 10.0.0.0/8 subnet
RSIP gateway C. RSIP gateway C strips off the outer IP header
After verifying that the source public IP address and source
number is valid, RSIP gateway C will tunnel the packets over
10.0.2.0/8 subnet to RSIP gateway A. RSIP gateway A strips off
outer IP header. After verifying that the source public IP
and source port number is valid, RSIP gateway A transmits the
on the public network
While it may be more efficient in terms of computation to have a
host tunnel directly to the overall parent of an RSIP gateway tree
this would introduce significant state and
difficulties
A RSIP gateway that is a child MUST take into consideration
parameter assignment constraints that it inherits from its
when it assigns parameters to its children. For example, if a
RSIP gateway is given a lease time of 3600 seconds on an IP address
it MUST compare the current time to the lease time and the time
the lease was assigned to compute the maximum allowable lease time
the address if it is to assign the address to a RSIP host or
RSIP gateway
Borella, et al. Experimental [Page 15]
RFC 3102 RSIP: Framework October 2001
4.2.2. NAT Behind
+--------+ +--------+
| NAT w/ | | RSIP |
hosts ------+ RSIP +------+ gate- +----- public
| host | | way |
+--------+ +--------+
In this architecture, an RSIP gateway is between a NAT box and
public network. The NAT is also equipped with an RSIP host. The
dynamically requests resources from the RSIP gateway as the
establish sessions to the public network. The hosts are not aware
the RSIP manipulation. This configuration does not enable the
to have end-to-end transparency and thus the NAT still requires
and the architecture cannot support IPSEC
4.2.3. RSIP Behind
+--------+ +--------+
RSIP | RSIP | | |
hosts ------+ gate- +------+ NAT +----- public
| way | | |
+--------+ +--------+
In this architecture, the RSIP hosts and gateway reside behind a NAT
This configuration does not enable the hosts to have end-to-
transparency and thus the NAT still requires ALGs and
architecture cannot support IPSEC. The hosts may have
if there is another gateway to the public network besides the
box, and this gateway supports cascaded RSIP behind RSIP
4.2.4. RSIP Through
+--------+ +--------+
RSIP | | | RSIP |
hosts ------+ NAT +------+ gate- +----- public
| | | way |
+--------+ +--------+
In this architecture, the RSIP hosts are separated from the
gateway by a NAT. RSIP signaling may be able to pass through the
if an RSIP ALG is installed. The RSIP data flow, however, will
its outer IP address translated by the NAT. The NAT must
translate the port numbers in order for RSIP to work properly
Therefore, only traditional NAT will make sense in this context
Borella, et al. Experimental [Page 16]
RFC 3102 RSIP: Framework October 2001
5. Interaction with Layer-Three
Since RSIP affects layer-three objects, it has an impact on
layer three protocols. In this section, we outline the impact
RSIP on these protocols, and in each case, how RSIP, the protocol,
both, can be extended to support interaction
Each of these sections is an overview and not a complete
specification. If a full technical specification of how
interacts with a layer-three protocol is necessary, a
document will contain it
5.1.
RSIP is a mechanism for allowing end-to-end IPSEC with sharing of
addresses. Full specification of RSIP/IPSEC details are in [RSIP
IPSEC]. This section provides a brief summary. Since IPSEC
encrypt TCP/UDP port numbers, these objects cannot be used
demultiplexing fields. However, IPSEC inserts an AH or ESP
following the IP header in all IPSEC-protected packets (packets
are transmitted on an IPSEC Security Association (SA)).
headers contain a 32-bit Security Parameter Index (SPI) field,
value of which is determined by the receiving side. The SPI field
always in the clear. Thus, during SA negotiation, an RSIP host
instruct their public peer to use a particular SPI value. This
value, along with the assigned IP address, can be used by an
gateway to uniquely identify and route packets to an RSIP host.
order to guarantee that RSIP hosts use SPIs that are unique
address, it is necessary for the RSIP gateway to allocate unique
to hosts along with their address/port tuple
IPSEC SA negotiation takes place using the Internet Key
(IKE) protocol. IKE is designated to use port 500 on at least
destination side. Some host IKE implementations will use source
500 as well, but this behavior is not mandatory. If two or more
hosts are running IKE at source port 500, they MUST use
initiator cookies (the first eight bytes of the IKE payload)
assigned IP address. The RSIP gateway will be able to route
IKE packets to the proper host based on initiator cookie value
Initiator cookies can be negotiated, like ports and SPIs. However
since the likelihood of two hosts assigned the same IP
attempting to simultaneously use the same initiator cookie is
small, the RSIP gateway can guarantee cookie uniqueness by
IKE packets with a cookie value that is already in use
Borella, et al. Experimental [Page 17]
RFC 3102 RSIP: Framework October 2001
5.2. Mobile
Mobile IP allows a mobile host to maintain an IP address as it
from network to network. For Mobile IP foreign networks that
private IP addresses, RSIP may be applicable. In particular,
would allow a mobile host to bind to a local private address,
maintaining a global home address and a global care-of address.
global care-of address could, in principle, be shared with
mobile nodes
The exact behavior of Mobile IP with respect to private IP
has not be settled. Until it is, a proposal to adapt RSIP to such
scenario is premature. Also, such an adaptation may be
complex. Thus, integration of RSIP and Mobile IP is a topic
ongoing consideration
5.3. Differentiated and Integrated
To attain the capability of providing quality of service between
communicating hosts in different realms, it is important to
the interaction of RSIP with different quality of
provisioning models and mechanisms. In the section, RSIP
with the integrated service and differentiated service frameworks
discussed
5.3.1. Differentiated
The differentiated services architecture defined in [RFC2475]
networks to support multiple levels of best-effort service
the use of "markings" of the IP Type-of-Service (now DS) byte.
value of the DS byte is termed a differentiated services code
(DSCP) and represents a particular per-hop behavior. This
may not be the same in all administrative domains. No
signaling is necessary to support differentiated services
For outbound packets from an edge network, DSCP marking is
performed and/or enforced on a boundary router. The marked packet
then forwarded onto the public network. In an RSIP-enabled network
a natural place for DSCP marking is the RSIP gateway. In the case
RSAP-IP, the RSIP gateway can apply its micro-flow (address/
tuple) knowledge of RSIP assignments in order to provide
service levels to different RSIP host. For RSA-IP, the RSIP
will not necessarily have knowledge of micro-flows, so it must
on markings made by the RSIP hosts (if any) or apply a default
to the packets
Borella, et al. Experimental [Page 18]
RFC 3102 RSIP: Framework October 2001
When differentiated services is to be performed between RSIP
and gateways, it must be done over the tunnel between these entities
Differentiated services over a tunnel is considered in detail
[DS-TUNN], the key points that need to be addressed here are
behaviors of tunnel ingress and egress for both incoming and
packets
For incoming packets arriving at an RSIP gateway tunnel ingress,
RSIP gateway may either copy the DSCP from the inner header to
outer header, leave the inner header DSCP untouched, but place
different DSCP in the outer header, or change the inner header
while applying either the same or a different DSCP to the
header
For incoming packets arriving at an RSIP host tunnel egress,
with respect to the DSCP is not necessarily important if the
host not only terminates the tunnel, but consumes the packet as well
If this is not the case, as per some cascaded RSIP scenarios,
RSIP host must apply local policy to determine whether to leave
inner header DSCP as is, overwrite it with the outer header DSCP,
overwrite it with a different value
For outgoing packets arriving at an RSIP host tunnel ingress,
host may either copy the DSCP from the inner header to the
header, leave the inner header DSCP untouched, but place a
DSCP in the outer header, or change the inner header DSCP
applying either the same or a different DSCP to the outer header
For outgoing packets arriving at an RSIP gateway tunnel egress,
RSIP gateway must apply local policy to determine whether to
the inner header DSCP as is, overwrite it with the outer header DSCP
or overwrite it with a different value
It is reasonable to assume that in most cases, the diffserv
applicable on a site will be the same for RSIP and non-RSIP hosts
For this reason, a likely policy is that the DSCP will always
copied between the outer and inner headers in all of the above cases
However, implementations should allow for the more general case
5.3.2. Integrated
The integrated services model as defined by [RFC2205]
signalling using RSVP to setup a resource reservation in
nodes between the communicating endpoints. In the most
scenario in which RSIP is deployed, receivers located within
private realm initiate communication sessions with senders
within the public realm. In this section, we discuss the
of RSIP architecture and RSVP in such a scenario. The less
Borella, et al. Experimental [Page 19]
RFC 3102 RSIP: Framework October 2001
case of having senders within the private realm and receivers
the public realm is not discussed although concepts mentioned
may be applicable
With senders in the public realm, RSVP PATH messages flow
from sender to receiver, inbound with respect to the RSIP gateway
while RSVP RESV messages flow in the opposite direction. Since
uses tunneling between the RSIP host and gateway within the
realm, how the RSVP messages are handled within the RSIP
depends on situations elaborated in [RFC2746].
Following the terminology of [RFC2476], if Type 1 tunnels
between the RSIP host and gateway, all intermediate nodes
of the RSIP gateway will be treated as a non-RSVP aware cloud
QoS reserved on these nodes. The tunnel will be viewed as a
(logical) link on the path between the source and destination. End
to-end RSVP messages will be forwarded through the
encapsulated in the same way as normal IP packets. We see this
the most common and applicable deployment scenario
However, should Type 2 or 3 tunnels be deployed between the
endpoints , end-to-end RSVP session has to be statically mapped (
2) or dynamically mapped (Type 3) into the tunnel sessions.
the end-to-end RSVP messages will be forwarded through the
encapsulated in the same way as normal IP packets, a tunnel
is established between the tunnel endpoints to ensure QoS
within the tunnel for the end-to-end session. Data traffic
special QoS assurance will be encapsulated in a UDP/IP header
normal traffic will be encapsulated using the normal IP-
encapsulation. In the type 2 deployment scenario where all
traffic flowing to the RSIP host receiver are given QoS treatment
UDP/IP encapsulation will be rendered in the RSIP gateway for
data flows. The tunnel between the RSIP host and gateway could
seen as a "hard pipe". Traffic exceeding the QoS guarantee of
"hard pipe" would fall back to the best effort IP-IP tunneling
In the type 2 deployment scenario where data traffic could
selectively channeled into the UDP/IP or normal IP-IP tunnel, or
type 3 deployment where end-to-end sessions could be
mapped into tunnel sessions, integration with the RSIP model could
complicated and tricky. (Note that these are the cases where
tunnel link could be seen as a expandable soft pipe.) Two
issues are worth considering
- For RSIP gateway implementations that does encapsulation of
incoming stream before passing to the IP layer for forwarding
the RSVP daemon has to be explicitly signaled upon reception
incoming RSVP PATH messages. The RSIP implementation has
Borella, et al. Experimental [Page 20]
RFC 3102 RSIP: Framework October 2001
recognize RSVP PATH messages and pass them to the RSVP
instead of doing the default tunneling. Handling of other
messages would be as described in [RFC2746].
- RSIP enables an RSIP host to have a temporary presence at
RSIP gateway by assuming one of the RSIP gateway's
interfaces. As a result, the RSVP PATH messages would
addressed to the RSIP gateway. Also, the RSVP SESSION
within an incoming RSVP PATH would carry the global
address, destination port (and protocol) tuples that
leased by the RSIP gateway to the RSIP host. Hence the
unaware RSVP daemon running on the RSIP gateway has to
presented with a translated version of the RSVP messages
Other approaches are possible, for example making the
daemon realm aware
A simple mechanism would be to have the RSIP module handle
necessary RSVP message translation. For an incoming RSVP
flow, the RSIP module does a packet translation of the IP header
RSVP SESSION object before handling the packet over to RSVP.
global address leased to the host is translated to the true
address of the host. (Note that this mechanism works with both RSA
IP and RSAP-IP.) The RSIP module also has to do an
translation from private to global parameter (plus tunneling)
end-to-end PATH messages generated by the RSVP daemon towards
RSIP host receiver. A translation on the SESSION object also has
be done for RSVP outbound control messages. Once the RSVP
gets the message, it maps them to an appropriate tunnel sessions
Encapsulation of the inbound data traffic needing QoS treatment
be done using UDP-IP encapsulation designated by the tunnel session
For this reason, the RSIP module has to be aware of the UDP-
encapsulation to use for a particular end-to-end session
Classification and scheduling of the QoS guaranteed end-to-end
on the output interface of the RSIP gateway would be based on
UDP/IP encapsulation. Mapping between the tunnel session and end
to-end session could continue to use the mechanisms proposed
[RFC2746]. Although [RFC2746] proposes a number of approaches
this purpose, we propose using the SESSION_ASSOC object
because of its simplicity
5.4. IP
The amount of specific RSIP/multicast support that is required
RSIP hosts and gateways is dependent on the scope of multicasting
the RSIP-enabled network, and the roles that the RSIP hosts
play. In this section, we discuss RSIP and multicast interactions
a number of scenarios
Borella, et al. Experimental [Page 21]
RFC 3102 RSIP: Framework October 2001
Note that in all cases, the RSIP gateway MUST be multicast
because it is on an administrative boundary between two domains
will not be sharing their all of their routing information. The
gateway MUST NOT allow private IP addresses to be propagated on
public network as part of any multicast message or as part of
routing table
5.4.1. Receiving-Only Private Hosts, No Multicast Routing
Private
In this scenario, private hosts will not source multicast traffic
but they may join multicast groups as recipients. In the
network, there are no multicast-aware routers, except for the
gateway
Private hosts may join and leave multicast groups by sending
appropriate IGMP messages to an RSIP gateway (there may be IGMP
routers between RSIP hosts and gateways). The RSIP gateway
coalesce these requests and perform the appropriate actions,
they be to perform a multicast WAN routing protocol, such as PIM,
to proxy the IGMP messages to a WAN multicast router. In
words, if one or more private hosts request to join a
group, the RSIP gateway MUST join in their stead, using one of
own public IP addresses
Note that private hosts do not need to acquire demultiplexing
and use RSIP to receive multicasts. They may receive all
using their private addresses, and by private address is how the
gateway will keep track of their group membership
5.4.2. Sending and Receiving Private Hosts, No Multicast
on Private
This scenarios operates identically to the previous scenario,
that when a private host becomes a multicast source, it MUST use
and acquire a public IP address (note that it will still receive
its private address). A private host sending a multicast will use
public source address and tunnel the packets to the RSIP gateway
The RSIP gateway will then perform typical RSIP functionality,
route the resulting packets onto the public network, as well as
to the private network, if there are any listeners on the
network
If there is more than one sender on the private network, then, to
public network it will seem as if all of these senders share the
IP address. If a downstream multicasting protocol identifies
Borella, et al. Experimental [Page 22]
RFC 3102 RSIP: Framework October 2001
based on IP address alone and not port numbers, then it is
that these protocols will not be able to distinguish between
senders
6. RSIP
In this section we document the know complications that RSIP
cause. While none of these complications should be considered "
stoppers" for the majority of applications, they may cause
or undefined behavior. Where it is appropriate, we discuss
remedial procedures that may reduce or eliminate the
impact of a complication
6.1. Unnecessary TCP TIME_
When TCP disconnects a socket, it enters the TCP TIME_WAIT state
a period of time. While it is in this state it will refuse to
new connections using the same socket (i.e., the same
address/port and destination address/port). Consider the case
which an RSIP host (using RSAP-IP) is leased an address/port
and uses this tuple to contact a public address/port tuple.
that the host terminates the session with the public tuple
immediately returns its leased tuple to the RSIP gateway. If
RSIP gateway immediately allocates this tuple to another RSIP
(or to the same host), and this second host uses the tuple to
the same public tuple while the socket is still in the TIME_
phase, then the host's connection may be rejected by the public host
In order to mitigate this problem, it is recommended that
gateways hold recently deallocated tuples for at least two minutes
which is the greatest duration of TIME_WAIT that is
implemented. In situations where port space is scarce, the
gateway MAY choose to allocate ports in a FIFO fashion from the
of recently deallocated ports
6.2. ICMP State in RSIP
Like NAT, RSIP gateways providing RSAP-IP must process ICMP
from the public network in order to determine the RSIP host (if any
that is the proper recipient. We distinguish between ICMP
packets, which are transmitted in response to an error with
associated IP packet, and ICMP response packets, which
transmitted in response to an ICMP request packet
ICMP request packets originating on the private network
typically consist of echo request, timestamp request and address
request. These packets and their responses can be identified by
tuple of source IP address, ICMP identifier, ICMP sequence number
Borella, et al. Experimental [Page 23]
RFC 3102 RSIP: Framework October 2001
and destination IP address. An RSIP host sending an ICMP
packet tunnels it to the RSIP gateway, just as it does TCP and
packets. The RSIP gateway must use this tuple to map incoming
responses to the private address of the appropriate RSIP host.
it has done so, it will tunnel the ICMP response to the host.
that it is possible for two RSIP hosts to use the same values for
tuples listed above, and thus create an ambiguity. However,
occurrence is likely to be quite rare, and is not addressed
in this document
Incoming ICMP error response messages can be forwarded to
appropriate RSIP host by examining the IP header and port
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.,
request) arriving at the RSIP gateway MUST be processed by the
gateway and MUST NOT be forwarded to an RSIP host
6.3. Fragmentation and IP Identification Field
If two or more RSIP hosts on the same private network
outbound packets that get fragmented to the same public gateway,
public gateway may experience a reassembly ambiguity if the IP
ID fields of these packets are identical
For TCP packets, a reasonably small MTU can be set so
fragmentation is guaranteed not to happen, or the likelihood
fragmentation is extremely small. If path MTU discovery
properly, the problem is mitigated. For UDP, applications
the size of packets, and the RSIP host stack may have to fragment
packets that exceed the local MTU. These packets may be
by an intermediate router as well
The only completely robust solution to this problem is to assign
RSIP hosts that are sharing the same public IP address
blocks of numbers to use in their IP identification fields. However
whether this modification is worth the effort of implementing
currently unknown
6.4. Application Servers on RSAP-IP
RSAP-IP hosts are limited by the same constraints as NAT with
to hosting servers that use a well-known port. Since
port numbers are used as routing information to uniquely identify
RSAP-IP host, typically no two RSAP-IP hosts sharing the same
Borella, et al. Experimental [Page 24]
RFC 3102 RSIP: Framework October 2001
IP address can simultaneously operate publically-available
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
per RSAP-IP IP address / port tuple may be used simultaneously if
only if there is a demultiplexing field within the payload of
packets that will uniquely determine the identity of the RSAP-
host, and this field is known by the RSIP gateway
In order for an RSAP-IP host to operate a publically-
gateway, the host must inform the RSIP gateway that it wishes
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
use by another host
In general, contacting devices behind an RSIP gateway may
difficult. A potential solution to the general problem would be
architecture that allows an application on an RSIP host to register
public IP address / port pair in a public database. Simultaneously
the RSIP gateway would initiate a mapping from this address /
tuple to the RSIP host. A peer application would then be required
contact the database to determine the proper address / port at
to contact the RSIP host's application
6.5. Determining Locality of Destinations from an RSIP
In general, an RSIP host must know, for a particular IP address
whether it should address the packet for local delivery on
private network, or if it has to use an RSIP interface to tunnel
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
gateway, then examination of the local network and subnet mask
provide the appropriate information. However, this is not always
case
An alternative that will work in general for statically
private networks is to store a list of the network and subnet
of every private subnet at the RSIP gateway. RSIP hosts may
the gateway with a particular target IP address, or for the
list
If the subnets on the local side of the network are changing
rapidly than the lifetime of a typical RSIP session, the RSIP
may have to query the location of every destination that it tries
communicate with
Borella, et al. Experimental [Page 25]
RFC 3102 RSIP: Framework October 2001
If an RSIP host transmits a packet addressed to a public host
using RSIP, then the RSIP gateway will apply NAT to the packet (if
supports NAT) or it may discard the packet and respond with
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
that it will be more severe on networks where the routing
is changing rapidly that on networks with relatively static routes
6.6. Implementing RSIP Host
An RSIP host MAY free resources that it has determined it no
requires. For example, on an RSAP-IP subnet with a limited number
public IP addresses, port numbers may become scarce. Thus, if
hosts are able to dynamically deallocate ports that they no
need, more hosts can be supported
However, this functionality may require significant modifications
a vanilla TCP/IP stack in order to implement properly. The RSIP
must be able to determine which TCP or UDP sessions are using
resources. If those resources are unused for a period of time,
the RSIP host may deallocate them. When an open socket's
are deallocated, it will cause some associated applications to fail
An analogous case would be TCP and UDP sessions that must
when an interface that they are using loses connectivity
On the other hand, this issue can be considered a resource
problem. It is not recommended that a large number (hundreds)
hosts share the same IP address, for performance purposes. Even if
say, 100 hosts each are allocated 100 ports, the total number
ports in use by RSIP would be still less than one-sixth the
port space for an IP address. If more hosts or more ports
needed, more IP addresses should be used. Thus, it is reasonable
that in many cases, RSIP hosts will not have to deallocate ports
the lifetime of their activity
Since RSIP demultiplexing fields are leased to hosts,
appropriately chosen lease time can alleviate some port
scarcity issues
6.7. Multi-Party
Multi-party applications are defined to have at least one of
following characteristics
- A third party sets up sessions or connections between
hosts
Borella, et al. Experimental [Page 26]
RFC 3102 RSIP: Framework October 2001
- Computation is distributed over a number of hosts such that
individual hosts may communicate with each other directly
RSIP has a fundamental problem with multi-party applications.
some of the parties are within the private addressing realm
others are within the public addressing realm, an RSIP host may
know when to use private addresses versus public addresses.
particular, IP addresses may be passed from party to party under
assumption that they are global endpoint identifiers. This may
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
always use public IP addresses, even when communicating only on
other RSIP hosts. However, this can result in a socket set
between two RSIP hosts having the same source and destination
addresses, which most TCP/IP stacks will consider as intra-
communication
6.8.
The scalability of RSIP is currently not well understood. While
is conceivable that a single RSIP gateway could support hundreds
RSIP hosts, scalability depends on the specific deployment
and applications used. In particular, three major constraints
scalability will be (1) RSIP gateway processing requirements, (2)
RSIP gateway memory requirements, and (3) RSIP negotiation
traffic requirements. It is advisable that all RSIP
protocol implementations attempt to minimize these requirements
7. Security
RSIP, in and of itself, does not provide security. It may
the illusion of security or privacy by hiding a private
space, but security can only be ensured by the proper use of
protocols and cryptographic techniques
8.
The authors would like to thank Pyda Srisuresh, Dan Nessett,
Jaszewski, Ajay Bakre, Cyndi Jung, and Rick Cobb for their input
The IETF NAT working group as a whole has been extremely helpful
the ongoing development of RSIP
Borella, et al. Experimental [Page 27]
RFC 3102 RSIP: Framework October 2001
9.
[DHCP-DNS] Stapp, M. and Y. Rekhter, "Interaction Between DHCP
DNS", Work in Progress
[RFC2983] Black, D., "Differentiated Services and Tunnels",
2983, October 2000.
[RFC3104] Montenegro, G. and M. Borella, "RSIP Support for End-to
End IPSEC", RFC 3104, October 2001.
[RFC3103] Borella, M., Grabelsky, D., Lo, J. and K. Taniguchi
"Realm Specific IP: Protocol Specification", RFC 3103,
October 2001.
[RFC2746] Terzis, A., Krawczyk, J., Wroclawski, J. and L. Zhang
"RSVP Operation Over IP Tunnels", RFC 2746, January 2000.
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.J
and E. Lear, "Address Allocation for Private Internets",
BCP 5, RFC 1918, February 1996.
[RFC2002] Perkins, C., "IP Mobility Support", RFC 2002,
1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to
requirement levels", BCP 14, RFC 2119, March 1997.
[RFC2663] Srisuresh, P. and M. Holdrege, "IP Network
Translator (NAT) Terminology and Considerations",
2663, August 1999.
[RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, S. and S
Jamin, "Resource Reservation Protocol (RSVP)", RFC 2205,
September 1997.
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z
and W. Weiss, "An Architecture for
Services", RFC 2475, December 1998.
[RFC3105] Kempf, J. and G. Montenegro, "Finding an RSIP Server
SLP", RFC 3105, October 2001.
Borella, et al. Experimental [Page 28]
RFC 3102 RSIP: Framework October 2001
10. Authors'
Michael
3800 Golf Rd
Rolling Meadows IL 60008
Phone: (847) 262-3083
EMail: mike_borella@commworks.
Jeffrey
Candlestick Networks,
70 Las Colinas Lane
San Jose, CA 95119
Phone: (408) 284 4132
EMail: yidarlo@yahoo.
David
3800 Golf Rd
Rolling Meadows IL 60008
Phone: (847) 222-2483
EMail: david_grabelsky@commworks.
Gabriel E.
Sun
Laboratories,
29, chemin du Vieux
38240
Phone: +33 476 18 80 45
EMail: gab@sun.
Borella, et al. Experimental [Page 29]
RFC 3102 RSIP: Framework October 2001
11. Full Copyright
Copyright (C) The Internet Society (2001). All Rights Reserved
This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures 