idnits 2.17.1 draft-ietf-nat-rsip-protocol-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 48 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 43 instances of too long lines in the document, the longest one being 10 characters in excess of 72. == There are 7 instances of lines with non-RFC2606-compliant FQDNs in the document. == There are 23 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 1 instance of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The exact meaning of the all-uppercase expression 'MAY NOT' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: 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]. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: 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 host 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. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: 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. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: 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 expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: 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 document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 2000) is 8807 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'Client ID' is mentioned on line 656, but not defined == Missing Reference: 'Bind ID' is mentioned on line 657, but not defined ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) ** Downref: Normative reference to an Informational RFC: RFC 2663 -- Possible downref: Non-RFC (?) normative reference: ref. 'RSIP-FRAME' -- Possible downref: Non-RFC (?) normative reference: ref. 'RSIP-IPSEC' Summary: 6 errors (**), 0 flaws (~~), 13 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET DRAFT M. Borella 2 Expires September 2000 D. Grabelsky 3 3Com Corp. 5 J. Lo 6 K. Tuniguchi 7 NEC USA 9 March 2000 11 Realm Specific IP: Protocol Specification 12 14 Status of this Memo 16 This document is an Internet-Draft and is in full conformance with 17 all provisions of Section 10 of RFC2026. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 Abstract 37 This document presents a protocol with which to implement Realm 38 Specific IP (RSIP). The protocol defined herein allows negotiation 39 of resources between an RSIP host and gateway, so that the host can 40 lease some of the gateway's addressing parameters in order to 41 establish a global network presence. This protocol is designed to 42 operate on the application layer and to use its own TCP or UDP port. 43 In particular, the protocol allows a gateway to allocate addressing 44 and control parameters to a host such that a flow policy can be 45 enforced at the gateway. 47 1. Introduction 48 Network Address Translation (NAT) has gained popularity as a method 49 of separating public and private address spaces, and alleviating 50 network address shortages. A NAT translates the addresses of packets 51 leaving a first routing realm to an address from a second routing 52 realm, and performs the reverse function for packets entering the 53 first routing realm from the second routing realm. This translation 54 is performed transparently to the hosts in either space, and may 55 include modification of TCP/UDP port numbers and IP addresses in 56 packets that traverse the NAT. 58 While a NAT does not require hosts to be aware of the translation, it 59 will require an application layer gateway (ALG) for any protocol that 60 transmits IP addresses or port numbers in packet payloads (such as 61 FTP). Additionally, a NAT will not work with protocols that require 62 IP addresses and ports to remain unmodified between the source and 63 destination hosts, or protocols that prevent such modifications to 64 occur (such as some IPSEC modes, or application-layer end-to-end 65 encryption). 67 An alternative to a NAT is an architecture that allows the hosts 68 within the first (e.g., private) routing realm to directly use 69 addresses and other routing parameters from the second (e.g., public) 70 routing realm. Thus, RSIP [RSIP-FRAME] has been defined a method for 71 address sharing that exhibits more transparency than NAT. In 72 particular, RSIP requires that an RSIP gateway (a router or gateway 73 between the two realms) assign at least one address from the second 74 routing realm, and perhaps some other resources, to each RSIP host. 75 An RSIP host is a host in the first routing realm that needs to 76 establish end-to-end connectivity to a host, entity or device in the 77 second routing realm. Thus, the second routing realm is not directly 78 accessible from RSIP host, but this system allows packets to maintain 79 their integrity from RSIP host to their destination. ALGs are not 80 required in the RSIP gateway. 82 RSIP requires that hosts be modified so that they place some number 83 of layer three, layer four or other values from those assigned by the 84 RSIP gateway in each packet bound for the second routing realm. 86 This draft discusses a method for assigning parameters to an RSIP 87 host from an RSIP gateway. The requirements, scope, and 88 applicability of RSIP, as well as its interaction with other layer 3 89 protocols, are discussed in a companion framework draft [RSIP-FRAME]. 90 Extensions to this protocol that enable end-to-end IPSEC are 91 discussed in [RSIP-IPSEC]. 93 2. Specification of Requirements 95 The keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", 96 "SHALL", "SHALL NOT", "MAY" and "MAY NOT" that appear in this 97 document are to be interpreted as described in [RFC2119]. 99 3. Terminology 101 Private Realm 103 A routing realm that uses private IP addresses from the ranges 104 (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) specified in 105 [RFC1918], or addresses that are non-routable from the Internet. 107 Public Realm 109 A routing realm with unique network addresses assigned by the 110 Internet Assigned Number Authority (IANA) or an equivalent address 111 registry. 113 RSIP Host 115 A host within the private realm that acquires publicly unique 116 parameters from an RSIP gateway through the use of the RSIP 117 client/server protocol. 119 RSIP Gateway 121 A router situated on the boundary between a private realm and a 122 public realm and owns one or more public IP addresses. An RSIP 123 gateway is responsible for public parameter management and 124 assignment to RSIP hosts. An RSIP gateway may act as a normal NAT 125 router for hosts within the private realm that are not RSIP 126 enabled. 128 RSIP Client 130 An application program that performs the client portion of the 131 RSIP client/server protocol. An RSIP client application MUST 132 exist on all RSIP hosts, and MAY exist on RSIP gateways. 134 RSIP Server 136 An application program that performs the server portion of the 137 RSIP client/server protocol. An RSIP server application MUST 138 exist on all RSIP gateways. 140 RSA-IP: Realm Specific Address IP 142 An RSIP method in which each RSIP host is allocated a unique IP 143 address from the public realm. Discussed in detail in [RFC2663] 145 RSAP-IP: Realm Specific Address and Port IP 147 An RSIP method in which each RSIP host is allocated an IP address 148 (possibly shared with other RSIP hosts) and some number of per- 149 address unique ports from the public realm. Discussed in detail 150 in [RFC2663] 152 Binding 154 An association of some combination of a local address, one or more 155 local ports, a remote address, and a remote port with an RSIP 156 host. 158 Resource 160 A general way to refer to an item that an RSIP host leases from an 161 RSIP gateway; e.g., an address or port. 163 All other terminology found in this document is consistent with that 164 of [RFC2663] and [RSIP-FRAME]. 166 4. Architecture 168 For simplicity, in the remainder of this document we will assume that 169 the RSIP hosts in the first routing realm (network) use private (e.g. 170 see [RFC1918]) IP addresses, and that the second routing realm 171 (network) uses public IP addresses. (This assumption is made without 172 loss of generality and the ensuing discussion applies to more general 173 cases.) The RSIP gateway connects the public and private realms and 174 contains interfaces to both. Other NAT terminology found in this 175 document is defined in [RFC2663]. 177 The diagram below describes an exemplary reference architecture for 178 RSIP. 180 RSIP Host RSIP Gateway Host 182 Xa Na Nb Yb 183 [X]------( Addr sp. A )----[N]-----( Addr sp. B )-------[Y] 184 ( Network ) ( Network ) 186 Hosts X and Y belong to different addressing realms A and B, 187 respectively, and N is an RSIP gateway (which may also perform NAT 188 functions). N has two interfaces: Na on address space A, and Nb on 189 address space B. N may have a pool of addresses in address space B 190 which it can assign to or lend to X and other hosts in address space 191 A. These addresses are not shown above, but they can be denoted as 192 Nb1, Nb2, Nb3 and so on. 194 Host X, needing to establish an end-to-end connection to a network 195 entity Y situated within address space B, first negotiates and 196 obtains assignment of the resources from the RSIP gateway. Upon 197 assignment of these parameters, the RSIP gateway creates a mapping, 198 of X's addressing information and the assigned resources. This 199 binding enables the RSIP gateway to correctly de-multiplex and 200 forward inbound traffic generated by Y for X. A lease time is 201 associated with each bind. 203 Using the public parameters assigned by the RSIP gateway, RSIP hosts 204 tunnel data packets across address space A to the RSIP gateway. The 205 RSIP gateway acts as the end point of such tunnels, stripping off the 206 outer headers and routing the inner packets onto the public realm. As 207 mentioned above, an RSIP gateway maintains a mapping of the assigned 208 public parameters as demultiplexing fields for uniquely mapping them 209 to RSIP host private addresses. When a packet from the public realm 210 arrives at the RSIP gateway and it matches a given set of 211 demultiplexing fields, then the RSIP gateway will tunnel it to the 212 appropriate RSIP host. The tunnel headers of outbound packets from X 213 to Y, given that X has been assigned Nb, are as follows: 215 +---------+---------+---------+ 216 | X -> Na | Nb -> Y | payload | 217 +---------+---------+---------+ 219 There are two basic flavors of RSIP: RSA-IP and RSAP-IP. RSIP hosts 220 and gateways MUST support RSAP-IP and MAY support RSA-IP. Details of 221 RSA-IP and RSAP-IP are found in [RSIP-FRAME]. 223 5. Transport Protocol 225 RSIP is an application layer protocol that requires the use of a 226 transport layer protocol for end-to-end delivery of packets. 228 RSIP gateways MUST support TCP, and SHOULD support UDP. Due to the 229 fact that RSIP may be deployed across a wide variety of network 230 links, RSIP hosts SHOULD support TCP. However, RSIP hosts MAY 231 support UDP instead. For RSIP hosts and gateways using UDP, timeout 232 and retransmissions MUST occur. We recommend a binary exponential 233 backoff scheme with an initial duration of 12.5 ms, and a maximum of 234 six retries (seven total attempts before failure). 236 Once a host and gateway have established a registration using either 237 TCP or UDP, they may not switch between the two protocols for the 238 duration of the registration. 240 6. Host / Gateway Relationships 241 An RSIP host can be in exactly one of three fundamental relationships 242 with respect to an RSIP gateway: 244 Unregistered: The RSIP gateway does not know of the RSIP host's 245 existence, and it will not forward or deliver packets globally 246 addressed on behalf of the host. The only valid RSIP-related 247 action for a host to perform in this state is to request 248 registration with an RSIP gateway. 250 Registered: The RSIP gateway knows of the RSIP host and has 251 assigned it a host ID and has specified the flow policies that 252 it requires of the host. However, no resources, such as 253 addresses or ports, have been allocated to the host, and the 254 gateway will not forward or deliver globally addressed packets 255 on behalf of the host. 257 Assigned: The RSIP gateway has granted one or more bindings of 258 resources to the host. The gateway will forward and deliver 259 globally addressed packets on behalf of the host. 261 Architectures in which an RSIP host is simultaneously registered with 262 more than one RSIP gateway are possible. In such cases, an RSIP host 263 may be in different relationships with different RSIP gateways at the 264 same time. 266 7. Gateway Flow Policy and State 268 Since an RSIP gateway is likely to reside on the boundary between two 269 or more different administrative domains, it is desirable to enable 270 an RSIP gateway to be able to enforce flow-based policy. In other 271 words, an RSIP gateway should have the ability to explicitly control 272 which local addresses and ports are used to communicate with remote 273 addresses and ports. 275 In the following, macro-flow policy refers to controlling flow policy 276 at the granularity level of IP addresses, while micro-flow policy 277 refers to controlling flow policy at the granularity of IP address 278 and port tuples. Of course there may be no policy at all, which 279 indicates that the RSIP gateway does not care about the flow 280 parameters used by RSIP hosts. We consider two levels of local flow 281 policy and three levels of remote flow policy. 283 7.1. Local Flow Policy 285 Local flow policy determines the granularity of control that an 286 RSIP gateway has over the local addressing parameters that an RSIP 287 host uses for particular sessions. 289 Since an RSIP host must use at least an IP address allocated by 290 the gateway, the loosest level of local flow policy is macro-flow 291 based. Under local macro-flow policy, an RSIP host is allocated 292 an IP address (RSA-IP) or an IP address and one or more ports to 293 use with it (RSAP-IP). However, the host may use the ports as it 294 desires for establishing sessions with public hosts. 296 Under micro-flow policy, a host is allocated exactly one port at a 297 time. The host may request more ports, also one at a time. This 298 policy gives the gateway very tight control over local port use, 299 although it affords the host less flexibility. 301 Note that only local macro-flow policy can be used with RSA-IP, 302 while either local macro-flow or local micro-flow policy may be 303 used with RSAP-IP. 305 Examples of how RSIP flow policy operates are given in Appendix C. 307 7.2. Remote Flow Policy 309 Remote flow policy determines the granularity of control that an 310 RSIP gateway has over the remote (public) hosts with which an RSIP 311 host communicates. In particular, remote flow policy dictates 312 what level of detail that a host must specify addressing 313 parameters of a remote host or application before the RSIP gateway 314 allows the host to communicate with that host or application. 316 The simplest and loosest form of flow policy is no policy at all. 317 In other words, the RSIP gateway allocates addressing parameters 318 to the host, and the host may use these parameters to communicate 319 with any remote host, without explicitly notifying the gateway. 321 Macro-flow policy requires that the host identify the remote 322 address of the host that it wishes to communicate with as part of 323 its request for local addressing parameters. If the request is 324 granted, the host MUST use the specified local parameters only 325 with the remote address specified, and MUST NOT communicate with 326 the remote address using any local parameters but the ones 327 allocated. However, the host may contact any port number at the 328 remote host without explicitly notifying the gateway. 330 Micro-flow policy requires that the host identify the remote 331 address and port of the host that it wishes to communicate with as 332 part of its request for local addressing parameters. If the 333 request is granted, the host MUST use the specified local 334 parameters only with the remote address and port specified, and 335 MUST NOT communicate with the remote address and port using any 336 local parameters but the ones allocated. 338 Remote flow policy is implemented in both the ingress and egress 339 directions, with respect to the location of the RSIP gateway. 341 7.3. Gateway State 343 An RSIP gateway must maintain state for all RSIP hosts and their 344 assigned resources. The amount and type of state maintained 345 depends on the local and remote flow policy. The required RSIP 346 gateway state will vary based on the RSIP method, but will always 347 include the chosen method's demultiplexing parameters. 349 7.3.1. RSA-IP State 351 An RSIP gateway serving an RSIP host using the RSA-IP method 352 MUST maintain the following minimum state to ensure proper 353 mapping of incoming packets to RSIP hosts: 355 - Host's private address 356 - Host's assigned public address(es) 358 7.3.2. RSAP-IP State 360 An RSIP gateway serving an RSIP host using the RSAP-IP method 361 MUST maintain the following minimum state to ensure proper 362 mapping of incoming packets to RSIP hosts: 364 - Host's private address 365 - Host's assigned public address(es) 366 - Host's assigned port(s) per address 368 7.3.3. Flow State 370 Regardless of whether the gateway is using RSA-IP or RSAP-IP, 371 additional state is necessary if either micro-flow based or 372 macro-flow based remote policy is used. 374 If the gateway is using macro-flow based remote policy, the 375 following state must be maintained: 377 - Remote host's address 379 If the gateway is using micro-flow based remote policy, the 380 following state must be maintained: 382 - Remote host's address 383 - Remote host's port 385 More state MAY be used by an RSIP gateway if desired. For 386 example, ToS/DS bytes may be recorded in order to facilitate 387 quality of service support. 389 8. Parameter Specification and Formats 391 In this section we define the formats for RSIP parameters. Each RSIP 392 message contains one or more parameters that encode the information 393 passed between the host and gateway. The general format of all 394 parameters consists of a 1-byte code followed by a 2-byte length as 395 shown below. 397 1 byte 2 bytes 'Length' bytes 398 +------+----------+-------------- 399 | Code | Length | ... 400 +------+----------+-------------- 402 The length field determines the length, in bytes, of the rest of the 403 parameter, such that the total length of a parameter is the value of 404 the length field plus 3. 406 8.1. Address 408 Code Length Type Value 409 +-------+---------+--------+--------+ 410 | 1 | 2 bytes | 1 byte | varies | 411 +-------+---------+--------+--------+ 413 The address parameter contains addressing information, either an 414 IPv4 address or netmask, an IPv6 address or netmask, or a fully 415 qualified domain name (FQDN). The type field is 1 byte in length, 416 indicating the type of address. 418 Defined types are: 420 Type Length of value field (in bytes) 421 ---- -------------------------------- 422 0 Reserved 0 423 1 IPv4 4 424 2 IPv4 netmask 4 425 3 IPv6 16 426 4 IPv6 netmask 16 427 5 FQDN varies 429 For FQDN, the length of the value field will be one less than the 430 value of the length field. 432 In some cases, it is necessary to specify a "don't care" value for 433 an address. This is signified by a setting the length field to 1 434 and omitting the value field. 436 It is not valid for a host to request an address with an FQDN type 437 as its local address (See specification of ASSIGN_REQUEST_RSA-IP 438 and ASSIGN_REQUEST_RSAP-IP, below). 440 8.2. Ports 442 Code Length Number Port Port 443 +-------+---------+--------+---------+ +---------+ 444 | 2 | 2 bytes | 1 byte | 2 bytes | ... | 2 bytes | 445 +-------+---------+--------+---------+ +---------+ 447 The ports parameter encodes one or more TCP or UDP ports. When a 448 single port is specified, the value of the number field is 1 and 449 there is one port field following the number field. When more 450 than one port is specified, the value of the number field will 451 indicate the total number of ports contained, and the parameter 452 may take one of two forms. If there is one port field, the ports 453 specified are considered to be contiguous starting at the port 454 number specified in the port field. Alternatively, there may be a 455 number of port fields equal to the value of the number field. The 456 number of port fields can be extrapolated from the length field. 458 In some cases, it is necessary to specify a don't care value for 459 one or more ports (e.g., when a client application is using 460 ephemeral source ports). This is accomplished by setting the 461 length field to 1, setting the number field to the number of ports 462 necessary, and omitting all port fields. The value of the number 463 field MUST be greater than or equal to one. 465 If micro-flow based policy applies to a given ports parameter, it 466 MUST contain exactly one port field. 468 This parameter is not used with RSA-IP. 470 8.3. Lease Time 472 Code Length Value 473 +-------+--------+---------+ 474 | 3 | 4 | 4 bytes | 475 +-------+--------+---------+ 477 The lease time parameter specifies the length, in seconds, of an 478 RSIP host parameter binding. 480 8.4. Client ID 481 Code Length Value 482 +-------+--------+---------+ 483 | 4 | 4 | 4 bytes | 484 +-------+--------+---------+ 486 The client ID parameter specifies an RSIP client ID. 488 8.5. Bind ID 490 Code Length Value 491 +-------+--------+---------+ 492 | 5 | 4 | 4 bytes | 493 +-------+--------+---------+ 495 The bind ID parameter specifies an RSIP bind ID. 497 8.6. Tunnel Type 499 Code Length Value 500 +-------+--------+--------+ 501 | 6 | 1 | 1 byte | 502 +-------+--------+--------+ 504 The tunnel type parameter specifies the type of tunnel used 505 between an RSIP host and an RSIP gateway. Defined tunnel types 506 are: 508 Tunnel Type 509 ----------- 510 0 Reserved 511 1 IP-IP 512 2 GRE 513 3 L2TP 515 8.7. RSIP Method 517 Code Length Value 518 +-------+--------+--------+ 519 | 7 | 1 | 1 byte | 520 +-------+--------+--------+ 522 The RSIP method parameter specifies an RSIP method. Defined RSIP 523 methods are: 525 RSIP method 526 ----------- 527 0 Reserved 528 1 RSA-IP 529 2 RSAP-IP 531 8.8. Error 533 Code Length Value 534 +-------+--------+---------+ 535 | 8 | 2 | 2 bytes | 536 +-------+--------+---------+ 538 The error parameter specifies an error. The currently defined 539 error values are presented in Appendix A. 541 8.9. Flow Policy 543 Code Length Local Remote 544 +-------+--------+--------+--------+ 545 | 9 | 2 | 1 byte | 1 byte | 546 +-------+--------+--------+--------+ 548 The flow policy parameter specifies both the local and remote flow 549 policy. 551 Defined local flow policies are: 553 Local Flow Policy 554 ----------------- 555 0 Reserved 556 1 Macro flows 557 2 Micro flows 559 Defined remote flow policies are: 561 Remote Flow Policy 562 ------------------ 563 0 Reserved 564 1 Macro flows 565 2 Micro flows 566 3 No policy 568 8.10. Indicator 570 Code Length Value 571 +-------+---------+--------+ 572 | 10 | 2 bytes | varies | 573 +-------+---------+--------+ 575 An indicator parameter is a general-purpose parameter, the use of 576 which is defined by the message that it appears in. An RSIP 577 message that uses an indicator parameter MUST define the meaning 578 and interpretation of all of the indicator's possible values. 580 8.11. Vendor Specific Parameter 582 Code Length Vendor ID Subcode Value 583 +-------+---------+-----------+---------+--------+ 584 | 240 | 2 bytes | 2 bytes | 2 bytes | varies | 585 +-------+---------+-----------+---------+--------+ 587 The vendor specific parameter is used to encode parameters that 588 are defined by a particular vendor. The vendor ID field is the 589 vendor-specific ID assigned by IANA. Subcodes are defined and 590 used by each vendor as necessary. An RSIP host or gateway SHOULD 591 silently ignore vendor-specific messages that it does not 592 understand. 594 9. Message Types 596 RSIP messages consist of three mandatory fields, version, message 597 type, and overall length, followed by one or more required 598 parameters, followed in turn by zero or more optional parameters. In 599 an RSIP message, all required parameters MUST appear in the exact 600 order specified below. Optional parameters MAY appear in any order. 602 The version number field is a single byte and specifies the RSIP 603 version number that is being used. The current RSIP version number 604 is 1. 606 The message type field is a single byte and specifies the message 607 contained in the current packet. There may be only one message per 608 packet. Message types are given numerical assignments in Appendix B. 610 The overall length field is two bytes and contains the number of 611 bytes in the RSIP message, including the three mandatory fields. 613 Most parameters are only allowed to appear once in each message. The 614 exceptions are as follows: 616 - Multiple address parameters MUST appear in ASSIGN_REQUEST_RSA-IP, 617 ASSIGN_RESPONSE_RSA-IP, ASSIGN_REQUEST_RSAP-IP, 618 ASSIGN_RESPONSE_RSAP-IP, LISTEN_REQUEST and LISTEN_RESPONSE. 620 - Multiple ports parameters MUST appear in ASSIGN_REQUEST_RSAP-IP, 621 ASSIGN_RESPONSE_RSAP-IP, LISTEN_REQUEST and LISTEN_RESPONSE. 623 - Multiple RSIP method and tunnel type parameters MAY appear in 624 RESISTER_RESPONSE. 626 - Multiple address parameters and multiple indicator parameters MAY 627 appear in QUERY_REQUEST and QUERY_RESPONSE. 629 The following message types are defined in simple BNF. Required 630 parameters are enclosed in <> and MUST appear. Optional parameters 631 are enclosed in [] and MAY appear. Not all message types need to be 632 implemented in order to be RSIP compliant. For example, an RSIP host 633 and/or gateway may not support LISTEN_REQUEST and LISTEN_RESPONSE, or 634 may only support RSAP-IP and not RSA-IP. 636 9.1. ERROR_RESPONSE 638 9.1.1. Description 640 An ERROR_RESPONSE is used to provide error messages from an 641 RSIP gateway to an RSIP host. Usually, errors indicate that 642 the RSIP gateway cannot or will not perform an action or 643 allocate resources on behalf of the host. If the error is 644 related to a particular host ID or bind ID, these associated 645 parameters MUST be included. Multiple errors MAY NOT be 646 reported in the same ERROR_RESPONSE. In situations where more 647 than one error has occurred, the RSIP gateway MUST choose only 648 one error to report. 650 9.1.2. Format 652 ::= 653 654 655 656 [Client ID] 657 [Bind ID] 659 9.1.3. Behavior 661 An ERROR_RESPONSE message MUST only be transmitted by an RSIP 662 gateway. An RSIP host that detects an error in a message 663 received from an RSIP gateway MUST silently discard the 664 message. There are no error conditions that can be caused by 665 an ERROR_RESPONSE. An ERROR_RESPONSE is typically transmitted 666 in response to a request from an RSIP host. 668 9.2. REGISTER_REQUEST 670 9.2.1. Description 671 The REGISTER_REQUEST message is used by an RSIP host to 672 establish registration with an RSIP gateway. An RSIP host MUST 673 register before it requests resources or services from an RSIP 674 gateway. Once an RSIP host has registered with an RSIP 675 gateway, it may not register again until it has de-registered 676 from that gateway. 678 9.2.2. Format 680 ::= 681 682 684 9.2.3. Behavior 686 The following message-specific error conditions exist: 688 - If the host is already registered with the gateway, the 689 gateway MUST respond with an ERROR_RESPONSE containing the 690 ALREADY_REGISTERED error. 692 - If the gateway's policy will not allow the host to register, 693 the gateway MUST respond with an ERROR_RESPONSE containing 694 the REGISTRATION_DENIED error. 696 9.3. REGISTER_RESPONSE 698 9.3.1. Description 700 The REGISTER_RESPONSE message is used by an RSIP gateway to 701 confirm the registration of an RSIP host, and to provide a 702 client ID, flow policy, and possibly an RSIP method and tunnel 703 type. 705 9.3.2. Format 707 ::= 708 709 710 711 712 [RSIP Method]... 713 [Tunnel Type]... 715 9.3.3. Behavior 717 An RSIP gateway MUST assign a different client ID to each host 718 that is simultaneously registered with it. The RSIP gateway 719 MAY respond with one or more RSIP methods and tunnel types that 720 it supports. If an RSIP method is not specified, RSAP-IP MUST 721 be assumed. If a tunnel type is not specified, IP-IP MUST be 722 assumed. 724 9.4. DE-REGISTER_REQUEST 726 9.4.1. Description 728 The DE-REGISTER_REQUEST message is used by an RSIP host to de- 729 register with an RSIP gateway. If a host de-registers from the 730 assigned state, all of the host's bindings are revoked. The 731 host SHOULD NOT de-register from the unregistered state. 733 9.4.2. Format 735 ::= 736 737 738 740 9.4.3. Behavior 742 The following message-specific error conditions exist: 744 - If the host is not registered with the gateway, the gateway 745 MUST respond with an ERROR_RESPONSE containing the 746 REGISTER_FIRST error. 748 - If the message contains an incorrect client ID, the gateway 749 MUST respond with an ERROR_RESPONSE containing the 750 BAD_CLIENT_ID error. 752 If there are no errors that result from this message, the 753 gateway MUST respond with an appropriate DE-REGISTER_RESPONSE. 754 Upon de-registering a host, an RSIP gateway must delete all 755 binds associated with that host and return their resources to 756 the pool of free resources. Once a host has de-registered, it 757 may not use any of the RSIP gateway's resources without 758 registering again. 760 9.5. DE-REGISTER_RESPONSE 762 9.5.1. Description 764 The DE-REGISTER_RESPONSE message is used by an RSIP gateway to 765 confirm the de-registration of an RSIP host or to force an RSIP 766 host to relinquish all of its bindings and terminate its 767 relationship with the RSIP gateway. Upon receiving a DE- 768 REGISTER_RESPONSE message, an RSIP host MUST stop all use of 769 the resources that have been allocated to it by the gateway. 771 9.5.2. Format 773 ::= 774 775 776 778 9.5.3. Behavior 780 An RSIP gateway MUST send a DE-REGISTER_RESPONSE in response to 781 a valid DE-REGISTER_REQUEST. An RSIP gateway SHOULD send a DE- 782 REGISTER_RESPONSE if it detects that it will no longer be able 783 to perform RSIP functionality for a given host. An RSIP host 784 MUST be ready to accept a DE-REGISTER_RESPONSE at any moment. 786 9.6. ASSIGN_REQUEST_RSA-IP 788 9.6.1. Description 790 The ASSIGN_REQUEST_RSA-IP message is used by an RSIP host to 791 request resources to use with RSA-IP. Note that RSA-IP cannot 792 be used in combination with micro-flow based local policy. 794 9.6.2. Format 796 ::= 797 798 799 800
801
802 803 [Lease Time] 804 [Tunnel Type] 806 9.6.3. Behavior 808 The RSIP host specifies two address parameters. The RSIP host 809 may request a particular local address by placing that address 810 in the first address parameter. To indicate that it has no 811 preference for local address, the RSIP host may place a "don't 812 care" value in the address parameter. 814 If macro-flow based remote policy is used, the host MUST 815 specify the remote address that it will use this binding (if 816 granted) to contact; however, the remote port number MAY remain 817 unspecified. If micro-flow based remote policy is used, the 818 host MUST specify the remote address and port number that it 819 will use this binding (if granted) to contact. If no flow 820 policy is used, the RSIP host may place a "don't care" value in 821 the value fields of the respective address and ports 822 parameters. 824 The following message-specific error conditions exist: 826 - If the host is not registered with the gateway, the gateway 827 MUST respond with an ERROR_RESPONSE containing the 828 REGISTER_FIRST error. 830 - If the message contains an incorrect client ID, the gateway 831 MUST respond with an ERROR_RESPONSE containing the 832 BAD_CLIENT_ID error. 834 - If the local address parameter is a don't care value and the 835 RSIP gateway cannot allocate ANY addresses, the RSIP gateway 836 MUST respond with an ERROR_RESPONSE containing the 837 LOCAL_ADDR_UNAVAILABLE error. 839 - If the local address parameter is not a don't care value 840 there are three possible error conditions: 842 o If the RSIP gateway cannot allocate ANY addresses, it MUST 843 respond with an ERROR_RESPONSE containing the 844 LOCAL_ADDR_UNAVAILABLE error. 846 o If the RSIP gateway cannot allocate the requested address 847 because it is in use, the RSIP gateway MUST respond with an 848 ERROR_RESPONSE containing the LOCAL_ADDR_INUSE error. 850 o If the RSIP gateway cannot allocate the requested address 851 because it is not allowed by policy, the RSIP gateway MUST 852 respond with an ERROR_RESPONSE containing the 853 LOCAL_ADDR_UNALLOWED error. 855 - If macro-flow based remote policy is used and the requested 856 remote address is not allowed by the RSIP gateway's policy, 857 the RSIP gateway MUST respond with an ERROR_RESPONSE 858 containing the REMOTE_ADDR_UNALLOWED error. 860 - If micro-flow based remote policy is used and the requested 861 remote address / port pair is not allowed by the RSIP 862 gateway's policy, the RSIP gateway MUST respond with an 863 ERROR_RESPONSE containing the REMOTE_ADDRPORT_UNALLOWED 864 error. 866 - If an unsupported or unallowed tunnel type is specified, the 867 RSIP gateway MUST respond with an ERROR_RESPONSE containing 868 the BAD_TUNNEL_TYPE error. 870 - If the host has not specified local or remote address or port 871 information in enough detail, the RSIP gateway MUST respond 872 with an ERROR_RESPONSE containing the FLOW_POLICY_VIOLATION 873 error. 875 9.7. ASSIGN_RESPONSE_RSA-IP 877 9.7.1. Description 879 The ASSIGN_RESPONSE_RSA-IP message is used by an RSIP gateway 880 to deliver parameter assignments to an RSIP host using RSA-IP. 881 A host-wise unique bind ID, lease time, and tunnel type must be 882 provided for every assignment. 884 9.7.2. Format 886 ::= 887 888 889 890 891
892
893 894 895 897 9.7.3. Behavior 899 If no remote flow policy is used, the RSIP gateway MUST use 900 "don't care" values for the remote address and ports 901 parameters. If macro-flow based remote policy is used, the 902 remote address parameter MUST contain the address specified in 903 the associated request, and the remote ports parameter MUST 904 contain a "don't care" value. If micro-flow based remote 905 policy is used, the remote address and remote ports parameters 906 MUST contain the address and port information specified in the 907 associated request. 909 If the host detects an error or otherwise does not "understand" 910 the gateway's response, it SHOULD send a FREE_REQUEST with the 911 bind ID from the said ASSIGN_RESPONSE_RSA-IP. This will serve 912 to help synchronize the states of the host and gateway. 914 9.8. ASSIGN_REQUEST_RSAP-IP 916 9.8.1. Description 918 The ASSIGN_REQUEST_RSAP-IP message is used by an RSIP host to 919 request resources to use with RSAP-IP. The RSIP host specifies 920 two address and two port parameters, the first of each, 921 respectively, refer to the local address and port(s) that will 922 be used, and the second of each, respectively, refer to the 923 remote address and port(s) that will be contacted. 925 9.8.2. Format 927 ::= 928 929 930 931
932 933
934 935 [Lease Time] 936 [Tunnel Type] 938 9.8.3. Behavior 940 An RSIP host may request a particular local address by placing 941 that address in the value field of the first address parameter. 942 The RSIP host may request particular local ports by placing 943 them in the first port parameter. To indicate that it has no 944 preference for local address or ports, the RSIP host may place 945 a "don't care" value in the respective address or ports 946 parameters. 948 If macro-flow based remote policy is used, the host MUST 949 specify the remote address that it will use this binding (if 950 granted) to contact; however, the remote port number(s) MAY 951 remain unspecified. If micro-flow based remote policy is used, 952 the host MUST specify the remote address and port number(s) 953 that it will use this binding (if granted) to contact. If no 954 flow policy is used, the RSIP host may place a value of all 0's 955 in the value fields of the respective address or port 956 parameters. 958 The following message-specific error conditions exist: 960 - If the host is not registered with the gateway, the gateway 961 MUST respond with an ERROR_RESPONSE containing the 962 REGISTER_FIRST error. 964 - If the message contains an incorrect client ID, the gateway 965 MUST respond with an ERROR_RESPONSE containing the 966 BAD_CLIENT_ID error. 968 - If the local address parameter is a don't care value and the 969 RSIP gateway cannot allocate ANY addresses, the RSIP gateway 970 MUST respond with an ERROR_RESPONSE containing the 971 LOCAL_ADDR_UNAVAILABLE error. 973 - If the local address parameter is not a don't care value 974 there are five possible error conditions: 976 o If the RSIP gateway cannot allocate ANY addresses, it MUST 977 respond with an ERROR_RESPONSE containing the 978 LOCAL_ADDR_UNAVAILABLE error. 980 o If the RSIP gateway cannot allocate the requested address 981 because it is in use, the RSIP gateway MUST respond with an 982 ERROR_RESPONSE containing the LOCAL_ADDR_INUSE error. 984 o If the RSIP gateway cannot allocate the requested address 985 because it is not allowed by policy, the RSIP gateway MUST 986 respond with an ERROR_RESPONSE containing the 987 LOCAL_ADDR_UNALLOWED error. 989 o If the RSIP gateway cannot allocate a requested address / 990 port tuple because it is in use, the RSIP gateway MUST 991 respond with an ERROR_RESPONSE containing the 992 LOCAL_ADDRPORT_INUSE error. 994 o If the RSIP gateway cannot allocate a requested address / 995 port tuple because it is not allowed by policy, the RSIP 996 gateway MUST respond with an ERROR_RESPONSE containing the 997 LOCAL_ADDRPORT_UNALLOWED error. 999 - If the RSIP host requests a number of ports (greater that 1000 one), but does not specify particular port numbers (i.e., 1001 uses "don't care" values) the RSIP gateway cannot grant the 1002 entire request, the RSIP gateway MUST return an 1003 ERROR_RESPONSE containing the LOCAL_ADDRPORT_UNAVAILABLE 1004 error. 1006 - If macro-flow based remote policy is used and the requested 1007 remote address is not allowed by the RSIP gateway's policy, 1008 the RSIP gateway MUST respond with an ERROR_RESPONSE 1009 containing the REMOTE_ADDR_UNALLOWED error. 1011 - If micro-flow based remote policy is used and the requested 1012 remote address / port pair is not allowed by the RSIP 1013 gateway's policy, the RSIP gateway MUST respond with an 1014 ERROR_RESPONSE containing the REMOTE_ADDRPORT_UNALLOWED 1015 error. 1017 - If an unsupported or unallowed tunnel type is specified, the 1018 RSIP gateway MUST respond with an ERROR_RESPONSE containing 1019 the BAD_TUNNEL_TYPE error. 1021 - If the host has not specified local or remote address or port 1022 information in enough detail, the RSIP gateway MUST respond 1023 with an ERROR_RESPONSE containing the FLOW_POLICY_VIOLATION 1024 error. 1026 9.9. ASSIGN_RESPONSE_RSAP-IP 1028 9.9.1. Description 1030 The ASSIGN_RESPONSE_RSAP-IP message is used by an RSIP gateway 1031 to deliver parameter assignments to an RSIP host. A host-wise 1032 unique bind ID, lease time, and tunnel type must be provided 1033 for every assignment. 1035 9.9.2. Format 1037 ::= 1038 1039 1040 1041 1042
1043 1044
1045 1046 1047 1049 9.9.3. Behavior 1050 Regardless of local flow policy, a local address and port(s) 1051 MUST be assigned to the host. If macro-flow based local policy 1052 is used, the host is assigned an address and one or more ports. 1053 If micro-flow based local policy is used, the host is assigned 1054 an address and exactly one port. 1056 If no remote flow policy is used, the RSIP gateway MUST use 1057 "don't care" values for the remote address and ports 1058 parameters. If macro-flow based remote policy is used, the 1059 remote address parameter MUST contain the address specified in 1060 the associated request, and the remote ports parameter must 1061 contain a "don't care" value. If micro-flow based remote 1062 policy is used, the remote address and remote ports parameters 1063 MUST contain the address and port information specified in the 1064 associated request. 1066 If the host detects an error or otherwise does not "understand" 1067 the gateway's response, it SHOULD send a FREE_REQUEST with the 1068 bind ID from the said ASSIGN_RESPONSE_RSAP-IP. This will serve 1069 to help synchronize the states of the host and gateway. 1071 9.10. EXTEND_REQUEST 1073 9.10.1. Description 1075 The EXTEND_REQUEST message is used to request a lease extension 1076 to a current bind. It may be used with both RSA-IP and RSAP- 1077 IP. The host MUST specify its client ID and the bind ID in 1078 question, and it MAY suggest a lease time to the gateway. 1080 9.10.2. Format 1082 ::= 1083 1084 1085 1086 1087 [Lease Time] 1089 9.10.3. Behavior 1091 The following message-specific error conditions exist: 1093 - If the host is not registered with the gateway, the gateway 1094 MUST respond with an ERROR_RESPONSE containing the 1095 REGISTER_FIRST error. 1097 - If the message contains an incorrect client ID, the gateway 1098 MUST respond with an ERROR_RESPONSE containing the 1099 BAD_CLIENT_ID error. 1101 - If the message contains an incorrect bind ID, the gateway 1102 MUST respond with an ERROR_RESPONSE containing the 1103 BAD_BIND_ID error. 1105 If the RSIP gateway grants an extension to the host's lease, it 1106 MUST RESPOND with an appropriate EXTEND_RESPONSE message. If 1107 the lease is not renewed, the RSIP gateway MAY let it 1108 implicitly expire by doing nothing or make it explicitly expire 1109 by sending an appropriate FREE_RESPONSE message. 1111 9.11. EXTEND_RESPONSE 1113 9.11.1. Description 1115 The EXTEND_RESPONSE message is used by an RSIP gateway to grant 1116 a requested lease extension. The gateway MUST specify the 1117 client ID of the host, the bind ID in question, and the new 1118 assigned lease time. 1120 9.11.2. Format 1122 ::= 1123 1124 1125 1126 1127 1129 9.11.3. Behavior 1131 The RSIP gateway will determine lease time as per its local 1132 policy. The returned time is to be interpreted as the number 1133 of seconds before the lease expires, counting from the time at 1134 which the message is sent/received. 1136 9.12. FREE_REQUEST 1138 9.12.1. Description 1140 The FREE_REQUEST message is used by an RSIP host to free a 1141 binding. The given bind ID identifies the bind to be freed. 1142 Resources may only be freed using the granularity of a bind ID. 1144 9.12.2. Format 1146 ::= 1147 1148 1149 1150 1152 9.12.3. Behavior 1154 The following message-specific error conditions exist: 1156 - If the host is not registered with the gateway, the gateway 1157 MUST respond with an ERROR_RESPONSE containing the 1158 REGISTER_FIRST error. 1160 - If the message contains an incorrect client ID, the gateway 1161 MUST respond with an ERROR_RESPONSE containing the 1162 BAD_CLIENT_ID error. 1164 - If the message contains an incorrect bind ID, the gateway 1165 MUST respond with an ERROR_RESPONSE containing the 1166 BAD_BIND_ID error. 1168 If a host receives an error in response to a FREE_REQUEST, this 1169 may indicate that the host and gateway's states have become 1170 unsynchronized. Therefore, the host SHOULD make an effort to 1171 resynchronize, such as freeing resources then re-requesting 1172 them, or de-registering then re-registering. 1174 9.13. FREE_RESPONSE 1176 9.13.1. Description 1178 The FREE_RESPONSE message is used by an RSIP gateway to 1179 acknowledge a FREE_REQUEST sent by an RSIP host, and to 1180 asynchronously deallocate resources granted to an RSIP host.. 1182 9.13.2. Format 1184 ::= 1185 1186 1187 1188 1190 9.13.3. Behavior 1191 An RSIP host must always be ready to accept a FREE_RESPONSE, 1192 even if its lease on the specified bind ID is not yet expired. 1194 9.14. QUERY_REQUEST 1196 9.14.1. Description 1198 A QUERY_REQUEST message is used by an RSIP host to ask an RSIP 1199 gateway whether or not a particular address or network is local 1200 or remote. The host uses this information to determine whether 1201 to contact the host(s) directly (in the local case), or via 1202 RSIP (in the remote case). 1204 This message defines an indicator parameter with a 1-byte value 1205 field and 2 defined values: 1207 - 1 address 1208 - 2 network 1210 9.14.2. Format 1212 ::= 1213 1214 1215 1216 [Address Tuple]... 1217 [Network Tuple]... 1219 where 1221
::= 1222
1224 ::= 1225
1226
1228 9.14.3. Behavior 1230 One or more address or network tuples may be specified. Each 1231 tuple encodes a request regarding the locality (local or 1232 remote) of the encoded address or network. If no tuple is 1233 specified, the RSIP gateway should interpret the message as a 1234 request for all tuples that it is willing to provide. Note 1235 that the FQDN form of the address parameter cannot be used to 1236 specify the address of a network, and only the netmask form of 1237 the address parameter can be used to specify the netmask of a 1238 network. 1240 If an RSIP gateway cannot determine whether a queried host or 1241 network is local or remote, it SHOULD transmit a QUERY_RESPONSE 1242 with no response specified for the said host or network. 1244 The following message-specific error conditions exist: 1246 - If the host is not registered with the gateway, the gateway 1247 MUST respond with an ERROR_RESPONSE containing the 1248 REGISTER_FIRST error. 1250 - If the message contains an incorrect client ID, the gateway 1251 MUST respond with an ERROR_RESPONSE containing the 1252 BAD_CLIENT_ID error. 1254 9.15. QUERY_RESPONSE 1256 9.15.1. Description 1258 A QUERY_RESPONSE message is used by an RSIP gateway to answer a 1259 QUERY_REQUEST from an RSIP host. 1261 This message defines an indicator parameter with a 1-byte value 1262 field and 4 defined values: 1264 - 1 local address 1265 - 2 local network 1266 - 3 remote address 1267 - 4 remote network 1269 9.15.2. Format 1271 ::= 1272 1273 1274 1275 [Local Address Tuple]... 1276 [Local Network Tuple]... 1277 [Remote Address Tuple]... 1278 [Remote Network Tuple]... 1280 where 1282 ::= 1283
1285 ::= 1286
1287
1289 ::= 1290
1292 ::= 1293
1294
1296 9.15.3. Behavior 1298 An RSIP gateway has some leeway in how it responds to a 1299 QUERY_REQUEST. It may just provide the information requested, 1300 if it can provide such information. It may provide its 1301 complete list of address and networks, in order to minimize the 1302 number of requests that the host needs to perform in the 1303 future. How an RSIP gateway responds may depend on network 1304 traffic considerations as well. 1306 If an RSIP gateway sends a QUERY_RESPONSE that does not contain 1307 any tuples, or a QUERY_RESPONSE that does not contain a tuple 1308 that applies to an associated tuple in the associated 1309 QUERY_REQUEST, this should be interpreted that the RSIP gateway 1310 does not know whether the queried host or network is local or 1311 remote. Appropriate host behavior upon receipt of such a 1312 message is to assume that the queried host or network is 1313 remote. 1315 Note that an RSIP gateway is not expected to maintain a 1316 complete list of all remote hosts and networks. In fact, a 1317 typical RSIP gateway will only maintain a list of the networks 1318 and hosts that it knows are local (private with respect to the 1319 RSIP host). 1321 9.16. LISTEN_REQUEST 1323 9.16.1. Description 1325 A LISTEN_REQUEST message is sent by an RSIP host that wants to 1326 register a service on a particular address and port number. The 1327 host must include its client ID, local address parameter and 1328 ports parameters, and remote address and ports parameters. The 1329 client MAY suggest a lease time and one or more tunnel types. 1331 9.16.2. Format 1333 ::= 1334 1335 1336 1337
1338 1339
1340 1341 [Lease Time] 1342 [Tunnel Type]... 1344 9.16.3. Behavior 1346 If the host wants to listen on a particular address or port, it 1347 may specify these in the address and ports parameters. 1348 Otherwise it may leave one or both of these parameters with 1349 "don't care" values. 1351 If no remote flow policy is being used, the host MUST fill both 1352 the remote address and ports parameters with "don't care" 1353 values. If macro-flow based remote policy is used, the host 1354 MUST specify the remote address, but MAY or MAY NOT specify the 1355 remote port(s). If micro-flow based remote policy is used, the 1356 host MUST specify the remote address and ports parameter. 1358 Once a LISTEN_REQUEST has been granted, the RSIP gateway MUST 1359 forward all packets destined to the address and port in 1360 question to the host, even if the remote host address and port 1361 tuple has not been previously contacted by the host. 1363 LISTEN_REQUEST is not necessary for RSA-IP. 1365 The following message-specific error conditions exist: 1367 - If the host is not registered with the gateway, the gateway 1368 MUST respond with an ERROR_RESPONSE containing the 1369 REGISTER_FIRST error. 1371 - If the message contains an incorrect client ID, the gateway 1372 MUST respond with an ERROR_RESPONSE containing the 1373 BAD_CLIENT_ID error. 1375 - If the local address parameter is a don't care value and the 1376 RSIP gateway cannot allocate ANY addresses, the RSIP gateway 1377 MUST respond with an ERROR_RESPONSE containing the 1378 LOCAL_ADDR_UNAVAILABLE error. 1380 - If the local address parameter is not a don't care value 1381 there are five possible error conditions: 1383 o If the RSIP gateway cannot allocate ANY addresses, it MUST 1384 respond with an ERROR_RESPONSE containing the 1385 LOCAL_ADDR_UNAVAILABLE error. 1387 o If the RSIP gateway cannot allocate the requested address 1388 because it is in use, the RSIP gateway MUST respond with an 1389 ERROR_RESPONSE containing the LOCAL_ADDR_INUSE error. 1391 o If the RSIP gateway cannot allocate the requested address 1392 because it is not allowed by policy, the RSIP gateway MUST 1393 respond with an ERROR_RESPONSE containing the 1394 LOCAL_ADDR_UNALLOWED error. 1396 o If the RSIP gateway cannot allocate the requested address / 1397 port tuple because it is in use, the RSIP gateway MUST 1398 respond with an ERROR_RESPONSE containing the 1399 LOCAL_ADDRPORT_INUSE error. 1401 o If the RSIP gateway cannot allocate the requested address / 1402 port tuple because it is not allowed by policy, the RSIP 1403 gateway MUST respond with an ERROR_RESPONSE containing the 1404 LOCAL_ADDRPORT_UNALLOWED error. 1406 - If macro-flow based remote policy is used and the requested 1407 remote address is not allowed by the RSIP gateway's policy, 1408 the RSIP gateway MUST respond with an ERROR_RESPONSE 1409 containing the REMOTE_ADDR_UNALLOWED error. 1411 - If micro-flow based remote policy is used and the requested 1412 remote address / port pair is not allowed by the RSIP 1413 gateway's policy, the RSIP gateway MUST respond with an 1414 ERROR_RESPONSE containing the REMOTE_ADDRPORT_UNALLOWED 1415 error. 1417 - If an unsupported or unallowed tunnel type is specified, the 1418 RSIP gateway MUST respond with an ERROR_RESPONSE containing 1419 the BAD_TUNNEL_TYPE error. 1421 - If the host has not specified local or remote address or port 1422 information in enough detail, the RSIP gateway MUST respond 1423 with an ERROR_RESPONSE containing the FLOW_POLICY_VIOLATION 1424 error. 1426 9.17. LISTEN_RESPONSE 1427 9.17.1. Description 1429 A LISTEN_RESPONSE message is used by an RSIP gateway to respond 1430 to a LISTEN_REQUEST message from an RSIP host. The RSIP 1431 gateway MUST issue a bind ID, and specify the address and port 1432 which have been granted to the host. The gateway must also 1433 specify a tunnel type and lease time. 1435 If no remote flow policy is being used, the gateway MUST fill 1436 both the remote address and ports parameters with "don't care" 1437 values. If macro-flow based remote policy is used, the gateway 1438 MUST specify the remote address, but MAY or MAY NOT specify the 1439 remote port(s). If micro-flow based remote policy is used, the 1440 gateway MUST specify the remote address and ports parameter. 1442 9.17.2. Format 1444 ::= 1445 1446 1447 1448 1449
1450 1451
1452 1453 1454 1456 9.17.3. Behavior 1458 If no remote flow policy is being used, the gateway MUST fill 1459 both the remote address and ports parameters with "don't care" 1460 values. If macro-flow based remote policy is used, the gateway 1461 MUST specify the remote address, but MAY or MAY NOT specify the 1462 remote port(s). If micro-flow based remote policy is used, the 1463 gateway MUST specify the remote address and ports parameter. 1465 10. Discussion 1467 10.1. General Gateway Policy 1469 There is a significant amount of RSIP gateway policy that may be 1470 implemented, but is beyond the scope of this draft. We expect 1471 that most of this policy will be site-specific or implementation- 1472 specific and therefore do not make any recommendations. Examples 1473 of general gateway policy include: 1475 - How ports are allocated to RSIP hosts. 1476 - Preferred length of lease times. 1477 - How flow policy is applied to which hosts. 1478 - How an RSIP gateway with multiple public IP addresses that may 1479 be leased by RSIP clients determines how to partition and/or lease 1480 these addresses. 1482 10.2. Errors Not From the RSIP Protocol 1484 Once an RSIP host and gateway have established a relationship and 1485 the host is assigned resources to use, error may occur due to the 1486 host's misuse of the resources or its attempting to use unassigned 1487 resources. The following error behavior is defined: 1489 - If a host attempts to use a local address which it has not been 1490 allocated, the RSIP gateway MUST drop the associated packet(s) 1491 and send the host an ERROR_RESPONSE containing the 1492 LOCAL_ADDR_UNALLOWED error. 1494 - If a host attempts to use a local address / port tuple which it 1495 has not been allocated, the RSIP gateway MUST drop the 1496 associated packet(s) and send the host an ERROR_RESPONSE 1497 containing the LOCAL_ADDRPORT_UNALLOWED error. 1499 - If a host attempts to contact a remote address which has not 1500 been properly specified or otherwise approved (e.g., via an 1501 ASSIGN_RESPONSE_RSAP-IP and macro or micro based remote flow 1502 policy), the RSIP gateway MUST drop the associated packet(s) and 1503 send the host an ERROR_RESPONSE containing the 1504 REMOTE_ADDR_UNALLOWED error. 1506 - If a host attempts to contact a remote address / port tuple 1507 which has not been properly specified or otherwise approved 1508 (e.g., via an ASSIGN_RESPONSE_RSAP-IP and micro based remote 1509 flow policy), the RSIP gateway MUST drop the associated 1510 packet(s) and send the host an ERROR_RESPONSE containing the 1511 REMOTE_ADDRPORT_UNALLOWED error. 1513 - If a host attempts to establish or use an improper tunnel type, 1514 the RSIP gateway MUST respond with an ERROR_RESPONSE containing 1515 the BAD_TUNNEL_TYPE error. 1517 - If the RSIP gateway's detects a local fault which prevents its 1518 RSIP server module from continuing operation, the RSIP gateway 1519 MUST respond with an ERROR_RESPONSE containing the 1520 INTERNAL_SERVER_ERROR error. 1522 10.3. Default Tunnel Type and RSIP Method 1524 If an RSIP gateway does not specify a tunnel type or RSIP method 1525 as part of a REGISTER_RESPONSE, the host MUST assume a tunnel type 1526 of IP-IP and an RSIP method of RSAP-IP. 1528 10.4. Address and Port Requests and Allocation 1530 Regardless of local flow policy, an RSIP host may "suggest" that 1531 it would like to use a particular local address and/or port number 1532 in a particular binding. An RSIP gateway that cannot grant such a 1533 request, because the specified resources are already in use, MUST 1534 respond with an ERROR_RESPONSE containing the LOCAL_ADDR_INUSE or 1535 LOCAL_ADDRPORT_INUSE values. 1537 10.5. Local Gateways and Flow Policy Interaction 1539 An RSIP host may initialize a publically accessible gateway (such 1540 as an FTP or HTTP gateway) by transmitting a LISTEN_REQUEST 1541 message to an RSIP gateway and receiving a LISTEN_RESPONSE. 1542 However, unless no remote flow policy is used, the gateway will 1543 have to specify the address or address and port of a single remote 1544 host that will be allowed to contact it. Obviously, such as 1545 restriction is not very useful for hosts that require their 1546 gateways to be accessible by any remote host. 1548 This indicates that there is a conflict between flow-based policy 1549 and support for gateways. The main purpose of enforcing flow- 1550 based policy for LISTEN_REQUESTs is that it allows an RSIP gateway 1551 tight control over how an RSIP host uses ports and the associated 1552 accounting. For example, an RSIP host, operating under remote 1553 micro-flow based policy and using a protocol such as FTP, will 1554 have to specify the address and port that it will receive FTP data 1555 on, as well as the address and port that the gateway will transmit 1556 data from, in a LISTEN_REQUEST. 1558 In general, an RSIP gateway may not allow arbitrary hosts to start 1559 public gateways because of the traffic and security concerns. 1560 Thus, we recommend that if remote micro-flow based policy is used, 1561 that an RSIP gateway only allow public gateways on RSIP hosts via 1562 administrative override. 1564 Currently, RSIP hosts can only be identified by their local IP 1565 address or MAC address. 1567 11. Security Considerations 1569 RSIP, in and of itself, does not provide security. It may provide 1570 the illusion of security or privacy by hiding a private address 1571 space, but security can only be ensured by the proper use of security 1572 protocols and cryptographic techniques. 1574 An RSIP gateway should take all measures deemed necessary to prevent 1575 its hosts from performing intentional or unintentional denial-of- 1576 service attacks by request large sets of resources. 1578 Currently, RSIP hosts can only be identified by their local IP 1579 address or MAC address. It is desirable to allow RSIP messages sent 1580 between a host and gateway to be authenticated. Further discussion 1581 of such authentication can be found in [RSIP-FRAME]. 1583 Discussion of RSIP support for end-to-end IPSEC can be found in 1584 [RSIP-IPSEC]. 1586 12. IANA Considerations 1588 All of the designations below are tentative. 1590 - RSIP port number: 4455 (pending approval). 1591 - RSIP error codes (see Appendix A). 1592 - RSIP message type codes (see Appendix B). 1593 - RSIP tunnel types, methods, and flow policies. 1595 RSIP parameter values are designated as follows: 1596 - 0 Reserved 1597 - 1-240 Assigned by IANA 1598 - 241-255 Reserved for private use 1600 New registrations for the above namespaces are recommended to be 1601 allocated via the Specification Required method documented in 1602 [RFC2434]. 1604 13. Changelog 1606 05 to 06 1607 - Terminology change. An "RSIP client" now refers to the application 1608 that performs RSIP client duties -- i.e., running the client 1609 side of the RSIP protocol. The physical device on which the RSIP 1610 client runs is now called the "RSIP host". An "RSIP server" now 1611 refers to the application that performs RSIP server duties -- 1612 i.e., running the server side of the RSIP protocol. The physical 1613 device on which the RSIP server runs is now called the "RSIP 1614 gateway". 1615 - Specifying how to lease multiple public IPs is a policy issue and 1616 beyond the scope of the draft. 1617 - Fixed ambiguity with "don't care" value formats. 1619 - Addressed the scenario in which a host request n ports but the server 1620 cannot grant all n. 1621 - Noted that client applications that use ephemeral source ports will 1622 find it useful to specify "don't care" values for local ports. 1623 - Correction of numerous minor typos. 1625 04 to 05 1626 - Depreciated the OK message. DEALLOCATE message replaced by 1627 FREE_RESPONSE, which had evolved into the same exact message 1628 as DEALLOCATE. 1629 - Categorized all RSIP messages as either client or server and 1630 mandatory or optional. 1631 - Added discussion of behavior and error conditions to all RSIP 1632 messages. 1633 - Re-worked error messages as per the above. 1634 - Noted that for micro-flow policy, a ports parameter MUST contain 1635 exactly one port field. 1636 - Fixed IANA Considerations section 1637 - Added indicator parameter 1638 - Set aside parameter codes 241-255 for private use 1639 - Major revision of QUERY_REQUEST and QUERY_RESPONSE 1640 - Added discussion of error that occur from data flow 1642 03 to 04 1643 - Changed "client / server state" to "client / server relationship" 1644 in order to not overload the word "state". 1645 - Added section on transport protocol support. 1646 - Reduced the size of "don't care" value for Address and Port parameters. 1647 - Removed message IDs. 1648 - Addition of overall length field in all messages. 1649 - Added example of an RSA-IP session. 1650 - Divided error numbers by category. 1652 02 to 03 1653 - Overall re-write and editing. 1654 - Removed a number of extraneous details that are now covered in the 1655 framework draft. 1656 - Moved parameter and message type codes to appendices. 1657 - Added section on flow policy. 1658 - Modified address and port parameters to simplify and generalize. 1660 01 to 02: 1661 - Added section on server state. 1662 - Re-wrote section on parameter negotiation. 1663 - Added details to ICMP Handling section. 1664 - Added LISTEN_REQUEST and LISTEN_RESPONSE messages. 1665 - Added appendix with client state diagram. 1666 - Updated references with respect to RFC 2663. 1668 - Clarified use/non-use of message IDs between clients and servers. 1669 - Added recommendation that RSIP use port 4455 for initial 1670 implementation and testing, until further notice. 1671 - Bumped code values up by 1, made code value of 0 reserved. 1672 - Expanded ASSIGN_REQUEST into ASSIGN_REQUEST_ADDR for RSA-IP, 1673 ASSIGN_REQUEST_PORT for RSAP-IP and ASSIGN_REQUEST_EXT for lease 1674 extensions. The same expansion applies for ASSIGN_RESPONSE. 1675 - Indicated that all RSIP parameters must not appear more than once 1676 except for tunnel type and RSIP method in ASSIGN_REQUEST messages. 1677 - Exactly one error is now reported in each ERROR_RESPONSE message. 1679 00 to 01: 1680 - Eliminated number of IP addresses and IP address range 1681 parameters and fixed other parameters to reflect this change. 1682 - Added IP address request message. 1683 - Added discussion on authentication to Security Considerations 1684 section. 1685 - Added Miscellaneous Issues section. 1686 - Changed all mention of "sequence number" to "message ID". 1687 - Reformatted References section. 1688 - Added reference to RSIP framework draft. 1689 - Separated request and response messages, then renumbered them. 1690 - Required that all RSIP implementations support IP-IP tunneling 1691 and RSA-IP. 1692 - Modified message semantics slightly. 1693 - Added appendix with protocol example. 1694 - Added address and port resource error messages. 1695 - Specified that multiple error responses may be returned in the 1696 same ERROR_RESPONSE message. 1697 - RSIP method may now be specified per binding, so that different 1698 methods can be used when connecting to different external systems. 1699 - Synched up terminology with the latest NAT terminology draft. 1700 - Added mention of RSIP servers also implementing a NAT as a 1701 fallback. 1702 - Added DEALLOCATE and OK messages. 1703 - Tunneling now negotiated per bind rather than per-registration. 1705 14. Acknowledgements 1707 The authors would like to specifically thank Gabriel Montenegro, Pyda 1708 Srisuresh, Dan Nessett, Gary Jaszewski, Naveen Rajanikantha, Sudhakar 1709 Ramakrishna, and Rick Cobb for their input. The IETF NAT working 1710 group as a whole has been extremely helpful in the ongoing 1711 development of RSIP. 1713 15. Appendix A: RSIP Error Numbers 1715 This section provides descriptions for the error values in the RSIP 1716 error parameter. These error values are preliminary and are very 1717 likely to change over time as implementations are tested. 1719 All errors are grouped into the following categories: 1721 100's: General errors. 1723 101: UNKNOWN_ERROR. An error that cannot be identified has 1724 occurred. This error should be used when all other error 1725 messages are inappropriate. 1727 102: USE_TCP. A host has attempted to use UDP on a server that 1728 only supports TCP. 1730 103: FLOW_POLICY_VIOLATION: A host has not specified address or 1731 port information in enough detail for its assigned flow policy. 1733 104: INTERNAL_SERVER_ERROR: An RSIP server application has 1734 detected an unrecoverable error within itself or the RSIP 1735 gateway. 1737 200's: Parameter and message errors. The gateway uses these errors 1738 when it detects that a parameter or message is malformed, as well 1739 as when it does not understand a parameter or message. 1741 201: MISSING_PARAM. The request does not contain a required 1742 parameter. 1744 202: DUPLICATE_PARAM. The request contains an illegal duplicate 1745 parameter. 1747 203: EXTRA_PARAM. The request contains a parameter that it should 1748 not. 1750 204: ILLEGAL_PARAM. The gateway does not understand a parameter 1751 code. 1753 205: BAD_PARAM. A parameter is malformed. 1755 206: ILLEGAL_MESSAGE. The gateway does not understand the message 1756 type. The message type is neither mandatory nor optional. 1758 207: BAD_MESSAGE. A message is malformed and gateway parsing 1759 failed. 1761 208: UNSUPPORTED_MESSAGE: The host has transmitted an optional 1762 message that the gateway does not support. 1764 300's: Permission, resource, and policy errors. The gateway uses 1765 these errors when a host has attempted to do something that it is 1766 not permitted to do, or something that violated gateway policy. 1768 301: REGISTER_FIRST. The RSIP host has attempted to request or use 1769 resources without registering. 1771 302: ALREADY_REGISTERED. The host has attempted to register again 1772 without first de-registering. 1774 303: ALREADY_UNREGISTERED. The host has attempted to de-register 1775 but it is already in the unregistered state. 1777 304: REGISTRATION_DENIED: The gateway will not allow the host to 1778 register. 1780 305: BAD_CLIENT_ID. The host has referred to itself with the wrong 1781 client ID. 1783 306: BAD_BIND_ID. The request refers to a bind ID that is not 1784 valid for the host. 1786 307: BAD_TUNNEL_TYPE. The request refers to a tunnel type that is 1787 not valid for the host. 1789 308: LOCAL_ADDR_UNAVAILABLE. The gateway is currently not able to 1790 allocate ANY local address, but the host may try again later. 1792 309: LOCAL_ADDRPORT_UNAVAILABLE. The gateway is currently not 1793 able to allocate ANY local IP address / port tuple of the 1794 requested magnitude (i.e., number of ports), but the host may 1795 try again later. 1797 310: LOCAL_ADDR_INUSE. The gateway was not able to allocate the 1798 requested local address because it is currently used by another 1799 entity. 1801 311: LOCAL_ADDRPORT_INUSE. The gateway was not able to allocate 1802 the requested local address / port tuple because it is 1803 currently used by another entity. 1805 312: LOCAL_ADDR_UNALLOWED. The gateway will not let the host use 1806 the specified local IP address due to policy. 1808 313: LOCAL_ADDRPORT_UNALLOWED. The gateway will not let the host 1809 use the specified local address / port pair due to policy. 1811 314: REMOTE_ADDR_UNALLOWED. The gateway will not allow the host 1812 to establish a session to the specified remote address. 1814 315: REMOTE_ADDRPORT_UNALLOWED. The gateway will not allow the 1815 host to establish a session to the specified remote address / 1816 port tuple. 1818 400's: IPSEC errors. All errors specific to RSIP / IPSEC operation. 1819 See [RSIP-IPSEC]. 1821 16. Appendix B: Message Types 1823 This section defines the values assigned to RSIP message types. 1824 These values are preliminary and are likely to change over time as 1825 implementations are tested. We also indicate which RSIP entity, host 1826 or gateway, produces each messages, and whether it is mandatory or 1827 optional. All *_REQUEST messages are only to be implemented on 1828 hosts, while all *_RESPONSE messages are only to be implemented on 1829 gateways. RSIP implementations (both host and gateway) MUST support 1830 all mandatory messages in order to be considered "RSIP compliant". 1832 Value Message Implementation Status 1833 ------------------------------------------------------------ 1834 1 ERROR_RESPONSE gateway mandatory 1835 2 REGISTER_REQUEST host mandatory 1836 3 REGISTER_RESPONSE gateway mandatory 1837 4 DE-REGISTER_REQUEST host mandatory 1838 5 DE-REGISTER_RESPONSE gateway mandatory 1839 6 ASSIGN_REQUEST_RSA-IP host optional 1840 7 ASSIGN_RESPONSE_RSA-IP gateway optional 1841 8 ASSIGN_REQUEST_RSAP-IP host mandatory 1842 9 ASSIGN_RESPONSE_RSAP-IP gateway mandatory 1843 10 EXTEND_REQUEST host mandatory 1844 11 EXTEND_RESPONSE gateway mandatory 1845 12 FREE_REQUEST host mandatory 1846 13 FREE_RESPONSE gateway mandatory 1847 14 QUERY_REQUEST host optional 1848 15 QUERY_RESPONSE gateway mandatory 1849 16 LISTEN_REQUEST host optional 1850 17 LISTEN_RESPONSE gateway optional 1852 17. Appendix C: Example RSIP host/gateway transactions 1854 In this appendix, we present an exemplary series of annotated 1855 transactions between an RSIP host and an RSIP gateway. All host to 1856 gateway traffic is denote by `C --> S' and all gateway to host 1857 traffic is denoted by `S --> C'. Parameter values are denoted inside 1858 of parentheses. Versions, message types, and overall lengths are not 1859 included in order to save space. "Don't care" values are indicated 1860 by 0's. 1862 A ports parameter is represented by the number of ports followed by 1863 the port numbers, separated by dashes. For example, 2-1012-1013 1864 indicates two ports, namely 1012 and 1013, while 16-10000 indicates 1865 16 ports, namely 10000-10015, and 4-0 indicates four ports, but the 1866 sender doesn't care where they are. 1868 IPv4 addresses are assumed. 1870 17.1. RSAP-IP with Local Macro-flow Based Policy and No Remote Flow 1871 Policy 1873 This example exhibits the loosest policy framework for RSAP-IP. 1875 C --> S: REGISTER_REQUEST () 1877 The host attempts to register with the gateway. 1879 S --> C: REGISTER_RESPONSE (Client ID = 1, Local Flow Policy = 1880 Macro, Remote Flow policy = None) 1882 The gateway responds, assigning a Client ID of 1, local macro- 1883 flow based policy and no remote flow policy. No RSIP method is 1884 indicated, so RSAP-IP is assumed. No tunnel type is indicated, 1885 so IP-IP is assumed. 1887 C --> S: ASSIGN_REQUEST_RSAP-IP: (Client ID = 1, Address (local) = 1888 0, Ports (local) = 4-0, Address (remote) = 0, Ports (remote) = 1889 0, Lease Time = 3600) 1891 The host requests an address and four ports to use with it, but 1892 doesn't care which address or ports are assigned. The host 1893 does not specify the remote address or ports either. The host 1894 suggests a lease time of 3600 seconds. 1896 S --> C: ASSIGN_RESPONSE_RSAP-IP: (Client ID = 1, Bind ID = 1, 1897 Address (local) = 149.112.240.156, Ports (local) = 4-1234, 1898 Address (remote) = 0, Ports (remote) = 0, Lease Time = 1800, 1899 Tunnel Type = IP-IP) 1901 The gateway responds by indicating that a bind ID of 1 has been 1902 assigned to IP address 149.112.240.156 with ports 1234-1237. 1903 Any remote host may be communicated with, using any remote port 1904 number. The lease time has been assigned to be 1800 seconds, 1905 and the tunnel type is confirmed to be IP-IP. 1907 The host is now able to communicate with any host on the public 1908 network using these resources. 1910 C --> S: QUERY_REQUEST: (Client ID = 1, Indicator = network, 1911 Address (network) = 10.20.60.0, Address (netmask) 1912 255.255.255.0) 1914 The host asks the gateway if the network 10.20.60.0/24 is 1915 local. 1917 S --> C: QUERY_RESPONSE: (Client ID = 1, Indicator = network, 1918 Address (network) = 10.20.60.0, Address (netmask) = 1919 255.255.255.0) 1921 The gateway responds indicating that the network in question is 1922 local. 1924 C --> S: ASSIGN_REQUEST_RSAP-IP: (Client ID = 1, Address (local) = 1925 149.112.240.156, Ports (local) = 8-1238, Address (remote) = 0, 1926 Ports (remote) = 0, Lease Time = 1800) 1928 The host requests eight more particular ports for use with 1929 RSAP-IP with the same address. A lease of 1800 seconds is 1930 requested. IP-IP tunneling is implied by default. 1932 S --> C: ASSIGN_RESPONSE_RSAP-IP: (Client ID = 1, Bind ID = 2, 1933 Address (local) = 149.112.240.156, Ports (local) = 8-1305, 1934 Address (remote) = 0, Ports (remote) = 0, Lease Time = 1800) 1936 The gateway grants the request with the same address, but with 1937 a different set of ports. IP-IP tunneling is implied by 1938 default. 1940 C --> S: FREE_REQUEST (Client ID = 1, Bind ID = 1) 1942 The host frees bind ID 1; i.e., ports 1234-1237 from IP address 1943 149.112.240.156. Note that the address itself is still 1944 assigned to the host because the host is still assigned ports 1945 1305-1314. 1947 S --> C: FREE_RESPONSE (Client ID = 1, Bind ID = 1) 1949 The gateway acknowledges that Bind ID 1 has been freed. 1951 C --> S: EXTEND_REQUEST (Client ID = 1, Bind ID = 2, Lease Time = 1952 1800) 1954 The host request that the lease on bind ID 1 be extended for 1955 1800 seconds. 1957 S --> C: EXTEND_RESPONSE (Client ID = 1, Bind ID = 2, Lease Time = 1958 1800) 1960 The gateway confirms the request. 1962 S --> C: FREE_RESPONSE (Client ID = 1, Bind ID = 2) 1964 The gateway forces the host to free the resources of bind ID 2. 1966 C --> S: DE-REGISTER_REQUEST (Client ID = 1) 1968 The host de-registers with the sever. 1970 S --> C: REGISTER_RESPONSE (Client ID = 1) 1972 The gateway acknowledges that the host has de-registered. 1974 17.2. RSAP-IP with Local Micro-flow Based Policy and Remote Micro- 1975 flow Based Policy 1977 This example exhibits the strictest policy framework for RSAP-IP. 1979 C --> S: REGISTER_REQUEST () 1981 The host attempts to register with the gateway. 1983 S --> C: REGISTER_RESPONSE (Client ID = 5, Local Flow Policy = 1984 Micro, Remote Flow policy = Micro, RSIP Method = RSAP-IP, RSIP 1985 Method = RSA-IP, Tunnel Type = IP-IP, Tunnel Type = GRE) 1987 The gateway responds, assigning a Client ID of 5, local micro- 1988 flow based policy and remote micro-flow based policy. Both 1989 RSAP-IP and RSA-IP are supported. Both IP-IP and GRE tunnel 1990 types are supported. 1992 C --> S: ASSIGN_REQUEST_RSAP-IP: (Client ID = 5, Address (local) = 1993 0, Ports (local) = 0, Address (remote) = 38.196.73.6, Ports 1994 (remote) = 21, Lease Time = 600, Tunnel Type = IP-IP) 1996 The host requests a local address and a port assignment to use 1997 with it. The host indicates that it wants to contact host 1998 38.196.73.6 at port 21 (FTP control). The host requests a 1999 lease time of 600 seconds and a tunnel type of IP-IP. 2001 S --> C: ASSIGN_RESPONSE_RSAP-IP: (Client ID = 5, Bind ID = 1, 2002 Address (local) = 149.112.240.156, Ports (local) = 2049, 2003 Address (remote) = 38.196.73.6, Ports (remote) = 21, Lease Time 2004 = 600, Tunnel Type = IP-IP) 2006 The gateway responds by indicating that a bind ID of 1 has been 2007 assigned to IP address 149.112.240.156 with port 2049. Only 2008 host 38.196.73.6 at port 21 may be contacted. The lease time 2009 has been assigned to be 600 seconds, and the tunnel type is 2010 confirmed to be IP-IP. 2012 C --> S: LISTEN_REQUEST: (Client ID = 5, Address (local) = 2013 149.112.240.156, Ports (local) = 2050, Address (remote) = 2014 38.196.73.6, Ports (remote) = 20) 2016 The host requests a listen port 2050 at the same address that 2017 it has been assigned. Only host 38.196.73.6 from ports 20 (FTP 2018 data) will be able to contact it. 2020 S --> C: LISTEN_RESPONSE: (Client ID = 5, Address (local) = 2021 149.112.240.156, Ports (local) = 2050, Address (remote) = 2022 38.196.73.6, Ports (remote) = 20, Lease Time = 600, Tunnel Type 2023 = IP-IP) 2025 The gateway confirms the request and assigns a lease time of 2026 600 seconds and a tunnel type of IP-IP. 2028 C --> S: DE-REGISTER_REQUEST (Client ID = 5) 2030 The host de-registers with the sever. 2032 S --> C: REGISTER_RESPONSE (Client ID = 5) 2034 The gateway acknowledges that the host has de-registered. All 2035 of the host's bindings have been implicitly revoked. 2037 17.3. RSA-IP with Local Macro-flow Based Policy and Remote Macro- 2038 flow based Policy 2040 This example exhibits a medium level of control for RSA-IP. 2042 C --> S: REGISTER_REQUEST () 2044 The host attempts to register with the gateway. 2046 S --> C: REGISTER_RESPONSE (Client ID = 3, Local Flow Policy = 2047 Macro, Remote Flow policy = Macro, RSIP Method = RSAP-IP, RSIP 2048 Method = RSA-IP, Tunnel Type = IP-IP, Tunnel Type = L2TP) 2050 The gateway responds, assigning a Client ID of 3, local macro- 2051 flow based policy and remote macro-flow based policy. Both 2052 RSAP-IP and RSA-IP are supported. Both IP-IP and L2TP tunnel 2053 types are supported. 2055 C --> S: ASSIGN_REQUEST_RSA-IP: (Client ID = 3, Address (local) = 2056 0, Address (remote) = www.foo.com, Ports (remote) = 0, Lease 2057 Time = 3600, Tunnel Type = IP-IP) 2059 The host requests a local address and indicates that it wants 2060 to contact host www.foo.com. 2062 S --> C: ERROR_RESPONSE: (Error = REMOTE_ADDR_UNALLOWED, Client ID 2063 = 3) 2065 The gateway indicates that the host is not permitted to 2066 establish communication with www.foo.com. 2068 C --> S: ASSIGN_REQUEST_RSA-IP: (Client ID = 3, Address (local) = 2069 0, Address (remote) = www.bar.com, Ports (remote) = 0, Lease 2070 Time = 3600, Tunnel Type = IP-IP) 2072 The host requests a local address and indicates that it wants 2073 to contact host www.bar.com. 2075 S --> C: ASSIGN_RESPONSE_RSA-IP: (Client ID = 3, Bind ID = 1, 2076 Address (local) = 149.112.240.17, Address (remote) = 2077 www.bar.com, Ports (remote) = 0, Lease Time = 3600, Tunnel Type 2078 = IP-IP) 2080 The gateway responds by granting local IP address 2081 149.112.240.17 to the host, and permitting it to communicate 2082 with www.bar.com, at any port. Requested lease time and tunnel 2083 type are also granted. 2085 C --> S: DE-REGISTER_REQUEST (Client ID = 3) 2087 The host de-registers with the sever. 2089 S --> C: REGISTER_RESPONSE (Client ID = 3) 2091 The gateway acknowledges that the host has de-registered. All 2092 of the host's bindings have been implicitly revoked. 2094 18. Appendix D: Example RSIP host state diagram 2096 This appendix provides an exemplary diagram of RSIP host state. The 2097 host begins in the unregistered state. We assume that for UDP, if a 2098 message is lost, the host will timeout and retransmit another copy of 2099 it. We recommend a 7-fold binary exponential backoff timer for 2100 retransmissions, with the first timeout occurring after 12.5 ms. 2101 This diagram does not include transitions for the LISTEN_REQUEST 2102 message. 2104 send 2105 +------------+ REGISTER_REQUEST +------------+ 2106 | |----------------->|Registration|<-- timeout/send 2107 +--->|Unregistered|<-----------------| Pending |--- REGISTER_REQUEST 2108 | | | 7th timeout/recv +------------+ 2109 | +------------+ ERROR_RESPONSE | 2110 | ^ | 2111 | |7th timeout/recv |recv timeout/send 2112 | |DE-REGISTER_RESPONSE |REGISTER_RESPONSE QUERY_REQUEST 2113 | | | ^ | 2114 | | send DE- v send | | 2115 | +----------------+ REGISTER_REQUEST+----------+QUERY_REQUEST +----------+ 2116 | | Registered |<----------------| |-------------->|Registered| 2117 | | De-registration| |Registered| | Query | 2118 | | Pending |---------------->| |<--------------| Pending | 2119 | +----------------+ recv +----------+ 7th timeout/ +----------+ 2120 | | ^ ERROR_RESPONSE ^ | recv 2121 | | | | | QUERY_RESPONSE or 2122 | timeout/send | | ERROR_RESPONSE 2123 | DE-REGISTER_REQUEST 7th timeout/recv| | 2124 | ERROR_RESPONSE | | 2125 | +----------------+ | | 2126 | |Go to Registered| | |send 2127 | +----------------+ | |ASSIGN_REQUEST 2128 | ^ timeout/send | | 2129 | |Yes FREE_REQUEST | | 2130 | + | | | | 2131 | + + v | | v 2132 | + + 7th timeout/ +--------+ +----------+ 2133 | + Are all + recv | Free | |Assignment|<--timeout/send 2134 | + resources +<-----------|Pending | | Pending |---ASSIGN_REQUEST 2135 | + freed? + FREE_RESPONSE+--------+ +----------+ 2136 | + + ^ | | 2137 | + + | | | 2138 | + | | |recv 2139 | |No send | |recv |ASSIGN_RESPONSE 2140 | v ERROR_REQUEST| |ERROR_ | 2141 | +---------------+ | |RESPONSE | 2142 | | Go to Assigned| | | | 2143 | +---------------+ | | | 7th timeout/recv 2144 | recv | | | QUERY_RESPONSE or 2145 | +---------------+ERROR_RESPONSE | v v ERROR_RESPONSE+-------------+ 2146 | | Assigned |-------------->+-------------+------------->| Assigned | 2147 +>|De-registration| | Assigned | | Query | 2148 | Pending |<--------------+-------------+<-------------| Pending | 2149 +---------------+ send ^ | send +-------------+ 2150 ^ | DE-REGISTER_REQUEST | | QUERY_REQUEST ^ | 2151 | | | | | | 2152 timeout/send 7th/timeout/recv | |send | | 2153 DE-REGISTER_ ASSIGN_RESPONSE | |ASSIGN_REQUEST timeout/send 2154 REQUEST or ERROR_RESPONSE| | QUERY_REQUEST 2155 | | 2156 | v 2157 +----------+ 2158 | Assigned | 2159 |Assignment| 2160 | Pending | 2161 +----------+ 2162 ^ | 2163 | | 2164 timeout/send 2165 ASSIGN_REQUEST 2167 19. References 2169 [RFC1918] Y. Rekhter, B. Moskowitz, D. Karrenberg, G. J. de Groot, 2170 and E. Lear, "Address Allocation for Private Internets," RFC 1918, 2171 Feb. 1996. 2173 [RFC2119] S. Bradner, "Key words for use in RFCs to indicate 2174 requirement levels," RFC 2119, Mar. 1997. 2176 [RFC2434] T. Narten and H. Alvestrand, "Guidelines for Writing an 2177 IANA Considerations Section in RFCs," RFC 2434, Oct. 1998. 2179 [RFC2663] P. Srisuresh and M. Holdrege, "IP Network Address 2180 Translator (NAT) Terminology and Considerations," RFC 2663, Aug. 2181 1999. 2183 [RSIP-FRAME] M. Borella, J. Lo, D. Grabelsky, and G. Montenegro, 2184 "Realm Specific IP: Framework," Internet Draft , Dec. 1999 (work in progress). 2187 [RSIP-IPSEC] G. Montenegro and M. Borella, "RSIP Support for End-to- 2188 end IPSEC," , work in progress, 2189 Feb. 2000. 2191 20. Authors' Addresses 2193 Michael Borella 2194 3Com Corp. 2195 1800 W. Central Rd. 2196 Mount Prospect IL 60056 2197 (847) 342-6093 2198 mike_borella@3com.com 2200 David Grabelsky 2201 3Com Corp. 2202 1800 W. Central Rd. 2203 Mount Prospect IL 60056 2204 (847) 222-2483 2205 david_grabelsky@3com.com 2207 Jeffrey Lo 2208 NEC USA 2209 C&C Research Labs. 2210 110 Rio Robles 2211 San Jose, CA 95134 2212 (408) 943-3033 2213 jlo@ccrl.sj.nec.com 2215 Kunihiro Taniguchi 2216 NEC USA 2217 C&C Research Labs. 2218 110 Rio Robles 2219 San Jose, CA 95134 2220 (408) 943-3031 2221 taniguti@ccrl.sj.nec.com 2223 21. Copyright Statement 2225 Copyright (c) The Internet Society (2000). All Rights Reserved. 2227 This document and translations of it may be copied and furnished to 2228 others, and derivative works that comment on or otherwise explain it 2229 or assist in its implementation may be prepared, copied, published and 2230 distributed, in whole or in part, without restriction of any kind, 2231 provided that the above copyright notice and this paragraph are 2232 included on all such copies and derivative works. However, this 2233 document itself may not be modified in any way, such as by removing 2234 the copyright notice or references to the Internet Society or other 2235 Internet organizations, except as needed for the purpose of developing 2236 Internet standards in which case the procedures for copyrights defined 2237 in the Internet Standards process must be followed, or as required to 2238 translate it into languages other than English. 2240 The limited permissions granted above are perpetual and will not be 2241 revoked by the Internet Society or its successors or assigns. 2243 This document and the information contained herein is provided on an 2244 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 2245 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT 2246 NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN 2247 WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 2248 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.