idnits 2.17.1 draft-ietf-mipshop-fast-mipv6-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1.a on line 13. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1920. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1897. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1904. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1910. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 44 longer pages, the longest (page 40) being 73 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 44 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. (A line matching the expected section header was found, but with an unexpected indentation: ' 1. Introduction' ) ** 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.) (A line matching the expected section header was found, but with an unexpected indentation: ' 9. IANA Considerations' ) ** 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 285: '... implementations MUST support the mech...' RFC 2119 keyword, line 286: '...address conflicts and SHOULD use them....' RFC 2119 keyword, line 291: '... feasible, the MN SHOULD send FBU from...' RFC 2119 keyword, line 297: '...irection, the MN SHOULD reverse tunnel...' RFC 2119 keyword, line 298: '...letes Binding Update. And, PAR SHOULD...' (132 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (25 October 2004) is 7123 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) -- Missing reference section? '3' on line 1760 looks like a reference -- Missing reference section? '1' on line 1751 looks like a reference -- Missing reference section? 'AP-ID' on line 1860 looks like a reference -- Missing reference section? 'AR-Info' on line 1860 looks like a reference -- Missing reference section? '6' on line 1772 looks like a reference -- Missing reference section? '7' on line 1776 looks like a reference -- Missing reference section? '4' on line 1764 looks like a reference -- Missing reference section? '2' on line 1755 looks like a reference -- Missing reference section? '5' on line 1768 looks like a reference Summary: 10 errors (**), 0 flaws (~~), 4 warnings (==), 16 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Mipshop Working Group Rajeev Koodli, Editor 2 INTERNET DRAFT Nokia Research Center 3 25 October 2004 5 Fast Handovers for Mobile IPv6 6 draft-ietf-mipshop-fast-mipv6-03.txt 8 This document is an Internet-Draft and is subject to all provisions 9 of section 3 of RFC 3667. By submitting this Internet-Draft, each 10 author represents that any applicable patent or other IPR claims of 11 which he or she is aware have been or will be disclosed, and any of 12 which he or she become aware will be disclosed, in accordance with 13 RFC 3668. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note 17 that other groups may also distribute working documents as 18 Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at 22 any time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This document is a submission of the IETF MIPSHOP WG. Comments should 32 be directed to the MIPSHOP WG mailing list, mipshop@ietf.org. 34 Abstract 36 Mobile IPv6 enables a Mobile Node to maintain its connectivity to 37 the Internet when moving from an Access Router to another, a process 38 referred to as handover. During handover, there is a period when 39 the Mobile Node is unable to send or receive packets due to both 40 link switching delay and IP protocol operations. This ``handover 41 latency'' resulting from standard Mobile IPv6 procedures, namely 42 movement detection, new Care of Address configuration and Binding 43 Update, is often unacceptable to real-time traffic such as Voice 44 over IP. Reducing the handover latency could be beneficial to non 45 real-time, throughput-sensitive applications as well. This document 46 specifies a protocol to improve handover latency due to Mobile IPv6 47 procedures. This document does not address improving the link 48 switching latency. 50 Contents 52 Abstract i 54 1. Introduction 2 56 2. Terminology 2 58 3. Protocol Overview 4 59 3.1. Addressing the Handover Latency . . . . . . . . . . . . . 4 60 3.2. Protocol Operation . . . . . . . . . . . . . . . . . . . 6 61 3.3. Protocol Operation of Network-initiated Handover . . . . 8 63 4. Protocol Details 9 65 5. Miscellaneous 13 66 5.1. Handover Capability Exchange . . . . . . . . . . . . . . 13 67 5.2. Determining New Care of Address . . . . . . . . . . . . . 14 68 5.3. Packet Loss . . . . . . . . . . . . . . . . . . . . . . . 14 69 5.4. DAD Handling . . . . . . . . . . . . . . . . . . . . . . 14 70 5.5. Fast or Erroneous Movement . . . . . . . . . . . . . . . 15 72 6. Message Formats 16 73 6.1. New Neighborhood Discovery Messages . . . . . . . . . . . 16 74 6.1.1. Router Solicitation for Proxy Advertisement 75 (RtSolPr) . . . . . . . . . . . . . . . . . . . . 16 76 6.1.2. Proxy Router Advertisement (PrRtAdv) . . . . . . 18 77 6.2. Inter-Access Router Messages . . . . . . . . . . . . . . 21 78 6.2.1. Handover Initiate (HI) . . . . . . . . . . . . . 21 79 6.2.2. Handover Acknowledge (HAck) . . . . . . . . . . . 23 80 6.3. New Mobility Header Messages . . . . . . . . . . . . . . 25 81 6.3.1. Fast Binding Update (FBU) . . . . . . . . . . . . 25 82 6.3.2. Fast Binding Acknowledgment (FBack) . . . . . . . 27 83 6.3.3. Fast Neighbor Advertisement (FNA) . . . . . . . . 28 84 6.4. New Options . . . . . . . . . . . . . . . . . . . . . . . 29 85 6.4.1. IP Address Option . . . . . . . . . . . . . . . . 30 86 6.4.2. New Router Prefix Information Option . . . . . . 31 87 6.4.3. Link-layer Address (LLA) Option . . . . . . . . . 32 88 6.4.4. Mobility Header Link-layer Address (MH-LLA) Option 33 89 6.4.5. Neighbor Advertisement Acknowledgment (NAACK) . . 34 91 7. Configurable Parameters 35 93 8. Security Considerations 36 95 9. IANA Considerations 37 97 10. Acknowledgments 38 99 11. Normative References 38 101 12. Author's Address 39 103 13. Contributors 39 105 A. Change Log 40 107 Intellectual Property Statement 41 109 Disclaimer of Validity 41 111 Copyright Statement 42 113 Acknowledgment 42 114 1. Introduction 116 Mobile IPv6 [3] describes the protocol operations for a mobile node 117 to maintain connectivity to the Internet during its handover from 118 one access router to another. These operations involve movement 119 detection, IP address configuration, and location update. The 120 combined handover latency is often sufficient to affect real-time 121 applications. Throughput-sensitive applications can also benefit 122 from reducing this latency. This document describes a protocol to 123 reduce the handover latency. 125 This specification addresses the following problem: how to allow a 126 mobile node to send packets as soon as it detects a new subnet link, 127 and how to deliver packets to a mobile node as soon as its attachment 128 is detected by the new access router. The protocol defines IP 129 protocol messages necessary for its operation regardless of link 130 technology. It does this without depending on specific link-layer 131 features while allowing link-specific customizations. By definition, 132 this specification considers handovers that inter-work with Mobile 133 IP: once attached to its new access router, a MN engages in Mobile IP 134 operations including Return Routability [3]. There are no special 135 requirements for a mobile node to behave differently with respect to 136 its standard Mobile IP operations. 138 2. Terminology 140 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 141 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "OPTIONAL", and 142 "silently ignore" in this document are to be interpreted as described 143 in RFC 2119 [1]. 145 The following terminology and abbreviations are used in this 146 document. The reference handover scenario is illustrated in 147 Figure 1. 149 Mobile Node (MN) 150 A Mobile IPv6 host 152 Access Point (AP) 153 A Layer 2 device connected to an IP subnet that offers 154 wireless connectivity to a MN. An Access Point Identifier 155 (AP-ID) refers the AP's L2 address. Sometimes, AP-ID is 156 also referred to as a Base Station Subsystem ID (BSSID). 158 Access Router (AR) 159 The MN's default router 161 Previous Access Router (PAR) 162 The MN's default router prior to its handover 164 New Access Router (NAR) 165 The MN's anticipated default router subsequent to its 166 handover 168 Previous CoA (PCoA) 169 The MN's Care of Address valid on PAR's subnet 171 New CoA (NCoA) 172 The MN's Care of Address valid on NAR's subnet 174 Handover 175 A process of terminating existing connectivity and 176 obtaining new IP connectivity. 178 Router Solicitation for Proxy Advertisement (RtSolPr) 179 A message from the MN to the PAR requesting information 180 for a potential handover 182 Proxy Router Advertisement (PrRtAdv) 183 A message from the PAR to the MN that provides 184 information about neighboring links facilitating 185 expedited movement detection. The message also acts as a 186 trigger for network-initiated handover. 188 (AP-ID, AR-Info) tuple 189 Contains an access router's L2 and IP addresses, and 190 prefix valid on the interface to which the Access Point 191 (identified by AP-ID) is attached. The triplet [Router's 192 L2 address, Router's IP address and Prefix] is called 193 ``AR-Info''. 195 Assigned Addressing 196 A particular type of NCoA configuration in which the NAR 197 assigns an IPv6 address for the MN. The method by which 198 NAR manages its address pool is not specified in this 199 document. 201 Fast Binding Update (FBU) 202 A message from the MN instructing its PAR to redirect its 203 traffic (towards NAR) 205 Fast Binding Acknowledgment (FBack) 206 A message from the PAR in response to FBU 208 Fast Neighbor Advertisement (FNA) 209 A message from the MN to the NAR to announce attachment, 210 and to confirm use of NCoA when the MN has not received 211 FBACK 213 Handover Initiate (HI) 214 A message from the PAR to the NAR regarding a MN's 215 handover 217 Handover Acknowledge (HAck) 218 A message from the NAR to the PAR as a response to HI 220 v +------------+ 221 +-+ | Previous | < 222 | | ---------- | Access | ------ > ----\ 223 +-+ | Router | < \ 224 MN | (PAR) | \ 225 | +------------+ +---------------+ 226 | ^ IP | Correspondent | 227 | | Network | Node | 228 V | +---------------+ 229 v / 230 v +------------+ / 231 +-+ | New | < / 232 | | ---------- | Access | ------ > ----/ 233 +-+ | Router | < 234 MN | (NAR) | 235 +------------+ 237 Figure 1: Reference Scenario for Handover 239 3. Protocol Overview 241 3.1. Addressing the Handover Latency 243 The ability to immediately send packets from a new subnet link 244 depends on the ``IP connectivity'' latency, which in turn depends 245 on the movement detection latency and the new CoA configuration 246 latency. Once a MN is IP-capable on the new subnet link, it can send 247 a Binding Update to its Home Agent and one or more correspondents. 248 Once its correspondents successfully process the Binding Update, 249 which typically involves the Return Routability procedure, the MN can 250 receive packets at the new CoA. So, the ability to receive packets 251 from correspondents directly at its new CoA depends on the Binding 252 Update latency as well as the IP connectivity latency. 254 The protocol enables a MN to quickly detect that it has moved to 255 a new subnet by providing the new access point and the associated 256 subnet prefix information when the MN is still connected to its 257 current subnet (i.e., PAR in Figure 1). For instance, a MN may 258 discover available access points using link-layer specific mechanisms 259 (e.g., a ``scan'' in WLAN) and then request subnet information 260 corresponding to one or more of those discovered access points. The 261 MN may do this after performing router discovery. The MN may also 262 do this at any time while connected to its current router. The 263 result of resolving an identifier associated with an access point is 264 a [AP-ID, AR-Info] tuple, which a MN can use in readily detecting 265 movement: when attachment to an access point with AP-ID takes place, 266 the MN knows the corresponding new router's co-ordinates including 267 its prefix, IP address and L2 address. The ``Router Solicitation 268 for Proxy Advertisement (RtSolPr)'' and ``Proxy Router Advertisement 269 (PrRtAdv)'' messages 6.1 are used for aiding movement detection. 271 Through the RtSolPr and PrRtAdv messages, the MN also formulates a 272 prospective new CoA (NCoA), when it is still present on the PAR's 273 link. Hence, the latency due to new prefix discovery subsequent to 274 handover is eliminated. Furthermore, this prospective address can 275 be used immediately after attaching to the new subnet link (i.e., 276 NAR's link) when the MN has received a ``Fast Binding Acknowledgment 277 (FBack)'' message prior to its movement. In the event it moves 278 without receiving an FBack, the MN can still start using NCoA after 279 announcing its attachment through a ``Fast Neighbor Advertisement 280 (FNA)'' message; NAR responds to FNA in case the tentative address 281 is already in use. In this way, NCoA configuration latency is 282 reduced. Under some limited conditions where the probability of 283 address collision is considered insignificant, it may be possible to 284 use NCoA immediately after attaching to the new link. Even so, all 285 implementations MUST support the mechanism specified in this document 286 to avoid potential address conflicts and SHOULD use them. 288 In order to reduce the Binding Update latency, the protocol specifies 289 a tunnel between the Previous CoA (PCoA) and NCoA. A MN sends a 290 ``Fast Binding Update'' message to its Previous Access Router to 291 establish this tunnel. When feasible, the MN SHOULD send FBU from 292 PAR's link. Otherwise, it should send it immediately after detecting 293 attachment to NAR. Subsequent sections describe the protocol 294 mechanics. In any case, the result is that PAR begins tunneling 295 packets arriving for PCoA to NCoA. Such a tunnel remains active 296 until the MN completes the Binding Update with its correspondents. 297 In the opposite direction, the MN SHOULD reverse tunnel packets 298 to PAR, again until it completes Binding Update. And, PAR SHOULD 299 forward the inner packet in the tunnel to its destination (i.e., to 300 the MN's correspondent). Such a reverse tunnel ensures that packets 301 containing PCoA as source IP address are not dropped due to ingress 302 filtering. Readers may observe that even though the MN is IP-capable 303 on the new link, it cannot use NCoA directly with its correspondents 304 without the correspondents first establishing a binding cache entry 305 (for NCoA). Forwarding support for PCoA is provided through a reverse 306 tunnel between the MN and the PAR. 308 Setting up a tunnel alone does not ensure that the MN receives 309 packets as soon as attaching to a new subnet link, unless NAR can 310 detect the MN's presence. A neighbor discovery operation involving 311 a neighbor's address resolution (i.e., Neighbor Solicitation and 312 Neighbor Advertisement) typically results in considerable delay, 313 sometimes lasting multiple seconds. For instance, when arriving 314 packets trigger NAR to send Neighbor Solicitation before the MN 315 attaches, subsequent re-transmissions of address resolution are 316 separated by a default period of one second each. In order to 317 circumvent this delay, a MN announces its attachment through the FNA 318 message that allows NAR to consider MN to be reachable. If there 319 is no existing entry, FNA allows NAR to create one. If NAR already 320 has an entry, FNA updates the entry while taking potential address 321 conflicts into consideration. Through tunnel establishment for PCoA 322 and fast advertisement, the protocol provides expedited forwarding of 323 packets to the MN. 325 The protocol also provides the following important functionalities. 326 The access routers can exchange messages to confirm that a proposed 327 NCoA is acceptable. For instance, when a MN sends FBU from PAR's 328 link, FBack can be delivered after NAR considers NCoA acceptable 329 to use. This is especially useful when addresses are assigned by 330 the access router. The NAR can also rely on its trust relationship 331 with PAR before providing forwarding support for the MN. That is, 332 it may create a forwarding entry for NCoA subject to ``approval'' 333 from PAR which it trusts. Finally, the access routers could transfer 334 network-resident contexts, such as access control, QoS, header 335 compression, in conjunction with handover. For all these operations, 336 the protocol provides ``Handover Initiate (HI)'' and ``Handover 337 Acknowledge (HAck)'' messages. Both of these messages MUST be 338 supported and SHOULD be used. The access routers MUST have necessary 339 security association established by means outside the scope of this 340 document. 342 3.2. Protocol Operation 344 The protocol begins when a MN sends RtSolPr to its access router 345 to resolve one or more Access Point Identifiers to subnet-specific 346 information. In response, the access router (e.g., PAR in Figure 1) 347 sends a PrRtAdv message which contains one or more [AP-ID, AR-Info] 348 tuples. The MN may send RtSolPr at any convenient time, for instance 349 as a response to some link-specific event (a ``trigger'') or simply 350 after performing router discovery. However, the expectation is that 351 prior to sending RtSolPr, the MN has discovered the available APs 352 by link-specific methods. The RtSolPr and PrRtAdv messages do not 353 establish any state at the access router, and their packet formats 354 are defined in Section 6.1. 356 With the information provided in the PrRtAdv message, the MN 357 formulates a prospective NCoA and sends an FBU message. The purpose 358 of FBU is to authorize PAR to bind PCoA to NCoA, so that arriving 359 packets can be tunneled to the new location of the MN. The FBU SHOULD 360 be sent from PAR's link whenever feasible. For instance, an internal 361 link-specific trigger could enable FBU transmission from the previous 362 link. When it is not feasible, FBU is sent from the new link. Care 363 must be taken to ensure that NCoA used in FBU does not conflict with 364 an address already in use by some other node on link. For this, FBU 365 encapsulation within FNA MUST be implemented and SHOULD be used (See 366 below) when FBU is sent from NAR's link. 368 The format and semantics of FBU processing are specified in 369 Section 6.3.1. 371 Depending on whether an FBack is received or not on the previous 372 link, which clearly depends on whether FBU was sent in the first 373 place, there are two modes of operation. 375 1. The MN receives FBack on the previous link. This means that 376 packet tunneling would already be in progress by the time the 377 MN handovers to NAR. The MN SHOULD send FNA immediately after 378 attaching to NAR, so that arriving as well as buffered packets 379 can be forwarded to the MN right away. 381 Before sending FBack to MN, PAR can determine whether NCoA is 382 acceptable to NAR through the exchange of HI and HAck messages. 383 When assigned addressing (i.e., addresses are assigned by the 384 router) is used, the proposed NCoA in FBU is carried in HI, and 385 NAR MAY assign the proposed NCoA. Such an assigned NCoA MUST be 386 returned in HAck, and PAR MUST in turn provide the assigned NCoA 387 in FBack. If there is an assigned NCoA returned in FBack, the MN 388 MUST use the assigned address (and not the proposed address in 389 FBU) upon attaching to NAR. 391 2. The MN does not receive FBack on the previous link. One reason 392 for this is that the MN has not sent the FBU. The other is that 393 the MN has left the link after sending the FBU, which itself may 394 be lost, but before receiving an FBack. Without receiving an 395 FBack in the latter case, the MN cannot ascertain whether PAR 396 has successfully processed the FBU. Hence, it (re)sends an FBU 397 as soon as it attaches to NAR. In order to enable NAR to forward 398 packets immediately (when FBU has been processed) and to allow 399 NAR to verify if NCoA is acceptable, the MN SHOULD encapsulate 400 FBU in FNA. If NAR detects that NCoA is in use when processing 401 FNA, for instance while creating a neighbor entry, it MUST 402 discard the inner FBU packet and send a Router Advertisement with 403 ``Neighbor Advertisement Acknowledge (NAACK)'' option in which 404 NAR MAY include an alternate IP address for the MN to use. This 405 discarding avoids rare but the undesirable outcome resulting from 406 address collision. Detailed FNA processing rules are specified 407 in Section 6.3.3. 409 The scenario in which a MN sends FBU and receives FBack on PAR's 410 link is illustrated in Figure 2. For convenience, this scenario is 411 characterized as ``predictive'' mode of operation. The scenario in 412 which the MN sends FBU from NAR's link is illustrated in Figure 3. 413 For convenience, this scenario is characterized as ``reactive'' 414 mode of operation. Note that the reactive mode also includes the 415 case when FBU has been sent from PAR's link but FBack has not been 416 received yet. 418 Finally, the PrRtAdv message may be sent unsolicited, i.e., without 419 the MN first sending RtSolPr. This mode is described in Section 3.3. 421 3.3. Protocol Operation of Network-initiated Handover 423 In some wireless technologies, the handover control may reside in 424 the network even though the decision to undergo handover may be 425 co-operatingly arrived at between the MN and the network. In such 426 networks, the PAR can send an unsolicited PrRtAdv containing the link 427 layer address, IP address and subnet prefixes of the NAR when the 428 network decides that a handover is imminent. The MN MUST process 429 this PrRtAdv to configure a new care of address on the new subnet, 430 and MUST send an FBU to PAR prior to switching to the new link. 431 After transmitting PrRtAdv, the PAR MUST continue to forward packets 432 to the MN on its current link until the FBU is received. The rest of 433 the operation is the same as that described in Section 3.2. 435 The unsolicited PrRtAdv also allows the network to inform the MN 436 about geographically adjacent subnets without the MN having to 437 explicitly request that information. This can reduce the amount 438 of wireless traffic required for the MN to obtain a neighborhood 439 topology map of links and subnets. Such usage of PrRtAdv is 440 decoupled from the actual handover. See Section 6.1.2. 442 MN PAR NAR 443 | | | 444 |------RtSolPr------->| | 445 |<-----PrRtAdv--------| | 446 | | | 447 |------FBU----------->|--------HI--------->| 448 | |<------HAck---------| 449 | <--FBack---|--FBack---> | 450 | | | 451 disconnect forward | 452 | packets===============>| 453 | | | 454 | | | 455 connect | | 456 | | | 457 |--------- FNA --------------------------->| 458 |<=================================== deliver packets 459 | | 461 Figure 2: ``Predictive'' Fast Handover 463 4. Protocol Details 465 All description makes use of Figure 1 as the reference. 467 After discovering one or more nearby access points, the MN sends 468 RtSolPr in order to resolve access point identifiers to subnet router 469 information. A convenient time to do this is after performing router 470 discovery. However, the MN can send RtSolPr at any time, e.g., when 471 one or more new access points are discovered. The MN can also send 472 RtSolPr more than once during its attachment to PAR. The trigger for 473 sending RtSolPr can originate from a link-specific event, such as the 474 promise of better signal strength from another access point coupled 475 with fading signal quality with the current access point. Such 476 events, often broadly referred to as ``L2 triggers'', are outside 477 the scope of this document. Nevertheless, they serve as events that 478 invoke this protocol. For instance, when a ``link up'' indication 479 is obtained on the new link, protocol messages (e.g., FNA) can be 480 immediately transmitted. Implementations SHOULD make use of such 481 triggers whenever available. 483 MN PAR NAR 484 | | | 485 |------RtSolPr------->| | 486 |<-----PrRtAdv--------| | 487 | | | 488 disconnect | | 489 | | | 490 | | | 491 connect | | 492 |------FNA[FBU]-------|------------------->| 493 | |<-----FBU-----------| 494 | |------FBack-------->| 495 | forward | 496 | packets===============>| 497 | | | 498 |<=================================== deliver packets 499 | | 501 Figure 3: ``Reactive'' Fast Handover 503 The RtSolPr message contains one or more AP-IDs. A wildcard requests 504 all available tuples. 506 As a response to RtSolPr, PAR sends a PrRtAdv message which indicates 507 one of the following possible conditions. 509 1. If the PAR does not have an entry corresponding to the new access 510 point, it MUST respond indicating that the new access point is 511 unknown. The MN MUST stop fast handover protocol operations on 512 the current link. The MN MAY send an FBU from its new link. 514 2. If the new access point is connected to the PAR's current 515 interface (to which MN is attached), PAR MUST respond with a Code 516 value indicating that the new access point is connected to the 517 current interface, but not send any prefix information. This 518 scenario could arise, for example, when several wireless access 519 points are bridged into a wired network. No further protocol 520 action is necessary. 522 3. If the new access point is known and the PAR has information 523 about it, then PAR MUST respond indicating that the new access 524 point is known and supply the [AP-ID, AR-Info] tuple. If the new 525 access point is known, but does not support fast handover, the 526 PAR MUST indicate this with Code 3 (See Section 6.1.2). 528 4. If a wildcard is supplied as an identifier for the new access 529 point, the PAR SHOULD supply neighborhood [AP-ID, AR-Info] tuples 530 subject to path MTU restrictions (i.e., provide any `n' tuples 531 without exceeding the link MTU). 533 When further protocol action is necessary, some implementations MAY 534 choose to begin buffering copies of incoming packets at PAR. If such 535 FIFO buffering is used, PAR MUST continue forwarding the packets to 536 PCoA (i.e., buffer and forward). Such buffering can be useful when 537 the MN leaves without sending the FBU message from the PAR's link. 538 The PAR SHOULD stop buffering after processing the FBU message. The 539 size of the buffer is an implementation-specific consideration. 541 The method by which Access Routers exchange information about 542 their neighbors and thereby allow construction of Proxy Router 543 Advertisements with information about neighboring subnets is outside 544 the scope of this document. 546 The RtSolPr and PrRtAdv messages MUST be implemented by a MN and 547 an access router that supports fast handovers. However, when 548 the parameters necessary for the MN to send packets immediately 549 upon attaching to the NAR are supplied by the link layer handover 550 mechanism itself, use of above messages is optional on such links. 552 After a PrRtAdv message is processed, the MN sends FBU and includes 553 the proposed NCoA. The MN SHOULD send FBU from PAR's link whenever 554 ``anticipation'' of handover is feasible. When anticipation is 555 not feasible or when it has not received an FBack, the MN sends 556 FBU immediately after attaching to NAR's link. This FBU SHOULD be 557 encapsulated in a FNA message. The encapsulation allows NAR to 558 discard the (inner) FBU packet if an address conflict is detected as 559 a result of (outer) FNA packet processing (see FNA processing below). 560 In response to FBU, PAR establishes a binding between PCoA (``Home 561 Address'') and NCoA, and sends FBack to MN. Prior to establishing 562 this binding, PAR SHOULD send a HI message to NAR, and receive HAck 563 in response. In order to determine the NAR's address for the HI 564 message, the PAR can perform longest prefix match of NCoA (in FBU) 565 with the prefix list of neighboring access routers. When the source 566 IP address of FBU is PCoA, i.e., the FBU is sent from the PAR's link, 567 the HI message MUST have a Code value set to 0. See Section 6.2.1. 568 When the source IP address of FBU is not PCoA, i.e., the FBU is sent 569 from the NAR's link, the HI message MUST have a Code value of 1. See 570 Section 6.2.1. 572 The HI message contains the PCoA, link-layer address and the NCoA of 573 the MN. In response to processing a HI message with Code 0, the NAR 574 1. determines whether NCoA supplied in the HI message is a valid 575 address for use, and if it is, starts proxying [6] the address 576 for PROXY_ND_LIFETIME during which the MN is expected to connect 577 to NAR. The NAR MAY use the link-layer address to verify if a 578 corresponding IP address exists in its forwarding tables. 580 2. allocates NCoA for the MN when assigned addressing is used, 581 creates a proxy neighbor cache entry and begins defending it. 582 The NAR MAY allocate the NCoA proposed in HI. 584 3. MAY create a host route entry for PCoA in case NCoA cannot 585 be accepted or assigned. This host route entry SHOULD be 586 implemented such that until the MN's presence is detected, either 587 through explicit announcement by the MN or by other means, 588 arriving packets do not invoke neighbor discovery. The NAR MAY 589 also set up a reverse tunnel to PAR in this case. 591 4. provides the status of handover request in Handover Acknowledge 592 (HAck) message. 594 When the Code value in HI is 1, NAR MUST skip the above operations 595 since it would have performed those operations during FNA processing. 596 However, it SHOULD be prepared to process any other options which 597 may be defined in the future. Sending a HI message with Code 1 598 allows NAR to, loosely speaking, validate the neighbor cache entry 599 it creates for the MN during FNA processing. That is, NAR can make 600 use of the knowledge that its trusted peer (i.e., PAR) has a trust 601 relationship with the MN. 603 If HAck contains an assigned NCoA, FBack MUST include it, and the 604 MN MUST use the address provided in FBack. The PAR MAY send FBack 605 to previous link as well to facilitate faster reception in the 606 event the MN be still present there. The result of FBU and FBack 607 processing is that PAR begins tunneling MN's packets to NCoA. If the 608 MN does not receive an FBack message even after re-transmitting FBU 609 for FBU_RETRIES, it must assume that fast handover support is not 610 available and stop the protocol operation. 612 As soon as the MN establishes link connectivity with the NAR, it 613 SHOULD send a Fast Neighbor Advertisement (FNA) message (see 6.3.3). 614 If the MN has not received an FBack by the time FNA is being sent, it 615 SHOULD encapsulate the FBU in FNA and send them together. 617 When the NCoA corresponding to the FNA message is acceptable, the NAR 618 MUST, 620 1. delete its proxy neighbor cache entry, if any is present. 622 2. create a neighbor cache entry and set its state to REACHABLE 623 without over-writing an existing entry for a different layer 2 624 address. 626 3. forward any buffered packets 628 4. enable the host route entry, if any is present, for PCoA. 630 When the NCoA corresponding to the FNA message is not acceptable, the 631 NAR MUST 633 1. discard the inner (FBU) packet. 635 2. send a Router Advertisement with the NAACK option in which it MAY 636 include an alternate NCoA for use. This message MUST be sent 637 to the source IP address present in FNA using the same Layer 2 638 address present in FNA. 640 If the MN receives a Router Advertisement with a NAACK option, it 641 MUST use the IP address, if any, provided in the NAACK option. 642 Otherwise, the MN should configure another NCoA. Subsequently, the MN 643 SHOULD send an FBU using the new CoA. As a special case, the address 644 supplied in NAACK could be PCoA itself, in which case the MN MUST NOT 645 send any more FBUs. 647 Once the MN has confirmed its NCoA, it SHOULD send a Neighbor 648 Advertisement message. This message allows MN's neighbors to update 649 their neighbor cache entries with the MN's addresses. 651 For data forwarding, the PAR tunnels packets to the MN using 652 its global IP address valid on the interface to which the MN was 653 attached. The MN reverse tunnels its packets to the same global 654 address of PAR. The tunnel end-point addresses must be configured 655 accordingly. When PAR receives a reverse tunneled packet, it must 656 verify if a secure binding exists for the MN identified by PCoA in 657 the tunneled packet, before forwarding the packet. 659 5. Miscellaneous 661 5.1. Handover Capability Exchange 663 The MN expects a PrRtAdv in response to its RtSolPr message. If the 664 MN does not receive a PrRtAdv message even after RTSOLPR_RETRIES, it 665 must assume that PAR does not support the fast handover protocol and 666 stop sending any more RtSolPr messages. 668 Even if a MN's current access router is capable of fast handover, the 669 new access router to which the MN attaches may be incapable of fast 670 handover. This is indicated to the MN during ``runtime'', through 671 the PrRtAdv message with a Code value of 3 (see Section 6.1.2). 673 5.2. Determining New Care of Address 675 Typically, the MN formulates its prospective NCoA using the 676 information provided in a PrRtAdv message, and sends FBU. The PAR 677 MUST use the NCoA present in FBU in its HI message. The NAR MUST 678 verify if NCoA present in HI is already in use. In any case, NAR 679 MUST respond to HI using a HAck, in which it may include another NCoA 680 to use, especially when assigned address configuration is used. If 681 there is a CoA present in HAck, PAR MUST include it in the FBack 682 message. 684 If PrRtAdv message carries a NCoA, the MN MUST use it as its 685 prospective NCoA. 687 5.3. Packet Loss 689 Handover involves link switching, which may not be exactly 690 co-ordinated with fast handover signaling. Furthermore, the 691 arrival pattern of packets is dependent on many factors, including 692 application characteristics, network queuing behaviors etc. Hence, 693 packets may arrive at NAR before the MN is able to establish its 694 link there. These packets will be lost unless they are buffered 695 by the NAR. Similarly, if the MN attaches to NAR and then sends an 696 FBU message, packets arriving at PAR will be lost unless they are 697 buffered. This protocol provides an option to indicate request for 698 buffering at the NAR in the HI message. When the PAR requests this 699 feature (for the MN), it SHOULD also provide its own support for 700 buffering. 702 5.4. DAD Handling 704 Duplicate Address Detection (DAD) was defined in [7] to avoid address 705 duplication on links when stateless address auto-configuration is 706 used. The use of DAD to verify the uniqueness of an IPv6 address 707 configured through stateless auto-configuration adds delays to a 708 handover. 710 The probability of an interface identifier duplication on the same 711 subnet is very low, however it cannot be ignored. In this draft 712 certain precautions are proposed to minimize the effects of a 713 duplicate address occurrence. 715 In some cases the NAR may already have the knowledge required to 716 assess whether the MN's address is a duplicate or not before the MN 717 moves to the new subnet. For example, the NAR can have a list of all 718 nodes on its subnet, perhaps for access control, and by searching 719 this list, it can confirm whether the MN's address is a duplicate 720 or not. The result of this search is sent back to the PAR in the 721 HAck message. If such knowledge is not available at the NAR, it may 722 indicate this by not confirming NCoA in the HAck message. The NAR 723 may also indicate this in the NAACK option as a response to the FNA 724 message. In such cases, the MN would have to follow the address 725 configuration procedure according to [6] after attaching to the NAR. 727 5.5. Fast or Erroneous Movement 729 Although this specification is for fast handover, the protocol has 730 its limits in terms of how fast a MN can move. A special case 731 of fast movement is ping-pong, where a MN moves between the same 732 two access points rapidly. Another instance of the same problem 733 is erroneous movement i.e., the MN receives information prior to 734 a handover that it is moving to a new access point and but it is 735 either moved to a different one or it aborts movement altogether. 736 All of the above behaviors are usually the result of link layer 737 idiosyncrasies and thus are often tackled at the link layer itself. 739 IP layer mobility, however, introduces its own limits. IP layer 740 handovers should occur at a rate suitable for the MN to update the 741 binding of, at least, its HA and preferably that of every CN with 742 which it is in communication. A MN that moves faster than necessary 743 for this signaling to complete, which may be of the order of few 744 seconds, may start losing packets. The signaling overhead over the 745 air and in the network may increase significantly, especially in the 746 case of rapid movement between several access routers. To avoid the 747 signaling overhead, the following measures are suggested. 749 A MN returning to the PAR before updating the necessary bindings when 750 present on NAR MUST send a Fast Binding Update with Home Address 751 equal to the MN's PCoA and a lifetime of zero, to the PAR. The MN 752 should have a security association with the PAR since it performed 753 a fast handover from it to the NAR. The PAR, on receiving this 754 Fast Binding Update, will check its set of outgoing (temporary 755 fast handover) tunnels. If it finds a match it SHOULD tear down 756 that tunnel; i.e., stop forwarding packets for this MN and start 757 delivering packets directly to the node instead. The MN SHOULD NOT 758 make any attempt to use any of the fast handover mechanisms described 759 in this specification and SHOULD revert back to standard Mobile IPv6. 761 Temporary tunnels for the purposes of fast handovers should use short 762 lifetimes (in the order of a small number of seconds or less). The 763 lifetime of such tunnels should be enough to allow a MN to update all 764 its active bindings. The default lifetime of the tunnel should be 765 the same as the lifetime value in the FBU message. 767 The effect of erroneous movement is typically limited to loss of 768 packets since routing can change and the PAR may forward packets 769 towards another router before the MN actually connects to that 770 router. If the MN discovers itself on an unanticipated access 771 router, a Fast Binding Update to the PAR SHOULD be sent. Since 772 Fast Binding Updates are authenticated, they supersede the existing 773 binding and packets MUST be redirected to the new confirmed location 774 of the MN. 776 6. Message Formats 778 All the ICMPv6 messages have a common Type specified in [4]. The 779 messages are distinguished based on the Subtype field (see below). 780 The values for the Subtypes are specified in Section 9. For all the 781 ICMPv6 messages, the checksum is defined in [2]. 783 6.1. New Neighborhood Discovery Messages 785 6.1.1. Router Solicitation for Proxy Advertisement (RtSolPr) 787 Mobile Nodes send Router Solicitation for Proxy Advertisement in 788 order to prompt routers for Proxy Router Advertisements. All the 789 link-layer address options have the format defined in 6.4.3. 791 0 1 2 3 792 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 793 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 794 | Type | Code | Checksum | 795 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 796 | Subtype | Reserved | Identifier | 797 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 798 | Options ... 799 +-+-+-+-+-+-+-+-+-+-+-+- 801 Figure 4: Router Solicitation for Proxy (RtSolPr) Message 803 IP Fields: 805 Source Address 806 An IP address assigned to the sending interface 808 Destination Address 809 The address of the Access Router or the all routers 810 multicast address. 812 Hop Limit 255. See RFC 2461. 814 Authentication Header 815 If a Security Association for the IP Authentication 816 Header exists between the sender and the 817 destination address, then the sender SHOULD include 818 this header. See RFC 2402. 820 ICMP Fields: 822 Type The Experimental Mobility Protocol Type. See [4]. 824 Code 0 826 Checksum The ICMPv6 checksum. 828 Subtype 2 830 Reserved MUST be set to zero by the sender and ignored by 831 the receiver. 833 Identifier MUST be set by the sender so that replies can be 834 matched to this Solicitation. 836 Valid Options: 838 Source Link-layer Address 839 When known, the link-layer address of the sender 840 SHOULD be included using the Link-Layer Address 841 option. See LLA option format below. 843 New Access Point Link-layer Address 844 The link-layer address or identification of the 845 access point for which the MN requests routing 846 advertisement information. It MUST be included 847 in all RtSolPr messages. More than one such address 848 or identifier can be present. This field can also 849 be a wildcard address with all bits set to zero. 851 Future versions of this protocol may define new option types. 852 Receivers MUST silently ignore any options that they do not recognize 853 and continue processing the rest of the message. 855 Including the source LLA option allows the receiver to record the 856 sender's L2 address so that neighbor discovery, when the receiver 857 needs to send packets back to the sender (of RtSolPr message), can be 858 avoided. 860 When a wildcard is used for New Access Point LLA, no other New Access 861 Point LLA options must be present. 863 A Proxy Router Advertisement (PrRtAdv) message should be received by 864 the MN as a response to RtSolPr. If such a message is not received 865 in a short time period but no less than twice the typical round trip 866 time (RTT) over the access link or 100 milliseconds if RTT is not 867 known, it SHOULD resend RtSolPr message. Subsequent retransmissions 868 can be up to RTSOLPR_RETRIES, but MUST use an exponential backoff 869 in which the timeout period (i.e., 2xRTT or 100 milliseconds) is 870 doubled prior to each instance of retransmission. If Proxy Router 871 Advertisement is not received by the time the MN disconnects from the 872 PAR, the MN SHOULD send FBU immediately after configuring a new CoA. 874 When RtSolPr messages are sent more than once, they MUST be rate 875 limited with MAX_RTSOLPR_RATE per second. During each use of 876 RtSolPr, exponential backoff is used for retransmissions. 878 6.1.2. Proxy Router Advertisement (PrRtAdv) 880 Access routers send out Proxy Router Advertisement message 881 gratuitously if the handover is network-initiated or as a response 882 to RtSolPr message from a MN, providing the link-layer address, 883 IP address and subnet prefixes of neighboring routers. All the 884 link-layer address options have the format defined in 6.4.3. 886 IP Fields: 888 Source Address 889 MUST be the link-local address assigned to the 890 interface from which this message is sent. 892 Destination Address 893 The Source Address of an invoking Router 894 Solicitation for Proxy Advertisement or the address 895 of the node the Access Router is instructing to 896 handover. 898 0 1 2 3 899 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 900 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 901 | Type | Code | Checksum | 902 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 903 | Subtype | Reserved | Identifier | 904 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 905 | Options ... 906 +-+-+-+-+-+-+-+-+-+-+-+- 908 Figure 5: Proxy Router Advertisement (PrRtAdv) Message 910 Hop Limit 255. See RFC 2461. 912 Authentication Header 913 If a Security Association for the IP Authentication 914 Header exists between the sender and the 915 destination address, then the sender SHOULD include 916 this header. See RFC 2402. 918 ICMP Fields: 920 Type The Experimental Mobility Protocol Type. See [4]. 922 Code 0, 1, 2, 3 or 4. See below. 924 Checksum The ICMPv6 checksum. 926 Subtype 3 928 Reserved MUST be set to zero by the sender and ignored by 929 the receiver. 931 Identifier Copied from Router Solicitation for Proxy 932 Advertisement or set to Zero if unsolicited. 934 Valid Options in the following order: 936 Source Link-layer Address 937 When known, the link-layer address of the sender 938 SHOULD be included using the Link-Layer Address 939 option. See LLA option format below. 941 New Access Point Link-layer Address 942 The link-layer address or identification of the 943 access point is copied from RtSolPr 944 message. This option MUST be present. 946 New Router's Link-layer Address 947 The link-layer address of the Access Router for 948 which this message is proxied for. This option MUST be 949 included when Code is 0 or 1. 951 New Router's IP Address 952 The IP address of NAR. This option MUST be 953 included when Code is 0 or 1. 955 New Router Prefix Information Option. 956 Specifies the prefix of the Access 957 Router the message is proxied for and is used 958 for address auto-configuration. This option MUST be 959 included when Code is 0 or 1. However, when this 960 prefix is the same as what is used in the New 961 Router's IP Address option (above), the Prefix 962 Information option need not be present. 964 New CoA Option 965 MAY be present when PrRtAdv is sent 966 unsolicited. PAR MAY compute new CoA using NAR's 967 prefix information and the MN's L2 address, or by 968 any other means. 970 Future versions of this protocol may define new option types. 971 Receivers MUST silently ignore any options they do not recognize and 972 continue processing the message. 974 Currently, Code values 0, 1, 2, 3 and 4 are defined. 976 A Proxy Router Advertisement with Code 0 means that the MN should 977 use the [AP-ID, AR-Info] tuple (present in the options above) for 978 movement detection and NCoA formulation. The Option-Code field in 979 the New Access Point LLA option in this case is 1 reflecting the LLA 980 of the access point for which the rest of the options are related. 981 Multiple tuples may be present. 983 A Proxy Router Advertisement with Code 1 means that the message is 984 sent unsolicited. If a New CoA option is present following the New 985 Router Prefix Information option, the MN SHOULD use the supplied NCoA 986 and send FBU immediately or else stand to lose service. This message 987 acts as a network-initiated handover trigger. See Section 3.3. The 988 Option-Code field in the New Access Point LLA option (see below) in 989 this case is 1 reflecting the LLA of the access point for which the 990 rest of the options are related. 992 A Proxy Router Advertisement with Code 2 means that no new router 993 information is present. Each New Access Point LLA option contains 994 an Option-Code value (described below) which indicates a specific 995 outcome. 997 - When the Option-Code field in the New Access Point LLA option is 998 5, handover to that access point does not require change of CoA. 999 No other options are required in this case. 1001 - When the Option-Code field in the New Access Point LLA option is 1002 6, PAR is not aware of the Prefix Information requested. The MN 1003 SHOULD attempt to send FBU as soon as it regains connectivity 1004 with the NAR. No other options are required in this case. 1006 - When the Option-Code field in the New Access Point LLA option is 1007 7, it means that the NAR does not support fast handover. The MN 1008 MUST stop fast handover protocol operations. No other options 1009 are required in this case. 1011 A Proxy Router Advertisement with Code 3 means that new router 1012 information is present only for a subset of access points requested. 1013 The Option-Code field values (defined above including a value of 1) 1014 distinguish different outcomes for individual access points. 1016 A Proxy Router Advertisement with Code 4 means that the subnet 1017 information regarding neighboring access points is sent unsolicited, 1018 but the message is not a handover trigger, unlike when the message is 1019 sent with Code 1. Multiple tuples may be present. 1021 When a wildcard AP identifier is supplied in the RtSolPr message, 1022 the PrRtAdv message should include any 'n' [Access Point Identifier, 1023 Link-layer address option, Prefix Information Option] tuples 1024 corresponding to the PAR's neighborhood. 1026 6.2. Inter-Access Router Messages 1028 6.2.1. Handover Initiate (HI) 1030 The Handover Initiate (HI) is an ICMPv6 message sent by an Access 1031 Router (typically PAR) to another Access Router (typically NAR) to 1032 initiate the process of a MN's handover. 1034 IP Fields: 1036 0 1 2 3 1037 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 1038 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1039 | Type | Code | Checksum | 1040 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1041 | Subtype |S|U| Reserved | Identifier | 1042 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1043 | Options ... 1044 +-+-+-+-+-+-+-+-+-+-+-+- 1046 Figure 6: Handover Initiate (HI) Message 1048 Source Address 1049 The IP address of the PAR 1051 Destination Address 1052 The IP address of the NAR 1054 Hop Limit 255. See RFC 2461. 1056 Authentication Header 1057 The authentication header MUST be used when this 1058 message is sent. See RFC 2402. 1060 ICMP Fields: 1062 Type The Experimental Mobility Protocol Type. See [4]. 1064 Code 0 or 1. See below 1066 Checksum The ICMPv6 checksum. 1068 Subtype 4 1070 S Assigned address configuration flag. When set, this 1071 message requests a new CoA to be returned by the 1072 destination. May be set when Code = 0. MUST be 0 1073 when Code = 1. 1075 U Buffer flag. When set, the destination SHOULD buffer 1076 any packets towards the node indicated in the options 1077 of this message. Used when Code = 0, SHOULD be set 1078 to 0 when Code = 1. 1080 Reserved MUST be set to zero by the sender and ignored by 1081 the receiver. 1083 Identifier MUST be set by the sender so replies can be matched 1084 to this message. 1086 Valid Options: 1088 Link-layer address of MN 1089 The link-layer address of the MN that is 1090 undergoing handover to the destination (i.e., NAR). 1091 This option MUST be included so that the destination 1092 can recognize the MN. 1094 Previous Care of Address 1095 The IP address used by the MN while 1096 attached to the originating router. This option 1097 SHOULD be included so that host route can be 1098 established in case necessary. 1100 New Care of Address 1101 The IP address the MN wishes to use when 1102 connected to the destination. When the `S' bit is 1103 set, NAR MAY assign this address. 1105 The PAR uses a Code value of 0 when it processes an FBU with PCoA as 1106 source IP address. The PAR uses a Code value of 1 when it processes 1107 an FBU whose source IP address is not PCoA. 1109 If Handover Acknowledge (HAck) message is not received as a response 1110 in a short time period but no less than twice the typical round trip 1111 time (RTT) between source and destination, or 100 milliseconds if RTT 1112 is not known, the Handover Initiate SHOULD be re-sent. Subsequent 1113 retransmissions can be up to HI_RETRIES, but MUST use exponential 1114 backoff in which the timeout period (i.e., 2xRTT or 100 milliseconds) 1115 is doubled during each instance of retransmission. 1117 6.2.2. Handover Acknowledge (HAck) 1119 The Handover Acknowledgment message is a new ICMPv6 message that MUST 1120 be sent (typically by NAR to PAR) as a reply to the Handover Initiate 1121 message. 1123 IP Fields: 1125 Source Address 1126 0 1 2 3 1127 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 1128 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1129 | Type | Code | Checksum | 1130 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1131 | Subtype | Reserved | Identifier | 1132 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1133 | Options ... 1134 +-+-+-+-+-+-+-+-+-+-+-+- 1136 Figure 7: Handover Acknowledge (HAck) Message 1138 Copied from the destination address of the Handover 1139 Initiate Message to which this message is a 1140 response. 1142 Destination Address 1143 Copied from the source address of the Handover 1144 Initiate Message to which this message is a 1145 response. 1147 Hop Limit 255. See RFC 2461. 1149 Authentication Header 1150 The authentication header MUST be used when this 1151 message is sent. See RFC 2402. 1153 ICMP Fields: 1155 Type The Experimental Mobility Protocol Type. See [4]. 1157 Code 1158 0: Handover Accepted, NCoA valid 1159 1: Handover Accepted, NCoA not valid 1160 2: Handover Accepted, NCoA in use 1161 3: Handover Accepted, NCoA assigned 1162 (used in Assigned addressing) 1163 4: Handover Accepted, NCoA not assigned 1164 (used in Assigned addressing) 1165 128: Handover Not Accepted, reason unspecified 1166 129: Administratively prohibited 1167 130: Insufficient resources 1169 Checksum The ICMPv6 checksum. 1171 Subtype 5 1173 Reserved MUST be set to zero by the sender and ignored by 1174 the receiver. 1176 Identifier Copied from the corresponding field in the Handover 1177 Initiate message this message is in response to. 1179 Valid Options: 1181 New Care of Address 1182 If the S flag in the Handover Initiate message is set, 1183 this option MUST be used to provide NCoA the MN should 1184 use when connected to this router. This option MAY be 1185 included even when `S' bit is not set, e.g., Code 2 1186 above. 1188 Upon receiving a HI message, the NAR MUST respond with a Handover 1189 Acknowledge message. If the `S' flag is set in the HI message, the 1190 NAR SHOULD include the New Care of Address option and a Code 3. 1192 The NAR MAY provide support for PCoA (instead of accepting or 1193 assigning NCoA) and establish a host route entry for PCoA, and set up 1194 a tunnel to the PAR to forward MN's packets sent with PCoA as source 1195 IP address. This host route entry SHOULD be used to forward packets 1196 once the NAR detects that the particular MN is attached to its link. 1198 When responding to a HI message containing a Code value 1, the Code 1199 values 1, 2, and 4 in the HAck message are not relevant. 1201 Finally, the new access router can always refuse handover, in which 1202 case it should indicate the reason in one of the available Code 1203 values. 1205 6.3. New Mobility Header Messages 1207 Mobile IPv6 uses a new IPv6 header type called Mobility Header [3]. 1208 The Fast Binding Update, Fast Binding Acknowledgment and Fast 1209 Neighbor Advertisement messages use the Mobility Header. 1211 6.3.1. Fast Binding Update (FBU) 1213 The Fast Binding Update message is identical to the Mobile IPv6 1214 Binding Update (BU) message. However, the processing rules are 1215 slightly different. 1217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1218 | Sequence # | 1219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1220 |A|H|L|K| Reserved | Lifetime | 1221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1222 | | 1223 . . 1224 . Mobility options . 1225 . . 1226 | | 1227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1229 Figure 8: Fast Binding Update (FBU) Message 1231 IP fields: 1233 Source address The PCoA or NCoA 1235 Destination Address 1236 The IP address of the Previous Access 1237 Router 1239 `A' flag MUST be set to one to request PAR to send a Fast 1240 Binding Acknowledgment message. 1242 `H' flag MUST be set to one. See [3]. 1244 `L' flag See [3]. 1246 `K' flag See [3]. 1248 Reserved This field is unused. MUST be set zero. 1250 Sequence Number See [3]. 1252 Lifetime See [3]. 1254 Mobility Options 1255 MUST contain alternate CoA option set to NCoA IP 1256 address when FBU is sent from PAR's link. 1258 The MN sends FBU message any time after receiving a PrRtAdv message. 1259 If the MN moves prior to receiving a PrRtAdv message, it SHOULD send 1260 a FBU to the PAR after configuring NCoA on the NAR according to 1261 Neighbor Discovery and IPv6 Address Configuration protocols. 1263 The source IP address is PCoA when FBU is sent from PAR's link, and 1264 the source IP address is NCoA when sent from NAR's link. When FBU is 1265 sent from NAR's link, it SHOULD be encapsulated within FNA. 1267 The FBU MUST also include the Home Address Option and the Home 1268 Address is PCoA. A FBU message MUST be protected so that PAR is able 1269 to determine that the FBU message is sent by a genuine MN. 1271 6.3.2. Fast Binding Acknowledgment (FBack) 1273 The Fast Binding Acknowledgment message is sent by the PAR to 1274 acknowledge receipt of a Fast Binding Update message in which the `A' 1275 bit is set. The Fast Binding Acknowledgment message SHOULD NOT be 1276 sent to the MN before the PAR receives a HAck message from the NAR. 1277 The Fast Binding Acknowledgment MAY also be sent to the MN on the old 1278 link. 1280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1281 | Status |K| Reserved | 1282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1283 | Sequence # | Lifetime | 1284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1285 | | 1286 . . 1287 . Mobility options . 1288 . . 1289 | | 1290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1292 Figure 9: Fast Binding Acknowledgment (FBack) Message 1294 IP fields: 1296 Source address The IP address of the Previous Access 1297 Router 1299 Destination Address The NCoA 1301 Status 1302 8-bit unsigned integer indicating the 1303 disposition of the Fast Binding Update. Values 1304 of the Status field less than 128 indicate that 1305 the Binding Update was accepted by the receiving 1306 node. The following such Status values are 1307 currently defined: 1309 0 Fast Binding Update accepted 1310 1 Fast Binding Update accepted but NCoA is 1311 invalid. Use NCoA supplied in ``alternate'' CoA 1313 Values of the Status field greater than or equal 1314 to 128 indicate that the Binding Update was 1315 rejected by the receiving node. The following 1316 such Status values are currently defined: 1318 128 Reason unspecified 1319 129 Administratively prohibited 1320 130 Insufficient resources 1321 131 Incorrect interface identifier length 1323 `K' flag See [3]. 1325 Reserved An unused field. MUST be set to zero. 1327 Sequence Number Copied from FBU message for use by the MN in 1328 matching this acknowledgment with an outstanding 1329 FBU. 1331 Lifetime 1332 The granted lifetime in seconds for which the 1333 sender of this message will retain a binding for 1334 traffic redirection. 1336 Mobility Options MUST contain ``alternate'' CoA if Status is 1. 1338 6.3.3. Fast Neighbor Advertisement (FNA) 1340 A MN sends a Fast Neighbor Advertisement to announce itself to the 1341 NAR. When the Mobility Header Type is FNA, the Payload Proto field 1342 may be set to IPv6 in order to assist FBU encapsulation. 1344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1345 | Reserved | 1346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1347 . . 1348 . Mobility Options . 1349 . . 1350 | | 1351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1353 Figure 10: Fast Neighbor Advertisement (FNA) Message 1355 IP fields: 1357 Source address NCoA 1359 Destination Address NAR's IP address 1361 Mobility Options MUST contain the Mobility Header Link-Layer 1362 Address of the MN in MH-LLA option format. See 1363 Section 6.4.4. 1365 The MN sends Fast Neighbor Advertisement to the NAR, as soon as it 1366 regains connectivity on the new link. Arriving or buffered packets 1367 can be immediately forwarded. If NAR is proxying NCoA, it creates 1368 a neighbor cache entry in REACHABLE state. If there is no entry at 1369 all, it creates one and sets it to REACHABLE. If there is an entry 1370 in INCOMPLETE state without a link-layer address, it sets it to 1371 REACHABLE. During the process of creating a neighbor cache entry, NAR 1372 can also detect if NCoA is in use, thus avoiding address collisions. 1373 Since FBU is encapsulated within FNA when sent from NAR's link, NAR 1374 drops FBU in case it detects any collision. 1376 The combination of NCoA (present in source IP address) and the 1377 Link-Layer Address (present as a Mobility Option) SHOULD be used to 1378 distinguish the MN from other nodes. 1380 6.4. New Options 1382 All the options are of the form shown in Figure 11. 1384 The Type values are defined from the Neighbor Discovery options 1385 space. The Length field is in units of 8 octets, except for the 1386 Mobility Header Link-Layer Address option, whose Length field 1387 is in units of octets in accordance with [3], Section 6.2. And, 1388 0 1 2 3 1389 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 1390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1391 | Type | Length | Option-Code | | 1392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1393 ~ ... ~ 1394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1396 Figure 11: Option Format 1398 Option-Code provides additional information for each of the options 1399 (See individual options below). 1401 6.4.1. IP Address Option 1403 This option is sent in the Proxy Router Advertisement, the Handover 1404 Initiate, and Handover Acknowledge messages. 1406 0 1 2 3 1407 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 1408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1409 | Type | Length | Option-Code | Prefix Length | 1410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1411 | Reserved | 1412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1413 | | 1414 + + 1415 | | 1416 + IPv6 Address + 1417 | | 1418 + + 1419 | | 1420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1422 Figure 12: IPv6 Address Option 1424 Type 1425 To be assigned by IANA 1427 Length 1428 The size of this option in 8 octets including the Type, 1429 Option-Code and Length fields. 1431 Option-Code 1432 1 Old Care-of Address 1433 2 New Care-of Address 1434 3 NAR's IP address 1436 Prefix Length 1437 The Length of the IPv6 Address Prefix. 1439 Reserved 1440 MUST be set to zero by the sender and MUST be 1441 ignored by the receiver. 1443 IPv6 address 1444 The IP address for the unit defined by the Type field. 1446 6.4.2. New Router Prefix Information Option 1448 This option is sent in the PrRtAdv message in order to provide the 1449 prefix information valid on the NAR. 1451 0 1 2 3 1452 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 1453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1454 | Type | Length | Option-Code | Prefix Length | 1455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1456 | Reserved | 1457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1458 | | 1459 + + 1460 | | 1461 + Prefix + 1462 | | 1463 + + 1464 | | 1465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1467 Figure 13: New Router Prefix Information Option 1469 Type 1470 To be assigned by IANA 1472 Length 1473 The size of this option in 8 octets including the Type, 1474 Option-Code and Length fields. 1476 Option-Code 1477 0 1479 Prefix Length 1480 8-bit unsigned integer. The number of leading bits in the 1481 Prefix that are valid. The value ranges from 0 to 128. 1483 Reserved 1484 MUST be set to zero by the sender and MUST be 1485 ignored by the receiver. 1487 Prefix 1488 An IP address or a prefix of an IP address. The Prefix Length 1489 field contains the number of valid leading bits in the prefix. 1490 The bits in the prefix after the prefix length are reserved 1491 and MUST be initialized to zero by the sender and ignored by 1492 the receiver. 1494 6.4.3. Link-layer Address (LLA) Option 1496 0 1 2 3 1497 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 1498 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1499 | Type | Length | Option-Code | LLA... 1500 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1502 Figure 14: Link-Layer Address Option 1504 Type 1505 To be assigned by IANA 1507 Length 1508 The size of this option in 8 octets including the Type, 1509 Option-Code and Length fields. 1511 Option-Code 1512 0 wildcard requesting resolution for all nearby access points 1513 1 Link-layer Address of the New Access Point 1514 2 Link-layer Address of the MN 1515 3 Link-layer Address of the NAR (i.e., Proxied Originator) 1516 4 Link-layer Address of the source of RtSolPr or PrRtAdv 1517 message 1518 5 The access point identified by the LLA belongs to the 1519 current interface of the router 1520 6 No prefix information available for the access point 1521 identified by the LLA 1522 7 No fast handovers support available for the access point 1523 identified by the LLA 1525 LLA 1526 The variable length link-layer address. 1528 Depending on the size of individual LLA option, appropriate padding 1529 MUST be used to ensure that the entire option size is a multiple of 8 1530 octects. 1532 The New Access Point Link Layer address contains the link-layer 1533 address of the access point for which handover is about to be 1534 attempted. This is used in the Router Solicitation for Proxy 1535 Advertisement message. 1537 The MN Link-Layer address option contains the link-layer address of a 1538 MN. It is used in the Handover Initiate message. 1540 The NAR (i.e., Proxied Originator) Link-Layer address option contains 1541 the Link Layer address of the Access Router for which the Proxy 1542 Router Solicitation message refers to. 1544 6.4.4. Mobility Header Link-layer Address (MH-LLA) Option 1546 This option is identical to the LLA option, but is carried in the 1547 Mobility Header messages, e.g., FNA. In the future, other Mobility 1548 Header messages may also make use of this option. The format of the 1549 option when LLA is 6 bytes is shown in Figure 15. When LLA size is 1550 different, the option MUST be aligned appropriately. (See Section 1551 6.2 in [3]). 1553 Type 1554 To be assigned by IANA 1556 Length 1557 0 1 2 3 1558 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 1559 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1560 | Type | Length | 1561 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1562 | Option-Code | Pad0=0 | LLA | 1563 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1564 | LLA | 1565 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1567 Figure 15: Mobility Header Link-Layer Address Option 1569 The size of this option in octets not including the Type, 1570 Length and Option-Code fields. 1572 Option-Code 1573 2 Link-layer Address of the MN 1575 LLA 1576 The variable length link-layer address. 1578 6.4.5. Neighbor Advertisement Acknowledgment (NAACK) 1580 0 1 2 3 1581 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 1582 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1583 | Type | Length | Option-Code | Status | 1584 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1585 | Reserved | 1586 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1588 Figure 16: Neighbor Advertisement Acknowledgment Option 1590 Type 1591 To be assigned by IANA. 1593 Length 1594 8-bit unsigned integer. Length of the option, in 8 1595 octets. The length is 1 when a new CoA is not supplied. The 1596 length is 3 when a new CoA is present (immediately following 1597 the Reserved field) 1599 Option-Code 1600 0 1602 Status 1603 8-bit unsigned integer indicating the disposition of the Fast 1604 Neighbor Advertisement message. The following Status 1605 values are currently defined: 1607 1 The New CoA is invalid 1608 2 The New CoA is invalid, use the supplied CoA. The New 1609 CoA MUST be present following the Reserved field. 1610 128 Link Layer Address unrecognized 1611 Reserved 1612 MUST be set to zero by the sender and MUST be 1613 ignored by the receiver. 1615 Since the NAACK option is carried in a Router Advertisement, the 1616 Length field is units of 8 octets unlike in other options. 1618 The NAR responds to FNA with the NAACK option to notify the MN 1619 to use a different NCoA if there is address collision. If the 1620 NCoA is invalid, the Router Advertisement MUST use the NCoA as the 1621 destination address but use the L2 address present in FNA. The MN 1622 SHOULD use the NCoA if it is supplied with the NAACK option. If the 1623 NAACK indicates that the Link Layer Address is unrecognized the MN 1624 MUST NOT use the NCoA or the PCoA and SHOULD start immediately the 1625 process of acquiring a NCoA at the NAR. 1627 In the future, new option types may be defined. 1629 7. Configurable Parameters 1631 Parameter Name Default Value Definition 1632 ------------------- ---------------------- ------- 1633 RTSOLPR_RETRIES 3 Section6.1.1 1634 MAX_RTSOLPR_RATE 3 Section6.1.1 1635 FBU_RETRIES 3 Section 4 1636 PROXY_ND_LIFETIME 1.5 seconds Section 6.2.2 1637 HI_RETRIES 3 Section 6.2.1 1639 8. Security Considerations 1641 The following security vulnerabilities are identified, and suggested 1642 solutions mentioned. 1644 1. Insecure FBU: in this case, packets meant for one address could 1645 be stolen, or redirected to some unsuspecting node. This concern 1646 is the same as that in a MN and Home Agent relationship. 1648 Hence, the PAR MUST ensure that the FBU packet arrived from a 1649 node that legitimately owns the PCoA. The access router and its 1650 hosts may use any available mechanism to establish a security 1651 association which MUST be used to secure FBU. The current version 1652 of this protocol does not specify how this security association 1653 is established. However, future work may specify this security 1654 association establishment. 1656 If an access router can ensure that the source IP address in 1657 an arriving packet could only have originated from the node 1658 whose link-layer address is in the router's neighbor cache, then 1659 a bogus node cannot use a victim's IP address for malicious 1660 redirection of traffic. Such an operation is recommended at 1661 least on neighbor discovery messages including the RtSolPr 1662 message. 1664 2. Secure FBU, malicious or inadvertent redirection: in this case, 1665 the FBU is secured, but the target of binding happens to be an 1666 unsuspecting node either due to inadvertent operation or due 1667 to malicious intent. This vulnerability can lead to a MN with 1668 genuine security association with its access router redirecting 1669 traffic to an incorrect address. 1671 However, the target of malicious traffic redirection is limited 1672 to an interface on an access router with which the PAR has a 1673 security association. The PAR MUST verify that the NCoA to 1674 which PCoA is being bound actually belongs to NAR's prefix. In 1675 order to do this, HI and HAck message exchanges are to be used. 1676 When NAR accepts NCoA in HI (with Code = 0), it proxies NCoA so 1677 that any arriving packets are not sent on the link until the MN 1678 attaches and announces itself through FNA. So, any inadvertent or 1679 malicious redirection to a host is avoided. It is still possible 1680 to jam NAR's buffer with redirected traffic. However, since 1681 NAR's handover state corresponding to NCoA has a finite (and 1682 short) lifetime corresponding to a small multiple of anticipated 1683 handover latency, the extent of this vulnerability is arguably 1684 small. 1686 3. Sending FBU from NAR's link: a malicious node may send FBU from 1687 NAR's link providing an unsuspecting node's address as NCoA. 1689 Since FBU is encapsulated in FNA, NAR should detect the collision 1690 with an address in use when processing FNA, and it then drops 1691 FBU. When NAR is unable to detect address collisions, there is a 1692 vulnerability that redirection can affect an unsuspecting node. 1694 9. IANA Considerations 1696 This document defines four new experimental ICMPv6 messages which use 1697 the Experimental Mobility Protocol ICMPv6 format [4]. These require 1698 four new Subtype value assignments out of the Experimental Mobility 1699 Protocol Subtype Registry [4] as follows: 1701 Subtype Description Reference 1702 ------- ----------- --------- 1703 2 RtSolPr Section 6.1.1 1704 3 PrRtAdv Section 6.1.2 1705 4 HI Section 6.2.1 1706 5 HAck Section 6.2.2 1708 The document defines four new Neighbor Discovery [6] options which 1709 need Type assignment from IANA. 1710 Option-Type Description Reference 1711 ----------- ----------- --------- 1712 TBD IP Address Option Section 6.4.1 1713 TBD New Router Prefix 1714 Information Option Section 6.4.2 1715 TBD Link-layer Address 1716 Option Section 6.4.3 1717 TBD Neighbor Advertisement 1718 Acknowledgment Option Section 6.4.5 1720 The document defines three new Mobility Header messages which 1721 need type allocation from the Mobility Header Types registry at 1722 http://www.iana.org/assignments/mobility-parameters: 1724 1. Fast Binding Update, described in Section 6.3.1 1726 2. Fast Binding Acknowledgment, described in Section 6.3.2, and 1728 3. Fast Neighbor Advertisement, described in Section 6.3.3 1730 The document defines a new Mobility Option which needs 1731 type assignment from the Mobility Options Type registry at 1732 http://www.iana.org/assignments/mobility-parameters: 1734 1. Mobility Header Link-Layer Address option, described in 1735 Section 6.4.4. 1737 10. Acknowledgments 1739 The editor would like to thank all those who have provided feedback 1740 on this specification, but can only mention a few here: Vijay 1741 Devarapalli, Youn-Hee Han, Suvidh Mathur, Gabriel Montenegro, Takeshi 1742 Ogawa, Sun Peng, YC Peng, Domagoj Premec, and Jonathan Wood. The 1743 editor would like to acknowledge contribution from James Kempf to 1744 improve this specification. The editor would also like to thank 1745 [mipshop] working group chair Gabriel Montenegro and the erstwhile 1746 [mobile ip] working group chairs Basavaraj Patil and Phil Roberts for 1747 providing much support for this work. 1749 11. Normative References 1751 [1] S. Bradner, ``Key words for use in RFCs to Indicate Requirement 1752 Levels,'' Request for Comments (Best Current Practice) 2119, 1753 Internet Engineering Task Force, March 1997. 1755 [2] A. Conta and S. Deering, ``Internet Control Message 1756 Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) 1757 Specification'', Request for Comments (Draft Standard) 2463, 1758 Internet Engineering Task Force, December 1998. 1760 [3] D. Johnson, C. E. Perkins, and J. Arkko, ``Mobility Support in 1761 IPv6'', Request for Comments (Proposed Standard) 3775, Internet 1762 Engineering Task Force, June 2004. 1764 [4] J. Kempf, ``Instructions for Seamoby and Experimental Mobility 1765 Protocol IANA Allocations (work in progress)'', Internet 1766 Engineering Task Force, June 2004. 1768 [5] S. Kent and R. Atkinson, ``IP Authentication Header'', Request 1769 for Comments (Draft Standard) 2402, Internet Engineering Task 1770 Force, November 1998. 1772 [6] T. Narten, E. Nordmark, and W. Simpson, ``Neighbor Discovery for 1773 IP Version 6 (IPv6)'', Request for Comments (Draft Standard) 1774 2461, Internet Engineering Task Force, December 1998. 1776 [7] S. Thomson and T. Narten, ``IPv6 Stateless Address 1777 Autoconfiguration'', Request for Comments (Draft Standard) 2462, 1778 Internet Engineering Task Force, December 1998. 1780 12. Author's Address 1782 Rajeev Koodli, Editor 1783 Nokia Research Center 1784 313 Fairchild Drive 1785 Mountain View, CA 94043 USA 1786 Phone: +1 650 625 2359 1787 Fax: +1 650 625 2502 1788 E-Mail: Rajeev.Koodli@nokia.com 1790 13. Contributors 1792 This document has its origins in the fast handover design team 1793 effort. The members of this design team in alphabetical order were; 1794 Gopal Dommety, Karim El-Malki, Mohammed Khalil, Charles Perkins, 1795 Hesham Soliman, George Tsirtsis and Alper Yegin. 1797 The design team member's contact information: 1799 Gopal Dommety 1800 Cisco Systems, Inc. 1801 170 West Tasman Drive 1802 San Jose, CA 95134 1803 Phone:+1 408 525 1404 1804 E-Mail: gdommety@cisco.com 1806 Karim El Malki 1807 Ericsson Radio Systems AB 1808 LM Ericssons Vag. 8 1809 126 25 Stockholm 1810 SWEDEN 1811 Phone: +46 8 7195803 1812 Fax: +46 8 7190170 1813 E-mail: Karim.El-Malki@era.ericsson.se 1815 Mohamed Khalil 1816 Nortel Networks 1817 E-Mail: mkhalil@nortelnetworks.com 1819 Charles E. Perkins 1820 Communications Systems Lab 1821 Nokia Research Center 1822 313 Fairchild Drive 1823 Mountain View, California 94043 1824 USA 1825 Phone: +1-650 625-2986 1826 E-Mail: charliep@iprg.nokia.com 1827 Fax: +1 650 625-2502 1829 Hesham Soliman 1830 Flarion Technologies 1831 E-mail: H.Soliman@flarion.com 1833 George Tsirtsis 1834 Flarion Technologies 1835 E-Mail: G.Tsirtsis@flarion.com 1837 Alper E. Yegin 1838 Samsung Advanced Institute of Technology 1839 75 West Plumeria Drive 1840 San Jose, CA 95134 1841 USA 1842 Phone: +1 408 544 5656 1843 E-Mail: alper.yegin@samsung.com 1845 A. Change Log 1847 The following revisions have been done since IESG review in Sep 04. 1849 - Added IPSec AH reference. 1851 - Changed options format to make use of RFC 2461 options Type 1852 space. Revised IANA Considerations section accordingly. 1854 - Added exponential backoff for retransmissions. Added rate 1855 limiting for RtSolPr message. 1857 - Replaced ``attachment point'' with ``access point'' for 1858 consistency. 1860 - Clarified [AP-ID, AR-Info] in Section 2. Clarified use of Prefix 1861 Information Option in Section 6.1.2. 1863 - Separated MH-LLA from LLA to future-proof LLA option. 1865 The following changes refer up to version 02 (under mipshop). The 1866 Section numbers refer to version 06 (under mobile ip). 1868 - New ICMPv6 format incorporated. ID Nits conformance. 1870 - Last Call comments incorporated 1872 - Revised the security considerations section in v07 1873 - Refined and added a section on network-initiated handover v07 1875 - Section 3 format change 1877 - Section 4 format change (i.e., no subsections). 1879 - Description in Section 4.4 merged with ``Fast or Erroneous 1880 Movement'' 1882 - Section 4.5 deprecated 1884 - Section 4.6 deprecated 1886 - Revision of some message formats in Section 6 1888 Intellectual Property Statement 1890 The IETF takes no position regarding the validity or scope of any 1891 Intellectual Property Rights or other rights that might be claimed to 1892 pertain to the implementation or use of the technology described in 1893 this document or the extent to which any license under such rights 1894 might or might not be available; nor does it represent that it has 1895 made any independent effort to identify any such rights. Information 1896 on the procedures with respect to rights in RFC documents can be 1897 found in BCP 78 and BCP 79. 1899 Copies of IPR disclosures made to the IETF Secretariat and any 1900 assurances of licenses to be made available, or the result of an 1901 attempt made to obtain a general license or permission for the 1902 use of such proprietary rights by implementers or users of this 1903 specification can be obtained from the IETF on-line IPR repository at 1904 http://www.ietf.org/ipr. 1906 The IETF invites any interested party to bring to its attention any 1907 copyrights, patents or patent applications, or other proprietary 1908 rights that may cover technology that may be required to implement 1909 this standard. Please address the information to the IETF at 1910 ietf-ipr@ietf.org. 1912 Disclaimer of Validity 1914 This document and the information contained herein are provided 1915 on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 1916 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 1917 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 1918 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1919 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1920 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1922 Copyright Statement 1924 Copyright (C) The Internet Society (2004). This document is subject 1925 to the rights, licenses and restrictions contained in BCP 78, and 1926 except as set forth therein, the authors retain all their rights. 1928 Acknowledgment 1930 Funding for the RFC Editor function is currently provided by the 1931 Internet Society.