idnits 2.17.1 draft-ietf-mipshop-fmipv6-rfc4068bis-00.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 on line 11. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1880. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1857. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1864. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1870. ** 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. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == 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 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' ) ** There is 1 instance of too long lines in the document, the longest one being 3 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? RFC 2119 keyword, line 283: '... implementations MUST support the mech...' RFC 2119 keyword, line 284: '...address conflicts and SHOULD use them....' RFC 2119 keyword, line 289: '... feasible, the MN SHOULD send FBU from...' RFC 2119 keyword, line 295: '...irection, the MN SHOULD reverse tunnel...' RFC 2119 keyword, line 296: '...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 (26 May 2006) is 6543 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 1767 looks like a reference -- Missing reference section? '1' on line 1758 looks like a reference -- Missing reference section? 'AP-ID' on line 1819 looks like a reference -- Missing reference section? 'AR-Info' on line 1819 looks like a reference -- Missing reference section? '6' on line 1779 looks like a reference -- Missing reference section? '7' on line 1783 looks like a reference -- Missing reference section? '4' on line 1771 looks like a reference -- Missing reference section? '2' on line 1762 looks like a reference -- Missing reference section? '5' on line 1775 looks like a reference Summary: 8 errors (**), 0 flaws (~~), 2 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 26 May 2006 5 Fast Handovers for Mobile IPv6 6 draft-ietf-mipshop-fmipv6-rfc4068bis-00.txt 8 By submitting this Internet-Draft, each author represents that any 9 applicable patent or other IPR claims of which he or she is aware 10 have been or will be disclosed, and any of which he or she becomes 11 aware will be disclosed, in accordance with Section 6 of BCP 79. 13 Internet-Drafts are working documents of the Internet Engineering 14 Task Force (IETF), its areas, and its working groups. Note 15 that other groups may also distribute working documents as 16 Internet-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. 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 This document is a submission of the IETF MIPSHOP WG. Comments should be 30 directed to the MIPSHOP WG mailing list, mipshop@ietf.org. 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 due to both 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 a protocol to improve handover latency due to Mobile IPv6 45 procedures. This document does not address improving the link 46 switching latency. 48 Contents 50 Abstract i 52 1. Introduction 2 54 2. Terminology 2 56 3. Protocol Overview 4 57 3.1. Addressing the Handover Latency . . . . . . . . . . . . . 4 58 3.2. Protocol Operation . . . . . . . . . . . . . . . . . . . 6 59 3.3. Protocol Operation of Network-initiated Handover . . . . 8 61 4. Protocol Details 9 63 5. Miscellaneous 13 64 5.1. Handover Capability Exchange . . . . . . . . . . . . . . 13 65 5.2. Determining New Care of Address . . . . . . . . . . . . . 14 66 5.3. Packet Loss . . . . . . . . . . . . . . . . . . . . . . . 14 67 5.4. DAD Handling . . . . . . . . . . . . . . . . . . . . . . 14 68 5.5. Fast or Erroneous Movement . . . . . . . . . . . . . . . 15 70 6. Message Formats 16 71 6.1. New Neighborhood Discovery Messages . . . . . . . . . . . 16 72 6.1.1. Router Solicitation for Proxy Advertisement 73 (RtSolPr) . . . . . . . . . . . . . . . . . . . . 16 74 6.1.2. Proxy Router Advertisement (PrRtAdv) . . . . . . 18 75 6.2. Inter-Access Router Messages . . . . . . . . . . . . . . 21 76 6.2.1. Handover Initiate (HI) . . . . . . . . . . . . . 21 77 6.2.2. Handover Acknowledge (HAck) . . . . . . . . . . . 23 78 6.3. New Mobility Header Messages . . . . . . . . . . . . . . 25 79 6.3.1. Fast Binding Update (FBU) . . . . . . . . . . . . 26 80 6.3.2. Fast Binding Acknowledgment (FBack) . . . . . . . 27 81 6.3.3. Fast Neighbor Advertisement (FNA) . . . . . . . . 29 82 6.4. New Options . . . . . . . . . . . . . . . . . . . . . . . 30 83 6.4.1. IP Address Option . . . . . . . . . . . . . . . . 30 84 6.4.2. New Router Prefix Information Option . . . . . . 31 85 6.4.3. Link-layer Address (LLA) Option . . . . . . . . . 32 86 6.4.4. Mobility Header Link-layer Address (MH-LLA) Option 34 87 6.4.5. Neighbor Advertisement Acknowledgment (NAACK) . . 34 89 7. Configurable Parameters 36 91 8. Security Considerations 36 93 9. IANA Considerations 37 95 10. Acknowledgments 38 97 11. Normative References 38 99 12. Author's Address 39 101 13. Contributors 39 103 A. Change Log 39 105 Intellectual Property Statement 40 107 Disclaimer of Validity 41 109 Copyright Statement 41 111 Acknowledgment 41 112 1. Introduction 114 Mobile IPv6 [3] describes the protocol operations for a mobile node 115 to maintain connectivity to the Internet during its handover from 116 one access router to another. These operations involve movement 117 detection, IP address configuration, and location update. The 118 combined handover latency is often sufficient to affect real-time 119 applications. Throughput-sensitive applications can also benefit 120 from reducing this latency. This document describes a protocol to 121 reduce the handover latency. 123 This specification addresses the following problem: how to allow a 124 mobile node to send packets as soon as it detects a new subnet link, 125 and how to deliver packets to a mobile node as soon as its attachment 126 is detected by the new access router. The protocol defines IP 127 protocol messages necessary for its operation regardless of link 128 technology. It does this without depending on specific link-layer 129 features while allowing link-specific customizations. By definition, 130 this specification considers handovers that inter-work with Mobile 131 IP: once attached to its new access router, a MN engages in Mobile IP 132 operations including Return Routability [3]. There are no special 133 requirements for a mobile node to behave differently with respect to 134 its standard Mobile IP operations. 136 2. Terminology 138 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 139 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "OPTIONAL", and 140 "silently ignore" in this document are to be interpreted as described 141 in RFC 2119 [1]. 143 The following terminology and abbreviations are used in this 144 document. The reference handover scenario is illustrated in 145 Figure 1. 147 Mobile Node (MN) 148 A Mobile IPv6 host 150 Access Point (AP) 151 A Layer 2 device connected to an IP subnet that offers 152 wireless connectivity to a MN. An Access Point Identifier 153 (AP-ID) refers the AP's L2 address. Sometimes, AP-ID is 154 also referred to as a Base Station Subsystem ID (BSSID). 156 Access Router (AR) 157 The MN's default router 159 Previous Access Router (PAR) 160 The MN's default router prior to its handover 162 New Access Router (NAR) 163 The MN's anticipated default router subsequent to its 164 handover 166 Previous CoA (PCoA) 167 The MN's Care of Address valid on PAR's subnet 169 New CoA (NCoA) 170 The MN's Care of Address valid on NAR's subnet 172 Handover 173 A process of terminating existing connectivity and 174 obtaining new IP connectivity. 176 Router Solicitation for Proxy Advertisement (RtSolPr) 177 A message from the MN to the PAR requesting information 178 for a potential handover 180 Proxy Router Advertisement (PrRtAdv) 181 A message from the PAR to the MN that provides 182 information about neighboring links facilitating 183 expedited movement detection. The message also acts as a 184 trigger for network-initiated handover. 186 (AP-ID, AR-Info) tuple 187 Contains an access router's L2 and IP addresses, and 188 prefix valid on the interface to which the Access Point 189 (identified by AP-ID) is attached. The triplet [Router's 190 L2 address, Router's IP address and Prefix] is called 191 ``AR-Info''. 193 Assigned Addressing 194 A particular type of NCoA configuration in which the NAR 195 assigns an IPv6 address for the MN. The method by which 196 NAR manages its address pool is not specified in this 197 document. 199 Fast Binding Update (FBU) 200 A message from the MN instructing its PAR to redirect its 201 traffic (towards NAR) 203 Fast Binding Acknowledgment (FBack) 204 A message from the PAR in response to FBU 206 Fast Neighbor Advertisement (FNA) 207 A message from the MN to the NAR to announce attachment, 208 and to confirm use of NCoA when the MN has not received 209 FBACK 211 Handover Initiate (HI) 212 A message from the PAR to the NAR regarding a MN's 213 handover 215 Handover Acknowledge (HAck) 216 A message from the NAR to the PAR as a response to HI 218 v +------------+ 219 +-+ | Previous | < 220 | | ---------- | Access | ------ > ----\ 221 +-+ | Router | < \ 222 MN | (PAR) | \ 223 | +------------+ +---------------+ 224 | ^ IP | Correspondent | 225 | | Network | Node | 226 V | +---------------+ 227 v / 228 v +------------+ / 229 +-+ | New | < / 230 | | ---------- | Access | ------ > ----/ 231 +-+ | Router | < 232 MN | (NAR) | 233 +------------+ 235 Figure 1: Reference Scenario for Handover 237 3. Protocol Overview 239 3.1. Addressing the Handover Latency 241 The ability to immediately send packets from a new subnet link 242 depends on the ``IP connectivity'' latency, which in turn depends 243 on the movement detection latency and the new CoA configuration 244 latency. Once a MN is IP-capable on the new subnet link, it can send 245 a Binding Update to its Home Agent and one or more correspondents. 246 Once its correspondents successfully process the Binding Update, 247 which typically involves the Return Routability procedure, the MN can 248 receive packets at the new CoA. So, the ability to receive packets 249 from correspondents directly at its new CoA depends on the Binding 250 Update latency as well as the IP connectivity latency. 252 The protocol enables a MN to quickly detect that it has moved to 253 a new subnet by providing the new access point and the associated 254 subnet prefix information when the MN is still connected to its 255 current subnet (i.e., PAR in Figure 1). For instance, a MN may 256 discover available access points using link-layer specific mechanisms 257 (e.g., a ``scan'' in WLAN) and then request subnet information 258 corresponding to one or more of those discovered access points. The 259 MN may do this after performing router discovery. The MN may also 260 do this at any time while connected to its current router. The 261 result of resolving an identifier associated with an access point is 262 a [AP-ID, AR-Info] tuple, which a MN can use in readily detecting 263 movement: when attachment to an access point with AP-ID takes place, 264 the MN knows the corresponding new router's co-ordinates including 265 its prefix, IP address and L2 address. The ``Router Solicitation 266 for Proxy Advertisement (RtSolPr)'' and ``Proxy Router Advertisement 267 (PrRtAdv)'' messages 6.1 are used for aiding movement detection. 269 Through the RtSolPr and PrRtAdv messages, the MN also formulates a 270 prospective new CoA (NCoA), when it is still present on the PAR's 271 link. Hence, the latency due to new prefix discovery subsequent to 272 handover is eliminated. Furthermore, this prospective address can 273 be used immediately after attaching to the new subnet link (i.e., 274 NAR's link) when the MN has received a ``Fast Binding Acknowledgment 275 (FBack)'' message prior to its movement. In the event it moves 276 without receiving an FBack, the MN can still start using NCoA after 277 announcing its attachment through a ``Fast Neighbor Advertisement 278 (FNA)'' message; NAR responds to FNA in case the tentative address 279 is already in use. In this way, NCoA configuration latency is 280 reduced. Under some limited conditions where the probability of 281 address collision is considered insignificant, it may be possible to 282 use NCoA immediately after attaching to the new link. Even so, all 283 implementations MUST support the mechanism specified in this document 284 to avoid potential address conflicts and SHOULD use them. 286 In order to reduce the Binding Update latency, the protocol specifies 287 a binding between the Previous CoA (PCoA) and NCoA. A MN sends a 288 ``Fast Binding Update'' message to its Previous Access Router to 289 establish this tunnel. When feasible, the MN SHOULD send FBU from 290 PAR's link. Otherwise, it should send it immediately after detecting 291 attachment to NAR. Subsequent sections describe the protocol 292 mechanics. In any case, the result is that PAR begins tunneling 293 packets arriving for PCoA to NCoA. Such a tunnel remains active 294 until the MN completes the Binding Update with its correspondents. 295 In the opposite direction, the MN SHOULD reverse tunnel packets 296 to PAR, again until it completes Binding Update. And, PAR SHOULD 297 forward the inner packet in the tunnel to its destination (i.e., to 298 the MN's correspondent). Such a reverse tunnel ensures that packets 299 containing PCoA as source IP address are not dropped due to ingress 300 filtering. Readers may observe that even though the MN is IP-capable 301 on the new link, it cannot use NCoA directly with its correspondents 302 without the correspondents first establishing a binding cache entry 303 (for NCoA). Forwarding support for PCoA is provided through a reverse 304 tunnel between the MN and the PAR. 306 Setting up a tunnel alone does not ensure that the MN receives 307 packets as soon as attaching to a new subnet link, unless NAR can 308 detect the MN's presence. A neighbor discovery operation involving 309 a neighbor's address resolution (i.e., Neighbor Solicitation and 310 Neighbor Advertisement) typically results in considerable delay, 311 sometimes lasting multiple seconds. For instance, when arriving 312 packets trigger NAR to send Neighbor Solicitation before the MN 313 attaches, subsequent re-transmissions of address resolution are 314 separated by a default period of one second each. In order to 315 circumvent this delay, a MN announces its attachment through the FNA 316 message that allows NAR to consider MN to be reachable. If there 317 is no existing entry, FNA allows NAR to create one. If NAR already 318 has an entry, FNA updates the entry while taking potential address 319 conflicts into consideration. Through tunnel establishment for PCoA 320 and fast advertisement, the protocol provides expedited forwarding of 321 packets to the MN. 323 The protocol also provides the following important functionalities. 324 The access routers can exchange messages to confirm that a proposed 325 NCoA is acceptable. For instance, when a MN sends FBU from PAR's 326 link, FBack can be delivered after NAR considers NCoA acceptable 327 to use. This is especially useful when addresses are assigned by 328 the access router. The NAR can also rely on its trust relationship 329 with PAR before providing forwarding support for the MN. That is, 330 it may create a forwarding entry for NCoA subject to ``approval'' 331 from PAR which it trusts. Finally, the access routers could transfer 332 network-resident contexts, such as access control, QoS, header 333 compression, in conjunction with handover. For all these operations, 334 the protocol provides ``Handover Initiate (HI)'' and ``Handover 335 Acknowledge (HAck)'' messages. Both of these messages MUST be 336 supported and SHOULD be used. The access routers MUST have necessary 337 security association established by means outside the scope of this 338 document. 340 3.2. Protocol Operation 342 The protocol begins when a MN sends RtSolPr to its access router 343 to resolve one or more Access Point Identifiers to subnet-specific 344 information. In response, the access router (e.g., PAR in Figure 1) 345 sends a PrRtAdv message which contains one or more [AP-ID, AR-Info] 346 tuples. The MN may send RtSolPr at any convenient time, for instance 347 as a response to some link-specific event (a ``trigger'') or simply 348 after performing router discovery. However, the expectation is that 349 prior to sending RtSolPr, the MN has discovered the available APs 350 by link-specific methods. The RtSolPr and PrRtAdv messages do not 351 establish any state at the access router, and their packet formats 352 are defined in Section 6.1. 354 With the information provided in the PrRtAdv message, the MN 355 formulates a prospective NCoA and sends an FBU message. The purpose 356 of FBU is to authorize PAR to bind PCoA to NCoA, so that arriving 357 packets can be tunneled to the new location of the MN. The FBU SHOULD 358 be sent from PAR's link whenever feasible. For instance, an internal 359 link-specific trigger could enable FBU transmission from the previous 360 link. When it is not feasible, FBU is sent from the new link. Care 361 must be taken to ensure that NCoA used in FBU does not conflict with 362 an address already in use by some other node on link. For this, FBU 363 encapsulation within FNA MUST be implemented and SHOULD be used (See 364 below) when FBU is sent from NAR's link. 366 The format and semantics of FBU processing are specified in 367 Section 6.3.1. 369 Depending on whether an FBack is received or not on the previous 370 link, which clearly depends on whether FBU was sent in the first 371 place, there are two modes of operation. 373 1. The MN receives FBack on the previous link. This means that 374 packet tunneling would already be in progress by the time the 375 MN handovers to NAR. The MN SHOULD send FNA immediately after 376 attaching to NAR, so that arriving as well as buffered packets 377 can be forwarded to the MN right away. 379 Before sending FBack to MN, PAR can determine whether NCoA is 380 acceptable to NAR through the exchange of HI and HAck messages. 381 When assigned addressing (i.e., addresses are assigned by the 382 router) is used, the proposed NCoA in FBU is carried in HI, and 383 NAR MAY assign the proposed NCoA. Such an assigned NCoA MUST be 384 returned in HAck, and PAR MUST in turn provide the assigned NCoA 385 in FBack. If there is an assigned NCoA returned in FBack, the MN 386 MUST use the assigned address (and not the proposed address in 387 FBU) upon attaching to NAR. 389 2. The MN does not receive FBack on the previous link. One reason 390 for this is that the MN has not sent the FBU. The other is that 391 the MN has left the link after sending the FBU, which itself may 392 be lost, but before receiving an FBack. Without receiving an 393 FBack in the latter case, the MN cannot ascertain whether PAR 394 has successfully processed the FBU. Hence, it (re)sends an FBU 395 as soon as it attaches to NAR. In order to enable NAR to forward 396 packets immediately (when FBU has been processed) and to allow 397 NAR to verify if NCoA is acceptable, the MN SHOULD encapsulate 398 FBU in FNA. If NAR detects that NCoA is in use when processing 399 FNA, for instance while creating a neighbor entry, it MUST 400 discard the inner FBU packet and send a Router Advertisement with 401 ``Neighbor Advertisement Acknowledge (NAACK)'' option in which 402 NAR MAY include an alternate IP address for the MN to use. This 403 discarding avoids rare but the undesirable outcome resulting from 404 address collision. Detailed FNA processing rules are specified 405 in Section 6.3.3. 407 The scenario in which a MN sends FBU and receives FBack on PAR's 408 link is illustrated in Figure 2. For convenience, this scenario is 409 characterized as ``predictive'' mode of operation. The scenario in 410 which the MN sends FBU from NAR's link is illustrated in Figure 3. 411 For convenience, this scenario is characterized as ``reactive'' 412 mode of operation. Note that the reactive mode also includes the 413 case when FBU has been sent from PAR's link but FBack has not been 414 received yet. 416 Finally, the PrRtAdv message may be sent unsolicited, i.e., without 417 the MN first sending RtSolPr. This mode is described in Section 3.3. 419 3.3. Protocol Operation of Network-initiated Handover 421 In some wireless technologies, the handover control may reside in 422 the network even though the decision to undergo handover may be 423 co-operatingly arrived at between the MN and the network. In such 424 networks, the PAR can send an unsolicited PrRtAdv containing the link 425 layer address, IP address and subnet prefixes of the NAR when the 426 network decides that a handover is imminent. The MN MUST process 427 this PrRtAdv to configure a new care of address on the new subnet, 428 and MUST send an FBU to PAR prior to switching to the new link. 429 After transmitting PrRtAdv, the PAR MUST continue to forward packets 430 to the MN on its current link until the FBU is received. The rest of 431 the operation is the same as that described in Section 3.2. 433 The unsolicited PrRtAdv also allows the network to inform the MN 434 about geographically adjacent subnets without the MN having to 435 explicitly request that information. This can reduce the amount 436 of wireless traffic required for the MN to obtain a neighborhood 437 topology map of links and subnets. Such usage of PrRtAdv is 438 decoupled from the actual handover. See Section 6.1.2. 440 MN PAR NAR 441 | | | 442 |------RtSolPr------->| | 443 |<-----PrRtAdv--------| | 444 | | | 445 |------FBU----------->|--------HI--------->| 446 | |<------HAck---------| 447 | <--FBack---|--FBack---> | 448 | | | 449 disconnect forward | 450 | packets===============>| 451 | | | 452 | | | 453 connect | | 454 | | | 455 |--------- FNA --------------------------->| 456 |<=================================== deliver packets 457 | | 459 Figure 2: ``Predictive'' Fast Handover 461 4. Protocol Details 463 All description makes use of Figure 1 as the reference. 465 After discovering one or more nearby access points, the MN sends 466 RtSolPr in order to resolve access point identifiers to subnet router 467 information. A convenient time to do this is after performing router 468 discovery. However, the MN can send RtSolPr at any time, e.g., when 469 one or more new access points are discovered. The MN can also send 470 RtSolPr more than once during its attachment to PAR. The trigger for 471 sending RtSolPr can originate from a link-specific event, such as the 472 promise of better signal strength from another access point coupled 473 with fading signal quality with the current access point. Such 474 events, often broadly referred to as ``L2 triggers'', are outside 475 the scope of this document. Nevertheless, they serve as events that 476 invoke this protocol. For instance, when a ``link up'' indication 477 is obtained on the new link, protocol messages (e.g., FNA) can be 478 immediately transmitted. Implementations SHOULD make use of such 479 triggers whenever available. 481 MN PAR NAR 482 | | | 483 |------RtSolPr------->| | 484 |<-----PrRtAdv--------| | 485 | | | 486 disconnect | | 487 | | | 488 | | | 489 connect | | 490 |------FNA[FBU]-------|------------------->| 491 | |<-----FBU-----------| 492 | |------FBack-------->| 493 | forward | 494 | packets===============>| 495 | | | 496 |<=================================== deliver packets 497 | | 499 Figure 3: ``Reactive'' Fast Handover 501 The RtSolPr message contains one or more AP-IDs. A wildcard requests 502 all available tuples. 504 As a response to RtSolPr, PAR sends a PrRtAdv message which indicates 505 one of the following possible conditions. 507 1. If the PAR does not have an entry corresponding to the new access 508 point, it MUST respond indicating that the new access point is 509 unknown. The MN MUST stop fast handover protocol operations on 510 the current link. The MN MAY send an FBU from its new link. 512 2. If the new access point is connected to the PAR's current 513 interface (to which MN is attached), PAR MUST respond with a Code 514 value indicating that the new access point is connected to the 515 current interface, but not send any prefix information. This 516 scenario could arise, for example, when several wireless access 517 points are bridged into a wired network. No further protocol 518 action is necessary. 520 3. If the new access point is known and the PAR has information 521 about it, then PAR MUST respond indicating that the new access 522 point is known and supply the [AP-ID, AR-Info] tuple. If the new 523 access point is known, but does not support fast handover, the 524 PAR MUST indicate this with Code 3 (See Section 6.1.2). 526 4. If a wildcard is supplied as an identifier for the new access 527 point, the PAR SHOULD supply neighborhood [AP-ID, AR-Info] tuples 528 subject to path MTU restrictions (i.e., provide any `n' tuples 529 without exceeding the link MTU). 531 When further protocol action is necessary, some implementations MAY 532 choose to begin buffering copies of incoming packets at PAR. If such 533 FIFO buffering is used, PAR MUST continue forwarding the packets to 534 PCoA (i.e., buffer and forward). Such buffering can be useful when 535 the MN leaves without sending the FBU message from the PAR's link. 536 The PAR SHOULD stop buffering after processing the FBU message. The 537 size of the buffer is an implementation-specific consideration. 539 The method by which Access Routers exchange information about 540 their neighbors and thereby allow construction of Proxy Router 541 Advertisements with information about neighboring subnets is outside 542 the scope of this document. 544 The RtSolPr and PrRtAdv messages MUST be implemented by a MN and 545 an access router that supports fast handovers. However, when 546 the parameters necessary for the MN to send packets immediately 547 upon attaching to the NAR are supplied by the link layer handover 548 mechanism itself, use of above messages is optional on such links. 550 After a PrRtAdv message is processed, the MN sends FBU and includes 551 the proposed NCoA. The MN SHOULD send FBU from PAR's link whenever 552 ``anticipation'' of handover is feasible. When anticipation is 553 not feasible or when it has not received an FBack, the MN sends 554 FBU immediately after attaching to NAR's link. This FBU SHOULD be 555 encapsulated in a FNA message. The encapsulation allows NAR to 556 discard the (inner) FBU packet if an address conflict is detected as 557 a result of (outer) FNA packet processing (see FNA processing below). 558 In response to FBU, PAR establishes a binding between PCoA (``Home 559 Address'') and NCoA, and sends FBack to MN. Prior to establishing 560 this binding, PAR SHOULD send a HI message to NAR, and receive HAck 561 in response. In order to determine the NAR's address for the HI 562 message, the PAR can perform longest prefix match of NCoA (in FBU) 563 with the prefix list of neighboring access routers. When the source 564 IP address of FBU is PCoA, i.e., the FBU is sent from the PAR's link, 565 the HI message MUST have a Code value set to 0. See Section 6.2.1. 566 When the source IP address of FBU is not PCoA, i.e., the FBU is sent 567 from the NAR's link, the HI message MUST have a Code value of 1. See 568 Section 6.2.1. 570 The HI message contains the PCoA, link-layer address and the NCoA of 571 the MN. In response to processing a HI message with Code 0, the NAR 572 1. determines whether NCoA supplied in the HI message is a valid 573 address for use, and if it is, starts proxying [6] the address 574 for PROXY_ND_LIFETIME during which the MN is expected to connect 575 to NAR. The NAR MAY use the link-layer address to verify if a 576 corresponding IP address exists in its forwarding tables. 578 2. allocates NCoA for the MN when assigned addressing is used, 579 creates a proxy neighbor cache entry and begins defending it. 580 The NAR MAY allocate the NCoA proposed in HI. 582 3. MAY create a host route entry for PCoA (on the interface to 583 which the MN is attaching to) in case NCoA cannot be accepted 584 or assigned. This host route entry SHOULD be implemented such 585 that until the MN's presence is detected, either through explicit 586 announcement by the MN or by other means, arriving packets do not 587 invoke neighbor discovery. The NAR MAY also set up a reverse 588 tunnel to PAR in this case. 590 4. provides the status of handover request in Handover Acknowledge 591 (HAck) message. 593 When the Code value in HI is 1, NAR MUST skip the above operations 594 since it would have performed those operations during FNA processing. 595 However, it SHOULD be prepared to process any other options which 596 may be defined in the future. Sending a HI message with Code 1 597 allows NAR to, loosely speaking, validate the neighbor cache entry 598 it creates for the MN during FNA processing. That is, NAR can make 599 use of the knowledge that its trusted peer (i.e., PAR) has a trust 600 relationship with the MN. 602 If HAck contains an assigned NCoA, FBack MUST include it, and the 603 MN MUST use the address provided in FBack. The PAR MAY send FBack 604 to previous link as well to facilitate faster reception in the 605 event the MN be still present there. The result of FBU and FBack 606 processing is that PAR begins tunneling MN's packets to NCoA. If the 607 MN does not receive an FBack message even after re-transmitting FBU 608 for FBU_RETRIES, it must assume that fast handover support is not 609 available and stop the protocol operation. 611 As soon as the MN establishes link connectivity with the NAR, it 612 SHOULD send a Fast Neighbor Advertisement (FNA) message (see 6.3.3). 613 If the MN has not received an FBack by the time FNA is being sent, it 614 SHOULD encapsulate the FBU in FNA and send them together. 616 When the NCoA corresponding to the FNA message is acceptable, the NAR 617 MUST, 619 1. delete its proxy neighbor cache entry, if any is present. 621 2. create a neighbor cache entry and set its state to REACHABLE 622 without over-writing an existing entry for a different layer 2 623 address. 625 3. forward any buffered packets 627 4. enable the host route entry, if any is present, for PCoA. 629 When the NCoA corresponding to the FNA message is not acceptable, the 630 NAR MUST 632 1. discard the inner (FBU) packet. 634 2. send a Router Advertisement with the NAACK option in which it MAY 635 include an alternate NCoA for use. This message MUST be sent 636 to the source IP address present in FNA using the same Layer 2 637 address present in FNA. 639 If the MN receives a Router Advertisement with a NAACK option, it 640 MUST use the IP address, if any, provided in the NAACK option. 641 Otherwise, the MN should configure another NCoA. Subsequently, the MN 642 SHOULD send an FBU using the new CoA. As a special case, the address 643 supplied in NAACK could be PCoA itself, in which case the MN MUST NOT 644 send any more FBUs. 646 Once the MN has confirmed its NCoA, it SHOULD send a Neighbor 647 Advertisement message. This message allows MN's neighbors to update 648 their neighbor cache entries with the MN's addresses. 650 For data forwarding, the PAR tunnels packets to the MN using 651 its global IP address valid on the interface to which the MN was 652 attached. The MN reverse tunnels its packets to the same global 653 address of PAR. The tunnel end-point addresses must be configured 654 accordingly. When PAR receives a reverse tunneled packet, it must 655 verify if a secure binding exists for the MN identified by PCoA in 656 the tunneled packet, before forwarding the packet. 658 5. Miscellaneous 660 5.1. Handover Capability Exchange 662 The MN expects a PrRtAdv in response to its RtSolPr message. If the 663 MN does not receive a PrRtAdv message even after RTSOLPR_RETRIES, it 664 must assume that PAR does not support the fast handover protocol and 665 stop sending any more RtSolPr messages. 667 Even if a MN's current access router is capable of fast handover, the 668 new access router to which the MN attaches may be incapable of fast 669 handover. This is indicated to the MN during ``runtime'', through 670 the PrRtAdv message with a Code value of 3 (see Section 6.1.2). 672 5.2. Determining New Care of Address 674 Typically, the MN formulates its prospective NCoA using the 675 information provided in a PrRtAdv message, and sends FBU. The PAR 676 MUST use the NCoA present in FBU in its HI message. The NAR MUST 677 verify if NCoA present in HI is already in use. In any case, NAR 678 MUST respond to HI using a HAck, in which it may include another NCoA 679 to use, especially when assigned address configuration is used. If 680 there is a CoA present in HAck, PAR MUST include it in the FBack 681 message. 683 If PrRtAdv message carries a NCoA, the MN MUST use it as its 684 prospective NCoA. 686 5.3. Packet Loss 688 Handover involves link switching, which may not be exactly 689 co-ordinated with fast handover signaling. Furthermore, the 690 arrival pattern of packets is dependent on many factors, including 691 application characteristics, network queuing behaviors etc. Hence, 692 packets may arrive at NAR before the MN is able to establish its 693 link there. These packets will be lost unless they are buffered 694 by the NAR. Similarly, if the MN attaches to NAR and then sends an 695 FBU message, packets arriving at PAR will be lost unless they are 696 buffered. This protocol provides an option to indicate request for 697 buffering at the NAR in the HI message. When the PAR requests this 698 feature (for the MN), it SHOULD also provide its own support for 699 buffering. 701 5.4. DAD Handling 703 Duplicate Address Detection (DAD) was defined in [7] to avoid address 704 duplication on links when stateless address auto-configuration is 705 used. The use of DAD to verify the uniqueness of an IPv6 address 706 configured through stateless auto-configuration adds delays to a 707 handover. 709 The probability of an interface identifier duplication on the same 710 subnet is very low, however it cannot be ignored. In this draft 711 certain precautions are proposed to minimize the effects of a 712 duplicate address occurrence. 714 In some cases the NAR may already have the knowledge required to 715 assess whether the MN's address is a duplicate or not before the MN 716 moves to the new subnet. For example, the NAR can have a list of all 717 nodes on its subnet, perhaps for access control, and by searching 718 this list, it can confirm whether the MN's address is a duplicate 719 or not. The result of this search is sent back to the PAR in the 720 HAck message. If such knowledge is not available at the NAR, it may 721 indicate this by not confirming NCoA in the HAck message. The NAR 722 may also indicate this in the NAACK option as a response to the FNA 723 message. In such cases, the MN would have to follow the address 724 configuration procedure according to [6] after attaching to the NAR. 726 5.5. Fast or Erroneous Movement 728 Although this specification is for fast handover, the protocol has 729 its limits in terms of how fast a MN can move. A special case 730 of fast movement is ping-pong, where a MN moves between the same 731 two access points rapidly. Another instance of the same problem 732 is erroneous movement i.e., the MN receives information prior to 733 a handover that it is moving to a new access point and but it is 734 either moved to a different one or it aborts movement altogether. 735 All of the above behaviors are usually the result of link layer 736 idiosyncrasies and thus are often tackled at the link layer itself. 738 IP layer mobility, however, introduces its own limits. IP layer 739 handovers should occur at a rate suitable for the MN to update the 740 binding of, at least, its HA and preferably that of every CN with 741 which it is in communication. A MN that moves faster than necessary 742 for this signaling to complete, which may be of the order of few 743 seconds, may start losing packets. The signaling overhead over the 744 air and in the network may increase significantly, especially in the 745 case of rapid movement between several access routers. To avoid the 746 signaling overhead, the following measures are suggested. 748 A MN returning to the PAR before updating the necessary bindings when 749 present on NAR MUST send a Fast Binding Update with Home Address 750 equal to the MN's PCoA and a lifetime of zero, to the PAR. The MN 751 should have a security association with the PAR since it performed 752 a fast handover from it to the NAR. The PAR, on receiving this 753 Fast Binding Update, will check its set of outgoing (temporary 754 fast handover) tunnels. If it finds a match it SHOULD tear down 755 that tunnel; i.e., stop forwarding packets for this MN and start 756 delivering packets directly to the node instead. The MN SHOULD NOT 757 make any attempt to use any of the fast handover mechanisms described 758 in this specification and SHOULD revert back to standard Mobile IPv6. 760 Temporary tunnels for the purposes of fast handovers should use short 761 lifetimes (in the order of a small number of seconds or less). The 762 lifetime of such tunnels should be enough to allow a MN to update all 763 its active bindings. The default lifetime of the tunnel should be 764 the same as the lifetime value in the FBU message. 766 The effect of erroneous movement is typically limited to loss of 767 packets since routing can change and the PAR may forward packets 768 towards another router before the MN actually connects to that 769 router. If the MN discovers itself on an unanticipated access 770 router, a Fast Binding Update to the PAR SHOULD be sent. Since 771 Fast Binding Updates are authenticated, they supersede the existing 772 binding and packets MUST be redirected to the new confirmed location 773 of the MN. 775 6. Message Formats 777 All the ICMPv6 messages have a common Type specified in [4]. The 778 messages are distinguished based on the Subtype field (see below). 779 The values for the Subtypes are specified in Section 9. For all the 780 ICMPv6 messages, the checksum is defined in [2]. 782 6.1. New Neighborhood Discovery Messages 784 6.1.1. Router Solicitation for Proxy Advertisement (RtSolPr) 786 Mobile Nodes send Router Solicitation for Proxy Advertisement in 787 order to prompt routers for Proxy Router Advertisements. All the 788 link-layer address options have the format defined in 6.4.3. 790 0 1 2 3 791 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 792 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 793 | Type | Code | Checksum | 794 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 795 | Subtype | Reserved | Identifier | 796 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 797 | Options ... 798 +-+-+-+-+-+-+-+-+-+-+-+- 800 Figure 4: Router Solicitation for Proxy (RtSolPr) Message 802 IP Fields: 804 Source Address 805 An IP address assigned to the sending interface 807 Destination Address 808 The address of the Access Router or the all routers 809 multicast address. 811 Hop Limit 255. See RFC 2461. 813 Authentication Header 814 If a Security Association for the IP Authentication 815 Header exists between the sender and the 816 destination address, then the sender SHOULD include 817 this header. See RFC 2402. 819 ICMP Fields: 821 Type The Experimental Mobility Protocol Type. See [4]. 823 Code 0 825 Checksum The ICMPv6 checksum. 827 Subtype 2 829 Reserved MUST be set to zero by the sender and ignored by 830 the receiver. 832 Identifier MUST be set by the sender so that replies can be 833 matched to this Solicitation. 835 Valid Options: 837 Source Link-layer Address 838 When known, the link-layer address of the sender 839 SHOULD be included using the Link-Layer Address 840 option. See LLA option format below. 842 New Access Point Link-layer Address 843 The link-layer address or identification of the 844 access point for which the MN requests routing 845 advertisement information. It MUST be included 846 in all RtSolPr messages. More than one such address 847 or identifier can be present. This field can also 848 be a wildcard address with all bits set to zero. 850 Future versions of this protocol may define new option types. 851 Receivers MUST silently ignore any options that they do not recognize 852 and continue processing the rest of the message. 854 Including the source LLA option allows the receiver to record the 855 sender's L2 address so that neighbor discovery, when the receiver 856 needs to send packets back to the sender (of RtSolPr message), can be 857 avoided. 859 When a wildcard is used for New Access Point LLA, no other New Access 860 Point LLA options must be present. 862 A Proxy Router Advertisement (PrRtAdv) message should be received by 863 the MN as a response to RtSolPr. If such a message is not received 864 in a short time period but no less than twice the typical round trip 865 time (RTT) over the access link or 100 milliseconds if RTT is not 866 known, it SHOULD resend RtSolPr message. Subsequent retransmissions 867 can be up to RTSOLPR_RETRIES, but MUST use an exponential backoff 868 in which the timeout period (i.e., 2xRTT or 100 milliseconds) is 869 doubled prior to each instance of retransmission. If Proxy Router 870 Advertisement is not received by the time the MN disconnects from the 871 PAR, the MN SHOULD send FBU immediately after configuring a new CoA. 873 When RtSolPr messages are sent more than once, they MUST be rate 874 limited with MAX_RTSOLPR_RATE per second. During each use of 875 RtSolPr, exponential backoff is used for retransmissions. 877 6.1.2. Proxy Router Advertisement (PrRtAdv) 879 Access routers send out Proxy Router Advertisement message 880 gratuitously if the handover is network-initiated or as a response 881 to RtSolPr message from a MN, providing the link-layer address, 882 IP address and subnet prefixes of neighboring routers. All the 883 link-layer address options have the format defined in 6.4.3. 885 IP Fields: 887 Source Address 888 MUST be the link-local address assigned to the 889 interface from which this message is sent. 891 Destination Address 892 The Source Address of an invoking Router 893 Solicitation for Proxy Advertisement or the address 894 of the node the Access Router is instructing to 895 handover. 897 0 1 2 3 898 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 899 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 900 | Type | Code | Checksum | 901 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 902 | Subtype | Reserved | Identifier | 903 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 904 | Options ... 905 +-+-+-+-+-+-+-+-+-+-+-+- 907 Figure 5: Proxy Router Advertisement (PrRtAdv) Message 909 Hop Limit 255. See RFC 2461. 911 Authentication Header 912 If a Security Association for the IP Authentication 913 Header exists between the sender and the 914 destination address, then the sender SHOULD include 915 this header. See RFC 2402. 917 ICMP Fields: 919 Type The Experimental Mobility Protocol Type. See [4]. 921 Code 0, 1, 2, 3 or 4. See below. 923 Checksum The ICMPv6 checksum. 925 Subtype 3 927 Reserved MUST be set to zero by the sender and ignored by 928 the receiver. 930 Identifier Copied from Router Solicitation for Proxy 931 Advertisement or set to Zero if unsolicited. 933 Valid Options in the following order: 935 Source Link-layer Address 936 When known, the link-layer address of the sender 937 SHOULD be included using the Link-Layer Address 938 option. See LLA option format below. 940 New Access Point Link-layer Address 941 The link-layer address or identification of the 942 access point is copied from RtSolPr 943 message. This option MUST be present. 945 New Router's Link-layer Address 946 The link-layer address of the Access Router for 947 which this message is proxied for. This option MUST be 948 included when Code is 0 or 1. 950 New Router's IP Address 951 The IP address of NAR. This option MUST be 952 included when Code is 0 or 1. 954 New Router Prefix Information Option. 955 Specifies the prefix of the Access 956 Router the message is proxied for and is used 957 for address auto-configuration. This option MUST be 958 included when Code is 0 or 1. However, when this 959 prefix is the same as what is used in the New 960 Router's IP Address option (above), the Prefix 961 Information option need not be present. 963 New CoA Option 964 MAY be present when PrRtAdv is sent 965 unsolicited. PAR MAY compute new CoA using NAR's 966 prefix information and the MN's L2 address, or by 967 any other means. 969 Future versions of this protocol may define new option types. 970 Receivers MUST silently ignore any options they do not recognize and 971 continue processing the message. 973 Currently, Code values 0, 1, 2, 3 and 4 are defined. 975 A Proxy Router Advertisement with Code 0 means that the MN should 976 use the [AP-ID, AR-Info] tuple (present in the options above) for 977 movement detection and NCoA formulation. The Option-Code field in 978 the New Access Point LLA option in this case is 1 reflecting the LLA 979 of the access point for which the rest of the options are related. 980 Multiple tuples may be present. 982 A Proxy Router Advertisement with Code 1 means that the message is 983 sent unsolicited. If a New CoA option is present following the New 984 Router Prefix Information option, the MN SHOULD use the supplied NCoA 985 and send FBU immediately or else stand to lose service. This message 986 acts as a network-initiated handover trigger. See Section 3.3. The 987 Option-Code field in the New Access Point LLA option (see below) in 988 this case is 1 reflecting the LLA of the access point for which the 989 rest of the options are related. 991 A Proxy Router Advertisement with Code 2 means that no new router 992 information is present. Each New Access Point LLA option contains 993 an Option-Code value (described below) which indicates a specific 994 outcome. 996 - When the Option-Code field in the New Access Point LLA option is 997 5, handover to that access point does not require change of CoA. 998 No other options are required in this case. 1000 - When the Option-Code field in the New Access Point LLA option is 1001 6, PAR is not aware of the Prefix Information requested. The MN 1002 SHOULD attempt to send FBU as soon as it regains connectivity 1003 with the NAR. No other options are required in this case. 1005 - When the Option-Code field in the New Access Point LLA option is 1006 7, it means that the NAR does not support fast handover. The MN 1007 MUST stop fast handover protocol operations. No other options 1008 are required in this case. 1010 A Proxy Router Advertisement with Code 3 means that new router 1011 information is present only for a subset of access points requested. 1012 The Option-Code field values (defined above including a value of 1) 1013 distinguish different outcomes for individual access points. 1015 A Proxy Router Advertisement with Code 4 means that the subnet 1016 information regarding neighboring access points is sent unsolicited, 1017 but the message is not a handover trigger, unlike when the message is 1018 sent with Code 1. Multiple tuples may be present. 1020 When a wildcard AP identifier is supplied in the RtSolPr message, 1021 the PrRtAdv message should include any 'n' [Access Point Identifier, 1022 Link-layer address option, Prefix Information Option] tuples 1023 corresponding to the PAR's neighborhood. 1025 6.2. Inter-Access Router Messages 1027 6.2.1. Handover Initiate (HI) 1029 The Handover Initiate (HI) is an ICMPv6 message sent by an Access 1030 Router (typically PAR) to another Access Router (typically NAR) to 1031 initiate the process of a MN's handover. 1033 IP Fields: 1035 0 1 2 3 1036 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 1037 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1038 | Type | Code | Checksum | 1039 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1040 | Subtype |S|U| Reserved | Identifier | 1041 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1042 | Options ... 1043 +-+-+-+-+-+-+-+-+-+-+-+- 1045 Figure 6: Handover Initiate (HI) Message 1047 Source Address 1048 The IP address of the PAR 1050 Destination Address 1051 The IP address of the NAR 1053 Hop Limit 255. See RFC 2461. 1055 Authentication Header 1056 The authentication header MUST be used when this 1057 message is sent. See RFC 2402. 1059 ICMP Fields: 1061 Type The Experimental Mobility Protocol Type. See [4]. 1063 Code 0 or 1. See below 1065 Checksum The ICMPv6 checksum. 1067 Subtype 4 1069 S Assigned address configuration flag. When set, this 1070 message requests a new CoA to be returned by the 1071 destination. May be set when Code = 0. MUST be 0 1072 when Code = 1. 1074 U Buffer flag. When set, the destination SHOULD buffer 1075 any packets towards the node indicated in the options 1076 of this message. Used when Code = 0, SHOULD be set 1077 to 0 when Code = 1. 1079 Reserved MUST be set to zero by the sender and ignored by 1080 the receiver. 1082 Identifier MUST be set by the sender so replies can be matched 1083 to this message. 1085 Valid Options: 1087 Link-layer address of MN 1088 The link-layer address of the MN that is 1089 undergoing handover to the destination (i.e., NAR). 1090 This option MUST be included so that the destination 1091 can recognize the MN. 1093 Previous Care of Address 1094 The IP address used by the MN while 1095 attached to the originating router. This option 1096 SHOULD be included so that host route can be 1097 established in case necessary. 1099 New Care of Address 1100 The IP address the MN wishes to use when 1101 connected to the destination. When the `S' bit is 1102 set, NAR MAY assign this address. 1104 The PAR uses a Code value of 0 when it processes an FBU with PCoA as 1105 source IP address. The PAR uses a Code value of 1 when it processes 1106 an FBU whose source IP address is not PCoA. 1108 If Handover Acknowledge (HAck) message is not received as a response 1109 in a short time period but no less than twice the typical round trip 1110 time (RTT) between source and destination, or 100 milliseconds if RTT 1111 is not known, the Handover Initiate SHOULD be re-sent. Subsequent 1112 retransmissions can be up to HI_RETRIES, but MUST use exponential 1113 backoff in which the timeout period (i.e., 2xRTT or 100 milliseconds) 1114 is doubled during each instance of retransmission. 1116 6.2.2. Handover Acknowledge (HAck) 1118 The Handover Acknowledgment message is a new ICMPv6 message that MUST 1119 be sent (typically by NAR to PAR) as a reply to the Handover Initiate 1120 message. 1122 IP Fields: 1124 Source Address 1125 0 1 2 3 1126 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 1127 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1128 | Type | Code | Checksum | 1129 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1130 | Subtype | Reserved | Identifier | 1131 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1132 | Options ... 1133 +-+-+-+-+-+-+-+-+-+-+-+- 1135 Figure 7: Handover Acknowledge (HAck) Message 1137 Copied from the destination address of the Handover 1138 Initiate Message to which this message is a 1139 response. 1141 Destination Address 1142 Copied from the source address of the Handover 1143 Initiate Message to which this message is a 1144 response. 1146 Hop Limit 255. See RFC 2461. 1148 Authentication Header 1149 The authentication header MUST be used when this 1150 message is sent. See RFC 2402. 1152 ICMP Fields: 1154 Type The Experimental Mobility Protocol Type. See [4]. 1156 Code 1157 0: Handover Accepted, NCoA valid 1158 1: Handover Accepted, NCoA not valid 1159 2: Handover Accepted, NCoA in use 1160 3: Handover Accepted, NCoA assigned 1161 (used in Assigned addressing) 1162 4: Handover Accepted, NCoA not assigned 1163 (used in Assigned addressing) 1164 5: Handover Accepted, use PCoA 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), using a host route entry to forward packets to the 1194 PCoA, and using a tunnel to the PAR to forward packets from the MN 1195 (sent with PCoA as source IP address). This host route entry SHOULD 1196 be used to forward packets once the NAR detects that the particular 1197 MN is attached to its link. The NAR indicates forwarding support 1198 for PCoA using Code value 5 in the HAck message. Subsequently, PAR 1199 establishes a tunnel to NAR in order to forward packets arriving for 1200 PCoA. 1202 When responding to a HI message containing a Code value 1, the Code 1203 values 1, 2, and 4 in the HAck message are not relevant. 1205 Finally, the new access router can always refuse handover, in which 1206 case it should indicate the reason in one of the available Code 1207 values. 1209 6.3. New Mobility Header Messages 1211 Mobile IPv6 uses a new IPv6 header type called Mobility Header [3]. 1212 The Fast Binding Update, Fast Binding Acknowledgment and Fast 1213 Neighbor Advertisement messages use the Mobility Header. 1215 6.3.1. Fast Binding Update (FBU) 1217 The Fast Binding Update message is identical to the Mobile IPv6 1218 Binding Update (BU) message. However, the processing rules are 1219 slightly different. 1221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1222 | Sequence # | 1223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1224 |A|H|L|K| Reserved | Lifetime | 1225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1226 | | 1227 . . 1228 . Mobility options . 1229 . . 1230 | | 1231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1233 Figure 8: Fast Binding Update (FBU) Message 1235 IP fields: 1237 Source address The PCoA or NCoA 1239 Destination Address 1240 The IP address of the Previous Access 1241 Router 1243 `A' flag MUST be set to one to request PAR to send a Fast 1244 Binding Acknowledgment message. 1246 `H' flag MUST be set to one. See [3]. 1248 `L' flag See [3]. 1250 `K' flag See [3]. 1252 Reserved This field is unused. MUST be set zero. 1254 Sequence Number See [3]. 1256 Lifetime See [3]. 1258 Mobility Options 1259 MUST contain alternate CoA option set to NCoA IP 1260 address when FBU is sent from PAR's link. 1262 The MN sends FBU message any time after receiving a PrRtAdv message. 1263 If the MN moves prior to receiving a PrRtAdv message, it SHOULD send 1264 a FBU to the PAR after configuring NCoA on the NAR according to 1265 Neighbor Discovery and IPv6 Address Configuration protocols. 1267 The source IP address is PCoA when FBU is sent from PAR's link, and 1268 the source IP address is NCoA when sent from NAR's link. When FBU is 1269 sent from NAR's link, it SHOULD be encapsulated within FNA. 1271 The FBU MUST also include the Home Address Option and the Home 1272 Address is PCoA. A FBU message MUST be protected so that PAR is able 1273 to determine that the FBU message is sent by a genuine MN. 1275 6.3.2. Fast Binding Acknowledgment (FBack) 1277 The Fast Binding Acknowledgment message is sent by the PAR to 1278 acknowledge receipt of a Fast Binding Update message in which the `A' 1279 bit is set. The Fast Binding Acknowledgment message SHOULD NOT be 1280 sent to the MN before the PAR receives a HAck message from the NAR. 1281 The Fast Binding Acknowledgment MAY also be sent to the MN on the old 1282 link. 1284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1285 | Status |K| Reserved | 1286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1287 | Sequence # | Lifetime | 1288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1289 | | 1290 . . 1291 . Mobility options . 1292 . . 1293 | | 1294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1296 Figure 9: Fast Binding Acknowledgment (FBack) Message 1298 IP fields: 1300 Source address The IP address of the Previous Access 1301 Router 1303 Destination Address The NCoA 1305 Status 1306 8-bit unsigned integer indicating the 1307 disposition of the Fast Binding Update. Values 1308 of the Status field less than 128 indicate that 1309 the Binding Update was accepted by the receiving 1310 node. The following such Status values are 1311 currently defined: 1313 0 Fast Binding Update accepted 1314 1 Fast Binding Update accepted but NCoA is 1315 invalid. Use NCoA supplied in ``alternate'' CoA 1317 Values of the Status field greater than or equal 1318 to 128 indicate that the Binding Update was 1319 rejected by the receiving node. The following 1320 such Status values are currently defined: 1322 128 Reason unspecified 1323 129 Administratively prohibited 1324 130 Insufficient resources 1325 131 Incorrect interface identifier length 1327 `K' flag See [3]. 1329 Reserved An unused field. MUST be set to zero. 1331 Sequence Number Copied from FBU message for use by the MN in 1332 matching this acknowledgment with an outstanding 1333 FBU. 1335 Lifetime 1336 The granted lifetime in seconds for which the 1337 sender of this message will retain a binding for 1338 traffic redirection. 1340 Mobility Options MUST contain ``alternate'' CoA if Status is 1. 1342 6.3.3. Fast Neighbor Advertisement (FNA) 1344 A MN sends a Fast Neighbor Advertisement to announce itself to the 1345 NAR. When the Mobility Header Type is FNA, the Payload Proto field 1346 may be set to IPv6 in order to assist FBU encapsulation. 1348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1349 | Reserved | 1350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1351 . . 1352 . Mobility Options . 1353 . . 1354 | | 1355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1357 Figure 10: Fast Neighbor Advertisement (FNA) Message 1359 IP fields: 1361 Source address NCoA 1363 Destination Address NAR's IP address 1365 Mobility Options MUST contain the Mobility Header Link-Layer 1366 Address of the MN in MH-LLA option format. See 1367 Section 6.4.4. 1369 The MN sends Fast Neighbor Advertisement to the NAR, as soon as it 1370 regains connectivity on the new link. Arriving or buffered packets 1371 can be immediately forwarded. If NAR is proxying NCoA, it creates 1372 a neighbor cache entry in REACHABLE state. If there is no entry at 1373 all, it creates one and sets it to REACHABLE. If there is an entry 1374 in INCOMPLETE state without a link-layer address, it sets it to 1375 REACHABLE. During the process of creating a neighbor cache entry, NAR 1376 can also detect if NCoA is in use, thus avoiding address collisions. 1377 Since FBU is encapsulated within FNA when sent from NAR's link, NAR 1378 drops FBU in case it detects any collision. 1380 The combination of NCoA (present in source IP address) and the 1381 Link-Layer Address (present as a Mobility Option) SHOULD be used to 1382 distinguish the MN from other nodes. 1384 6.4. New Options 1386 All the options are of the form shown in Figure 11. 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 The Type values are defined from the Neighbor Discovery options 1399 space. The Length field is in units of 8 octets, except for the 1400 Mobility Header Link-Layer Address option, whose Length field 1401 is in units of octets in accordance with [3], Section 6.2. And, 1402 Option-Code provides additional information for each of the options 1403 (See individual options below). 1405 6.4.1. IP Address Option 1407 This option is sent in the Proxy Router Advertisement, the Handover 1408 Initiate, and Handover Acknowledge messages. 1410 Type 1411 To be assigned by IANA 1413 Length 1414 The size of this option in 8 octets including the Type, 1415 Option-Code and Length fields. 1417 Option-Code 1418 1 Old Care-of Address 1419 2 New Care-of Address 1420 3 NAR's IP address 1422 Prefix Length 1423 The Length of the IPv6 Address Prefix. 1425 0 1 2 3 1426 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 1427 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1428 | Type | Length | Option-Code | Prefix Length | 1429 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1430 | Reserved | 1431 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1432 | | 1433 + + 1434 | | 1435 + IPv6 Address + 1436 | | 1437 + + 1438 | | 1439 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1441 Figure 12: IPv6 Address Option 1443 Reserved 1444 MUST be set to zero by the sender and MUST be 1445 ignored by the receiver. 1447 IPv6 address 1448 The IP address for the unit defined by the Type field. 1450 6.4.2. New Router Prefix Information Option 1452 This option is sent in the PrRtAdv message in order to provide the 1453 prefix information valid on the NAR. 1455 Type 1456 To be assigned by IANA 1458 Length 1459 The size of this option in 8 octets including the Type, 1460 Option-Code and Length fields. 1462 Option-Code 1463 0 1465 Prefix Length 1467 0 1 2 3 1468 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 1469 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1470 | Type | Length | Option-Code | Prefix Length | 1471 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1472 | Reserved | 1473 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1474 | | 1475 + + 1476 | | 1477 + Prefix + 1478 | | 1479 + + 1480 | | 1481 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1483 Figure 13: New Router Prefix Information Option 1485 8-bit unsigned integer. The number of leading bits in the 1486 Prefix that are valid. The value ranges from 0 to 128. 1488 Reserved 1489 MUST be set to zero by the sender and MUST be 1490 ignored by the receiver. 1492 Prefix 1493 An IP address or a prefix of an IP address. The Prefix Length 1494 field contains the number of valid leading bits in the prefix. 1495 The bits in the prefix after the prefix length are reserved 1496 and MUST be initialized to zero by the sender and ignored by 1497 the receiver. 1499 6.4.3. Link-layer Address (LLA) Option 1501 Type 1502 To be assigned by IANA 1504 Length 1505 The size of this option in 8 octets including the Type, 1506 Option-Code and Length fields. 1508 Option-Code 1509 0 1 2 3 1510 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 1511 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1512 | Type | Length | Option-Code | LLA... 1513 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1515 Figure 14: Link-Layer Address Option 1517 0 wildcard requesting resolution for all nearby access points 1518 1 Link-layer Address of the New Access Point 1519 2 Link-layer Address of the MN 1520 3 Link-layer Address of the NAR (i.e., Proxied Originator) 1521 4 Link-layer Address of the source of RtSolPr or PrRtAdv 1522 message 1523 5 The access point identified by the LLA belongs to the 1524 current interface of the router 1525 6 No prefix information available for the access point 1526 identified by the LLA 1527 7 No fast handovers support available for the access point 1528 identified by the LLA 1530 LLA 1531 The variable length link-layer address. 1533 Depending on the size of individual LLA option, appropriate padding 1534 MUST be used to ensure that the entire option size is a multiple of 8 1535 octects. 1537 The New Access Point Link Layer address contains the link-layer 1538 address of the access point for which handover is about to be 1539 attempted. This is used in the Router Solicitation for Proxy 1540 Advertisement message. 1542 The MN Link-Layer address option contains the link-layer address of a 1543 MN. It is used in the Handover Initiate message. 1545 The NAR (i.e., Proxied Originator) Link-Layer address option contains 1546 the Link Layer address of the Access Router for which the Proxy 1547 Router Solicitation message refers to. 1549 6.4.4. Mobility Header Link-layer Address (MH-LLA) Option 1551 This option is identical to the LLA option, but is carried in the 1552 Mobility Header messages, e.g., FNA. In the future, other Mobility 1553 Header messages may also make use of this option. The format of the 1554 option when LLA is 6 bytes is shown in Figure 15. When LLA size is 1555 different, the option MUST be aligned appropriately. (See Section 1556 6.2 in [3]). 1558 0 1 2 3 1559 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 1560 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1561 | Type | Length | 1562 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1563 | Option-Code | Pad0=0 | LLA | 1564 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1565 | LLA | 1566 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1568 Figure 15: Mobility Header Link-Layer Address Option 1570 Type 1571 To be assigned by IANA 1573 Length 1574 The size of this option in octets not including the Type, 1575 Length and Option-Code fields. 1577 Option-Code 1578 2 Link-layer Address of the MN 1580 LLA 1581 The variable length link-layer address. 1583 6.4.5. Neighbor Advertisement Acknowledgment (NAACK) 1585 Type 1586 To be assigned by IANA. 1588 Length 1589 8-bit unsigned integer. Length of the option, in 8 1591 0 1 2 3 1592 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 1593 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1594 | Type | Length | Option-Code | Status | 1595 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1596 | Reserved | 1597 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1599 Figure 16: Neighbor Advertisement Acknowledgment Option 1601 octets. The length is 1 when a new CoA is not supplied. The 1602 length is 3 when a new CoA is present (immediately following 1603 the Reserved field) 1605 Option-Code 1606 0 1608 Status 1609 8-bit unsigned integer indicating the disposition of the Fast 1610 Neighbor Advertisement message. The following Status 1611 values are currently defined: 1613 1 The New CoA is invalid 1614 2 The New CoA is invalid, use the supplied CoA. The New 1615 CoA MUST be present following the Reserved field. 1616 128 Link Layer Address unrecognized 1617 Reserved 1618 MUST be set to zero by the sender and MUST be 1619 ignored by the receiver. 1621 Since the NAACK option is carried in a Router Advertisement, the 1622 Length field is units of 8 octets unlike in other options. 1624 The NAR responds to FNA with the NAACK option to notify the MN 1625 to use a different NCoA if there is address collision. If the 1626 NCoA is invalid, the Router Advertisement MUST use the NCoA as the 1627 destination address but use the L2 address present in FNA. The MN 1628 SHOULD use the NCoA if it is supplied with the NAACK option. If the 1629 NAACK indicates that the Link Layer Address is unrecognized the MN 1630 MUST NOT use the NCoA or the PCoA and SHOULD start immediately the 1631 process of acquiring a NCoA at the NAR. 1633 In the future, new option types may be defined. 1635 7. Configurable Parameters 1637 Parameter Name Default Value Definition 1638 ------------------- ---------------------- ------- 1639 RTSOLPR_RETRIES 3 Section6.1.1 1640 MAX_RTSOLPR_RATE 3 Section6.1.1 1641 FBU_RETRIES 3 Section 4 1642 PROXY_ND_LIFETIME 1.5 seconds Section 6.2.2 1643 HI_RETRIES 3 Section 6.2.1 1645 8. Security Considerations 1647 The following security vulnerabilities are identified, and suggested 1648 solutions mentioned. 1650 1. Insecure FBU: in this case, packets meant for one address could 1651 be stolen, or redirected to some unsuspecting node. This concern 1652 is the same as that in a MN and Home Agent relationship. 1654 Hence, the PAR MUST ensure that the FBU packet arrived from a 1655 node that legitimately owns the PCoA. The access router and its 1656 hosts may use any available mechanism to establish a security 1657 association which MUST be used to secure FBU. The current version 1658 of this protocol does not specify how this security association 1659 is established. However, future work may specify this security 1660 association establishment. 1662 If an access router can ensure that the source IP address in 1663 an arriving packet could only have originated from the node 1664 whose link-layer address is in the router's neighbor cache, then 1665 a bogus node cannot use a victim's IP address for malicious 1666 redirection of traffic. Such an operation is recommended at 1667 least on neighbor discovery messages including the RtSolPr 1668 message. 1670 2. Secure FBU, malicious or inadvertent redirection: in this case, 1671 the FBU is secured, but the target of binding happens to be an 1672 unsuspecting node either due to inadvertent operation or due 1673 to malicious intent. This vulnerability can lead to a MN with 1674 genuine security association with its access router redirecting 1675 traffic to an incorrect address. 1677 However, the target of malicious traffic redirection is limited 1678 to an interface on an access router with which the PAR has a 1679 security association. The PAR MUST verify that the NCoA to 1680 which PCoA is being bound actually belongs to NAR's prefix. In 1681 order to do this, HI and HAck message exchanges are to be used. 1682 When NAR accepts NCoA in HI (with Code = 0), it proxies NCoA so 1683 that any arriving packets are not sent on the link until the MN 1684 attaches and announces itself through FNA. So, any inadvertent or 1685 malicious redirection to a host is avoided. It is still possible 1686 to jam NAR's buffer with redirected traffic. However, since 1687 NAR's handover state corresponding to NCoA has a finite (and 1688 short) lifetime corresponding to a small multiple of anticipated 1689 handover latency, the extent of this vulnerability is arguably 1690 small. 1692 3. Sending FBU from NAR's link: a malicious node may send FBU from 1693 NAR's link providing an unsuspecting node's address as NCoA. 1694 Since FBU is encapsulated in FNA, NAR should detect the collision 1695 with an address in use when processing FNA, and it then drops 1696 FBU. When NAR is unable to detect address collisions, there is a 1697 vulnerability that redirection can affect an unsuspecting node. 1699 9. IANA Considerations 1701 This document defines four new experimental ICMPv6 messages which use 1702 the Experimental Mobility Protocol ICMPv6 format [4]. These require 1703 four new Subtype value assignments out of the Experimental Mobility 1704 Protocol Subtype Registry [4] as follows: 1706 Subtype Description Reference 1707 ------- ----------- --------- 1708 2 RtSolPr Section 6.1.1 1709 3 PrRtAdv Section 6.1.2 1710 4 HI Section 6.2.1 1711 5 HAck Section 6.2.2 1713 The document defines four new Neighbor Discovery [6] options which 1714 need Type assignment from IANA. 1715 Option-Type Description Reference 1716 ----------- ----------- --------- 1717 TBD IP Address Option Section 6.4.1 1718 TBD New Router Prefix 1719 Information Option Section 6.4.2 1720 TBD Link-layer Address 1721 Option Section 6.4.3 1722 TBD Neighbor Advertisement 1723 Acknowledgment Option Section 6.4.5 1725 The document defines three new Mobility Header messages which 1726 need type allocation from the Mobility Header Types registry at 1727 http://www.iana.org/assignments/mobility-parameters: 1729 1. Fast Binding Update, described in Section 6.3.1 1731 2. Fast Binding Acknowledgment, described in Section 6.3.2, and 1733 3. Fast Neighbor Advertisement, described in Section 6.3.3 1735 The document defines a new Mobility Option which needs 1736 type assignment from the Mobility Options Type registry at 1737 http://www.iana.org/assignments/mobility-parameters: 1739 1. Mobility Header Link-Layer Address option, described in 1740 Section 6.4.4. 1742 10. Acknowledgments 1744 The editor would like to thank all those who have provided feedback 1745 on this specification, but can only mention a few here: Vijay 1746 Devarapalli, Youn-Hee Han, Suvidh Mathur, Gabriel Montenegro, Takeshi 1747 Ogawa, Sun Peng, YC Peng, Domagoj Premec, and Jonathan Wood. The 1748 editor would like to acknowledge contribution from James Kempf to 1749 improve this specification. The editor would also like to thank 1750 [mipshop] working group chair Gabriel Montenegro and the erstwhile 1751 [mobile ip] working group chairs Basavaraj Patil and Phil Roberts for 1752 providing much support for this work. 1754 11. Normative References 1756 References 1758 [1] S. Bradner, ``Key words for use in RFCs to Indicate Requirement 1759 Levels,'' Request for Comments (Best Current Practice) 2119, 1760 Internet Engineering Task Force, March 1997. 1762 [2] A. Conta and S. Deering, ``Internet Control Message 1763 Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) 1764 Specification'', Request for Comments (Draft Standard) 2463, 1765 Internet Engineering Task Force, December 1998. 1767 [3] D. Johnson, C. E. Perkins, and J. Arkko, ``Mobility Support in 1768 IPv6'', Request for Comments (Proposed Standard) 3775, Internet 1769 Engineering Task Force, June 2004. 1771 [4] J. Kempf, ``Instructions for Seamoby and Experimental Mobility 1772 Protocol IANA Allocations (work in progress)'', Internet 1773 Engineering Task Force, June 2004. 1775 [5] S. Kent and R. Atkinson, ``IP Authentication Header'', Request 1776 for Comments (Draft Standard) 2402, Internet Engineering Task 1777 Force, November 1998. 1779 [6] T. Narten, E. Nordmark, and W. Simpson, ``Neighbor Discovery for 1780 IP Version 6 (IPv6)'', Request for Comments (Draft Standard) 1781 2461, Internet Engineering Task Force, December 1998. 1783 [7] S. Thomson and T. Narten, ``IPv6 Stateless Address 1784 Autoconfiguration'', Request for Comments (Draft Standard) 2462, 1785 Internet Engineering Task Force, December 1998. 1787 12. Author's Address 1789 Rajeev Koodli, Editor 1790 Nokia Research Center 1791 313 Fairchild Drive 1792 Mountain View, CA 94043 USA 1793 Phone: +1 650 625 2359 1794 Fax: +1 650 625 2502 1795 E-Mail: Rajeev.Koodli@nokia.com 1797 13. Contributors 1799 This document has its origins in the fast handover design team 1800 effort. The members of this design team in alphabetical order were; 1801 Gopal Dommety, Karim El-Malki, Mohammed Khalil, Charles Perkins, 1802 Hesham Soliman, George Tsirtsis and Alper Yegin. 1804 A. Change Log 1806 The following revisions have been done since IESG review in Sep 04. 1808 - Added IPSec AH reference. 1810 - Changed options format to make use of RFC 2461 options Type 1811 space. Revised IANA Considerations section accordingly. 1813 - Added exponential backoff for retransmissions. Added rate 1814 limiting for RtSolPr message. 1816 - Replaced ``attachment point'' with ``access point'' for 1817 consistency. 1819 - Clarified [AP-ID, AR-Info] in Section 2. Clarified use of Prefix 1820 Information Option in Section 6.1.2. 1822 - Separated MH-LLA from LLA to future-proof LLA option. 1824 The following changes refer up to version 02 (under mipshop). The 1825 Section numbers refer to version 06 (under mobile ip). 1827 - New ICMPv6 format incorporated. ID Nits conformance. 1829 - Last Call comments incorporated 1831 - Revised the security considerations section in v07 1833 - Refined and added a section on network-initiated handover v07 1835 - Section 3 format change 1837 - Section 4 format change (i.e., no subsections). 1839 - Description in Section 4.4 merged with ``Fast or Erroneous 1840 Movement'' 1842 - Section 4.5 deprecated 1844 - Section 4.6 deprecated 1846 - Revision of some message formats in Section 6 1848 Intellectual Property Statement 1850 The IETF takes no position regarding the validity or scope of any 1851 Intellectual Property Rights or other rights that might be claimed to 1852 pertain to the implementation or use of the technology described in 1853 this document or the extent to which any license under such rights 1854 might or might not be available; nor does it represent that it has 1855 made any independent effort to identify any such rights. Information 1856 on the procedures with respect to rights in RFC documents can be 1857 found in BCP 78 and BCP 79. 1859 Copies of IPR disclosures made to the IETF Secretariat and any 1860 assurances of licenses to be made available, or the result of an 1861 attempt made to obtain a general license or permission for the 1862 use of such proprietary rights by implementers or users of this 1863 specification can be obtained from the IETF on-line IPR repository at 1864 http://www.ietf.org/ipr. 1866 The IETF invites any interested party to bring to its attention any 1867 copyrights, patents or patent applications, or other proprietary 1868 rights that may cover technology that may be required to implement 1869 this standard. Please address the information to the IETF at 1870 ietf-ipr@ietf.org. 1872 Disclaimer of Validity 1874 This document and the information contained herein are provided 1875 on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 1876 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 1877 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 1878 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1879 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1880 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1882 Copyright Statement 1884 Copyright (C) The Internet Society (2006). This document is subject 1885 to the rights, licenses and restrictions contained in BCP 78, and 1886 except as set forth therein, the authors retain all their rights. 1888 Acknowledgment 1890 Funding for the RFC Editor function is currently provided by the 1891 Internet Society.