INTERNET DRAFT Editors: Expires April 2000 M. Borella 3Com Corp. J. Lo NEC USA Contributors: D. Grabelsky 3Com Corp G. Montenegro Sun Microsystems October 1999 Realm Specific IP: Framework Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This draft examines the general framework of Realm Specific IP (RSIP). RSIP is intended as a alternative to NAT in which the end-to- end integrity of packets is maintained. We document RSIP's interaction with other layer-three protocols and discuss the tradeoffs between different methods for implementing RSIP. 1. Introduction Borella et. al. Expires April 2000 [Page 1] INTERNET DRAFT Realm Specific IP: Framework October 1999 Network Address Translation (NAT) has become a popular mechanism of enabling private addressing and the separation of addressing spaces. A NAT router must examine and change the network layer, and possibly the transport layer, header of each packet crossing the addressing domains that the NAT router is connecting. This causes the mechanism of NAT to violate the end-to-end nature of the Internet connectivity, and disrupts protocols requiring or enforcing such end-to-end connectivity, such as the network security protocols which embody IPSEC. While NAT does not require a host to be aware of its presence, it requires the presence of a proxy module, the application layer gateway (ALG), within the NAT router for each application that embeds addressing information, IP address or port content, within the packet payload (e.g FTP). Given these limitations, RSIP has emerged as a alternative to remedy them. RSIP is based on the concept of granting host from one addressing realm a presence in another addressing realm by allowing it to use resources (e.g. addresses and other routing parameters) from the second addressing realm. RSIP requires ability of the RSIP server to grant such resources to RSIP clients. Hosts requiring end-to-end connectivity from the first addressing realm to the second also has to be RSIP aware. ALGs are not required on the RSIP server for communications between an RSIP client and a host on a different addressing realm. It is important to note that RSIP is not a replacement for IPv6. We fully advocate the adoption and deployment of IPv6. RSIP has been designed to restore some of the end-to-end transparency that NAT has taken away from the Internet, and smooth the IPv6 transition process. Upcoming documents will explain this transition in more detail. 2. Terminology Private Realm A routing realm that uses private IP addresses from the ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) specified in [RFC1918], or addresses that are non-routable from the Internet. Public Realm A routing realm with unique network addresses assigned by the Internet Assigned Number Authority (IANA) or an equivalent address registry. RSIP Server Borella et. al. Expires April 2000 [Page 2] INTERNET DRAFT Realm Specific IP: Framework October 1999 A router situated on the boundary between a private realm and a public realm and owns one or more public IP addresses. An RSIP server is responsible for public parameter management and assignment to RSIP clients. An RSIP server may act as a normal NAT router for hosts within the private realm that are not RSIP enabled. RSIP Client A host within the private realm that assumes publicly unique parameters from an RSIP server through the use of RSIP. RSA-IP: Realm Specific Address IP An RSIP method in which each RSIP client is allocated a unique IP address from the public realm. Discussed in detail in [RFC2663] RSAP-IP: Realm Specific Address and Port IP An RSIP method in which each RSIP client is allocated an IP address (possibly shared with other RSIP clients) and some number of per-address unique ports from the public realm. Discussed in detail in [RFC2663] RSIP-enabled Mobile Node (RMN) A host that uses RSIP for connectivity to the public network, and also uses Mobile IP for roaming support. RSIP Home Network (RHN) A network on which a number of hosts use RSIP to share one or more public IP addresses. RSIP Home Agent (RHA) A router, running an RSIP server, that manages Mobile IP connectivity for RSIP-enabled mobile nodes belonging to an RSIP home network. RSIP Foreign Network (RFN) A network which can support RSIP-enabled mobile nodes as they roam. RSIP Foreign Agent (RFA) A router that manages Mobile IP connectivity for roaming RSIP- Borella et. al. Expires April 2000 [Page 3] INTERNET DRAFT Realm Specific IP: Framework October 1999 enabled mobile nodes. This router may or may not use RSIP on its local network. All other terminology found in this document is consistent with that of [RFC2663] and [RFC2002]. 3. Specification of Requirements The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this documents are to be interpreted as described in [RFC2119]. 4. Architecture In a typical scenario where RSIP is deployed, there are some number of hosts within one addressing realm connected to another addressing realm by the RSIP server. This model is diagrammatically represented as follows: RSIP Client RSIP Server Host Xa Na Nb Yb [X]------( Addr sp. A )----[N]-----( Addr sp. B )-------[Y] ( Network ) ( Network ) Hosts X and Y belong to different addressing realms A and B, respectively, and N is an RSIP server (which may also act as a NAT router). 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. As is often the case, the hosts within address space A are likely to use private addresses while the RSIP server is multi-homed with one or more private addresses from address space A in addition to it's public addresses from address space B. Host X wishing 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 (e.g. addresses and other routing parameters of address space B) from the RSIP server. Upon assignment of these parameters, the RSIP server creates a mapping, known as a bind, of X's addressing information and the assigned resources. This binding enables the RSIP server to correctly de-multiplex and forward inbound traffic generated by Y for X. If permitted by the RSIP server, X may create multiple such bindings on the same RSIP server. A lease time SHOULD be associated with each bind. Using the public parameters assigned by the RSIP server, RSIP clients Borella et. al. Expires April 2000 [Page 4] INTERNET DRAFT Realm Specific IP: Framework October 1999 route (usually tunnel) data packets to the RSIP server within address space A. If tunneling is used, the RSIP server 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 server maintains a mapping of the assigned public parameters as demultiplexing tuples for uniquely mapping them to RSIP client private addresses. When a packet from the public realm arrives at the RSIP server and it matches a given set of demultiplexing tuples, then the RSIP server will tunnel it to the appropriate RSIP client. A disadvantage of RSIP is that it requires modification of RSIP clients to enable RSIP client-server negotiation, usage of the assigned resources and in the case when tunneling is used, to tunnel the data packets to the RSIP server. 5. Client and Server Requirements An RSIP client must be able to maintain one or more virtual interfaces for the IP address(es) that it leases from an RSIP server. The client must also support tunneling and be able to serve as an end-point for one or more tunnels to RSIP servers. An RSIP client MUST NOT respond to ARPs for a public realm address that it leases. An RSIP server is a multi-homed host that routes packets between two or more realms. It must also support tunneling and be able to serve as an end-point for tunnels to RSIP clients. The RSIP server MAY be a policy enforcement point, which in turn may require it to perform firewall and packet filtering duties in addition to RSIP. The RSIP server must reassemble all incoming packet fragments from the public network in order to be able to route and tunnel them to the proper client. As is necessary for all fragment reassembly, an RSIP server must timeout fragments that are never fully reassembled. 6. Demultiplexing Fields Assume that an RSIP client within a private realm has transmitted a request to a public server within a public realm, and the public server has sent a response packet that successfully arrived at the RSIP server. Based on a pre-arranged mapping, the RSIP server must be able to determine the private IP address of the packet's destination; i.e., the RSIP client. The only information that the RSIP server may use is what is already contained within the headers of the inbound data packet, or in the payload of the packet if said payload is not encrypted. We will refer to these header fields as the "demultiplexing fields" as they are used to spread the incoming streams of packets to multiple destinations within the private realm. Depending on the type of mapping used by the RSIP server, Borella et. al. Expires April 2000 [Page 5] INTERNET DRAFT Realm Specific IP: Framework October 1999 demultiplexing fields have been defined in [RSIP-PROTO] to be one or more of the following: - destination IP address - IP protocol - destination TCP or UDP port - IPSEC SPI present in ESP or AH header (see [RSIP-IPSEC]) - ISAKMP initiator cookie present in IKE payload (see [RSIP-IPSEC]) - others Demultiplexing of incoming traffic could be logically thought of as a decision tree, which could be represented as follows : - In the case where a public IP address is assigned for each client, a unique public IP address is mapped to each RSIP client. - If the same IP address is used for more than one RSIP client, then subsequent headers must have at least one field that will be assigned a unique value per client so that it is usable as a demultiplexing field. The IP protocol field SHOULD be used to determine what in the subsequent headers these demultiplexing fields ought to be. - If the subsequent header is TCP or UDP, then destination port number can be used. However, if the TCP and UDP port number is the same for more than one RSIP client, the payload section of the packet must contain a demultiplexing field that is guaranteed to be different for each RSIP client. - If the subsequent header is anything other than TCP or UDP, there must exist other fields within the IP payload usable as a demultiplexing fields. It is desirable for all demultiplexing fields to occur in well-known fixed locations so that an RSIP server can mask out and examine the appropriate fields on incoming packets. 7. Negotiation Protocol 7.1. Encapsulation Demultiplexing of incoming streams of packet requires pre- assignment of the demultiplexing fields to RSIP clients. Hence there exists a requirement for a negotiation protocol that enables these parameters to be negotiated between RSIP server and RSIP clients. Such a negotiation can be based on the following approaches. - As an extension of current host configuration or policy protocols such as DHCP, COPS, RADIUS, DIAMETER, or SOCKS. - During tunnel establishment, for example as an extension to L2TP Borella et. al. Expires April 2000 [Page 6] INTERNET DRAFT Realm Specific IP: Framework October 1999 parameter negotiation. - As an RSIP specific protocol such as described in [RSIP-PROTO]. In order to ease initial deployment of RSIP, the protocol described in [RSIP-PROTO] is the recommended approach. The demultiplexing fields to be negotiated may actually differ depending on the data traffic type that the RSIP client is negotiating for. For example, for IPSEC data traffic using Security Payload Index (SPI) as the demultiplexing field, the assignment of SPI value has to be negotiated. Hence it is necessary to have a mechanism built into the negotiation protocol that enables RSIP client to indicate to the RSIP server which data type it is negotiating the parameters for. Using this information, the RSIP server would be able to associate the binding information to the appropriate location on the decision tree. 7.2. Transport The RSIP protocol defined in [RSIP-PROTO] has been defined to operate over either UDP or TCP. Despite the well-known advantages and disadvantages of each of these protocols, it is important to consider the particular characteristic of RSIP before deciding on a transport for the negotiation protocol. RSIP is likely to be a candidate for thin clients and embedded systems. These devices are typically implemented on hardware that is processing and memory constrained. Thus, UDP is a natural candidate. However, UDP adds additional complexity to the application layer implementation, because both client and server must perform timeouts and retransmissions. Furthermore, it is easier for the client and server to fall out of synchronization with each other. A TCP implementation not only has the advantage of reliability, and therefore a simpler application design, but also it is easier for a server to audit and authenticate a TCP stream. In large deployments, however, such as large enterprise networks with thousands of potential RSIP clients, the number of TCP sessions available at the RSIP server may become a bottleneck. In this case, use of UDP may be necessary. TCP is the recommended transport protocol for RSIP. RSIP servers SHOULD support both TCP and UDP for RSIP transport because not all client devices will have a TCP module available and UDP may be more desirable than TCP in some scenarios. It should be noted that if RSIP is to be used by remote access Borella et. al. Expires April 2000 [Page 7] INTERNET DRAFT Realm Specific IP: Framework October 1999 concentrators, then the RSIP protocol will likely be implemented on top on IPCP. 7.3. Control Parameters Apart from negotiation of demultiplexing fields, other information pertaining to the assignment of those fields may also need to be negotiated. Examples of such control parameters are: - Client ID: The negotiation protocol MAY support registration of the RSIP client with the RSIP server. Upon a successful registration, a client ID unique to the RSIP client entity is generated. The client ID facilitates the association of an RSIP client record on an RSIP server with its established bindings. After the registration, further communication between the RSIP client and server MAY use the client ID as an identifier. The client ID is removed upon client de-registration. - Bind ID: A binding identifier MAY be assigned for each public parameter assignment. The binding identifier serves to uniquely identify the resource(s) that has been allocated by an RSIP server. It may also be used during lookup to efficiently index existing bindings. - Lease time: A duration may be associated with each bind of public parameters to an RSIP client. - RSIP method: RSIP clients MAY require that the RSIP server specify how it allocates address and port resources (referred to as the RSIP method). RSIP servers may only allocate a public IP address to each unique host, known as RSA-IP. Or, RSIP-servers may distribute a (potentially shared) public IP address and a unique port range per that IP address to each host, termed RSAP-IP. In addition, RSIP extension for a new protocol may define a new RSIP method such that RSIP server could assign protocol specific demultiplexing fields based on the new RSIP methods. - Tunnel Type: The type of tunnel to use between an RSIP client and RSIP server. For example, IP-IP, GRE, L2TP, and so on. The negotiation and assignment mechanism SHOULD be extensible and facilitate vendor specific parameters. 8. Tunnel Use and Establishment on the Private Network Once the public demultiplexing fields have been allocated by the RSIP server, RSIP clients will be able to use them freely. However, RSIP requires data packets to be tunneled between the RSIP client and server within the private realm since public routing information is not advertised in the private realm. The type of tunnel may be IP-IP, GRE, IPSEC tunnel mode, L2TP, or other forms. IP-IP tunneling is the preferred mode and MUST be implemented by all RSIP devices that use UDP or TCP. Borella et. al. Expires April 2000 [Page 8] INTERNET DRAFT Realm Specific IP: Framework October 1999 The tunneling requirement allows the RSIP server to be able to transmit a packet it receives from the public network to the appropriate RSIP client on the private network. While tunneling is not absolutely necessary in order to transmit packets from the RSIP client to the RSIP server, it is advantageous to establish a tunnel in this direction as well since it is likely that an RSIP server will also act as a firewall or packet filter for the private network. In this case, if publically addressed packets are transmitted on the private network, the RSIP server may consider these packets to be part of an attack. Tunnels may be established statically or dynamically between RSIP clients and servers. A static tunnel is established at RSIP initiation and remains in service until the host is no longer using the public network. A dynamic tunnel is established at the beginning of a session or flow and exists only for the lifetime of the session. Both types of tunnels may allow for on-the-fly re-negotiation of demultiplexing fields and re-assignment of parameters to RSIP clients. If tunneling is used to route the publicly addressed packet within private realm, public parameter negotiation could be associated with tunnel establishment mechanisms. Alternatively, a negotiation protocol may enable the negotiation of tunnel type as well. 9. MTU Limitation to Prevent Fragmentation and ID Collision RSIP clients MUST limit their MTU so that packets transmitted by an RSIP server are not fragmented. If two or more RSIP clients on the same private network transmit outbound packets that get fragmented to the same public server, the public server may experience a reassembly ambiguity if the IP header ID fields of these packets are identical. For TCP packets, this is not an issue if path MTU discovery work properly. For UDP packets, an artificially small MTU, such as 512 bytes, is required. We expect that the impact of this limitation will be small since UDP packets found on a public network should be typically less than a few hundred bytes. 10. Servers on RSAP-IP Clients RSAP-IP clients are limited by the same constraints as NAT with respect to hosting servers that use a well-known port. Since destination port numbers are used as routing information to uniquely identify an RSAP-IP client, typically no two RSAP-IP clients sharing the same public IP address can simultaneously operate publically- available servers on the same port. For protocols that operate on well-known ports, this implies that only one public server per RSAP- IP IP address / port tuple is used simultaneously. However, more Borella et. al. Expires April 2000 [Page 9] INTERNET DRAFT Realm Specific IP: Framework October 1999 than one server per RSAP-IP IP address / port tuple may be used simultaneously if and only if there is a unique token within the payload of all packets that will determine the identity of the RSAP- IP client, and this token is known by the RSIP server (see [RSIP- IPSEC]). In order for an RSAP-IP client to operate a publically-available server, the client must inform the RSIP server that it wishes to receive all traffic destined to that port number, per its IP address. Such a request MUST be denied if the port in question is already in use by another client. See [RSIP-PROTO] for an example of the signaling required in order to enable such a mechanism. 11. Determining Locality of Destinations from an RSIP Client In general, an RSIP client must know, for a particular IP address, whether it should transmit the packet normally for local delivery, or tunnel the packet to the RSIP server. Since more than one subnet may be behind an RSIP server, looking at a local subnet mask will not always work. We'd rather not have to propagate routing tables to all RSIP clients. A simple alternative, proposed in [RSIP-PROTO], that will solve this problem is to require that the RSIP server knows all of the subnets that are on the private network. This information can be manually entered because it is not expected to change often. Then, if an IP address in question is not on a host's local subnet, the host can query the server with the address. The RSIP server will return a simple "yes or "no" answer - yes, this address is local, or no, it is not. As proposed in [RSIP-PROTO], a queried RSIP server may respond with the list of subnets supported. An RSIP client may cache this information. However, in large enterprise networks, an RSIP server may not be aware of all private subnets. Alternatively, RSIP-clients could send all packets for destinations without an explicit static route to the RSIP server. If they arrive at the RSIP server, it informs the host that it should instead tunnel the packet. The host then acquires the necessary public parameters and tunnels the packet, to the RSIP server. This approach may require further changes to the TCP/IP stack at the host, since, in the case of TCP traffic, a half-open TCP socket must be discarded. Likewise, the RSIP client could at first tunnel the packets to the RSIP server. If the server determines that the destination is local, it would inform the host of this fact and the host could then transmit the packet in the standard fashion. Regardless of the solution chosen, RSIP clients caching the "locality" of recently-contacted IP addresses may be beneficial. 12. Implementing RSIP Client Deallocation Borella et. al. Expires April 2000 [Page 10] INTERNET DRAFT Realm Specific IP: Framework October 1999 As currently defined in [RSIP-PROTO], an RSIP client MAY free resources that it has determined it no longer requires. For example, on a large RSAP-IP subnet with a limited number of public IP addresses, locally-unique port numbers may become scarce. Thus, if RSIP clients are able to deallocate ports that they no longer need, RSIP will be more scalable. However, this functionality may require significant modifications to a vanilla TCP/IP stack in order to implement properly. The RSIP client must be able to determine which TCP or UDP sessions are using RSIP resources. If those resources are unused for a period of time, then the RSIP client may deallocate them. When an open socket's resources are deallocated, it will cause some associated applications to fail. An analogous case would be TCP and UDP sessions that must terminate when a PPP interface that they are using loses connectivity. On the other hand, this issue can be considered a resource allocation problem. It is not recommended that a large number (hundreds) of hosts share the same IP address, for performance purposes. Even if, say, 100 hosts each are allocated 100 ports, the total number of ports in use by RSIP would be still less than one-sixth the total port space for an IP address. If more hosts or more ports are needed, more IP addresses should be used. Thus, it is reasonable, that in many cases, RSIP clients will not have to deallocate ports for the lifetime of their activity. Similarly, it is non-trivial for an RSIP client to know when to allocate ports. It will have to detect activity on a socket, determine if the destination host is local or external, and then request the appropriate resources. In cases when the allocation requires multiple rounds, for example when more than one public resources are to be allocated and multiple assignment requests are issued or a request gets denied a number of times, delays may be introduced by the resource allocation process. 13. RSIP Deployment Although the goal of this draft is to consider the general issues related to RSIP, there are specific issues that will need to be addressed when RSIP is deployed in different scenarios. 13.1. Possible Deployment Scenarios In this section we discuss a number of potential RSIP deployment scenarios. The selection below are not comprehensive and other scenarios may emerge. Borella et. al. Expires April 2000 [Page 11] INTERNET DRAFT Realm Specific IP: Framework October 1999 13.1.1. Small / Medium Enterprise Up to several hundred hosts will reside behind an RSIP-enabled router. It is likely that there will be only one gateway to the public network and therefore only one RSIP server. This RSIP server may control only one, or perhaps several, public IP addresses. The RSIP server may also perform firewall functions, as well as routing inbound traffic to particular destination ports on to a small number of dedicated servers on the private network. 13.1.2. Large Enterprise From several hundred to hundreds of thousands of hosts reside behind multiple RSIP servers and gateways to the public network. Each RSIP server may control multiple IP addresses and perform firewall functions as well as routing traffic to particular destination ports on to a small number of dedicated servers on the private network. Each of these servers MUST register their service port number with all RSIP servers. Server redundancy, replication and failover mechanisms MUST be provided. 13.1.3. Residential Networks This category includes both networking within just one residence, as well as within multiple-dwelling units. At most several hundred hosts will share the server's resources. In particular, many of these devices may be thin clients or so- called "network appliances" and therefore not require access to the public Internet frequently. The RSIP server is likely to be implemented as part of a residential firewall, and it may be called upon to route traffic to particular destination ports on to a small number of dedicated servers on the private network. It is likely that only one gateway to the public network will be present and that this gateway's RSIP server will control only one IP address. Support for secure end-to-end VPN access to corporate intranets will be important. 13.1.4. Hospitality Networks A hospitality network is a general type of "hosting" network that a traveler will use for a short period of time (a few minutes or a few hours). Examples scenarios include hotels, conference centers and airports and train stations. At most several hundred hosts will share the server's resources. The RSIP server may be implemented as part of a firewall, and it will probably not be used to route traffic to particular Borella et. al. Expires April 2000 [Page 12] INTERNET DRAFT Realm Specific IP: Framework October 1999 destination ports on to dedicated servers on the private network. It is likely that only one gateway to the public network will be present and that this gateway's RSIP server will control only one IP address. Support for secure end-to- end VPN access to corporate intranets will be important. 13.1.5. Dialup Remote Access RSIP servers may be placed in dialup remote access concentrators in order to multiplex IP addresses across dialup users. At most several hundred hosts will share the server's resources. The RSIP server may or may not be implemented as part of a firewall, and it will probably not be used to route traffic to particular destination ports on to dedicated servers on the private network. Only one gateway to the public network will be present (the remote access concentrator itself) and that this gateway's RSIP server will control a small number of IP addresses. Support for secure end-to-end VPN access to corporate intranets will be important. The RSIP protocol will be just between the client host and the remote access server, and therefore use IPCP instead of UDP or TCP. 13.1.6. Wireless Remote Access Networks Wireless remote access will become very prevalent as more PDA and IP / cellular devices are deployed. In these scenarios, hosts may be changing physical location very rapidly - therefore Mobile IP will play a role. Hosts typically will register with an RSIP server for a short period of time. At most several hundred hosts will share the server's resources. The RSIP server may be implemented as part of a firewall, and it will probably not be used to route traffic to particular destination ports on to dedicated servers on the private network. It is likely that only one gateway to the public network will be present and that this gateway's RSIP server will control a small number of IP addresses. Support for secure end-to-end VPN access to corporate intranets will be important. 13.2. Multi-homed Private Realms In the case where a private realm has multiple connections to the public realm, one RSIP server will be necessary for each gateway. It is essential for these RSIP servers to exchange state information so that if the inbound packets get routed to different RSIP servers, they would possess the correct state information to tunnel the packets to the appropriate RSIP clients. Similarly, if one of the RSIP servers fails, the others would be able to take Borella et. al. Expires April 2000 [Page 13] INTERNET DRAFT Realm Specific IP: Framework October 1999 over. However, having multiple RSIP servers within a single private realm may give rise to the risk of state inconsistency. To minimize such risk, three architectures are worth considering. 13.2.1. Centralized Global Address Management and Assignment In this architecture, the global parameter management and assignment functions are logically separated from the parameter binding management and tunneling functions. For benefit of discussion in this section, an RSIP controller refers to an entity in charge of the global parameter management and assignment functions while an RSIP gateway refers to an entity carrying out the parameter binding management and tunneling functions. A multi-homed private realm would normally be configured with an RSIP controller and more than one RSIP gateway. If an RSIP client needs to connect to a public realm, it will obtain the global parameters from the RSIP controller. The RSIP controller may relay addressing information of the RSIP gateway which acts as the tunnel end-point together with the parameter assignment. In such a case, the RSIP controller would have to resume responsibility of tunnel management. Establishment of parameter binding information on the RSIP gateway could either be controller initiated, gateway initiated, or a mixture of both. In the first case, RSIP controller would relay the new global parameter assignment and binding information to all RSIP gateways within the private realm when new assignments are made. Similarly, when assignments are freed, such information are relayed to all RSIP gateways. In the second case, new binding information would only be relayed to the RSIP gateways once they encounter the tunneled packets from the RSIP clients and send queries to the RSIP controller. RSIP controllers maintain records on the existence of mapping information for a particular bind on the RSIP gateways. If the binding is later freed, all relevant RSIP gateways are informed. In the third case, the RSIP controller will relay the new binding information to the RSIP gateway which the RSIP client has been informed to tunnel outbound packets to. If the inbound packets for the session arrived at an RSIP gateway other than the one which a parameter mapping has been established, the RSIP controller could be queried to obtain the existing bindings. Regardless of which approach is being adopted, it is essential for all RSIP gateways to have knowledge of all the global parameters managed by the RSIP Borella et. al. Expires April 2000 [Page 14] INTERNET DRAFT Realm Specific IP: Framework October 1999 controller. 13.2.2. Splitting of Global Parameter Management Each RSIP server could be configured to manage and assign a subset of the global parameters for a private realm. An RSIP client could contact any of the RSIP server and be assigned global parameters. In the case when an RSIP server returns "no resources available" type error response, the RSIP client is free to contact another RSIP server. If a packet is routed to an RSIP server which does not possess the required mapping, it could either drop the packet or contact the relevant server for mapping information. If the latter option were to be adopted, there is a need for an RSIP server to be aware of the global parameter ranges that the other servers are responsible for. Issues of how the RSIP clients could be informed of the list of RSIP servers, and how RSIP servers learn of the global parameter ranges that the other servers are responsible for, are implementation dependent. 13.2.3. Master and Slave RSIP Server This is the case where the private realm possesses multiple RSIP servers capable of global parameter assignment. There is a need to maintain state consistency on all RSIP servers. In the case when there is a conflict, state mapping on the master server could be used to resolve the conflict. If the master server fails, the remaining servers could elect to have a new master. 14. Cascaded RSIP and NAT It is possible for RSIP to allow for cascading of RSIP servers as well as cascading of RSIP servers with NAT boxes. For example, consider an ISP that uses RSIP for address sharing amongst its customers. It might assign resources (e.g., IP addresses and ports) to a particular customer. This customer may further subdivide the port ranges and address(es) amongst individual end hosts Note that some of the architectures discussed below may not be useful or desirable. The goal of this section is to explore the interactions between NAT and RSIP as RSIP is incrementally deployed on systems that already support NAT. 14.1. RSIP Behind RSIP A reference architecture is depicted below. Borella et. al. Expires April 2000 [Page 15] INTERNET DRAFT Realm Specific IP: Framework October 1999 +-----------+ | | | RSIP | | server +---- 10.0.0.0/8 | B | | | +-----+-----+ | | 10.0.1.0/24 +-----------+ | (149.112.240.0/25) | | | 149.112.240.0/24| RSIP +--+ ----------------+ server | | A +--+ | | | +-----------+ | 10.0.2.0/24 | (149.112.240.128/25) | +-----+-----+ | | | RSIP | | server +---- 10.0.0.0/8 | C | | | +-----------+ RSIP-server A is in charge of the IP addresses of subnet 149.112.240.0/24. It distributes these addresses to RSIP-clients and RSIP-servers. In the given configuration, it distributes addresses 149.112.240.0 - 149.112.240.127 to RSIP-server B, and addresses 149.112.240.128 - 149.112.240.254 to RSIP-server C. Note that the subnet broadcast address, 149.112.240.255, must remain unclaimed, so that broadcast packets can be distributed to arbitrary hosts behind RSIP-server A. Also, the subnets between RSIP-server A and RSIP- servers B and C will use private addresses. Due to the tree-like fashion in which addresses will be cascaded, we will refer to RSIP-servers A as the 'parent' of RSIP-servers B and C, and RSIP-servers B and C as 'children' of RSIP-servers A. An arbitrary number of levels of children may exist under a parent RSIP- server. A parent RSIP-server will not necessarily be aware that the address(es) and port blocks that it distributes to a child RSIP- server will be further distributed. Thus, the RSIP-clients MUST tunnel their outgoing packets to the nearest RSIP-server. This server will then verify that the sending host has used the proper Borella et. al. Expires April 2000 [Page 16] INTERNET DRAFT Realm Specific IP: Framework October 1999 address and port block, and then tunnel the packet on to its parent RSIP-server. For example, in the context of the diagram above, host 10.0.0.1, behind RSIP-server C will use its assigned external IP address (say, 149.112.240.130) and tunnel its packets over the 10.0.0.0/8 subnet to RSIP-server C. RSIP-server C strips off the outer IP header. After verifying that the source public IP address and source port number is valid, RSIP-server C will tunnel the packets over the 10.0.2.0/8 subnet to RSIP-server A. RSIP-server A strips off the outer IP header. After verifying that the source public IP address and source port number is valid, RSIP-server A transmits the packet on the public network. While it may be more efficient in terms of computation to have a RSIP-client tunnel directly to the overall parent of an RSIP- server tree, this would introduce significant state and administrative difficulties. A RSIP-server that is a child MUST take into consideration the parameter assignment constraints that it inherits from its parent when it assigns parameters to its children. For example, if a child RSIP-server is given a lease time of 3600 seconds on an IP address, it MUST compare the current time to the lease time and the time that the lease was assigned to compute the maximum allowable lease time on the address if it is to assign the address to a RSIP-client or child RSIP-server. 14.2. NAT Behind RSIP +--------+ +--------+ | NAT w/ | | RSIP | clients ----+ RSIP +------+ server +----- public network | client | | | +--------+ +--------+ In this architecture, an RSIP server is between a NAT box and the public network. The NAT is also equipped with an RSIP client. The NAT dynamically requests resources from the RSIP server as the clients establish sessions to the public network. The clients are not aware of the RSIP manipulation. This configuration does not enable the clients to have end-to-end transparency and thus the NAT still requires ALGs and the architecture cannot support IPSEC. 14.3. RSIP Behind NAT Borella et. al. Expires April 2000 [Page 17] INTERNET DRAFT Realm Specific IP: Framework October 1999 +--------+ +--------+ RSIP | RSIP | | | clients ----+ server +------+ NAT +----- public network | | | | +--------+ +--------+ In this architecture, The RSIP clients and server reside behind a NAT. This configuration does not enable the clients to have end- to-end transparency and thus the NAT still requires ALGs and the architecture cannot support IPSEC. The clients may have transparency if there is another gateway to the public network besides the NAT box, and this gateway supports cascaded RSIP behind RSIP. 14.4. RSIP Through NAT +--------+ +--------+ RSIP | | | RSIP | clients ----+ NAT +------+ server +----- public network | | | | +--------+ +--------+ In this architecture, the RSIP clients are separated from the RSIP server by a NAT. RSIP signaling may be able to pass through the NAT if an RSIP ALG is installed. The RSIP data flow, however, will have its outer IP address translated by the NAT. The NAT must not translate the port numbers in order for RSIP to work properly. Therefore, only traditional NAT will make sense in this context. 15. Integration with Mobile IP RSIP can be used as a configuration tool for coarse-grained mobility (nomadicity). For example, a laptop or handheld device may use RSIP to temporarily register on a local network. However, once the host de-registers from this network, or otherwise terminates its associated with the network, all ongoing communication between the host and its peers must also terminate. It is desirable for RSIP to support fine-grained mobility; i.e., the ability to move between networks, and register and de-register with RSIP servers, without tearing down any communications sessions. Pragmatically speaking, this means that socket parameters, such as the host's IP address and port number(s) must remain the same as it roams. Mobile IP [RFC2002] provides the necessary mechanisms for a mobile host to maintain its sessions and socket parameters while it moves between its home network and foreign networks. The goal of this Borella et. al. Expires April 2000 [Page 18] INTERNET DRAFT Realm Specific IP: Framework October 1999 draft is to discuss the architecture, requirements, and feasibility of integrating RSIP and Mobile IP. In doing so we expect that the impact on both protocols will be minimal. In particular, the modifications that we suggest below require minor messaging changes to both RSIP and Mobile IP. 15.1. Mobility Architecture The general architecture that we will consider is illustrated below: This architecture is similar to that discussed in Section 4, but has been annotated specifically for mobility. RMNa RHAa RHAp RFAp RFAb RMNb RMN]------------[RHA]--------------------[RFA]-------------[RMN] (RSIP home (public network "p") (RSIP foreign network "a") network "b") In this diagram, an RMN roams between an RHN "a" and an RFN "b". On RHN "a" the RMN uses private address RMNa, and on RFN "b" the RMN uses private address RMNb. The RHA on the RHN uses private address RHAa and public address RHAp. The RFA on the RFN uses private address RFAb and public address RFAp. Note that the RFN may also act as an RHN for its RMNs, and the RHN may also act as an RFN for roaming RMNs. In order so that the RMN can communicate with peers on the public network, the RHA assigns the RMN address RMNp (not shown). RMNp may be identical to RHAp. Note that until standard Mobile IP, the address RMNa is not guaranteed to be unique. This address is likely to be from the private space, so when the RMN is on RFN "b", RMNa may collide with other RMNs in the RFN, or with stationary nodes on the network. Thus, it is necessary that the RMN be allocated RMNb when it is on RMN "b". The recommended mechanism to do this with is DHCP. We assume that the RHA and RFA will always be on the boundary between public and private address spaces. Thus RMNs can always be uniquely identified by the tuple (RMNa, RMNp), although other identification mechanisms may also be used. 15.2. Data Flow This section presents the flow of data between the participants in RSIP / Mobile IP transaction. We ignore both RSIP and Mobile IP control flow and signaling for now - it is discussed in the next section. Borella et. al. Expires April 2000 [Page 19] INTERNET DRAFT Realm Specific IP: Framework October 1999 15.2.1. Non-Roaming RMN When the RMN is not roaming; i.e., it is on the RHN, it operates just as if it were a stationary node. All data flows according to [RSIP-PROTO]. 15.2.2. Roaming RMN When the RMN is roaming, the typical routing scheme of Mobile IP is used. In particular, if the RMN is communicating with a public node (PN) which has address PNp, the RMN will be known to the PN as RMNp. On the RFN, the RMN will have a local IP address of RMNb. In the case of RSAP-IP, the RMN will also be using ports allocated by the RHA. Packets sent from the RN to the RMN will be addressed identically to standard Mobile IP operation: ne 4 +-------------+---------+ | PNp -> RMNp | payload | +-------------+---------+ Since the RHA will be advertising a route to RMNp, this packet will be received by the RHA. The RHA will determine that the RMN is not on the RHN, and forward the packet to the RMN's care-of address, RFAp, via an IP-IP tunnel. +--------------+-------------+---------+ | RHAp -> RFAp | PNp -> RMNp | payload | +--------------+-------------+---------+ Once the packet arrives at the RFA, it terminates the IP-IP tunnel from the RHA and initiates a new IP-IP tunnel to the RMN, as shown below. +--------------+-------------+---------+ | RFAb -> RMNb | PNp -> RMNp | payload | +--------------+-------------+---------+ Packets from the RMN are transmitted via the same tunnel back to the RFA, and then on to the PN. +--------------+-------------+---------+ | RMNb -> RFAb | RMNp -> PNp | payload | +--------------+-------------+---------+ 15.3. Control Flow Borella et. al. Expires April 2000 [Page 20] INTERNET DRAFT Realm Specific IP: Framework October 1999 In this section, we illustrate the control flow (signaling) requirements for RSIP / Mobile IP. The RMN is always listening for the ICMP Mobile IP Agent Advertisement messages. Upon receipt of such a message the RMN determines whether or not it is on the RHN. The RMN may also transmit Agent Solicitation messages, as per Mobile IP. When the RMN determines that it has moved from a RHN to a RFN, or from a RFN to another RFN, it requests a local address (e.g., RMNb from above) then performs the Mobile IP registration process. This process includes informing the RHA of the RMN's new care-of address. Note that the RMN must identify itself uniquely to the RHA. Since RMNp may be in use by more than one RMN at a time, the RMN must use either RMNa or a combination of RMNp and a port number or range of port numbers (in the case of RSAP-IP) that it has been allocated by the RHA. All RSIP messages that would normally flow between the RMN and the RHA must be forwarded by the RFA. The RMN may request more resources from or return resources to the RHA. The RMN must also be prepared to accept DEALLOCATE messages from the RHA which would force it to discontinue use of certain resources. Note that if the RMN de-registers from the RHA, it may lose connectivity entirely. All RSIP control messages must be tunneled between the RMN and the RFA, as well as between the RFA and the RHA. The form of these tunnels is illustrated below. From RMN to RFA: +--------------+--------------+---------+ | RMNb -> RFAb | RMNa -> RHAa | payload | +--------------+--------------+---------+ From RFA to RHA: +--------------+--------------+---------+ | RFAp -> RHAp | RMNa -> RHAa | payload | +--------------+--------------+---------+ From RHA to RFA: +--------------+--------------+---------+ | RHAp -> RFAp | RHAa -> RMNa | payload | +--------------+--------------+---------+ Borella et. al. Expires April 2000 [Page 21] INTERNET DRAFT Realm Specific IP: Framework October 1999 From RFA to RMN: +--------------+--------------+---------+ | RFAb -> RMNb | RHAa -> RMNa | payload | +--------------+--------------+---------+ Since the RMN has a presence, in the form of an address (RMNb) on the RFN, it must reply to all ARP messages for RMNb. However, it MUST NOT respond to ARPs for RMNa or RMNp. The RMN may communicate with other nodes on the RFN by using RMNb, and is thus not constrained to use port numbers allocated by the RHA (in the case of RSAP-IP) when communicating locally. The RHA must perform all RSIP server functions as defined in [RSIP-PROTO]. The RHA must also perform all home agent Mobile IP functions as defined in [RFC2002]. The RFA must perform all foreign agent Mobile IP functions as defined in [RFC2002]. It must also maintain an IP-IP tunnel to all RMNs so that they can pass control and data flow packets. 16. To Do - Interaction with multicast - Interaction with QoS - Session authentication - Mobile IP section is very preliminary. Needs work on terminology and requirements. 17. Changelog 01 to 02: - Added section on Mobile IP integration - Added to section on cascaded RSIP - Added section on client and server requirements - Added RSIP for multi-homed network - Added deployment scenarios - Added section on RSAP-IP support for servers - Added section on MTU limitations - Elaborated on discussion in the Architecture section - Elaborated on discussion under demultiplexing fields - Elaborated on discussion on Negotiation Protocol - Clarified section on tunneling between the client and server - Editorial changes 00 to 01: - Synched up terminology with the latest NAT terminology draft. - Changed all instances of "global" to "public" Borella et. al. Expires April 2000 [Page 22] INTERNET DRAFT Realm Specific IP: Framework October 1999 - Modified section on "Architecture" - Added discussion of demultiplexing parameters tree to the "Negotiation and assignment of demultiplexing fields" section - Added discussion of subnet list query in "Determining Locality of Destination" section - Added "RSIP Client Deallocation" discussion section - Added more explanation in "Tunnel Use and Establishment" section 18. 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. All Mobile IP and RSIP control messages SHOULD be authenticated to prevent denial of service, spoofing and hijacking attacks. 19. Acknowledgements The authors would like to thank Pyda Srisuresh, Dan Nessett, Gary Jaszewski, Aja Bakre, and Rick Cobb for their input. 20. References [RSIP-IPSEC] G. Montenegro and M. Borella, "RSIP Support for End-to- end IPSEC," , work in progress, May 1999. [RSIP-PROTO] M. Borella, D. Grabelsky, J. Lo and K. Taniguchi, "Realm Specific IP: Protocol Specification," , work in progress, Aug. 1999. [RFC1918] Y. Rekhter, B. Moskowitz, D. Karrenberg, G. J. de Groot, and E. Lear, "Address Allocation for Private Internets," RFC 1918, Feb. 1996. [RFC2002] C. Perkins, "IP Mobility Support," RFC 2002, Oct. 1996. [RFC2119] S. Bradner, "Key words for use in RFCs to indicate requirement levels," RFC 2119, Mar. 1997. [RFC2663] P. Srisuresh and Matt Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations," RFC 2663, Aug. 1999. 21. Authors' Addresses Borella et. al. Expires April 2000 [Page 23] INTERNET DRAFT Realm Specific IP: Framework October 1999 Michael Borella 3Com Corp. 1800 W. Central Rd. Mount Prospect IL 60056 (847) 342-6093 mike_borella@3com.com Jeffrey Lo NEC USA C&C Research Labs. 110 Rio Robles San Jose, CA 95134 (408) 943-3033 jlo@ccrl.sj.nec.com David Grabelsky 3Com Corp. 1800 W. Central Rd. Mount Prospect IL 60056 (847) 222-2483 david_grabelsky@3com.com Gabriel E. Montenegro Sun Microsystems, Inc. 15 Network Circle Menlo Park CA 94025 650 786 6288 gab@sun.com 22. Copyright Statement Copyright (c) The Internet Society (1999). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. Borella et. al. Expires April 2000 [Page 24] INTERNET DRAFT Realm Specific IP: Framework October 1999 This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Borella et. al. Expires April 2000 [Page 25]