As per Relevance of the word containing, we have this rfc below:
Network Working Group M.
Request for Comments: 3103 D.
Category: Experimental
J.
Candlestick
K.
NEC
October 2001
Realm Specific IP: Protocol
Status of this
This memo defines an Experimental Protocol for the
community. It does not specify an Internet standard of any kind
Discussion and suggestions for improvement are requested
Distribution of this memo is unlimited
Copyright
Copyright (C) The Internet Society (2001). All Rights Reserved
IESG
The IESG notes that the set of documents describing the
technology imply significant host and gateway changes for a
implementation. In addition, the floating of port numbers can
problems for some applications, preventing an RSIP-enabled host
interoperating transparently with existing applications in some
(e.g., IPsec). Finally, there may be significant
complexities associated with using RSIP. Some of these and
complications are outlined in section 6 of the RFC 3102, as well
in the Appendices of RFC 3104. Accordingly, the costs and
of using RSIP should be carefully weighed against other means
relieving address shortage
This document presents a protocol with which to implement
Specific IP (RSIP). The protocol defined herein allows
of resources between an RSIP host and gateway, so that the host
lease some of the gateway's addressing parameters in order
establish a global network presence. This protocol is designed
operate on the application layer and to use its own TCP or UDP port
In particular, the protocol allows a gateway to allocate
and control parameters to a host such that a flow policy can
enforced at the gateway
Borella, et al. Experimental [Page 1]
RFC 3103 RSIP Protocol Specification October 2001
Table of
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Specification of Requirements . . . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 5
5. Transport Protocol . . . . . . . . . . . . . . . . . . . . . 7
6. Host / Gateway Relationships . . . . . . . . . . . . . . . . 7
7. Gateway Flow Policy and State . . . . . . . . . . . . . . . . 8
7.1. Local Flow Policy . . . . . . . . . . . . . . . . . . . . . 9
7.2. Remote Flow Policy . . . . . . . . . . . . . . . . . . . . 9
7.3. Gateway State . . . . . . . . . . . . . . . . . . . . . . . 10
8. Parameter Specification and Formats . . . . . . . . . . . . . 11
8.1. Address . . . . . . . . . . . . . . . . . . . . . . . . . . 11
8.2. Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
8.3. Lease Time . . . . . . . . . . . . . . . . . . . . . . . . 13
8.4. Client ID . . . . . . . . . . . . . . . . . . . . . . . . . 13
8.5. Bind ID . . . . . . . . . . . . . . . . . . . . . . . . . . 13
8.6. Tunnel Type . . . . . . . . . . . . . . . . . . . . . . . . 14
8.7. RSIP Method . . . . . . . . . . . . . . . . . . . . . . . . 14
8.8. 8.8. Error . . . . . . . . . . . . . . . . . . . . . . . . 14
8.9. Flow Policy . . . . . . . . . . . . . . . . . . . . . . . . 15
8.10. Indicator . . . . . . . . . . . . . . . . . . . . . . . . 15
8.11. Message Counter . . . . . . . . . . . . . . . . . . . . . 16
8.12. Vendor Specific Parameter . . . . . . . . . . . . . . . . 16
9. Message Types . . . . . . . . . . . . . . . . . . . . . . . . 16
9.1. ERROR_RESPONSE . . . . . . . . . . . . . . . . . . . . . . 17
9.2. REGISTER_REQUEST . . . . . . . . . . . . . . . . . . . . . 18
9.3. REGISTER_RESPONSE . . . . . . . . . . . . . . . . . . . . . 19
9.4. DE-REGISTER_REQUEST . . . . . . . . . . . . . . . . . . . . 19
9.5. DE-REGISTER_RESPONSE . . . . . . . . . . . . . . . . . . . 20
9.6. ASSIGN_REQUEST_RSA-IP . . . . . . . . . . . . . . . . . . . 21
9.7. ASSIGN_RESPONSE_RSA-IP . . . . . . . . . . . . . . . . . . 22
9.8. ASSIGN_REQUEST_RSAP-IP . . . . . . . . . . . . . . . . . . 23
9.9. ASSIGN_RESPONSE_RSAP-IP . . . . . . . . . . . . . . . . . . 26
9.10. EXTEND_REQUEST . . . . . . . . . . . . . . . . . . . . . . 27
9.11. EXTEND_RESPONSE . . . . . . . . . . . . . . . . . . . . . 28
9.12. FREE_REQUEST . . . . . . . . . . . . . . . . . . . . . . . 28
9.13. FREE_RESPONSE . . . . . . . . . . . . . . . . . . . . . . 29
9.14. QUERY_REQUEST . . . . . . . . . . . . . . . . . . . . . . 30
9.15. QUERY_RESPONSE . . . . . . . . . . . . . . . . . . . . . . 31
9.16. LISTEN_REQUEST . . . . . . . . . . . . . . . . . . . . . . 32
9.17. LISTEN_RESPONSE . . . . . . . . . . . . . . . . . . . . . 35
10. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 36
10.1. Use of Message Counters . . . . . . . . . . . . . . . . . 36
10.2. RSIP Host and Gateway Failure Scenarios . . . . . . . . . 37
10.3. General Gateway Policy . . . . . . . . . . . . . . . . . . 38
10.4. Errors Not From the RSIP Protocol . . . . . . . . . . . . 39
Borella, et al. Experimental [Page 2]
RFC 3103 RSIP Protocol Specification October 2001
10.5. Address and Port Requests and Allocation . . . . . . . . . 40
10.6. Local Gateways and Flow Policy Interaction . . . . . . . . 40
11. Security Considerations . . . . . . . . . . . . . . . . . . 40
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . 41
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 41
14. Appendix A: RSIP Error Numbers . . . . . . . . . . . . . . . 42
15. Appendix B: Message Types . . . . . . . . . . . . . . . . . 44
16. Appendix C: Example RSIP host/gateway transactions . . . . . 45
17. Appendix D: Example RSIP host state diagram . . . . . . . . 50
18. References . . . . . . . . . . . . . . . . . . . . . . . . . 52
19. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 53
20. Full Copyright Statement . . . . . . . . . . . . . . . . . . 54
1.
Network Address Translation (NAT) has gained popularity as a
of separating public and private address spaces, and
network address shortages. A NAT translates the addresses of
leaving a first routing realm to an address from a second
realm, and performs the reverse function for packets entering
first routing realm from the second routing realm. This
is performed transparently to the hosts in either space, and
include modification of TCP/UDP port numbers and IP addresses
packets that traverse the NAT
While a NAT does not require hosts to be aware of the translation,
will require an application layer gateway (ALG) for any protocol
transmits IP addresses or port numbers in packet payloads (such
FTP). Additionally, a NAT will not work with protocols that
IP addresses and ports to remain unmodified between the source
destination hosts, or protocols that prevent such modifications
occurring (such as some IPsec modes, or application-layer end-to-
encryption).
An alternative to a NAT is an architecture that allows the
within the first (e.g., private) routing realm to directly
addresses and other routing parameters from the second (e.g., public
routing realm. Thus, RSIP [RSIP-FRAME] has been defined as a
for address sharing that exhibits more transparency than NAT.
particular, RSIP requires that an RSIP gateway (a router or
between the two realms) assign at least one address from the
routing realm, and perhaps some other resources, to each RSIP host
An RSIP host is a host in the first routing realm that needs
establish end-to-end connectivity to a host, entity or device in
second routing realm. Thus, the second routing realm is not
Borella, et al. Experimental [Page 3]
RFC 3103 RSIP Protocol Specification October 2001
accessible from the RSIP host, but this system allows packets
maintain their integrity from the RSIP host to their destination
ALGs are not required in the RSIP gateway
RSIP requires that hosts be modified so that they place some
of layer three, layer four or other values from those assigned by
RSIP gateway in each packet bound for the second routing realm
This document discusses a method for assigning parameters to an
host from an RSIP gateway. The requirements, scope,
applicability of RSIP, as well as its interaction with other layer 3
protocols, are discussed in a companion framework document [RSIP
FRAME]. Extensions to this protocol that enable end-to-end IPsec
discussed in [RSIP-IPSEC].
2. Specification of
The keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT",
"SHALL", "SHALL NOT", "MAY" and "MAY NOT" that appear in
document are to be interpreted as described in [RFC2119].
3.
Private
A routing realm that uses private IP addresses from the
(10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) specified
[RFC1918], or addresses that are non-routable from the Internet
Public
A routing realm with unique network addresses assigned by
Internet Assigned Number Authority (IANA) or an equivalent
registry
RSIP
A host within the private realm that acquires publicly
parameters from an RSIP gateway through the use of the
client/server protocol
RSIP
A router situated on the boundary between a private realm and
public realm and owns one or more public IP addresses. An
gateway is responsible for public parameter management
assignment to RSIP hosts. An RSIP gateway may act as a NAT
for hosts within the private realm that are not RSIP enabled
Borella, et al. Experimental [Page 4]
RFC 3103 RSIP Protocol Specification October 2001
RSIP
An application program that performs the client portion of
RSIP client/server protocol. An RSIP client application
exist on all RSIP hosts, and MAY exist on RSIP gateways
RSIP
An application program that performs the server portion of
RSIP client/server protocol. An RSIP server application
exist on all RSIP gateways
RSA-IP: Realm Specific Address
An RSIP method in which each RSIP host is allocated a unique
address from the public realm. Discussed in detail in [RSIP
FRAME
RSAP-IP: Realm Specific Address and Port
An RSIP method in which each RSIP host is allocated an IP
(possibly shared with other RSIP hosts) and some number of per
address unique ports from the public realm. Discussed in
in [RSIP-FRAME
An association of some combination of a local address, one or
local ports, a remote address, and a remote port with an
host
A general way to refer to an item that an RSIP host leases from
RSIP gateway; e.g., an address or port
All other terminology found in this document is consistent with
of [RFC2663] and [RSIP-FRAME].
4.
For simplicity, in the remainder of this document we will assume
the RSIP hosts in the first routing realm (network) use
(e.g., see [RFC1918]) IP addresses, and that the second routing
(network) uses public IP addresses. (This assumption is made
loss of generality and the ensuing discussion applies to more
Borella, et al. Experimental [Page 5]
RFC 3103 RSIP Protocol Specification October 2001
cases.) The RSIP gateway connects the public and private realms
contains interfaces to both. Other NAT terminology found in
document is defined in [RFC2663].
The diagram below describes an exemplary reference architecture
RSIP
RSIP Host RSIP Gateway
Xa Na Nb
[X]------( Addr sp. A )----[N]-----( Addr sp. B )-------[Y
( Network ) ( Network )
Hosts X and Y belong to different addressing realms A and B
respectively, and N is an RSIP gateway (which may also perform
functions). N has two interfaces: Na on address space A, and Nb
address space B. N may have a pool of addresses in address space
which it can assign to or lend to X and other hosts in address
A. These addresses are not shown above, but they can be denoted
Nb1, Nb2, Nb3 and so on
Host X, needing to establish an end-to-end connection to a
entity Y situated within address space B, first negotiates
obtains assignment of the resources from the RSIP gateway.
assignment of these parameters, the RSIP gateway creates a mapping
of X's addressing information and the assigned resources.
binding enables the RSIP gateway to correctly de-multiplex
forward inbound traffic generated by Y for X. A lease time
associated with each bind
Using the public parameters assigned by the RSIP gateway, RSIP
tunnel data packets across address space A to the RSIP gateway.
RSIP gateway acts as the end point of such tunnels, stripping off
outer headers and routing the inner packets onto the public realm
As mentioned above, an RSIP gateway maintains a mapping of
assigned public parameters as demultiplexing fields for
mapping them to RSIP host private addresses. When a packet from
public realm arrives at the RSIP gateway and it matches a given
of demultiplexing fields, then the RSIP gateway will tunnel it to
appropriate RSIP host. The tunnel headers of outbound packets from
to Y, given that X has been assigned Nb, are as follows
+---------+---------+---------+
| X -> Na | Nb -> Y | payload |
+---------+---------+---------+
Borella, et al. Experimental [Page 6]
RFC 3103 RSIP Protocol Specification October 2001
There are two basic flavors of RSIP: RSA-IP and RSAP-IP. RSIP
and gateways MUST support RSAP-IP and MAY support RSA-IP. Details
RSA-IP and RSAP-IP are found in [RSIP-FRAME].
5. Transport
RSIP is an application layer protocol that requires the use of
transport layer protocol for end-to-end delivery of packets
RSIP gateways MUST support TCP, and SHOULD support UDP. Due to
fact that RSIP may be deployed across a wide variety of
links, RSIP hosts SHOULD support TCP, because of TCP's
across said variety of links. However, RSIP hosts MAY support
instead of TCP, or both UDP and TCP
For RSIP hosts and gateways using UDP, timeout and
MUST occur. We recommend a binary exponential backoff scheme with
initial duration of 12.5 ms, and a maximum of six retries (
total attempts before failure). However, these parameters MAY
adjusted or tuned for specific link types or scenarios
Once a host and gateway have established a registration using
TCP or UDP, they may not switch between the two protocols for
duration of the registration. The decision of whether to use TCP
UDP is made by the client, and is determined by the
protocol of the first packet sent by a client in a
registration procedure
6. Host / Gateway
An RSIP host can be in exactly one of three fundamental
with respect to an RSIP gateway
Unregistered: The RSIP gateway does not know of the RSIP host'
existence, and it will not forward or deliver globally
packets on behalf of the host. The only valid RSIP-related
for an RSIP host to perform in this state is to
registration with an RSIP gateway
Registered: The RSIP gateway knows of the RSIP host and has
it a client ID and has specified the flow policies that
requires of the host. However, no resources, such as addresses
ports, have been allocated to the host, and the gateway will
forward or deliver globally addressed packets on behalf of
host. All registrations have an associated lease time. If
lease time expires, the RSIP host automatically reverts to
unregistered state
Borella, et al. Experimental [Page 7]
RFC 3103 RSIP Protocol Specification October 2001
Assigned: The RSIP gateway has granted one or more bindings
resources to the host. The gateway will forward and
globally addressed packets on behalf of the host. Each
has an associated lease time. If this lease time expires,
binding is automatically revoked
Architectures in which an RSIP host is simultaneously registered
more than one RSIP gateway are possible. In such cases, an RSIP
may be in different relationships with different RSIP gateways at
same time
An RSIP gateway MAY redirect an RSIP host to use a tunnel
for data traffic that is not the RSIP gateway itself, or perhaps is
different interface on the RSIP gateway. This is done by
the tunnel endpoint's address as part of an assignment. In such
architecture, it is desirable (though not necessary) for the
gateway to have a method with which to notify the tunnel endpoint
assignments, and the expiration status of these assignments
Lease times for bindings and registrations are managed as follows
All lease times are given in units of seconds from the current time
indicating a time in the future at which the lease will expire
These expiration times are used in the ensuing discussion
An initial expiration time (R) is given to a registration.
this registration, multiple bindings may be established, each
their own expiration times (B1, B2, ...). When each binding
established or extended, the registration expiration time is
so that the registration will last at least as long as the
lease. In other words, when binding Bi is established or extended
the following calculation is performed: R = max(R, Bi).
Under this scheme, a registration will never expire while
binding's lease is still valid. However, a registration may
when the last binding's lease expires, or at some point thereafter
7. Gateway Flow Policy and
Since an RSIP gateway is likely to reside on the boundary between
or more different administrative domains, it is desirable to
an RSIP gateway to be able to enforce flow-based policy. In
words, an RSIP gateway should have the ability to explicitly
which local addresses and ports are used to communicate with
addresses and ports
In the following, macro-flow policy refers to controlling flow
at the granularity level of IP addresses, while micro-flow
refers to controlling flow policy at the granularity of IP
Borella, et al. Experimental [Page 8]
RFC 3103 RSIP Protocol Specification October 2001
and port tuples. Of course there may be no policy at all,
indicates that the RSIP gateway does not care about the
parameters used by RSIP hosts. We consider two levels of local
policy and three levels of remote flow policy
7.1. Local Flow
Local flow policy determines the granularity of control that an
gateway has over the local addressing parameters that an RSIP
uses for particular sessions
Since an RSIP host must use at least an IP address allocated by
gateway, the loosest level of local flow policy is macro-flow based
Under local macro-flow policy, an RSIP host is allocated an
address (RSA-IP) or an IP address and one or more ports to use
it (RSAP-IP). However, the host may use the ports as it desires
establishing sessions with public hosts
Under micro-flow policy, a host is allocated exactly one port at
time. The host may request more ports, also one at a time.
policy gives the gateway very tight control over local port use
although it affords the host less flexibility
Note that only local macro-flow policy can be used with RSA-IP,
either local macro-flow or local micro-flow policy may be used
RSAP-IP
Examples of how RSIP flow policy operates are given in Appendix C
7.2. Remote Flow
Remote flow policy determines the granularity of control that an
gateway has over the remote (public) hosts with which an RSIP
communicates. In particular, remote flow policy dictates what
of detail that a host must specify addressing parameters of a
host or application before the RSIP gateway allows the host
communicate with that host or application
The simplest and loosest form of flow policy is no policy at all.
other words, the RSIP gateway allocates addressing parameters to
host, and the host may use these parameters to communicate with
remote host, without explicitly notifying the gateway
Macro-flow policy requires that the host identify the remote
of the host that it wishes to communicate with as part of its
for local addressing parameters. If the request is granted, the
MUST use the specified local parameters only with the remote
specified, and MUST NOT communicate with the remote address using
Borella, et al. Experimental [Page 9]
RFC 3103 RSIP Protocol Specification October 2001
local parameters but the ones allocated. However, the host
contact any port number at the remote host without
notifying the gateway
Micro-flow policy requires that the host identify the remote
and port of the host that it wishes to communicate with as part
its request for local addressing parameters. If the request
granted, the host MUST use the specified local parameters only
the remote address and port specified, and MUST NOT communicate
the remote address and port using any local parameters but the
allocated
Remote flow policy is implemented in both the ingress and
directions, with respect to the location of the RSIP gateway
7.3. Gateway
An RSIP gateway must maintain state for all RSIP hosts and
assigned resources. The amount and type of state maintained
on the local and remote flow policy. The required RSIP gateway
will vary based on the RSIP method, but will always include
chosen method's demultiplexing parameters
7.3.1. RSA-IP
An RSIP gateway serving an RSIP host using the RSA-IP method
maintain the following minimum state to ensure proper mapping
incoming packets to RSIP hosts
- Host's private
- Host's assigned public address(es
7.3.2. RSAP-IP
An RSIP gateway serving an RSIP host using the RSAP-IP method
maintain the following minimum state to ensure proper mapping
incoming packets to RSIP hosts
- Host's private
- Host's assigned public address(es
- Host's assigned port(s) per
7.3.3. Flow
Regardless of whether the gateway is using RSA-IP or RSAP-IP
additional state is necessary if either micro-flow based or macro
flow based remote policy is used
Borella, et al. Experimental [Page 10]
RFC 3103 RSIP Protocol Specification October 2001
If the gateway is using macro-flow based remote policy, the
state must be maintained
- Remote host's
If the gateway is using micro-flow based remote policy, the
state must be maintained
- Remote host's
- Remote host's
More state MAY be used by an RSIP gateway if desired. For example
ToS/DS bytes may be recorded in order to facilitate quality
service support
8. Parameter Specification and
In this section we define the formats for RSIP parameters. Each
message contains one or more parameters that encode the
passed between the host and gateway. The general format of
parameters is TLV (type-length-value) consisting of a 1-byte
followed by a 2-byte length followed by a 'length' byte value
shown below
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value ...
+-+-+-+-+-+-+-+-+-+-+-+
The value field may be divided into a number of other fields as
the type of the parameter. Note that the length field encodes
number of bytes in the value field, NOT the overall number of
in the parameter
8.1.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 1 | Length | Addrtype |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address...
+-+-+-+-+-+-+-+-+-+-+-+
Borella, et al. Experimental [Page 11]
RFC 3103 RSIP Protocol Specification October 2001
The address parameter contains addressing information, either an IPv
address or netmask, an IPv6 address or netmask, or a fully
domain name (FQDN). The Addrtype field is 1 byte in length
indicating the type of address
Addrtype Length of address field (in bytes
---- --------------------------------
0 Reserved 0
1 IPv4 4
2 IPv4 netmask 4
3 IPv6 16
4 FQDN
For FQDN (Fully qualified domain name), the length of the
field will be one less than the value of the length field, and
name will be represented as an ASCII string (no
character).
In some cases, it is necessary to specify a "don't care" value for
address. This is signified by a setting the length field to 1
omitting the value field
It is not valid for a host to request an address with an FQDN type
its local address (See specification of ASSIGN_REQUEST_RSA-IP
ASSIGN_REQUEST_RSAP-IP, below).
8.2.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 2 | Length | Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port number | ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The ports parameter encodes zero or more TCP or UDP ports. When
single port is specified, the value of the number field is 1
there is one port field following the number field. When more
one port is specified, the value of the number field will
the total number of ports contained, and the parameter may take
of two forms. If there is one port field, the ports specified
considered to be contiguous starting at the port number specified
the port field. Alternatively, there may be a number of port
equal to the value of the number field. The number of port
can be extrapolated from the length field
Borella, et al. Experimental [Page 12]
RFC 3103 RSIP Protocol Specification October 2001
In some cases, it is necessary to specify a don't care value for
or more ports (e.g., when a client application is using
source ports). This is accomplished by setting the length field
1, setting the number field to the number of ports necessary,
omitting all port fields. The value of the number field MUST
greater than or equal to one
If micro-flow based policy applies to a given ports parameter,
MUST contain exactly one port field
8.3. Lease
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 3 | Length = 4 | Lease time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lease time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The lease time parameter specifies the length, in seconds, of
RSIP host registration or parameter binding
8.4. Client
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 4 | Length = 4 | Client ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Client ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The client ID parameter specifies an RSIP client ID. Client ID'
by an RSIP gateway to differentiate RSIP hosts
8.5. Bind
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 5 | Length = 4 | Bind ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bind ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The bind ID parameter specifies an RSIP bind ID. Bind ID's are
by RSIP hosts and gateways to differentiate an RSIP host's bindings
Borella, et al. Experimental [Page 13]
RFC 3103 RSIP Protocol Specification October 2001
8.6. Tunnel
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 6 | Length = 1 | Tunnel type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The tunnel type parameter specifies the type of tunnel used
an RSIP host and an RSIP gateway. Defined tunnel types are
Tunnel
-----------
0
1 IP-
2
3 L2
8.7. RSIP
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 7 | Length = 1 | RSIP method |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The RSIP method parameter specifies an RSIP method. Defined
methods are
RSIP
-----------
0
1 RSA-
2 RSAP-
8.8.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 8 | Length = 2 | Error |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error |
+-+-+-+-+-+-+-+-+
The error parameter specifies an error. The currently defined
values are presented in Appendix A
Borella, et al. Experimental [Page 14]
RFC 3103 RSIP Protocol Specification October 2001
8.9. Flow
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 9 | Length = 2 | Local |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote |
+-+-+-+-+-+-+-+-+
The flow policy parameter specifies both the local and remote
policy
Defined local flow policies are
Local Flow
-----------------
0
1 Macro
2 Micro
Defined remote flow policies are
Remote Flow
------------------
0
1 Macro
2 Micro
3 No
8.10.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 10 | Length = 2 | Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value |
+-+-+-+-+-+-+-+-+
An indicator parameter is a general-purpose parameter, the use
which is defined by the message that it appears in. An RSIP
that uses an indicator parameter MUST define the meaning
interpretation of all of the indicator's possible values
Borella, et al. Experimental [Page 15]
RFC 3103 RSIP Protocol Specification October 2001
8.11. Message
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 11 | Length = 4 | Counter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Counter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A message counter parameter is used to mark RSIP messages
sequentially-increasing values. Message counters MUST be used
UDP, in order to facilitate reliability
8.12. Vendor Specific
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 12 | Length | Vendor ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor ID | Subtype | Value...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The vendor specific parameter is used to encode parameters that
defined by a particular vendor. The vendor ID field is the vendor
specific ID assigned by IANA. Subtypes are defined and used by
vendor as necessary. An RSIP host or gateway SHOULD silently
vendor-specific messages that it does not understand
9. Message
RSIP messages consist of three mandatory fields, version,
type, and overall length, followed by one or more
parameters, followed in turn by zero or more optional parameters.
an RSIP message, all required parameters MUST appear in the
order specified below. Optional parameters MAY appear in any order
Message format is shown below
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Message type | Overall length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Parameters...
+-+-+-+-+-+-+-+-+-+-+
Borella, et al. Experimental [Page 16]
RFC 3103 RSIP Protocol Specification October 2001
The version number field is a single byte and specifies the
version number that is being used. The current RSIP version
is 1.
The message type field is a single byte and specifies the
contained in the current packet. There may be only one message
packet. Message types are given numerical assignments in Appendix B
The overall length field is two bytes and contains the number
bytes in the RSIP message, including the three mandatory fields
Most parameters are only allowed to appear once in each message.
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
LISTEN_RESPONSE
- Multiple RSIP method and tunnel type parameters MAY appear
RESISTER_RESPONSE
- Multiple address parameters and multiple indicator
MAY appear in QUERY_REQUEST and QUERY_RESPONSE
The following message types are defined in BNF. Required
are enclosed in <> and MUST appear. Optional parameters are
in [] and MAY appear. Not all message types need to be
in order to be RSIP compliant. For example, an RSIP host and/
gateway may not support LISTEN_REQUEST and LISTEN_RESPONSE, or
only support RSAP-IP and not RSA-IP
9.1. ERROR_
9.1.1.
An ERROR_RESPONSE is used to provide error messages from an
gateway to an RSIP host. Usually, errors indicate that the
gateway cannot or will not perform an action or allocate resources
behalf of the host. If the error is related to a particular
ID or bind ID, these associated parameters MUST be included
Multiple errors MAY NOT be reported in the same ERROR_RESPONSE.
situations where more than one error has occurred, the RSIP
MUST choose only one error to report
Borella, et al. Experimental [Page 17]
RFC 3103 RSIP Protocol Specification October 2001
9.1.2.
RESPONSE> ::=
[Message Counter
[Client ID
[Bind ID
9.1.3.
An ERROR_RESPONSE message MUST only be transmitted by an
gateway. An RSIP host that detects an error in a message
from an RSIP gateway MUST silently discard the message. There are
error conditions that can be caused by an ERROR_RESPONSE.
ERROR_RESPONSE is typically transmitted in response to a request
an RSIP host, but also may be transmitted asynchronously by an
gateway
9.2. REGISTER_
9.2.1.
The REGISTER_REQUEST message is used by an RSIP host to
registration with an RSIP gateway. An RSIP host MUST register
it requests resources or services from an RSIP gateway. Once an
host has registered with an RSIP gateway, it may not register
until it has de-registered from that gateway
9.2.2.
<REGISTER_REQUEST> ::=
[Message Counter
9.2.3.
The following message-specific error conditions exist
- If the host is already registered with the gateway, the
MUST respond with an ERROR_RESPONSE containing
ALREADY_REGISTERED error and the RSIP host's client ID
- If the gateway's policy will not allow the host to register
the gateway MUST respond with an ERROR_RESPONSE containing
REGISTRATION_DENIED error
Borella, et al. Experimental [Page 18]
RFC 3103 RSIP Protocol Specification October 2001
9.3. REGISTER_
9.3.1.
The REGISTER_RESPONSE message is used by an RSIP gateway to
the registration of an RSIP host, and to provide a client ID,
policy, and possibly a message counter and one or more RSIP
and/or tunnel types
9.3.2.
<REGISTER_RESPONSE> ::=
[Message Counter
[RSIP Method]...
[Tunnel Type]...
9.3.3.
An RSIP gateway MUST assign a different client ID to each host
is simultaneously registered with it. The RSIP gateway MAY
with one or more RSIP methods and tunnel types that it supports.
an RSIP method is not specified, RSAP-IP MUST be assumed. If
tunnel type is not specified, IP-IP MUST be assumed
9.4. DE-REGISTER_
9.4.1.
The DE-REGISTER_REQUEST message is used by an RSIP host to de
register with an RSIP gateway. If a host de-registers from
assigned state, all of the host's bindings are revoked. The
SHOULD NOT de-register from the unregistered state
9.4.2.
REGISTER_REQUEST> ::=
[Message Counter
Borella, et al. Experimental [Page 19]
RFC 3103 RSIP Protocol Specification October 2001
9.4.3.
The following message-specific error conditions exist
- If the host is not registered with the gateway, the
MUST respond with an ERROR_RESPONSE containing
REGISTER_FIRST error
- If the message contains an incorrect client ID, the
MUST respond with an ERROR_RESPONSE containing
BAD_CLIENT_ID error
If there are no errors that result from this message, the
MUST respond with an appropriate DE-REGISTER_RESPONSE. Upon de
registering a host, an RSIP gateway must delete all binds
with that host and return their resources to the pool of
resources. Once a host has de-registered, it may not use any of
RSIP gateway's resources without registering again
9.5. DE-REGISTER_
9.5.1.
The DE-REGISTER_RESPONSE message is used by an RSIP gateway
confirm the de-registration of an RSIP host or to force an RSIP
to relinquish all of its bindings and terminate its relationship
the RSIP gateway. Upon receiving a DE-REGISTER_RESPONSE message,
RSIP host MUST stop all use of the resources that have been
to it by the gateway
9.5.2.
REGISTER_RESPONSE> ::=
[Message Counter
9.5.3.
An RSIP gateway MUST send a DE-REGISTER_RESPONSE in response to
valid DE-REGISTER_REQUEST. An RSIP gateway MUST send a DE
REGISTER_RESPONSE to an RSIP host when that host's registration
time times out. An RSIP gateway SHOULD send a DE-REGISTER_
if it detects that it will no longer be able to perform
functionality for a given host. An RSIP host MUST be ready to
a DE-REGISTER_RESPONSE at any moment
Borella, et al. Experimental [Page 20]
RFC 3103 RSIP Protocol Specification October 2001
9.6. ASSIGN_REQUEST_RSA-
9.6.1.
The ASSIGN_REQUEST_RSA-IP message is used by an RSIP host to
resources to use with RSA-IP. Note that RSA-IP cannot be used
combination with micro-flow based local policy
9.6.2.
::=
[Message Counter
[Lease Time
[Tunnel Type
9.6.3.
The RSIP host specifies two address parameters. The RSIP host
request a particular local address by placing that address in
first address parameter. To indicate that it has no preference
local address, the RSIP host may place a "don't care" value in
address parameter
If macro-flow based remote policy is used, the host MUST specify
remote address that it will use this binding (if granted) to contact
however, the remote port number MAY remain unspecified. If micro
flow based remote policy is used, the host MUST specify the
address and port number that it will use this binding (if granted)
contact. If no flow policy is used, the RSIP host may place a "don'
care" value in the value fields of the respective address and
parameters
The following message-specific error conditions exist
- If the host is not registered with the gateway, the
MUST respond with an ERROR_RESPONSE containing
REGISTER_FIRST error
- If the message contains an incorrect client ID, the
MUST respond with an ERROR_RESPONSE containing
BAD_CLIENT_ID error
Borella, et al. Experimental [Page 21]
RFC 3103 RSIP Protocol Specification October 2001
- If the local address parameter is a don't care value and
RSIP gateway cannot allocate ANY addresses, the RSIP
MUST respond with an ERROR_RESPONSE containing
LOCAL_ADDR_UNAVAILABLE error
- If the local address parameter is not a don't care value
are three possible error conditions
o If the RSIP gateway cannot allocate ANY addresses, it
respond with an ERROR_RESPONSE containing
LOCAL_ADDR_UNAVAILABLE error
o If the RSIP gateway cannot allocate the requested
because it is in use, the RSIP gateway MUST respond with
ERROR_RESPONSE containing the LOCAL_ADDR_INUSE error
o If the RSIP gateway cannot allocate the requested
because it is not allowed by policy, the RSIP gateway
respond with an ERROR_RESPONSE containing
LOCAL_ADDR_UNALLOWED error
- If macro-flow based remote policy is used and the
remote address is not allowed by the RSIP gateway's policy,
RSIP gateway MUST respond with an ERROR_RESPONSE containing
REMOTE_ADDR_UNALLOWED error
- If micro-flow based remote policy is used and the
remote address / port pair is not allowed by the RSIP gateway'
policy, the RSIP gateway MUST respond with an ERROR_
containing the REMOTE_ADDRPORT_UNALLOWED error
- If an unsupported or unallowed tunnel type is specified,
RSIP gateway MUST respond with an ERROR_RESPONSE containing
BAD_TUNNEL_TYPE error
- If the host has not specified local or remote address or
information in enough detail, the RSIP gateway MUST
with an ERROR_RESPONSE containing the FLOW_POLICY_
error
9.7. ASSIGN_RESPONSE_RSA-
9.7.1.
The ASSIGN_RESPONSE_RSA-IP message is used by an RSIP gateway
deliver parameter assignments to an RSIP host using RSA-IP. A host
wise unique bind ID, lease time, and tunnel type must be provided
every assignment
Borella, et al. Experimental [Page 22]
RFC 3103 RSIP Protocol Specification October 2001
9.7.2.
RESPONSE_RSA-IP> ::=
[Address (tunnel endpoint)]
[Message Counter
9.7.3.
If no remote flow policy is used, the RSIP gateway MUST use "don'
care" values for the remote address and ports parameters. If macro
flow based remote policy is used, the remote address parameter
contain the address specified in the associated request, and
remote ports parameter MUST contain a "don't care" value. If micro
flow based remote policy is used, the remote address and remote
parameters MUST contain the address and port information specified
the associated request
If the host detects an error or otherwise does not "understand"
gateway's response, it SHOULD send a FREE_REQUEST with the bind
from the said ASSIGN_RESPONSE_RSA-IP. This will serve to
synchronize the states of the host and gateway
The address of a tunnel endpoint that is not the RSIP gateway MAY
specified. If this parameter is not specified, the RSIP gateway
be assumed to be the tunnel endpoint
9.8. ASSIGN_REQUEST_RSAP-
9.8.1.
The ASSIGN_REQUEST_RSAP-IP message is used by an RSIP host to
resources to use with RSAP-IP. The RSIP host specifies two
and two port parameters, the first of each, respectively, refer
the local address and port(s) that will be used, and the second
each, respectively, refer to the remote address and port(s) that
be contacted
Borella, et al. Experimental [Page 23]
RFC 3103 RSIP Protocol Specification October 2001
9.8.2.
::=
[Message Counter
[Lease Time
[Tunnel Type
9.8.3.
An RSIP host may request a particular local address by placing
address in the value field of the first address parameter. The
host may request particular local ports by placing them in the
port parameter. To indicate that it has no preference for
address or ports, the RSIP host may place a "don't care" value in
respective address or ports parameters
If macro-flow based remote policy is used, the host MUST specify
remote address that it will use this binding (if granted) to contact
however, the remote port number(s) MAY remain unspecified.
micro-flow based remote policy is used, the host MUST specify
remote address and port number(s) that it will use this binding (
granted) to contact. If no flow policy is used, the RSIP host
place a value of all 0's in the value fields of the
address or port parameters
The following message-specific error conditions exist
- If the host is not registered with the gateway, the
MUST respond with an ERROR_RESPONSE containing
REGISTER_FIRST error
- If the message contains an incorrect client ID, the
MUST respond with an ERROR_RESPONSE containing
BAD_CLIENT_ID error
- If the local address parameter is a don't care value and
RSIP gateway cannot allocate ANY addresses, the RSIP
MUST respond with an ERROR_RESPONSE containing
LOCAL_ADDR_UNAVAILABLE error
Borella, et al. Experimental [Page 24]
RFC 3103 RSIP Protocol Specification October 2001
- If the local address parameter is not a don't care value
are five possible error conditions
o If the RSIP gateway cannot allocate ANY addresses, it
respond with an ERROR_RESPONSE containing
LOCAL_ADDR_UNAVAILABLE error
o If the RSIP gateway cannot allocate the requested
because it is in use, the RSIP gateway MUST respond with
ERROR_RESPONSE containing the LOCAL_ADDR_INUSE error
o If the RSIP gateway cannot allocate the requested
because it is not allowed by policy, the RSIP gateway
respond with an ERROR_RESPONSE containing
LOCAL_ADDR_UNALLOWED error
o If the RSIP gateway cannot allocate a requested address /
port tuple because it is in use, the RSIP gateway
respond with an ERROR_RESPONSE containing
LOCAL_ADDRPORT_INUSE error
o If the RSIP gateway cannot allocate a requested address /
port tuple because it is not allowed by policy, the
gateway MUST respond with an ERROR_RESPONSE containing
LOCAL_ADDRPORT_UNALLOWED error
- If the RSIP host requests a number of ports (greater that one),
but does not specify particular port numbers (i.e., uses "don'
care" values) the RSIP gateway cannot grant the entire request
the RSIP gateway MUST return an ERROR_RESPONSE containing
LOCAL_ADDRPORT_UNAVAILABLE error
- If macro-flow based remote policy is used and the
remote address is not allowed by the RSIP gateway's policy,
RSIP gateway MUST respond with an ERROR_RESPONSE containing
REMOTE_ADDR_UNALLOWED error
- If micro-flow based remote policy is used and the
remote address / port pair is not allowed by the RSIP gateway'
policy, the RSIP gateway MUST respond with an ERROR_
containing the REMOTE_ADDRPORT_UNALLOWED error
- If an unsupported or unallowed tunnel type is specified,
RSIP gateway MUST respond with an ERROR_RESPONSE containing
BAD_TUNNEL_TYPE error
Borella, et al. Experimental [Page 25]
RFC 3103 RSIP Protocol Specification October 2001
- If the host has not specified local or remote address or
information in enough detail, the RSIP gateway MUST
with an ERROR_RESPONSE containing the FLOW_POLICY_
error
9.9. ASSIGN_RESPONSE_RSAP-
9.9.1.
The ASSIGN_RESPONSE_RSAP-IP message is used by an RSIP gateway
deliver parameter assignments to an RSIP host. A host-wise
bind ID, lease time, and tunnel type must be provided for
assignment
9.9.2.
RESPONSE_RSAP-IP> ::=
[Address (tunnel endpoint)]
[Message Counter
9.9.3.
Regardless of local flow policy, a local address and port(s) MUST
assigned to the host. If macro-flow based local policy is used,
host is assigned an address and one or more ports. If micro-
based local policy is used, the host is assigned an address
exactly one port
If no remote flow policy is used, the RSIP gateway MUST use "don'
care" values for the remote address and ports parameters. If macro
flow based remote policy is used, the remote address parameter
contain the address specified in the associated request, and
remote ports parameter must contain a "don't care" value. If micro
flow based remote policy is used, the remote address and remote
parameters MUST contain the address and port information specified
the associated request
Borella, et al. Experimental [Page 26]
RFC 3103 RSIP Protocol Specification October 2001
If the host detects an error or otherwise does not "understand"
gateway's response, it SHOULD send a FREE_REQUEST with the bind
from the said ASSIGN_RESPONSE_RSAP-IP. This will serve to
synchronize the states of the host and gateway
The address of a tunnel endpoint that is not the RSIP gateway MAY
specified. If this parameter is not specified, the RSIP gateway
be assumed to be the tunnel endpoint
9.10. EXTEND_
9.10.1.
The EXTEND_REQUEST message is used to request a lease extension to
current bind. It may be used with both RSA-IP and RSAP-IP. The
MUST specify its client ID and the bind ID in question, and it
suggest a lease time to the gateway
9.10.2.
::=
[Lease Time
[Message Counter
9.10.3.
The following message-specific error conditions exist
- If the host is not registered with the gateway, the
MUST respond with an ERROR_RESPONSE containing
REGISTER_FIRST error
- If the message contains an incorrect client ID, the
MUST respond with an ERROR_RESPONSE containing
BAD_CLIENT_ID error
- If the message contains an incorrect bind ID, the gateway
respond with an ERROR_RESPONSE containing the BAD_BIND_
error
Borella, et al. Experimental [Page 27]
RFC 3103 RSIP Protocol Specification October 2001
If the RSIP gateway grants an extension to the host's lease, it
RESPOND with an appropriate EXTEND_RESPONSE message. If the lease
not renewed, the RSIP gateway MAY let it implicitly expire by
nothing or make it explicitly expire by sending an
FREE_RESPONSE message
9.11. EXTEND_
9.11.1.
The EXTEND_RESPONSE message is used by an RSIP gateway to grant
requested lease extension. The gateway MUST specify the client ID
the host, the bind ID in question, and the new assigned lease time
9.11.2.
RESPONSE> ::=
[Message Counter
9.11.3.
The RSIP gateway will determine lease time as per its local policy
The returned time is to be interpreted as the number of
before the lease expires, counting from the time at which the
is sent/received
9.12. FREE_
9.12.1.
The FREE_REQUEST message is used by an RSIP host to free a binding
The given bind ID identifies the bind to be freed. Resources
only be freed using the granularity of a bind ID
9.12.2.
::=
[Message Counter
Borella, et al. Experimental [Page 28]
RFC 3103 RSIP Protocol Specification October 2001
9.12.3.
The following message-specific error conditions exist
- If the host is not registered with the gateway, the
MUST respond with an ERROR_RESPONSE containing
REGISTER_FIRST error
- If the message contains an incorrect client ID, the
MUST respond with an ERROR_RESPONSE containing
BAD_CLIENT_ID error
- If the message contains an incorrect bind ID, the gateway
respond with an ERROR_RESPONSE containing the BAD_BIND_
error
If a host receives an error in response to a FREE_REQUEST, this
indicate that the host and gateway's states have
unsynchronized. Therefore, the host SHOULD make an effort
resynchronize, such as freeing resources then re-requesting them,
de-registering then re-registering
9.13. FREE_
9.13.1.
The FREE_RESPONSE message is used by an RSIP gateway to acknowledge
FREE_REQUEST sent by an RSIP host, and to asynchronously
resources granted to an RSIP host
9.13.2.
RESPONSE> ::=
[Message Counter
9.13.3.
An RSIP host must always be ready to accept a FREE_RESPONSE, even
its lease on the specified bind ID is not yet expired
Borella, et al. Experimental [Page 29]
RFC 3103 RSIP Protocol Specification October 2001
9.14. QUERY_
9.14.1.
A QUERY_REQUEST message is used by an RSIP host to ask an
gateway whether or not a particular address or network is local
remote. The host uses this information to determine whether
contact the host(s) directly (in the local case), or via RSIP (in
remote case).
This message defines an indicator parameter with a 1-byte value
and 2 defined values
- 1
- 2
9.14.2.
::=
[Message Counter
[Address Tuple]...
[Network Tuple]...
::= <Indicator (address)>
::= <Indicator (network)>
9.14.3.
One or more address or network tuples may be specified. Each
encodes a request regarding the locality (local or remote) of
encoded address or network. If no tuple is specified, the
gateway should interpret the message as a request for all tuples
it is willing to provide. Note that the FQDN form of the
parameter cannot be used to specify the address of a network,
only the netmask form of the address parameter can be used to
the netmask of a network
If an RSIP gateway cannot determine whether a queried host or
is local or remote, it SHOULD transmit a QUERY_RESPONSE with
response specified for the said host or network
Borella, et al. Experimental [Page 30]
RFC 3103 RSIP Protocol Specification October 2001
The following message-specific error conditions exist
- If the host is not registered with the gateway, the
MUST respond with an ERROR_RESPONSE containing
REGISTER_FIRST error
- If the message contains an incorrect client ID, the
MUST respond with an ERROR_RESPONSE containing
BAD_CLIENT_ID error
9.15. QUERY_
9.15.1.
A QUERY_RESPONSE message is used by an RSIP gateway to answer
QUERY_REQUEST from an RSIP host
This message defines an indicator parameter with a 1-byte value
and 4 defined values
- 1 local
- 2 local
- 3 remote
- 4 remote
9.15.2.
RESPONSE> ::=
[Message Counter
[Local Address Tuple]...
[Local Network Tuple]...
[Remote Address Tuple]...
[Remote Network Tuple]...
::= <Indicator (local address)>
::= <Indicator (local network)>
::= <Indicator (remote address)>
Borella, et al. Experimental [Page 31]
RFC 3103 RSIP Protocol Specification October 2001
::= <Indicator (remote network)>
9.15.3.
An RSIP gateway has some leeway in how it responds to
QUERY_REQUEST. It may just provide the information requested, if
can provide such information. It may provide its complete list
address and networks, in order to minimize the number of
that the host needs to perform in the future. How an RSIP
responds may depend on network traffic considerations as well
If an RSIP gateway sends a QUERY_RESPONSE that does not contain
tuples, or a QUERY_RESPONSE that does not contain a tuple
applies to an associated tuple in the associated QUERY_REQUEST,
should be interpreted that the RSIP gateway does not know whether
queried host or network is local or remote. Appropriate
behavior upon receipt of such a message is to assume that the
host or network is remote
Note that an RSIP gateway is not expected to maintain a complete
of all remote hosts and networks. In fact, a typical RSIP
will only maintain a list of the networks and hosts that it knows
local (private with respect to the RSIP host).
9.16. LISTEN_
9.16.1.
A LISTEN_REQUEST message is sent by an RSIP host that wants
register a service on a particular address and port number. The
must include its client ID, local address parameter and
parameters, and remote address and ports parameters. The client
suggest a lease time and one or more tunnel types
Borella, et al. Experimental [Page 32]
RFC 3103 RSIP Protocol Specification October 2001
9.16.2.
::=
[Message Counter
[Lease Time
[Tunnel Type]...
9.16.3.
If the host wants to listen on a particular address or port, it
specify these in the address and ports parameters. Otherwise it
leave one or both of these parameters with "don't care" values
If no remote flow policy is being used, the host MUST fill both
remote address and ports parameters with "don't care" values.
macro-flow based remote policy is used, the host MUST specify
remote address, but MAY or MAY NOT specify the remote port(s).
micro-flow based remote policy is used, the host MUST specify
remote address and ports parameter
Once a LISTEN_REQUEST has been granted, the RSIP gateway MUST
all packets destined to the address and port in question to the host
even if the remote host address and port tuple has not
previously contacted by the host
LISTEN_REQUEST is not necessary for RSA-IP
The following message-specific error conditions exist
- If the host is not registered with the gateway, the
MUST respond with an ERROR_RESPONSE containing
REGISTER_FIRST error
- If the message contains an incorrect client ID, the
MUST respond with an ERROR_RESPONSE containing
BAD_CLIENT_ID error
- If the local address parameter is a don't care value and
RSIP gateway cannot allocate ANY addresses, the RSIP
MUST respond with an ERROR_RESPONSE containing
LOCAL_ADDR_UNAVAILABLE error
Borella, et al. Experimental [Page 33]
RFC 3103 RSIP Protocol Specification October 2001
- If the local address parameter is not a don't care value
are five possible error conditions
o If the RSIP gateway cannot allocate ANY addresses, it
respond with an ERROR_RESPONSE containing
LOCAL_ADDR_UNAVAILABLE error
o If the RSIP gateway cannot allocate the requested
because it is in use, the RSIP gateway MUST respond with
ERROR_RESPONSE containing the LOCAL_ADDR_INUSE error
o If the RSIP gateway cannot allocate the requested
because it is not allowed by policy, the RSIP gateway
respond with an ERROR_RESPONSE containing
LOCAL_ADDR_UNALLOWED error
o If the RSIP gateway cannot allocate the requested address /
port tuple because it is in use, the RSIP gateway
respond with an ERROR_RESPONSE containing
LOCAL_ADDRPORT_INUSE error
o If the RSIP gateway cannot allocate the requested address /
port tuple because it is not allowed by policy, the
gateway MUST respond with an ERROR_RESPONSE containing
LOCAL_ADDRPORT_UNALLOWED error
- If macro-flow based remote policy is used and the
remote address is not allowed by the RSIP gateway's policy,
RSIP gateway MUST respond with an ERROR_RESPONSE containing
REMOTE_ADDR_UNALLOWED error
- If micro-flow based remote policy is used and the
remote address / port pair is not allowed by the RSIP gateway'
policy, the RSIP gateway MUST respond with an ERROR_
containing the REMOTE_ADDRPORT_UNALLOWED error
- If an unsupported or unallowed tunnel type is specified,
RSIP gateway MUST respond with an ERROR_RESPONSE containing
BAD_TUNNEL_TYPE error
- If the host has not specified local or remote address or
information in enough detail, the RSIP gateway MUST
with an ERROR_RESPONSE 