Mobile IP Working Group Charles E. Perkins INTERNET DRAFT G. Montenegro 25 June 1999 Pat R. Calhoun Sun Laboratories Private Addresses in Mobile IP draft-ietf-mobileip-privaddr-00.txt Status of This Memo This document is a submission by the mobile-ip Working Group of the Internet Engineering Task Force (IETF). Comments should be submitted to the MOBILE-IP@STANDARDS.NORTELNETWORKS.COM mailing list. Distribution of this memo is unlimited. 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 The use of possibly non-unique private addresses (i.e., addresses that are not globally routable in the internet) for mobile nodes, foreign agents, or home agents is not handled by RFC 2002. This document specifies changes to enable Mobile IP to handle such addresses. Perkins, Montenegro, Calhoun Expires 25 December 1999 [Page i] Internet Draft Private Addresses for Mobile IP 25 June 1999 1. Introduction Full-scale deployment of Mobile IP would benefit from an ability to provide mobility across differing address spaces, sometimes called "realms", especially because corporate networks often use private address spaces. A solution is needed to handle such addresses consistently with regionalized registrations and firewall traversal. The mechanisms proposed in this note aim to solve this problem. We use use the following model: +---------------------------+ +----------------+ | Foreign Private Network | | Home Private | | | +---------+ | Network | | | | | | | | +------+ +-------+ | | Public | | +------+ | | | FA |------| GFA |-------------------------| SHA | | | +--+---+ +-------+ | | Network | | +--+---+ | | | | | | | | | +-----|---------------------+ +---------+ | +--+---+ | | | | HA | | +--+---+ | +------+ | | MN | | | +------+ +----------------+ Figure 1: Mobility with Private Networks A Home Agent using a private address cannot be the destination of any packets transmitted by a foreign agent in a different addressing domain. Thus, such a home agent has to rely on the presence of a Surrogate Home Agent (a SHA). Furthermore, every mobile node on the Home Network served by such a home agent will also have a private address. This means that Registration Requests for the mobile node have to be sent to the SHA. Then, the SHA has to know how to forward such requests to the home agent. In this document, the GHAA (Global Home Agent Address) is defined to be either the HA, if the HA has a globally routable IP address, or else the SHA, if the HA does not have a globally routable IP address. Mobile IP has two distinct phases: 1. tunnel setup via a UDP-based (registration) protocol, and Perkins, Montenegro, Calhoun Expires 25 December 1999 [Page 1] Internet Draft Private Addresses for Mobile IP 25 June 1999 2. data transfer via tunneled packets. 2. Data Transfer Let's examine first the data transfer phase. Given that only systems within the same address space have direct reachability, the packets do not travel along an end-to-end tunnel. Instead, the tunnel from HA to FA is a compound tunnel, used as in a previous proposal, Tunnel Establishment Protocol (TEP) [2]. The segments of the tunnel are always within any given address space. If the home agent has a private address, there are 3 tunnel segments: HA->SHA, SHA->GFA, and GFA->FA Otherwise, if the home agent has a globally routable IP address, only two tunnel segments are necessary: HA->GFA and GFA->FA It is also possible that additional tunnel segments will be needed between the GFA and the FA, but setting up such additional tunnel segments is outside the scope of this document. The order and endpoints of the compounds tunnels are reversed when packets flow in the reverse direction. Data transfer, then, proceeds from the correspondent node to the home agent through the SHA along to the FA in the manner to be described next. In this section, MN refers to a particular mobile node which needs to receive data at a particular care-of address, which may itself be a private address from a separate address space than the one from which MN's IP address is allocated. In sections 2.3 through 2.5, the IP node sending the packet the GFA is designated as the GHAA, as defined in section 1. 2.1. From HA to SHA Say a correspondent node CN (not shown in figure 1) sends a packet to MN. If the home agent (HA) has a private address, then it MUST know the address of a SHA, and MUST cause the tunneled data packet to the MN's care-of address to seem to originate from the SHA. The HA first encapsulates the packet with an IP header that indicates that origination. Then, the HA encapsulates it and sends it towards SHA as illustrated in figure 2. Perkins, Montenegro, Calhoun Expires 25 December 1999 [Page 2] Internet Draft Private Addresses for Mobile IP 25 June 1999 +-------------------------------+ | +--------------------+| | | +--------+|| | HA->SHA | SHA->GFA | CN->MN ||| | | +--------+|| | +--------------------+| +-------------------------------+ Figure 2: IP-in-IP tunneled packet from HA to SHA 2.2. From SHA to GFA +--------------------+ | +--------+| | SHA->GFA | CN->MN || | +--------+| +--------------------+ Figure 3: IP-in-IP tunneled packet from SHA to GFA Once the packet reaches SHA, the packet is decapsulated, exposing the still encapsulated packet with SHA as the source IP address. The packet from SHA to GFA is illustrated in figure 3. 2.3. From GFA to FA When GFA decapsulates the packet, it looks for a binding for MN, the inner destination. Following the discussion in [6], MN's IP address does not necessarily uniquely identify the mobile node. The reason is that the GFA may have another binding in place for a mobile node from another private address space that is using the same IP address as MN. The GFA has to identify the correct visitor list entry based on a tuple (i.e., an ordered set of information) which is guaranteed to be unique. One such tuple sufficient for demultiplexing IP-within-IP packets [7] (protocol 4) is (MN,GHAA), where: - MN is the destination IP address of the innermost header, and - GHAA is the source IP address of the encapsulating header. Perkins, Montenegro, Calhoun Expires 25 December 1999 [Page 3] Internet Draft Private Addresses for Mobile IP 25 June 1999 The destination IP address of the innermost header is the mobile node's home address. The source IP address of the encapsulating header is GHAA. The ordered pair (MN,GHAA) is presumed unique among all of GFA's Mobile IP clients. GFA requires (MN,GHAA) to fetch the next tunnel endpoint, FA. This tuple continues to be required for any foreign agent beyond GFA, as such agents MAY reside in a separate address space from MN's home address. Accordingly, GFA encapsulates again so that GHAA will still be visible in the intermediate header. The packet that arrives at FA is illustrated in figure 4. +--------------------------------+ | +---------------------+| | | +--------+|| | GFA->FA | GHAA->GFA | CN->MN ||| | | +--------+|| | +---------------------+| +--------------------------------+ Figure 4: IP-in-IP tunneled packet from GFA to FA 2.4. From FA to MN Before delivering the packet to the mobile node, the FA MUST check that the outer source IP address (GFA) matches the intermediate destination IP address. The FA MAY require that the same GFA always be associated with the MN, by storing this information in its routing table. Note that a routing loop would result from indiscriminately forwarding the decapsulated packet after the outer (GFA->FA) header was removed, because the GFA would keep doing the same thing to the packet. RFC 2002 includes language to prohibit this indiscriminate forwarding, and the mobility agents handling private addresses require at least as much care as RFC 2002 mobility agents when dealing with encapsulation. Like the GFA, the FA searches based on (MN,GHAA). Once the FA identifies the ultimate destination of the packet, MN, it delivers the packet using link-level mechanisms. Perkins, Montenegro, Calhoun Expires 25 December 1999 [Page 4] Internet Draft Private Addresses for Mobile IP 25 June 1999 2.5. Using GRE tunnels GRE packets with a Routing field are outside the scope of this document. GRE packets [4, 5] (protocol 47) without a Key field are only handled if their Protocol Type field has a value of 0x800 (other values are outside the scope of this document), and can be demultiplexed based on the same tuple (MN,GHAA) as IP-within-IP packets. GRE packets with a Key field could be demultiplexed based on that field used as a tunnel identifier [2] negotiated at registration time. Question: how is the tunnel identifier negotiated? In this case, by absorbing the cost of negotiating the tunnel identifier and setting up the necessary routing for the GRE header, extra encapsulation steps can be avoided by providing a single GRE header, as illustrated in figure 5. +---------------------+ | +--------+| | GHAA->GFA | CN->MN || | tunnelID +--------+| +---------------------+ Figure 5: GRE tunneled packet from GFA to FA 3. Tunnel Establishment Even if the HA cannot address FA directly, the HA has to send tunneled packets so that they eventually arrive at the FA so that the FA can deliver them to the mobile node. These packets are delivered via GHAA and GFA. Configuring this tunnel is initiated by the Mobile IP Registration Request message, as defined in [8]. If mobile node MN is registering with home agent HA, the GFA should be used as the care-of address, because the GHAA sends packets to MN via GFA. The mobility agents FA and GFA create the mapping (MN,GHAA) for each mobile node. This information is available from the registration messages. If the mobile node has acquired a co-located address, any foreign agent issuing agent advertisements MUST use the 'R' bit to force the mobile node's Registration Request to go through it. If a mobile node using a co-located address is not receiving any advertisements, then one of two things must be true: Perkins, Montenegro, Calhoun Expires 25 December 1999 [Page 5] Internet Draft Private Addresses for Mobile IP 25 June 1999 - the co-located care-of address is globally routable, or - the mobile node discovers the GFA; the protocol for this discovery operation is not specified within this document. 3.1. Privately Addressed Mobile Nodes Foreign agents that comply with Mobile IP as specified in RFC 2002 are not required to handle mobile nodes with private IP addresses. Doing so requires additional mechanism, because it is possible for two mobile nodes to show up with the same identical private IP address. Fortunately, at least delivery from the foreign agent's network interface to the mobile node will still be possible, based on the MAC address of the mobile node. However, once the Foreign Agent has decapsulated the packets it receives for the mobile node(s) with a duplicated private IP address, it cannot determine which mobile node should receive the packet based only the value of the destination IP address (MN) in the inner IP header, In order to handle private addresses, a Foreign Agent MUST be able to identify its visitor list entry for the mobile node by using (MN,GHAA) as defined in section 2.3. Pending Registration Requests using private addresses MUST be able to be identified by using the the Identification field along with either: - the NAI [1] supplied by the mobile node, or - (MN,GHAA) A new `P' bit is defined, from the currently reserved field of the Agent Advertisement defined in RFC 2002 [8], for use by Foreign Agents that have the mechanisms specified herein. If the mobile node has a private address, then it SHOULD send registration requests only to a foreign agent that has advertised the ability to handle private addresses by setting the `P' bit. If the mobile node has a private address, then it SHOULD include the NAI extension [3] in its Registration Request. When a Registration Reply is determined to match a request from a Mobile Node (MN) with a private address, the foreign agent MUST associate GHAA with its (new) visitor list entry for MN. DISCUSSION: cep: I am not surewe should tie together the NAI with the use of private addresses in this way. And, I think that the Perkins, Montenegro, Calhoun Expires 25 December 1999 [Page 6] Internet Draft Private Addresses for Mobile IP 25 June 1999 FA has to advertise its willingness to handle such nasty, unfriendly things such as private addresses. cep: We could make the home agent append a Private Address extension to the Registration Reply, in the range 128-255. That would avoid making the mobile nodes have to be smart, and it would avoid requiring the foreign agents make the more difficult routing determination for mobile nodes with unique IP addresses. 3.2. Privately Addressed Home Agents Suppose the home agent has a private address. Then, the home agent MUST perform the encapsulation steps specified in section 2.1. The mobile node MUST be able to discover the address of its SHA. This discovery MAY occur in one of the following ways: 1. The home agent can advertise an SHA's address in advertisements received by the mobile node when the mobile node is at home. This document does not specify any method by which a home agent can advertise a SHA. 2. The SHA can be returned in the Home Agent field of the Registration Reply, when the mobile node asks for dynamic allocation of a Home Agent. 3. The mobile node can be statically configured to contain the address of a SHA, at the same time that it is configured with a security association with a home agent or with a home AAA server. 3.3. Foreign Agents with Private Addresses A foreign agent with a private address SHOULD NOT advertise its care-of address within its agent advertisements (beacons), because the beacons are assumed to offer connectivity for mobile nodes that may belong in a different addressing domain. Instead, it SHOULD advertise a care-of address that is reachable by the GHAA. This globally reachable care-of address is associated with a distinguished foreign agent known as the Gateway Foreign Agent (GFA). DISCUSSION: The FA could use one of three methods to indicate to the mobile node the necessary information about the foreign domain/GFA: - can advertise FA@domain - can advertise GFA Perkins, Montenegro, Calhoun Expires 25 December 1999 [Page 7] Internet Draft Private Addresses for Mobile IP 25 June 1999 - can reject registration and send GFA If the foreign agent advertises a care-of address which is not associated with one of its own network interfaces, the mobile node must be given some other method to detect when it moves to a different foreign agent. A foreign agent advertising a GFA as its care-of address SHOULD use the FA-NAI extension, specified in section 4. In order to advertise the GFA as a care-of address, the foreign agent has to find find out what it is. This MAY be done by any of the following methods: 1. The GFA can list its care-of address in advertisements received by the foreign agent. 2. The GFA can be returned in the Care-of Address field of the Registration Reply. This requires that the care-of address be made known to the home agent, in order for the Registration Reply to be properly authenticated. 3. The foreign agent can be statically configured to contain the care-of address of a GFA. [gab - does an MN need to know the GFA?. maybe not. just issue the request with care-of address 0 and have the FA figure it out via AAA or whatever, precisely as outlined in the next section.] This document does not (yet) specify any method by which the home agent may obtain the GFA's globally routable care-of address. 3.4. Alternative GFAs If a foreign agent has access to multiple GFAs, the appropriate GFA for a particular mobile node MAY may be selected depending upon the NAI given by the mobile node, or the home agent address given by the mobile node. In this case, the foreign agent MAY advertise a care-of address of zero, and include the FA-NAI extension specified in section 4. When the mobile node first attempts to make a connection in a particular foreign domain, it is typically unaware of any nearby care-of address. When the foreign agent advertises a zero care-of address, the care-of address that the mobile node uses during its initial registration MUST be zero. Before the Registration Request reaches the home domain, the care-of address (say, of a GFA), MUST be inserted by an agent (call it AAAX) trusted and authenticated by the home domain, or an associate in the foreign domain trusted and Perkins, Montenegro, Calhoun Expires 25 December 1999 [Page 8] Internet Draft Private Addresses for Mobile IP 25 June 1999 verified by AAAX. The home agent, then, includes that care-of address in the Registration Reply, for subsequent use by the mobile node. DISCUSSION: This should perhaps go into a separate document. It could depend on AAA. We need to define error numbers for the following cases: - nonzero COA at private FA - zero COA at GHAA 3.5. Protocol between SHA and HA In this section we assume that the home agent has a private address, and thus that every packet tunneled to the mobile node has the IP address of the SHA as the source IP address in the tunnel header. If a SHA receives a Registration Request, and it is not the home agent for the initiating mobile node, the SHA has to have an entry for the mobile node and a record of the associated home agent in its home list. This record can be created in the following ways: 1. Manual configuration 2. The SHA can receive a Registration Request from a AAA agent in the home domain (call it AAAH) during the initial registration sequence for the mobile node in the foreign domain. In this case, the AAAH will send the address of the appropriate home agent along with the Registration Request. When the home agent receives a data packet for delivery to the mobile node, the home agent MUST first deliver this packet to the SHA. It does this by iterated encapsulation: 1. Encapsulate using the care-of address as the tunnel destination and the SHA as the tunnel source address, and then 2. Encapsulate using the SHA as the tunnel destination and the home agent's private address as the tunnel source address When the SHA receives this tunneled packet, it only has to remove the outermost IP header from the packet and forward the (still at least singly encapsulated) result to the care-of address. Perkins, Montenegro, Calhoun Expires 25 December 1999 [Page 9] Internet Draft Private Addresses for Mobile IP 25 June 1999 4. Foreign Agent NAI The Foreign Agent NAI Extension to the Agent Advertisement contains the foreign agent's host name following the format defined in [1]. The NAI is used to identify the foreign agent and can be used by a mobile node to determine whether or not it has moved out of the domain in which its previous foreign agent was configured to provide mobility service. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | FA NAI ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6: The FA NAI Extension Type TDB Length The length in bytes of the FA NAI field FA NAI Contains the foreign agent's NAI in the format defined in [1]. 5. Security Considerations Since private addresses are typically administered to prevent access to networks inside an enterprise, privately addressed mobile nodes with Mobile IP must be handled with great care to avoid break-ins. For instance, the mobile node should probably not offer any IP forwarding services while registered at an external care-of address. It is difficult to imagine how forwarding traffic between the foreign and home domain could be logically consistent with the raison d'etre for the private address space in the home domain. The SHA and GFA offer access mechanisms into a private address space. Packets sent to the SHA or GFA for further handling may, therefore, require authentication and possibly encryption to maintain the existing security policy which originally dictated the choice of using a private address space within the enterprise. Perkins, Montenegro, Calhoun Expires 25 December 1999 [Page 10] Internet Draft Private Addresses for Mobile IP 25 June 1999 6. IPv6 Considerations It is hoped that IPv6 will not offer any such private addresses as have been brought about by perceived unavailabilty of enough IPv4 addresses. References [1] B. Aboba and M. Beadles. RFC 2486: The network access identifier, January 1999. Status: PROPOSED STANDARD. [2] P. Calhoun and C. Perkins. Tunnel Establishment Protocol (TEP). draft-ietf-mobileip-calhoun-tep-00.txt, December 1997. (work in progress). [3] Pat R. Calhoun and Charles E. Perkins. Mobile IP Network Address Identifier Extension. draft-ietf-mobileip-mn-nai-01.txt, February 1999. (work in progress). [4] Stan Hanks, Tony Li, Dino Farinacci, and Paul Traina. Generic Routing Encapsulation (GRE). RFC 1701, October 1994. [5] Stan Hanks, Tony Li, Dino Farinacci, and Paul Traina. Generic Routing Encapsulation over IPv4 networks. RFC 1702, October 1994. [6] G. Montenegro. Negotiated Address Reuse (NAR). draft-montenegro-aatn-nar-00.txt, May 1998. (work in progress). [7] Charles Perkins. IP Encapsulation within IP. RFC 2003, May 1996. [8] C. Perkins, Editor. IP Mobility Support. RFC 2002, October 1996. Perkins, Montenegro, Calhoun Expires 25 December 1999 [Page 11] Internet Draft Private Addresses for Mobile IP 25 June 1999 Addresses The working group can be contacted via the current chairs: Erik Nordmark Basavaraj Patil Sun Microsystems, Inc. Nortel Networks Inc. 17 Network Circle 2201 Lakeside Blvd. Menlo Park, California 94025 Richardson, TX. 75082-4399 USA USA Phone: +1 650 786-5166 +1 972-684-1489 Fax: +1 650 786-5896 E-mail: nordmark@sun.com bpatil@nortelnetworks.com Questions about this memo can be directed to: Charles E. Perkins Pat R. Calhoun Sun Microsystems Laboratories Sun Microsystems Laboratories 15 Network Circle 15 Network Circle Menlo Park, California 94025 Menlo Park, California 94025 USA USA Phone: +1-650 786-6464 Phone: +1 650-786-7733 EMail: cperkins@eng.sun.com EMail: pcalhoun@eng.sun.com Fax: +1 650 786-6445 Gabriel Montenegro Sun Microsystems Laboratories 15 Network Circle Menlo Park, California 94025 USA Phone: +1-650-786-6288 EMail: gab@eng.sun.com Perkins, Montenegro, Calhoun Expires 25 December 1999 [Page 12]