INTERNET DRAFT Pat R. Calhoun Category: Standards Track Sun Microsystems, Inc. Title: draft-calhoun-mobileip-proactive-fa-02.txt Tom Hiller Date: September 2000 Lucent Technologies James Kempf Sun Microsystems, Inc. Peter J. McCann Lucent Technologies Chandana Pairla University of Illinois Ajoy Singh Sebastian Thalanany Motorola Foreign Agent Assisted Hand-off Status of this Memo This document is an individual contribution for consideration by the Mobile IP Working Group of the Internet Engineering Task Force. 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. Calhoun et al. expires February 2001 [Page 1] INTERNET DRAFT September 2000 Copyright (C) The Internet Society 2000. All Rights Reserved. Abstract The Mobile IP protocol allows a Mobile Node to continue using the same home address even after changing its point of attachment to the Internet. This provides transparency to most existing applications that assume a fixed address and a fixed point of attachment. However, new applications, such as voice-over-IP, have additional real-time requirements such that a change in the point of attachment will cause a noticeable degradation of service unless additional steps are taken to reduce the latency of a handoff event. This specification proposes extensions to the Mobile IP protocol that may be used by Foreign Agents to set up a Mobile Node's visitor entry, and forward its packets, prior to receiving a formal Registration Request from the Mobile Node. This enables a very rapid establishment of service at the new point of attachment so that the effect of the handoff on real-time applications is minimized. Table of Contents 1.0 Introduction 1.1 Requirements language 1.2 Terminology 1.3 Fast handoffs 2.0 Registration Latency 2.1 Gateway Foreign Agents 2.2 Anchor Foreign Agent 3.0 Movement Detection 3.1 Ping-Pong effect 4.0 Reverse Tunneling Support 5.0 Security Relationships 6.0 Power Consumption 7.0 Operation 7.1 Foreign Agent Considerations 7.2 Gateway/Anchor Foreign Agent Considerations 8.0 Binding Update extensions 9.0 Link Layer Address NAI 9.1 CDMA 2000 Link Layer Address Extension 9.2 Ethernet Link Layer Address Extension 10.0 Error Values 11.0 IANA Considerations 12.0 Security Considerations 13.0 References 14.0 Acknowledgements 15.0 Authors' Addresses Calhoun et al. expires February 2001 [Page 2] INTERNET DRAFT September 2000 16.0 Full Copyright Statement Calhoun et al. expires February 2001 [Page 3] INTERNET DRAFT September 2000 1.0 Introduction This specification proposes extensions to the Mobile IP protocol that may be used by Foreign Agents to set up a Mobile Node's visitor entry, and forward its packets, prior to receiving a formal Registration Request from the Mobile Node. This enables a very rapid establishment of service at the new point of attachment so that the effect of the handoff on real-time applications is minimized. The proposed extensions make a few minimal assumptions about support available from the link layer. These assumptions are fairly broad and abstract. Although they address the kinds of link layer support available in existing radio link layers, the assumptions are not based on any specific radio link protocol. The extensions handle both intra-domain and inter-domain handoff. While intra-domain handoff MAY make use of pre-configured security associations between Mobility Agents, inter-domain handoffs MAY make use of the AAA infrastructure. In the case of inter-technology handoff, active involvement by the mobile is necessary to switch from one network interface to another; however, the delivery of the agent advertisements, indicating the availability of a mobility agent on a new network interface, is still controlled by network assisted handoff. In summary, this draft covers a hand-off scenario not addressed by RFC 2002: that of a pro-active, network-controlled, anchor-chained hand-off. 1.1 Requirements language In this document, the key words "MAY", "MUST, "MUST NOT", "optional", "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as described in [4]. 1.2 Terminology This document frequently uses the following terms: AAA Authentication, accounting and authorization. Anchor Foreign Agent (AFA) A foreign agent with publicly routable IP address that acts as an anchor point when a mobile moves to a new foreign agent. Upon successful global registration (registration with home agent) of a mobile node, the anchor foreign agent supports Calhoun et al. expires February 2001 [Page 4] INTERNET DRAFT September 2000 local registration when the mobile node changes its point of attachment to some other neighboring foreign agents. cdma2000 This is a wide-band radio transmission technology standard, that uses CDMA(code division multiple access) technology, to meet the demands of a third-generation wireless communication system. Connection ID A number used to differentiate different link layer connections originated from the same device. Dormant mode Certain wireless technologies support dormancy, which allows the mobile to go into power saving mode. This typically occurs when the mobile has been idle for some time, but could be initiated by the network. Foreign Agent IP Address Derivation The derivation of the IP address of a source foreign agent or a target foreign agent based on the receipt of a link layer trigger at the target foreign agent or the source foreign agent respectively. Gateway Foreign Agent(GFA) A foreign agent with publicly routable IP address that acts as a concentration point for other foreign agents within an administrative domain. Upon successful global registration (registration with Home agent) of a mobile node, the GFA supports local registration when the mobile node changes its point of Attachment to some other foreign agent of the same administrative Domain. Home Domain The domain where the home network [1] and home agent [1] are located. International Mobile Subscriber information (IMSI) A number used for identifying a mobile subscriber station. Link layer A link layer specifies a protocol used by communicating nodes to exchange information over a physical link. A mobile node attaches itself to a mobile access network, before it can be served by a foreign agent. A mobile node's link layer address is the media access control(MAC) address of the mobile node's network interface. Calhoun et al. expires February 2001 [Page 5] INTERNET DRAFT September 2000 Mobility Agent A foreign agent or a home agent. The foreign agent types include an anchor foreign agent and a gateway foreign agent. Mobility Advertisement An advertisement message constructed by attaching a special extension to a router advertisement message. Movement Detection A detection of a movement in the link layer attachement of the mobile node to a mobile access network. Ping-Pong Handoff The rapid oscillation of a mobile node among coverage area of two or more foreign agents. Proactive Foreign agent A foreign agent that initiates mobile/IP registration on behalf of a mobile node due to reception of some link layer trigger event. Source Trigger A signal received by the source foreign agent mobile/IP stack, via the link layer, when the mobile node departs from the serving area of the source foreign agent. Target Trigger A signal received by the target foreign agent mobile/IP stack, via the link layer, when the mobile node arrives at the serving area of the target foreign agent. Trigger The link layer signal used by wireless link layer to inform inter foreign agent handoff event to Mobile/IP stack. Visited Domain An administrative domain, visited by a Mobile IP client, and containing the AAA infrastructure needed to carry out the necessary operations enabling Mobile IP registrations. From the point of view of the foreign agent, the foreign domain is the local domain. 1.2 Fast handoffs MNs connect to FAs via direct, link-layer connections. Because an FA is directly connected to the link-layer, it may obtain link-layer information such as power measurements that might indicate the Calhoun et al. expires February 2001 [Page 6] INTERNET DRAFT September 2000 necessity of a hand-off to a new FA. The FA can also gain assurance of the MN's identity through link-layer authentication, and can authenticate the stream of traffic coming from the MN, including any power measurements or other indications used for hand-off. In this document, we will assume that the link-layer events are signaled to the Foreign Agent as "triggers". The acquisition of a "trigger" to signal that a hand-off is necessary may be more difficult when the technologies differ. We assume that any such triggers will be sufficient to derive the IP addresses of the Foreign Agents that will receive or send the hand-off. If such a trigger is not available or if the MN decides on its own that a hand-off is to take place, then one of the FAs can often still derive the identity (IP address) of the other from link-layer messages. In order for the Mobile IP protocol to provide fast hand-off, the following problems must be addressed: 1. Reducing the latency involved in the registration process. Although optimization of the Registration process is not typically considered a Hand-Off problem, this proposal assumes that such a mechanism is in place. 2. Reducing the latency involved in the Mobile Node's movement detection process. 3. "Bi-casting" the Mobile Node's traffic to two (or more) points of attachment, ensuring that the mobile's traffic is delivered as soon as the link layer hand-off is completed. 4. Support for Reverse Tunneling, which MAY be required for private addresses. 5. The Security Relationships between the mobility entities for inter-domain hand-offs. 6. Does not increase mobile power consumption 2.0 Registration Latency The Mobile IP protocol [1] requires that a Mobile Node registers with a Foreign Agent, and subsequently its Home Agent, in order to have its packets delivered to its current point of attachment. The Mobile IP Regional Registration [6] specification proposes optimized registration approaches using two different methods: 1. Gateway Foreign Agents (GFA), which are mobility agents that act as concentration points for Foreign Agents within an Administrative Domain. 2. Anchor Foreign Agents (AFA), where a previously used Foreign Agent becomes an anchor point when a mobile moves to a new Foreign Agent. Calhoun et al. expires February 2001 [Page 7] INTERNET DRAFT September 2000 Both GFAs and AFAs allow a Mobile Node's registration message to be processed by a Mobility Agent in the local domain, eliminating the need to contact the Home Agent, which MAY be topologically distant. 2.1 Gateway Foreign Agents The Mobile IP Regional Registration specification introduces the Gateway Foreign Agent (GFA), as a mobility agent that two Foreign Agents providing service to a Mobile Node have in common. Figure 1 provides an example of a Mobile's initial registration, through the GFA. Given this is the first registration message, the message MUST be forwarded to the Home Agent. All packets destined for the mobile will be delivered to the GFA, which in turn will forward the packets to the Foreign Agent servicing the Mobile Node. Reg Req +-----+ Reg Req +----------->| oFA |--------------+ | +-----+ | | v +----+ +-----+ Reg Req +----+ | MN | | GFA |<------->| HA | +----+ +-----+ +----+ +-----+ | nFA | +-----+ Figure 1 - Initial Registrations through GFA In the event that the mobile moves to a new Foreign Agent that is serviced by a GFA that is common with oFA, the Mobile Node MAY issue a Regional Registration Request (see Figure 2). The Regional Registration message does not need to be forwarded to the Home Agent, since the mobile's traffic can still be delivered to the same GFA. This optimized approach effectively reduces the latency involved in the registration process. Calhoun et al. expires February 2001 [Page 8] INTERNET DRAFT September 2000 +-----+ | oFA | +-----+ +----+ +-----+ +----+ | MN | | GFA | | HA | +----+ +-----+ +----+ | ^ | +-----+ | +------------>| nFA |-------------+ Regional Reg +-----+ Regional Reg Figure 2 - Regional Registration through GFA 2.2 Anchor Foreign Agent The Mobile IP Regional Registration specification introduces what this document will call the Anchor Foreign Agent, which is similar to [7]. The Anchor Foreign Agent operates very similarly to the GFA, with the exception that the mobile's old Foreign Agent acts as an anchor point for the Mobile Node. In order to minimize the latency involved in the registration process, the Mobile Node MAY issues a Regional Registration message, setting the old Foreign Agent as the GFA, as shown in Figure 3. Once completed, the Mobile Node MAY issue an additional RFC 2002 compliant Registration Messages to eliminate the routing leg through the anchor Foreign Agent. +-----+ +----+ | oFA | | HA | +-----+ +----+ ^ +----+ | | MN | | Regional +----+ | Reg | | | +-----+ +------------>| nFA | Regional Reg +-----+ Figure 3 - Regional Registrations through an AFA 3.0 Movement Detection The Mobile IP protocol [1] and the Regional Registration extension [6] require Mobile Nodes to listen for, or solicit, advertisements in order to detect that a movement to a new IP subnet has occurred. This Calhoun et al. expires February 2001 [Page 9] INTERNET DRAFT September 2000 movement detection mechanism introduces significant latency into the hand-off process, which causes service degradation, especially for real-time services. Service is further impacted given the additional latency introduced through the registration process that follows the movement detection, since the mobile's traffic can only be delivered once all of the registration has completed. There have been many solutions proposed to solve this problem, including increasing the advertisement frequency. In networks where radio spectrum is expensive or bandwidth is limited, the additional signaling required for increasing advertisement frequency is a serious issue impacting deployability. +-----+ | GFA | +-----+ ^ | 2b. Regional Reg | | 3b. Regional Reply | | | v +-----+ 1. Binding Update +-----+ | | -----------------> | | | oFA | 2a. Regional Reg | nFA | | | <----------------- | | +-----+ 3a. Regional Reply +-----+ -----------------> +-----+ Movement +-----+ | MN | - - - - - - - - -> | MN | +-----+ +-----+ Figure 4 - "source trigger" hand-off using either AFA or GFA In this document, we propose that the Foreign Agent take a pro-active approach and issue the Regional Registration message on behalf of the Mobile Node (acting as a surrogate of sorts). When a Foreign Agent is aware that a hand-off is occurring at the link-layer, a trigger is sent to the Mobile IP protocol stack. This trigger could occur either at old Foreign agent (see Figure 4), or at the new Foreign agent(see Figure 5). The source trigger can be obtained at the old FA once the link layer detects that the MN is departing from the old FA coverage area. The target trigger can be obtained at the new FA once the link layer detects that the MN is arriving at the new FA coverage area. Both the source and target trigger may be available before the actual completion of the link layer handoff. Calhoun et al. expires February 2001 [Page 10] INTERNET DRAFT September 2000 +-----+ | GFA | +-----+ ^ | 3b. Regional Reg | | 4b. Regional Reply | | 1. Binding Request | v +-----+ <---------------- +-----+ | | 2. Binding Update | | | oFA | -----------------> | nFA | | | 3a. Regional Reg | | +-----+ <----------------- +-----+ 4a. Regional Reply -----------------> +-----+ Movement +-----+ | MN | - - - - - - - - -> | MN | +-----+ +-----+ Figure 5 - "target trigger" hand-off using either AFA or GFA Figures 4 & 5 provide an example of network initiated hand-off using both an Anchor Foreign Agent and a Gateway Foreign Agent. The messages whose numbers end with 'a' (e.g. 3a) are used with Anchor Foreign Agents, while the messages with a 'b' are used with Gateway Foreign Agents. The fact that both the AFA and the GFA are present in Figures 4 & 5 are purely for illustrative purposes, as a network would only use one method for a given mobile. In Figure 4, oFA obtains link-layer information, such as power measurements, that indicates the necessity of a hand-off to nFA. This causes a trigger on oFA, which results in the transmission of a Binding Update to nFA. In Figure 5, if a GFA is being used, the nFA must issue a Binding Request to oFA when it receives a trigger that indicates that a link-layer handoff has occured. This is needed in order to determine the GFA's address, if one was used. Upon receipt of a Binding Request, oFA MUST reply with a Binding Update. In both cases, the receipt of a Binding Update causes a Regional Registration Request to be sent from nFA to either oFA (which acts as the anchor FA) or the GFA. The associated Regional Registration Reply contains the information required by nFA to establish its local visitor entry. In the event that the GFA information was provided by the link-layer, the Binding Request and Update messages do not need to be exchanged in the "target trigger" case. If this mechanism is used, the need for Calhoun et al. expires February 2001 [Page 11] INTERNET DRAFT September 2000 GRE and Reverse Tunneling would also have to be contained within the link-layer messages. The need for modifying the link-layer messages to carry such information is out of the scope of this specification. The end result is that the new Foreign Agent already has a visitor entry for the Mobile Node prior to the RFC 2002 Registration procedure. The Mobile Node's packets may be delivered as soon as it enters nFA's service area, and establishes the necessary air interface channel. 3.1 Ping-Pong effect Some link-layers are subject to rapid motion of MNs between two FAs. For example, even though link-layer power measurements may indicate that a hand-off is necessary, the mobile may fail to attach to the new point of attachment, and return almost immediately to its old point of attachment. This event is known as a "ping-pong" effect. Data +-----+ Data +-------------| oFA |<-------------+ | +-----+ | v | +----+ +-----+ Data +----+ | MN | | GFA |<--------| HA | +----+ +-----+ +----+ ^ | | +-----+ | +-------------| nFA |<-------------+ Data +-----+ Data Figure 6 - Bi-Casting using a Gateway Foreign Agent In such situations, it does not benefit the Mobile to issue a registration in the new service area, and then move back to its old point of attachment. To avoid problems with ping ponging, this proposal makes use of the 'S' bit (Simultaneous Binding) in the Regional Registration message, allowing the user's traffic to be "Bi-Casted" to two or more Foreign Agents (see Figures 6 & 7). Calhoun et al. expires February 2001 [Page 12] INTERNET DRAFT September 2000 Data +-----+ Data +----+ +-------------| oFA |<--------------------------| HA | | +-----+ +----+ v | +----+ | | MN | | Data +----+ | ^ v | +-----+ +-------------| nFA | Data +-----+ Figure 7 - Bi-Casting using an Anchor Foreign Agent When simultaneous bindings are in effect, and a ping-pong event occurs, the mobile's service is guaranteed not to experience any additional latency beyond that imposed by the link-layer handoff. It is also possible for Foreign Agents to issue Regional Registrations with the 'S' bit enabled in order to provide for a smooth hand-off between service areas. 4.0 Reverse Tunneling Support In the event the Mobile Node requested Reverse Tunneling [12] support, by setting the 'T' bit in its Registration Request, the Binding Update (see Section 8.0) from either oFA or the GFA includes the 'T' bit enabled to inform nFA to establish a bi-directional tunnel for the visitor entry. 5.0 Security Relationships The Mobile IP Regional Registration specification [6] requires that the communicating Mobility Agents exchange authenticated messages. This imposes a requirement for Mobility Agents to share a pre- established security association. This assumption is valid for intra-domain mobility (mobility within an Administrative Domain). However, such a requirement introduces a scaling problem when the Mobility Agents are owned by separate Administrative Domains (ADs). Given that the existing AAA infrastructure is used to establish dynamic security associations between Foreign and Home Agents in different ADs, the same infrastructure could be used to establish the required security association for the purposes of inter-domain hand- offs (see Figure 8). Calhoun et al. expires February 2001 [Page 13] INTERNET DRAFT September 2000 +-----+ +-----+ | AAA |-------------->| AAA | +-----+ +-----+ ^ | | | | AAA | | Hand-Off | | Req | | v +-----+ +-----+ | oFA | | nFA | +-----+ +-----+ +-----+ Movement +-----+ | MN | - - - - - - > | MN | +-----+ +-----+ Figure 8 - Inter-FA communication using AAA Note that it is possible for geographically neighboring Foreign Agents owned by different Administrative Domains to have a pre- established security association, which would reduce the latency introduced by the AAA infrastructure traversal. Given that such geographically neighboring FAs MAY be small in number, such an approach MAY be reasonable. 6.0 Power Consumption An additional benefit that derives from this proposal is the potential for tracking mobile nodes while in dormant mode, if the radio link supports it, allowing significant power saving without adding additional complexity to the network layer protocol in the wired network. One of the primary innovations proposed here, namely to allow the Foreign Agents to set up visitor entries prior to the Mobile Node's registration, is also useful for power saving. Certain radio link layers allow the mobile node to enter dormant mode when idle. Allowing the network to control the handoff ensures that the mobiles do not have to be removed out of dormant mode in order to establish a Mobile IP handoff. Limiting power consumption is a requirement for certain wireless Standards Defining Organizations (SDOs), and a Mobile IP fast handoff proposal MUST satisfy this requirement. 7.0 Operation A Foreign Agent can receive two different types of triggers informing Calhoun et al. expires February 2001 [Page 14] INTERNET DRAFT September 2000 it of a handoff (The event that causes the trigger may be derived via link layer messaging assistance from the network or from the mobile): - a "source trigger" is when the old FA is informed of an upcoming link-layer handoff, - a "target trigger" occurs at the new FA when it is informed that a link layer handoff is in progress. It is also possible that a particular kind of link layer technology can support both source and target triggers. The method by which such triggers occur are link-layer specific, and are outside the scope of this document. When the new Foreign Agent receives a "target trigger" event notification, it SHOULD issue a Binding Request [5] message to the old Foreign Agent. This is necessary in order to determine whether a GFA was used. When the old Foreign Agent receives a "source trigger" event notification, or a Binding Request, it MUST issue a Binding Update [5] message to the new Foreign Agent. The Binding Update contains the Mobile Node's home address, any security association information [8], as well as the identity of either the Gateway Foreign Agent (GFA) or the Anchor Foreign Agent (AFA). The Mobile's link-layer address MUST also be provided within the Binding Update (see Section 9). The new Foreign Agent MUST issue a Regional Registration Request message to either the AFA, or the GFA, upon receipt of a Binding Update message. The Regional registration message MUST include the mobile's link-layer address, as specified in Section 9. The Regional Registration message MAY have the 'S' bit enabled, depending upon local policy (see Section 3.1). The Regional Registration's lifetime field specifies the proposed GFA or AFA's visitor entry duration. Should the GFA or AFA not receive a new Regional Registration message, or a Registration Request message from the Mobile Node prior to the expiration of the lifetine, it SHOULD expire the visitor entry tied to the new Foreign Agent. The Regional Registration Reply message from the AFA or GFA MUST include the Mobile Node's Home Address, Home Agent Address, any security associations used with those nodes, visitor entry lifetime, and the flags that were agreed upon at registration time. Once the Mobile Node establishes a link layer channel with the new Foreign Agent, its traffic will be immediately delivered along with a Mobility Advertisement message [1]. Upon receipt of the Advertisement message, the Mobile Node MUST issue a Registration Message to update Calhoun et al. expires February 2001 [Page 15] INTERNET DRAFT September 2000 its Home Agent's binding table. Note that the Foreign Agent MAY delay sending the Mobility Advertisement message, especially to reduce noticeable service disruption during a ping-pong effect. However, when doing so, it MAY need to re-issue a new Regional Registration message to either the AFA or GFA, to extend the visitor entry's lifetime. This procedure MAY also be used in wireless technologies that support dormant mobiles, in order to eliminate the need for the mobile to wake up and perform a Mobile IP registration. In the case of a dormant mobile, or a mobile outside of the local service area, incoming data destined for the Mobile Node MAY require the Foreign Agent to cause a transmission of a link-layer page message. Given that a Mobile Node's packets will be delivered prior to registration, a Mobile Node is free to discard all packets received from Foreign Agents with which it hasn't registered. If GFAs are used, and a Foreign Agent determines that a Mobile Node is no longer in its service area, it SHOULD issue a Regional Registration message with the lifetime set to zero (0), which will remove the current visitor entry on the GFA. Foreign Agents MAY decide to not issue this message immediately when a link-layer trigger is received, in order to support smooth service during a ping-pong event. If AFAs are used, a Foreign Agent MUST issue a Regional Registration message with a zero lifetime to the AFA once a successful Registration Reply is received from the Mobile Node's Home Agent. This will effectively change the Mobile Node's anchor point to the new Foreign Agent. 7.1 Foreign Agent Considerations Upon receipt of a "target trigger" event, the Foreign Agent MAY issue a Binding Request [5] message to the Foreign Agent to whom the mobile is being handed off. Upon receipt of either a Binding Request or a "source trigger" event, the Foreign Agent MUST issue a Binding Update message [5] to the Foreign Agent to which the mobile is being handed off. The Binding Update's Mobile Node Home Address field MUST be set to the recipient of the message, while the Care-Of address field MUST be set to the local address. The Binding Update message MUST include a Link Layer Address NAI extension (Section 9). If the Foreign Agent made use of a GFA for the mobile, the GFA IP Address Extension [6] MUST be present. Calhoun et al. expires February 2001 [Page 16] INTERNET DRAFT September 2000 Upon receipt of a Binding Update, the Foreign Agent MUST issue a Regional Registration Request to either the GFA (if the GFA IP Address Extension was present in the Binding Update), or the sender of the Binding Update. The Regional Registration Request's Care-Of address field MUST be set to the local Foreign Agent's address, while the GFA IP Address MUST be set to the address of the recipient of the request. The Link-Layer Address NAI (Section 9) extension MUST be present. The request's lifetime field is set to an administratively configured value, that is used to inform the recipient of the expected lifetime for the visitor entry. The above procedures require Foreign Agents to resolve the handoff peer's link layer address to an IP address, and this particular process is outside the scope of this document. The GFA or AFA MUST reply with a Regional Registration Reply, which MUST include the Link Layer Address NAI extension (Section 9), as well as the Mobile Node's home and Home Agent addresses, the remaining tunnel lifetime, as well as any flags that were set in the Mobile Node's registration request message. If the code field indicates a successful registration, the local Foreign Agent MUST create a visitor entry for the Mobile Node. In the event that a Foreign Agent handling a particular Mobile Node's visitor entry is soon to expire, and the Mobile Node has not yet issued a Registration Request, the FA has the option to transmit a new Regional Registration message to either the GFA or AFA. Whether the FA transmits a new Regional Registration is a policy decision up to the network administrator. A Foreign Agent MAY receive packets for a Mobile Node to which it does not have a direct link layer connection. At this point, the Foreign Agent MAY: 1. Drop all packets for the Mobile Node 2. Buffer packets for the Mobile Node 3. Attempt to establish a link-layer connection with the mobile 4. Issue a Regional Registration Request with a zero lifetime When a Foreign Agent determines that it is no longer servicing a Mobile Node, it SHOULD issue a Regional Registration Request message with the lifetime field set to zero (0). This will cause the associated visitor entry on the AFA or GFA to be expired. If a Regional Registration Reply message is received with the code field set to DO_NOT_SERVICE_MN (Section 10), the Foreign Agent SHOULD NOT provide service to the Mobile Node. The Foreign Agent MAY enforce this by closing the Link-Layer connection (if possible), not issuing any Mobility Advertisements to the Mobile Node (assuming a point-to- Calhoun et al. expires February 2001 [Page 17] INTERNET DRAFT September 2000 point Link Layer), or simply denying all Registration Requests with the error code set to 65 (Administratively Prohibited) [1]. 7.2 Gateway/Anchor Foreign Agent Considerations Upon receipt of a Regional Registration Request, a GFA or AFA MUST create a visitor entry indicating the Mobile Node's current point of attachment. In the event that a visitor entry already exists, the GFA or AFA SHOULD be able to create multiple visitor entries for the same Mobile Nodes with different Care-Of addresses. If the 'S' bit was enabled in the Regional Registration Request, the GFA MUST be able to forward the mobile's packets to all Foreign Agents in the visitor entries. When constructing the Regional Registration Reply, the AFA or GFA SHOULD include the FA-FA authentication extension [6], and set the lifetime field to the lesser of: 1. number of seconds before the Mobile Node's Registration with its Home Agent will expire. 2. The lifetime of the locally created Visitor Entry. In the event that the Regional Registration Request's lifetime field was set to zero (0), the GFA or AFA MUST remove the visitor entry associated with the Care-Of address in the message. Should the GFA or AFA decide that the Foreign Agent is not to provide service to the Mobile Node, it MUST issue a Regional Registration Reply message, with the code field set to DO_NOT_SERVICE_MN (see Section 10). 8.0 Binding Update extensions This specification has identified a need for Reverse Tunneling to be communicated in the Binding Update from oFA to nFA (see Figures 4 & 5). Calhoun et al. expires February 2001 [Page 18] INTERNET DRAFT September 2000 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 |A|I|M|G|T| Rsvd| Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mobile Node Home Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Care-of Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Identification + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Extensions ... +-+-+-+-+-+-+-+- The only change to the Binding Update [5] is the additional 'T' bit: T nFA must establish a reverse tunnel for the visitor entry 9.0 Generalized Link Layer Address Extension This section defines the Generalized Link Layer Address (LLA) Extension, used by any that needs to communicate Link Layer Addresses. The format of the extension follows MIER [13], and each sub-type of link-layer address defines its own sub-structure. This draft defines two sub-types, the cdma2000 IMSI and the Ethernet Address. Future RFCs should allocate their own sub-type and define their own address formats. 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 | Sub-Type | LLA ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type TBD (skippable) [1] Length The length of the Link Layer Address + the one octet Sub-Type field Calhoun et al. expires February 2001 [Page 19] INTERNET DRAFT September 2000 Sub-Type This field contains the Link Layer sub-type identifier LLA Contains the Link Layer Address In this document, two subtypes are defined: 1 cdma2000 International Mobile Station Identity [14] 2 Ethernet 48 bit MAC address [15] 9.1 cdma2000 Link Layer Address Extension The cdma2000 Link Layer Address Extension contains the International Mobile Station Identity, as defined in [14]. 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 | Sub-Type | IMSI ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type TBD (skippable) [1] Length The length of the IMSI field + the one octet Sub-Type field Sub-Type 1 IMSI Contains the IMSI, in the form: : Where the is an ASCII-based representation of the International Mobile Station Identifier, most significant digit first, ":" is ASCII 0x3a, and the Connection ID is the ASCII representation of a small, decimal number used for distinguishing different link-layer connections from the same Calhoun et al. expires February 2001 [Page 20] INTERNET DRAFT September 2000 device. 9.2 Ethernet Link Layer Address Extension The Ethernet Link Layer Address Extension contains the 48 bit Ethernet MAC Address, as defined in [15]. 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 | Sub-Type | MAC ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type TBD (skippable) [1] Length 7 (includes the Sub-Type field) Sub-Type 2 MAC Contains the 48 bit Ethernet MAC Address. 10.0 Error Values The following table contains the name of Code [9] to be returned in a Registration Reply, the value for the Code, and the section in which the error is first mentioned in this specification. Error Name Value Section of Document ---------------------- ----- ------------------- DO_NOT_SERVICE_MN TBD 7.1 11.0 IANA Considerations The number for the Generalized Link Layer Address Extension is taken from the numbering space defined for Mobile IP registration extensions defined in RFC 2002 [1]. These MUST NOT conflict with any numbers used in RFC 2002[1], RFC 2344 [12], RFC 2356 [16], Mobile IP Calhoun et al. expires February 2001 [Page 21] INTERNET DRAFT September 2000 Challenge/Response Extension [17], Mobile IP Network Access Identifier Extensions Draft[18]. The Code values specified for errors, listed in section 10, MUST NOT conflict with any other code values listed in RFC 2002[1], RFC 2344 [12], RFC 2356 [16], Mobile IP Challenge/Response Extensions[7], or Mobile IP Network Access Identifier Extensions Draft [18]. The new 'T' flag in the Binding Update message MUST NOT conflict with any other flags defined in the message in [5]. 12.0 Security Considerations Similar to [6] and [7], this specification assumes that the local Foreign Agent, and the GFA (or AFA) inherently trust each other. This MAY be achieved through the use of a long lived security association. This specification introduces a new change to Mobile IP, which is the ability for a Mobile Node to receive packets from a Foreign Agent to which it has not yet registered. In the event that the Mobile Node does not wish to receive packets from unknown Foreign Agents, it MAY drop them. Although this document does not specify how Foreign Agents can identify, or track, Mobile Nodes, it is assumed that the wireless link layer be sufficiently secure in order to correctly identify a Mobile Node. Wireless networks that do not provide such features will be subjected to impersonation attacks, where malicious nodes could cause the Foreign Agents to believe that a Mobile Node has moved to other service areas. 13.0 References [1] C. Perkins, Editor. "IP Mobility Support". RFC 2002. October 1996. [2] T. Hiller et al. "Cdma2000 Wireless Data Requirements for AAA". draft-hiller-cdma2000-AAA-00.txt (work in progress). October 1999. [3] U. Black. "2nd Generation Wireless Networks". Prentice-Hall. New York. 1999. [4] S. Bradner. "Key words for use in RFCs to Indicate Requirement Levels". BCP 14. RFC 2119. March 1997. Calhoun et al. expires February 2001 [Page 22] INTERNET DRAFT September 2000 [5] C. Perkins and D. Johnson. "Route Optimization in Mobile IP". draft-ietf-mobileip-optim-08.txt (work in progress). February 1999. [6] E. Gustafsson, A. Jonsson, C. Perkins. "Mobile IP Regional Registration", draft-ietf-mobileip-reg-tunnel-02.txt (work in progress), March 2000. [7] G. Dommety. "Local and Indirect Registration for Anchoring Hand- offs", draft-dommety-mobileip-anchor-handoff-00.txt (work in progress), March 2000. [8] P. Calhoun, H. Akhtar, E. Qaddoura, N. Asokan, "Foreign Agent Keys Encoded as Opaque Tokens for use in Hand-off Process", draft-calhoun-mobileip-fa-tokens-00.txt (work in progress), March 2000. [9] S. Hanks, T. Li, D. Farinacci, and P. Traina. Generic Routing Encapsulation (GRE). Request for Comments (Informational) 1701, Internet Engineering Task Force, October 1994. [10] C. Perkins. Minimal Encapsulation within IP. Request for Com- ments (Proposed Standard) 2004, Internet Engineering Task Force, October 1996. [11] Mohamed M.Khalil, Emad Qaddoura, Haseeb Akhtar, Pat R. Calhoun, "Generalized NAI Extension (GNAIE)", draft-ietf-mobileip-gnaie- 00.txt (work in progress), February 2000. [12] G. Montenegro, "Reverse Tunneling for Mobile IP", RFC 2344, May 1998. [13] Khalil, and et. al. Mobile IP Extensions Rationalization (MIER) draft-ietf-mobileip-mier-00.txt, Dec 1999. [14] TIA/EIA/IS-95-B [15] D. Plummer, "An Ethernet Address Resolution Protocol - or - Con- verting Network Protocol Addresses to 48.bit Ethernet Address for Transmission on Ethernet Hardware", RFC 826, Symbolics, Inc., November 1982. [16] Montenegro, G. and V. Gupta, "Sun's SKIP Firewall Traversal for Mobile IP", RFC 2356, June 1998. [17] P. Calhoun, C. Perkins, "Mobile IP Network Access Identifier Extension", RFC 2794, March 2000. Calhoun et al. expires February 2001 [Page 23] INTERNET DRAFT September 2000 [18] C. Perkins, P. Calhoun. Mobile IP Challenge/Response Exten- sions. draft-ietf-mobileip-challenge-13.txt, June 2000. 14.0 Acknowledgements The authors would like to thank Charles Perkins for his valuable feedback. 15.0 Authors' Addresses Questions about this memo can be directed to: Pat R. Calhoun Network and Security Research Center, Sun Labs Sun Microsystems, Inc. 15 Network Circle Menlo Park, California, 94025 USA Phone: +1 650 786 7733 Fax: +1 650 786 6445 E-mail: pcalhoun@eng.sun.com Tom Hiller Lucent Technologies Rm 2F-218 263 Shuman Blvd Naperville, IL 60566-7050 USA Phone: +1 630 979 7673 FAX: +1 630 979 7673 E-Mail: tom.hiller@lucent.com James Kempf Network and Security Research Center, Sun Labs Sun Microsystems, Inc. 15 Network Circle Menlo Park, California, 94025 USA Phone: +1 650 786 5890 Fax: +1 650 786 6445 E-mail: james.kempf@eng.sun.com Calhoun et al. expires February 2001 [Page 24] INTERNET DRAFT September 2000 Peter J. McCann Lucent Technologies Rm 2Z-305 263 Shuman Blvd Naperville, IL 60566-7050 USA Phone: +1 630 713 9359 FAX: +1 630 713 4982 E-Mail: mccap@lucent.com Chandana Pairla University of Illinois - Urbana Champaign 3315, DCL, 1304, W. Springfield Ave., Urbana, IL 61801 USA Phone: +1 217 244 7117 E-mail: pairla@uiuc.edu Sebastian Thalanany Motorola 1475 West Shure Drive Arlington Heights, IL - 60004 USA Phone: +1 847 435 9296 E-mail: sthalan1@email.mot.com Ajoy Singh Motorola 1501 West Shure Drive Arlington Heights, IL ô 60004 USA Phone: +1 847 632 6941 E-mail: asingh1@email.mot.com 16.0 Full Copyright Statement Copyright (C) The Internet Society (2000). 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 Calhoun et al. expires February 2001 [Page 25] INTERNET DRAFT September 2000 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 docu- ment 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 develop- ing 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 lim- ited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DIS- CLAIMS 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." Calhoun et al. expires February 2001 [Page 26]