Mobile IP Working Group Rajeev Koodli INTERNET DRAFT Charles E. Perkins 13 July 2000 Communication Systems Laboratory Nokia Research Center A Framework for Smooth Handovers with Mobile IPv6 draft-koodli-mobileip-smoothv6-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 MOBILE-IP@STANDARDS.NORTELNETWORKS.COM mailing list. Distribution of this memo is unlimited. Abstract During handover from one access router to another, a wireless mobile node may need to have a certain amount of state information passed from the Previous-Router to the new one. This document specifies extensions to Mobile IPv6 which allow additional control structures enabling the transfer of the necessary state during handovers. This state transfer allows the applications running on the mobile node to operate with reduced latency, minimal disruption, and reduced packet loss during handovers. Koodli, Perkins Expires 13 January 2001 [Page i] Internet Draft Smooth Handovers with Mobile IPv6 13 July 2000 Contents Status of This Memo i Abstract i 1. Introduction 2 2. Overview 2 3. Smooth Handover Initiate (SHIN) Destination Option 5 4. Smooth Handover Request Message (SHREQ) 8 5. Smooth Handover Reply (SHREP) Message 9 6. Smooth Handover Acknowledgement (SHACK) Message 10 7. NCMA Hand-over 11 8. Configurable Parameters 12 9. Security Considerations 12 10. Acknowledgements 12 Addresses 13 Koodli, Perkins Expires 13 January 2001 [Page 1] Internet Draft Smooth Handovers with Mobile IPv6 13 July 2000 1. Introduction With the advent of real-time applications such as VoIP, it has become extremely important to address efficient handovers in Mobile IP. When a Mobile Node (MN) running a real-time application undergoes hand-over, the hand-over not only needs to be fast, it also needs to support such features as state transfer (e.g., for header compression state relocation) and buffer management (in order to reduce packet loss for glitch-free operation). For this, enhancements to Mobile IP are needed. This document proposes a framework using Mobile IP that facilitates "smooth" hand-overs with reduced latency, packet loss, and allows a MN to operate with minimal disruption. We assume IPv6 in our presentation here. Applicability of the proposed scheme for IPv4 is out of scope of this specification, but might be done in a very similar way using some newly specified extensions to be associated with the proposed Previous Foreign Agent Notification extension [5]. 2. Overview Handover operations are complicated by the possible existence of a substantial amount of state information associated with the mobile node while it is attached to the local network links. When the mobile node moves to a new point of attachment, it is likely (depending upon the specific feature) that some or all of the state associated with the mobile node for that feature will have to be transferred to the mobility agent (i.e., the router) serving the mobile node's new point of attachment. In this document, we specify common protocol structures that are intended to handle all such context handover requirements. Other documents are needed to specify the specific protocol structures to be used for handling the context information associated with specific features such as header compression, buffering, regional registration, or Quality of Service. We consider the scenario shown in Figure 1 as the basis for our discussion. In Figure 1, a MN undergoes hand-over to a New-Router (Nrtr) from a Previous-Router (Prtr). As a result of hand-over, the MN requests transfer of information, both control state and data packets, from the Previous-Router to the New-Router. Broadly speaking, we classify hand-over scenarios into two cases. In a "Network-Controlled, Mobile-Assisted" (NCMA) scenario, some entity within the local network domain determines, and hence knows, which router the MN will get attached to next due to handover. In this case, the Previous-Router serving the mobile node can potentially set up the required state at the New-Router almost as soon as (or even before) a new link is established for the MN. Koodli, Perkins Expires 13 January 2001 [Page 2] Internet Draft Smooth Handovers with Mobile IPv6 13 July 2000 | MN +-----------+ +-+ | Previous | < | | ---------- | Router | ------ > ----\ +-+ | (Prtr) | < \ | | \ | +-----------+ +--------+ | ^ IP | Corr. | | | Network | Node | V | +--------+ v / | MN +-----------+ / +-+ | New | < / | | ---------- | Router | ------ > ----/ +-+ | (Nrtr) | < | | +-----------+ Figure 1: Reference Scenario for Hand-over In the "Mobile-Controlled, Network-(un)Assisted" (MCNA) scenario however, some mobile-aware entity in the local domain may notify the MN's IP layer about an impending handover, so that the MN may prepare to send Mobile IP(v6) messages right away. However, beyond this generic notification, no other function is initiated regarding state transfer. It is also possible that no indication of an impending handover is detected by the IP layer in the MN. In both of these cases, the MN performs necessary signaling for state transfer. The first action after a mobile node moves to a new point of IPv6 attachment will be Neighbor Discovery [4]. To enable the effective use of SHIN messages by the mobile node, the Router Advertisement messages SHOULD carry information to guide the mobile node in its selection of handover features. Since there are multiple features that may be in use, each feature may be represented by using an appropriate data structure in the Router Advertisement message. The representation and use of such data structures is feature dependent and is beyond the scope of this framework document. After configuring a new Care-of Address, a mobile node using Mobile IPv6 has to send a Binding Update to its home agent (or perhaps a nearer regional mobility agent). The Binding Update is carried along with a Smooth Handover INitiate (SHIN) that is delivered to the default router Koodli, Perkins Expires 13 January 2001 [Page 3] Internet Draft Smooth Handovers with Mobile IPv6 13 July 2000 (New-Router in Figure 1). The smooth handover request resides in a Destination Option that contains suboptions for each desired feature. The following figure shows the overall message structure: In the +--------------------------------------------------------------+ | IPv6 header | SHIN option | IPv6 header | Binding Update | +--------------------------------------------------------------+ Figure 2: Overall Message Structure for Smooth Handover Initiate Message figure, SHIN is a new destination option with suboptions for each feature type. The Binding Update packet, addressed to the mobility agent which maintains the care-of address of the mobile node, is encapsulated with a new IPv6 header, and the new handover option is placed in front of the encapsulated Binding Request. The structure for suboptions to the SHIN Destination Option is as follows: 1. SHIN Destination Options hdr 2. Suboptions for new router 3. Suboptions for use by both new and previous router 4. Authentication data 5. Suboptions for previous router The encapsulating header is addressed to the New-Router, which then takes charge of transferring context associated with the mobile node from the previous point of attachment to the mobile node's new point of attachment. This requires new messages to be sent between the two routers. The content of these messages depends upon the particular suboptions of the SHIN Destination Option as selected by the mobile node. In this document, we specify the SHIN Destination Option and some generally useful suboptions. Other suboptions, useful only in the context of specific features, are specified in other documents. We start with the MCNA case first. Koodli, Perkins Expires 13 January 2001 [Page 4] Internet Draft Smooth Handovers with Mobile IPv6 13 July 2000 We consider two general cases: assisted handover and un-assisted handover. In "assisted" handover, the MN detects that a new link layer with a different network prefix is available. In this assisted case, the MN sends an unsolicited Router Solicitation message, receives a Router Advertisement message, and then sends a combined Smooth Handover Initiate and Binding Update message shown in Figure 2. In the un-assisted case, the MN learns that it has undergone handover when it receives a new Router Advertisement message, and it simply sends a combined Smooth Hand-over Initiate and BU message shown in Figure 2. When the New-Router receives a Smooth Handover Initiate (SHIN) destination option (as described in section 3), it identifies the suboptions within the SHIN and constructs a new message for the Previous-Router which requests the context handover. This message, called the Smooth Handover Request (SHREQ) message, MAY use appropriate security protection and is described in section 4. The New-Router then decapsulates the Binding Update packet and transmits it to the intended recipient. When the Previous-Router receives the SHREQ message (see section 4), it MUST check to see whether it has a security association with the New Router. If so, the Previous Router MUST check for the presence and validity of an IPv6 Authentication Option [2]. Then the Previous Router MUST check for the presence and validity of the SHREQ Authentication Suboption data supplied by the mobile node to make sure that the handover has been authorized by the mobile node. This verification is done as part of processing the destination option which includes the sub-option supplied by the mobile node to the Previous-Router. The Previous-Router then formulates a Smooth Handover Reply (SHREP) message and begins to insert appropriate structures into the message for the context transfer. It is important that context for the mobile node be not destroyed at the Previous-Router without authorization. After gathering all the requested state for the smooth handover, and sending it to the New-Router in the SHREP message, the Previous-Router has to keep the context data for the mobile node intact for CONTEXT_SAVE_TIME in order to allow recovery in case a SHREP message is lost and not received by the router sending the SHREQ message. 3. Smooth Handover Initiate (SHIN) Destination Option The Smooth Handover Initiate destination option is an envelope for containing suboptions, prefixed by some fields that are generally expected to be useful for all suboptions. IP fields (in encapsulating header): Source address The New CoA of the MN Koodli, Perkins Expires 13 January 2001 [Page 5] Internet Draft Smooth Handovers with Mobile IPv6 13 July 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 Header (NH = DestOpts) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NH = IPv6 | Hdr Ext Len | Op-Type=SHIN | Option Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 128-bit Previous Care-of Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 128-bit Previous Router Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Sub-Option Type| Sub-Option Len| Feature Data for Nrtr only +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Sub-Option Type| Sub-Option Len| Feature Data for Nrtr + Prtr +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |SOType=AuthPrtr| Sub-Option Len| Reserved | Replay | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 32-bit Authentication Data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Sub-Option Type| Sub-Option Len| Feature Data for Prtr only +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 Header (NH = DestOpts) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NH = NONE | Binding Update to HA/Regional Mobility Agent | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: Smooth Handover Initiate Destination Option Format Destination Address The global IP address of the New-Router Option Type Smooth Handover Initiate (SHIN) Option Length Variable Reserved Reserved for future use. Must be set to zero by the MN. Replay A value used to make sure that each use of the Smooth Handover Initiate destination option is uniquely identifiable. Koodli, Perkins Expires 13 January 2001 [Page 6] Internet Draft Smooth Handovers with Mobile IPv6 13 July 2000 Authentication Data An unforgeable value calculated as discussed below. Suboptions Feature suboptions included as selected by the mobile node, in the order specified. IP fields (in encapsulated header) Source address The New CoA of the MN Destination Address The global IP address of the mobility agent to which the mobile node wished the Binding Update to be delivered. In order to make sure that context cannot be lost at the previous router in response to a erroneous action or malicious not initiated by the mobile node, authentication is required for the handover request. The Authentication Data (Auth) is calculated as follows: Auth = HMAC (Key, input_data) mod 2^32 where HMAC (Key, Data) is defined (see RFC 2104 [3] for details) roughly as follows: HMAC (Key, Data) = MD5 (Key, MD5 (Key || Data)) and MD5 is defined as given in RFC 1321 [6]. The input_data is defined as follows: input_data = HO_features || Replay || Previous_Care-of_Address where HO_features includes all the sub-option data from the MN to the Previous-Router. If a mobile node uses the same features and Previous_Care-of_Address more than 255 times, then the mobile node SHOULD establish a new security association with the Previous-Router (i.e., the mobile node's default router at the Previous Care-of Address). When the mobile node requests smooth handover features, it also implicitly requests that the Previous Router establish a binding cache entry for the mobile node at the new Care-of Address given in the SHREQ message. This binding cache entry is used to tunnel incoming packets to the New Router, as specified in [1]. By default, this binding cache has Lifetime equal to be HO_BINDING_LIFE. At the end of the binding lifetime, in addition to deleting the binding cache entry giving the mobile node's new Care-of Address, the Previous Router SHOULD tear down all existing connection context associated with the mobile node. A specific feature MAY request a different value for specific feature context lifetime. Koodli, Perkins Expires 13 January 2001 [Page 7] Internet Draft Smooth Handovers with Mobile IPv6 13 July 2000 4. Smooth Handover Request Message (SHREQ) The Smooth Handover Request (SHREQ) message, illustrated in figure 4, is sent from the New-Router to the Previous-Router to request that some feature context associated with the mobile node at the Previous-Router be sent to the New-Router as part of a smooth handover. The destination option contains sub-options prefixed by the New and Previous Care-of Addresses of the MN. The New-Router MUST copy the sub-options supplied by the MN (in the SHIN message) exclusively for the Previous-Router verbatim starting from the sub- option type AuthPrtr. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 Header (NH = DestOpts) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NH = NONE | Hdr Ext Len | Op-Type=SHREQ | Option Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 128-bit New Care-of Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 128-bit Previous Care-of Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-options feature data for Prtr only from MN +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-options feature data for Nrtr and Prtr from MN +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |SOType=AuthPrtr| Sub-Option Len| Reserved | Replay | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 32-bit Authentication Data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-options feature data for Prtr only from Nrtr +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: Smooth Handover Request Message Format IP fields: Source address The IP address of the New-Router Destination Address The IP address of the Previous-Router Option Type Smooth Handover Request (SHREQ) Option Length Variable Koodli, Perkins Expires 13 January 2001 [Page 8] Internet Draft Smooth Handovers with Mobile IPv6 13 July 2000 Reserved Reserved for future use, set to zero by the MN. Replay A value used to make sure that each use of the Smooth Handover Initiate destination option is uniquely identifiable. Authentication Data An unforgeable value calculated as discussed above. Suboptions Feature suboptions included as selected by the mobile node and the New- Router, in the order specified. If a router transmits a SHREQ message, and does not receive a SHREP message within SHREQ_REXMIT_TIME, the router SHOULD retransmit the SHREQ message. This retransmission should be attempted until SHREQ_RETRIES is exceeded. 5. Smooth Handover Reply (SHREP) Message The Smooth Handover Reply (SHREP) message, illustrated in figure 5, is sent from the Previous-Router to the New-Router to furnish feature context data associated with the mobile node as part of a smooth handover. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 Header (NH = DestOpts) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NH = NONE | Hdr Ext Len | Op-Type=SHREP | Option Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 128-bit New Care-of Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 128-bit Previous Care-of Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-options for Nrtr only +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-options for Nrtr and MN +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-options for MN only +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5: Smooth Handover Reply Message Format Koodli, Perkins Expires 13 January 2001 [Page 9] Internet Draft Smooth Handovers with Mobile IPv6 13 July 2000 IP fields Source address The global IP address of the Previous-Router. Destination Address The global IP address of the New-Router. Option Type Smooth Handover Reply (SHREP) Option Length Variable Suboptions Feature suboptions data appropriate for each sub-option present in the SHREQ message in the order specified. 6. Smooth Handover Acknowledgement (SHACK) Message The Smooth Handover Acknowledgement (SHACK) message, illustrated in figure 6, MAY be sent from the New-Router to the mobile node in some cases, to inform the mobile node about the status of its smooth handover request. The acknowledgment may contain multiple separate status reports for each relevant feature that was requested. However, unless a failure has occurred, or else unless required by a specific feature, the SHACK message is optional. The mobile node MUST be prepared to process a SHACK message even when no error has occurred. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 Header (NH = DestOpts) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NH = NONE | Hdr Ext Len | Op-Type=SHACK | Option Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-options response from Nrtr and Prtr +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-options response from Prtr only +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6: Smooth Handover Reply Message Format Koodli, Perkins Expires 13 January 2001 [Page 10] Internet Draft Smooth Handovers with Mobile IPv6 13 July 2000 7. NCMA Hand-over In this type of hand-over, the Previous-Router proactively pushes state information to the New-Router. This could improve performance when the MN sends SHIN message as before, since the state would already be available at the New-Router. For this purpose, the Previous Router uses the SHREP message, with all suboptions inserted just as for the MCNA case. In order for this operation to be secure the Previous Router MUST have a security association with the New Router, and it MUST include an IPv6 Authentication Header in the unsolicited SHREP message. Otherwise, the SHREP message is just as described in section 5, except that the New Care-of Address is set to zero. When the New Router receives a SHREP, it MUST check for the presence and validity of an IPv6 Authentication Header using the security association it has with the Previous Router. It will be able to characterize the message as an unsolicited SHREP, because the New Care-of Address will be zero. When the New Router receives a valid unsolicited SHREP message, it MUST buffer the message for at least GRAT_SHREP_TIME, or until it receives the corresponding SHIN message from the mobile node whichever event occurs first. When the mobile node sends a SHIN to a New Router that has received an unsolicited SHREP from the Previous Router, the New Router can immediately complete all necessary context transfers for the smooth handover. If the New Router receives an unsolicited SHREP message for a smooth handover which has already been initiated by a Mobile Node, it SHOULD silently discard the unsolicited SHREP. The New Router will most likely already have sent a SHREQ message to the Previous Router requesting the context transfer which was indicated in the unsolicited SHREP. Koodli, Perkins Expires 13 January 2001 [Page 11] Internet Draft Smooth Handovers with Mobile IPv6 13 July 2000 8. Configurable Parameters Every Mobile IP agent supporting the extensions defined in this document SHOULD be able to configure each parameter in the following table. Each table entry contains the name of the parameter, the default value, and the section of the document in which the parameter first appears. Parameter Name Default Value ------------------- ------------- SHREQ_RETRIES 3 SHREQ_REXMIT_TIME 1 seconds CONTEXT_SAVE_TIME 2 * SHREQ_REXMIT_TIME HO_BINDING_LIFE 5 seconds 9. Security Considerations According to this specification, the New-Router transmits the encapsulated Binding Update immediately upon receipt from the mobile node. This typically enables a higher grade of service for the generally honest user at the cost of only a tiny and short-lived additional vulnerability to malicious use. Since authentication data is supplied by the mobile node along with its smooth handover requests, there is substantially no danger of loss of handover context due to malicious attacks. However, if the mobile node fails to change its security association with the Previous-Router (as specified in section 3), an attacker could keep track of all 256 available replay protection values and cause a future disconnection the next time the mobile node acquires the same care-of address at the same Previous-Router. The Previous-Router and the New-Router MAY use authentication for the SHREQ and SHREP messages depending on their security association. 10. Acknowledgements The authors wish to thank Robert Chalmers, Hannu Flinck, Govind Krishnamurthi, Jari Malinen and Manish Tiwari for discussion and review of this document. Koodli, Perkins Expires 13 January 2001 [Page 12] Internet Draft Smooth Handovers with Mobile IPv6 13 July 2000 References [1] D. Johnson and C. Perkins. Mobility Support in IPv6 (work in progress). draft-ietf-mobileip-ipv6-12.txt, April 2000. [2] S. Kent and R. Atkinson. IP Authentication Header. Request for Comments (Proposed Standard) 2402, Internet Engineering Task Force, November 1998. [3] H. Krawczyk, M. Bellare, and R. Canetti. HMAC: Keyed-Hashing for Message Authentication. Request for Comments (Informational) 2104, Internet Engineering Task Force, February 1997. [4] 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. [5] C. E. Perkins and D. Johnson. Route Optimization in Mobile IP (work in progress). draft-ietf-mobileip-optim-09.txt, February 2000. [6] R. Rivest. The MD5 Message-Digest Algorithm. Request for Comments (Informational) 1321, Internet Engineering Task Force, April 1992. Addresses The working group can be contacted via the current chairs: Basavaraj Patil Phil Roberts Nokia Corporation Motorola 6000 Connection Drive 1501 West Shure Drive M/S M8-540 Irving, Texas 75039 Arlington Heights, IL 60004 USA USA Phone: +1 972-894-6709 Phone: +1 847-632-3148 Fax : +1 972-894-5349 EMail: Basavaraj.Patil@nokia.com EMail: QA3445@email.mot.com Questions about this memo can also be directed to the authors: Koodli, Perkins Expires 13 January 2001 [Page 13] Internet Draft Smooth Handovers with Mobile IPv6 13 July 2000 Rajeev Koodli Charles E. Perkins 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-2986 EMail: rajeev.koodli@nokia.com EMail: charliep@iprg.nokia.com Fax: +1 650 625-2502 Fax: +1 650 625-2502 Koodli, Perkins Expires 13 January 2001 [Page 14]