Seamoby Working Group Rajeev Koodli INTERNET DRAFT Jari T. Malinen 13 July 2001 Communication Systems Laboratory Idle Mode Handover Support in IPv6 Networks draft-koodli-idle-mode-ctv6-00.txt Status of This Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at: http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at: http://www.ietf.org/shadow.html. This document is an individual submission for the mobile-ip 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 This document considers the problem of expediting authenticated network access as well as enabling authorized context transfer during idle-mode handovers. In essence, this document addresses idle-mode context transfers, so that an idle-mode Mobile Node (MN) can resume its sessions in a seamless fashion. We propose supplying the session key in the paging message to the Access Router (AR) that locates the idle Mobile Node. Subsequently, the AR issues a local challenge in the router advertisement, and the MN replies with a hash of session key, its previous IP address and the local challenge. The new AR grants network access once its own hash matches that supplied by the MN. We demonstrate how this simple procedure can be used for any generic context transfers. Koodli, Malinen Expires 13 January 2002 [Page i] Internet Draft Idle Mode Handover Support 13 July 2001 Contents Status of This Memo i Abstract i 1. Introduction 2 2. Terminology 3 3. Idle Handover Considerations 4 4. Protocol Messages 6 4.1. Key Distribution Extension to the Paging Message . . . . 6 4.2. Context Transfer Extension to the Paging Message . . . . 7 4.3. Router Advertisement with AAAv6 Local Challenge . . . . . 8 4.4. AAAv6 Request for Idle Mode Handover Support . . . . . . 10 4.5. AAAv6 Reply for Idle Mode Handover Support . . . . . . . 12 5. Protocol Constants 14 6. Security Considerations 14 Addresses 15 Koodli, Malinen Expires 13 January 2002 [Page 1] Internet Draft Idle Mode Handover Support 13 July 2001 1. Introduction When a MN powers up in a visited domain and obtains link connectivity with the network, a network policy may require that MN performs network layer authentication prior to obtaining IP connectivity. This is critical in order to provide a mechanism for the network provider to ensure unabused network access. The specification in [1] outlines a mechanism based on ICMP protocol that could be used in conjunction with other protocols, such as IPv6 address auto-configuration and Mobile IPv6, in order to provide this kind of network layer authentication. Provided the MN is authorized to access the network, this protocol then enables a security association between a MN and its default Access Router (AR) and supplies both the entities the necessary security keys. The MN then uses the supplied key in securing its communication, whenever necessary, with its AR. v +------------+ +-+ | Previous | ! ! ----------------- | Access | +-+ | Router(PAR)| MN | | | +------------+ | | | | IP Paging Message | | | V | ........................... | . . | . Paging area multicast . V . group . . . v +------------+ +------------+ +------------+ +-+ | New | | New | | New | | | -------| Access | | Access | | Access | +-+ | Router(NAR)| | Router(NAR)| | Router(NAR)| MN | | | | | | +------------+ +------------+ +------------+ Figure 1: Reference Scenario for Idle-Mode Handover Once authorized to use the network prefix advertised by the AR, the MN may proceed to send IP packets. For instance, the MN may send a Binding Koodli, Malinen Expires 13 January 2002 [Page 2] Internet Draft Idle Mode Handover Support 13 July 2001 Update to its Home Agent to inform about its new location. Note that for performance reasons, it is possible to combine the Binding Update with network authentication messages, as proposed in [1]. Here, we assume a logical separation between the two protocols. Nevertheless, the MN may then engage in active packet transmission and reception, or it may remain idle. Observe that the MN may establish feature contexts for its packet streams and then enter idle-mode. For example, the MN may establish QoS context for its `www' traffic, engage in active data communication, and then transition to idle state. Furthermore, the MN may enter idle mode even while engaged in active communication due to the bursty nature of packet data communication. Subsequently, the MN undergoes a handover while remaining in idle-mode. See Figure 1 The purpose of this document is to address the problem of expeditiously authenticating network access (for the MN) as well as authorizing feature contexts (to the MN) during idle-mode handovers. In essence, this document addresses idle-mode context transfers, so that an idle-mode Mobile Node (MN) can resume its sessions in a seamless fashion. We propose a solution using simple extensions to paging messages that would allow us to meet our objectives without the need for a dedicated paging server or additional entries in the routing tables. 2. Terminology Mobile Node A host that attaches to a network, untethered or otherwise, and changes its point of attachment due to host mobility. Idle mode A state internal to a Mobile Node in which the MN is not in active packet transmission or reception. This definition assumes that it is possible for a MN to enter idle mode, e.g., due to silence intervals, when it has an active traffic channel. Paging A mechanism by which a network locates a MN in idle mode, in order to, e.g., deliver an incoming packet [3]. (Access) Authentication The process by which an Access Router (AR) verifies the MN's credentials and grants (authorizes) network access [1]. Context Transfer The process by which state information pertaining to a MN is transferred from one AR to another, perhaps to facilitate seamless operation of applications running on the MN [6]. Koodli, Malinen Expires 13 January 2002 [Page 3] Internet Draft Idle Mode Handover Support 13 July 2001 3. Idle Handover Considerations We begin with a set of assumptions. First, we assume that each paging area is uniquely identified by an IP multicast group called ``all access router's multicast group'', whose members are the ARs that constitute the paging area. Second, a Mobile Node does not perform paging area registrations when inside the same paging area. The mechanisms by which a MN determines that it is within the boundary of the same paging area are beyond the scope of this document. It may make use of any known mechanism; for example, it may make use of the paging area identifier typically advertised on the broadcast channel to determine its location with respect to the paging area. Third, an AR originates an IP paging message when it determines that it cannot deliver an IP packet to its MN. The mechanism by which an AR determines that a MN that was attached to it is no longer visible is not specified in this document. An AR may be able to realize this by, for example, explicit idle mode registrations or (implicitly) via timer expirations. Note that because of this assumption, we see no reason for a specialized paging server in our discourse. Note also that there is no need for additional routing table entries in this model. Finally, we assume that all the members of the all access routers multicast group share security association with each other. We consider the two idle mode scenarios outlined earlier. We start with the case where the MN moves without having initiated active data communication. Recall that the MN first establishes network connectivity. This means, at the very least, the state corresponding to security association should be present at both the MN and its default AR. Now, let us assume that the MN moves to a subnet controlled by a different AR, yet within the same paging area. As mentioned earlier, we assume that the MN does not send a paging area registration message if operating within the same paging area. This assumption is necessary since a paging area registration may entitle the MN to IP connectivity, in which case, the routing of IP packets follows normal Mobile IP procedures. Now, if a packet arrives at the previous AR for the MN, the previous AR has to locate the MN in order to deliver the packet. We assume that an IP paging message would be available for this purpose. Whereas the exact form and nature of such a message is not standardized yet, we will assume the message outlined in [9], and identify extensions needed. In [9], the PAR uses a well-known multicast address, the ``all access routers multicast group'', to send the paging request, which we call the ``IP paging message''. All the ARs within the paging area are members of this multicast group, and thus receive the paging request packet. Each AR then sends an unsolicited router advertisement that contains the MN's IP address established while connected to PAR. This message may trigger Layer 2 (L2) paging, when present, on each AR in Koodli, Malinen Expires 13 January 2002 [Page 4] Internet Draft Idle Mode Handover Support 13 July 2001 order to wake up the sleeping MN. The MN, once paged, has to determine that it has changed its AR by verifying the source address in the router advertisement, begin to formulate a new IP address, and then respond to the IP paging request. When the MN wakes up and realizes that it has changed its AR, it may be required to perform network access authentication described earlier. This procedure is time-consuming given the delays in accessing the MN's home network AAA and the Home Agent. In order to minimize this delay, we propose to transfer the key from PAR to all the potential access routers which are members of the ``all access routers multicast group'' in the IP paging message. We assume that the MN first established authenticated network access with PAR. In the unsolicited router advertisement message that follows the IP paging message, each AR sends and caches a random number in a local challenge requiring the MN to return a token that is a hash of network prefix advertised, the random number in the local challenge and the key that the MN possesses. Each AR uses the key supplied in the IP paging message to compute its own hash and allows network access if the token supplied by the MN matches its computation. The MN uses the Embedded Data Option in the AAAv6 Request message in [1] to include this token as well as other information, such as the Binding Update message. When the AR receives the AAAv6 Request, it determines that the AAAv6 Request message corresponds to the unsolicited router advertisement (sent in response to the paging message) by inspecting the Embedded Data Option containing the above-mentioned hash. The above key transfer concept can indeed be applied to handle generic feature contexts. The MN's contexts at PAR are transferred gratuitously to all the ARs in the paging area multicast group. When the network policy requires explicit authorization of these contexts, each AR mandates that the MN presents a separate access authentication token such that the AR can verify authenticity of the feature context request. This token is generated according to HMAC-MD5-96 [7] using the random number advertised in the Local Challenge as an input parameter. The details of this token computation are specified in the description of Seamless Handover Initiate (SHIN) option [5]. We propose using the SHIN option as an embedded data in the AAAv6 request for explicit authorization of the feature context requests. The new AR verifies that the token present in the SHIN matches its own computation and makes the contexts available to the MN. It then generates a SHREQ message to the PAR that originated the IP paging message in order to set up a forwarding path for packets arriving at PAR. The PAR SHOULD generate a SHREP message indicating the response for the SHREQ message. The new AR MAY send a SHAK message indicating authorization of contexts to the MN. The MN SHOULD be prepared to handle packets treated with feature contexts without expecting a SHAK message. Koodli, Malinen Expires 13 January 2002 [Page 5] Internet Draft Idle Mode Handover Support 13 July 2001 Note that context transfer could happen reactively following paging. That is, the AR that locates the MN would initiate the transfer of contexts from the PAR in response to successfully authenticating the MN and (optionally) processing the SHIN option. In such a scenario, only the session key is transferred from the PAR to the members of the paging area. The net effect is that fewer bytes are sent in the access network since context transfer only happens between the AR that locates the MN and the PAR. 4. Protocol Messages In this section, we describe new protocol messages or options used in the protocol extensions described earlier. When paging occurs, a session key is passed along with the paging message. A paging message triggers a router advertisement which is required to contain a Local Challenge (LC) as in AAAv6. The router advertisement invokes the mobile node to perform a localized AAAv6 request and reply exchange with the AR. 4.1. Key Distribution Extension to the Paging Message We assume that a paging entity sends a paging message containing the IP address of the MN to a multicast group specific for the paging area. A paging message can be, e.g., a Paging Request Message as specified in [9]. Since the exact form of a Paging Message has not been standardized yet, we define a generic session key option which is shown in Figure 2. This option can be carried (with suitable padding whenever necessary) in an appropriate paging message. The receiving AR extracts the session key from this option, where the key is encrypted using pre-existing shared key between the originator of the paging message and the receiving access router. 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 | Alg | Key Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SPI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: Session Key Option Koodli, Malinen Expires 13 January 2002 [Page 6] Internet Draft Idle Mode Handover Support 13 July 2001 Type TBD (skippable), one for key request, one for key reply Length 8-bit unsigned integer. The length of the option (including the type and length fields) in units of 8 octets. Alg 8-bit algorithm indication as specified for the Authentication Header [4]. Key Length 8-bit unsigned integer. The length of the key in units of 4 octets. SPI 32-bit Security Parameter Index value. Key Encrypted key. 4.2. Context Transfer Extension to the Paging Message A paging entity may use this option to gratuitously supply the contexts established at PAR to all the members of the paging area. Such an action could provide performance benefits, since data communication typically follows paging. The option is shown in Figure 3. 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 | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + One or more feature contexts + | | ~ ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: Context Transfer Option Koodli, Malinen Expires 13 January 2002 [Page 7] Internet Draft Idle Mode Handover Support 13 July 2001 Type (skippable) Gratuitous Context Transfer. Length 8-bit unsigned integer. The length of the option (including the type and length fields) in units of 8 octets. As with the Session Key option, this option is also carried in an appropriate paging message. The AR that locates the MN then authorizes the use of received contexts after successfully processing the SHIN option from the MN. 4.3. Router Advertisement with AAAv6 Local Challenge The paging message is received by access routers in the paging area. A subsequent router advertisement message, described in this section, is sent out by each Access Router. The router advertisement as specified by Neighbor Discovery [8] is modified to include the local challenge as specified in [1]. The AR uses the value in local challenge in computing the access authentication token. The extension appears as a Router Advertisement option shown in 4. Koodli, Malinen Expires 13 January 2002 [Page 8] Internet Draft Idle Mode Handover Support 13 July 2001 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ {1}| Router Advertisement Options | | . . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ {2}| Type | Length | Sequence no | Rsvd | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Challenge | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: Router Advertisement with AAAv6 local challenge {1} Router Advertisement Options A paging option contains the IP address of the paged MN. It is possible to send a page to a group of dormant mobiles by associating a multicast address with that group. In such a case, this option includes the IP addresses of all the paged mobiles. May also include target Link-layer address, Prefix Information Options, etc. {2} AAAv6 Challenge Option in the router advertisement Type 9 = ICMPv6 Router Advertisement Local Challenge Option Length 1 = Length in 8 octets including the type and length fields Sequence Number a monotonically increasing integer that associates the IP address, Challenge and the Key tuple. The MN supplies this value in addition to the hash it generates to aid the AR in verifying the checksum computation. Reserved 0 = Ignored on reception Challenge This is a 32-bit random number generated by the access router and used to prevent replay attacks. Koodli, Malinen Expires 13 January 2002 [Page 9] Internet Draft Idle Mode Handover Support 13 July 2001 4.4. AAAv6 Request for Idle Mode Handover Support This section describes the message the mobile node sends in response to the paging router advertisement which contains an AAAv6 local challenge. This response includes a token to facilitate expedited network access authentication and also request for context transfer authorization. The message the MN sends is an ICMPv6 message of AAAv6 request type. This AAAv6 message contains one or more Embedded Data Options. Each Embedded Data Option (EDO) may contain sub types for various purposes. The two new sub types used by this extension are the access authentication token and Seamless Handover Initiate (SHIN). The SHIN subtype is optional if the network policy allows context authorization based only on network access authentication. The access authentication token contains a hash over mobile node's previous IP address and the challenge sent in the router advertisement. Since the paging message from the paging router to the access routers distributes the key known to the MN and the paging router, this key is now known by the new router which can verify whether the hash received is valid. If not, the packet is dropped and a diagnostics AAAv6 reply with status AAAV6_INVALID_CREDENTIALS in the Code field is returned. Koodli, Malinen Expires 13 January 2002 [Page 10] Internet Draft Idle Mode Handover Support 13 July 2001 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ {1}| | | IPv6 Header... | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ {2}|Type=AAAv6req | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (AAAv6 Request Options) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ {3}| Type=EDO |Subtype=AAToken| Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Network Access Authentication Hash | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ {4}| Type=EDO |Subtype=SHIN | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ SHIN (optional) ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5: AAAv6 request for Idle Mode Handover Support {1} IPv6 Header SRC = MN's new IP address; DEST = AAAv6 Attendant; NxtHDR = 58 (ICMPv6) {2} ICMPv6 Header [2] Type 151 (97h) [TBD] = AAAv6 Request Code 0 - For AAA request, not defined Checksum Calculated as defined in [2]. Koodli, Malinen Expires 13 January 2002 [Page 11] Internet Draft Idle Mode Handover Support 13 July 2001 {3} AAAv6 Embedded Data Option [1] for access authentication Type 8 (unskippable) = Embedded Data Option Subtype 5 = AAToken Length 4 = Length of Network Access Authentication Hash in octets. Network Access Authentication Hash A 16-byte result of a pseudo-random function, such as HMAC-MD5-96, computed over the identity-providing old CoA, freshness-providing random number (LC), and the session key. {4} AAAv6 Embedded Data Option [1] for SHIN Type 8 (unskippable) = Embedded Data Option Subtype 6 = SHIN Length 4 = Length of SHIN in octets. SHIN Seamless Handover Initiate message. 4.5. AAAv6 Reply for Idle Mode Handover Support In this section, we provide the extended AAAv6 reply to the AAAv6 request for idle mode context transfer support. Note that the request for context transfer was embedded to an EDO containing the SHIN message. Here a similar new and optional EDO contains the optional SHAK. {1} IPv6 Header Koodli, Malinen Expires 13 January 2002 [Page 12] Internet Draft Idle Mode Handover Support 13 July 2001 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ {1}| | | IPv6 Header... | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ {2}|Type=AAAv6req | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (AAAv6 Reply Options) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ {3}| Type=EDO |Subtype=SHAK | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ SHAK (optional) ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6: AAAv6 reply for Idle Mode Handover Support SRC = AAAv6 Attendant; DEST = mobile node; NxtHDR = 58 (ICMPv6) {2} ICMPv6 Header [2] Type [TBD] = AAAv6 Reply Code The success code for AAAv6 Reply. Checksum Calculated as defined in [2]. {3} AAAv6 Embedded Data Option [1] for SHAK Type 8 (unskippable) = Embedded Data Option Koodli, Malinen Expires 13 January 2002 [Page 13] Internet Draft Idle Mode Handover Support 13 July 2001 Subtype 7 = SHAK Length Length of SHAK in octets. SHAK Seamless Handover Acknowledgment. 5. Protocol Constants Three new sub-types for AAAv6 Embedded Data Option are needed, one for access authentication token, and one for SHIN, and SHAK options, respectively. 6. Security Considerations This protocol assumes that when the mobile node arrives at a visited domain, it performs a secure initial registration, after which there is a mobile-visited domain session key in both the mobile node and the first visited-domain router. Also, there is a pre-existing common security association between all nodes in a paging area multicast group. Using the assumed associations, the paging causes the session key to be provided to the new access router which can use it to verify both authenticity of the received AAAv6 request as well as the authorization token present in the SHIN message. These mechanisms used together with AAAv6 provide authorized idle mode context transfers. Koodli, Malinen Expires 13 January 2002 [Page 14] Internet Draft Idle Mode Handover Support 13 July 2001 References [1] N. Asokan, Patrik Flykt, C. Perkins, and Thomas Eklund. AAA for IPv6 Network Access (work in progress). Internet Draft, Internet Engineering Task Force, March 2000. [2] A. Conta and S. Deering. Internet Control Message Protocol (ICMPv6) for the Internet protocol version 6 (ipv6) specification. Request for Comments (Draft Standard) 2463, Internet Engineering Task Force, December 1998. [3] J. Kempf. Dormant mode host alerting (ip paging) problem statement. Request for Comments (Informational) 3132, Internet Engineering Task Force, June 2001. [4] S. Kent and R. Atkinson. IP Authentication Header. Request for Comments (Proposed Standard) 2402, Internet Engineering Task Force, November 1998. [5] R. Koodli, , and C. Perkins. A context transfer framework for seamless mobility (work in progress). Internet Draft, Internet Engineering Task Force, July 2000. [6] et al. Levkowetz, O. H. Problem description: Reasons for performing context transfers between nodes in an ip access network (work in progress). Internet Draft, Internet Engineering Task Force, June 2001. [7] C. Madson and R. Glenn. The Use of HMAC-MD5-96 within ESP and AH. Request for Comments (Proposed Standard) 2403, Internet Engineering Task Force, November 1998. [8] T. Narten, E. Nordmark, and W. Simpson. Neighbor Discovery for IP Version 6 (ipv6). Request for Comments (Draft Standard) 2461, Internet Engineering Task Force, December 1998. [9] B. Sarikaya, J. Haverinen, H.and Malinen, and V. Magret. Mobile ipv6 regional paging (work in progress). Internet Draft, Internet Engineering Task Force, November 2000. Addresses Questions about this memo can also be directed to the authors: Koodli, Malinen Expires 13 January 2002 [Page 15] Internet Draft Idle Mode Handover Support 13 July 2001 Rajeev Koodli Jari T. Malinen Communications Systems Lab Communications Systems Lab Nokia Research Center Nokia Research Center 313 Fairchild Drive 313 Fairchild Drive Mountain View, California 94043 Mountain View, California 94043 USA USA Phone: +1-650 625-2359 Phone: +1-650 625-2355 EMail: rajeev.koodli@nokia.com EMail: jmalinen@iprg.nokia.com Fax: +1 650 625-2502 Fax: +1 650 625-2502 Koodli, Malinen Expires 13 January 2002 [Page 16]