SeaMoby Working Group Dirk Trossen Govind Krishnamurthi Hemant Chaskar Nokia Research Center Eunsoo Shim Richard D. Gitlin Columbia University Internet Draft Document: draft-trossen-seamoby-cardiscovery- November, 2001 00.txt Protocol for Candidate Access Router Discovery for Seamless IP-level Handovers Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. 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. This document is an individual submission for the Seamoby Working Group of the Internet Engineering Task Force (IETF). Comments should be submitted to the seamoby@diameter.org mailing list. Distribution of this memo is unlimited. Abstract A critical requirement in the protocols being designed for seamless IP-level handovers, such as fast handover and context transfer, is that the target access router (TAR) for the mobile node's (MN) handover is known to the current access router (AR). The TAR needs to have the capability set necessary to meet the MN's requirements, and meet any local policy requirements. While the TAR selection process happens at the time of handover, the ARs which have the capabilities to meet the MN's requirements can be identified in advance. These ARs are called candidate access routers (CARs). In this draft, we Shim/Gitlin Expires September 2001 1 Internet Draft Anticipated CAR Discovery Protocol October 1,2001 propose a distributed protocol to identify CARs at a time prior to the handover. Our protocol qualifies to be what is called the CAR discovery protocol. Table of Contents 1. Introduction àààààààààààààààààààààààààààààààààààààààààààààà.2 1.1. Conventions Used In This Document ààààààààààààààààààààààààà.3 1.2. Terminology ààààààààààààààààààààààààààààààààààààààààààààààà 3 2. Hybrid CAD Discovery Protocol Overview àààààààààààààààààà..4 2.1. Identifying GAARs ààààààààààààààààààààààààààààààààààààààààà.4 2.1.1. The Physical Neighborhood List (PNL)ààààààààààààààààààààààà 5 2.2. Capability Exchange Between GAARs ààààààààààààààààààààààààà 7 2.2.1. Examples of Capabilities àààààààààààààààààààààààààààààààààà 7 2.3. Candidate Access Router (CAR) Identification àààààààààààààà 8 2.4. Target Access Router (TAR) Selection àààààààààààààààààààààà 8 3. New Messages Used By The Hybrid CAR Discovery Protocol àààà 8 3.1. Router Identity Message ààààààààààààààààààààààààààààààààààà 8 3.2. Capability Exchange Message ààààààààààààààààààààààààààààààà 9 4. Mobile Node (MN) Operation àààààààààààààààààààààààààààààààà 10 5. Access Router (AR) Operation àààààààààààààààààààààààààààààà 10 6. Security Considerations ààààààààààààààààààààààààààààààààààà 11 7. Intellectual Property Rights Notice ààààààààààààààààààààààà 11 8. References ààààààààààààààààààààààààààààààààààààààààààààààà. 12 9. Author's Addresses àààààààààààààààààààààààààààààààààààààààà 12 Appendices àààààààààààààààààààààààààààààààààààààààààààààààààààààà. 13 A. Dealing With Private Address Space àààààààààààààààààààààààààà 13 B. Enhancement To The CAR Discovery Protocol ààààààààààààààààààààà 15 1. INTRODUCTION There are existing solutions [1, 2] that enable mobile nodes (MNs) to execute IP-level handovers between the points of attachment (called access routers or ARs) to IP network. Additionally, work is underway [3, 4, 5, 6, 7], to define protocols that would allow seamless, i.e., low latency and low packet loss, handovers of MNs between ARs. These seamless handover solutions assume that the identity of the target AR (TAR) for the MN's handover is known to the current AR. It is required to develop a protocol that would allow an AR to identify the TAR for MN's handover. As described in [8], there are two important components in the problem of TAR selection. They are as follows: 1) Identifying the neighboring ARs sufficiently in advance of the handover, which have the capability set required to meet the MN's requirements. They are called as the candidate access routers (CARs) and the corresponding protocol is called the "CAR discovery protocol". Trossen, et. al Expires May, 2002 2 Internet Draft Anticipated CAR Discovery Protocol October 1,2001 2) Choosing the TAR at the time of handover from the set of CARs, with the help of additional information such as the AR reachability information provided by the MN, local policy, MN's preferences etc. Three approaches, namely, anticipated, dynamic and hybrid, have been outlined in [8] for CAR discovery. In the "anticipated" approach, the current AR identifies the CARs for handover prior to the handover process. At the time of handover, the TAR is identified by the current AR from the set of CARs. If CAR selection is "dynamic", the MN is actively involved in the CAR discovery process. The MN identifies the neighboring ARs as well as their capabilities and selects the TAR. This information is then forwarded to the current AR. A "hybrid" approach lies in between these two. In this draft, we present a hybrid protocol for CAR discovery. In our protocol, MNs identify geographically adjacent ARs (GAARs), while capability exchange between GAARs happens over the Internet. A MN listens to beacons from neighboring access points and forwards the information in the beacon to the AR it is currently attached to. The TAR selection protocol will take as input the CARs along with other parameters described earlier in this section to uniquely identify the TAR. The description of a TAR selection protocol, however, is out of scope for this document. 1.1. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [2]. 1.2. Terminology Access Point (AP) : A layer 2 device to which the MN connects to through a wireless link. An AP may connect to one or more ARs. An AR may be connected to connected to APs belonging to different technologies. Access Router (AR) : An IP router residing in an access network and connected to one or more APs. An AR offers IP connectivity to MN. When dealing with IPv4 based networks running Mobile IPv4, Foreign Agents (FAs) take the place of ARs. Geographically Adjacent AR (GAAR) : An AR whose coverage area is such that an MN may move from the coverage area of the AR currently serving the MN into the coverage area of this AR. Trossen, et. al Expires May, 2002 3 Internet Draft Anticipated CAR Discovery Protocol October 1,2001 Physical Neighborhood List (PNL) : The set of GAARs along with their capabilities maintained at an AR. Candidate AR (CAR) : This is an AR that is a candidate for MN's handover. Candidate AR is "physically adjacent" to the AR currently serving the MN, and has the capability set required to serve the MN. Target AR (TAR) : This is an AR with which the procedures for MN's handover are initiated. Border Router (BR) : Globally IP addressable router through which a privately addressable network connects to the Internet. IP-level Identity of an AR : This is the IP address of an AR if the address is globally routable. However, if an AR resides in a private IP address space, this is a tuple (border routerÆs globally routable IP address, AR identifier recognized by the BR). 2. HYBRID CAR DISCOVERY PROTOCOL OVERVIEW The task of identifying CARs has the following components. 2.1. Identifying GAARs A basic requirement for a new AR to be considered as a CAR for an MN is that the coverage area of the new AR be "geographically adjacent" to that of the AR currently serving the MN. Note that, the geographical adjacency of two ARs is not necessarily implied by their "logical" adjacency. Logical adjacency of two ARs implies one IP hop between them. Conversely, geographical adjacency does not imply logical adjacency. One approach is to manually configure this physical neighborhood at each AR. However, as described in [8] such an approach has disadvantages and in many cases, may not be feasible. For instance, two ARs that are geographically adjacent may be under different administrative control, and thus, are not informed about each other's presence. Even within the same administrative domain, the manual configuration approach demands much network planning in terms of the coverage areas of different ARs. Further, if the routers are relocated, then such a process is not suitable. We therefore propose a dynamic learning mechanism to identify GAARs for each AR. It is described with reference to Figure 1. Trossen, et. al Expires May, 2002 4 Internet Draft Anticipated CAR Discovery Protocol October 1,2001 MN +-----------+ +-+ | Current | < | | ---------- | AR | ------ > ----\ +-+ | | < \ | ID=IP1 | \ Handover | +-----------+ +--------+ | Capability ^ IP | Corr. | | Exchange | Network |Node(CN)| V | +--------+ v / MN IP1 +-----------+ / +-+ --------> | New | < / | | ---------- | AR | ------ > ----/ +-+ | | < | ID=IP2 | +-----------+ Figure 1: Reference Scenario for Handovers In Figure 1, when the MN moves from the current AR to the new AR's coverage area, it MUST forward the IP-level identity of the current AR to the new AR. The new AR adds this identity to its Physical Neighborhood List (PNL) if this entry does not already exist and associates a lifetime to it. The lifetime field is refreshed if the entry already exists. This "Router Identity" message can be sent to the new AR as an ICMP option. The MN sends Router Identity message to the new AR either after undergoing a handover from the old AR to the new AR or via a second radio interface. The IP-level identity of the old AR contained in the Router Identity message is usually the IP address of the old AR. However, in certain cases such as the old AR being in the private IP address space, this identity can be different (Appendix A). If the MN can detect the identity of the new AR by listening to its beacon while still connected to the old AR, then the MN MUST forward this identity to the old AR. It again uses the Router Identity message for this purpose. If the MN receives the L2 identity of the AP in the APÆs beacon it forwards this information to the current AR also through the Router Identity message. 2.1.1. The Physical Neighborhood List (PNL) Figure 2 shows the PNL that is maintained at an AR. There is one entry in the PNL for each GAAR of an AR that has been identified so far. Trossen, et. al Expires May, 2002 5 Internet Draft Anticipated CAR Discovery Protocol October 1,2001 +-------------------------------------------------------+ |P|V| GAAR Identity | AP List |Lifetime| Capability Set| |_|_|____________ | ______|________|_________ ______| | | | | | | | | | | | | | | | | | | | | | +-------------------------------------------------------+ Figure 2: Physical Neighborhood List (PNL) Each entry in the PNL has the following fields: 1. Private (P) bit : When set (value = 1), this indicates that the corresponding GAAR is in the private IP address space. 2. Version (V) bit : When set (value =1 ) represents IPv4 address. When reset (value =0) represents IPv6 address. 3. GAAR Identity : 256 bit field representing the identity of the GAAR. If P =1 then the first 128 bits represent the border routerÆs globally routable IPv6 address and the second 32 bits are for the AR's identifier (see APPENDIX A). If P = 0, then the first 128 bits represent the globally routable IPv6 address of the GAAR. If the V bit is set the globally routable address is the IPv4 address of the BR. 4. AP List : This field contains the identifiers of the APs connected to the particular GAAR. These AP identities MUST be the same as those broadcast by the APs in their beacons. If APs broadcast the IP-level identity of their AR in the beacons, then this field is redundant. AP identities can be of variable length. This field is useful for conveying the AR reachability information from the MN to the current AR at the time of handover, as required by the TAR selection algorithm. In particular, if the AP do not transmit the IP-level identity as such of its AR in the broadcast beacon, then this field allows the current AR to correlate AP identity provided by the MN with the IP-level identity of the AR that serves the reachable AP. 5 Lifetime : The associated lifetime with each entry. It defines the time of expiry in seconds. This Trossen, et. al Expires May, 2002 6 Internet Draft Anticipated CAR Discovery Protocol October 1,2001 field is refreshed whenever a Router Identity message is received for the corresponding GAAR. 6 Capability Set : This field records the capabilities of the associated GAAR. 2.2. Capability exchange between GAARs Though not common now, in future IP networks, the GAARs may be heterogeneous in administrative control, function, capability, link layer technology and resources available for packet sessions. Further the MN may have specific requirements as regards these parameters. The knowledge of GAARs' capabilities allows the current AR to choose CARs from GAARs. Hence, the current AR needs to identify the capability set of each of its GAARs. When an AR receives the identity of a new GAAR, a capability exchange message is sent to a new GAAR over the wired Internet enlisting the AR's capabilities. On receiving this message, the recipient GAAR responds over the Internet with a message detailing its own capabilities. The capability information obtained via this message is used to populate the "Capability Set" field in the PNL. GAARs MAY also exchange the status of capabilities periodically or on-demand. 2.2.1. Examples of capabilities Capabilities can broadly be divided into dynamic and static. Static capabilities do not change over time, while dynamic capabilities do. Some of the capabilities are specific to a particular MN, and MAY be exchanged on demand. There may be other capabilities which are more generic and which may specify information relevant to all MNs. The capability exchange message is an ICMP option defined in Figure 2. Defining capability parameters and their content is not within the scope of this document. However, some illustrative examples are provided below. - Administrative parameters: ISP name, organizational ownership, device authentication and authorization data, policy information; - Cost of access: Dollar cost per QoS class; - Available radio interfaces that are geographically adjacent to given AR: 802.11, WCDMA, GSM; - Availability of application logic: Multicast support, playout buffer hosting for streaming applications, TCP performance enhancing proxies (PEPs), media transcoding functionality, header compression functionality; Trossen, et. al Expires May, 2002 7 Internet Draft Anticipated CAR Discovery Protocol October 1,2001 - Internet connectivity parameters: NAT traversal for connectivity; - Resource parameters: Existing load, available bandwidth are some of the resource parameters that can be used. - Identities of APs (layer 2 identities) that are served by the AR. 2.3. Candidate Access Router (CAR) Identification Once GAARs are identified, the current AR identifies the CARs for a particular MN as GAARs whose capabilities meet the MN's capability requirements. 2.4. Target Access Router (TAR) Selection The process of identifying the TAR for the MN's handover forms the final step of the TAR selection process. This step is performed at the time of handover. The TAR selection algorithm selects a unique TAR from the set of CARs. For this it also uses the AR reachability information for the MN at the time of handover. In addition, other aspects such as local policy and MN's preferences are also applied during the decision making. The details of TAR selection algorithm are not within the scope of CAR discovery protocol. 3. NEW MESSAGES USED BY THE HYBRID CAR DISCOVERY PROTOCOL 3.1. Router Identity Message This ICMP option (Figure 3), defined in the TLV format given below, is sent from an MN to the AR, to inform the AR about the identities of GAARs. 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 |P|V|L| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MN ID | +---------------------------------------------------------------+ | GAAR ID ~ +---------------------------------------------------------------+ Figure 3: Router Identity message Type : TBD Length : Variable Private (P) bit : When set (value =1) indicates that the AR identity corresponds to GAAR in the private IP address space. Trossen, et. al Expires May, 2002 8 Internet Draft Anticipated CAR Discovery Protocol October 1,2001 Version (V) bit : When set to 1 indicates IPv4 addresses. Set to 0 to indicate IPv6 addresses. Link Layer (L) bit : When set (value = 1) indicates that a Link Layer ID is being sent in the GAAR ID field. Reserved : 13 bit Reserved field. This field is set to zero. MN ID : Identity of the MN sending the Router Identity message. This is usually the home address of the MN. This is required for the security measure described in Section 6. GAAR ID : When P=0, this refers to the globally routable IP address of the GAAR. When P=1, the first 128 (32 if V= 1) bits refer to the globally routable IP address of the BR and the next 32 bits correspond to the GAAR identity within the private domain (see APPENDIX A). L bit MUST be set to zero. If only the L2 identity is available, this information is propagated in this field. The L bit MUST be set to 1 here. 3.2. Capability Exchange Message This ICMP option (Figure 4), defined in the TLV format given below, is sent between GAARs to advertise their capabilities. If GAAR is in the private IP address space, this option is sent to the corresponding Border Router (BR). The associated L2 identities (considered as part of the capabilities) of the APs, that are served by the AR are also propagated along with this message. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length |S|D|V| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Private source AR ID ~ +---------------------------------------------------------------+ | Private destination AR ID ~ +---------------------------------------------------------------+ ~ Capability parameters in TLV format ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: Capability exchange ICMP option Type : TBD Length : Variable Trossen, et. al Expires May, 2002 9 Internet Draft Anticipated CAR Discovery Protocol October 1,2001 Private Source(S) AR bit : When S = 1, it indicates that the AR sending this message is in the private IP address space. When S = 1, the private source AR ID field is also present. Private Destination (D) bit : When D = 1, it indicates that the AR finally receiving this message is in the private IP address space. When D = 1, the private destination AR ID field is also present. Version (V) bit : When V = 1, it indicates IPv4 addresses. When V = 0, it indicates IPv6 addresses. Reserved : This 13 bit field is reserved and is set to zero. Private Source AR ID : 32 bit source AR id which is present when S = 1. Private Destination AR ID : 32 bit destination AR id. Present when D = 1. Capabilities : Capabilities information in TLV format. 4. MOBILE NODE (MN) OPERATION The following item summarizes the operations at the MN: - Maintains information about current ARÆs IP Identity. - Listens to neighboring AP/AR beacons. - Forwards GAARÆs IP identity to the current AR using the Router Identity message. If the IP identity is not available, the APÆs L2 identity is transferred. - When a MN moves to a new AR it forwards the previous ARÆs IP Identity to the new AR. 5. ACCESS ROUTER (AR) OPERATION The following items summarize the operations at the AR: - The AR maintains a PNL. Trossen, et. al Expires May, 2002 10 Internet Draft Anticipated CAR Discovery Protocol October 1,2001 - Upon receiving a Router Identity message containing the identity of a GAAR from an MN, the AR checks to see whether the entry for this GAAR exists in the PNL. If it does, the AR refreshes the lifetime of the entry. If the entry does not exist, the AR sends a capability exchange message to the GAAR identified in the Router Identity message. The associated AP identities are also sent along with capabilities. If only the L2 identity is present in the GAAR ID field of the message, then the enhancement proposed in APPENDIX B MAY be used. - Identifies CARs based on the MN's requirements and capability parameters of GAARs recorded in the PNL. The current AR may solicit any MN-specific requirements from the GAARs. 6. SECURITY CONSIDERATIONS It is required to discuss the security considerations involved in performing GAAR discovery and performing capability exchange between the GAARs, which are the two main functions performed by the CAR discovery protocol presented here. As far as the capability exchange is considered, the capability exchange messages SHOULD be at least authenticated. The security association between GAARs for the exchange of capability information can be established using standard methods for device authentication, key exchange and encryption. The GAAR discovery part of the protocol however requires one special security measure, which is described below. This is to guard against a malicious MN or a faulty MN providing the AR with the incorrect GAAR identity. As a byproduct, this security measure also guards against a situation where the MN sends Router Identity message to the AR after waking up, based on its knowledge at the point of time when it entered the idle mode. According to this security measure, upon receiving the Router Identity message from the MN, the AR SHOULD check with the GAAR identified in the message as to whether that GAAR indeed had the context for the MN in the recent past. The MN ID provided by the MN in the Router Identity message is used to uniquely identify the MN at AR and GAAR. 7. INTELLECTUAL PROPERTY RIGHTS NOTICE Nokia Corporation and/or its affiliates hereby declare that they are in conformity with Section 10 of RFC 2026. Nokia's contributions may contain one or more patents or patent applications. To the extent Nokia's contribution is adopted to the specification, Nokia undertakes to license patents technically necessary to implement the specification on fair, reasonable and nondiscriminatory terms based on reciprocity. Trossen, et. al Expires May, 2002 11 Internet Draft Anticipated CAR Discovery Protocol October 1,2001 8. REFERENCES [1] IP Mobility Support, C. Perkins (Editor), RFC 2002, October 1996. [2] Mobility Support in IPv6, D. Johnson and C. Perkins, draft-ietf- mobileip-ipv6-13.txt, work in progress, November 2000. [3] Low Latency Handoffs in Mobile IPv4, MIPv4 Handoffs Design Team, draft-ietf-mobileip-lowlatency-handovers-v4-00.txt, work in progress, February 2001. [4] Fast handovers for Mobile IPv6, MIPv6 handover Design Team, draft-ietf-mobileip-fast-mipv6-01.txt, work in progress, April 2001. [5] Problem Description: Reasons For Performing Context Transfers Between Nodes in an IP Access Network, O. H. Levkowetz et. al., draft-ietf-seamoby-context-transfer-problem-stat-01.doc, work in progress, May 2001. [6] General requirements for a context transfer framework, H. Sayed et. al., draft-ietf-seamoby-ct-reqs-00.txt, work in progress, May 2001. [7] Buffer Management for Smooth handovers in Mobile IPv6, G. Krishnamurthi, R. Chalmers, C. Perkins, draft-krishnamurthi- mobileip-buffer6-01.txt, work in progress, March 2001. [8] Issues in Candidate Access Router Discovery, D. Trossen, G Krishnamurthi, H. Chaskar, J. Kempf, draft-ietf-seamoby- CARdiscovery-02.txt, work in progress, November 2001. 9. AUTHORÆS ADDRESSES Questions about this memo can also be directed to the authors: Dirk Trossen Communication Systems Laboratory, Nokia Research Center 5 Wayside Road Burlington, MA 01803, USA Phone: +1 781 993 3605 Fax: +1 781 993 1907 Email: dirk.trossen@nokia.com Govind Krishnamurthi Communication Systems Laboratory, Nokia Research Center 5 Wayside Road Burlington, MA 01803, USA Trossen, et. al Expires May, 2002 12 Internet Draft Anticipated CAR Discovery Protocol October 1,2001 Phone: +1 781 993 3627 Fax: +1 781 993 1907 Email: govind.krishnamurthi@nokia.com Hemant Chaskar Communication Systems Laboratory, Nokia Research Center 5 Wayside Road Burlington, MA 01803, USA Phone: +1 781 993 3785 Fax: +1 781 993 1907 Email: hemant.chaskar@nokia.com Eunsoo Shim Department of Electrical Engineering Columbia University 530 West 120th Street New York, NY 10027 Email: eunsoo@ctr.columbia.edu Richard D. Gitlin Department of Electrical Engineering Columbia University 530 West 120th Street New York, NY 10027 Email: rich@ee.columbia.edu APPENDIX A. Dealing With Private Address Space Due to the scarcity of IPv4 address space and also for security reasons, many networks use private IP addresses for the routers within those networks. They also deploy a Border Router (BR) with access to Network Address Translation (NAT) capability, at the point where such a network is connected to the Internet. By the term border router we mean a globally routable router connecting the private space to the Internet. In order to apply the solution proposed in this draft to scenarios where at least one of the two ARs, that are geographically adjacent to each other, is in the private IP address space, the following extensions are suggested to illustrate a possible approach. Trossen, et. al Expires May, 2002 13 Internet Draft Anticipated CAR Discovery Protocol October 1,2001 MN +-----------+ +--+ +-+ | Current | |B | < | | ---------- | AR | -|R |-> ----\ +-+ | | | | < \ | ARp | +--+ \ | +-----------+ ^ +--------+ |Handover / IP | Corr. | | Capability / Network |Node(CN)| V Exchange / +--------+ v / MN (NAT,ARpid)+-----------+ / +-+ --------> | New | < / | | ---------- | AR | ------ > ----/ +-+ | | < | ARg | +-----------+ Figure 5: Handover from Private to Public Domains Consider a scenario as in Figure 5 where an MN is currently attached to an AR in a private address space (for example in a corporate Intranet) denoted by ARp. Assume that ARp is connected to the Internet via a BR. Further suppose that there is an AR in the globally routable IP address space (for example an AR in the cellular wide area network) denoted by ARg, which is physically adjacent to ARp. As described in Section 3.1, the MN must provide ARg with the identity of ARp so that ARp and ARg can learn about each other's presence and engage in the capability exchange procedures. The MN however cannot provide the private IP address of ARp to ARg. This is because ARg cannot contact ARp directly for the capability exchange. We therefore propose the following extension the protocol defined in this draft as an illustrative approach. We require that the BR assign an identity (scope of which is within the Intranet) to each AR (ARpid in Figure 4) in the private address space. This identity SHOULD be different from the private IP address of that AR. An MN that is connected to an AR in the private address space such as ARp, is informed about the globally routable IP address of the BR and also about the identity ARpid. Then, in the Router Identity message the MN provides ARg with the globally routable IP address of the BR along with the identity ARpid. Upon receiving this message, ARg adds the tuple (BR IP address, ARpid) in the "GAAR Identity" field of it PNL as an identifier for ARp. ARg then sends the capability exchange message to the address of the BR. This message also includes the identity ARpid. The BR performs the mapping from the ARpid to the private IP address of ARp and forwards the capability exchange message to ARp. This also allows the BR to scrutinize the capability exchange message so as to detect any security attacks. This extension is also used when an MN moves into a private address space from a public network. Trossen, et. al Expires May, 2002 14 Internet Draft Anticipated CAR Discovery Protocol October 1,2001 B. Enhancement To The CAR Discovery Protocol In Section 3.1, we presented a protocol in which an AR, say AR1, discovers its GAARs based on handovers. However, in the event that AR1 cannot map a link layer ID it receives from an MN to an ARÆs IP address, the MN may be forced to perform a hard handover. The probability of this event can be reduced by querying any GAARs already existing in the PNL of AR1 for the link layer ID. Each GAAR receiving such a query, can then check whether an AR, link layer ID mapping exists in their PNLs. If mapping does exist, in any of the GAARs, AR1 can then be informed about the mapping. AR1 can query the GAARs in its PNL in a sequential or parallel fashion. If the immediate GAARs in AR1 do not have such a mapping, they can then query GAARs in their PNLs in turn, thus expanding the search to find the required mapping. Trossen, et. al Expires May, 2002 15