idnits 2.17.1 draft-ietf-mipshop-fast-mipv6-00.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 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' 8. Security Considerations' ) ** 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 an Authors' Addresses Section. ** 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 1 character 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 -- however, there's a paragraph with a matching beginning. Boilerplate error? RFC 2119 keyword, line 255: '... implementations MUST implement the me...' RFC 2119 keyword, line 256: '...l address conflicts and SHOULD support...' RFC 2119 keyword, line 262: '... tunnel. When feasible, the MN SHOULD...' RFC 2119 keyword, line 268: '...osite direction, the MN SHOULD reverse...' RFC 2119 keyword, line 270: '... PAR SHOULD forward the inner packet...' (133 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: If the MN receives a Router Advertisement with a NAACK option, it MUST revert to configuring a new address, and SHOULD use the address, if any is, provided in the NAACK option. Subsequently, the MN SHOULD send an FBU using the new CoA. As a special case, the address supplied in NAACK could be PCoA itself, in which case the MN MUST not send any more FBUs. If no address is present in NAACK option, the MN MUST follow [5] in order to configure a new CoA and SHOULD still send FBU to PAR. -- 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 (10 October 2003) is 7501 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: 'AP-ID' on line 315 -- Looks like a reference, but probably isn't: 'AR-Info' on line 315 -- Looks like a reference, but probably isn't: 'AP' on line 503 -- Looks like a reference, but probably isn't: 'AR' on line 503 ** Obsolete normative reference: RFC 2463 (ref. '2') (Obsoleted by RFC 4443) -- Possible downref: Non-RFC (?) normative reference: ref. '3' == Outdated reference: A later version (-07) exists of draft-ietf-mobileip-mier-05 -- Possible downref: Normative reference to a draft: ref. '4' ** Obsolete normative reference: RFC 2462 (ref. '5') (Obsoleted by RFC 4862) Summary: 10 errors (**), 0 flaws (~~), 3 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Mobile IP Working Group Rajeev Koodli, Editor 2 INTERNET DRAFT Nokia Research Center 3 10 October 2003 5 Fast Handovers for Mobile IPv6 6 draft-ietf-mipshop-fast-mipv6-00.txt 8 Status of This Memo 10 This document is an Internet-Draft and is in full conformance with 11 all provisions of Section 10 of RFC2026. 13 Internet-Drafts are working documents of the Internet Engineering 14 Task Force (IETF), its areas, and its working groups. Note that 15 other groups may also distribute working documents as Internet- 16 Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at 20 any time. It is inappropriate to use Internet- Drafts as reference 21 material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at: 24 http://www.ietf.org/ietf/1id-abstracts.txt 25 The list of Internet-Draft Shadow Directories can be accessed at: 26 http://www.ietf.org/shadow.html. 28 This memo provides information for the Internet community. This memo 29 does not specify an Internet standard of any kind. Distribution of 30 this memo is unlimited. 32 Abstract 34 Mobile IPv6 enables a Mobile Node to maintain its connectivity to 35 the Internet when moving from an Access Router to another, a process 36 referred to as handover. During handover, there is a period when 37 the Mobile Node is unable to send or receive packets both due to 38 link switching delay and IP protocol operations. This ``handover 39 latency'' resulting from standard Mobile IPv6 procedures, namely 40 movement detection, new Care of Address configuration and Binding 41 Update, is often unacceptable to real-time traffic such as Voice 42 over IP. Reducing the handover latency could be beneficial to non 43 real-time, throughput-sensitive applications as well. This document 44 specifies enhancements to reduce the handover latency due to standard 45 Mobile IPv6 procedures. This document does not address improving the 46 link switching latency. 48 Contents 50 Status of This Memo i 52 Abstract i 54 1. Introduction 2 56 2. Terminology 2 58 3. Protocol Overview 3 59 3.1. Addressing the Handover Latency . . . . . . . . . . . . . 3 60 3.2. Protocol Operation . . . . . . . . . . . . . . . . . . . 6 61 3.3. Protocol Operation of Network-initiated Handover . . . . 8 63 4. Protocol Details 9 65 5. Other Considerations 13 66 5.1. Handover Capability Exchange . . . . . . . . . . . . . . 13 67 5.2. Determining New Care of Address . . . . . . . . . . . . . 13 68 5.3. Packet Loss . . . . . . . . . . . . . . . . . . . . . . . 13 69 5.4. DAD Handling . . . . . . . . . . . . . . . . . . . . . . 14 70 5.5. Fast or Erroneous Movement . . . . . . . . . . . . . . . 14 72 6. Message Formats 15 73 6.1. New Neighbor Discovery Messages . . . . . . . . . . . . . 15 74 6.1.1. Router Solicitation for Proxy . . . . . . . . . . 15 75 6.1.2. Proxy Router Advertisement (PrRtAdv) . . . . . . 17 76 6.2. Inter-Access Router Messages . . . . . . . . . . . . . . 20 77 6.2.1. Handover Initiate (HI) . . . . . . . . . . . . . 20 78 6.2.2. Handover Acknowledge (HAck) . . . . . . . . . . . 22 79 6.3. New Mobility Header Messages . . . . . . . . . . . . . . 24 80 6.3.1. Fast Binding Update (FBU) . . . . . . . . . . . . 24 81 6.3.2. Fast Binding Acknowledgment (FBack) . . . . . . . 25 82 6.3.3. Fast Neighbor Advertisement (FNA) . . . . . . . . 27 83 6.4. New ICMP Options . . . . . . . . . . . . . . . . . . . . 28 84 6.4.1. IP Address Option . . . . . . . . . . . . . . . . 28 85 6.4.2. New Router Prefix Information Option . . . . . . 29 86 6.4.3. Link-layer Address (LLA) . . . . . . . . . . . . 30 87 6.4.4. Neighbor Advertisement Acknowledgment (NAACK) . . 31 89 7. Configurable Parameters 32 91 8. Security Considerations 32 93 9. Contributors 33 95 10. Acknowledgments 33 97 A. Change Log 34 99 B. Contact Information 34 100 1. Introduction 102 Mobile IPv6 [3] describes the protocol operations for a mobile node 103 to maintain connectivity to the Internet during its handover from one 104 access router to another. These operations broadly involve movement 105 detection, IP address configuration, and location update phases. 106 The combined handover latency could be (especially) appreciable 107 for real-time applications. Throughput-sensitive applications can 108 also benefit from reducing this latency. This document describes a 109 protocol to reduce the handover latency. 111 This specification addresses the following problem: how to allow 112 a mobile node to send packets as soon as it detects a new subnet 113 link, and how to deliver packets to a mobile node as soon as its 114 attachment is detected by the new access router. The protocol 115 defines IP protocol messages necessary for its operation on any link 116 technology. It does this without depending on specific link-layer 117 features while allowing link-specific customizations. By definition, 118 this specification considers handovers that inter-work with Mobile 119 IP: once attached to its new access router, a MN engages in Mobile 120 IP operations including Return Routability [3]. Hence, there are no 121 special requirements for a mobile node to behave differently with 122 respect to its standard Mobile IP operations. 124 2. Terminology 126 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 127 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "OPTIONAL", and 128 "silently ignore" in this document are to be interpreted as described 129 in RFC 2119 [1]. 131 The following terminology and abbreviations are used in this 132 document. The reference handover scenario is illustrated in 133 Figure 1. 135 Mobile Node (MN) 136 A Mobile IPv6 host 138 Access Point (AP) 139 A Layer 2 device connected to a subnet that offers 140 wireless connectivity to a MN. 142 Access Router (AR) 143 The MN's default router 145 Previous Access Router (PAR) 146 The MN's default router prior to its handover 148 New Access Router (NAR) 149 The MN's anticipated default router subsequent to its 150 handover 152 Previous CoA (PCoA) 153 The MN's Care of Address valid on PAR. The MN may reuse 154 this address while attached to NAR until it finishes 155 Mobile IP operations. 157 New CoA (NCoA) 158 The MN's Care of Address valid on NAR 160 Handover 161 A process of terminating existing connectivity and 162 obtaining new IP connectivity. 164 Router Solicitation for Proxy (RtSolPr) 165 A message from the MN to the PAR requesting information 166 for a potential handover 168 Proxy Router Advertisement (PrRtAdv) 169 A message from the PAR indicating a MN to undergo 170 handover 172 Fast Binding Update (FBU) 173 A message from the MN instructing its PAR to redirect its 174 traffic (towards NAR) 176 Fast Binding Acknowledgment (FBACK) 177 A message from the PAR in response to FBU 179 Fast Neighbor Advertisement (FNA) 180 A message from the MN to the NAR to announce attachment 181 and to confirm use of NCoA when the MN has not received 182 FBACK 184 Handover Initiate (HI) 185 A message from the PAR to the NAR to initiate handover 187 Handover Acknowledge (HACK) 188 A message from the NAR to the PAR as a response to HI 190 3. Protocol Overview 192 3.1. Addressing the Handover Latency 194 The ability to quickly send packets from a new subnet link depends 195 on the ``IP connectivity'' latency, which in turn depends on the 196 v +------------+ 197 +-+ | Previous | < 198 | | ---------- | Access | ------ > ----\ 199 +-+ | Router | < \ 200 MN | (PAR) | \ 201 | +------------+ +---------------+ 202 | ^ IP | Correspondent | 203 | | Network | Node | 204 V | +---------------+ 205 v / 206 v +------------+ / 207 +-+ | New | < / 208 | | ---------- | Access | ------ > ----/ 209 +-+ | Router | < 210 MN | (NAR) | 211 +------------+ 213 Figure 1: Reference Scenario for Handover 215 movement detection latency and the new CoA configuration latency. 216 Once a MN is IP-capable on the new subnet link, it can send Binding 217 Update to its Home Agent and one or more correspondents. Once 218 its correspondents successfully process the Binding Update, which 219 involves the Return Routability procedure, the MN can receive packets 220 at new CoA. So, the ability to receive packets from correspondents 221 directly at its new CoA depends on the Binding Update latency. 223 The protocol enables a MN to quickly detect that it has moved to 224 a new subnet by providing the new access point and the associated 225 subnet prefix information when the MN is still connected to its 226 current subnet (i.e., PAR in Figure 1). For instance, a MN may 227 discover available access points using link-layer specific mechanisms 228 (e.g., a ``scan'' in WLAN) and then request subnet information 229 corresponding to one or more of those discovered access points. 230 The MN may do this after performing router discovery. The MN may 231 also do this at any time during its sojourn on its current point of 232 attachment. The result of resolving an identifier associated with 233 an access point is a [AP-ID, AR-Info] tuple, which a MN can use in 234 readily detecting movement: when attachment to an access point 235 with AP-ID takes place, the MN knows the corresponding new router's 236 co-ordinates including its prefix, IP address and MAC address. The 237 ``Router Solicitation for Proxy (RtSolPr)'' and ``Proxy Router 238 Advertisement (PrRtAdv)'' messages are used for aiding in movement 239 detection. 241 Through the RtSolPr and PrRtAdv messages, the MN also formulates 242 a prospective new CoA (NCoA), again when still present on PAR's 243 link. Hence, the latency due to new prefix discovery subsequent to 244 handover is eliminated. Furthermore, this prospective address can 245 be used immediately after attaching to the new subnet link (i.e., 246 NAR's link) when the MN has received a ``Fast Binding Acknowledgment 247 (FBack)'' message prior to its movement. In the event it moves 248 without receiving an FBack, the MN can still start using NCoA after 249 announcing its attachment through a ``Fast Neighbor Advertisement 250 (FNA)'' message; NAR responds to FNA in case the tentative address 251 is already in use. In this way, NCoA configuration latency is 252 reduced. Under some limited conditions where the probability of 253 address collision is considered insignificant, it may be possible 254 to use NCoA immediately after attaching to the new link. Even so, 255 all implementations MUST implement the mechanism specified in this 256 document to avoid potential address conflicts and SHOULD support 257 them. 259 In order to reduce the Binding Update latency, the protocol specifies 260 a tunnel establishment typically between the Previous CoA (PCoA) and 261 NCoA. A MN sends a ``Fast Binding Update'' message to its Previous 262 Access Router to establish this tunnel. When feasible, the MN SHOULD 263 send FBU from PAR's link. Otherwise, it should send it immediately 264 after detecting attachment to NAR. Subsequent sections describe 265 the protocol mechanics. In any case, the net result is that PAR 266 begins tunneling packets arriving for PCoA to NCoA. Such a tunnel 267 would remain active until the MN completes Binding Update with its 268 correspondents. In the opposite direction, the MN SHOULD reverse 269 tunnel packets to PAR, again until it completes Binding Update. And, 270 PAR SHOULD forward the inner packet in the tunnel to its destination 271 (i.e., to the MN's correspondent). Such a reverse tunnel ensures 272 that packets containing PCoA as source IP addres are not dropped 273 due to ingress filtering. Readers may observe that even though the 274 MN is IP-capable on the new link, it cannot use NCoA directly with 275 its correspondents without the correspondents first establishing a 276 binding cache entry (for NCoA). 278 Setting up a tunnel alone does not ensure that the MN receives 279 packets as soon as attaching to a new subnet link, unless NAR can 280 detect the MN's presence. Neighbor discovery operation involving 281 a neighbor's address resolution (i.e., Neighbor Solicitation and 282 Neighbor Advertisement) typically result in considerable delay, 283 sometimes lasting multiple seconds. For instance, when arriving 284 packets trigger NAR to send Neighbor Solicitation before the MN 285 attaches, subsequent re-transmissions of address resolution are 286 separated by a default time of one second each. In order to 287 circumvent this delay, a MN announces its attachment through the FNA 288 message that allows NAR to consider MN to be reachable. If there 289 is no existing entry, FNA allows NAR to create one. If NAR already 290 has an entry, FNA updates the entry while taking potential address 291 conflicts into consideration. Through tunnel establishment for PCoA 292 and fast advertisement, the protocol provides expeditious forwarding 293 of packets to the MN. 295 The protocol also provides the following important functionalities. 296 The access routers can exchange messages to confirm that a proposed 297 NCoA is acceptable. For instance, when a MN sends FBU from PAR's 298 link, FBack can be delivered after NAR considers NCoA acceptable to 299 use. This is especially useful when stateful address configuration 300 is used. The NAR can also rely on its trust relationship with PAR 301 before providing forwarding support for the MN. That is, it may 302 create a forwarding entry for NCoA subject to ``approval'' from 303 PAR which it trusts. Finally, the access routers could transfer 304 network-resident contexts, such as access control, QoS, header 305 compression, in conjunction with handover. For all these operations, 306 the protocol provides ``Handover Initiate (HI)'' and ``Handover 307 Acknowledge (HAck)'' messages. Both of these messages MUST be 308 implemented and SHOULD be supported. 310 3.2. Protocol Operation 312 The protocol begins when a MN sends RtSolPr to its access router 313 to resolve one or more Access Point Identifiers to subnet-specific 314 information. In response, the access router (e.g., PAR in Figure 1) 315 sends a PrRtAdv message which contains one or more [AP-ID, AR-Info] 316 tuples. The MN may send RtSolPr at any convenient time, for instance 317 as a response to some link-specific event (a ``trigger'') or simply 318 after performing router discovery. However, the expectation is that 319 prior to sending RtSolPr, the MN has discovered the available APs 320 by link-specific methods. The RtSolPr and PrRtAdv messages do not 321 establish any state at the access router, and their packet formats 322 are defined in Section 6.1. 324 With the information provided in the PrRtAdv message, the MN 325 formulates a prospective NCoA and sends an FBU message. The purpose 326 of FBU is to authorize PAR to bind PCoA to NCoA, so that arriving 327 packets can be tunneled to the new location. The FBU SHOULD be 328 sent from PAR's link whenever feasible. For instance, an internal 329 link-specific trigger could enable FBU transmission from the previous 330 link. When it is not feasible, FBU is sent from the new link. Care 331 must be taken to ensure that NCoA used in FBU does not conflict with 332 an address already in use by some other node on link. For this, FBU 333 encapsulation within FNA MUST be implemented and SHOULD be used (See 334 below). 336 The format and semantics of FBU processing are specified in 337 Section 6.3.1. 339 Depending on whether an FBack is received or not on the previous 340 link, which clearly depends on whether FBU was sent in the first 341 place, there are two modes of operation. 343 1. The MN receives FBack on the previous link. This means that 344 packet tunneling would already be in progress by the time the 345 MN handovers to NAR. The MN SHOULD send FNA immediately after 346 attaching to NAR, so that arriving as well as buffered packets 347 can be forwarded to the MN right away. 349 Before sending FBack to MN, PAR can verify if NCoA is acceptable 350 to NAR through the exchange of HI and HAck messages. When 351 stateful assignment is used, the proposed NCoA in FBU is carried 352 in HI, and NAR MAY consider assigning the proposed NCoA. In any 353 case, the assigned NCoA MUST be returned in HAck, and PAR MUST in 354 turn provide the assigned NCoA in FBack. If there is an assigned 355 NCoA returned in FBack, the MN MUST use the assigned address 356 (and not the proposed address in FBU) upon attaching to NAR. 357 The HI and HAck protocol exchange to verify NCoA acceptability, 358 among others noted in Section 3.1, can be used even when stateful 359 assignment is not used. 361 2. The MN does not receive FBack on the previous link. One obvious 362 reason for this is that the MN has not sent the FBU. The other 363 reason is that the MN has left the link after sending the FBU 364 (which may be lost) but before receiving an FBack. Without 365 receiving an FBack in the latter case, the MN cannot ascertain 366 whether PAR has successfully processed the FBU. Hence, it 367 (re)sends an FBU as soon as it attaches to NAR. In order to 368 enable NAR to forward packets immediately (when FBU has been 369 processed) and to allow NAR to verify if NCoA is acceptable, the 370 MN SHOULD encapsulate FBU in FNA. If NAR detects that NCoA is in 371 use when processing FNA, for instance while creating a neighbor 372 entry, it MUST discard the inner FBU packet and send a Router 373 Advertisement with ``Neighbor Advertisement Acknowledge (NAACK)'' 374 option in which NAR MAY include an alternate IP address for the 375 MN to use. This discarding avoids the undesirable outcome of 376 address collision, even though the chances of such a collision 377 are extremely low. Detailed FNA processing rules are specified 378 in Section 6.3.3. 380 The scenario in which a MN sends FBU and receives FBack on PAR's link 381 is illustrated in Figure 2. For convenience, this scenario may be 382 characterized as ``predictive'' mode of operation. The scenario in 383 which the MN sends FBU from NAR's link is illustrated in Figure 3. 384 For convenience, this scenario may be characterized as ``reactive'' 385 mode of operation. Note however that the reactive mode includes the 386 case when FBU has been sent from PAR's link but FBack has not been 387 received yet. 389 Finally, the PrRtAdv message may be sent gratuitously, i.e., without 390 the MN first sending RtSolPr. 392 MN PAR NAR 393 | | | 394 |------RtSolPr------->| | 395 |<-----PrRtAdv--------| | 396 | | | 397 |------FBU----------->|--------HI--------->| 398 | |<------HAck---------| 399 | <--FBack---|--FBack---> | 400 | | | 401 disconnect forward | 402 | packets===============>| 403 | | | 404 | | | 405 connect | | 406 | | | 407 |--------- FNA --------------------------->| 408 |<=================================== deliver packets 409 | | 411 Figure 2: ``Predictive'' Fast Handover 413 3.3. Protocol Operation of Network-initiated Handover 415 In some wireless technologies, the handover control may reside in 416 the network even though the decision to undergo handover may be 417 co-operatingly arrived at between the MN and the network. On such 418 network, it is possible for the PAR to send an unsolicited PrRtAdv 419 containing the link address, IP address and subnet prefixes of the 420 NAR when the network decides that a handover is imminent. The MN 421 MUST process this PrRtAdv to configure a new care of address on the 422 new subnet, and MUST send an FBU to PAR prior to switching to the new 423 link. After transmitting the FBU, the PAR MUST continue to forward 424 packets to the MN on its current link until the FBU is received. The 425 rest of the operation is the same as that described in Section 3.2. 427 MN PAR NAR 428 | | | 429 |------RtSolPr------->| | 430 |<-----PrRtAdv--------| | 431 | | | 432 disconnect | | 433 | | | 434 | | | 435 connect | | 436 |------FNA[FBU]-------|------------------->| 437 | |<-----FBU-----------| 438 | |------FBack-------->| 439 | forward | 440 | packets===============>| 441 | | | 442 |<=================================== deliver packets 443 | | 445 Figure 3: ``Reactive'' Fast Handover 447 An alternative use of the unsolicited PrRtAdv is to allow the network 448 to inform the MN about geographically adjacent subnets without the 449 MN having to explicitly request that information. This can reduce 450 the amount of wireless traffic required for the MN to obtain a 451 neighborhood links and subnet topology map. Such usage of PrRtAdv is 452 decoupled from the actual handover. Exactly how to reconcile this 453 function with the use of PrRtAdv as a handover trigger is a topic for 454 future experimental work. 456 4. Protocol Details 458 All description makes use of Figure 1 as the reference. 460 After discovering nearby access points, the MN sends RtSolPr in order 461 to resolve access point identifiers to subnet router information. 462 A convenient time to do this is after performing router discovery. 463 However, the MN MAY send RtSolPr at any time during its attachment to 464 PAR. The trigger for sending RtSolPr can emanate from a link-specific 465 event, such as the promise of better signal strength from another 466 access point coupled with fading signal quality with the current 467 access point. Such events, often broadly called as ``L2 triggers'', 468 are outside the scope of this document. Nevertheless, they serve 469 as important events that invoke the protocol. For instance, when 470 a ``link up'' indication is obtained on the new link, the protocol 471 messages (e.g., FNA) can be immediately transmitted. Implementations 472 SHOULD make use of such triggers whenever available. 474 The RtSolPr message may contain one or more AP-IDs. A wildcard 475 requests all available tuples. When the MN has knowledge of an 476 impending handover, it MAY set the `U' bit in RtSolPr to request PAR 477 to start buffering its packets. 479 As a response to RtSolPr, PAR sends a PrRtAdv message which indicates 480 one of the following possible conditions. 482 1. If the PAR does not have an entry corresponding to the new 483 attachment point, it MUST respond indicating that the new 484 point of attachment is unknown. The MN MUST stop fast handover 485 protocol operations on the current link. The MN MAY send an FBU 486 from its new link. 488 2. If the new point of attachment is connected to the PAR itself, 489 PAR MUST respond indicating that the point of attachment is known 490 but is connected to itself. This could happen, for example, when 491 the wireless access points are bridged into a wired network. No 492 further protocol action is necessary. 494 3. If the new point of attachment is known and the PAR has 495 information about it, then PAR MUST respond indicating that the 496 point of attachment is known. The message MUST contain the NCoA 497 that the MN should use or the network prefix that should be used 498 to form NCoA. If the new point of attachment is known, but does 499 not support fast handover, the PAR MUST indicate this with Code 3 500 (See Section 6.1.2). 502 4. If a wildcard is supplied as an identifier for the new point of 503 attachment, the PAR SHOULD supply neighborhood [AP, AR] tuples 504 subject to path MTU restrictions (i.e., provide any `n' tuples 505 without exceeding the link MTU). 507 If the `U' bit is set in RtSolPr, PAR MAY buffer incoming packets 508 in FIFO order but MUST continue forwarding packets to PCoA on 509 PAR's link. It SHOULD stop buffering after processing the FBU 510 message. The size of the buffer and the duration of buffering 511 are implementation-specific considerations. If the new point of 512 attachment belongs to itself, PAR MAY chose to ignore buffering. 514 The method by which Access Routers exchange information about 515 their neighbors and thereby allow construction of PrRtAdvs with 516 information about the new subnet is outside the scope of this 517 document. Furthermore, this document assumes that the access routers 518 share necessary security association established by means outside the 519 scope of this document. 521 The RtSolPr and PrRtAdv messages MUST be implemented by a MN and 522 an access router that supports fast handovers. However, when 523 the parameters necessary for the MN to send packets immediately 524 upon attaching to the NAR are supplied by the link layer handover 525 mechanism itself, the above messages are optional on such link 526 layers. 528 Sometime after PrRtAdv is received, the MN sends FBU in which it 529 includes the proposed NCoA. The MN SHOULD send FBU from PAR's link 530 whenever feasible, i.e., whenever ``anticipation'' of handover is 531 feasible. When anticipation is not feasible or if has not received 532 an FBack yet, the MN sends FBU immediately after attaching to NAR's 533 link. In addition, this FBU SHOULD be encapsulated in a FNA message 534 in order to allow NAR to first verify if NCoA is in use already 535 before it can forward the (inner) FBU packet to PAR. In response to 536 FBU, PAR establishes a binding between PCoA (``Home Address'') and 537 NCoA, and sends FBack to MN. Prior to establishing this binding, PAR 538 SHOULD send a HI message to NAR, and receive HAck in response. 540 The HI message contains the PCoA, link-layer address and the NCoA of 541 the MN. In response to processing the HI message, the NAR 543 1. verifies if NCoA supplied in the HI message is a valid address 544 for use, and if it is, starts proxying the address. 546 2. allocates NCoA for the MN when stateful address configuration is 547 used, creates a proxy neighbor cache entry and begins defending 548 it. The NAR MAY consider NCoA proposed in HI for allocation. 550 3. MAY create a host route entry for PCoA in case NCoA cannot be 551 accepted or assigned such that the entry allows it to forward 552 packets to the MN. This host route entry SHOULD be implemented 553 such that until the MN's presence is detected, either through 554 explicit announcement by the MN or by other means, arriving 555 packets do not invoke neighbor discovery. The NAR MAY also set 556 up a reverse tunnel to PAR in this case. 558 4. SHOULD start buffering packets if the `U' bit is set. 560 5. provides the status of handover request in Handover Acknowledge 561 (HAck) message. 563 If HAck contains an assigned NCoA, such as in stateful allocation, 564 FBack MUST include it, and the MN MUST use the address provided in 565 FBack. The PAR SHOULD send FBack to previous link as well. The 566 result of FBU and FBack processing is that PAR begins tunneling MN's 567 packets to NCoA. If the MN does not receive an FBack message even 568 after re-transmitting FBU for FBU_RETRIES, it must assume that fast 569 handover support is not available and stop the protocol operation. 571 As soon as the MN establishes link connectivity with the NAR, it 572 SHOULD send a Fast Neighbor Advertisement (FNA) message (See 6.3.3). 573 If the MN has not received an FBack by the time FNA is being sent, it 574 SHOULD encapsulate the FBU in FNA and send them together. 576 When it is acceptable to use NCoA corresponding to the FNA message, 577 the NAR MUST 579 1. delete the proxy neighbor cache entry, if any is present. 581 2. create a neighbor cache entry and set its state to REACHABLE 582 without over-writing an existing entry for a different layer 2 583 address. 585 3. forward any buffered packets 587 4. enable the host route entry, if any is present, for PCoA. 589 If NAR detects that NCoA is in use by another node while processing 590 the FNA, it MUST 592 1. discard the inner (FBU) packet. 594 2. send a Router Advertisement with the NAACK option, and NAR MAY 595 include an alternate NCoA for use 597 If the MN receives a Router Advertisement with a NAACK option, it 598 MUST revert to configuring a new address, and SHOULD use the address, 599 if any is, provided in the NAACK option. Subsequently, the MN 600 SHOULD send an FBU using the new CoA. As a special case, the address 601 supplied in NAACK could be PCoA itself, in which case the MN MUST not 602 send any more FBUs. If no address is present in NAACK option, the MN 603 MUST follow [5] in order to configure a new CoA and SHOULD still send 604 FBU to PAR. 606 Once the MN has confirmed its NCoA, it SHOULD send a Neighbor 607 Advertisement message. This message updates its neighbor's cache 608 entries with the MN's link-layer address. 610 5. Other Considerations 612 5.1. Handover Capability Exchange 614 The MN expects a PrRtAdv in response to its RtSolPr message. If the 615 MN does not receive a PrRtAdv message even after RTSOLPR_RETRIES, it 616 must assume that PAR does not support the fast handover protocol. 617 Similarly, if PAR sends PrRtAdv gratuitously to a MN, but does not 618 receive an FBU even after GR_PRRTADV_RETRIES, it must assume that the 619 MN does not support the fast handover protocol. 621 Even if a MN's current access router is capable of fast handover, 622 the access router into which the MN is handing over to may not 623 be capable of fast handover. This is indicated to the MN during 624 ``runtime'', through the PrRtAdv message with a Code value of 3. See 625 Section 6.1.2. 627 5.2. Determining New Care of Address 629 Typically, the MN formulates its prospective NCoA using the 630 information provided in a PrRtAdv message, and sends FBU. The PAR 631 MUST use the NCoA present in FBU in its HI message. The NAR SHOULD 632 verify if NCoA present in HI is already in use. In any case, NAR 633 MUST respond to HI in the form of a HAck in which it may include a 634 different NCoA to use, especially when stateful address configuration 635 is used. If there is an address present in HAck, PAR MUST convey it 636 to the MN in the FBack message. 638 If PrRtAdv message carries a NCoA, the MN MUST use it as its 639 prospective NCoA. 641 5.3. Packet Loss 643 Handover involves link switching. It is understandably difficult 644 to exactly co-ordinate fast handover signaling with link switching. 645 Furthermore, arrival pattern of packets is dependent on many factors, 646 including application characteristics, network queuing behavior etc. 647 Hence, packets may arrive at NAR before the MN is able to attach to 648 it. These packets will be lost unless they are buffered by the NAR. 649 Similarly, if the MN attaches to NAR and then sends an FBU message, 650 packets arriving at PAR will be lost unless they are buffered. This 651 protocol provides an option to indicate request for buffering at the 652 NAR in the HI message. When the PAR does request this feature, it 653 SHOULD also provide its own support for buffering. 655 5.4. DAD Handling 657 Duplicate Address Detection (DAD) was defined in [5] to avoid address 658 duplication on links when stateless address auto- configuration is 659 used. The use of DAD to verify the uniqueness of an IPv6 address 660 configured through stateless autoconfiguration adds delays to a MIPv6 661 handover. 663 The probability of an interface identifier duplication on the 664 same subnet is very low, however it can not be ignored. In this 665 draft certain precautions are proposed to minimize the effects of 666 a duplicate address occurrence. On links wherein the uniqueness 667 of the interface identifier is ensured within the subnet (by means 668 beyond the scope of this document), DAD handling procedures SHOULD be 669 avoided. 671 In some cases the NAR may already have the knowledge required to 672 assess whether the MN's address is a duplicate or not before the MN 673 moves to the new subnet. For example, the NAR can have a list of all 674 nodes on its subnet, perhaps for access control, and by searching 675 this list, it can confirm whether the MN's address is a duplicate 676 or not. The result of this search is sent back to the PAR in the 677 HACK message. If such knowledge is not available at the NAR, it 678 may indicate this by not confirming NCoA in the HACK message. The 679 NAR may also indicate this in the NAACK option as a response to the 680 FNA message. In such cases, the MN would have to follow stateless 681 address configuration rules after attaching to the NAR. 683 5.5. Fast or Erroneous Movement 685 Although this specification is for fast handover, the protocol has 686 its limits in terms of how fast a MN can move. A special case 687 of fast movement is ping-pong, where a MN moves between the same 688 two access points rapidly. Another instance of the same problem 689 is erroneous movement i.e., the MN receives information prior to 690 a handover that it is moving to a new access point and but it is 691 either moved to a different one or it aborts movement altogether. 692 All of the above behaviors are usually the result of link layer 693 idiosyncrasies and thus are often tackled at the link layer itself. 695 IP layer mobility, however, introduces its own limits. IP layer 696 handovers should be in a frequency that allows enough time for the 697 MN to update the binding of, at least, its HA and preferably that 698 of every CN with which it is in communication. A MN that moves 699 faster than necessary for this signaling to complete, which may be 700 of the order of few seconds, may start losing packets and ultimately 701 connectivity. The signaling overhead over the air and in the network 702 may increase significantly, especially in the case of rapid movement 703 between two access routers. To avoid the signaling overhead, the 704 following measures are suggested. 706 A MN returning to the PAR before updating the necessary bindings when 707 present on NAR MUST send a Fast Binding Update with Home Address 708 equal to the MN's PCoA and a lifetime of zero, to the PAR. The MN 709 should have a security association with the PAR since it performed 710 a fast handover from it to the NAR. The PAR, on receiving this Fast 711 Binding Update, will check its set of outgoing (temporary fast 712 handover) tunnels and if it finds a match it SHOULD drop that tunnel; 713 i.e., stop forwarding packets for this MN and start delivering 714 packets directly to the node instead. The MN SHOULD NOT make any 715 attempt to use any of the fast handover mechanisms described in this 716 specification and SHOULD revert back to standard Mobile IPv6. 718 Temporary tunnels for the purposes of fast handovers should use short 719 lifetimes (in the order of a small number of seconds or less). The 720 lifetime of such tunnels should be enough to allow a MN to update all 721 its active bindings. 723 Erroneous movement is not likely to damage the network but it may 724 cause loss of packets since routing can change and the PAR may 725 forward packets towards another AR before the MN actually connects 726 to that AR. If the MN discovers itself on an unanticipated AR, a 727 Fast Binding Update to the PAR SHOULD be sent. Since Fast Binding 728 Updates are authenticated, they MUST supersede the existing binding 729 and packets SHOULD be redirected to the new confirmed location of the 730 MN. No attempt should be made to recover packets from the AR the MN 731 was supposed to connect to. 733 6. Message Formats 735 6.1. New Neighbor Discovery Messages 737 6.1.1. Router Solicitation for Proxy 739 Mobile Nodes send Router Solicitation for Proxy in order to prompt 740 routers for Proxy Router Advertisements. For all the ICMP messages, 741 the checksum is defined in [2]. 743 IP Fields: 745 Source Address 746 An IP address assigned to the sending interface 748 Destination Address 749 The address of the Access Router or the all routers 751 0 1 2 3 752 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 753 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 754 | Type | Code | Checksum | 755 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 756 | Identifier |U| Reserved | 757 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 758 | Options ... 759 +-+-+-+-+-+-+-+-+-+-+-+- 761 Figure 4: Router Solicitation for Proxy (RtSolPr) Message 763 multicast address. 765 Hop Limit 255 767 Authentication Header 768 If a Security Association for the IP Authentication 769 Header exists between the sender and the 770 destination address, then the sender SHOULD include 771 this header. 773 ICMP Fields: 775 Type TBA 777 Code 0 779 Checksum The ICMP checksum. 781 Identifier MUST be set by the sender so that replies can be 782 matched to this Solicitation. 784 `U' bit If set, requests access router to also buffer 785 arriving packets 787 Reserved MUST be set to zero by the sender and ignored by 788 the receiver. 790 Valid Options: 792 Source link-layer address 793 The link-layer address of the sender, if known. 795 It SHOULD be included on link layers that have 796 addresses. 798 New Attachment Point Link-Layer Address 799 The link-layer address or identification of the 800 attachment point for which the MN requests routing 801 advertisement information. It MUST be included 802 in all RtSolPr messages. More than one such address 803 or identifier can be present. This field can also 804 be a wildcard address with all bits set to zero. 806 Future versions of this protocol may define new option types. 807 Receivers MUST silently ignore any options that they do not recognize 808 and continue processing the rest of the message. 810 A MN sends this message if it wishes to initiate fast handover. It 811 indicates its destination with the New Attachment Point Link-Layer 812 Address. A Proxy Router Advertisement message should be received in 813 response. If such a message is not received in a short time period 814 but no less than twice the typical round trip time (RTT) over the 815 access link or 100 ms if RTT is not known, it SHOULD resend RtSolPr 816 message at most RTSOLPR_RETRIES, waiting for the same time during 817 each instance of retransmission. If Proxy Router Advertisement is 818 not received by the time the MN disconnects from the PAR, the MN 819 SHOULD send FBU immediately after configuring a new CoA. 821 6.1.2. Proxy Router Advertisement (PrRtAdv) 823 Access routers send out Proxy Router Advertisement message 824 gratuitously if the handover is network-initiated or as a response 825 to RtSolPr message from a MN, providing the link-layer address, IP 826 address and subnet prefixes of neighboring routers. This avoids the 827 MN having to solicit Router Advertisement when it connects to the new 828 subnet. 830 IP Fields: 832 Source Address 833 MUST be the link-local address assigned to the 834 interface from which this message is sent. 836 Destination Address 837 The Source Address of an invoking Router 838 Solicitation for Proxy or the address of the node 839 the Access Router is instructing to handover. 841 Hop Limit 255 842 0 1 2 3 843 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 844 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 845 | Type | Code | Checksum | 846 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 847 | Identifier | Reserved | 848 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 849 | Options ... 850 +-+-+-+-+-+-+-+-+-+-+-+- 852 Figure 5: Proxy Router Advertisement (PrRtAdv) Message 854 Authentication Header 855 If a Security Association for the IP Authentication 856 Header exists between the sender and the 857 destination address, then the sender SHOULD include 858 this header. 860 ICMP Fields: 862 Type TBA 864 Code 0, 1, or 2 866 Checksum The ICMP checksum. 868 Identifier Copied from Router Solicitation for Proxy or set to 869 Zero if unsolicited. 871 Reserved MUST be set to zero by the sender and ignored by 872 the receiver. 874 Valid Options: 876 Source link-layer address 877 The link-layer address of the sender, if known. 878 It SHOULD be included on link layers that have 879 addresses. 881 Link-layer address of proxied originator (i.e., NAR) 882 The link-layer address of the Access Router for 883 which this message is proxied for. This option MUST 884 be included when Code is 0. 886 New Router Prefix Information Option. 887 These options specify the prefixes of the Access 888 Router the message is proxied for and are used 889 for address autoconfiguration. This option SHOULD be 890 included when Code is 0. 892 New CoA Option 893 When PrRtAdv is sent gratuitously, this option MUST 894 be included. Otherwise, this option MAY be present. 896 Future versions of this protocol may define new option types. 897 Receivers MUST silently ignore any options they do not recognize and 898 continue processing the message. 900 A Proxy Router Advertisement with Code 0 but without a New CoA Option 901 means that the MN SHOULD construct a NCoA out of its Interface ID 902 (used in the Destination Address in this Proxy Router Advertisement) 903 and the Prefix in the New Router Prefix Information Option (See 904 Section 6.4.2. A Proxy Router Advertisement with Code 0 and a New 905 CoA Option means that the MN SHOULD use the supplied NCoA or else 906 stand to loose service. 908 A Proxy Router Advertisement with Code 1 is sent if handover to the 909 New Attachment Point, as indicated by the New Attachment Point Link 910 Layer address in the corresponding RtSolPr message, does not require 911 change of CoA. No options are required in this case. 913 A Proxy Router Advertisement with Code 2 means that the PAR is not 914 aware of the Prefix Information requested. The MN SHOULD attempt to 915 send FBU as soon as it regains connectivity with the NAR. No options 916 are required in this case. 918 A Proxy Router Advertisement with Code 3 means that the NAR does 919 not support fast handover. The MN MUST stop fast handover protocol 920 operations. No options are required in this case. 922 When a wildcard AP identifier is supplied in the RtSolPr message, 923 the PrRtAdv message should include any 'n' [Access Point Identifier, 924 Link-layer address option, Prefix Information Option] tuples 925 corresponding to the PAR's neighborhood. 927 6.2. Inter-Access Router Messages 929 6.2.1. Handover Initiate (HI) 931 The Handover Initiate (HI) is a new ICMPv6 message sent by an Access 932 Router (typically PAR) to another Access Router (typically NAR) to 933 initiate the process of a MN's handover. 935 0 1 2 3 936 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 937 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 938 | Type | Code | Checksum | 939 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 940 | Identifier |S|U| Reserved | 941 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 942 | Options... 943 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 945 Figure 6: Handover Initiate (HI) Message 947 IP Fields: 949 Source Address 950 The IP address of the PAR 952 Destination Address 953 The IP address of the NAR 955 Hop Limit 255 957 Authentication Header 958 A Security Association MUST exist between the 959 sender and the receiver of this message. This 960 message MUST be authenticated and so the authentication 961 header MUST be used when this message is sent. 963 ICMP Fields: 965 Type TBA 967 Code 0 968 Checksum The ICMP checksum. 970 Identifier MUST be set by the sender so replies can be matched 971 to this message. 973 S Stateful address configuration flag. When set, this 974 message requests a new CoA to be returned by the 975 destination. 977 U Buffer flag. When set, the destination SHOULD buffer 978 any packets towards the node indicated in the options 979 of this message. 981 Reserved MUST be set to zero by the sender and ignored by 982 the receiver. 984 Valid Options: 986 Link-layer address of MN 987 The link-layer address of the MN that is 988 undergoing handover to the destination. This option 989 SHOULD be included to help the destination 990 recognize the MN when it connects to the 991 destination. 993 Previous Care of Address 994 The IP address used by the MN while 995 attached to the originating router. This option 996 SHOULD be included so that host route can be 997 established in case necessary. 999 New Care of Address 1000 The IP address the MN wishes to use when 1001 connected to the destination. When the `S' bit is 1002 set, NAR MAY use this address in its stateful 1003 assignment. 1005 If Handover Acknowledge (HAck) message is not received as a response, 1006 the Handover Initiate SHOULD be re-sent up to HI_RETRIES times using 1007 a short retransmission timer with a value no less than twice the 1008 round trip time between source and destination or 100 ms if RTT is 1009 not known. 1011 6.2.2. Handover Acknowledge (HAck) 1013 The Handover Acknowledgment message is a new ICMPv6 message that MUST 1014 be sent (typically by NAR to PAR) as a reply to the Handover Initiate 1015 message. 1017 0 1 2 3 1018 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 1019 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1020 | Type | Code | Checksum | 1021 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1022 | Identifier |H|T|R| Reserved | 1023 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1024 | Options... 1025 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 1027 Figure 7: Handover Acknowledge (HAck) Message 1029 IP Fields: 1031 Source Address 1032 Copied from the destination address of the Handover 1033 Initiate Message to which this message is a 1034 response. 1036 Destination Address 1037 Copied from the source address of the Handover 1038 Initiate Message to which this message is a 1039 response. 1041 Hop Limit 255 1043 Authentication Header 1044 A Security Association MUST exist between the 1045 sender and the receiver of this message. This message 1046 MUST be authenticated and so the authentication 1047 header MUST be used when this message is sent. 1049 ICMP Fields: 1051 Type TBA 1052 Code 1053 0: Handover Accepted, NCoA valid 1054 1: Handover Accepted, NCoA not valid 1055 2: Handover Accepted, NCoA in use 1056 3: Handover Accepted, NCoA assigned (Stateful) 1057 4: Handover Accepted, NCoA not assigned (Stateful) 1058 128: Handover Not Accepted, reason unspecified 1059 129: Administratively prohibited 1060 130: Insufficient resources 1062 Checksum The ICMP checksum. 1064 Identifier Copied from the corresponding field in the Handover 1065 Initiate message this message is in response to. 1067 Reserved MUST be set to zero by the sender and ignored by 1068 the receiver. 1070 Valid Options: 1072 New Care of Address 1073 If the S flag in the Handover Initiate message is set, 1074 this option MUST be used to provide NCoA the MN should 1075 use when connected to this router. This option MAY be 1076 included even when `S' bit is not set, e.g., Code 2 1077 above. 1079 Upon receiving the HI message, the NAR MUST respond with a Handover 1080 Acknowledge message. If the `S' flag is set in the HI message, the 1081 NAR SHOULD include the New Care of Address option and a Code of 3. 1083 If the `S' flag is not set in the HI message, the NAR MUST check the 1084 validity of the NCoA when sent with HI, and reply with appropriate 1085 Code values enumerated above. If NCoA is valid, the NAR SHOULD 1086 insert NCoA in its Proxy Neighbor Cache and defend NCoA for 1087 PROXY_ND_LIFETIME period of time during which the MN is expected to 1088 connect to NAR. If the NCoA is not valid or not assigned, the NAR 1089 MUST respond with an appropriate Code value. 1091 The NAR MAY provide support for PCoA (instead of accepting or 1092 assigning NCoA) and establish a host route entry for PCoA, and set up 1093 a tunnel to the PAR to forward MN's packets sent with PCoA as source 1094 IP address. This host route entry SHOULD be used to forward packets 1095 once the NAR detects that the particular MN is attached to its link. 1097 Finally, the new access router can always refuse handover, in which 1098 case it should indicate the reason in one of the available Code 1099 values. 1101 6.3. New Mobility Header Messages 1103 Mobile IPv6 uses a new IPv6 header type called Mobility Header [3]. 1104 The Fast Binding Update, Fast Binding Acknowledgment and Fast 1105 Neighbor Advertisement messages use the Mobility Header. 1107 6.3.1. Fast Binding Update (FBU) 1109 The Fast Binding Update message is identical to the Mobile IPv6 1110 Binding Update (BU) message. However, the processing rules are 1111 slightly different. The Mobility Header Type value for FBU is 8. 1113 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1114 | Sequence # | 1115 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1116 |A|H|L|K| Reserved | Lifetime | 1117 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1118 | | 1119 . . 1120 . Mobility options . 1121 . . 1122 | | 1123 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1125 Figure 8: Fast Binding Update (FBU) Message 1127 IP fields: 1129 Source address The PCoA or NCoA 1131 Destination Address 1132 The IP address of the Previous Access 1133 Router 1135 `A' flag MUST be set to one to request PAR to send a Fast 1136 Binding Acknowledgement message. 1138 `H' flag MUST be set to one. See [3]. 1140 `L' flag See [3]. 1142 `K' flag See [3]. 1144 Reserved This field is unused. MUST be set zero. 1146 Sequence Number See [3]. 1148 Lifetime See [3]. 1150 Mobility Options 1151 MUST contain alternate CoA option set to NCoAIP 1152 address when sent FBU is sent from PAR's link. 1153 MAY contain alternate CoA option set to NCoA when 1154 FBU is sent from NAR's link. 1156 The MN sends FBU message any time after receiving a PrRtAdv message. 1157 If the MN moves prior to receiving a PrRtAdv message, it SHOULD send 1158 a FBU to the PAR after configuring a new CoA on the NAR. 1160 The source IP address is PCoA when FBU is sent from PAR's link, and 1161 the source IP address is NCoA when sent from NAR's link. When FBU is 1162 sent from NAR's link, it SHOULD be encapsulated within FNA. 1164 The FBU MUST also include the Home Address Option and the Home 1165 Address is PCoA. A FBU message MUST be protected in a way appropriate 1166 for MN and PAR communication. That is, PAR MUST be able to determine 1167 that the FBU message is sent by a genuine MN. 1169 6.3.2. Fast Binding Acknowledgment (FBack) 1171 The Fast Binding Acknowledgment message is sent by the PAR to 1172 acknowledge receipt of a Fast Binding Update message in which the `A' 1173 bit is set. The Fast Binding Acknowledgment message SHOULD NOT be 1174 sent to the MN before the PAR receives a HAck message from the NAR. 1175 The Fast Binding Acknowledgment MAY also be sent to the MN on the old 1176 link. The Mobility Header Type value for FBACK is 9. 1178 IP fields: 1180 Source address The IP address of the Previous Access 1181 Router 1183 Destination Address The NCoA 1185 Status 1186 8-bit unsigned integer indicating the 1187 disposition of the Fast Binding Update. Values 1188 of the Status field less than 128 indicate that 1189 the Binding Update was accepted by the receiving 1190 node. The following such Status values are 1191 currently defined: 1193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1194 | Status |K| Reserved | 1195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1196 | Sequence # | Lifetime | 1197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1198 | | 1199 . . 1200 . Mobility options . 1201 . . 1202 | | 1203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1205 Figure 9: Fast Binding Acknowledgment (FBack) Message 1207 0 Fast Binding Update accepted 1208 1 Fast Binding Update accepted but NCoA is 1209 invalid. Use NCoA supplied in ``alternate'' 1210 (e.g., stateful) CoA 1212 Values of the Status field greater than or equal 1213 to 128 indicate that the Binding Update was 1214 rejected by the receiving node. The following 1215 such Status values are currently defined: 1217 128 Reason unspecified 1218 129 Administratively prohibited 1219 130 Insufficient resources 1220 131 Incorrect interface identifier length 1222 `K' flag See [3]. 1224 Reserved An unused field. MUST be set to zero. 1226 Sequence Number Copied from FBU message for use by the MN in 1227 matching this acknowledgment with an outstanding 1228 FBU. 1230 Lifetime 1231 The granted lifetime in seconds for which the 1232 sender of this message will retain a binding for 1233 traffic redirection. 1235 Mobility Options MUST contain ``alternate'' CoA if Status is 1. 1237 6.3.3. Fast Neighbor Advertisement (FNA) 1239 A MN sends a Fast Neighbor Advertisement to announce itself to the 1240 NAR. The Mobility Header Type value for FBACK is 10. When the 1241 Mobility Header Type is FNA, the Payload Proto field may be set to 1242 IPv6 in order to assist FBU encapsulation. 1244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1245 | Reserved | 1246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1247 . . 1248 . Mobility Options . 1249 . . 1250 | | 1251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1253 Figure 10: Fast Neighbor Advertisement (FNA) Message 1255 IP fields: 1257 Source address NCoA 1259 Destination Address NAR's IP address 1261 Mobility Options MUST contain the Link-Layer Address 1263 The MN sends Fast Neighbor Advertisement to the NAR, as soon as it 1264 regains connectivity on the new link to announce its attachment so 1265 that arriving or buffered packets can be immediately forwarded. If 1266 NAR is proxying NCoA, it creates a neighbor cache entry in REACHABLE 1267 state. If there is no entry at all, it creates one and sets it 1268 to REACHABLE. If there is an entry in INCOMPLETE state without a 1269 link-layer address, it sets it to REACHABLE. During the process of 1270 creating a neighbor cache entry, NAR can also detect if NCoA is in 1271 use, thus avoiding address collisions. Since FBU is encapsulated 1272 within FNA when sent from NAR's link, NAR drops FBU in case it 1273 detects any collision. 1275 The combination of NCoA (present in source IP address) and the 1276 Link-Layer Address (present as a Mobility Option) SHOULD be used to 1277 distinguish the MN from other nodes. 1279 6.4. New ICMP Options 1281 6.4.1. IP Address Option 1283 This option is sent in the Proxy Router Advertisement, the Handover 1284 Initiate, and Handover Acknowledge messages. The Proxy Router 1285 Advertisement and Handover Acknowledgment messages only contain the 1286 NCoA while the Handover Initiate message may include both NCoA and 1287 PCoA. The format is based on [4]. 1289 0 1 2 3 1290 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 1291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1292 | Type | Length | Sub-Type | Prefix Length | 1293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1294 | Reserved | 1295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1296 | | 1297 + + 1298 | | 1299 + IPv6 Address + 1300 | | 1301 + + 1302 | | 1303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1305 Figure 11: IPv6 Address Option 1307 Type 1308 TBA 1310 Length 1311 size of this option units of 8 octets (i.e., 3) 1313 Sub-Type 1314 1 Old Care-of Address 1315 2 New Care-of Address 1317 Prefix Length 1318 The Length of the IPv6 Address Prefix 1320 IPv6 address 1321 The IP address for the unit defined by the Type field. 1323 6.4.2. New Router Prefix Information Option 1325 This option is sent in the PrRtAdv message in order to provide the 1326 prefix information valid on the NAR. 1328 0 1 2 3 1329 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 1330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1331 | Type | Length | Sub-Type | Prefix Length | 1332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1333 | | 1334 + + 1335 | | 1336 + Prefix + 1337 | | 1338 + + 1339 | | 1340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1342 Figure 12: New Router Prefix Information Option 1344 Type 1345 TBA 1347 Length 1348 The length of the option (including the type, sub-type and 1349 length fields) in units of 8 octets. 1351 Sub-Type 1352 0 1354 Prefix Length 1355 8-bit unsigned integer. The number of leading bits in the 1356 Prefix that are valid. The value ranges from 0 to 128. 1358 Prefix 1359 An IP address or a prefix of an IP address. The Prefix Length 1360 field contains the number of valid leading bits in the prefix. 1361 The bits in the prefix after the prefix length are reserved 1362 and MUST be initialized to zero by the sender and ignored by 1363 the receiver. 1365 6.4.3. Link-layer Address (LLA) 1367 0 1 2 3 1368 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 1369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1370 | Type | Length | Sub-Type | LLA ... 1371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1373 Figure 13: Link-Layer Address Option 1375 Type 1376 TBA 1378 Length 1379 The length of the option (including the type, sub-type and 1380 length fields) in units of 8 octets. 1382 Sub-Type 1383 0 wildcard requesting resolution for all nearby access points 1384 1 Link-layer Address of the new Attachment Point. 1385 2 Link-layer Address of the MN. 1386 3 Link-layer Address of the Proxied Originator 1388 LLA 1389 The variable length link-layer address. 1391 The New Attachment Point Link Layer address contains the link-layer 1392 address of the attachment point for which handover is about to 1393 be attempted. This is used in the Router Solicitation for Proxy 1394 message. 1396 The MN Link-Layer address option contains the link-layer address of a 1397 MN. It is used in the Handover Initiate message. 1399 The Proxied Originator Link-Layer address option contains the 1400 Link Layer address of the Access Router for which the Proxy Router 1401 Solicitation message refers to. 1403 These options MUST be silently ignored when used with other Neighbor 1404 Discovery messages. 1406 6.4.4. Neighbor Advertisement Acknowledgment (NAACK) 1408 0 1 2 3 1409 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 1410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1411 | Type | Length | Sub-Type | Status | 1412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1414 Figure 14: Neighbor Advertisement Acknowledgment Option 1416 Type 1417 TBA 1419 Length 1420 8-bit unsigned integer. Length of the option, in 8 octets, 1421 excluding the Option Type and Option Length fields. 1423 Sub-Type 1424 0 1426 Status 1427 8-bit unsigned integer indicating the disposition of the Fast 1428 Binding Update. Values of the Status field less than 128 1429 indicate that the Binding Update was accepted by the receiving 1430 node. The following such Status values are currently defined: 1432 0 The New CoA is valid 1433 1 The New CoA is invalid 1434 2 The New CoA is invalid, use the supplied CoA 1435 128 Link Layer Address unrecognized 1437 The NAR responds to FNA with the NAACK option to notify the MN 1438 to use a different NCoA when there is address collision. If the 1439 NCoA is invalid, the Router Advertisement MUST use the PCoA as the 1440 destination address, available from the HI message. The MN SHOULD 1441 use the NCoA supplied along with the NAACK option. If the NAACK 1442 indicates that the Link Layer Address is unrecognized the MN MUST NOT 1443 use the NCoA or the PCoA and SHOULD start immediately the process of 1444 acquiring a NCoA at the NAR. 1446 In the future, new option types may be defined. 1448 7. Configurable Parameters 1450 Parameter Name Default Value Definition 1451 ------------------- ---------------------- ------- 1452 RTSOLPR_RETRIES 2 1453 GR_PRRTADV_RETRIES 2 1454 FBU_RETRIES 3 Section 4 1455 PROXY_ND_LIFETIME 1 second Section 6.2.2 1456 HI_RETRIES 4 Section 6.2.1 1458 8. Security Considerations 1460 The following security vulnerabilities are identified, and suggested 1461 solutions mentioned. 1463 1. Insecure FBU: in this case, packets meant for one address could 1464 be stolen, or redirected to some unsuspecting node. This concern 1465 is the same as that in a MN and Home Agent relationship. 1467 Hence, the PAR MUST ensure that the FBU packet arrived from a 1468 node that legitimately owns the PCoA. The access router and its 1469 hosts may use any available mechanism to establish a security 1470 association which MUST be used to secure FBU. The current version 1471 of this protocol does not specify how this security association 1472 is established. However, the future work, either as part of this 1473 document or in a separate document, may specify this security 1474 establishment. 1476 If an access router can ensure that the source IP address in 1477 an arriving packet could only have originated from the node 1478 whose link-layer address is in the router's neighbor cache, then 1479 a bogus node cannot use a victim's IP address for malicious 1480 redirection of traffic. Such an operation is recommended at 1481 least on neighbor discovery messages including the RtSolPr 1482 message. 1484 2. Secure FBU, malicious or inadvertant redirection: in this case, 1485 the FBU is secured, but the target of binding happens to be an 1486 unsuspecting node either due to inadvertant operation or due 1487 to malicious intent. This vulnerability can lead to a MN with 1488 genuine security association with its access router redirecting 1489 traffic to an incorrect address. 1491 However, the target of malicious traffic redirection is limited 1492 to an interface on an access router with which the PAR has a 1493 security association. The PAR MUST verify that the NCoA to 1494 which PCoA is being bound actually belongs to NAR's prefix. 1495 In order to do this, HI and HAck message exchanges are to be 1496 used. When NAR accepts NCoA in HI, it proxies NCoA so that 1497 any arriving packets are not sent on the link until the MN 1498 attaches and announces itself through FNA. So, any inadvertant or 1499 malicious redirection to a host is avoided. It is still possible 1500 to jam NAR's buffer with redirected traffic. However, since 1501 NAR's handover state corresponding to NCoA has a finite (and 1502 short) lifetime corresponding to a small multiple of anticipated 1503 handover latency, this loophole is not significant. 1505 3. Sending FBU from NAR's link: a malicious node may send FBU from 1506 NAR's link providing an unsuspecting node's address as NCoA. 1507 Since FBU is encapsulated in FNA, NAR should detect the collision 1508 with an address in use when processing FNA, and it then drops 1509 FBU. When NAR is unable to detect address collisions, there is a 1510 vulnerability that redirection can affect an unsuspecting node. 1512 9. Contributors 1514 This document originated from the fast handover design team effort. 1515 The members of this design team in alphabetical order were; Gopal 1516 Dommety, Karim El-Malki, Mohammed Khalil, Charles Perkins, Hesham 1517 Soliman, George Tsirtsis and Alper Yegin. 1519 10. Acknowledgments 1521 The editor would like to thank all the interested folks who have 1522 provided feedback on this specification. The editor would like 1523 to acknowledge the contribution from James Kempf to improve this 1524 specification. And, the working group chairs have been very 1525 supportive. 1527 References 1529 [1] S. Bradner. Key words for use in RFCs to Indicate Requirement 1530 Levels. Request for Comments (Best Current Practice) 2119, 1531 Internet Engineering Task Force, March 1997. 1533 [2] A. Conta and S. Deering. Internet Control Message Protocol 1534 (ICMPv6) for the Internet Protocol Version 6 (IPv6) 1535 Specification. Request for Comments (Draft Standard) 2463, 1536 Internet Engineering Task Force, December 1998. 1538 [3] D. Johnson, C. Perkins, and J. Arkko. Mobility Support in IPv6 1539 (work in progress). Internet Draft, Internet Engineering Task 1540 Force, 2002. 1542 [4] M. Khalil, R. Narayanan, H. Akhtar, and E. Qaddoura. Mobile IP 1543 Extensions Rationalization (MIER) (work in progress). Internet 1544 Draft, Internet Engineering Task Force. 1545 draft-ietf-mobileip-mier-05.txt, February 2000. 1547 [5] S. Thomson and T. Narten. IPv6 Stateless Address 1548 Autoconfiguration. Request for Comments (Draft Standard) 1549 2462, Internet Engineering Task Force, December 1998. 1551 A. Change Log 1553 The following changes have taken place since the previous version. 1554 The Section numbers refer to version 06. 1556 - Revised the security considerations section in v07 1558 - Refined and added a section on network-initiated handover v07 1560 - Section 3 format change 1562 - Section 4 format change (i.e., no subsections). 1564 - Description in Section 4.4 merged with ``Fast or Erroneous 1565 Movement'' 1567 - Section 4.5 deprecated 1569 - Section 4.6 deprecated 1571 - Revision of some message formats in Section 6 1573 B. Contact Information 1575 The design team member's contact information: 1577 Gopal Dommety 1578 Cisco Systems, Inc. 1580 170 West Tasman Drive 1581 San Jose, CA 95134 1582 Phone:+1 408 525 1404 1583 E-Mail: gdommety@cisco.com 1585 Karim El Malki 1586 Ericsson Radio Systems AB 1587 LM Ericssons Vag. 8 1588 126 25 Stockholm 1589 SWEDEN 1590 Phone: +46 8 7195803 1591 Fax: +46 8 7190170 1592 E-mail: Karim.El-Malki@era.ericsson.se 1594 Mohamed Khalil 1595 Nortel Networks 1596 E-Mail: mkhalil@nortelnetworks.com 1598 Charles E. Perkins 1599 Communications Systems Lab 1600 Nokia Research Center 1601 313 Fairchild Drive 1602 Mountain View, California 94043 1603 USA 1604 Phone: +1-650 625-2986 1605 E-Mail: charliep@iprg.nokia.com 1606 Fax: +1 650 625-2502 1608 Hesham Soliman 1609 Flarion Technologies 1610 E-mail: H.Soliman@flarion.com 1612 George Tsirtsis 1613 Flarion Technologies 1614 E-Mail: G.Tsirtsis@flarion.com 1616 Alper E. Yegin 1617 NTT DoCoMo Labs USA 1618 E-mail: alper@docomolabs-usa.com 1620 The editor's contact information: 1622 Rajeev Koodli 1623 Nokia Research Center 1624 313 Fairchild Drive 1625 Mountain View, CA 94043 USA 1626 Phone: +1 650 625 2359 1627 Fax: +1 650 625 2502 1628 E-Mail: Rajeev.Koodli@nokia.com