INTERNET DRAFT Michael Borella
Expires February 2000 David Grabelsky
3Com Corp.
Jeffrey Lo
Kunihiro Tuniguchi
NEC USA
August 1999
Realm Specific IP: Protocol Specification
<draft-ietf-nat-rsip-protocol-02.txt>
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet- Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
This draft presents a protocol that enables an alternative to network
address translation (NAT). Realm-Specific IP (RSIP) defines an
architecture in which an RSIP server is a multi-homed host connecting
two routing realms. An RSIP client in the first routing realm may be
assigned a plurality of routing parameters from the second routing
realm. The RSIP client will be allowed to create packets using these
parameters, and tunnel them across the first routing realm. For
example, more than one host from a private address space using RSIP
may share one or more public address. Unlike NAT, RSIP does not
Borella et al. Expires February 2000 [Page 1]
INTERNET-DRAFT Realm Specific IP: Protocol Specification August 1999
break the end-to-end integrity of protocols. We present a general,
extensible negotiation protocol to be operated between RSIP clients
and servers which facilitates the assignment of parameters and
resources from the server to the client.
1. Introduction
Network Address Translation (NAT) has gained popularity as a method
of separating public and private address spaces, and alleviating
network address shortages. A NAT translates the addresses of packets
leaving a first routing realm to an address from a second routing
realm, and performs the reverse function for packets entering the
first routing realm from the second routing realm. This translation
is performed transparently to the hosts in either space, and may
include modification of TCP/UDP port numbers as well as IP addresses.
While a NAT does not require hosts to be aware of the translation, it
will require an application layer gateway (ALG) for any protocol that
transmits IP addresses or port numbers in packet payloads (such as
FTP). Additionally, a NAT will not work with protocols that require
IP addresses and ports to remain unmodified between the source and
destination hosts, or protocols that prevent such modifications to
occur (such as some IPSEC modes, or application-layer end-to-end
encryption).
An alternative to a transparent NAT is an architecture that allows
the clients within the first (e.g., private) routing realm to
directly use addresses and other routing parameters from the second
(e.g., public) routing realm. This form of Realm-Specific IP (RSIP)
requires that an RSIP server (a router or gateway between the two
realms) assign at least one address from the second routing realm,
and perhaps some other resources, to each RSIP client host in the
first routing realm that needs to establish end-to-end connectivity
to a host, entity or device in the second routing realm. Thus, the
second routing realm is not transparent to RSIP client, but this
system allows packets to maintain their integrity from RSIP client to
destination. In order to resolve addressing, routing, and/or
firewall policy ambiguities in the first routing realm, all publicly
routed packets are tunneled between RSIP client and the RSIP server,
or tunneled such that the RSIP server can perform a NAT function on
the outer IP header only. ALGs are not required in the RSIP server.
A disadvantage to RSIP is that it requires that hosts be modified so
that they tunnel externally-bound packets and place some number of
layer three, layer four or other values from those assigned by the
RSIP server in each packet bound for the second routing realm.
This draft discusses a method for assigning parameters to an RSIP
Borella et al. Expires February 2000 [Page 2]
INTERNET-DRAFT Realm Specific IP: Protocol Specification August 1999
client from an RSIP server. The requirements, scope and
applicability of RSIP are discussed in a companion framework draft
[RSIP-FRAME].
1.1. Specification of Requirements
The keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD
NOT", "SHALL", "SHALL NOT", "MAY" and "MAY NOT" that appear in
this document are to be interpreted as described in [RFC2119].
2. Architecture
For simplicity, for the remainder of this document we will assume
that the RSIP clients in the first routing realm (network) use
private (e.g. see [RFC1918]) IP addresses, and that the second
routing realm (network) uses public IP addresses. The RSIP server
connects the public and private realms and contains interfaces to
both. Other NAT terminology found in this document is defined in
[RFC2663].
The diagram below describes an exemplary reference architecture for
RSIP. Some number of RSIP clients are attached via a private network
to an RSIP server, which also acts as a router or gateway between the
private and public networks. This router has been assigned some
number of public addresses that it may use or allocate for use on the
public network.
+-------------+
| RSIP client |
| 1 +--+
| 10.0.0.2 | | +-------------+
+-------------+ | 10.0.0.1 | | 149.112.240.0/24
+-----------------+ RSIP server +-------------------
+-------------+ | | |
| RSIP client | | +-------------+
| 2 +--+ private public
| 10.0.0.3 | | network network
+-------------+ |
|
|
...
RSIP MAY be based on either the Basic NAT or the NAPT model. In the
Basic NAT model, a unique public IP address is assigned to each
private NAT client that is actively communicating with the public
network. Only one NAT client uses a given public address. In the
NAPT model, one public address is shared by one or more NAT clients.
One or more NAT clients may use the same public address by limiting
Borella et al. Expires February 2000 [Page 3]
INTERNET-DRAFT Realm Specific IP: Protocol Specification August 1999
the ports that they use to disjoint subsets of the port space. The
NAT server assigns these disjoint port sets to each host, along with
the public IP address. For the remainder of this document we will
assume the NAPT model unless otherwise stated. With respect to RSIP,
we refer to these models as the Realm Specific Address IP (RSA-IP)
method (NAT) and Realm Specific Address and Port IP (RSAP-IP) method
(NAPT). The RSIP method determines the demultiplexing field(s) of
the packets coming from the public network to the private network.
The RSIP method is extensible to other yet-to-be-defined
demultiplexing fields. A demultiplexing field must be able to
uniquely identify an RSIP client.
RSIP may be deployed incrementally. An RSIP server may be co-located
with a NAT router such that RSIP clients can use the RSIP server, but
non-RSIP clients can use the NAT.
For purposes of illustration, we will provide a brief example of the
transport operation of RSIP with respect to the above architecture.
We assume that RSIP client 10.0.0.2 has been assigned public address
149.112.240.10 and port range 10000-10015 (the actual mechanism for
this assignment is discussed below). Packets transmitted from this
client to a WWW server at the external address of 128.153.4.3 will
appear as follows on the private network:
Outer IP Inner IP TU Ports
+--------------+----------------+----------+
Src: | 10.0.0.2 | 149.112.240.10 | 10000 |
+--------------+----------------+----------+
Dst: | 10.0.0.1 | 128.153.4.3 | 80 |
+--------------+----------------+----------+
Note that 10000 was chosen arbitrarily from the port set by the
kernel port selection code of the RSIP client. Upon reaching the
RSIP server, the outer IP header is stripped off, and the remaining
packet is transmitted on the public network. Incoming packets to the
RSIP client are demultiplexed based on the RSIP method and tunneled
from the RSIP server to the RSIP client. Note that the tunneling
need not be IP-IP and other tunneling mechansims may be used.
Note that the architecture and protocols for RSIP may allow for
cascading of RSIP servers. For example, RSIP server A may assign
some number of public IP addresses and port sets to RSIP server B,
which is entirely inside of the private network. RSIP server B will
then assign some of these addresses and port sets to private hosts.
This architecture conforms to the model in which a corporation (in
charge of RSIP server B) buys public network access from an ISP (in
charge of RSIP server A). In this scenario, RSIP server B and end
hosts within the corporation could be considered the RSIP client of
Borella et al. Expires February 2000 [Page 4]
INTERNET-DRAFT Realm Specific IP: Protocol Specification August 1999
RSIP server A and RSIP server B respectively.
2.1. RSIP Parameter Negotiation
The goal of the RSIP protocol is to specify the basic requirements
of RSIP client / server communication in a series of simple
request / response messages. All request messages from an RSIP
client are replied to by the RSIP server with either the
appropriate response message or an ERROR_RESPONSE. The
ERROR_RESPONSE message may be used at any time by the RSIP server
to indicate that an RSIP client's request was denied or malformed.
An RSIP client initiates a binding request with an RSIP server by
transmitting a REGISTER_REQUEST message. This allows the RSIP
server to become aware of the RSIP client. The RSIP server will
assign a unique identifier to the RSIP client, and respond with a
REGISTER_RESPONSE message.
An RSIP client must then use one of the ASSIGN_REQUEST messages to
request an IP address, port set and/or other parameters from the
public realm. Negotiation of tunnel type and RSIP method may also
occur. The RSIP server will respond with an ASSIGN_RESPONSE
message if it approves the request. All parameters will be
assigned with a lease time, after which their assignment must be
renewed. After parameters have been assigned, the RSIP client may
use the parameters to transmit packets to the public network.
If an RSIP client no longer needs some parameters that it has been
assigned, it may release them by transmitting a FREE_REQUEST
message to the RSIP server, and specifying the parameters to
release within that message. The RSIP server will respond with a
FREE_RESPONSE.
If an RSIP client no longer needs to communicate with the public
network, it may use the DE-REGISTER_REQUEST message to notify the
RSIP server of such. Use of the DE-REGISTER_REQUEST message
effectively releases all of the RSIP client's parameters. The
RSIP server will respond with a DE-REGISTER_RESPONSE. Once an
RSIP client has de-registered, it must register and be assigned
parameters once more before it transmits packets to the public
network again.
An RSIP server may deallocate the parameters of a given client
with the DEALLOCATE message. An RSIP client MUST acknowledge a
DEALLOCATE message with an OK message.
2.2. Operation
Borella et al. Expires February 2000 [Page 5]
INTERNET-DRAFT Realm Specific IP: Protocol Specification August 1999
In the case of RSA-IP, an RSIP client MUST request an IP address,
but not any ports. With the RSAP-IP method, an RSIP client MUST
request an IP address and a port range in the same ASSIGN_REQUEST
message.
If the resources requested are temporarily unavailable, an RSIP
server MAY NOT commit a subset of the resources requested; it MUST
return an ERROR_RESPONSE message indicating that the requested
resources were temporarily unavailable. An RSIP client is free to
attempt another ASSIGN_REQUEST for the same or other resources
after an interval of time. An RSIP server MUST NOT allocate ports
without an associated IP address.
If an RSIP server receives a FREE_REQUEST message that refers to
parameters not assigned to the originating RSIP client, an
ERROR_RESPONSE message indicating that the parameter range was
invalid MUST be returned. If an RSIP server receives a
FREE_REQUEST message referring to an unknown binding, an
ERROR_RESPONSE message indicating that the binding is unknown MUST
be returned.
If an RSIP client wishes to extend the duration of an existing
binding, an ASSIGN_REQUEST with the same Bind ID and the desired
extension duration MAY be sent. The RSIP server MUST either grant
the request, grant a smaller duration than that requested or deny
the request. If a smaller duration is granted, this duration MUST
be included in the response message to the ASSIGN_REQUEST. In the
case when the request is denied, the appropriate ERROR_RESPONSE
MUST be sent.
RSIP servers SHOULD NOT forward packets from a RSIP client without
checking the validity of the packets' demultiplexing parameters.
Other necessary policy based routing checks SHOULD also be made.
Improper use of demultiplexing parameters or other parameters, or
any RSIP client using a resource or parameter assigned to a
different RSIP client are auditable events.
If RSAP-IP is used, an RSIP client can request that the RSIP
server pass to it all packets sent to a particular IP address and
port number. The RSIP client must specify the IP address and
port(s) to listen on with the LISTEN_REQUEST message. A
successful request will be followed by a LISTEN_RESPONSE message
from the RSIP server. This would enable, for example, an RSIP
client to bind a WWW server to a public address at port 80, and
receive all traffic to that address/port pair.
Note that the RSIP control protocol operates on a simple
request/response basis, as described above. However, an RSIP
Borella et al. Expires February 2000 [Page 6]
INTERNET-DRAFT Realm Specific IP: Protocol Specification August 1999
client MAY transmit an OK message upon receiving a response from
an RSIP server. Such OK messages serve to complete a three-way
handshake and are useful for verifying the authenticity of a
request. However, use of a three-way handshake over an unreliable
transport mechanism leads to more complicated client and server
state maintenance.
If an RSIP server must deallocate the resources associated with an
RSIP client's Bind ID, it may do so with a DEALLOCATE message.
This message must be followed by an OK message from the RSIP
client.
2.3. RSIP Server State
An RSIP server must maintain state for all RSIP clients with
assigned resources. This state may be maintained on the basis of
individual RSIP clients, or on the basis of their active flows.
The required RSIP server state will vary based on the RSIP method,
but will always include the chosen methods demultiplexing
parameters.
2.3.1. RSA-IP State
An RSIP server serving an RSIP client using the RSA-IP method
MUST maintain the following state:
- Client's private address
- Client's assigned public address(es)
For flow-based state, the additional parameters that MAY be
maintained are:
- Source port number
- Destination port number
- Peer's public IP address
- ToS / DS byte
For a packet destined to an RSIP client, an RSIP server must
examine, at a minimum, the destination IP address. From this
address, and possibly some number of the fields listed above,
the RSIP server will be able to determine the RSIP client to
which the packet should be tunneled. It is highly recommended
that all RSIP servers use flow-based state in order to minimize
the impact of denial of service flooding attacks.
2.3.2. RSAP-IP State
An RSIP server serving an RSIP client using the RSAP-IP method
Borella et al. Expires February 2000 [Page 7]
INTERNET-DRAFT Realm Specific IP: Protocol Specification August 1999
MUST maintain the following state:
- Client's private address
- Client's assigned public address(es)
- Client's assigned port range(s)
For flow-based state, the additional parameters that MAY be
maintained are:
- Source port number
- Destination port number
- Peer's public IP address
- ToS / DS byte
For a packet destined to an RSIP client, the RSIP server must
examine, at a minimum, the destination IP address and
destination port number. From these fields, and possibly some
number of the fields listed above, the RSIP server will be able
to determine the RSIP client to which the packet should be
tunneled. It is highly recommended that all RSIP servers use
flow-based state in order to minimize the impact of denial of
service flooding attacks
Policy may be applied such that public hosts are allowed to
initiate contact to private RSIP clients through their assigned
address(es) and port(s). Thus, after a successful assignment, an
RSIP client will be able to start a service on one of its public
ports, and this service may be used by hosts on the public network
(how the public hosts are notified of this service's existence is
an open issue). Alternatively, the RSIP server may restrict a
public host from initiating contact with an RSIP client. In this
case, packets destinated to an RSIP client are forwarded by the
RSIP server only if the RSIP client has already transmitted a
packet to the sender.
Note that if an RSIP client is issued a binding to an address/port
pair with the LISTEN_RESPONSE message, then the RSIP server MUST
forward all packets destinated to that address/port on to the RSIP
client.
2.4. Subnet Query
In some cases it is not possible for an RSIP client to know
whether a packet should be tunneled to the RSIP server or
transmitted using the local (private) routing realm only. The RSIP
protocol provides a subnet query mechanism through which an RSIP
client may query an RSIP server to ask whether a particular subnet
falls within the private domain. An RSIP client queries the
Borella et al. Expires February 2000 [Page 8]
INTERNET-DRAFT Realm Specific IP: Protocol Specification August 1999
server using the QUERY_REQUEST message with the subnet included in
the IP address field of the message. The RSIP server uses the
QUERY_RESPONSE to reply to this message. The RSIP server MAY
confirm the subnet queried or MAY return the whole range of
subnets supported so as to enable the RSIP client to cache the
entries. The RSIP server may be manually configured to know the
topology of the private domain.
2.5. Unreliable Transport and Message IDs
A message ID field SHOULD be included in all messages if UDP, or
some other unreliable transport mechanism, is used. The message ID
starts with zero in the client's REGISTER_REQUEST message and end
with a maximum value in the server's DE-REGISTER_RESPONSE message.
This field SHOULD be incremented by one for every request issued.
Responses MUST include the same message ID as that of the request
which it acknowledges.
If an RSIP client does not receive a response from the RSIP server
for a request, a new request with the same message ID MAY be
issued after an interval of time. An RSIP server receiving a
request with a message ID smaller than what it previously received
(within a REGISTERed session) SHOULD ignore the request.
Pipelining of requests and aggregation of responses MUST NOT be
allowed.
Message ID wraparound is highly unlikely, however it must be
considered in both the RSIP clients and servers.
RSIP servers SHOULD implement message IDs, and SHOULD respond with
message IDS to all clients that offer message IDs in their
requests. An RSIP client MAY accept messages without message IDs
from servers even if the client has offered message IDs.
2.6. Parameter Assignment Transport and Mechanisms
In order to assign parameters to the RSIP client from the RSIP
server, a transport protocol and an assignment mechanism must be
used. Design of the RSIP protocol aims to be transport
independent, so that existing transport protocols such as UDP or
TCP can be used. The advantages of using either UDP or TCP in
different situations is discussed in [RSIP-FRAME].
RSIP has been designed to be protocol agnostic, in that RSIP
messages can ride on top of other parameter assignment and
negotiation protocols such as DHCP or SOCKS. However, it is
likely that initial RSIP implementations will use a dedicated port
number and implement the RSIP protocol in the raw form specified
Borella et al. Expires February 2000 [Page 9]
INTERNET-DRAFT Realm Specific IP: Protocol Specification August 1999
in this draft. Current RSIP implementations have been using UDP
and TCP port 4455 for testing. Note that this port number has not
been officially assigned to RSIP by IANA and therefore may change
at any time.
2.7. ICMP Handling
Like NAT, RSIP server are required to remember recent ICMP packets
for which responses cannot be demultiplexed by port number (i.e.,
echo request packets). ICMP request packets originating on the
private network 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 target IP address. An RSIP client
sending an ICMP request packet tunnels it to the RSIP server, just
as it does TCP and UDP packets. The RSIP server must use this
tuple to map incoming ICMP responses to the private address of the
appropriate RSIP client. Once it has done so, it will tunnel the
ICMP response to the client. Note that it is possible for two
RSIP clients to use the same values for the tuples listed above,
and thus create an ambiguity. However, this occurance is likely
to be quite rare, and is not addressed further in this draft.
Incoming ICMP error response messages can be forwarded to the
appropriate RSIP client by examining the IP header and port
numbers embedding within the packet. In the case of RSA-IP, only
the source IP address is necessary to determine the RSIP client.
In the case of RSAP-IP, the source IP address and source port
number is necessary to determine the RSIP client.
Occasionally, an RSIP client will have to send an ICMP response
(e.g., port unreachable). These responses are tunneled to the
RSIP server, as is done for TCP and UDP packets. All ICMP
requests (e.g., echo request) arriving at the RSIP server MUST be
processed by the RSIP server and MUST NOT be forwarded to an RSIP
client.
3. General Message and Parameter Formats
In this section we define the general message and parameter format.
Codes for each parameter and message types will be discussed the
following sections. Within an RSIP message, all required parameters
SHOULD appear before all optional parameters.
The general message format is shown below.
Borella et al. Expires February 2000 [Page 10]
INTERNET-DRAFT Realm Specific IP: Protocol Specification August 1999
1 byte Variable Variable
+-----------+---------------+-------------------
| Type | Parameter 1 | Parameter 2 ...
+-----------+---------------+-------------------
The type field indicates how the parameters are to be interpreted
(e.g., request, response, error, etc.).
The general format of all parameters is shown below.
1 byte 2 bytes 'Length' bytes
+------+----------+----------------------
| Code | Length | Parameter value ...
+------+----------+----------------------
All parameters consist of a fixed portion and a variable portion.
The fixed portion is a 1 byte code value and a 2 byte length. The
remaining portion of the parameter is the parameter value, the length
which is the number of bytes indicated by the length field.
Note that the code value of 0 is reserved.
4. Parameter Types and Formats
4.1. IP Address Request
Code Length
+------+--------+
| 1 | 0 |
+------+--------+
Used in ASSIGN_REQUEST messages to request an IP address.
4.2. Number of Ports
Code Length Number of Ports
+------+--------+-------------------+
| 2 | 1 | (1 byte) |
+------+--------+-------------------+
Used in ASSIGN_REQUEST messages to request a particular number of
ports to be assigned.
4.3. IP Address
Code Length IP Address
+------+--------+-----------------------+
| 3 | 4 | (4 bytes) |
Borella et al. Expires February 2000 [Page 11]
INTERNET-DRAFT Realm Specific IP: Protocol Specification August 1999
+------+--------+-----------------------+
This field represents the IPv4 address negotiated. Used in
ASSIGN_RESPONSE, QUERY_REQUEST and QUERY_RESPONSE messages.
4.4. Port Range
Code Length Low Port High Port
+------+--------+-----------+-----------+
| 4 | 4 | (2 bytes) | (2 bytes) |
+------+--------+-----------+-----------+
The range of ports allocated to an RSIP client. The port range
MUST be contiguous and is inclusive.
4.5. Lease Time
Code Length Lease Time
+------+--------+-----------------------+
| 5 | 4 | (4 bytes) |
+------+--------+-----------------------+
Number of seconds that an RSIP client may retain the parameters
assigned by an RSIP server.
4.6. Error
Code Length Error
+------+--------+-----------+
| 6 | 2 | (2 bytes) |
+------+--------+-----------+
These error codes allow an RSIP server to inform an RSIP client
why a particular request has failed.
1 UNKNOWNERROR - An error that cannot be identified has occurred.
2 BADBINDID - The request refers to an invalid Bind ID.
3 BADCLIENTID - The request refers to an invalid Client ID.
4 MISSINGPARAM - The request does not contain a required parameter.
5 DUPLICATEPARAM - The request contains an illegal duplicate parameter.
6 ILLEGALPARAM - The request contains a parameter that it should not.
7 ILLEGALMESSAGE - The RSIP server does not understand the message type.
8 REGISTERFIRST - The RSIP client has attempted to request or use
resources without registering.
9 BADMESSAGEID - The request contains an unexpected message ID.
10 ALREADYREGISTERED - The RSIP client has attempted to register again
without first de-registering.
11 ALREADYUNREGISTERED - The RSIP client has attempted to de-register
Borella et al. Expires February 2000 [Page 12]
INTERNET-DRAFT Realm Specific IP: Protocol Specification August 1999
but it is already in the unregistered state.
12 BADTUNNELTYPE - The RSIP client has tried to use a tunnel type that
the RSIP server does not support.
13 ADDRUNAVAILABLE - The RSIP server was not able to allocate an IP address.
14 PORTUNAVAILABLE - The RSIP server was not able to allocate port(s).
4.7. Client ID
Code Length Client ID
+------+--------+-------------------+
| 7 | 4 | (4 bytes) |
+------+--------+-------------------+
A unique number assigned by an RSIP server when an RSIP client
registers with the server. It is used to identify the RSIP client.
4.8. Bind ID
Code Length Bind ID
+------+--------+-------------------+
| 8 | 4 | (4 bytes) |
+------+--------+-------------------+
The Bind ID is a unique number allocated for each new assignment.
It is returned as part of an ASSIGN_RESPONSE to a successful
ASSIGN_REQUEST. Subsequent message exchanges pertaining a bind
MUST include its Bind ID. When parameters are assigned to an RSIP
client, these parameters are said to be 'bound' to that client.
More than one bind, each with different Bind IDs, may be
established between an RSIP client and RSIP server pair. A binding
will expire when its lease time runs out or when the RSIP client
de-registers itself with the RSIP server.
4.9. Message ID
Code Length Message ID
+------+--------+-------------------+
| 9 | 1 | (1 byte) |
+------+--------+-------------------+
If the transport protocol is connectionless, such as UDP, the
message ID field MUST be included as a means to order the messages
and/or match requests and responses.
4.10. Tunnel Type
Borella et al. Expires February 2000 [Page 13]
INTERNET-DRAFT Realm Specific IP: Protocol Specification August 1999
Code Length Tunnel Type
+------+--------+------------+
| 10 | 1 | (1 byte) |
+------+--------+------------+
The type of tunnel used between an RSIP client and an RSIP server.
Values are assigned as follows:
0 Reserved
1 IP-IP
2 GRE
3 L2TP
4.11. RSIP Method
Code Length RSIP Method
+------+--------+-------------+
| 11 | 1 | (1 byte) |
+------+--------+-------------+
The RSIP method that the server will support.
1 Realm Specific Address IP (RSA-IP) method.
2 Realm Specific Address and Port IP (RSAP-IP) method.
4.12. Vendor Specific Parameter
Code Length Vendor ID Subcode Parameter
+------+----------+------------+-----------+-----------+
| 12 | n+4 | (2 bytes) | (2 bytes) | (n bytes) |
+------+----------+------------+-----------+-----------+
This parameter allows vendors to specify vendor specific
information. The Vendor ID field the vendor-specific ID assigned
by IANA. Subcodes are defined and used by each vendor.
5. Message Types
Apart from the message type field, which MUST appear at the beginning
of each message, other parameters MAY appear in any order. Note that
message sequencing MAY need to be introduced depending on the
transport. The following message types are defined in simple BNF.
Required parameters are enclosed in <> and MUST appear. Optional
parameters are enclosed in [] and MAY appear. Message type numbers
are defined below. Not all message types need to be implemented in
order to be RSIP compliant. For example, an RSIP client and/or
server may not support LISTEN_REQUEST and LISTEN_RESPONSE, but will
Borella et al. Expires February 2000 [Page 14]
INTERNET-DRAFT Realm Specific IP: Protocol Specification August 1999
still be able to perform RSIP.
Note that for all RSIP messages, each parameter MUST NOT appear more
than once, with the exception of parameters such as tunnel type and
RSIP method, which MAY appear more than once in an ASSIGN_REQUEST
message.
5.1. Message Type Numbers
Numbers are assigned to message types as follows:
1 ERROR_RESPONSE
2 REGISTER_REQUEST
3 REGISTER_RESPONSE
4 DE-REGISTER_REQUEST
5 DE-REGISTER_RESPONSE
6 ASSIGN_REQUEST_ADDR
7 ASSIGN_REQUEST_PORT
8 ASSIGN_REQUEST_EXT
9 ASSIGN_RESPONSE_ADDR
10 ASSIGN_RESPONSE_PORT
11 ASSIGN_RESPONSE_EXT
12 FREE_REQUEST
13 FREE_RESPONSE
14 QUERY_REQUEST
15 QUERY_RESPONSE
16 DEALLOCATE
17 OK
18 LISTEN_REQUEST
19 LISTEN_RESPONSE
5.2. ERROR_RESPONSE
An ERROR_RESPONSE is used to provide error messages to an RSIP
client message. If the error is related to a particular Client ID
or Bind ID, these parameters MUST be included. Multiple errors
MAY NOT be reported in the same ERROR_RESPONSE.
<ERROR_RESPONSE>::= <Message Type> <Error Parameter>
[Message ID][Client ID]
[Bind ID]
5.3. REGISTER_REQUEST
The REGISTER_REQUEST message is used by an RSIP client to register
with an RSIP server. An RSIP client MUST register before it
requests parameters from the RSIP server.
Borella et al. Expires February 2000 [Page 15]
INTERNET-DRAFT Realm Specific IP: Protocol Specification August 1999
<REGISTER_REQUEST> ::= <Message Type> [Message ID]
5.4. REGISTER_RESPONSE
The REGISTER_RESPONSE message is used by an RSIP server to confirm
the registration of an RSIP client, and to provide a Client ID.
<REGISTER_RESPONSE> ::= <Message Type> <Client ID> [Message ID]
5.5. DE-REGISTER_REQUEST
The DE-REGISTER_REQUEST message is used by an RSIP client to de-
register with an RSIP server.
<DE-REGISTER_REQUEST> ::= <Message Type> <Client ID> [Message ID]
5.6. DE-REGISTER_RESPONSE
The DE-REGISTER_RESPONSE message is used by an RSIP server to
confirm the de-registration of an RSIP client.
<DE-REGISTER_RESPONSE> ::= <Message Type> <Client ID> [Message ID]
5.7. ASSIGN_REQUEST
The ASSIGN_REQUEST message is used by an RSIP client to request
parameter assignments. In RSA-IP method, ASSIGN_REQUEST_ADDR
format MUST be used and an IP address MUST be requested. For RSAP-
IP, ASSIGN_REQUEST_PORT format MUST be used, and a port range MUST
be requested for every IP address requested. When requesting a
renewal of a previously-assigned, but not yet expired lease,
ASSIGN_REQUEST_EXT format MUST be used, and a valid Bind ID MUST
be specified. All types of ASSIGN_REQUEST message share the same
message type. The RSIP client MAY list all of the tunnel types
supported. The default tunnel type is IP-IP; thus, if no tunnel
type is specified, the RSIP server MUST assume that IP-IP
tunneling will be used, unless a different type of tunnel is
implied by the RSIP method. All RSIP implementations MUST support
IP-IP tunneling.
Borella et al. Expires February 2000 [Page 16]
INTERNET-DRAFT Realm Specific IP: Protocol Specification August 1999
<ASSIGN_REQUEST_ADDR> ::= <Message Type> <Client ID>
<RSIP method = RSA-IP> <IP Addr Req>
[Lease Time] [Tunnel Type...]
[Message ID]
<ASSIGN_REQUEST_PORT> ::= <Message Type> <Client ID>
<RSIP method = RSAP-IP> <IP Addr Req>
<Number of Ports> [Lease Time]
[Tunnel Type...] [Message ID]
<ASSIGN_REQUEST_EXT> ::= <Message Type> <Client ID>
<Bind ID> [Lease Time] [Message ID]
5.8. ASSIGN_RESPONSE
The ASSIGN_RESPONSE message is used by an RSIP server to deliver
parameter assignments to an RSIP client. A client-wise unique
Bind ID must be provided for every assignment. If a lease time is
not requested by an RSIP client, an RSIP server MUST assign a
default lease time. If an ASSIGN_REQUEST is not granted, the
appropriate ERROR_RESPONSE message(s) MUST be generated,
specifying all reasons why the ASSIGN_REQUEST failed. If the
requested RSIP method is not supported, the RSIP server MUST NOT
allocate any resources. For RSA-IP, ASSIGN_RESPONSE_ADDR is used.
For RSAP-IP, ASSIGN_RESPONSE_PORT is used. When a lease extension
is granted, ASSIGN_RESPONSE_EXT is used. All types of
ASSIGN_RESPONSE message share the same message type. Note that
the chosen tunnel type MUST be included in the message, except for
extension requests and when the RSIP method implies that a
particular type of tunnel must be used.
<ASSIGN_RESPONSE_ADDR> ::= <Message Type> <Client ID> <Bind ID>
<RSIP method = RSA-IP> <IP Address>
<Lease Time> <Tunnel Type> [Message ID]
<ASSIGN_RESPONSE_PORT> ::= <Message Type> <Client ID> <Bind ID>
<RSIP method = RSAP-IP> <IP Address>
<Port Range> <Lease Time> <Tunnel Type>
[Message ID]
<ASSIGN_RESPONSE_EXT> ::= <Message Type> <Client ID>
<Bind ID> <Lease Time>
[Message ID]
5.9. FREE_REQUEST
The FREE_REQUEST message is used by an RSIP client to free
parameter assignments. The given Bind ID identifies the IP
Borella et al. Expires February 2000 [Page 17]
INTERNET-DRAFT Realm Specific IP: Protocol Specification August 1999
address and/or port range being freed. Resources may only be
freed using the granularity of a Bind ID.
<FREE_REQUEST> ::= <Message Type> <Client ID> <Bind ID>
[Message ID]
5.10. FREE_RESPONSE
The FREE_RESPONSE message is used by an RSIP server to acknowledge
a FREE_REQUEST sent by an RSIP client.
<FREE_RESPONSE> ::= <Message Type> <Client ID> <Bind ID>
[Message ID]
5.11. QUERY_REQUEST
A QUERY_REQUEST message is used by an RSIP client to request if a
subnet or IP address is supported by an RSIP server. If a subnet
is queried, it is placed in an IP address parameter.
<QUERY_REQUEST> ::= <Message Type> <Client ID> <IP address>
[Message ID]
5.12. QUERY_RESPONSE
A QUERY_RESPONSE message is used by an RSIP server to answer a
QUERY_REQUEST from an RSIP client. The RSIP server SHOULD respond
with a list of all subnets and/or addresses that are on the
private side of the network.
<QUERY_RESPONSE> ::= <Message Type> <Client ID> <IP address>
[IP address...] [Message ID]
5.13. DEALLOCATE
A DEALLOCATE message is used by an RSIP server to force an RSIP
client to relinquish specified resources (e.g., in the case of a
lease expiration). The Bind ID of the resources to be
relinquished MUST be included. Upon receiving a DEALLOCATE
message, an RSIP client MUST stop all use of the said resources
and immediately send an OK response to the server.
<DEALLOCATE> ::= <Message Type> <Client ID> <Bind ID>
[Message ID]
5.14. OK
Borella et al. Expires February 2000 [Page 18]
INTERNET-DRAFT Realm Specific IP: Protocol Specification August 1999
An OK message MAY be used by an RSIP client to positively
acknowledge the receipt of a message from the RSIP server. The OK
message MUST be used to respond to a DEALLOCATE message from an
RSIP server.
<OK> ::= <Message Type> <Client ID> [Message ID]
5.15. LISTEN_REQUEST
A LISTEN_REQUEST message is sent by an RSIP client that wants to
register a service on a particular IP address and port number.
The required parameters are and IP address and a port range.
Optional parameters are RSIP method and tunnel type. The RSIP
client may request a range of listen ports, or just one (a single
port is specified by placing the same port number in the "low" and
"high" fields of the Port Range parameter). LISTEN_REQUEST is not
necessary for RSA-IP.
<LISTEN_REQUEST> ::= <Message Type> <Client ID> <IP Address>
<Port range> [Lease Time] [RSIP method]
[Tunnel Type] [Message ID]
5.16. LISTEN_RESPONSE
A LISTEN_RESPONSE message is used by an RSIP server to respond to
a LISTEN_REQUEST message from an RSIP client. The RSIP server
MUST issue a Bind ID, and specify the IP address, port range, RSIP
method, and tunnel type to be used.
<LISTEN_RESPONSE> ::= <Message Type> <Client ID> <Bind ID>
<IP Address> <Port range> <RSIP method>
<Tunnel Type> <Lease Time> [Message ID]
6. Miscellaneous Issues
TCP TIME_WAIT at external servers: When a TCP server 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 circumstance in which an
RSIP client terminates a connection with an external server, and
immediately frees the port that it was using to source the
connection (alternatively, the port may be deallocated by the RSIP
server). If the RSIP server immediately allocates this port to
another RSIP client, and this client uses the same port to contact
the same external server while that server is still in TIME_WAIT,
then the client's connection may be rejected by the server. In
order to mitigate this problem, it is recommended that RSIP
Borella et al. Expires February 2000 [Page 19]
INTERNET-DRAFT Realm Specific IP: Protocol Specification August 1999
servers hold recently deallocated ports for at least two minutes,
which is the greatest duration of TIME_WAIT that is commonly
implemented [STEV94]. In situations where ports are scarce, the
RSIP server MAY choose to allocate ports in a FIFO fashion from
the pool of recently deallocated ports.
Split DNS: RSIP requires that DNS traffic from the private network
not be propagation on the public network. This issue is not
specific to RSIP - it also occurs in NAT.
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.
An RSIP implementation must be guarded against potential denial- of-
service attacks. A malicious RSIP client may be able to determine
the parameters associated with another RSIP client via packet
sniffing. An attacker could use or free the resources allocated by
the RSIP server by spoofing a data packet or a FREE request,
respectively. It is desirable to secure negotiation between an RSIP
client and RSIP server with an appropriate authentication mechanism.
This general problem is not specific to RSIP - DHCP suffers from the
same lack of authentication. However, this security hole is
mitigated to some extent by the following: (1) It is much more
difficult to sniff packets if the RSIP clients are on a switched LAN,
and this is the direction that the industry is moving towards, (2)
use of the RSIP Bind ID and message IDs prevents some simple attacks
such as packet replay, and (3) all RSIP clients must answer to the
authority to which they are borrowing resources from; therefore, once
detected, an attacker can be dealt with administratively. Note that
although IPSEC could be used for securing the channel between the
RSIP client and the RSIP server, it would require implementations on
both the client and the server, and may prove to be too heavyweight
for some systems.
8. Changelog
01 to 02:
- Added section on server state.
- Re-wrote section on parameter negotiation.
- Added details to ICMP Handling section.
- Added LISTEN_REQUEST and LISTEN_RESPONSE messages.
- Added appendix with client state diagram.
- Updated references with respect to RFC 2663.
- Clarified use/non-use of message IDs between clients and servers.
Borella et al. Expires February 2000 [Page 20]
INTERNET-DRAFT Realm Specific IP: Protocol Specification August 1999
- Added recommendation that RSIP use port 4455 for initial implementation
and testing, until further notice.
- Bumped code values up by 1, made code value of 0 reserved.
- Expanded ASSIGN_REQUEST into ASSIGN_REQUEST_ADDR for RSA-IP,
ASSIGN_REQUEST_PORT for RSAP-IP and ASSIGN_REQUEST_EXT for lease
extensions. The same expansion applies for ASSIGN_RESPONSE.
- Indiciated that all RSIP parameters must not appear more than once
except for tunnel type and RSIP method in ASSIGN_REQUEST messages.
- Exactly one error is now reported in each ERROR_RESPONSE message.
00 to 01:
- Eliminated number of IP addresses and IP address range
parameters and fixed other parameters to reflect this change.
- Added IP address request message.
- Added discussion on authentication to Security Considerations
section.
- Added Miscellaneous Issues section.
- Changed all mention of "sequence number" to "message ID".
- Reformatted References section.
- Added reference to RSIP framework draft.
- Separated request and response messages, then renumbered them.
- Required that all RSIP implementations support IP-IP tunneling
and RSA-IP.
- Modified message semantics slightly.
- Added appendix with protocol example.
- Added address and port resource error messages.
- Specified that multiple error responses may be returned in the
same ERROR_RESPONSE message.
- RSIP method may now be specified per binding, so that different
methods can be used when connecting to different external systems.
- Synched up terminology with the latest NAT terminology draft.
- Added mention of RSIP servers also implementing a NAT as a
fallback.
- Added DEALLOCATE and OK messages.
- Tunneling now negotiated per bind rather than per-registration.
9. Acknowledgements
The authors would like to thank Gabriel Montenegro, Pyda Srisuresh,
Dan Nessett, Gary Jaszewski, and Rick Cobb for their input.
10. Appendix: Example RSIP client/server transactions
In this appendix, we present an exemplary series of transactions
between an RSIP client and an RSIP server. All client to server
traffic is denote by `C --> S' and all server to client traffic is
denoted by `S --> C'. Message types and message ID's are not
Borella et al. Expires February 2000 [Page 21]
INTERNET-DRAFT Realm Specific IP: Protocol Specification August 1999
included in order to save space.
C --> S: REGISTER_REQUEST ()
The client attempts to register with the server.
S --> C: REGISTER_RESPONSE (Client ID = 1)
The server responds, assigning a Client ID of 1.
C --> S: ASSIGN_REQUEST_PORT: (Client ID = 1, RSIP method = RSAP-IP,
IP Address Request, Num Ports = 16, Lease Time = 3600 Tunnel type
= IP-IP, Tunnel type = GRE)
The client requests an IP address and 16 ports to use with it with
RSAP-IP. The client indicates that it would like to use these
resources for 3600 seconds with either IP-IP and GRE tunneling.
S --> C: ASSIGN_RESPONSE_PORT: (Client ID = 1, RSIP method = RSAP-IP,
Bind ID = 0, IP address = 149.112.240.156, Port range = 9000-9015,
Lease time = 1800, Tunnel type = IP-IP)
The server responds by indicating that a Bind ID of 0 has been
assigned to the resources of an IP address of 149.112.240.156 and
a port range of 9000-9015 to be used for RSAP-IP. The server also
indicates that it will grant a lease time of only 1800 seconds,
and indicates that IP-IP tunneling will be used.
The client is now able to communicate with the public network
using these resources.
C --> S: QUERY_REQUEST: (Client ID = 1, IP address = 10.20.60.0)
The client asks the server if the subnet 10.20.60.0 is local.
S --> C: QUERY_RESPONSE: (Client ID = 1, IP address = 10.20.60.0, IP
address = 10.20.66.0, IP address = 10.20.68.0)
The server responds with a list of local subnets, implicitly
informing the client that subnet 10.20.60.0 is local.
C --> S: ASSIGN_REQUEST_PORT: (Client ID = 1, RSIP method = RSAP-IP,
IP Address Request, Num Ports = 8, Lease Time = 1800)
The client requests 8 more ports for use with RSAP-IP. A lease of
1800 seconds is requested. IP-IP tunneling is implied by default.
S --> C: ASSIGN_RESPONSE_PORT: (Client ID = 1, RSIP method = RSAP-IP,
Borella et al. Expires February 2000 [Page 22]
INTERNET-DRAFT Realm Specific IP: Protocol Specification August 1999
Bind ID = 1, IP address = 149.112.240.156, Port range = 9074-9081,
Lease time = 1800)
The server grants the request, assigning ports 9074-9081 from IP
address 149.112.240.156. IP-IP tunneling is implied by default.
C --> S: FREE_REQUEST (Client ID = 1, Bind ID = 0)
The client frees Bind ID 0; i.e., ports 9000-9015 from IP address
149.112.240.156. Note that the address itself is still assigned
to the client because the client is still assigned ports
9074-9081.
S --> C: FREE_RESPONSE (Client ID = 1, Bind ID = 0)
The server acknowledges that Bind ID 0 has been freed.
C --> S: ASSIGN_REQUEST_EXT (Client ID = 1, Bind ID = 1, Lease Time =
1800)
The client request that the lease on Bind ID 1 be extended for
1800 seconds.
S --> C: ASSIGN_RESPONSE_EXT (Client ID = 1, Bind ID = 1, Lease Time
= 1800)
The server confirms the request.
S --> C: DEALLOCATE (Client ID = 1, Bind ID = 1)
The server forces the client to deallocate the resources of Bind
ID 1.
C --> S: OK (Client ID = 1)
The client acknowledges that the resources have been deallocated.
C --> S: DE-REGISTER_REQUEST (Client ID = 1)
The client de-registers with the sever.
S --> C: REGISTER_RESPONSE (Client ID = 1)
The server acknowledges that the client has de-registered.
11. Appendix: Example RSIP client state diagram
This appendix provides an exemplary diagram of RSIP client state.
Borella et al. Expires February 2000 [Page 23]
INTERNET-DRAFT Realm Specific IP: Protocol Specification August 1999
The client begins in the Unregistered state. We assume that if a
message are lost, the client will timeout and retransmit another copy
of it. We recommend a 7-fold binary exponential backoff timer for
retransmissions, with the first timeout occuring after 25 ms. This
diagram does not include transitions for the LISTEN_REQUEST message
or the DEALLOCATE message.
send
+------------+ REGISTER_REQUEST +------------+
| |----------------->|Registration|<-- timeout/send
+--->|Unregistered|<-----------------| Pending |--- REGISTER_REQUEST
| | | 7th timeout/recv +------------+
| +------------+ ERROR_RESPONSE |
| ^ |
| |7th timeout/recv |recv timeout/send
| |DE-REGISTER_RESPONSE |REGISTER_RESPONSE QUERY_REQUEST
| | | ^ |
| | send DE- v send | |
| +----------------+ REGISTER_REQUEST+----------+QUERY_REQUEST +----------+
| | Registered |<----------------| |-------------->|Registered|
| | De-registration| |Registered| | Query |
| | Pending |---------------->| |<--------------| Pending |
| +----------------+ recv +----------+ 7th timeout/ +----------+
| | ^ ERROR_RESPONSE ^ | recv
| | | | | QUERY_RESPONSE or
| timeout/send | | ERROR_RESPONSE
| DE-REGISTER_REQUEST 7th timeout/recv| |
| ERROR_RESPONSE | |
| +----------------+ | |
| |Go to Registered| | |send
| +----------------+ | |ASSIGN_REQUEST
| ^ timeout/send | |
| |Yes FREE_REQUEST | |
| + | | | |
| + + v | | v
| + + 7th timeout/ +--------+ +----------+
| + Are all + recv | Free | |Assignment|<--timeout/send
| + resources +<-----------|Pending | | Pending |---ASSIGN_REQUEST
| + freed? + FREE_RESPONSE+--------+ +----------+
| + + ^ | |
| + + | | |
| + | | |recv
| |No send | |recv |ASSIGN_RESPONSE
| v ERROR_REQUEST| |ERROR_ |
| +---------------+ | |RESPONSE |
| | Go to Assigned| | | |
| +---------------+ | | | 7th timeout/recv
Borella et al. Expires February 2000 [Page 24]
INTERNET-DRAFT Realm Specific IP: Protocol Specification August 1999
| recv | | | QUERY_RESPONSE or
| +---------------+ERROR_RESPONSE | v v ERROR_RESPONSE+-------------+
| | Assigned |-------------->+-------------+------------->| Assigned |
+>|De-registration| | Assigned | | Query |
| Pending |<--------------+-------------+<-------------| Pending |
+---------------+ send ^ | send +-------------+
^ | DE-REGISTER_REQUEST | | QUERY_REQUEST ^ |
| | | | | |
timeout/send 7th/timeout/recv | |send | |
DE-REGISTER_ ASSIGN_RESPONSE | |ASSIGN_REQUEST timeout/send
REQUEST or ERROR_RESPONSE| | QUERY_REQUEST
| |
| v
+----------+
| Assigned |
|Assignment|
| Pending |
+----------+
^ |
| |
timeout/send
ASSIGN_REQUEST
12. References
[RFC2663] P. Srisuresh and M. Holdrege, "IP Network Address
Translator (NAT) Terminology and Considerations," RFC 2663, Aug.
1999.
[RFC1918] Y. Rekhter, B. Moskowitz, D. Karrenberg, G. J. de Groot,
and E. Lear, "Address Allocation for Private Internets," RFC 1918,
Feb. 1996.
[RFC2119] S. Bradner, "Key words for use in RFCs to indicate
requirement levels," RFC 2119, Mar. 1997.
[RSIP-FRAME] J. Lo, M. Borella, and D. Grabelsky, "Realm Specific IP:
A Framework," Internet Draft <draft-ietf-nat-rsip-
framework-01.txt>, Apr. 1999 (work in progress).
[STEV94] W. R. Stevens, "TCP/IP Illustrated, Vol. 1," Addison-Wesley,
1994.
13. Authors' Addresses
Michael Borella
Borella et al. Expires February 2000 [Page 25]
INTERNET-DRAFT Realm Specific IP: Protocol Specification August 1999
3Com Corp.
1800 W. Central Rd.
Mount Prospect IL 60056
(847) 342-6093
mike_borella@3com.com
David Grabelsky
3Com Corp.
1800 W. Central Rd.
Mount Prospect IL 60056
(847) 222-2483
david_grabelsky@3com.com
Jeffrey Lo
NEC USA
C&C Research Labs.
110 Rio Robles
San Jose, CA 95134
(408) 943-3033
jlo@ccrl.sj.nec.com
Kunihiro Taniguchi
NEC USA
C&C Research Labs.
110 Rio Robles
San Jose, CA 95134
(408) 943-3031
taniguti@ccrl.sj.nec.com
Copyright (c) The Internet Society (1999). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
Borella et al. Expires February 2000 [Page 26]
INTERNET-DRAFT Realm Specific IP: Protocol Specification August 1999
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Borella et al. Expires February 2000 [Page 27]
