diff options
Diffstat (limited to 'doc/rfc/rfc3103.txt')
| -rw-r--r-- | doc/rfc/rfc3103.txt | 3027 |
1 files changed, 3027 insertions, 0 deletions
diff --git a/doc/rfc/rfc3103.txt b/doc/rfc/rfc3103.txt new file mode 100644 index 0000000..c3cf581 --- /dev/null +++ b/doc/rfc/rfc3103.txt @@ -0,0 +1,3027 @@ + + + + + + +Network Working Group M. Borella +Request for Comments: 3103 D. Grabelsky +Category: Experimental CommWorks + J. Lo + Candlestick Networks + K. Taniguchi + NEC USA + October 2001 + + + Realm Specific IP: Protocol Specification + +Status of this Memo + + This memo defines an Experimental Protocol for the Internet + 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 Notice + + Copyright (C) The Internet Society (2001). All Rights Reserved. + +IESG Note + + The IESG notes that the set of documents describing the RSIP + technology imply significant host and gateway changes for a complete + implementation. In addition, the floating of port numbers can cause + problems for some applications, preventing an RSIP-enabled host from + interoperating transparently with existing applications in some cases + (e.g., IPsec). Finally, there may be significant operational + complexities associated with using RSIP. Some of these and other + complications are outlined in section 6 of the RFC 3102, as well as + in the Appendices of RFC 3104. Accordingly, the costs and benefits + of using RSIP should be carefully weighed against other means of + relieving address shortage. + +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 host and gateway, so that the host can + lease some of the gateway'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 gateway to allocate addressing + and control parameters to a host such that a flow policy can be + enforced at the gateway. + + + +Borella, et al. Experimental [Page 1] + +RFC 3103 RSIP Protocol Specification October 2001 + + +Table of Contents + + 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. Introduction + + Network Address Translation (NAT) has gained popularity as a method + of separating public and private address spaces, and alleviating + network address shortages. A NAT translates the addresses of packets + leaving a first routing realm to an address from a second routing + realm, and performs the reverse function for packets entering the + first routing realm from the second routing realm. This translation + is performed transparently to the hosts in either space, and may + include modification of TCP/UDP port numbers 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 from + occurring (such as some IPsec modes, or application-layer end-to-end + encryption). + + An alternative to a NAT is an architecture that allows the hosts + 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 as a method + for address sharing that exhibits more transparency than NAT. In + particular, RSIP requires that an RSIP gateway (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 host. + An RSIP host 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 + + + + + + +Borella, et al. Experimental [Page 3] + +RFC 3103 RSIP Protocol Specification October 2001 + + + accessible from the RSIP host, but this system allows packets to + 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 number + of layer three, layer four or other values from those assigned by the + RSIP gateway in each packet bound for the second routing realm. + + This document discusses a method for assigning parameters to an RSIP + host from an RSIP gateway. The requirements, scope, and + 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 are + discussed in [RSIP-IPSEC]. + +2. Specification of Requirements + + The keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", + "SHALL", "SHALL NOT", "MAY" and "MAY NOT" that appear in this + document are to be interpreted as described in [RFC2119]. + +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 Host + + A host within the private realm that acquires publicly unique + parameters from an RSIP gateway through the use of the RSIP + client/server protocol. + + RSIP Gateway + + A router situated on the boundary between a private realm and a + public realm and owns one or more public IP addresses. An RSIP + gateway is responsible for public parameter management and + assignment to RSIP hosts. An RSIP gateway may act as a NAT router + 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 Client + + An application program that performs the client portion of the + RSIP client/server protocol. An RSIP client application MUST + exist on all RSIP hosts, and MAY exist on RSIP gateways. + + RSIP Server + + An application program that performs the server portion of the + RSIP client/server protocol. An RSIP server application MUST + exist on all RSIP gateways. + + RSA-IP: Realm Specific Address IP + + An RSIP method in which each RSIP host is allocated a unique IP + address from the public realm. Discussed in detail in [RSIP- + FRAME] + + RSAP-IP: Realm Specific Address and Port IP + + An RSIP method in which each RSIP host is allocated an IP address + (possibly shared with other RSIP hosts) and some number of per- + address unique ports from the public realm. Discussed in detail + in [RSIP-FRAME] + + 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 + host. + + Resource + + A general way to refer to an item that an RSIP host leases from an + RSIP gateway; 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 hosts 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 + + + + + +Borella, et al. Experimental [Page 5] + +RFC 3103 RSIP Protocol Specification October 2001 + + + cases.) The RSIP gateway 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 Host RSIP Gateway 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 gateway (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 gateway. Upon + assignment of these parameters, the RSIP gateway creates a mapping, + of X's addressing information and the assigned resources. This + binding enables the RSIP gateway 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 gateway, RSIP hosts + tunnel data packets across address space A to the RSIP gateway. The + RSIP gateway acts as the end point of such tunnels, stripping off the + outer headers and routing the inner packets onto the public realm. + As mentioned above, an RSIP gateway maintains a mapping of the + assigned public parameters as demultiplexing fields for uniquely + mapping them to RSIP host private addresses. When a packet from the + public realm arrives at the RSIP gateway and it matches a given set + of demultiplexing fields, then the RSIP gateway will tunnel it to the + appropriate RSIP host. 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 | + +---------+---------+---------+ + + + + + +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 hosts + and gateways 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 gateways MUST support TCP, and SHOULD support UDP. Due to the + fact that RSIP may be deployed across a wide variety of network + links, RSIP hosts SHOULD support TCP, because of TCP's robustness + across said variety of links. However, RSIP hosts MAY support UDP + instead of TCP, or both UDP and TCP. + + For RSIP hosts and gateways 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). However, these parameters MAY be + adjusted or tuned for specific link types or scenarios. + + Once a host and gateway have established a registration using either + TCP or UDP, they may not switch between the two protocols for the + duration of the registration. The decision of whether to use TCP or + UDP is made by the client, and is determined by the transport + protocol of the first packet sent by a client in a successful + registration procedure. + +6. Host / Gateway Relationships + + An RSIP host can be in exactly one of three fundamental relationships + with respect to an RSIP gateway: + + Unregistered: The RSIP gateway does not know of the RSIP host's + existence, and it will not forward or deliver globally addressed + packets on behalf of the host. The only valid RSIP-related action + for an RSIP host to perform in this state is to request + registration with an RSIP gateway. + + Registered: The RSIP gateway knows of the RSIP host and has assigned + it a client ID and has specified the flow policies that it + requires of the host. However, no resources, such as addresses or + ports, have been allocated to the host, and the gateway will not + forward or deliver globally addressed packets on behalf of the + host. All registrations have an associated lease time. If this + lease time expires, the RSIP host automatically reverts to the + 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 of + resources to the host. The gateway will forward and deliver + globally addressed packets on behalf of the host. Each binding + has an associated lease time. If this lease time expires, the + binding is automatically revoked. + + Architectures in which an RSIP host is simultaneously registered with + more than one RSIP gateway are possible. In such cases, an RSIP host + may be in different relationships with different RSIP gateways at the + same time. + + An RSIP gateway MAY redirect an RSIP host to use a tunnel endpoint + for data traffic that is not the RSIP gateway itself, or perhaps is a + different interface on the RSIP gateway. This is done by specifying + the tunnel endpoint's address as part of an assignment. In such an + architecture, it is desirable (though not necessary) for the RSIP + gateway to have a method with which to notify the tunnel endpoint of + 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. Under + this registration, multiple bindings may be established, each with + their own expiration times (B1, B2, ...). When each binding is + established or extended, the registration expiration time is adjusted + so that the registration will last at least as long as the longest + 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 any + binding's lease is still valid. However, a registration may expire + when the last binding's lease expires, or at some point thereafter. + +7. Gateway Flow Policy and State + + Since an RSIP gateway is likely to reside on the boundary between two + or more different administrative domains, it is desirable to enable + an RSIP gateway to be able to enforce flow-based policy. In other + words, an RSIP gateway 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 + + + +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, which + indicates that the RSIP gateway does not care about the flow + parameters used by RSIP hosts. 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 + gateway has over the local addressing parameters that an RSIP host + uses for particular sessions. + + Since an RSIP host must use at least an IP address allocated by the + gateway, the loosest level of local flow policy is macro-flow based. + Under local macro-flow policy, an RSIP host is allocated an IP + address (RSA-IP) or an IP address and one or more ports to use with + it (RSAP-IP). However, the host may use the ports as it desires for + establishing sessions with public hosts. + + Under micro-flow policy, a host is allocated exactly one port at a + time. The host may request more ports, also one at a time. This + 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, 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 + gateway has over the remote (public) hosts with which an RSIP host + communicates. In particular, remote flow policy dictates what level + of detail that a host must specify addressing parameters of a remote + host or application before the RSIP gateway allows the host 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 gateway allocates addressing parameters to the + host, and the host may use these parameters to communicate with any + remote host, without explicitly notifying the gateway. + + Macro-flow policy requires that the host 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 host + MUST use the specified local parameters only with the remote address + specified, and MUST NOT communicate with the remote address using any + + + +Borella, et al. Experimental [Page 9] + +RFC 3103 RSIP Protocol Specification October 2001 + + + local parameters but the ones allocated. However, the host may + contact any port number at the remote host without explicitly + notifying the gateway. + + Micro-flow policy requires that the host 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 host 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 gateway. + +7.3. Gateway State + + An RSIP gateway must maintain state for all RSIP hosts and their + assigned resources. The amount and type of state maintained depends + on the local and remote flow policy. The required RSIP gateway state + will vary based on the RSIP method, but will always include the + chosen method's demultiplexing parameters. + +7.3.1. RSA-IP State + + An RSIP gateway serving an RSIP host using the RSA-IP method MUST + maintain the following minimum state to ensure proper mapping of + incoming packets to RSIP hosts: + + - Host's private address + - Host's assigned public address(es) + +7.3.2. RSAP-IP State + + An RSIP gateway serving an RSIP host using the RSAP-IP method MUST + maintain the following minimum state to ensure proper mapping of + incoming packets to RSIP hosts: + + - Host's private address + - Host's assigned public address(es) + - Host's assigned port(s) per address + +7.3.3. Flow State + + 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 following + state must be maintained: + + - Remote host's address + + If the gateway 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 gateway 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 host and gateway. The general format of all + parameters is TLV (type-length-value) consisting of a 1-byte type + followed by a 2-byte length followed by a 'length' byte value as + 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 per + the type of the parameter. Note that the length field encodes the + number of bytes in the value field, NOT the overall number of bytes + in the parameter. + +8.1. Address + + 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 IPv4 + address or netmask, an IPv6 address or netmask, or a fully qualified + 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 varies + + For FQDN (Fully qualified domain name), the length of the address + field will be one less than the value of the length field, and the + name will be represented as an ASCII string (no terminating + character). + + 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 host 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 + + 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 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. + + + + + +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 one + or more ports (e.g., when a client application is using ephemeral + source 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. + +8.3. Lease Time + + 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 an + RSIP host registration or parameter binding. + +8.4. Client ID + + 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's + by an RSIP gateway to differentiate RSIP hosts. + +8.5. Bind ID + + 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 used + 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 Type + + 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 between + an RSIP host and an RSIP gateway. Defined tunnel types are: + + Tunnel Type + ----------- + 0 Reserved + 1 IP-IP + 2 GRE + 3 L2TP + +8.7. RSIP Method + + 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 RSIP + methods are: + + RSIP method + ----------- + 0 Reserved + 1 RSA-IP + 2 RSAP-IP + +8.8. Error + + 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 error + values are presented in Appendix A. + + + + +Borella, et al. Experimental [Page 14] + +RFC 3103 RSIP Protocol Specification October 2001 + + +8.9. Flow Policy + + 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 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 + + 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 of + which is defined by the message that it appears in. An RSIP message + that uses an indicator parameter MUST define the meaning and + 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 Counter + + 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 with + sequentially-increasing values. Message counters MUST be used with + UDP, in order to facilitate reliability. + +8.12. Vendor Specific Parameter + + 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 are + defined by a particular vendor. The vendor ID field is the vendor- + specific ID assigned by IANA. Subtypes are defined and used by each + vendor as necessary. An RSIP host or gateway 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. + 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 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 are 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 BNF. Required 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 host and/or + gateway 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 + gateway to an RSIP host. Usually, errors indicate that the RSIP + gateway cannot or will not perform an action or allocate resources on + behalf of the host. 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 more than one error has occurred, the RSIP gateway + MUST choose only one error to report. + + + + +Borella, et al. Experimental [Page 17] + +RFC 3103 RSIP Protocol Specification October 2001 + + +9.1.2. Format + + <ERROR_RESPONSE> ::= <Version> + <Message Type> + <Overall Length> + <Error> + [Message Counter] + [Client ID] + [Bind ID] + +9.1.3. Behavior + + An ERROR_RESPONSE message MUST only be transmitted by an RSIP + gateway. An RSIP host that detects an error in a message received + from an RSIP gateway 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 host, but also may be transmitted asynchronously by an RSIP + gateway. + +9.2. REGISTER_REQUEST + +9.2.1. Description + + The REGISTER_REQUEST message is used by an RSIP host to establish + registration with an RSIP gateway. An RSIP host MUST register before + it requests resources or services from an RSIP gateway. Once an RSIP + host has registered with an RSIP gateway, it may not register again + until it has de-registered from that gateway. + +9.2.2. Format + + <REGISTER_REQUEST> ::= <Version> + <Message Type> + <Overall Length> + [Message Counter] + +9.2.3. Behavior + + The following message-specific error conditions exist: + + - If the host is already registered with the gateway, the gateway + MUST respond with an ERROR_RESPONSE containing the + 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 the + REGISTRATION_DENIED error. + + + +Borella, et al. Experimental [Page 18] + +RFC 3103 RSIP Protocol Specification October 2001 + + +9.3. REGISTER_RESPONSE + +9.3.1. Description + + The REGISTER_RESPONSE message is used by an RSIP gateway to confirm + the registration of an RSIP host, and to provide a client ID, flow + policy, and possibly a message counter and one or more RSIP methods + and/or tunnel types. + +9.3.2. Format + + <REGISTER_RESPONSE> ::= <Version> + <Message Type> + <Overall Length> + <Client ID> + <Lease time> + <Flow Policy> + [Message Counter] + [RSIP Method]... + [Tunnel Type]... + +9.3.3. Behavior + + An RSIP gateway MUST assign a different client ID to each host that + is simultaneously registered with it. The RSIP gateway 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 + +9.4.1. Description + + The DE-REGISTER_REQUEST message is used by an RSIP host to de- + register with an RSIP gateway. If a host de-registers from the + assigned state, all of the host's bindings are revoked. The host + SHOULD NOT de-register from the unregistered state. + +9.4.2. Format + + <DE-REGISTER_REQUEST> ::= <Version> + <Message Type> + <Overall Length> + <Client ID> + [Message Counter] + + + + + + +Borella, et al. Experimental [Page 19] + +RFC 3103 RSIP Protocol Specification October 2001 + + +9.4.3. Behavior + + The following message-specific error conditions exist: + + - If the host is not registered with the gateway, the gateway + MUST respond with an ERROR_RESPONSE containing the + REGISTER_FIRST error. + + - If the message contains an incorrect client ID, the gateway + MUST respond with an ERROR_RESPONSE containing the + BAD_CLIENT_ID error. + + If there are no errors that result from this message, the gateway + MUST respond with an appropriate DE-REGISTER_RESPONSE. Upon de- + registering a host, an RSIP gateway must delete all binds associated + with that host and return their resources to the pool of free + resources. Once a host has de-registered, it may not use any of the + RSIP gateway's resources without registering again. + +9.5. DE-REGISTER_RESPONSE + +9.5.1. Description + + The DE-REGISTER_RESPONSE message is used by an RSIP gateway to + confirm the de-registration of an RSIP host or to force an RSIP host + to relinquish all of its bindings and terminate its relationship with + the RSIP gateway. Upon receiving a DE-REGISTER_RESPONSE message, an + RSIP host MUST stop all use of the resources that have been allocated + to it by the gateway. + +9.5.2. Format + + <DE-REGISTER_RESPONSE> ::= <Version> + <Message Type> + <Overall Length> + <Client ID> + [Message Counter] + +9.5.3. Behavior + + An RSIP gateway MUST send a DE-REGISTER_RESPONSE in response to a + valid DE-REGISTER_REQUEST. An RSIP gateway MUST send a DE- + REGISTER_RESPONSE to an RSIP host when that host's registration lease + time times out. An RSIP gateway SHOULD send a DE-REGISTER_RESPONSE + if it detects that it will no longer be able to perform RSIP + functionality for a given host. An RSIP host MUST be ready to accept + 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-IP + +9.6.1. Description + + The ASSIGN_REQUEST_RSA-IP message is used by an RSIP host 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)> + [Message Counter] + [Lease Time] + [Tunnel Type] + +9.6.3. Behavior + + The RSIP host specifies two address parameters. The RSIP host 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 host may place a "don't care" value in the + address parameter. + + If macro-flow based remote policy is used, the host MUST specify the + 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 remote + address and port number that it will use this binding (if granted) to + contact. If no flow policy is used, the RSIP host may place a "don't + care" value in the value fields of the respective address and ports + parameters. + + The following message-specific error conditions exist: + + - If the host is not registered with the gateway, the gateway + MUST respond with an ERROR_RESPONSE containing the + REGISTER_FIRST error. + + - If the message contains an incorrect client ID, the gateway + MUST respond with an ERROR_RESPONSE containing the + 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 the + RSIP gateway cannot allocate ANY addresses, the RSIP gateway + 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 gateway cannot allocate ANY addresses, it MUST + respond with an ERROR_RESPONSE containing the + LOCAL_ADDR_UNAVAILABLE error. + + o If the RSIP gateway cannot allocate the requested address + because it is in use, the RSIP gateway MUST respond with an + ERROR_RESPONSE containing the LOCAL_ADDR_INUSE error. + + o If the RSIP gateway cannot allocate the requested address + because it is not allowed by policy, the RSIP gateway 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 gateway's policy, the + RSIP gateway 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 gateway's + policy, the RSIP gateway MUST respond with an ERROR_RESPONSE + containing the REMOTE_ADDRPORT_UNALLOWED error. + + - If an unsupported or unallowed tunnel type is specified, the + RSIP gateway MUST respond with an ERROR_RESPONSE containing the + BAD_TUNNEL_TYPE error. + + - If the host has not specified local or remote address or port + information in enough detail, the RSIP gateway 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 gateway to + deliver parameter assignments to an RSIP host using RSA-IP. A host- + wise unique bind ID, lease time, and tunnel type must be provided for + every assignment. + + + +Borella, et al. Experimental [Page 22] + +RFC 3103 RSIP Protocol Specification October 2001 + + +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> + [Address (tunnel endpoint)] + [Message Counter] +9.7.3. Behavior + + If no remote flow policy is used, the RSIP gateway 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 host detects an error or otherwise does not "understand" the + gateway'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 the states of the host and gateway. + + The address of a tunnel endpoint that is not the RSIP gateway MAY be + specified. If this parameter is not specified, the RSIP gateway MUST + be assumed to be the tunnel endpoint. + +9.8. ASSIGN_REQUEST_RSAP-IP + +9.8.1. Description + + The ASSIGN_REQUEST_RSAP-IP message is used by an RSIP host to request + resources to use with RSAP-IP. The RSIP host 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. + + + + + + + +Borella, et al. Experimental [Page 23] + +RFC 3103 RSIP Protocol Specification October 2001 + + +9.8.2. Format + + <ASSIGN_REQUEST_RSAP-IP> ::= <Version> + <Message Type> + <Overall Length> + <Client ID> + <Address (local)> + <Ports (local)> + <Address (remote)> + <Ports (remote)> + [Message Counter] + [Lease Time] + [Tunnel Type] + +9.8.3. Behavior + + An RSIP host may request a particular local address by placing that + address in the value field of the first address parameter. The RSIP + host 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 host may place a "don't care" value in the + respective address or ports parameters. + + If macro-flow based remote policy is used, the host 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 host 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 host 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: + + - If the host is not registered with the gateway, the gateway + MUST respond with an ERROR_RESPONSE containing the + REGISTER_FIRST error. + + - If the message contains an incorrect client ID, the gateway + 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 gateway cannot allocate ANY addresses, the RSIP gateway + MUST respond with an ERROR_RESPONSE containing the + 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 there + are five possible error conditions: + + o If the RSIP gateway cannot allocate ANY addresses, it MUST + respond with an ERROR_RESPONSE containing the + LOCAL_ADDR_UNAVAILABLE error. + + o If the RSIP gateway cannot allocate the requested address + because it is in use, the RSIP gateway MUST respond with an + ERROR_RESPONSE containing the LOCAL_ADDR_INUSE error. + + o If the RSIP gateway cannot allocate the requested address + because it is not allowed by policy, the RSIP gateway MUST + respond with an ERROR_RESPONSE containing the + LOCAL_ADDR_UNALLOWED error. + + o If the RSIP gateway cannot allocate a requested address / + port tuple because it is in use, the RSIP gateway MUST + respond with an ERROR_RESPONSE containing the + LOCAL_ADDRPORT_INUSE error. + + o If the RSIP gateway cannot allocate a requested address / + port tuple because it is not allowed by policy, the RSIP + gateway MUST respond with an ERROR_RESPONSE containing the + 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't + care" values) the RSIP gateway cannot grant the entire request, + the RSIP gateway MUST return an ERROR_RESPONSE containing the + LOCAL_ADDRPORT_UNAVAILABLE error. + + - If macro-flow based remote policy is used and the requested + remote address is not allowed by the RSIP gateway's policy, the + RSIP gateway 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 gateway's + policy, the RSIP gateway MUST respond with an ERROR_RESPONSE + containing the REMOTE_ADDRPORT_UNALLOWED error. + + - If an unsupported or unallowed tunnel type is specified, the + RSIP gateway MUST respond with an ERROR_RESPONSE containing the + 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 port + information in enough detail, the RSIP gateway 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 gateway to + deliver parameter assignments to an RSIP host. A host-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> + [Address (tunnel endpoint)] + [Message Counter] + +9.9.3. Behavior + + Regardless of local flow policy, a local address and port(s) MUST be + assigned to the host. If macro-flow based local policy is used, the + host is assigned an address and one or more ports. If micro-flow + based local policy is used, the host is assigned an address and + exactly one port. + + If no remote flow policy is used, the RSIP gateway 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. + + + + + +Borella, et al. Experimental [Page 26] + +RFC 3103 RSIP Protocol Specification October 2001 + + + If the host detects an error or otherwise does not "understand" the + gateway'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 host and gateway. + + The address of a tunnel endpoint that is not the RSIP gateway MAY be + specified. If this parameter is not specified, the RSIP gateway MUST + be assumed to be the tunnel endpoint. + +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 host + MUST specify its client ID and the bind ID in question, and it MAY + suggest a lease time to the gateway. + +9.10.2. Format + + <EXTEND_REQUEST> ::= <Version> + <Message Type> + <Overall Length> + <Client ID> + <Bind ID> + [Lease Time] + [Message Counter] + +9.10.3. Behavior + + The following message-specific error conditions exist: + + - If the host is not registered with the gateway, the gateway + MUST respond with an ERROR_RESPONSE containing the + REGISTER_FIRST error. + + - If the message contains an incorrect client ID, the gateway + MUST respond with an ERROR_RESPONSE containing the + BAD_CLIENT_ID error. + + - If the message contains an incorrect bind ID, the gateway MUST + respond with an ERROR_RESPONSE containing the BAD_BIND_ID + 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 MUST + RESPOND with an appropriate EXTEND_RESPONSE message. If the lease is + not renewed, the RSIP gateway MAY let it implicitly expire by doing + nothing or make it explicitly expire by sending an appropriate + FREE_RESPONSE message. + +9.11. EXTEND_RESPONSE + +9.11.1. Description + + The EXTEND_RESPONSE message is used by an RSIP gateway to grant a + requested lease extension. The gateway MUST specify the client ID of + the host, 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> + [Message Counter] + +9.11.3. Behavior + + The RSIP gateway will determine lease time as per its local policy. + The returned time is to be interpreted as the number of seconds + before the lease expires, counting from the time at which the message + is sent/received. + +9.12. FREE_REQUEST + +9.12.1. Description + + 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 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> + [Message Counter] + + + + +Borella, et al. Experimental [Page 28] + +RFC 3103 RSIP Protocol Specification October 2001 + + +9.12.3. Behavior + + The following message-specific error conditions exist: + + - If the host is not registered with the gateway, the gateway + MUST respond with an ERROR_RESPONSE containing the + REGISTER_FIRST error. + + - If the message contains an incorrect client ID, the gateway + MUST respond with an ERROR_RESPONSE containing the + BAD_CLIENT_ID error. + + - If the message contains an incorrect bind ID, the gateway MUST + respond with an ERROR_RESPONSE containing the BAD_BIND_ID + error. + + If a host receives an error in response to a FREE_REQUEST, this may + indicate that the host and gateway's states have become + unsynchronized. Therefore, the host 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 gateway to acknowledge a + FREE_REQUEST sent by an RSIP host, and to asynchronously deallocate + resources granted to an RSIP host. + +9.13.2. Format + + <FREE_RESPONSE> ::= <Version> + <Message Type> + <Overall Length> + <Client ID> + <Bind ID> + [Message Counter] + +9.13.3. Behavior + + An RSIP host must always be ready to accept a FREE_RESPONSE, even if + 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_REQUEST + +9.14.1. Description + + A QUERY_REQUEST message is used by an RSIP host to ask an RSIP + gateway whether or not a particular address or network is local or + remote. The host 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: + + - 1 address + - 2 network + +9.14.2. Format + + <QUERY_REQUEST> ::= <Version> + <Message Type> + <Overall Length> + <Client ID> + [Message Counter] + [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 + gateway 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 gateway 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. + + + +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 gateway + MUST respond with an ERROR_RESPONSE containing the + REGISTER_FIRST error. + + - If the message contains an incorrect client ID, the gateway + MUST respond with an ERROR_RESPONSE containing the + BAD_CLIENT_ID error. + +9.15. QUERY_RESPONSE + +9.15.1. Description + + A QUERY_RESPONSE message is used by an RSIP gateway to answer a + QUERY_REQUEST from an RSIP host. + + 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> + [Message Counter] + [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> + + + +Borella, et al. Experimental [Page 31] + +RFC 3103 RSIP Protocol Specification October 2001 + + + <Remote Network Tuple> ::= <Indicator (remote network)> + <Address (network)> + <Address (netmask)> + +9.15.3. Behavior + + An RSIP gateway 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 number of requests + that the host needs to perform in the future. How an RSIP gateway + responds may depend on network traffic considerations as well. + + If an RSIP gateway 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 gateway does not know whether the + queried host or network is local or remote. Appropriate host + behavior upon receipt of such a message is to assume that the queried + host or network is remote. + + Note that an RSIP gateway is not expected to maintain a complete list + of all remote hosts and networks. In fact, a typical RSIP gateway + will only maintain a list of the networks and hosts that it knows are + local (private with respect to the RSIP host). + +9.16. LISTEN_REQUEST + +9.16.1. Description + + A LISTEN_REQUEST message is sent by an RSIP host that wants to + register a service on a particular address and port number. The host + 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. + + + + + + + + + + + + + + + + +Borella, et al. Experimental [Page 32] + +RFC 3103 RSIP Protocol Specification October 2001 + + +9.16.2. Format + + <LISTEN_REQUEST> ::= <Version> + <Message Type> + <Overall Length> + <Client ID> + <Address (local)> + <Ports (local)> + <Address (remote)> + <Ports (remote)> + [Message Counter] + [Lease Time] + [Tunnel Type]... + +9.16.3. Behavior + + If the host 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. + + If no remote flow policy is being used, the host MUST fill both the + remote address and ports parameters with "don't care" values. If + macro-flow based remote policy is used, the host MUST specify the + remote address, but MAY or MAY NOT specify the remote port(s). If + micro-flow based remote policy is used, the host MUST specify the + remote address and ports parameter. + + Once a LISTEN_REQUEST has been granted, the RSIP gateway MUST forward + all packets destined to the address and port in question to the host, + even if the remote host address and port tuple has not been + 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 gateway + MUST respond with an ERROR_RESPONSE containing the + REGISTER_FIRST error. + + - If the message contains an incorrect client ID, the gateway + 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 gateway cannot allocate ANY addresses, the RSIP gateway + MUST respond with an ERROR_RESPONSE containing the + 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 there + are five possible error conditions: + + o If the RSIP gateway cannot allocate ANY addresses, it MUST + respond with an ERROR_RESPONSE containing the + LOCAL_ADDR_UNAVAILABLE error. + + o If the RSIP gateway cannot allocate the requested address + because it is in use, the RSIP gateway MUST respond with an + ERROR_RESPONSE containing the LOCAL_ADDR_INUSE error. + + o If the RSIP gateway cannot allocate the requested address + because it is not allowed by policy, the RSIP gateway MUST + respond with an ERROR_RESPONSE containing the + LOCAL_ADDR_UNALLOWED error. + + o If the RSIP gateway cannot allocate the requested address / + port tuple because it is in use, the RSIP gateway MUST + respond with an ERROR_RESPONSE containing the + LOCAL_ADDRPORT_INUSE error. + + o If the RSIP gateway cannot allocate the requested address / + port tuple because it is not allowed by policy, the RSIP + gateway 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 gateway's policy, the + RSIP gateway 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 gateway's + policy, the RSIP gateway MUST respond with an ERROR_RESPONSE + containing the REMOTE_ADDRPORT_UNALLOWED error. + + - If an unsupported or unallowed tunnel type is specified, the + RSIP gateway MUST respond with an ERROR_RESPONSE containing the + BAD_TUNNEL_TYPE error. + + - If the host has not specified local or remote address or port + information in enough detail, the RSIP gateway MUST respond + with an ERROR_RESPONSE containing the FLOW_POLICY_VIOLATION + error. + + + + + + + +Borella, et al. Experimental [Page 34] + +RFC 3103 RSIP Protocol Specification October 2001 + + +9.17. LISTEN_RESPONSE + +9.17.1. Description + + A LISTEN_RESPONSE message is used by an RSIP gateway to respond to a + LISTEN_REQUEST message from an RSIP host. The RSIP gateway MUST + issue a bind ID, and specify the address and port which have been + granted to the host. The gateway must also specify a tunnel type and + lease time. + + If no remote flow policy is being used, the gateway MUST fill both + the remote address and ports parameters with "don't care" values. If + macro-flow based remote policy is used, the gateway MUST specify the + remote address, but MAY or MAY NOT specify the remote port(s). If + micro-flow based remote policy is used, the gateway MUST specify the + remote address and ports parameter. + +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> + [Address (tunnel endpoint)] + [Message Counter] + + +9.17.3. Behavior + + If no remote flow policy is being used, the gateway MUST fill both + the remote address and ports parameters with "don't care" values. If + macro-flow based remote policy is used, the gateway MUST specify the + remote address, but MAY or MAY NOT specify the remote port(s). If + micro-flow based remote policy is used, the gateway MUST specify the + remote address and ports parameter. + + The address of a tunnel endpoint that is not the RSIP gateway MAY be + specified. If this parameter is not specified, the RSIP gateway MUST + be assumed to be the tunnel endpoint. + + + + + +Borella, et al. Experimental [Page 35] + +RFC 3103 RSIP Protocol Specification October 2001 + + +10. Discussion + +10.1. Use of Message Counters, Timeouts, and Retransmissions + + Message counters are conceptually similar to sequence numbers. They + are necessary to facilitate reliability when UDP is the transport + protocol. Each UDP message is marked with a message counter. When + such a message is transmitted, the message is stored in a "last + message" buffer. For RSIP hosts, a timer is set to expire at the + appropriate timeout value. + + General rules: + + - When an RSIP host transmits a message with a message counter + value of n, the RSIP gateway's response will contain a message + counter value of n. + + - An RSIP host will not increment its message counter value to + n+1 until it receives a message from the RSIP gateway with a + message counter value of n. + + - An RSIP gateway begins all sessions with a message counter + value of 1. + + - If the message counter value reaches the maximum possible 32- + bit value, it will wrap around to 1, not 0. + + - If a message with a message counter value of n is transmitted + by an RSIP host, but a timer expires before a response to that + message is received, the copy of the message (from the "last + message" buffer) is retransmitted. + + - When an RSIP gateway receives a duplicate copy of a message + with a message counter value of n, it transmits the contents of + its "last message" buffer. + + - When the RSIP gateway transmits an asynchronous RSIP message + (an RSIP message for which there was no request by the RSIP + host), a message counter value of 0 MUST be used. Note that + only three RSIP messages can be transmitted asynchronously: + ERROR_RESPONSE, DE-REGISTER_RESPONSE, and FREE_RESPONSE. These + messages may also be transmitted in response to an RSIP host + request, so their message counter values MAY be non-zero. + + - If a message counter is not present in a message from an RSIP + host, but is required, the RSIP gateway MUST respond with an + ERROR_RESPONSE containing the MESSAGE_COUNTER_REQUIRED error. + + + + +Borella, et al. Experimental [Page 36] + +RFC 3103 RSIP Protocol Specification October 2001 + + +10.2. RSIP Host and Gateway Failure Scenarios + + When either the RSIP host or gateway suffers from an unrecoverable + failure, such as a crash, all RSIP-related state will be lost. In + this section, we describe the sequence of events that will occur in + both host and gateway failures, and how the host and gateway re- + synchronize. + +10.2.1. Host Failure + + After a host failure, the host will reboot and be unaware of any RSIP + state held on its behalf at the gateway. + + If the host does not immediately attempt to re-establish a session, + it may receive RSIP packets on the RSIP client application port that + it was using before it rebooted. If an RSIP client application is + not active on this port, these packets will be responded to with ICMP + port unreachable messages. If TCP is the transport protocol, it is + likely that the connection will be terminated with a TCP RST. If an + RSIP client is active on this port, it will not recognize the session + that these packets belong to, and it SHOULD silently ignore them. + + The RSIP host may also receive packets from a remote host with which + it was communicating before it rebooted. These packets will be + destined to the RSIP tunnel interface, which should not exist. Thus + they SHOULD be silently discarded by the RSIP host's stack, or the + RSIP host will transmit appropriate ICMP messages to the tunnel + endpoint (e.g., the RSIP gateway). The behavior of the system with + respect to sessions that were active before the reboot should be + similar to that of a publically addressable non-RSIP host that + reboots. + + Upon rebooting, an RSIP host may attempt to establish a new RSIP + session with the RSIP gateway. Upon receiving the REGISTER_REQUEST + message, the RSIP gateway will be able to determine that, as far as + it is concerned, the RSIP host is already registered. Thus, it will + transmit an ERROR_RESPONSE with the ALREADY_REGISTERED message. Upon + receipt of this message, the RSIP host will know the client ID of its + old registration, and SHOULD immediately transmit a DE- + REGISTER_REQUEST using this client ID. After this is accomplished, + the states of the RSIP host and gateway have been synchronized, and a + new RSIP session may be established. + + If the RSIP host does not de-register itself from the RSIP gateway, + it will eventually receive a DE-REGISTER_RESPONSE from the gateway, + when the gateway times out the host's session. Since the DE- + REGISTER_RESPONSE will refer to a client ID that has no meaning to + + + + +Borella, et al. Experimental [Page 37] + +RFC 3103 RSIP Protocol Specification October 2001 + + + the host, the host SHOULD silently ignore such a message. At this + point, the states of the RSIP host and gateway have been + synchronized, and a new RSIP session may be established. + +10.2.2. Gateway Failure + + After a gateway failure, the gateway will reboot and be unaware of + any RSIP state held by an RSIP host. + + Since the gateway will not attempt to contact any of its RSIP hosts, + a problem will first be detected when either an RSIP host sends an + RSIP message to the gateway, an RSIP host sends tunneled data to the + gateway, or data from a remote host intended for an RSIP host + arrives. + + In the first case, the RSIP gateway SHOULD immediately response to + all messages (except for a REGISTER_REQUEST) with an ERROR_RESPONSE + with a REGISTER_FIRST error. Upon receipt of such a message, an RSIP + host MUST interpret the message as an indication of a loss of + synchronization between itself and the RSIP gateway. The RSIP host + SHOULD immediately transmit a DE-REGISTRATION_REQUEST with its old + client ID (which will generate another error, but this error SHOULD + be ignored by the host). At this point, the states of the RSIP host + and gateway have been synchronized, and a new RSIP session may be + established. + + In the second case, all data that an RSIP host sends to the tunneled + interface of an RSIP server will either (1) be discarded silently, + (2) responded to with an ICMP Destination Unreachable message, such + as "Communication Administratively Prohibited", or (3) blindly routed + to the intended destination. In all of the above cases, the RSIP + gateway will not have an explicit method to notify the RSIP host of + the problem. To prevent a long term communications outage, small + lease times of several minutes can be set by the RSIP gateway. + + In the third case, the RSIP gateway SHOULD discard all incoming + packets and/or respond with ICMP Port Unreachable messages. + +10.3. General Gateway Policy + + There is a significant amount of RSIP gateway policy that may be + implemented, but is beyond the scope of this document. We expect + that most of this policy will be site-specific or implementation- + specific and therefore do not make any recommendations. Examples of + general gateway policy include: + + - How ports are allocated to RSIP hosts. + - Preferred length of lease times. + + + +Borella, et al. Experimental [Page 38] + +RFC 3103 RSIP Protocol Specification October 2001 + + + - How flow policy is applied to which hosts. + - How an RSIP gateway with multiple public IP addresses that may + be leased by RSIP clients determines how to partition + and/or lease these addresses. + +10.4. Errors Not From the RSIP Protocol + + Once an RSIP host and gateway have established a relationship and the + host is assigned resources to use, error may occur due to the host's + misuse of the resources or its attempting to use unassigned + resources. The following error behavior is defined: + + - If a host attempts to use a local address which it has not been + allocated, the RSIP gateway MUST drop the associated packet(s) + and send the host an ERROR_RESPONSE containing the + LOCAL_ADDR_UNALLOWED error. + + - If a host attempts to use a local address / port tuple which it + has not been allocated, the RSIP gateway MUST drop the + associated packet(s) and send the host an ERROR_RESPONSE + containing the LOCAL_ADDRPORT_UNALLOWED error. + + - If a host 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 gateway MUST drop the associated packet(s) + and send the host an ERROR_RESPONSE containing the + REMOTE_ADDR_UNALLOWED error. + + - If a host 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 gateway MUST drop the associated + packet(s) and send the host an ERROR_RESPONSE containing the + REMOTE_ADDRPORT_UNALLOWED error. + + - If a host attempts to establish or use an improper tunnel type, + the RSIP gateway MUST respond with an ERROR_RESPONSE containing + the BAD_TUNNEL_TYPE error. + + - If the RSIP gateway's detects a local fault which prevents its + RSIP server module from continuing operation, the RSIP gateway + MUST respond with an ERROR_RESPONSE containing the + INTERNAL_SERVER_ERROR error. + + + + + + + +Borella, et al. Experimental [Page 39] + +RFC 3103 RSIP Protocol Specification October 2001 + + +10.5. Address and Port Requests and Allocation + + Regardless of local flow policy, an RSIP host may "suggest" that it + would like to use a particular local address and/or port number in a + particular binding. An RSIP gateway 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.6. Local Gateways and Flow Policy Interaction + + An RSIP host may initialize a publically accessible gateway (such as + an FTP or HTTP gateway) by transmitting a LISTEN_REQUEST message to + an RSIP gateway and receiving a LISTEN_RESPONSE. However, unless no + remote flow policy is used, the gateway 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 hosts that require their gateways to be accessible by any + remote host. + + This indicates that there is a conflict between flow-based policy and + support for gateways. The main purpose of enforcing flow-based + policy for LISTEN_REQUESTs is that it allows an RSIP gateway tight + control over how an RSIP host uses ports and the associated + accounting. For example, an RSIP host, 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 gateway will transmit data + from, in a LISTEN_REQUEST. + + In general, an RSIP gateway may not allow arbitrary hosts to start + public gateways because of the traffic and security concerns. Thus, + we recommend that if remote micro-flow based policy is used, that an + RSIP gateway only allow public gateways on RSIP hosts via + administrative override. + + Currently, RSIP hosts 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. + + + + + + +Borella, et al. Experimental [Page 40] + +RFC 3103 RSIP Protocol Specification October 2001 + + + An RSIP gateway should take all measures deemed necessary to prevent + its hosts from performing intentional or unintentional denial-of- + service attacks by request large sets of resources. + + Currently, RSIP hosts can only be identified by their local IP + address or, in some cases, MAC address. It is desirable to allow + RSIP messages sent between a host and gateway 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 have been registered by the IANA. + + - RSIP port number: 4555 + - 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: + + - 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. Acknowledgements + + The authors would like to specifically thank Gabriel Montenegro, Pyda + Srisuresh, Brian Carpenter, Eliot Lear, Dan Nessett, Gary Jaszewski, + Naveen Rajanikantha, Sudhakar Ramakrishna, Jim March, and Rick Cobb + for their input. The IETF NAT working group as a whole has been + extremely helpful in the ongoing development of RSIP. + + + + + + + + + + + + +Borella, et al. Experimental [Page 41] + +RFC 3103 RSIP Protocol Specification October 2001 + + +14. Appendix A: RSIP Error Numbers + + This section provides descriptions for the error values in the RSIP + error parameter. + + 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 host has attempted to use UDP on a server that + only supports TCP. + + 103: FLOW_POLICY_VIOLATION: A host has not specified address or + port information in enough detail for its assigned flow policy. + + 104: INTERNAL_SERVER_ERROR: An RSIP server application has + detected an unrecoverable error within itself or the RSIP + gateway. + + 105: MESSAGE_COUNTER_REQUIRED: An RSIP host did not use a message + counter parameter in a situation in which it should have. + + 106: UNSUPPORTED_RSIP_VERSION: An RSIP host sent a message with a + version number that is not supported by the RSIP gateway. + + 200's: Parameter and message errors. The gateway 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 gateway does not understand a parameter + type. + + 205: BAD_PARAM. A parameter is malformed. + + + + + +Borella, et al. Experimental [Page 42] + +RFC 3103 RSIP Protocol Specification October 2001 + + + 206: ILLEGAL_MESSAGE. The gateway does not understand the message + type. The message type is neither mandatory nor optional. + + 207: BAD_MESSAGE. A message is malformed and gateway parsing + failed. + + 208: UNSUPPORTED_MESSAGE: The host has transmitted an optional + message that the gateway does not support. + + 300's: Permission, resource, and policy errors. The gateway uses + these errors when a host has attempted to do something that it is + not permitted to do, or something that violated gateway policy. + + 301: REGISTER_FIRST. The RSIP host has attempted to request or + use resources without registering. + + 302: ALREADY_REGISTERED. The host has attempted to register again + without first de-registering. + + 303: ALREADY_UNREGISTERED. The host has attempted to de-register + but it is already in the unregistered state. + + 304: REGISTRATION_DENIED. The gateway will not allow the host to + register. + + 305: BAD_CLIENT_ID. The host 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 host. + + 307: BAD_TUNNEL_TYPE. The request refers to a tunnel type that is + not valid for the host. + + 308: LOCAL_ADDR_UNAVAILABLE. The gateway is currently not able to + allocate ANY local address, but the host may try again later. + + 309: LOCAL_ADDRPORT_UNAVAILABLE. The gateway is currently not + able to allocate ANY local IP address / port tuple of the + requested magnitude (i.e., number of ports), but the host may + try again later. + + 310: LOCAL_ADDR_INUSE. The gateway was not able to allocate the + requested local address because it is currently used by another + entity. + + + + + + +Borella, et al. Experimental [Page 43] + +RFC 3103 RSIP Protocol Specification October 2001 + + + 311: LOCAL_ADDRPORT_INUSE. The gateway was not able to allocate + the requested local address / port tuple because it is + currently used by another entity. + + 312: LOCAL_ADDR_UNALLOWED. The gateway will not let the host use + the specified local IP address due to policy. + + 313: LOCAL_ADDRPORT_UNALLOWED. The gateway will not let the host + use the specified local address / port pair due to policy. + + 314: REMOTE_ADDR_UNALLOWED. The gateway will not allow the host + to establish a session to the specified remote address. + + 315: REMOTE_ADDRPORT_UNALLOWED. The gateway will not allow the + host to establish a session to the specified remote address / + port tuple. + + 400's: IPsec errors. All errors specific to RSIP / IPsec operation. + See [RSIP-IPSEC]. + +15. Appendix B: Message Types + + This section defines the values assigned to RSIP message types. We + also indicate which RSIP entity, host or gateway, produces each + messages, and whether it is mandatory or optional. All *_REQUEST + messages are only to be implemented on hosts, while all *_RESPONSE + messages are only to be implemented on gateways. RSIP + implementations (both host and gateway) MUST support all mandatory + messages in order to be considered "RSIP compliant". + + + + + + + + + + + + + + + + + + + + + + +Borella, et al. Experimental [Page 44] + +RFC 3103 RSIP Protocol Specification October 2001 + + + Value Message Implementation Status + ------------------------------------------------------------ + 1 ERROR_RESPONSE gateway mandatory + 2 REGISTER_REQUEST host mandatory + 3 REGISTER_RESPONSE gateway mandatory + 4 DE-REGISTER_REQUEST host mandatory + 5 DE-REGISTER_RESPONSE gateway mandatory + 6 ASSIGN_REQUEST_RSA-IP host optional + 7 ASSIGN_RESPONSE_RSA-IP gateway optional + 8 ASSIGN_REQUEST_RSAP-IP host mandatory + 9 ASSIGN_RESPONSE_RSAP-IP gateway mandatory + 10 EXTEND_REQUEST host mandatory + 11 EXTEND_RESPONSE gateway mandatory + 12 FREE_REQUEST host mandatory + 13 FREE_RESPONSE gateway mandatory + 14 QUERY_REQUEST host optional + 15 QUERY_RESPONSE gateway mandatory + 16 LISTEN_REQUEST host optional + 17 LISTEN_RESPONSE gateway optional + +16. Appendix C: Example RSIP host/gateway transactions + + In this appendix, we present an exemplary series of annotated + transactions between an RSIP host and an RSIP gateway. All host to + gateway traffic is denote by `C --> S' and all gateway to host + 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 + sender doesn't care where they are. + + IPv4 addresses are assumed. + +16.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 host attempts to register with the gateway. + + + + + +Borella, et al. Experimental [Page 45] + +RFC 3103 RSIP Protocol Specification October 2001 + + + S --> C: REGISTER_RESPONSE (Client ID = 1, Local Flow Policy = + Macro, Remote Flow policy = None, Lease Time = 600) + + The gateway 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. A lease time of 600 seconds is assigned. + + 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 host requests an address and four ports to use with it, but + doesn't care which address or ports are assigned. The host + does not specify the remote address or ports either. The host + 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 gateway 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 host 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) + + The host asks the gateway 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 gateway 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) + + + +Borella, et al. Experimental [Page 46] + +RFC 3103 RSIP Protocol Specification October 2001 + + + The host 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 gateway 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 host 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 host because the host is still assigned ports + 1305-1314. + + S --> C: FREE_RESPONSE (Client ID = 1, Bind ID = 1) + + The gateway acknowledges that Bind ID 1 has been freed. + + C --> S: EXTEND_REQUEST (Client ID = 1, Bind ID = 2, Lease Time = + 1800) + + The host 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 gateway confirms the request. + + S --> C: FREE_RESPONSE (Client ID = 1, Bind ID = 2) + + The gateway forces the host to free the resources of bind ID 2. + + C --> S: DE-REGISTER_REQUEST (Client ID = 1) + + The host de-registers with the sever. + + S --> C: DE-REGISTER_RESPONSE (Client ID = 1) + + The gateway acknowledges that the host has de-registered. + + + + + + +Borella, et al. Experimental [Page 47] + +RFC 3103 RSIP Protocol Specification October 2001 + + +16.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 host attempts to register with the gateway. + + 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, Lease + Time = 600) + + The gateway 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. A lease time of 600 seconds is assigned. + + 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 host requests a local address and a port assignment to use + with it. The host indicates that it wants to contact host + 38.196.73.6 at port 21 (FTP control). The host 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 gateway 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. + + 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 host 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. + + + + + +Borella, et al. Experimental [Page 48] + +RFC 3103 RSIP Protocol Specification October 2001 + + + 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 gateway 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 host de-registers with the sever. + + S --> C: DE-REGISTER_RESPONSE (Client ID = 5) + + The gateway acknowledges that the host has de-registered. All + of the host's bindings have been implicitly revoked. + +16.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 host attempts to register with the gateway. + + 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, Lease + Time = 600) + + The gateway 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. A lease time of 600 seconds is assigned. + + 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 host requests a local address and indicates that it wants + to contact host www.foo.com. + + S --> C: ERROR_RESPONSE: (Error = REMOTE_ADDR_UNALLOWED, Client ID + = 3) + + The gateway indicates that the host is not permitted to + establish communication with www.foo.com. + + + +Borella, et al. Experimental [Page 49] + +RFC 3103 RSIP Protocol Specification October 2001 + + + 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 host 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 gateway responds by granting local IP address + 149.112.240.17 to the host, 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 host de-registers with the sever. + + S --> C: DE-REGISTER_RESPONSE (Client ID = 3) + + The gateway acknowledges that the host has de-registered. All + of the host's bindings have been implicitly revoked. + +17. Appendix D: Example RSIP host state diagram + + This appendix provides an exemplary diagram of RSIP host state. The + host begins in the unregistered state. We assume that for UDP, if a + message is lost, the host 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. + + + + + + + + + + + + + + + + +Borella, et al. Experimental [Page 50] + +RFC 3103 RSIP Protocol Specification October 2001 + + + send + REGISTER_REQUEST + +------------+ +------------+ + | |------------->|Registration|<-- timeout/send ++--->|Unregistered|<-------------| Pending |--- REGISTER_REQUEST +| | | +------------+ +| +------------+ 7th timeout/recv | +| ^ ERROR_RESPONSE | +| | | +| | | +| |7th timeout/recv |recv timeout/send +| |DE-REGISTER_RESPONSE |REGISTER_RESPONSE QUERY_REQUEST +| | | ^ | +| | | | | +| | | send | | +| | send DE- v QUERY_REQUEST | | +| +----------------+ REGISTER_REQUEST+----------+ +----------+ +| | Registered |<----------------| |--------->|Registered| +| | De-registration| |Registered| | Query | +| | Pending |---------------->| |<---------| Pending | +| +----------------+ recv +----------+ +----------+ +| | ^ ERROR_RESPONSE ^ | 7th timeout/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 +| +---------------+ | | | QUERY_RESPONSE or +| recv | | | ERROR_RESPONSE +| +---------------+ERROR_RESPONSE | v v +-----------+ + + + +Borella, et al. Experimental [Page 51] + +RFC 3103 RSIP Protocol Specification October 2001 + + +| | Assigned |-------------->+-------------+-------->| Assigned | ++>|De-registration| | Assigned | | Query | + | Pending |<--------------+-------------+<--------| Pending | + +---------------+ send ^ | +-----------+ + ^ | DE-REGISTER_REQUEST | | send ^ | + | | | | QUERY_REQUEST | | + | | | | | | + timeout/send 7th/timeout/recv | |send | | + DE-REGISTER_ ASSIGN_RESPONSE | |ASSIGN_REQUEST timeout/send + REQUEST or ERROR_RESPONSE| | QUERY_REQUEST + | | + | v + +----------+ + | Assigned | + |Assignment| + | Pending | + +----------+ + ^ | + | | + timeout/send + ASSIGN_REQUEST + +18. References + + [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, + G.J. and E. Lear, "Address Allocation for Private + Internets", BCP 5, RFC 1918, February 1996. + + [RFC2119] Bradner, S., "Key words for use in RFCs to indicate + requirement levels", BCP 14, RFC 2119, March 1997. + + [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an + IANA Considerations Section in RFCs", BCP 26, RFC 2434, + October 1998. + + [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address + Translator (NAT) Terminology and Considerations", RFC + 2663, August 1999. + + [RSIP-FRAME] Borella, M. Lo, J., Grabelsky, D. and G. Montenegro, + "Realm Specific IP: Framework", RFC 3102, October 2001. + + [RSIP-IPSEC] Montenegro, G. and M. Borella, "RSIP Support for End- + to-end IPSEC", RFC 3104, October 2001. + + + + + + + +Borella, et al. Experimental [Page 52] + +RFC 3103 RSIP Protocol Specification October 2001 + + +19. Authors' Addresses + + Michael Borella + CommWorks + 3800 Golf Rd. + Rolling Meadows IL 60008 + + Phone: (847) 262-3083 + EMail: mike_borella@commworks.com + + + David Grabelsky + CommWorks + 3800 Golf Rd. + Rolling Meadows IL 60008 + + Phone: (847) 222-2483 + EMail: david_grabelsky@commworks.com + + + Jeffrey Lo + Candlestick Networks, Inc + 70 Las Colinas Lane, + San Jose, CA 95119 + + Phone: (408) 284 4132 + EMail: yidarlo@yahoo.com + + + Kunihiro Taniguchi + NEC USA + C&C Research Labs. + 110 Rio Robles + San Jose, CA 95134 + + Phone: (408) 943-3031 + EMail: taniguti@ccrl.sj.nec.com + + + + + + + + + + + + + + +Borella, et al. Experimental [Page 53] + +RFC 3103 RSIP Protocol Specification October 2001 + + +20. Full Copyright Statement + + Copyright (C) The Internet Society (2001). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Borella, et al. Experimental [Page 54] + |