idnits 2.17.1 draft-designteam-fast-mipv6-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document is more than 15 pages and seems to lack a Table of Contents. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of too long lines in the document, the longest one being 2 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 183: '... The oldAR MUST wait for a Binding U...' RFC 2119 keyword, line 191: '... oldAR MUST wait for a Binding Updat...' RFC 2119 keyword, line 323: '...irming the handover. This BU SHOULD be...' RFC 2119 keyword, line 326: '... possible the BU MUST be sent after th...' RFC 2119 keyword, line 327: '... The oldAR MUST then send a BACK mes...' (62 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 1027 has weird spacing: '...uration is u...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 2001) is 8314 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'ICMPv6' is mentioned on line 839, but not defined == Unused Reference: 'ASSNUM' is defined on line 1100, but no explicit reference was found in the text == Unused Reference: 'EUI' is defined on line 1107, but no explicit reference was found in the text == Unused Reference: 'IMSI' is defined on line 1111, but no explicit reference was found in the text == Unused Reference: 'MAC' is defined on line 1113, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1700 (ref. 'ASSNUM') (Obsoleted by RFC 3232) ** Obsolete normative reference: RFC 2462 (ref. 'AUTO') (Obsoleted by RFC 4862) == Outdated reference: A later version (-07) exists of draft-ietf-mobileip-mier-05 == Outdated reference: A later version (-24) exists of draft-ietf-mobileip-ipv6-12 ** Obsolete normative reference: RFC 2461 (ref. 'ND') (Obsoleted by RFC 4861) Summary: 10 errors (**), 0 flaws (~~), 8 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Personal G. Tsirtsis 2 Editor 3 A. Yegin 4 C. Perkins 5 G. Dommety 6 K. El-Malki 7 M. Khalil 8 Internet Draft 9 Title: draft-designteam-fast-mipv6-01.txt 10 Category: Informational February 2001 11 Expires : July 2001 13 Fast Handovers for Mobile IPv6 14 16 Status of This Memo 18 This document is a submission by the mobile-ip Working Group of the 19 Internet Engineering Task Force (IETF). Comments should be submitted 20 to the MOBILE-IP@STANDARDS.NORTELNETWORKS.COM mailing list. 22 Distribution of this memo is unlimited. 24 This document is an Internet-Draft and is in full conformance with 25 all provisions of Section 10 of RFC2026. Internet-Drafts are working 26 documents of the Internet Engineering Task Force (IETF), its areas, 27 and its working groups. Note that other groups may also distribute 28 working documents as Internet-Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at 32 any time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at: 36 http://www.ietf.org/ietf/1id-abstracts.txt 37 The list of Internet-Draft Shadow Directories can be accessed at: 38 http://www.ietf.org/shadow.html. 40 Abstract 42 This document specifies protocol enhancements to MIPv6 that enable 43 mobile nodes to more quickly become connected at new points of 44 attachment to the Internet. These protocol enhancements are intended 45 to minimize the time during which the mobile node is unable to send 46 or receive IPv6 packets (i.e., the handover latency). 48 1. Introduction 50 This draft presents the initial output of the MIPv6 Design Team on 51 Fast Handovers with Mobile IPv6. 53 The design decision has been taken not to consider scenarios in which 54 the handover cannot be initiated until the mobile node has layer-2 55 connectivity to the new access router, since these are covered 56 adequately by the base Mobile IPv6 Specification [MIPv6]. 58 In scenarios which the handover can be initiated while the mobile 59 node still has layer-2 connectivity at the previous access router, 60 another design decision has been taken. Since this specification 61 deals with layer-3 issues, the handover is considered to require 62 some layer three information relevant to the new access router. 63 Specifically, the handover at layer 3 requires a new care-of 64 address on the new link, as well as prefix lifetime information and 65 possibly other link parameters typically advertised by the new access 66 router. In parallel the acquisition of this new care-of address 67 should be performed in away that a duplicate or invalid address can 68 not be picked and in the rear case that it does the system to be able 69 to recover gracefully. 71 Situations where the mobile node would be expected to acquire this 72 information from advertisements from the new access router while 73 still maintaining layer-2 connectivity with the previous access 74 router are excluded from consideration in this specification. 75 Otherwise, the protocol would actually become a special case of again 76 the base MIPv6 specification. 78 2. Protocol Overview 80 The aim of this protocol is to enable the MN to configure a newCOA 81 before it moves to a newAR in a way that can use this newCOA 82 immediately at connection with newAR. The areas of preparation are 83 newCOA configuration, Duplicate Addressing avoidance and Neighbor 84 Discovery. 86 The pictured model provides standard terminology, standard behavior, 87 standard messages, and standard message semantics that enable fast 88 handover behavior with minimal interruption to packets flowing to a 89 mobile node as it moves. This model applies both to networks in 90 which the network determines that a handover will take place and to 91 networks in which the mobile determines that a handover will take 92 place. The model also preserves the Mobile IP characteristic of 93 having the mobile making the ultimate determination of whether 94 traffic destined to it is diverted to its new point of attachment. 96 MN oldAR newAR 97 | | | 98 |-----RtSolPr-------->| | 99 | | | 100 |<------PrRtAdv-------| | 101 | |--------HI--------->| 102 |----------BU-------->| | 103 |<---------BACK-------|<-------HACK--------| 104 | forward | 105 | packets===============>| 106 | | | 107 |--------------------NA-----------> | 108 | | deliver 109 |<=====================================Packets 111 Figure 1: General Framework. 113 Fast handover is implemented by adding 4 new messages which are 114 implemented between access routers and between an access router and a 115 mobile node. An access router is the last router between the network 116 and the mobile node. From the point of view of an upcoming handover, 117 the old Access Router (oldAR) is the router to which the mobile node 118 is currently attached (mobile's default router) and the new Access 119 Router (newAR) is the router to which the mobile node is about to 120 move. 122 The following messages are used in this specification and are defined 123 in detail in later sections: 125 - Router Solicitation for Proxy (RtSolPr) - MN to oldAR 127 - Proxy Router Advert (PrRtAdv) - oldAR to MN 129 - Handover Initiate (HI) - oldAR to newAR 131 - Handover Ack (HAck) - newAR to oldAR 133 - Binding Update (BU/BACK) - as defined in [MIPv6] + some flags 135 The behavior of the entities involved in the exchange are described 136 as follows. 138 To initiate a fast handover the mobile node sends a Router 139 Solicitation for Proxy to the oldAR indicating that it desires to 140 implement a fast handover to a new attachment point. The Router 141 Solicitation Proxy contains some form of identifier to indicate the 142 new attachment point. It will receive in response a Proxy Router 143 Advertisement message from the oldAR with a set of possible responses 144 indicating that the point of attachment is unknown, the point of 145 attachment is known and is connected through the same access router, 146 or is known and here is the prefix (or care-of-address) you should 147 use to form your new care-of-address (COA). The mobile node sends a 148 Binding Update using its newly formed COA as the last message before 149 it executes the handover. The mobile node then receives a Binding 150 Acknowledgement either through the oldAR or the newAR indicating that 151 the binding was complete. Whenever a mobile node moves to the newAR 152 it sends the Neighbor Advertisement to initiate the flow of packets 153 that may be waiting there for the mobile. 155 The oldAR can also initiate a handover for the mobile node using the 156 same messages. In this case the mobile node receives a Proxy Router 157 Advertisement with a new prefix (or care-of-address) indicating that 158 the mobile is about to be moved. The mobile responds by sending a 159 Binding Update to the oldAR with its new care-of-address. The mobile 160 receives a Binding Acknowledgement indicating that the handover is 161 complete. 163 The MN needs to be prepared for a number of error conditions. It may 164 not receive a response to an initial RtSolPr in which case it needs 165 to resend it. It also may not receive a response to its Binding 166 Update in which case it needs to sends a Neighbor Advertisement to 167 the newAR. If it does not receive its BACK at this point, the 168 Binding Update never got to the old access router and the Binding 169 Update needs to be resent. 171 The oldAR communicates with the MN using the exchange of packets 172 described above. If the mobile node is initiating the handover it 173 will receive a Router Solicitation Proxy with some access network 174 information. It will respond to this in one of three ways. If it 175 does not understand the access network information it will respond 176 saying that the access network information is unknown. If the oldAR 177 understands the access network information but realizes that the 178 access network information provided uses the same access router it 179 will respond that the mobile node will continue to use the same 180 access router. If the oldAR recognizes the access network 181 information but realizes it uses a different access router, it will 182 respond with a care-of-address or prefix for the new Access Router. 183 The oldAR MUST wait for a Binding Update from the MN before actually 184 forwarding packets. The oldAR sends a Binding Update acknowledgement 185 message to the mobile node through the temporary tunnel that is 186 constructed and to the mobile node over its old link. 188 If the oldAR is initiating the handover, it will begin the exchange 189 by using the Proxy Router Advertisement informing the MN of the new 190 care-of-address that will be used to deliver packets to it. The 191 oldAR MUST wait for a Binding Update from the MN before actually 192 forwarding packets. The oldAR sends a Binding Acknowledgement message 193 to the mobile node through the temporary tunnel that is constructed 194 and to the mobile node over its old link. 196 In addition to the exchange with the MN the oldAR exchanges 197 information with the newAR to facilitate the forwarding of packets 198 between the two and reduce the latency perceived by the MN during the 199 handover. The oldAR sends a Handover Initiate (HI) message to the 200 newAR with the requested care-of-address on the newAR and the care- 201 of-address being used currently at the oldAR. The oldAR receives in 202 response a Handover Acknowledgement (HACK) message either accepting 203 or rejecting the new care-of-address. If the new care-of-address is 204 accepted, the oldAR sets up a temporary tunnel to forward packets 205 destined for the mobile to the new care-of-address on the newAR. If 206 the new care-of-address is rejected by the newAR, the oldAR sets up a 207 temporary tunnel to forward packets destined for the mobile to the 208 old care-of-address which will be temporarily hosted on the newAR. 209 In either case the oldAR does not forward packets until it has 210 received a Binding Update from the MN. 212 In the case of stateful address allocation, the HI/HACK exchange 213 needs to be completed before the Proxy Router Advertisement is sent 214 to the mobile node. 216 The newAR also exchanges messages with the oldAR and forwards 217 messages between the oldAR and the MN. When the newAR receives an HI 218 message without a new COA it allocates a new COA and sends it to the 219 oldAR in the HACK message. When the newAR receives an HI message 220 with a new COA it determines whether the newCOA is valid and sends an 221 indication in the HACK message. If a valid newCOA is returned to the 222 oldAR the newAR will be receiving packets for the MN with a valid 223 newCOA and will just forward them as normal to the MN. If no valid 224 newCOA is determined, the newAR will record the oldCOA, de-tunnel the 225 packets received in the tunnel from the oldAR and deliver them to the 226 MN. 228 The newAR will deliver packets to the MN when it receives an 229 indication from the access network that it can begin sending packets 230 to the MN or when it receives a neighbor advertisement from the MN, 231 also an indication that it can send packets to the MN. 233 The following summarizes the semantics of the messages. 235 The Router Solicitation for Proxy is always an indication to the 236 oldAR that the MN would like to perform a handover and is requesting 237 information to enable the handover to be performed with minimal 238 interruption. 240 The Proxy Router Advertisement is an indication that the MN should go 241 ahead and move and it provides the prefix or address to be used on 242 the New AR. If the handover is mobile determined it provides 243 information about whether the handover will involve moving to a new 244 AR. If the handover is network determined it provides the indication 245 that the mobile is about to be moved and the information that it will 246 be using in the newAR. In network determined handover, failure to 247 conform with the Proxy Router Advertisement may result in loss of 248 service. 250 The Binding Update indicates the Binding that the mobile node wants 251 the oldAR to make. It also indicates to the network that the mobile 252 is moving and that it wants its packets forwarded. 254 The Binding Update Ack indicates whether the Binding Update was 255 successful. A negative acknowledgement may indicate that the newCOA 256 is invalid or that the Binding Update failed for any of the standard 257 reasons. 259 The Handover Initiate Message indicates the oldAR is trying to 260 facilitate a fast handover to the newAR and the oldCOA that will be 261 used in the case that the requested address negotiation between the 262 routers fail. 264 The Handover Ack Message indicates what the newCOA should be in the 265 new Router. 267 3. Supported scenarios 269 The framework described above applies to two main network scenarios. 270 A Network Determined Handover scenario were the network is 271 responsible for moving the mobile node from one attachment point to 272 another and a Mobile Determined Handover scenario were the mobile 273 itself has to define and initiate the handovers. 275 In either case the ultimate decision is on the mobile, in that no 276 routing change (no redirection of packets) takes place unless the MN 277 confirms the handover with a Binding Update to the old Access Router. 279 3.1. Network Determined Handover 281 In this scenario both stateless and stateful care of address 282 configuration is supported. 284 3.1.1. Stateless new Care-of-Address Configuration 286 When the oldAR realizes (or gets notified) that a MN must move to a 287 newAR it compiles a newCOA based on the MN's Interface ID and the 288 newAR's Prefix. It then sends this newCOA to the MN together with the 289 NewAR IP address and Link Layer Address using the PrRtAdv message. At 290 the same time the oldAR sends the HI message to the newAR indicating 291 the MN's oldCOA as well as the newly created newCOA. 293 The newAR first establishes whether the newCOA is a valid address 294 performing checks to ensure that it is not a duplicate. If the newCOA 295 is legal and acceptable to the newAR it adds it to the Neighboring 296 Cash for a short time period so it can defend it and it responds with 297 an HACK. If the newCOA is not valid (e.g.: used by other node) the 298 newAR adds a host route for the oldCOA pointing to its mobility 299 interface, for a short time period and responds to the oldAR with a 300 HACK (newCOA not valid). 302 MN oldAR newAR 303 | | | 304 |<------PrRtAdv-------|--------HI--------->| 305 |--------BU---------->|<-------HAck--------| 306 Disconnect <--BACK--|--BACK--> | 307 | | | 308 | forward | 309 | packets===============>| 310 | | | 311 |--------------------NA-----------> | 312 | | deliver 313 |<=====================================Packets 315 Figure 2: Network Determined and Stateless 317 If the HACK indicates the newCOA is valid the oldAR will get ready to 318 forward packets for this MN to its newCOA. If the HACK indicates the 319 newCOA is not valid the oldAR will get ready to forward packets for 320 this MN to the newAR. 322 The oldAR will only change its routing regarding an MN after it 323 receives a BU from the MN confirming the handover. This BU SHOULD be 324 sent (if permitted by the link layer conditions at handover time) to 325 the oldAR while the MN is still connected to the oldAR. If this is 326 not possible the BU MUST be sent after the MN connects to the newAR. 327 The oldAR MUST then send a BACK message to the MN both locally and by 328 way of newAR (using the newCOA or the newAR as encapsulating address) 330 On reception of the BU and providing the HACK has also been received, 331 the oldAR can start forwarding packets destined to the MN's oCOA to 332 either the newCOA or the newAR, depending of the HACK value. Now the 333 oldAR acts as a Home Agent with home address being the MN's oldCOA 334 and care-of-address being either the MN's newCOA or the newAR 335 address. 337 The MN MUST NOT use the newCOA address as source address until it 338 receives a BACK from the oldAR. The BACK may be received while the MN 339 is still connected to the oldAR in which case the MN will only have 340 to announce itself to the newAR to get full connectivity. In the case 341 were the BACK was sent but not received at the oldAR, there will be a 342 copy of it waiting for the MN at the newAR. If the BACK is not 343 received at all the MN should assume the BU was not received by the 344 oldAR and it MUST resent the BU to the oldAR. 346 3.1.2. Stateful new Care-of-Address Configuration 347 An alternative message sequence has HI/HAck message exchange proceeds 348 the PrRtAdv message send from the oldAR to the MN. This provides a 349 way to retrieve the correct contents for the PrRtAdv from the newAR 350 when this information is not available to the oldAR by other means. 352 MN oldAR newAR 353 | | | 354 | |--------HI--------->| 355 | |<-------HAck--------| 356 |<------PrRtAdv-------| | 357 | | | 359 Figure 3: Network Determined and Stateful 361 The rest of the process is identical to the stateless approach 363 3.2. Mobile Determined Handover 365 The main difference between this and the Network Determined approach 366 is that here the mobile node MUST send a Router Solicitation for 367 Proxy message to the oldAR and trigger the Proxy router 368 Advertisement. 370 In the RtSolPr message the MN indicates the Link Layer address or the 371 Identifier of the Attachment Point that it wants to attach to. The 372 oldAR will then reply with a PrRtAdv which contains the same 373 information with the stateless approach of Network Determined 374 approach. 376 MN oldAR newAR 377 | | | 378 |------RtSolPr------->| | 379 |<-----PrRtAdv--------|--------HI--------->| 380 |--------BU---------->|<------HACK---------| 381 Disconnect <--BACK--|--BACK--> | 382 | | | 383 | forward | 384 | packets===============>| 385 Connect | | 386 |------------------NA-------------> | 387 | | Deliver 388 |<=====================================Packets 390 Figure 4: Mobile Determined 391 The rest of the behavior is the same in that the newCOA is sent to 392 the newAR for validation using the HI/HACK sequence and the oldAR 393 does not changes its routing regarding the mobile in question unless 394 it receives a Binding Update from it, while the MN does not use the 395 newCOA until it receives a BACK. After all this is done, as before, 396 the oldAR acts as a Home Agent with home address being the MN's 397 oldCOA and care-of-address being either the MN's newCOA or the newAR 398 address. 400 3.3. Sending Binding Updates at the New Access Router 402 When the mobile node move to a new access router, it needs to send a 403 Binding Update to its home agent. It also may need to send a Binding 404 Update to its old access router, unless it has a positive indication 405 that the old access router already has made the appropriate binding 406 cache modifications. The typical form of such a positive indication 407 is a Binding Acknowledgement send from the old access router to the 408 mobile node; if the mobile node expects but does not receive the 409 acknowledgement, then it must effectively carry out the 410 retransmission algorithm for Binding Updates, as specified in 411 [MIPv6]. 413 In this section, it is considered that all necessary link 414 establishment details have been completed. This may possibly include 415 Duplicate Address Detection, and/or reception of a Router 416 Advertisement from the new access router. Those events may not 417 always have to occur, and when they are needed they must have 418 occurred before the transmission of Binding Updates messages. 420 When the new access router receives any packet from the mobile node 421 to be forwarded elsewhere, it means that the mobile node considers 422 the new access router to be its default router, and thus that link 423 establishment is complete from the point of view of the mobile node. 424 If the Binding Acknowledgement was received, then the mobile node 425 only has to send the Binding Update to its home agent. In that case, 426 that Binding Update would be sent through the mobile node's default 427 router--that is, the new access router. 429 If on the other hand the mobile node has not yet received a Binding 430 Acknowledgement from the old access router, then the mobile node 431 SHOULD arrange for oldAR to receive an appropriate Binding Update 432 associating the mobile node's new care-of address to its new care-of 433 address (as specified in [MIPv6]). Therefore, we specify that if the 434 mobile node knows the address of the newAR, it should first send any 435 necessary Binding Update packet to its old access router, before 436 sending the Binding Update packet to its home agent. 438 Furthermore, alternative encapsulation strategies, which would allow 439 both Binding Update options to be sent with a single transmission 440 over the air from the mobile node, are the subject of current 441 discussion in the design team. 443 If the mobile node does not know the address of the new access 444 router, Neighbor Discovery will have to take place before the Binding 445 Update is send. 447 In some circumstances, packets sent by the mobile node to the 448 previous access router just before handover may have been dropped. 449 If this information contained directives to the oldAR to initiate the 450 smooth handover, the new access router may not have taken any steps 451 to speed up the handover before the mobile node arrives. In this 452 case, the mobile node may assume that the new access router is ready 453 to provide connectivity, and then send a Binding Update through the 454 new access router before Duplicate Address Detection has been 455 accomplished for the new care-of address. In this case, the new 456 access router is expected to send a (perhaps newly defined) ICMP 457 message back to the mobile node. After taking care of the necessary 458 processes to protect its link-local address on the network at the 459 new point of attachment, the mobile node MAY resend the same Binding 460 Update packet(s) to the new access router, and/or home agent without 461 any recalculation. 463 3.3.1. Features enabling Partial Handover Optimization 465 The following features are related, and yet able to be separated, and 466 enable various facets of connectivity between the mobile node and the 467 new access router. 469 1. The mobile node may be able to discover the IP address of the new 470 access router 472 2. The mobile node may be able to discover the MAC address of the new 473 access router. 475 3. The mobile node may be able to direct the new access router to 476 ascertain the uniqueness of its new care-of address before 477 establishing connectivity with the new access router 479 4. The mobile node may be able to send a Binding Update to its 480 previous access router before breaking the previous connection 482 4a. The mobile node may be able to receive the Binding 483 Acknowledgement for the Binding Update sent to the old 484 access router before breaking the old connection. 486 4b. The mobile node may fail to receive the Binding Acknowledgement 487 for the Binding Update sent to the previous access router before 488 breaking the old connection. 490 All of these operations are possibly both in the network-determined 491 and the mobile-determined scenarios. 493 If (1), (2), and (3) hold, then the mobile node can begin to use the 494 new access router as its default router as soon as layer-2 495 connectivity is established. Thus, in this optimal circumstance, 496 any necessary Binding Updates can be delivered without any additional 497 delay as soon as the mobile node gets to the new network. 499 If any of (1), (2) or (3) do not hold, then the mobile node is 500 required to perform some combination of Neighbor Discovery and 501 Duplicate Address Detection when it arrives at the new access 502 router's area. 504 For all of cases 4, 4a, 4b, a simple rule is effective. If the 505 mobile node does not receive a Binding Acknowledgement for the 506 Binding Updates that it has sent, then it MUST retransmit those 507 Binding Updates according to the retransmission algorithm specified 508 in the base Mobile IPv6 document. 510 4. Message Extension and Option Formats 512 In this section, message and option formats are specified. The 513 description for each message extension and option will specify which 514 message or option it may be used with. 516 4.1. Router Solicitation for Proxy (RtSolPr) 518 Hosts send Router Solicitation for Proxy in order to prompt routers 519 for Proxy Router Advertisements. 521 0 1 2 3 522 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 523 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 524 | Type | Code | Checksum | 525 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 526 | Identifier | Reserved | 527 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 528 | Options ... 529 +-+-+-+-+-+-+-+-+-+-+-+- 531 IP Fields: 533 Source Address 534 An IP address assigned to the sending interface 536 Destination Address 537 The address of the Access Router 539 Hop Limit 255 540 Authentication Header 541 If a Security Association for the IP Authentication 542 Header exists between the sender and the 543 destination address, then the sender SHOULD include 544 this header. 546 ICMP Fields: 548 Type TBA 550 Code 0 552 Checksum The ICMP checksum. See [ICMPv6]. 554 Identifier MUST be set by the sender so replies can be matched 555 to this Solicitation. 557 Reserved MUST be set to zero by the sender and ignored by 558 the receiver. 560 Valid Options: 562 Source link-layer address 563 The link-layer address of the sender, if known. 564 It SHOULD be included on link layers that have 565 addresses. 567 New attachment point link-layer address 568 The link-layer address or identification of the 569 attachment point the mobile node requests routing 570 advertisement information for. It MUST be included 571 in all RtSolPr messages. 573 Future versions of this protocol may define new option types. 574 Receivers MUST silently ignore any options they do not recognize 575 and continue processing the message. 577 Description 579 The mobile node MUST sends this message if it wants to 580 initiate a fast handover. It indicates its destination 581 with the New Attachment Point Link-Layer Address. A 582 PrRtAdv message should be received in response. If such 583 message is not received in a short time period but no less 584 than 2 times the typical round trip time (RTT) over the 585 access link or 100msec if RTT is not known, it SHOULD 586 resend it once or at the most twice (after the same 587 waiting time). If the PrRtAdv is not received by the time 588 the mobile node disconnects from oldAR, Fast Handover can 589 not be performed and the mobile node SHOULD revert back to 590 normal MIPv6. 592 4.2 Proxy Router Advertisement (PrRtAdv) 594 Routers send out Router Advertisement message unsolicited if the 595 network is controlling the handover or in response to a Router 596 Solicitation for Proxy message from a mobile node. 598 0 1 2 3 599 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 600 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 601 | Type | Code | Checksum | 602 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 603 | Identifier | Reserved | 604 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 605 | Options ... 606 +-+-+-+-+-+-+-+-+-+-+-+- 608 IP Fields: 610 Source Address 611 MUST be the link-local address assigned to the 612 interface from which this message is sent. 614 Destination Address 615 The Source Address of an invoking Router 616 Solicitation for Proxy or the address of the node 617 the Access Router is instructing to handover. 619 Hop Limit 255 621 Authentication Header 622 If a Security Association for the IP Authentication 623 Header exists between the sender and the 624 destination address, then the sender SHOULD include 625 this header. 627 ICMP Fields: 629 Type TBA 631 Code 0 - Handover Information 632 1 - No change of COA required 633 2 - New Attachment Point not known 635 Checksum The ICMP checksum. See [ICMPv6]. 637 Identifier Copied from Router Solicitation for Proxy or set to 638 Zero if unsolicited. 640 Reserved MUST be set to zero by the sender and ignored by 641 the receiver. 643 Valid Options: 645 Source link-layer address 646 The link-layer address of the sender, if known. 647 It SHOULD be included on link layers that have 648 addresses. 650 Link-layer address of proxied originator 651 The link-layer address of the Access Router for 652 which this message is proxied for. 654 Prefix Information 655 These options specify the prefixes of the Access 656 Router the message is proxied for and are used 657 for address autoconfiguration. 659 New COA Option 660 In sateful configuration, this option MUST be sent 661 to allocate an address on behalf of the Access 662 Router this message is proxied for. In stateless 663 address auto-configuration this option may or may 664 not be sent. 665 If sent, indicates that the requesting node SHOULD 666 use this address as newCOA for the duration 667 of the handover. If not sent the requesting node 668 SHOULD compute the newCOA using the Interface ID 669 from the Destination Address of this message. 671 Future versions of this protocol may define new option types. 672 Receivers MUST silently ignore any options they do not recognize 673 and continue processing the message. 675 Description 677 A PrRtAdv with Code 0 but without a New COA Option means 678 that the mobile node SHOULD construct a newCOA out of its 679 Interface ID (used in the Destination Address in this 680 PrRtAdv) and the Prefix in the Prefix Information Option. 681 A PrRtAdv with Code 0 and a New COA Option means that the 682 mobile node SHOULD use the COA indicated as a newCOA at 683 the new Access Router. This MUST used when Stateful COA 684 configuration is in use and MAY be used to help the oldAR 685 and MN calculate the same newCOA when Stateless COA 686 configuration is used. 687 A PrRtAdv with Code 1 is sent if handover to the New 688 Attachment Point, as indicated by the New Attachment Point 689 Link Layer address in the corresponding RtSolPr message, 690 does not require change of COA. No options required in 691 this case. 692 A PrRtAdv with Code 2 means that the oldAR is not aware of 693 the Prefix Information requested. The MN MUST give up its 694 attempt to perform fast handover to this new attachment 695 point. Normal MIPv6 MAY be used instead. No options 696 required in this case. 697 This message is sent once for every RtSolPr received. 699 4.3. Handover Initiation (HI) 701 The Handover Initiation message is a new ICMPv6 message sent by the 702 old Access Router to new Access Router to initiate the process of 703 Mobile Node's handover from one sub-network to another. 705 0 1 2 3 706 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 707 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 708 | Type | Code | Checksum | 709 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 710 | Identifier |S|U| Reserved | 711 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 712 | Options ... 713 +-+-+-+-+-+-+-+-+-+-+-+- 715 IP Fields: 717 Source Address 718 The IP address of the Router sending this message 720 Destination Address 721 The IP address of the Router this message is sent 722 To. 724 Hop Limit 255 726 Authentication Header 727 A Security Association MUST exists between the 728 sender and the destination address. This messages 729 MUST be authenticated and so the authentication 730 header MUST be used when this message is sent 732 ICMP Fields: 734 Type TBA 736 Code 0 738 Checksum The ICMP checksum. See [ICMPv6]. 740 Identifier MUST be set by the sender so replies can be matched 741 to this Solicitation. 743 S Stateful address configuration flag. When SET this 744 message requests a new COA to be returned by the 745 destination. 747 U Buffer flag. The destination SHOULD buffer any 748 packets towards the node indicated in the options 749 of this message. 751 Reserved MUST be set to zero by the sender and ignored by 752 the receiver. 754 Valid Options: 756 Link-layer address of mobile node 757 The link-layer address of the mobile node that is 758 being handed of to the destination. This options 759 SHOULD be included to help the destination 760 recognize the mobile node when it will be connected 761 to it. 763 Old Care of Address 764 The IP address used by the mobile node while 765 attached to the originating router. This option 766 MUST be included so packets to this mobile node can 767 be redirected to the destination even if the new 768 Care of Address is not acceptable. 770 New Care of Address 771 The IP address the mobile node wants to use when 772 connected to the destination. In Stateless 773 configuration this option indicates the new Care of 774 Address the mobile node will be using when 775 connected to the destination. 777 Description 779 If HACK message is not received as a response to this 780 message. the HI SHOULD be resent up to 4 times using a 781 short retransmission timer but no less than twice the 782 round trip time between source and destination or 100msec 783 if RTT is not known. Failure to receive an HACK means that 784 no fast handover can be performed. 785 The purpose of this message is to notify the newAR about 786 the upcoming handover and establish a valid newCOA for the 787 mobile node. If the S flag is SET this message requests an 788 address from the newAR to be assigned statefully. If the 789 new COA option is included the oldAR requests the newAR to 790 confirm that this is a valid newCOA. 792 4.4. Handover Acknowledgement (HACK) Message 794 The Handover Acknowledgement message is a new ICMPv6 message that 795 MUST be sent by the new Access Router to the old Access Router in 796 response to a Handover Initiate message. 798 0 1 2 3 799 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 800 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 801 | Type | Code | Checksum | 802 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 803 | Identifier | Reserved | 804 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 805 | Options ... 806 +-+-+-+-+-+-+-+-+-+-+-+- 808 IP Fields: 810 Source Address 811 Copied from the destination address of the HI 812 Message this message is in response to. 814 Destination Address 815 Copied from the source address of the HI 816 Message this message is in response to. 818 Hop Limit 255 820 Authentication Header 821 A Security Association MUST exists between the 822 sender and the destination address. This messages 823 MUST be authenticated and so the authentication 824 header MUST be used when this message is sent 826 ICMP Fields: 828 Type TBA 830 Code 831 0-Handover Accepted, newCOA valid 832 1-Handover Accepted, newCOA not valid 833 2-Handover Accepted, newCOA in use 834 3-Handover Accepted, newCOA assigned (Stateful) 835 4-Handover Accepted, newCOA not assigned (Stateful) 836 128-Handover Not Accepted, reason unspecified 837 129-Administratively prohibited 838 130-Insufficient resources 839 Checksum The ICMP checksum. See [ICMPv6]. 841 Identifier Copied from the corresponding field in the HI 842 message this message is in response to. 844 Reserved MUST be set to zero by the sender and ignored by 845 the receiver. 847 Valid Options: 849 New Care of Address 850 If the S flag in the HI message is SET, this option 851 Is used to provide the new Care of Address the 852 mobile node should use when connected to this 853 router. 855 Description 857 On reception of HI the newAR MUST respond with an HACK. If 858 the S flag is SET in the HI, the newAR SHOULD include the 859 new Care of Address option and a Code of 3. 860 If the S flag is not SET in the HI, the newAR SHOULD check 861 the validity of the newCOA sent with the HI and reply 862 accordingly. 863 If the newCOA is valid and the handover the newAR SHOULD 864 insert the newCOA in its Neighbor Cash and defended on 865 behalf of the mobile for a short period of time of a 866 default value of 1 second in which period the mobile node 867 is expected to connect to the newAR. 868 If the newCOA is not valid or not assigned (Stateful) the 869 newAR SHOULD insert a host route, pointing to its mobility 870 interface the mobile node is expected to connect to, for 871 the mobile's oldCOA. 872 The newAR can always refuse the handover in which case it 873 should indicate the reason in one of the available Code 874 values. 876 4.5. IP Address Option 878 This section defines the IP Address Option, used by the ICMPv6 879 messages defined in this document. The extension format is based on 880 [MIER]. 882 0 1 2 3 883 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 884 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 885 | Type | Sub-Type | Length | Prefix Length | 886 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 887 | Reserved | 888 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 889 | | 890 + + 891 | | 892 + IPv6 Address + 893 | | 894 + + 895 | | 896 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 898 Type 899 TBA 901 Sub-Type 902 1 Old Care-of Address 903 2 New Care-of Address 905 Length 906 3 908 Prefix Length 909 The Length of the IPv6 Address Prefix 911 IPv6 address 912 The IP address for the unit defined by the Type 913 field. 915 This option is sent in the Proxy Router Advertisement, the Handover 916 Initiate and Handover Acknowledgement messages. The PrRtAdv and HACK 917 messages only contain the newCOA while the HI message may include 918 both newCOA and oldCOA. 920 4.6. Link-layer Addresses (LLA) 922 This extension is based on the [MIER] format. 924 0 1 2 3 925 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 926 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 927 | Type | Sub-Type | Length | LLA ... 928 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 929 Fields: 931 Type 932 TBA 934 Sub-Type 935 1 for the Link-layer Address of the new Attachment Point. 936 2 for the Link-layer Address of the Mobile Node. 937 3 for the Link-layer Address of the Proxied Originator 939 Length 940 The length of the option (including the type, sub-type and 941 length fields) in units of 8 octets. 943 LLA 944 The variable length link-layer address. 946 The content and format of this field (including byte and bit 947 ordering) is expected to be specified in specific documents 948 that describe how IPv6 operates over different link layers. 950 Description 951 The New Attachment Point Link Layer address contains the 952 link-layer address of the attachment point the mobile node 953 attempts to handover to. This is used in the Router 954 Solicitation for Proxy message. 956 The Mobile Node Link-Layer address option contains the link- 957 layer address of a mobile node. It is used in the Handover 958 Initiation message. 960 The Proxied Originator Link-Layer address option contains the 961 Link Layer address of the Access Router the Proxy Router 962 Solicitation message refers to. 964 These options MUST be silently ignored for other Neighbor 965 Discovery messages. 967 NOTE: Source and Target Link Layer Addresses as defined in [ND] MAY 968 also be used by Router Solicitation for Proxy and Proxy Routing 969 Advertisement messages. 971 4.7 Modified Binding Update Option 973 Two flags B, U are added to the flag bits in the Binding Update 974 Option. The mobile node sets the B flag in the Binding Update, to 975 indicate that the mobile node would like the AR to do bicasting. The 976 mobile node sets the U flag in the Binding Update to indicate that 977 the mobile node would like the AR to do buffering. Finally the AR MAY 978 honor the bicasting and buffering requests or reject them silently. 980 Thus, the Binding Update Option under Fast Handovers for Mobile IPv6 981 will show as below: 983 0 1 2 3 984 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 985 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 986 | Option Type | Option Length | 987 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 988 |A|H|R|D|B|U|r|r| Prefix Length ... 989 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 991 B The mobile node is requesting the AR to do bicasting. 993 U The mobile node is requesting the AR to do buffering. 995 r reserved and it MUST be set to 0. 997 The rest of the flag bits and the other fields are as defined in 998 [MIPv6]. 1000 Description 1002 This message MUST be send by the mobile node to the old 1003 Access Router so that the latter can redirect traffic to 1004 the mobile node by the way of the new Access Router. The 1005 message SHOULD be sent while the mobile node is still 1006 connected to the oldAR and a BACK SHOULD be received at the 1007 same place. If that is not possible, due to link layer 1008 conditions, the BU MUST be send or resend at the newAR and 1009 the BACK MUST be received before the mobile node can use 1010 the newCOA. The initial retransmission timer for the BU in 1011 this particular case should be very short but no less than 1012 1.5 times theworst case RTT of the L2 after the MN connects 1013 to the newAR. The BU SHOULD be resent using exponential 1014 backoff but only once or at most twice more. If that does 1015 not yield a BACK the mobile node MUST give up the attempt 1016 for a fast handover and revert back to normal MIPv6. 1018 5. Error Cases and other issues 1020 In this section we are going to examine some common error cases that 1021 may affect the performance and/or reliability of the mechanisms 1022 described in this specification. 1024 5.1. DAD handling 1025 Duplicate Address Detection (DAD) was defined in [AUTO] to avoid 1026 address duplication on links when stateless address auto- 1027 configuration is used. The use of DAD to verify the uniqueness of a 1028 statelessly configured IPv6 address may add delays to a MIPv6 1029 handover. 1031 The probability of an interface identifier duplication on the same 1032 subnet can be considered very low, however it can not be ignored. In 1033 this draft certain precautions are proposed to minimize the effects 1034 of a duplicate address occurrence. 1036 In some cases the new AR may already have the knowledge required to 1037 assess whether the MN's address is duplicated or not, before the MN 1038 moves to the new subnet. For example, the AR can have a list of all 1039 nodes on its subnet (may be used for access control) and by searching 1040 this list it can confirm whether the MN's address is duplicated. The 1041 result of this search can be sent back to the old AR in the HAck 1042 message. 1044 If such knowledge is not available in the new AR, the MN would have 1045 to perform DAD after moving to the new subnet. To avoid delays due to 1046 performing DAD, it is suggested that the MN performs DAD while using 1047 its oldCOA. This is possible since the framework described in this 1048 specification allows packet redirection based on the oldCOA 1049 encapsulated into the newAR IP address. 1051 So, if the newAR cannot confirm the validity of the newCOA address 1052 included in the HI message but is never the less willing to serve the 1053 MN it can describe that in the HACK message and install a host route 1054 towards its mobility interface regarding the MN's oldCOA. 1056 The oldAR on reception of this type of HACK replies with a BUNACK to 1057 the BU sent by the MN attempting to registers is newCOA. The oldAR 1058 now forwards packets for this MN to the newAR which will decapsulates 1059 and due to the host route installed earlier it can forward these 1060 packets to the mobile. 1062 The MN will at some point, either at the old or at the newAR receive 1063 the BUNACK and thus attempt to get a newCOA. If the MN does not 1064 receive the BACK or BUNACK at the oldAR and after connecting to the 1065 newAR it still does not receive it in a short time frame (X sec) it 1066 can assume that the BU was not received by the oldAR and it MUST 1067 retransmit it. The source address used in this BU SHOULD be the 1068 newCOA, which is not yet confirmed, to avoid ingress filtering. If 1069 the newCOA is not valid the oldAR will send (or resend) a BUNACK to 1070 the oldAR, encapsulated in the address of the newAR and thus it will 1071 safely be received by the MN. 1073 6. Security Considerations 1075 The security needed for fast handover is almost the same as is 1076 needed for handling Binding Updates in IPv6. If a handover could 1077 be initiated by a node masquerading as the mobile node, a range of 1078 undesirable effects might result. The malicious node could usurp 1079 traffic destined from the mobile node, diverting it to a nearby 1080 router and possibly an unauthorized care-of address. The exact 1081 details of the possible effects would depend on the kinds of handover 1082 data available as part of the fast handover process. 1084 The Fast MIPv6 Handover proposal assumes that a security association 1085 exists between the oldAR and the MN, as well as between the old and 1086 newARs. Providing the above is true then, routing is only changes by 1087 a BU from the MN, which MUST be authenticated. It is also highly 1088 recommended that RtSolPr and PrRtAdv messages are also authenticated 1089 since they are between oldAR and MN which have a security 1090 association. 1092 7. Acknowledgements 1094 Thanks to Basavaraj Patil and Phil Roberts for supporting this effort 1095 and the whole Mobile IP WG for participating in the initial 1096 discussion. 1098 References 1100 [ASSNUM] J. Reynolds, J. Postel, Assigned Numbers, Request For 1101 Comments (Standards Track) 1700. October 1994. 1103 [AUTO] S. Thomson and T. Narten. IPv6 Stateless Address 1104 Autoconfiguration. Request for Comments (Draft Standard) 2462, 1105 Internet Engineering Task Force, December 1998. 1107 [EUI] IEEE, "Guidelines for 64-bit Global Identifier (EUI-64) 1108 Registration Authority", 1109 http://standards.ieee.org/regauth/oui/tutorials/EUI64.html, March 1997. 1111 [IMSI] TIA/EIA/IS-95-B 1113 [MAC] D. Plummer, "An Ethernet Address Resolution Protocol - or - 1114 Converting Network Protocol Addresses to 48.bit Ethernet Address for 1115 Transmission on Ethernet Hardware", RFC 826, November 1982. 1117 [MIER] M.Khalil, R. Narayanan, H. Akhtar, E. Qaddoura, Mobile IP 1118 Extensions Rationalization (MIER)(work in progress). 1119 draft-ietf-mobileip-mier-05.txt, December 1999. 1121 [MIPv6] D. Johnson and C. Perkins. Mobility Support in IPv6 (work in 1122 progress). draft-ietf-mobileip-ipv6-12.txt, April 2000. 1124 [ND] T. Narten, E. Nordmark, and W. Simpson. Neighbor Discovery for 1125 IP Version 6 (IPv6). Request for Comments (Draft Standard) 2461, 1126 Internet Engineering Task Force, December 1998. 1128 Addresses 1130 The working group can be contacted via the current chairs: 1132 Basavaraj Patil Phil Roberts 1133 Nokia Corporation Motorola 1134 6000 Connection Drive 1501 West Shure Drive 1135 M/S M8-540 1136 Irving, Texas 75039 Arlington Heights, IL 60004 1137 USA USA 1138 Phone: +1 972-894-6709 Phone: +1 847-632-3148 1139 Fax : +1 972-894-5349 1140 EMail: Basavaraj.Patil@nokia.com EMail: QA3445@email.mot.com 1142 The authors of this document are: 1144 Alper Yegin Sun Alper.Yegin@eng.sun.com 1145 Charles E. Perkins Nokia charliep@iprg.nokia.com 1146 George Tsirtsis Flarion G.Tsirtsis@flarion.com 1147 Gopal Dommety Cisco gdommety@cisco.com 1148 Karim El-Malki Ericsson Karim.El-Malki@era.ericsson.se 1149 Mohamed Khalil Nortel mkhalil@nortelnetworks.com