INTERNET DRAFT M. Borella
Expires June 2000 D. Grabelsky
3Com Corp.
J. Lo
K. Tuniguchi
NEC USA
January 2000
Realm Specific IP: Protocol Specification
<draft-ietf-nat-rsip-protocol-05.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 document presents a protocol with which to implement Realm
Specific IP (RSIP). The protocol defined herein allows negotiation
of resources between an RSIP client and server, so that the client
can lease some of the server's addressing parameters in order to
establish a global network presence. This protocol is designed to
operate on the application layer and to use its own TCP or UDP port.
In particular, the protocol allows a server to allocate addressing
and control parameters to a client such that a flow policy can be
enforced at the server.
1. Introduction
Borella et al. Expires July 2000 [Page 1]
INTERNET-DRAFT Realm Specific IP: Protocol Specification January 2000
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 and IP addresses in
packets that traverse the NAT.
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 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. Thus, RSIP [RSIP-FRAME] has been defined a method for
address sharing that exhibits more transparency than NAT. In
particular, 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.
An RSIP client is a 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 directly
accessible from RSIP client, but this system allows packets to
maintain their integrity from RSIP client to their destination. ALGs
are not required in the RSIP server.
RSIP requires that hosts be modified so that they 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
client from an RSIP server. The requirements, scope, and
applicability of RSIP, as well as its interaction with other layer 3
protocols, are discussed in a companion framework draft [RSIP-FRAME].
Extensions to this protocol that enable end-to-end IPSEC are
discussed in [RSIP-IPSEC].
2. Specification of Requirements
The keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT",
Borella et al. Expires July 2000 [Page 2]
INTERNET-DRAFT Realm Specific IP: Protocol Specification January 2000
"SHALL", "SHALL NOT", "MAY" and "MAY NOT" that appear in this
document are to be interpreted as described in [RFC2119].
3. Terminology
Private Realm
A routing realm that uses private IP addresses from the ranges
(10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) specified in
[RFC1918], or addresses that are non-routable from the Internet.
Public Realm
A routing realm with unique network addresses assigned by the
Internet Assigned Number Authority (IANA) or an equivalent address
registry.
RSIP Server
A router situated on the boundary between a private realm and a
public realm and owns one or more public IP addresses. An RSIP
server is responsible for public parameter management and
assignment to RSIP clients. An RSIP server may act as a normal NAT
router for hosts within the private realm that are not RSIP
enabled.
RSIP Client
A host within the private realm that acquires publicly unique
parameters from an RSIP server through the use of RSIP.
RSA-IP: Realm Specific Address IP
An RSIP method in which each RSIP client is allocated a unique IP
address from the public realm. Discussed in detail in [RFC2663]
RSAP-IP: Realm Specific Address and Port IP
An RSIP method in which each RSIP client is allocated an IP
address (possibly shared with other RSIP clients) and some number
of per-address unique ports from the public realm. Discussed in
detail in [RFC2663]
Binding
An association of some combination of a local address, one or more
local ports, a remote address, and a remote port with an RSIP
client.
Borella et al. Expires July 2000 [Page 3]
INTERNET-DRAFT Realm Specific IP: Protocol Specification January 2000
Resource
A general way to refer to an item that an RSIP client leases from
an RSIP server; e.g., an address or port.
All other terminology found in this document is consistent with that
of [RFC2663] and [RSIP-FRAME].
4. Architecture
For simplicity, in 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. (This assumption is made without
loss of generality and the ensuing discussion applies to more general
cases.) 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.
RSIP Client RSIP Server Host
Xa Na Nb Yb
[X]------( Addr sp. A )----[N]-----( Addr sp. B )-------[Y]
( Network ) ( Network )
Hosts X and Y belong to different addressing realms A and B,
respectively, and N is an RSIP server (which may also perform NAT
functions). N has two interfaces: Na on address space A, and Nb on
address space B. N may have a pool of addresses in address space B
which it can assign to or lend to X and other hosts in address space
A. These addresses are not shown above, but they can be denoted as
Nb1, Nb2, Nb3 and so on.
Host X, needing to establish an end-to-end connection to a network
entity Y situated within address space B, first negotiates and
obtains assignment of the resources from the RSIP server. Upon
assignment of these parameters, the RSIP server creates a mapping, of
X's addressing information and the assigned resources. This binding
enables the RSIP server to correctly de-multiplex and forward inbound
traffic generated by Y for X. A lease time is associated with each
bind.
Using the public parameters assigned by the RSIP server, RSIP clients
tunnel data packets across address space A to the RSIP server. The
RSIP server acts as the end point of such tunnels, stripping off the
Borella et al. Expires July 2000 [Page 4]
INTERNET-DRAFT Realm Specific IP: Protocol Specification January 2000
outer headers and routing the inner packets onto the public realm. As
mentioned above, an RSIP server maintains a mapping of the assigned
public parameters as demultiplexing fields for uniquely mapping them
to RSIP client private addresses. When a packet from the public
realm arrives at the RSIP server and it matches a given set of
demultiplexing fields, then the RSIP server will tunnel it to the
appropriate RSIP client. The tunnel headers of outbound packets from
X to Y, given that X has been assigned Nb, are as follows:
+---------+---------+---------+
| X -> Na | Nb -> Y | payload |
+---------+---------+---------+
There are two basic flavors of RSIP: RSA-IP and RSAP-IP. RSIP
clients and servers MUST support RSAP-IP and MAY support RSA-IP.
Details of RSA-IP and RSAP-IP are found in [RSIP-FRAME].
5. Transport Protocol
RSIP is an application layer protocol that requires the use of a
transport layer protocol for end-to-end delivery of packets.
RSIP servers MUST support TCP, and SHOULD support UDP. Due to the
fact that RSIP may be deployed across a wide variety of network
links, RSIP clients SHOULD support TCP. However, RSIP clients MAY
support UDP instead. For RSIP clients and servers using UDP, timeout
and retransmissions MUST occur. We recommend a binary exponential
backoff scheme with an initial duration of 12.5 ms, and a maximum of
six retries (seven total attempts before failure).
Once a client and server have established a registration using either
TCP or UDP, they may not switch between the two protocols for the
duration of the registration.
6. Client / Server Relationships
An RSIP client can be in exactly one of three fundamental
relationships with respect to an RSIP server:
Unregistered: The RSIP server does not know of the RSIP client's
existence, and it will not forward or deliver packets globally
addressed on behalf of the client. The only valid RSIP-related
action for a client to perform in this state is to request
registration with an RSIP server.
Registered: The RSIP server knows of the RSIP client and has
assigned it a client ID and has specified the flow policies
that it requires of the client. However, no resources, such as
Borella et al. Expires July 2000 [Page 5]
INTERNET-DRAFT Realm Specific IP: Protocol Specification January 2000
addresses or ports, have been allocated to the client, and the
server will not forward or deliver globally addressed packets
on behalf of the client.
Assigned: The RSIP server has granted one or more bindings of
resources to the client. The server will forward and deliver
globally addressed packets on behalf of the client.
Architectures in which an RSIP client is simultaneously registered
with more than one RSIP server are possible. In such cases, an RSIP
client may be in different relationships with different RSIP servers
at the same time.
7. Server Flow Policy and State
Since an RSIP server is likely to reside on the boundary between two
or more different administrative domains, it is desirable to enable
an RSIP server to be able to enforce flow-based policy. In other
words, an RSIP server should have the ability to explicitly control
which local addresses and ports are used to communicate with remote
addresses and ports.
In the following, macro-flow policy refers to controlling flow policy
at the granularity level of IP addresses, while micro-flow policy
refers to controlling flow policy at the granularity of IP address
and port tuples. Of course there may be no policy at all, which
indicates that the RSIP server does not care about the flow
parameters used by RSIP clients. We consider two levels of local flow
policy and three levels of remote flow policy.
7.1. Local Flow Policy
Local flow policy determines the granularity of control that an
RSIP server has over the local addressing parameters that an RSIP
client uses for particular sessions.
Since an RSIP client must use at least an IP address allocated by
the server, the loosest level of local flow policy is macro-flow
based. Under local macro-flow policy, an RSIP client is allocated
an IP address (RSA-IP) or an IP address and one or more ports to
use with it (RSAP-IP). However, the client may use the ports as
it desires for establishing sessions with public hosts.
Under micro-flow policy, a client is allocated exactly one port at
a time. The client may request more ports, also one at a time.
This policy gives the server very tight control over local port
use, although it affords the client less flexibility.
Borella et al. Expires July 2000 [Page 6]
INTERNET-DRAFT Realm Specific IP: Protocol Specification January 2000
Note that only local macro-flow policy can be used with RSA-IP,
while either local macro-flow or local micro-flow policy may be
used with RSAP-IP.
Examples of how RSIP flow policy operates are given in Appendix C.
7.2. Remote Flow Policy
Remote flow policy determines the granularity of control that an
RSIP server has over the remote (public) hosts with which an RSIP
client communicates. In particular, remote flow policy dictates
what level of detail that a client must specify addressing
parameters of a remote host or application before the RSIP server
allows the client to communicate with that host or application.
The simplest and loosest form of flow policy is no policy at all.
In other words, the RSIP server allocates addressing parameters to
the client, and the client may use these parameters to communicate
with any remote host, without explicitly notifying the server.
Macro-flow policy requires that the client identify the remote
address of the host that it wishes to communicate with as part of
its request for local addressing parameters. If the request is
granted, the client MUST use the specified local parameters only
with the remote address specified, and MUST NOT communicate with
the remote address using any local parameters but the ones
allocated. However, the client may contact any port number at the
remote host without explicitly notifying the server.
Micro-flow policy requires that the client identify the remote
address and port of the host that it wishes to communicate with as
part of its request for local addressing parameters. If the
request is granted, the client MUST use the specified local
parameters only with the remote address and port specified, and
MUST NOT communicate with the remote address and port using any
local parameters but the ones allocated.
Remote flow policy is implemented in both the ingress and egress
directions, with respect to the location of the RSIP server.
7.3. Server State
An RSIP server must maintain state for all RSIP clients and their
assigned resources. The amount and type of state maintained
depends on the local and remote flow policy. The required RSIP
server state will vary based on the RSIP method, but will always
include the chosen method's demultiplexing parameters.
Borella et al. Expires July 2000 [Page 7]
INTERNET-DRAFT Realm Specific IP: Protocol Specification January 2000
7.3.1. RSA-IP State
An RSIP server serving an RSIP client using the RSA-IP method
MUST maintain the following minimum state to ensure proper
mapping of incoming packets to RSIP clients:
- Client's private address
- Client's assigned public address(es)
7.3.2. RSAP-IP State
An RSIP server serving an RSIP client using the RSAP-IP method
MUST maintain the following minimum state to ensure proper
mapping of incoming packets to RSIP clients:
- Client's private address
- Client's assigned public address(es)
- Client's assigned port(s) per address
7.3.3. Flow State
Regardless of whether the server is using RSA-IP or RSAP-IP,
additional state is necessary if either micro-flow based or
macro-flow based remote policy is used.
If the server is using macro-flow based remote policy, the
following state must be maintained:
- Remote host's address
If the server is using micro-flow based remote policy, the
following state must be maintained:
- Remote host's address
- Remote host's port
More state MAY be used by an RSIP server if desired. For
example, ToS/DS bytes may be recorded in order to facilitate
quality of service support.
8. Parameter Specification and Formats
In this section we define the formats for RSIP parameters. Each RSIP
message contains one or more parameters that encode the information
passed between the client and server. The general format of all
parameters consists of a 1-byte code followed by a 2-byte length as
shown below.
Borella et al. Expires July 2000 [Page 8]
INTERNET-DRAFT Realm Specific IP: Protocol Specification January 2000
1 byte 2 bytes 'Length' bytes
+------+----------+--------------
| Code | Length | ...
+------+----------+--------------
The length field determines the length, in bytes, of the rest of the
parameter, such that the total length of a parameter is the value of
the length field plus 3.
8.1. Address
Code Length Type Value
+-------+---------+--------+--------+
| 1 | 2 bytes | 1 byte | varies |
+-------+---------+--------+--------+
The address parameter contains addressing information, either an
IPv4 address or netmask, an IPv6 address or netmask, or a fully
qualified domain name (FQDN). The type field is 1 byte in length,
indicating the type of address.
Defined types are:
Type Length of value field (in bytes)
---- --------------------------------
0 Reserved 0
1 IPv4 4
2 IPv4 netmask 4
3 IPv6 16
4 IPv6 netmask 16
5 FQDN varies
For FQDN, the length of the value field will be one less than the
value of the length field.
In some cases, it is necessary to specify a "don't care" value for
an address. This is signified by a setting the length field to 1
and omitting the value field.
It is not valid for a client to request an address with an FQDN
type as its local address (See specification of
ASSIGN_REQUEST_RSA-IP and ASSIGN_REQUEST_RSAP-IP, below).
8.2. Ports
Borella et al. Expires July 2000 [Page 9]
INTERNET-DRAFT Realm Specific IP: Protocol Specification January 2000
Code Length Number Port Port
+-------+---------+--------+---------+ +---------+
| 2 | 2 bytes | 1 byte | 2 bytes | ... | 2 bytes |
+-------+---------+--------+---------+ +---------+
The ports parameter encodes one or more TCP or UDP ports. When a
single port is specified, the value of the number field is 1 and
there is one port field following the number field. When more
than one port is specified, the value of the number field will
indicate the total number of ports contained, and the parameter
may take one of two forms. If there is one port field, the ports
specified are considered to be contiguous starting at the port
number specified in the port field. Alternatively, there may be a
number of port fields equal to the value of the number field. The
number of port fields can be extrapolated from the length field.
In some cases, it is necessary to specify a don't care value for
one or more ports. This is accomplished by setting the length
field to 1, setting the number field to the number of ports
necessary, and omitting all port fields. The value of the number
field MUST be greater than or equal to one.
If micro-flow based policy applies to a given ports parameter, it
MUST contain exactly one port field.
This parameter is not used with RSA-IP.
8.3. Lease Time
Code Length Value
+-------+--------+---------+
| 3 | 4 | 4 bytes |
+-------+--------+---------+
The lease time parameter specifies the length, in seconds, of an
RSIP client parameter binding.
8.4. Client ID
Code Length Value
+-------+--------+---------+
| 4 | 4 | 4 bytes |
+-------+--------+---------+
The client ID parameter specifies an RSIP client ID.
8.5. Bind ID
Borella et al. Expires July 2000 [Page 10]
INTERNET-DRAFT Realm Specific IP: Protocol Specification January 2000
Code Length Value
+-------+--------+---------+
| 5 | 4 | 4 bytes |
+-------+--------+---------+
The bind ID parameter specifies an RSIP bind ID.
8.6. Tunnel Type
Code Length Value
+-------+--------+--------+
| 6 | 1 | 1 byte |
+-------+--------+--------+
The tunnel type parameter specifies the type of tunnel used
between an RSIP client and an RSIP server. Defined tunnel types
are:
Tunnel Type
-----------
0 Reserved
1 IP-IP
2 GRE
3 L2TP
8.7. RSIP Method
Code Length Value
+-------+--------+--------+
| 7 | 1 | 1 byte |
+-------+--------+--------+
The RSIP method parameter specifies an RSIP method. Defined RSIP
methods are:
RSIP method
-----------
0 Reserved
1 RSA-IP
2 RSAP-IP
8.8. Error
Code Length Value
+-------+--------+---------+
| 8 | 2 | 2 bytes |
+-------+--------+---------+
Borella et al. Expires July 2000 [Page 11]
INTERNET-DRAFT Realm Specific IP: Protocol Specification January 2000
The error parameter specifies an error. The currently defined
error values are presented in Appendix A.
8.9. Flow Policy
Code Length Local Remote
+-------+--------+--------+--------+
| 9 | 2 | 1 byte | 1 byte |
+-------+--------+--------+--------+
The flow policy parameter specifies both the local and remote flow
policy.
Defined local flow policies are:
Local Flow Policy
-----------------
0 Reserved
1 Macro flows
2 Micro flows
Defined remote flow policies are:
Remote Flow Policy
------------------
0 Reserved
1 Macro flows
2 Micro flows
3 No policy
8.10. Indicator
Code Length Value
+-------+---------+--------+
| 10 | 2 bytes | varies |
+-------+---------+--------+
An indicator parameter is a general-purpose parameter, the use of
which is defined by the message that is appears in. An RSIP
message that uses an indicator parameter MUST define the meaning
and interpretation of all of the indicator's possible values.
8.11. Vendor Specific Parameter
Borella et al. Expires July 2000 [Page 12]
INTERNET-DRAFT Realm Specific IP: Protocol Specification January 2000
Code Length Vendor ID Subcode Value
+-------+---------+-----------+---------+--------+
| 240 | 2 bytes | 2 bytes | 2 bytes | varies |
+-------+---------+-----------+---------+--------+
The vendor specific parameter is used to encode parameters that
are defined by a particular vendor. The vendor ID field is the
vendor-specific ID assigned by IANA. Subcodes are defined and
used by each vendor as necessary. An RSIP client or server SHOULD
silently ignore vendor-specific messages that it does not
understand.
9. Message Types
RSIP messages consist of three mandatory fields, version, message
type, and overall length, followed by one or more required
parameters, followed in turn by zero or more optional parameters. In
an RSIP message, all required parameters MUST appear in the exact
order specified below. Optional parameters MAY appear in any order.
The version number field is a single byte and specifies the RSIP
version number that is being used. The current RSIP version number
is 1.
The message type field is a single byte and specifies the message
contained in the current packet. There may be only one message per
packet. Message types given numerical assignments in Appendix B.
The overall length field is two bytes and contains the number of
bytes in the RSIP message, including the three mandatory fields.
Most parameters are only allowed to appear once in each message. The
exceptions are as follows:
- Multiple address parameters MUST appear in ASSIGN_REQUEST_RSA-IP,
ASSIGN_RESPONSE_RSA-IP, ASSIGN_REQUEST_RSAP-IP,
ASSIGN_RESPONSE_RSAP-IP, LISTEN_REQUEST and LISTEN_RESPONSE.
- Multiple ports parameters MUST appear in ASSIGN_REQUEST_RSAP-IP,
ASSIGN_RESPONSE_RSAP-IP, LISTEN_REQUEST and LISTEN_RESPONSE.
- Multiple RSIP method and tunnel type parameters MAY appear in
RESISTER_RESPONSE.
- Multiple address parameters and multiple indicator parameters MAY
appear in QUERY_REQUEST and QUERY_RESPONSE.
The following message types are defined in simple BNF. Required
Borella et al. Expires July 2000 [Page 13]
INTERNET-DRAFT Realm Specific IP: Protocol Specification January 2000
parameters are enclosed in <> and MUST appear. Optional parameters
are enclosed in [] and MAY appear. 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, or may only support RSAP-IP and not RSA-IP.
9.1. ERROR_RESPONSE
9.1.1. Description
An ERROR_RESPONSE is used to provide error messages from an
RSIP server to an RSIP client. Usually, errors indicate that
the RSIP server cannot or will not perform an action or
allocate resources on behalf of the client. If the error is
related to a particular client ID or bind ID, these associated
parameters MUST be included. Multiple errors MAY NOT be
reported in the same ERROR_RESPONSE. In situations where which
more than one error has occurred, the RSIP server MUST choose
only one error to report.
9.1.2. Format
<ERROR_RESPONSE> ::= <Version>
<Message Type>
<Overall Length>
<Error>
[Client ID]
[Bind ID]
9.1.3. Behavior
An ERROR_RESPONSE message MUST only be transmitted by an RSIP
server. An RSIP client that detects an error in a message
received from an RSIP server MUST silently discard the message.
There are no error conditions that can be caused by an
ERROR_RESPONSE. An ERROR_RESPONSE is typically transmitted in
response to a request from an RSIP client.
9.2. REGISTER_REQUEST
9.2.1. Description
The REGISTER_REQUEST message is used by an RSIP client to
establish registration with an RSIP server. An RSIP client
MUST register before it requests resources or services from an
RSIP server. Once an RSIP client has registered with an RSIP
server, it may not register again until it has de-registered
from that server.
Borella et al. Expires July 2000 [Page 14]
INTERNET-DRAFT Realm Specific IP: Protocol Specification January 2000
9.2.2. Format
<REGISTER_REQUEST> ::= <Version>
<Message Type>
<Overall Length>
9.2.3. Behavior
The following message-specific error conditions exist:
- If the client is already registered with the server, the
server MUST respond with an ERROR_RESPONSE containing the
ALREADY_REGISTERED error.
- If the server's policy will not allow the client to register,
the server MUST respond with an ERROR_RESPONSE containing the
REGISTRATION_DENIED error.
9.3. REGISTER_RESPONSE
9.3.1. Description
The REGISTER_RESPONSE message is used by an RSIP server to
confirm the registration of an RSIP client, and to provide a
client ID, flow policy, and possibly an RSIP method and tunnel
type.
9.3.2. Format
<REGISTER_RESPONSE> ::= <Version>
<Message Type>
<Overall Length>
<Client ID>
<Flow Policy>
[RSIP Method]...
[Tunnel Type]...
9.3.3. Behavior
An RSIP server MUST assign a different client ID to each client
that is simultaneously registered with it. The RSIP server MAY
respond with one or more RSIP methods and tunnel types that it
supports. If an RSIP method is not specified, RSAP-IP MUST be
assumed. If a tunnel type is not specified, IP-IP MUST be
assumed.
9.4. DE-REGISTER_REQUEST
Borella et al. Expires July 2000 [Page 15]
INTERNET-DRAFT Realm Specific IP: Protocol Specification January 2000
9.4.1. Description
The DE-REGISTER_REQUEST message is used by an RSIP client to
de-register with an RSIP server. If a client de-registers from
the assigned state, all of the client's bindings are revoked.
The client SHOULD NOT de-register from the unregistered state.
9.4.2. Format
<DE-REGISTER_REQUEST> ::= <Version>
<Message Type>
<Overall Length>
<Client ID>
9.4.3. Behavior
The following message-specific error conditions exist:
- If the client is not registered with the server, the server
MUST respond with an ERROR_RESPONSE containing the
REGISTER_FIRST error.
- If the message contains an incorrect client ID, the server
MUST respond with an ERROR_RESPONSE containing the
BAD_CLIENT_ID error.
If there are no errors that result from this message, the
server MUST respond with an appropriate DE-REGISTER_RESPONSE.
Upon de-registering a client, an RSIP server must delete all
binds associated with that client and return their resources to
the pool of free resources. Once a client has de-registered,
it may not use any of the RSIP server's resources without
registering again.
9.5. DE-REGISTER_RESPONSE
9.5.1. Description
The DE-REGISTER_RESPONSE message is used by an RSIP server to
confirm the de-registration of an RSIP client or to force an
RSIP client to relinquish all of its bindings and terminate its
relationship with the RSIP server. Upon receiving a DE-
REGISTER_RESPONSE message, an RSIP client MUST stop all use of
the resources that have been allocated to it by the server.
Borella et al. Expires July 2000 [Page 16]
INTERNET-DRAFT Realm Specific IP: Protocol Specification January 2000
9.5.2. Format
<DE-REGISTER_RESPONSE> ::= <Version>
<Message Type>
<Overall Length>
<Client ID>
9.5.3. Behavior
An RSIP server MUST send a DE-REGISTER_RESPONSE in response to
a valid DE-REGISTER_REQUEST. An RSIP server SHOULD send a DE-
REGISTER_RESPONSE if it detects that it will no longer be able
to perform RSIP functionality for a given client. An RSIP
client MUST be ready to accept a DE-REGISTER_RESPONSE at any
moment.
9.6. ASSIGN_REQUEST_RSA-IP
9.6.1. Description
The ASSIGN_REQUEST_RSA-IP message is used by an RSIP client to
request resources to use with RSA-IP. Note that RSA-IP cannot
be used in combination with micro-flow based local policy.
9.6.2. Format
<ASSIGN_REQUEST_RSA-IP> ::= <Version>
<Message Type>
<Overall Length>
<Client ID>
<Address (local)>
<Address (remote)>
<Ports (remote)>
[Lease Time]
[Tunnel Type]
9.6.3. Behavior
The RSIP client specifies two address parameters. The RSIP
client may request a particular local address by placing that
address in the first address parameter. To indicate that it
has no preference for local address, the RSIP client may place
a "don't care" value of all zeros in the address parameter.
If macro-flow based remote policy is used, the client MUST
specify the remote address that it will use this binding (if
granted) to contact; however, the remote port number MAY remain
Borella et al. Expires July 2000 [Page 17]
INTERNET-DRAFT Realm Specific IP: Protocol Specification January 2000
unspecified. If micro-flow based remote policy is used, the
client MUST specify the remote address and port number that it
will use this binding (if granted) to contact. If no flow
policy is used, the RSIP client may place a "don't care" value
of all zeros in the value fields of the respective address and
ports parameters.
The following message-specific error conditions exist:
- If the client is not registered with the server, the server
MUST respond with an ERROR_RESPONSE containing the
REGISTER_FIRST error.
- If the message contains an incorrect client ID, the server
MUST respond with an ERROR_RESPONSE containing the
BAD_CLIENT_ID error.
- If the local address parameter is a don't care value and the
RSIP server cannot allocate ANY addresses, the RSIP server
MUST respond with an ERROR_RESPONSE containing the
LOCAL_ADDR_UNAVAILABLE error.
- If the local address parameter is not a don't care value
there are three possible error conditions:
o If the RSIP server cannot allocate ANY addresses, it MUST
respond with an ERROR_RESPONSE containing the
LOCAL_ADDR_UNAVAILABLE error.
o If the RSIP server cannot allocate the requested address
because it is in use, the RSIP server MUST respond with an
ERROR_RESPONSE containing the LOCAL_ADDR_INUSE error.
o If the RSIP server cannot allocate the requested address
because it is not allowed by policy, the RSIP server MUST
respond with an ERROR_RESPONSE containing the
LOCAL_ADDR_UNALLOWED error.
- If macro-flow based remote policy is used and the requested
remote address is not allowed by the RSIP server's policy,
the RSIP server MUST respond with an ERROR_RESPONSE
containing the REMOTE_ADDR_UNALLOWED error.
- If micro-flow based remote policy is used and the requested
remote address / port pair is not allowed by the RSIP
server's policy, the RSIP server MUST respond with an
ERROR_RESPONSE containing the REMOTE_ADDRPORT_UNALLOWED
error.
Borella et al. Expires July 2000 [Page 18]
INTERNET-DRAFT Realm Specific IP: Protocol Specification January 2000
- If an unsupported or unallowed tunnel type is specified, the
RSIP server MUST respond with an ERROR_RESPONSE containing
the BAD_TUNNEL_TYPE error.
- If the client has not specified local or remote address or
port information in enough detail, the RSIP server MUST
respond with an ERROR_RESPONSE containing the
FLOW_POLICY_VIOLATION error.
9.7. ASSIGN_RESPONSE_RSA-IP
9.7.1. Description
The ASSIGN_RESPONSE_RSA-IP message is used by an RSIP server to
deliver parameter assignments to an RSIP client using RSA-IP.
A client-wise unique bind ID, lease time, and tunnel type must
be provided for every assignment.
9.7.2. Format
<ASSIGN_RESPONSE_RSA-IP> ::= <Version>
<Message Type>
<Overall Length>
<Client ID>
<Bind ID>
<Address (local)>
<Address (remote)>
<Ports (remote)>
<Lease Time>
<Tunnel Type>
9.7.3. Behavior
If no remote flow policy is used, the RSIP server MUST use
"don't care" values for the remote address and ports
parameters. If macro-flow based remote policy is used, the
remote address parameter MUST contain the address specified in
the associated request, and the remote ports parameter MUST
contain a "don't care" value. If micro-flow based remote
policy is used, the remote address and remote ports parameters
MUST contain the address and port information specified in the
associated request.
If the client detects an error or otherwise does not
"understand" the server's response, it SHOULD send a
FREE_REQUEST with the bind ID from the said
ASSIGN_RESPONSE_RSA-IP. This will serve to help synchronize
Borella et al. Expires July 2000 [Page 19]
INTERNET-DRAFT Realm Specific IP: Protocol Specification January 2000
the states of the client and server.
9.8. ASSIGN_REQUEST_RSAP-IP
9.8.1. Description
The ASSIGN_REQUEST_RSAP-IP message is used by an RSIP client to
request resources to use with RSAP-IP. The RSIP client
specifies two address and two port parameters, the first of
each, respectively, refer to the local address and port(s) that
will be used, and the second of each, respectively, refer to
the remote address and port(s) that will be contacted.
9.8.2. Format
<ASSIGN_REQUEST_RSAP-IP> ::= <Version>
<Message Type>
<Overall Length>
<Client ID>
<Address (local)>
<Ports (local)>
<Address (remote)>
<Ports (remote)>
[Lease Time]
[Tunnel Type]
9.8.3. Behavior
An RSIP client may request a particular local address by
placing that address in the value field of the first address
parameter. The RSIP client may request particular local ports
by placing them in the first port parameter. To indicate that
it has no preference for local address or ports, the RSIP
client may place a "don't care" value of zeros in the
respective address or ports parameters.
If macro-flow based remote policy is used, the client MUST
specify the remote address that it will use this binding (if
granted) to contact; however, the remote port number(s) MAY
remain unspecified. If micro-flow based remote policy is used,
the client MUST specify the remote address and port number(s)
that it will use this binding (if granted) to contact. If no
flow policy is used, the RSIP client may place a value of all
0's in the value fields of the respective address or port
parameters.
The following message-specific error conditions exist:
Borella et al. Expires July 2000 [Page 20]
INTERNET-DRAFT Realm Specific IP: Protocol Specification January 2000
- If the client is not registered with the server, the server
MUST respond with an ERROR_RESPONSE containing the
REGISTER_FIRST error.
- If the message contains an incorrect client ID, the server
MUST respond with an ERROR_RESPONSE containing the
BAD_CLIENT_ID error.
- If the local address parameter is a don't care value and the
RSIP server cannot allocate ANY addresses, the RSIP server
MUST respond with an ERROR_RESPONSE containing the
LOCAL_ADDR_UNAVAILABLE error.
- If the local address parameter is not a don't care value
there are six possible error conditions:
o If the RSIP server cannot allocate ANY addresses, it MUST
respond with an ERROR_RESPONSE containing the
LOCAL_ADDR_UNAVAILABLE error.
o If the RSIP server cannot allocate the requested address
because it is in use, the RSIP server MUST respond with an
ERROR_RESPONSE containing the LOCAL_ADDR_INUSE error.
o If the RSIP server cannot allocate the requested address
because it is not allowed by policy, the RSIP server MUST
respond with an ERROR_RESPONSE containing the
LOCAL_ADDR_UNALLOWED error.
o If the RSIP server cannot allocate the requested address /
port tuple because it is in use, the RSIP server MUST
respond with an ERROR_RESPONSE containing the
LOCAL_ADDRPORT_INUSE error.
o If the RSIP server cannot allocate the requested address /
port tuple because it is not allowed by policy, the RSIP
server MUST respond with an ERROR_RESPONSE containing the
LOCAL_ADDRPORT_UNALLOWED error.
- If macro-flow based remote policy is used and the requested
remote address is not allowed by the RSIP server's policy,
the RSIP server MUST respond with an ERROR_RESPONSE
containing the REMOTE_ADDR_UNALLOWED error.
- If micro-flow based remote policy is used and the requested
remote address / port pair is not allowed by the RSIP
server's policy, the RSIP server MUST respond with an
ERROR_RESPONSE containing the REMOTE_ADDRPORT_UNALLOWED
Borella et al. Expires July 2000 [Page 21]
INTERNET-DRAFT Realm Specific IP: Protocol Specification January 2000
error.
- If an unsupported or unallowed tunnel type is specified, the
RSIP server MUST respond with an ERROR_RESPONSE containing
the BAD_TUNNEL_TYPE error.
- If the client has not specified local or remote address or
port information in enough detail, the RSIP server MUST
respond with an ERROR_RESPONSE containing the
FLOW_POLICY_VIOLATION error.
9.9. ASSIGN_RESPONSE_RSAP-IP
9.9.1. Description
The ASSIGN_RESPONSE_RSAP-IP message is used by an RSIP server
to deliver parameter assignments to an RSIP client. A client-
wise unique bind ID, lease time, and tunnel type must be
provided for every assignment.
9.9.2. Format
<ASSIGN_RESPONSE_RSAP-IP> ::= <Version>
<Message Type>
<Overall Length>
<Client ID>
<Bind ID>
<Address (local)>
<Ports (local)>
<Address (remote)>
<Ports (remote)>
<Lease Time>
<Tunnel Type>
9.9.3. Behavior
Regardless of local flow policy, a local address and port(s)
MUST be assigned to the client. If macro-flow based local
policy is used, the client is assigned an address and one or
more ports. If micro-flow based local policy is used, the
client is assigned an address and exactly one port.
If no remote flow policy is used, the RSIP server MUST use
"don't care" values for the remote address and ports
parameters. If macro-flow based remote policy is used, the
remote address parameter MUST contain the address specified in
the associated request, and the remote ports parameter must
contain a "don't care" value. If micro-flow based remote
Borella et al. Expires July 2000 [Page 22]
INTERNET-DRAFT Realm Specific IP: Protocol Specification January 2000
policy is used, the remote address and remote ports parameters
MUST contain the address and port information specified in the
associated request.
If the client detects an error or otherwise does not
"understand" the server's response, it SHOULD send a
FREE_REQUEST with the bind ID from the said
ASSIGN_RESPONSE_RSAP-IP. This will serve to help synchronize
the states of the client and server.
9.10. EXTEND_REQUEST
9.10.1. Description
The EXTEND_REQUEST message is used to request a lease extension
to a current bind. It may be used with both RSA-IP and RSAP-
IP. The client MUST specify its client ID and the bind ID in
question, and it MAY suggest a lease time to the server.
9.10.2. Format
<EXTEND_REQUEST> ::= <Version>
<Message Type>
<Overall Length>
<Client ID>
<Bind ID>
[Lease Time]
9.10.3. Behavior
The following message-specific error conditions exist:
- If the client is not registered with the server, the server
MUST respond with an ERROR_RESPONSE containing the
REGISTER_FIRST error.
- If the message contains an incorrect client ID, the server
MUST respond with an ERROR_RESPONSE containing the
BAD_CLIENT_ID error.
- If the message contains an incorrect bind ID, the server MUST
respond with an ERROR_RESPONSE containing the BAD_BIND_ID
error.
If the RSIP server grants an extension to the client's lease,
it MUST RESPOND with an appropriate EXTEND_RESPONSE message.
If the lease is not renewed, the RSIP server MAY let it
implicitly expire by doing nothing or make it explicitly expire
Borella et al. Expires July 2000 [Page 23]
INTERNET-DRAFT Realm Specific IP: Protocol Specification January 2000
by sending an appropriate FREE_RESPONSE message.
9.11. EXTEND_RESPONSE
9.11.1. Description
The EXTEND_RESPONSE message is used by an RSIP server to grant
a requested lease extension. The server MUST specify the
client ID of the client, the bind ID in question, and the new
assigned lease time.
9.11.2. Format
<EXTEND_RESPONSE> ::= <Version>
<Message Type>
<Overall Length>
<Client ID>
<Bind ID>
<Lease Time>
9.11.3. Behavior
The RSIP server will determine lease time as per its local
policy.
9.12. FREE_REQUEST
9.12.1. Description
The FREE_REQUEST message is used by an RSIP client to free a
binding. The given bind ID identifies the bind to be freed.
Resources may only be freed using the granularity of a bind ID.
9.12.2. Format
<FREE_REQUEST> ::= <Version>
<Message Type>
<Overall Length>
<Client ID>
<Bind ID>
9.12.3. Behavior
The following message-specific error conditions exist:
- If the client is not registered with the server, the server
MUST respond with an ERROR_RESPONSE containing the
REGISTER_FIRST error.
Borella et al. Expires July 2000 [Page 24]
INTERNET-DRAFT Realm Specific IP: Protocol Specification January 2000
- If the message contains an incorrect client ID, the server
MUST respond with an ERROR_RESPONSE containing the
BAD_CLIENT_ID error.
- If the message contains an incorrect bind ID, the server MUST
respond with an ERROR_RESPONSE containing the BAD_BIND_ID
error.
If a client receives an error in response to a FREE_REQUEST,
this may indicate that the client and server's states have
become unsynchronized. Therefore, the client SHOULD make an
effort to resynchronize, such as freeing resources then re-
requesting them, or de-registering then re-registering.
9.13. FREE_RESPONSE
9.13.1. Description
The FREE_RESPONSE message is used by an RSIP server to
acknowledge a FREE_REQUEST sent by an RSIP client, and to
asynchronously deallocate resources granted to an RSIP client..
9.13.2. Format
<FREE_RESPONSE> ::= <Version>
<Message Type>
<Overall Length>
<Client ID>
<Bind ID>
9.13.3. Behavior
An RSIP client must always be ready to accept a FREE_RESPONSE,
even if its lease on the specified bind ID is not yet expired.
9.14. QUERY_REQUEST
9.14.1. Description
A QUERY_REQUEST message is used by an RSIP client to ask an
RSIP server whether or not a particular address or network is
local or remote. The client uses this information to determine
whether to contact the host(s) directly (in the local case), or
via RSIP (in the remote case).
This message defines an indicator parameter with a 1-byte value
field and 2 defined values:
Borella et al. Expires July 2000 [Page 25]
INTERNET-DRAFT Realm Specific IP: Protocol Specification January 2000
- 1 address
- 2 network
9.14.2. Format
<QUERY_REQUEST> ::= <Version>
<Message Type>
<Overall Length>
<Client ID>
[Address Tuple]...
[Network Tuple]...
where
<Address Tuple> ::= <Indicator (address)>
<Address>
<Network Tuple> ::= <Indicator (network)>
<Address (network)>
<Address (netmask)>
9.14.3. Behavior
One or more address or network tuples may be specified. Each
tuple encodes a request regarding the locality (local or
remote) of the encoded address or network. If no tuple is
specified, the RSIP server should interpret the message as a
request for all tuples that it is willing to provide. Note
that the FQDN form of the address parameter cannot be used to
specify the address of a network, and only the netmask form of
the address parameter can be used to specify the netmask of a
network.
If an RSIP server cannot determine whether a queried host or
network is local or remote, it SHOULD transmit a QUERY_RESPONSE
with no response specified for the said host or network.
The following message-specific error conditions exist:
- If the client is not registered with the server, the server
MUST respond with an ERROR_RESPONSE containing the
REGISTER_FIRST error.
- If the message contains an incorrect client ID, the server
MUST respond with an ERROR_RESPONSE containing the
BAD_CLIENT_ID error.
Borella et al. Expires July 2000 [Page 26]
INTERNET-DRAFT Realm Specific IP: Protocol Specification January 2000
9.15. QUERY_RESPONSE
9.15.1. Description
A QUERY_RESPONSE message is used by an RSIP server to answer a
QUERY_REQUEST from an RSIP client.
This message defines an indicator parameter with a 1-byte value
field and 4 defined values:
- 1 local address
- 2 local network
- 3 remote address
- 4 remote network
9.15.2. Format
<QUERY_RESPONSE> ::= <Version>
<Message Type>
<Overall Length>
<Client ID>
[Local Address Tuple]...
[Local Network Tuple]...
[Remote Address Tuple]...
[Remote Network Tuple]...
where
<Local Address Tuple> ::= <Indicator (local address)>
<Address>
<Local Network Tuple> ::= <Indicator (local network)>
<Address (network)>
<Address (netmask)>
<Remote Address Tuple> ::= <Indicator (remote address)>
<Address>
<Remote Network Tuple> ::= <Indicator (remote network)>
<Address (network)>
<Address (netmask)>
9.15.3. Behavior
An RSIP server has some leeway in how it responds to a
QUERY_REQUEST. It may just provide the information requested,
if it can provide such information. It may provide its
complete list of address and networks, in order to minimize the
Borella et al. Expires July 2000 [Page 27]
INTERNET-DRAFT Realm Specific IP: Protocol Specification January 2000
number of requests that the client needs to perform in the
future. How an RSIP server responds may depend of network
traffic considerations as well.
If an RSIP server sends a QUERY_RESPONSE that does not contain
any tuples, or a QUERY_RESPONSE that does not contain a tuple
that applies to an associated tuple in the associated
QUERY_REQUEST, this should be interpreted that the RSIP server
does not know whether the queried host or network is local or
remote. Appropriate client behavior upon receipt of such a
message is to assume that the queried host or network is
remote.
Note that an RSIP server is not expected to maintain a complete
list of all remote hosts and networks. In fact, a typical RSIP
server will only maintain a list of the networks and hosts that
it knows are local (private with respect to the RSIP client).
9.16. LISTEN_REQUEST
9.16.1. Description
A LISTEN_REQUEST message is sent by an RSIP client that wants
to register a service on a particular address and port number.
The client must include its client ID, local address parameter
and ports parameters, and remote address and ports parameters.
The client MAY suggest a lease time and one or more tunnel
types.
9.16.2. Format
<LISTEN_REQUEST> ::= <Version>
<Message Type>
<Overall Length>
<Client ID>
<Address (local)>
<Ports (local)>
<Address (remote)>
<Ports (remote)>
[Lease Time]
[Tunnel Type]...
9.16.3. Behavior
If the client wants to listen on a particular address or port,
it may specify these in the address and ports parameters.
Otherwise it may leave one or both of these parameters with
"don't care" values.
Borella et al. Expires July 2000 [Page 28]
INTERNET-DRAFT Realm Specific IP: Protocol Specification January 2000
If no remote flow policy is being used, the client MUST fill
both the remote address and ports parameters with "don't care"
values. If macro-flow based remote policy is used, the client
MUST specify the remote address, but MAY or MAY NOT specify the
remote port(s). If micro-flow based remote policy is used, the
client MUST specify the remote address and ports parameter.
Once a LISTEN_REQUEST has been granted, the RSIP server MUST
forward all packets destined to the address and port in
question to the client, even if the remote host address and
port tuple has not been previously contacted by the client.
LISTEN_REQUEST is not necessary for RSA-IP.
The following message-specific error conditions exist:
- If the client is not registered with the server, the server
MUST respond with an ERROR_RESPONSE containing the
REGISTER_FIRST error.
- If the message contains an incorrect client ID, the server
MUST respond with an ERROR_RESPONSE containing the
BAD_CLIENT_ID error.
- If the local address parameter is a don't care value and the
RSIP server cannot allocate ANY addresses, the RSIP server
MUST respond with an ERROR_RESPONSE containing the
LOCAL_ADDR_UNAVAILABLE error.
- If the local address parameter is not a don't care value
there are six possible error conditions:
o If the RSIP server cannot allocate ANY addresses, it MUST
respond with an ERROR_RESPONSE containing the
LOCAL_ADDR_UNAVAILABLE error.
o If the RSIP server cannot allocate the requested address
because it is in use, the RSIP server MUST respond with an
ERROR_RESPONSE containing the LOCAL_ADDR_INUSE error.
o If the RSIP server cannot allocate the requested address
because it is not allowed by policy, the RSIP server MUST
respond with an ERROR_RESPONSE containing the
LOCAL_ADDR_UNALLOWED error.
o If the RSIP server cannot allocate the requested address /
port tuple because it is in use, the RSIP server MUST
respond with an ERROR_RESPONSE containing the
Borella et al. Expires July 2000 [Page 29]
INTERNET-DRAFT Realm Specific IP: Protocol Specification January 2000
LOCAL_ADDRPORT_INUSE error.
o If the RSIP server cannot allocate the requested address /
port tuple because it is not allowed by policy, the RSIP
server MUST respond with an ERROR_RESPONSE containing the
LOCAL_ADDRPORT_UNALLOWED error.
- If macro-flow based remote policy is used and the requested
remote address is not allowed by the RSIP server's policy,
the RSIP server MUST respond with an ERROR_RESPONSE
containing the REMOTE_ADDR_UNALLOWED error.
- If micro-flow based remote policy is used and the requested
remote address / port pair is not allowed by the RSIP
server's policy, the RSIP server MUST respond with an
ERROR_RESPONSE containing the REMOTE_ADDRPORT_UNALLOWED
error.
- If an unsupported or unallowed tunnel type is specified, the
RSIP server MUST respond with an ERROR_RESPONSE containing
the BAD_TUNNEL_TYPE error.
- If the client has not specified local or remote address or
port information in enough detail, the RSIP server MUST
respond with an ERROR_RESPONSE containing the
FLOW_POLICY_VIOLATION error.
9.17. LISTEN_RESPONSE
9.17.1. Description
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 address and port
which have been granted to the client. The server must also
specify a tunnel type and lease time.
If no remote flow policy is being used, the server MUST fill
both the remote address and ports parameters with "don't care"
values. If macro-flow based remote policy is used, the server
MUST specify the remote address, but MAY or MAY NOT specify the
remote port(s). If micro-flow based remote policy is used, the
server MUST specify the remote address and ports parameter.
Borella et al. Expires July 2000 [Page 30]
INTERNET-DRAFT Realm Specific IP: Protocol Specification January 2000
9.17.2. Format
<LISTEN_RESPONSE> ::= <Version>
<Message Type>
<Overall Length>
<Client ID>
<Bind ID>
<Address (local)>
<Ports (local)>
<Address (remote)>
<Ports (remote)>
<Tunnel Type>
<Lease Time>
9.17.3. Behavior
If no remote flow policy is being used, the server MUST fill
both the remote address and ports parameters with "don't care"
values. If macro-flow based remote policy is used, the server
MUST specify the remote address, but MAY or MAY NOT specify the
remote port(s). If micro-flow based remote policy is used, the
server MUST specify the remote address and ports parameter.
10. Discussion
10.1. General Server Policy
There is a significant amount of RSIP server policy that may be
implemented, but is beyond the scope of this draft. We expect
that most of this policy will be site-specific or implementation-
specific and therefore do not make any recommendations. Examples
of general server policy include:
- How ports are allocated to RSIP clients.
- Preferred length of lease times.
- How flow policy is applied to which clients.
10.2. Errors Not From the RSIP Protocol
Once an RSIP client and server have established a relationship and
the client is assigned resources to use, error may occur due to
the client's misuse of the resources or its attempting to use
unassigned resources. The following error behavior is defined:
- If a client attempts to use a local address which it has not
been allocated, the RSIP server MUST drop the associated
packet(s) and send the client an ERROR_RESPONSE containing the
LOCAL_ADDR_UNALLOWED error.
Borella et al. Expires July 2000 [Page 31]
INTERNET-DRAFT Realm Specific IP: Protocol Specification January 2000
- If a client attempts to use a local address / port tuple which
it has not been allocated, the RSIP server MUST drop the
associated packet(s) and send the client an ERROR_RESPONSE
containing the LOCAL_ADDRPORT_UNALLOWED error.
- If a client attempts to contact a remote address which has not
been properly specified or otherwise approved (e.g., via an
ASSIGN_RESPONSE_RSAP-IP and macro or micro based remote flow
policy), the RSIP server MUST drop the associated packet(s) and
send the client an ERROR_RESPONSE containing the
REMOTE_ADDR_UNALLOWED error.
- If a client attempts to contact a remote address / port tuple
which has not been properly specified or otherwise approved
(e.g., via an ASSIGN_RESPONSE_RSAP-IP and micro based remote
flow policy), the RSIP server MUST drop the associated packet(s)
and send the client an ERROR_RESPONSE containing the
REMOTE_ADDRPORT_UNALLOWED error.
- If a client attempts to establish or use an improper tunnel
type, the RSIP server MUST respond with an ERROR_RESPONSE
containing the BAD_TUNNEL_TYPE error.
10.3. Default Tunnel Type and RSIP Method
If an RSIP server does not specify a tunnel type or RSIP method as
part of a REGISTER_RESPONSE, the client MUST assume a tunnel type
of IP-IP and an RSIP method of RSAP-IP.
10.4. Address and Port Requests and Allocation
Regardless of local flow policy, an RSIP client may "suggest" that
it would like to use a particular local address and/or port number
in a particular binding. An RSIP server that cannot grant such a
request, because the specified resources are already in use, MUST
respond with an ERROR_RESPONSE containing the LOCAL_ADDR_INUSE or
LOCAL_ADDRPORT_INUSE values.
10.5. Local Servers and Flow Policy Interaction
An RSIP client may initialize a publically accessible server (such
as an FTP or HTTP server) by transmitting a LISTEN_REQUEST message
to an RSIP server and receiving a LISTEN_RESPONSE. However,
unless no remote flow policy is used, the server will have to
specify the address or address and port of a single remote host
that will be allowed to contact it. Obviously, such as
restriction is not very useful for clients that require their
servers to be accessible by any remote host.
Borella et al. Expires July 2000 [Page 32]
INTERNET-DRAFT Realm Specific IP: Protocol Specification January 2000
This indicates that there is a conflict between flow-based policy
and support for servers. The main purpose of enforcing flow-based
policy for LISTEN_REQUESTs is that it allows an RSIP server tight
control over how an RSIP client uses ports and the associated
accounting. For example, an RSIP client, operating under remote
micro-flow based policy and using a protocol such as FTP, will
have to specify the address and port that it will receive FTP data
on, as well as the address and port that the server will transmit
data from, in a LISTEN_REQUEST.
In general, an RSIP server may not allow arbitrary clients to
start public servers because of the traffic and security concerns.
Thus, we recommend that if remote micro-flow based policy is used,
that an RSIP server only allow public servers on RSIP clients via
administrative override.
Currently, RSIP clients can only be identified by their local IP
address or MAC address.
11. 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 server should take all measures deemed necessary to prevent
its clients from performing intentional or unintentional denial-of-
service attacks by request large sets of resources.
Currently, RSIP clients can only be identified by their local IP
address or MAC address. It is desirable to allow RSIP messages sent
between a client and server to be authenticated. Further discussion
of such authentication can be found in [RSIP-FRAME].
Discussion of RSIP support for end-to-end IPSEC can be found in
[RSIP-IPSEC].
12. IANA Considerations
All of the designations below are tentative.
- RSIP port number: 4455 (pending approval).
- RSIP error codes (see Appendix A).
- RSIP message type codes (see Appendix B).
- RSIP tunnel types, methods, and flow policies.
RSIP parameter values are designated as follows:
Borella et al. Expires July 2000 [Page 33]
INTERNET-DRAFT Realm Specific IP: Protocol Specification January 2000
- 0 Reserved
- 1-240 Assigned by IANA
- 241-255 Reserved for private use
New registrations for the above namespaces are recommended to be
allocated via the Specification Required method documented in
[RFC2434].
13. Changelog
04 to 05
- Categorized all RSIP messages as either client or server and
mandatory or optional.
- Added discussion of behavior and error conditions to all RSIP
messages.
- Re-worked error messages as per the above.
- Noted that for micro-flow policy, a ports parameter MUST contain
exactly one port field.
- Fixed IANA Considerations section
- Added indicator parameter
- Set aside parameter codes 241-255 for private use
- Major revision of QUERY_REQUEST and QUERY_RESPONSE
- Added discussion of error that occur from data flow
03 to 04
- Changed "client / server state" to "client / server relationship"
in order to not overload the word "state".
- Added section on transport protocol support.
- Reduced the size of "don't care" value for Address and Port parameters.
- Removed message IDs.
- Addition of overall length field in all messages.
- Added example of an RSA-IP session.
- Divided error numbers by category.
02 to 03
- Overall re-write and editing.
- Removed a number of extraneous details that are now covered in the
framework draft.
- Moved parameter and message type codes to appendices.
- Added section on flow policy.
- Modified address and port parameters to simplify and generalize.
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.
Borella et al. Expires July 2000 [Page 34]
INTERNET-DRAFT Realm Specific IP: Protocol Specification January 2000
- Updated references with respect to RFC 2663.
- Clarified use/non-use of message IDs between clients and servers.
- 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.
- Indicated 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.
14. Acknowledgements
The authors would like to specifically thank Gabriel Montenegro, Pyda
Srisuresh, Dan Nessett, Gary Jaszewski, Naveen Rajanikantha, Sudhakar
Ramakrishna, and Rick Cobb for their input. The IETF NAT working
group as a whole has been extremely helpful in the ongoing
development of RSIP.
15. Appendix A: RSIP Error Numbers
Borella et al. Expires July 2000 [Page 35]
INTERNET-DRAFT Realm Specific IP: Protocol Specification January 2000
This section provides descriptions for the error values in the RSIP
error parameter. These error values are preliminary and are very
likely to change over time as implementations are tested.
All errors are grouped into the following categories:
100's: General errors.
101: UNKNOWN_ERROR. An error that cannot be identified has
occurred. This error should be used when all other error
messages are inappropriate.
102: USE_TCP. A client has attempted to use UDP on a server that
only supports TCP.
103: FLOW_POLICY_VIOLATION: A client has not specified address or
port information in enough detail for its assigned flow policy.
200's: Parameter and message errors. The server uses these errors
when it detects that a parameter or message is malformed, as well
as when it does not understand a parameter or message.
201: MISSING_PARAM. The request does not contain a required
parameter.
202: DUPLICATE_PARAM. The request contains an illegal duplicate
parameter.
203: EXTRA_PARAM. The request contains a parameter that it should
not.
204: ILLEGAL_PARAM. The server does not understand a parameter
code.
205: BAD_PARAM. A parameter is malformed.
206: ILLEGAL_MESSAGE. The server does not understand the message
type. The message type is neither mandatory nor optional.
207: BAD_MESSAGE. A message is malformed and server parsing
failed.
208: UNSUPPORTED_MESSAGE: The client has transmitted an optional
message that the server does not support.
300's: Permission, resource, and policy errors. The server uses
these errors when a client has attempted to do something that it
is not permitted to do, or something that violated server policy.
Borella et al. Expires July 2000 [Page 36]
INTERNET-DRAFT Realm Specific IP: Protocol Specification January 2000
301: REGISTER_FIRST. The RSIP client has attempted to request or
use resources without registering.
302: ALREADY_REGISTERED. The client has attempted to register
again without first de-registering.
303: ALREADY_UNREGISTERED. The client has attempted to de-register
but it is already in the unregistered state.
304: REGISTRATION_DENIED: The server will not allow the client to
register.
305: BAD_CLIENT_ID. The client has referred to itself with the
wrong client ID.
306: BAD_BIND_ID. The request refers to a bind ID that is not
valid for the client.
307: BAD_TUNNEL_TYPE. The request refers to a tunnel type that is
not valid for the client.
308: LOCAL_ADDR_UNAVAILABLE. The server is currently not able to
allocate ANY local address, but the client may try again later.
309: LOCAL_ADDRPORT_UNAVAILABLE. The server is currently not able
to allocate ANY local IP address / port tuple, but the client
may try again later.
310: LOCAL_ADDR_INUSE. The server was not able to allocate the
requested local address because it is currently used by another
entity.
311: LOCAL_ADDRPORT_INUSE. The server was not able to allocate
the requested local address / port tuple because it is
currently used by another entity.
312: LOCAL_ADDR_UNALLOWED. The server will not let the client use
the specified local IP address due to policy.
313: LOCAL_ADDRPORT_UNALLOWED. The server will not let the client
use the specified local address / port pair due to policy.
314: REMOTE_ADDR_UNALLOWED. The server will not allow the client
to establish a session to the specified remote address.
315: REMOTE_ADDRPORT_UNALLOWED. The server will not allow the
client to establish a session to the specified remote address /
port tuple.
Borella et al. Expires July 2000 [Page 37]
INTERNET-DRAFT Realm Specific IP: Protocol Specification January 2000
400's: IPSEC errors. All errors specific to RSIP / IPSEC operation.
See [RSIP-IPSEC].
16. Appendix B: Message Types
This section defines the values assigned to RSIP message types.
These values are preliminary and are likely to change over time as
implementations are tested. We also indicate which RSIP entity,
client or server, produces each messages, and whether it is mandatory
or optional. All *_REQUEST messages are only to be implemented on
clients, while all *_RESPONSE messages are only to be implemented on
servers. RSIP implementations (both client and server) MUST support
all mandatory messages in order to be considered "RSIP compliant".
Value Message Implementation Status
------------------------------------------------------------
1 ERROR_RESPONSE server mandatory
2 REGISTER_REQUEST client mandatory
3 REGISTER_RESPONSE server mandatory
4 DE-REGISTER_REQUEST client mandatory
5 DE-REGISTER_RESPONSE server mandatory
6 ASSIGN_REQUEST_RSA-IP client optional
7 ASSIGN_RESPONSE_RSA-IP server optional
8 ASSIGN_REQUEST_RSAP-IP client mandatory
9 ASSIGN_RESPONSE_RSAP-IP server mandatory
10 EXTEND_REQUEST client mandatory
11 EXTEND_RESPONSE server mandatory
12 FREE_REQUEST client mandatory
13 FREE_RESPONSE server mandatory
14 QUERY_REQUEST client optional
15 QUERY_RESPONSE server mandatory
16 LISTEN_REQUEST client optional
17 LISTEN_RESPONSE server optional
17. Appendix C: Example RSIP client/server transactions
In this appendix, we present an exemplary series of annotated
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'. Parameter values are denoted inside
of parentheses. Versions, message types, and overall lengths are not
included in order to save space. "Don't care" values are indicated
by 0's.
A ports parameter is represented by the number of ports followed by
the port numbers, separated by dashes. For example, 2-1012-1013
indicates two ports, namely 1012 and 1013, while 16-10000 indicates
16 ports, namely 10000-10015, and 4-0 indicates four ports, but the
Borella et al. Expires July 2000 [Page 38]
INTERNET-DRAFT Realm Specific IP: Protocol Specification January 2000
sender doesn't care where they are.
IPv4 addresses are assumed.
17.1. RSAP-IP with Local Macro-flow Based Policy and No Remote Flow
Policy
This example exhibits the loosest policy framework for RSAP-IP.
C --> S: REGISTER_REQUEST ()
The client attempts to register with the server.
S --> C: REGISTER_RESPONSE (Client ID = 1, Local Flow Policy =
Macro, Remote Flow policy = None)
The server responds, assigning a Client ID of 1, local macro-
flow based policy and no remote flow policy. No RSIP method is
indicated, so RSAP-IP is assumed. No tunnel type is indicated,
so IP-IP is assumed.
C --> S: ASSIGN_REQUEST_RSAP-IP: (Client ID = 1, Address (local) =
0, Ports (local) = 4-0, Address (remote) = 0, Ports (remote) =
0, Lease Time = 3600)
The client requests an address and four ports to use with it,
but doesn't care which address or ports are assigned. The
client does not specify the remote address or ports either.
The client suggests a lease time of 3600 seconds.
S --> C: ASSIGN_RESPONSE_RSAP-IP: (Client ID = 1, Bind ID = 1,
Address (local) = 149.112.240.156, Ports (local) = 4-1234,
Address (remote) = 0, Ports (remote) = 0, Lease Time = 1800,
Tunnel Type = IP-IP)
The server responds by indicating that a bind ID of 1 has been
assigned to IP address 149.112.240.156 with ports 1234-1237.
Any remote host may be communicated with, using any remote port
number. The lease time has been assigned to be 1800 seconds,
and the tunnel type is confirmed to be IP-IP.
The client is now able to communicate with any host on the
public network using these resources.
C --> S: QUERY_REQUEST: (Client ID = 1, Indicator = network,
Address (network) = 10.20.60.0, Address (netmask)
255.255.255.0)
Borella et al. Expires July 2000 [Page 39]
INTERNET-DRAFT Realm Specific IP: Protocol Specification January 2000
The client asks the server if the network 10.20.60.0/24 is
local.
S --> C: QUERY_RESPONSE: (Client ID = 1, Indicator = network,
Address (network) = 10.20.60.0, Address (netmask) =
255.255.255.0)
The server responds indicating that the network in question is
local.
C --> S: ASSIGN_REQUEST_RSAP-IP: (Client ID = 1, Address (local) =
149.112.240.156, Ports (local) = 8-1238, Address (remote) = 0,
Ports (remote) = 0, Lease Time = 1800)
The client requests eight more particular ports for use with
RSAP-IP with the same address. A lease of 1800 seconds is
requested. IP-IP tunneling is implied by default.
S --> C: ASSIGN_RESPONSE_RSAP-IP: (Client ID = 1, Bind ID = 2,
Address (local) = 149.112.240.156, Ports (local) = 8-1305,
Address (remote) = 0, Ports (remote) = 0, Lease Time = 1800)
The server grants the request with the same address, but with a
different set of ports. IP-IP tunneling is implied by default.
C --> S: FREE_REQUEST (Client ID = 1, Bind ID = 1)
The client frees bind ID 1; i.e., ports 1234-1237 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 1305-1314.
S --> C: FREE_RESPONSE (Client ID = 1, Bind ID = 1)
The server acknowledges that Bind ID 1 has been freed.
C --> S: EXTEND_REQUEST (Client ID = 1, Bind ID = 2, Lease Time =
1800)
The client request that the lease on bind ID 1 be extended for
1800 seconds.
S --> C: EXTEND_RESPONSE (Client ID = 1, Bind ID = 2, Lease Time =
1800)
The server confirms the request.
S --> C: FREE_RESPONSE (Client ID = 1, Bind ID = 2)
Borella et al. Expires July 2000 [Page 40]
INTERNET-DRAFT Realm Specific IP: Protocol Specification January 2000
The server forces the client to free the resources of bind ID
2.
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.
17.2. RSAP-IP with Local Micro-flow Based Policy and Remote Micro-
flow Based Policy
This example exhibits the strictest policy framework for RSAP-IP.
C --> S: REGISTER_REQUEST ()
The client attempts to register with the server.
S --> C: REGISTER_RESPONSE (Client ID = 5, Local Flow Policy =
Micro, Remote Flow policy = Micro, RSIP Method = RSAP-IP, RSIP
Method = RSA-IP, Tunnel Type = IP-IP, Tunnel Type = GRE)
The server responds, assigning a Client ID of 5, local micro-
flow based policy and remote micro-flow based policy. Both
RSAP-IP and RSA-IP are supported. Both IP-IP and GRE tunnel
types are supported.
C --> S: ASSIGN_REQUEST_RSAP-IP: (Client ID = 5, Address (local) =
0, Ports (local) = 0, Address (remote) = 38.196.73.6, Ports
(remote) = 21, Lease Time = 600, Tunnel Type = IP-IP)
The client requests a local address and a port assignment to
use with it. The client indicates that it wants to contact
host 38.196.73.6 at port 21 (FTP control). The client requests
a lease time of 600 seconds and a tunnel type of IP-IP.
S --> C: ASSIGN_RESPONSE_RSAP-IP: (Client ID = 5, Bind ID = 1,
Address (local) = 149.112.240.156, Ports (local) = 2049,
Address (remote) = 38.196.73.6, Ports (remote) = 21, Lease Time
= 600, Tunnel Type = IP-IP)
The server responds by indicating that a bind ID of 1 has been
assigned to IP address 149.112.240.156 with port 2049. Only
host 38.196.73.6 at port 21 may be contacted. The lease time
has been assigned to be 600 seconds, and the tunnel type is
confirmed to be IP-IP.
Borella et al. Expires July 2000 [Page 41]
INTERNET-DRAFT Realm Specific IP: Protocol Specification January 2000
C --> S: LISTEN_REQUEST: (Client ID = 5, Address (local) =
149.112.240.156, Ports (local) = 2050, Address (remote) =
38.196.73.6, Ports (remote) = 20)
The client requests a listen port 2050 at the same address that
it has been assigned. Only host 38.196.73.6 from ports 20 (FTP
data) will be able to contact it.
S --> C: LISTEN_RESPONSE: (Client ID = 5, Address (local) =
149.112.240.156, Ports (local) = 2050, Address (remote) =
38.196.73.6, Ports (remote) = 20, Lease Time = 600, Tunnel Type
= IP-IP)
The server confirms the request and assigns a lease time of 600
seconds and a tunnel type of IP-IP.
C --> S: DE-REGISTER_REQUEST (Client ID = 5)
The client de-registers with the sever.
S --> C: REGISTER_RESPONSE (Client ID = 5)
The server acknowledges that the client has de-registered. All
of the client's bindings have been implicitly revoked.
17.3. RSA-IP with Local Macro-flow Based Policy and Remote Macro-
flow based Policy
This example exhibits a medium level of control for RSA-IP.
C --> S: REGISTER_REQUEST ()
The client attempts to register with the server.
S --> C: REGISTER_RESPONSE (Client ID = 3, Local Flow Policy =
Macro, Remote Flow policy = Macro, RSIP Method = RSAP-IP, RSIP
Method = RSA-IP, Tunnel Type = IP-IP, Tunnel Type = L2TP)
The server responds, assigning a Client ID of 3, local macro-
flow based policy and remote macro-flow based policy. Both
RSAP-IP and RSA-IP are supported. Both IP-IP and L2TP tunnel
types are supported.
C --> S: ASSIGN_REQUEST_RSA-IP: (Client ID = 3, Address (local) =
0, Address (remote) = www.foo.com, Ports (remote) = 0, Lease
Time = 3600, Tunnel Type = IP-IP)
The client requests a local address and indicates that it wants
Borella et al. Expires July 2000 [Page 42]
INTERNET-DRAFT Realm Specific IP: Protocol Specification January 2000
to contact host www.foo.com.
S --> C: ERROR_RESPONSE: (Error = REMOTE_ADDR_UNALLOWED, Client ID
= 3)
The server indicates that the client is not permitted to
establish communication with www.foo.com.
C --> S: ASSIGN_REQUEST_RSA-IP: (Client ID = 3, Address (local) =
0, Address (remote) = www.bar.com, Ports (remote) = 0, Lease
Time = 3600, Tunnel Type = IP-IP)
The client requests a local address and indicates that it wants
to contact host www.bar.com.
S --> C: ASSIGN_RESPONSE_RSA-IP: (Client ID = 3, Bind ID = 1,
Address (local) = 149.112.240.17, Address (remote) =
www.bar.com, Ports (remote) = 0, Lease Time = 3600, Tunnel Type
= IP-IP)
The server responds by granting local IP address 149.112.240.17
to the client, and permitting it to communicate with
www.bar.com, at any port. Requested lease time and tunnel type
are also granted.
C --> S: DE-REGISTER_REQUEST (Client ID = 3)
The client de-registers with the sever.
S --> C: REGISTER_RESPONSE (Client ID = 3)
The server acknowledges that the client has de-registered. All
of the client's bindings have been implicitly revoked.
18. Appendix D: Example RSIP client state diagram
This appendix provides an exemplary diagram of RSIP client state.
The client begins in the unregistered state. We assume that for UDP,
if a message is 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 occurring after 12.5 ms.
This diagram does not include transitions for the LISTEN_REQUEST
message or the DEALLOCATE message.
send
+------------+ REGISTER_REQUEST +------------+
| |----------------->|Registration|<-- timeout/send
Borella et al. Expires July 2000 [Page 43]
INTERNET-DRAFT Realm Specific IP: Protocol Specification January 2000
+--->|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
| 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
Borella et al. Expires July 2000 [Page 44]
INTERNET-DRAFT Realm Specific IP: Protocol Specification January 2000
| |
| v
+----------+
| Assigned |
|Assignment|
| Pending |
+----------+
^ |
| |
timeout/send
ASSIGN_REQUEST
19. References
[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.
[RFC2434] T. Narten and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs," RFC 2434, Oct. 1998.
[RFC2663] P. Srisuresh and M. Holdrege, "IP Network Address
Translator (NAT) Terminology and Considerations," RFC 2663, Aug.
1999.
[RSIP-FRAME] M. Borella, J. Lo, D. Grabelsky, and G. Montenegro,
"Realm Specific IP: Framework," Internet Draft <draft-ietf-nat-
rsip-framework-03.txt>, Dec. 1999 (work in progress).
[RSIP-IPSEC] G. Montenegro and M. Borella, "RSIP Support for End-to-
end IPSEC," <draft-ietf-nat-rsip-ipsec-01.txt>, work in progress,
Oct. 1999.
20. Authors' Addresses
Michael Borella
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.
Borella et al. Expires July 2000 [Page 45]
INTERNET-DRAFT Realm Specific IP: Protocol Specification January 2000
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
21. Copyright Statement
Copyright (c) The Internet Society (1999). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
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 July 2000 [Page 46]
