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-ietf-koodli-smoothv6-00.txt Status of This Memo This document is a submission by the mobile-ip Working Group of the Internet Engineering Task Force (IETF). Comments should be submitted to the MOBILE-IP@STANDARDS.NORTELNETWORKS.COM mailing list. Distribution of this memo is unlimited. This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at: http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at: http://www.ietf.org/shadow.html. Abstract 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 the Binding Update Destination Option to carry 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. Contents Status of This Memo 1 Abstract 1 K1.oIntroductionodli, Perkins Expires 13 January 2001 1 [Page 1] 2. Overview 2 3. Smooth Handover Initiate (SHIN) Destination Option 5 4. Smooth Handover Request Message (SHREQ) 7 5. Smooth Handover Reply (SHREP) Message 9 6. Smooth Handover Acknowledgement Message 10 7. NCMA Hand-over 10 8. Configurable Parameters 13 9. Security Considerations 13 10. IANA Considerations 13 Addresses 14 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 Internet Draft Smooth Handovers with Mobile IPv6 13 July 2000 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 [2]. 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 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 "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. 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 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 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. We specify that Router Advertisement messages 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 flag in the Router Advertisement message. The representation and use of such a flag 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). We specify that the Binding Update is carried along with a Smooth Handover INitiate (SHIN) that is delivered to the default router (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 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 Koodli, Perkins Expires 13 January 2001 [Page 3] Internet Draft Smooth Handovers with Mobile IPv6 13 July 2000 +--------------------------------------------------------------+ | IPv6 header | SHIN option | IPv6 header | Binding Update | +--------------------------------------------------------------+ Figure 2: Overall Message Structure for Smooth Handover Initiate Message encapsulated with a new IPv6 header, and the new handover option is placed in front of the encapsulated Binding Request. 1. SHIN Destination Options hdr 2. Suboptions for new router 3. Suboptions for use by both new and previous router 4. Suboptions for previous router Figure 3: Suboptions Structure for SHIN Destination Option The structure for suboptions to the SHIN Destination Option is shown in figure 3. Suboptions sent by the mobile node for processing by the New-Router only are inserted first. Suboptions meant for both the New-Router and the Previous-Router are listed next. Finally, suboptions for the Previous-Router only are listed at the end. The structure and relative order of sub-options is further described in Sections 3 - 6. 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. We consider two general cases: assisted handover and un-assisted handover. In "assisted" handover, the MN detects that a new link Koodli, Perkins Expires 13 January 2001 [Page 4] Internet Draft Smooth Handovers with Mobile IPv6 13 July 2000 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 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 MAY first authenticate the New-Router prior to checking the authenticity of the 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 Destination Address The global IP address of the New-Router Option Type Smooth Handover Initiate (SHIN) 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 4: Smooth Handover Initiate Destination Option Format 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. 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) Koodli, Perkins Expires 13 January 2001 [Page 6] Internet Draft Smooth Handovers with Mobile IPv6 13 July 2000 Source address The New CoA of the MN Destination Address The global IP address of the Home Agent/Regional Mobility Agent 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 [1] for details) roughly as follows: HMAC (Key, Data) = MD5 (Key, MD5 (Key || Data)) and MD5 is defined as given in RFC 1321 [3]. The input_data is defined as follows: input_data = HO_features || Replay || Old_Care-of_Address 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, the previous router is likely to tear down context associated with the mobile node as soon as it transfers the state to the New-Router. An implicit Lifetime with this context is defined to be xx seconds. A specific feature may request this Lifetime to be a suitable, non-zero value. 4. Smooth Handover Request Message (SHREQ) The Smooth Handover Request (SHREQ) message, illustrated in figure 5, is sent from the New-Router to the Previous-Router to request that any 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. IP fields: Source address The global IP address of the New-Router Destination Address The global IP address of the Previous-Router Option Type Smooth Handover Request (SHREQ) Option Length Variable Koodli, Perkins Expires 13 January 2001 [Page 7] 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 = NONE | Hdr Ext Len | Op-Type=SHREQ | Option Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 128-bit New Care-of Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 128-bit Previous Care-of Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |SOType=AuthPrtr| Sub-Option Len| Reserved | Replay | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 32-bit Authentication Data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-options feature data for Prtr only from MN +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-options feature data for Nrtr and Prtr from MN +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-options feature data for Prtr only from Nrtr +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5: Smooth Handover Request Message Format 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. Koodli, Perkins Expires 13 January 2001 [Page 8] Internet Draft Smooth Handovers with Mobile IPv6 13 July 2000 5. Smooth Handover Reply (SHREP) Message The Smooth Handover Reply (SHREP) message, illustrated in figure 6, is sent from the Previous-Router to the New-Router to furnish all the 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 6: Smooth Handover Reply Message Format 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. Koodli, Perkins Expires 13 January 2001 [Page 9] Internet Draft Smooth Handovers with Mobile IPv6 13 July 2000 6. Smooth Handover Acknowledgement Message The Smooth Handover Acknowledgement (SHACK) message, illustrated in figure 7, 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 7: Smooth Handover RePly Message Format 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. The format of Smooth Handover Push (SHPSH) message is shown in Figure 8. The New-Router MAY respond back with Smooth Handover Push Acknowledgement (SHPAK) is shown in Figure 9. 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 Push (SHPSH) Koodli, Perkins Expires 13 January 2001 [Page 10] 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 = NONE | Hdr Ext Len | Op-Type=SHPSH | Option Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 128-bit Previous Care-of Address of MN | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-options features data for Nrtr +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 8: Smooth Handover Push Message Format Option Length Variable Suboptions Feature suboptions "default" data. 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=SHPAK | Option Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 128-bit Previous Care-of Address of MN | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-options response from Nrtr +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 9: Smooth Handover Push Acknowledgement Message Format IP fields Source address The global IP address of the New-Router. Destination Address The global IP address of the Previous-Router. Koodli, Perkins Expires 13 January 2001 [Page 11] Internet Draft Smooth Handovers with Mobile IPv6 13 July 2000 Option Type Smooth Handover Push Acknowledgement (SHPAK) Option Length Variable Suboptions Feature-specific response codes for individual sub-options present in the SHPSH message. Koodli, Perkins Expires 13 January 2001 [Page 12] 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 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 4), 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. IANA Considerations TBD. References [1] H. Krawczyk, M. Bellare, and R. Canetti. HMAC: Keyed-Hashing for Message Authentication. Request for Comments (Informational) 2104, Internet Engineering Task Force, February 1997. Koodli, Perkins Expires 13 January 2001 [Page 13] Internet Draft Smooth Handovers with Mobile IPv6 13 July 2000 [2] C. E. Perkins and D. Johnson. Route Optimization in Mobile IP (work in progress). draft-ietf-mobileip-optim-09.txt, February 2000. [3] 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: 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]