idnits 2.17.1 draft-ietf-mipshop-fmipv6-rfc4068bis-04.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 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1955. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1966. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1973. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1979. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == The document seems to lack 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? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (November 19, 2007) is 5974 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: 'AP-ID' is mentioned on line 1902, but not defined == Missing Reference: 'AR-Info' is mentioned on line 1902, but not defined Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MIPSHOP Working Group Rajeev. Koodli 3 Internet-Draft Nokia Siemens Networks 4 Intended status: Standards Track November 19, 2007 5 Expires: May 22, 2008 7 Mobile IPv6 Fast Handovers 8 draft-ietf-mipshop-fmipv6-rfc4068bis-04.txt 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on May 22, 2008. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2007). 39 Abstract 41 Mobile IPv6 enables a Mobile Node to maintain its connectivity to the 42 Internet when moving from an Access Router to another, a process 43 referred to as handover. During this time, the Mobile Node is unable 44 to send or receive packets due to both link switching delay and IP 45 protocol operations. The "handover latency" resulting from standard 46 Mobile IPv6 procedures, namely, movement detection, new Care of 47 Address configuration and Binding Update, is often unacceptable to 48 real-time traffic such as Voice over IP. Reducing the handover 49 latency could be beneficial to non real-time, throughput-sensitive 50 applications as well. This document specifies a protocol to improve 51 handover latency due to Mobile IPv6 procedures. This document does 52 not address improving the link switching latency. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 6 59 3.1. Addressing the Handover Latency . . . . . . . . . . . . . 6 60 3.2. Protocol Operation . . . . . . . . . . . . . . . . . . . . 9 61 3.3. Protocol Operation during Network-initiated Handover . . . 10 62 4. Protocol Details . . . . . . . . . . . . . . . . . . . . . . . 12 63 5. Other Considerations . . . . . . . . . . . . . . . . . . . . . 16 64 5.1. Handover Capability Exchange . . . . . . . . . . . . . . . 16 65 5.2. Determining New Care of Address . . . . . . . . . . . . . 16 66 5.3. Prefix Management . . . . . . . . . . . . . . . . . . . . 17 67 5.4. Packet Loss . . . . . . . . . . . . . . . . . . . . . . . 17 68 5.5. DAD Handling . . . . . . . . . . . . . . . . . . . . . . . 17 69 5.6. Fast or Erroneous Movement . . . . . . . . . . . . . . . . 18 70 6. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 19 71 6.1. New Neighborhood Discovery Messages . . . . . . . . . . . 19 72 6.1.1. Router Solicitation for Proxy Advertisement 73 (RtSolPr) . . . . . . . . . . . . . . . . . . . . . . 19 74 6.1.2. Proxy Router Advertisement (PrRtAdv) . . . . . . . . . 21 75 6.2. Inter-Access Router Messages . . . . . . . . . . . . . . . 24 76 6.2.1. Handover Initiate (HI) . . . . . . . . . . . . . . . . 24 77 6.2.2. Handover Acknowledge (HAck) . . . . . . . . . . . . . 26 78 6.3. New Mobility Header Messages . . . . . . . . . . . . . . . 28 79 6.3.1. Fast Binding Update (FBU) . . . . . . . . . . . . . . 28 80 6.3.2. Fast Binding Acknowledgment (FBack) . . . . . . . . . 29 81 6.4. Unsolicited Neighbor Advertisement (UNA) . . . . . . . . . 31 82 6.5. New Options . . . . . . . . . . . . . . . . . . . . . . . 32 83 6.5.1. IP Address/Prefix Option . . . . . . . . . . . . . . . 32 84 6.5.2. Link-layer Address (LLA) Option . . . . . . . . . . . 33 85 6.5.3. Mobility Header Link-layer Address (MH-LLA) Option . . 34 86 6.5.4. Binding Authorization Data for FMIPv6 (BADF) . . . . . 35 87 6.5.5. Neighbor Advertisement Acknowledgment (NAACK) . . . . 36 88 7. Related Protocol and Device Considerations . . . . . . . . . . 37 89 8. Configurable Parameters . . . . . . . . . . . . . . . . . . . 38 90 9. Security Considerations . . . . . . . . . . . . . . . . . . . 38 91 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39 92 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 40 93 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 41 94 12.1. Normative References . . . . . . . . . . . . . . . . . . . 41 95 12.2. Informative References . . . . . . . . . . . . . . . . . . 41 96 Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 42 97 Appendix B. . . . . . . . . . . . . . . . . . . . . . . . . . . 42 98 Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 43 99 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 44 100 Intellectual Property and Copyright Statements . . . . . . . . . . 46 102 1. Introduction 104 Mobile IPv6 [rfc3775] describes the protocol operations for a mobile 105 node to maintain connectivity to the Internet during its handover 106 from one access router to another. These operations involve link 107 layer procedures, movement detection, IP address configuration, and 108 location update. The combined handover latency is often sufficient 109 to affect real-time applications. Throughput-sensitive applications 110 can also benefit from reducing this latency. This document describes 111 a protocol to reduce the handover latency. 113 This specification addresses the following problem: how to allow a 114 mobile node to send packets as soon as it detects a new subnet link, 115 and how to deliver packets to a mobile node as soon as its attachment 116 is detected by the new access router. The protocol defines IP 117 protocol messages necessary for its operation regardless of link 118 technology. It does this without depending on specific link-layer 119 features while allowing link-specific customizations. By definition, 120 this specification considers handovers that interwork with Mobile IP: 121 once attached to its new access router, a MN engages in Mobile IP 122 operations including Return Routability [rfc3775]. There are no 123 special requirements for a mobile node to behave differently with 124 respect to its standard Mobile IP operations. 126 2. Terminology 128 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 129 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "OPTIONAL", and 130 "silently ignore" in this document are to be interpreted as described 131 in RFC 2119 [RFC2119]. 133 The following terminology and abbreviations are used in this document 134 in addition to those defined in [rfc3775]. The reference handover 135 scenario is illustrated in Figure 1. 137 Mobile Node (MN): A Mobile IPv6 host 139 Access Point (AP): A Layer 2 device connected to an IP subnet that 140 offers wireless connectivity to a MN. An Access Point Identifier 141 (AP-ID) refers the AP's L2 address. Sometimes, AP-ID is also 142 referred to as a Basic Service Set IDentifier (BSSID). 144 Access Router (AR): The MN's default router 146 Previous Access Router (PAR): The MN's default router prior to its 147 handover 148 New Access Router (NAR): The MN's anticipated default router 149 subsequent to its handover 151 Previous CoA (PCoA): The MN's Care of Address valid on PAR's 152 subnet 154 New CoA (NCoA): The MN's Care of Address valid on NAR's subnet 156 Handover: A process of terminating existing connectivity and 157 obtaining new IP connectivity 159 Router Solicitation for Proxy Advertisement (RtSolPr): A message 160 from the MN to the PAR requesting information for a potential 161 handover 163 Proxy Router Advertisement (PrRtAdv): A message from the PAR to 164 the MN that provides information about neighboring links 165 facilitating expedited movement detection. The message can also 166 act as a trigger for network-initiated handover. 168 (AP-ID, AR-Info) tuple: Contains an access router's L2 and IP 169 addresses, and prefix valid on the interface to which the Access 170 Point (identified by AP-ID) is attached. The triplet [Router's L2 171 address, Router's IP address and Prefix] is called "AR-Info". See 172 also Section 5.3. 174 Neighborhood Discovery: The process of resolving neighborhood AP- 175 IDs to AR-Info 177 Assigned Addressing: A particular type of NCoA configuration in 178 which the NAR assigns an IPv6 address for the MN. The method by 179 which NAR manages its address pool is not specified in this 180 document. 182 Fast Binding Update (FBU): A message from the MN instructing its 183 PAR to redirect its traffic (towards NAR) 185 Fast Binding Acknowledgment (FBack): A message from the PAR in 186 response to FBU 188 Predictive Fast Handover: The fast handover in which a MN is able 189 to send FBU when it is attached to the PAR, which then establishes 190 forwarding for its traffic (even before the MN attaches to the 191 NAR) 192 Reactive Fast Handover: The fast handover in which a MN is able to 193 send the FBU only after attaching to the NAR 195 Unsolicited Neighbor Advertisement (UNA): The message in [rfc4861] 196 with 'O' bit cleared 198 Fast Neighbor Advertisement (FNA): This message from RFC4068 199 [rfc4068] is deprecated. The UNA message above is the preferred 200 message in this specification. 202 Handover Initiate (HI): A message from the PAR to the NAR 203 regarding a MN's handover 205 Handover Acknowledge (HAck): A message from the NAR to the PAR as 206 a response to HI 208 v +--------------+ 209 +-+ | Previous | < 210 | | ------------ | Access | ------- >-----\ 211 +-+ | Router | < \ 212 MN | (PAR) | \ 213 | +--------------+ +---------------+ 214 | ^ IP | Correspondent | 215 | | Network | Node | 216 V | +---------------+ 217 v / 218 v +--------------+ / 219 +-+ | New | < / 220 | | ------------ | Access | ------- >-----/ 221 +-+ | Router | < 222 MN | (NAR) | 223 +--------------+ 225 Figure 1: Reference Scenario for Handover 227 3. Protocol Overview 229 3.1. Addressing the Handover Latency 231 The ability to immediately send packets from a new subnet link 232 depends on the "IP connectivity" latency, which in turn depends on 233 the movement detection latency and the new CoA configuration latency. 234 Once a MN is IP-capable on the new subnet link, it can send a Binding 235 Update to its Home Agent and one or more correspondents. Once its 236 correspondents successfully process the Binding Update, which 237 typically involves the Return Routability procedure, the MN can 238 receive packets at the new CoA. So, the ability to receive packets 239 from correspondents directly at its new CoA depends on the Binding 240 Update latency as well as the IP connectivity latency. 242 The protocol enables a MN to quickly detect that it has moved to a 243 new subnet by providing the new access point and the associated 244 subnet prefix information when the MN is still connected to its 245 current subnet (i.e., PAR in Figure 1). For instance, a MN may 246 discover available access points using link-layer specific mechanisms 247 (e.g., a "scan" in WLAN) and then request subnet information 248 corresponding to one or more of those discovered access points. The 249 MN may do this after performing router discovery. The MN may also do 250 this at any time while connected to its current router. The result 251 of resolving an identifier associated with an access point is a 252 [AP-ID, AR-Info] tuple, which a MN can use in readily detecting 253 movement: when attachment to an access point with AP-ID takes place, 254 the MN knows the corresponding new router's co-ordinates including 255 its prefix, IP address and L2 address. The "Router Solicitation for 256 Proxy Advertisement (RtSolPr)" and "Proxy Router Advertisement 257 (PrRtAdv)" messages in Section 6.1 are used for aiding movement 258 detection. 260 Through the RtSolPr and PrRtAdv messages, the MN also formulates a 261 prospective new CoA (NCoA), when it is still present on the PAR's 262 link. Hence, the latency due to new prefix discovery subsequent to 263 handover is eliminated. Furthermore, this prospective address can be 264 used immediately after attaching to the new subnet link (i.e., NAR's 265 link) when the MN has received a "Fast Binding Acknowledgment 266 (FBack)" (see Section 6.3.2) message prior to its movement. In the 267 event it moves without receiving an FBack, the MN can still start 268 using NCoA after announcing its attachment through an unsolicited 269 Neighbor Advertisement message (with the 'O' bit set to zero) message 270 [rfc4861]; NAR responds to to this UNA message in case it wishes to 271 provide a different IP address to use. In this way, NCoA 272 configuration latency is reduced. 274 The information provided in the PrRtAdv message can be used even when 275 DHCP [rfc3315] is used to configure an NCoA on the NAR's link. In 276 this case, the protocol supports forwarding for PCoA and the MN 277 performs DHCP once it attaches to the NAR's link even though it 278 formulates an NCoA for transmitting FBU. 280 In order to reduce the Binding Update latency, the protocol specifies 281 a binding between the Previous CoA (PCoA) and NCoA. A MN sends a 282 "Fast Binding Update" (see Section 6.3.1) message to its Previous 283 Access Router to establish this tunnel. When feasible, the MN SHOULD 284 send FBU from PAR's link. Otherwise, it should send it immediately 285 after detecting attachment to NAR. An FBU message MUST contain the 286 Binding Authorization Data for FMIPv6 (BADF) option (see 287 Section 6.5.4) in order to ensure that only a legitimate MN that owns 288 the PCoA is able to establish a binding. Subsequent sections 289 describe the protocol mechanics. In any case, the result is that PAR 290 begins tunneling packets arriving for PCoA to NCoA. Such a tunnel 291 remains active until the MN completes the Binding Update with its 292 correspondents. In the opposite direction, the MN SHOULD reverse 293 tunnel packets to PAR, again until it completes Binding Update. And, 294 PAR SHOULD forward the inner packet in the tunnel to its destination 295 (i.e., to the MN's correspondent). Such a reverse tunnel ensures 296 that packets containing PCoA as source IP address are not dropped due 297 to ingress filtering. Even though the MN is IP-capable on the new 298 link, it cannot use NCoA directly with its correspondents without the 299 correspondents first establishing a binding cache entry (for NCoA). 300 Forwarding support for PCoA is provided through a reverse tunnel 301 between the MN and the PAR. 303 Setting up a tunnel alone does not ensure that the MN receives 304 packets as soon as attaching to a new subnet link, unless NAR can 305 detect the MN's presence. A neighbor discovery operation involving a 306 neighbor's address resolution (i.e., Neighbor Solicitation and 307 Neighbor Advertisement) typically results in considerable delay, 308 sometimes lasting multiple seconds. For instance, when arriving 309 packets trigger NAR to send Neighbor Solicitation before the MN 310 attaches, subsequent re-transmissions of address resolution are 311 separated by a default period of one second each. In order to 312 circumvent this delay, a MN announces its attachment immediately with 313 an UNA message that allows NAR to forward packets to the MN right 314 away. Through tunnel establishment for PCoA and fast advertisement, 315 the protocol provides expedited forwarding of packets to the MN. 317 The protocol also provides the following important functionalities. 318 The access routers can exchange messages to confirm that a proposed 319 NCoA is acceptable. For instance, when a MN sends FBU from PAR's 320 link, FBack can be delivered after NAR considers NCoA acceptable to 321 use. This is especially useful when addresses are assigned by the 322 access router. The NAR can also rely on its trust relationship with 323 PAR before providing forwarding support for the MN. That is, it may 324 create a forwarding entry for NCoA subject to "approval" from PAR 325 which it trusts. In addition, buffering for handover traffic may be 326 desirable. Even though the Neighbor Discovery protocol provides a 327 small buffer (typically one or two packets) for packets awaiting 328 address resolution, this buffer may be inadequate for traffic such as 329 VoIP already in progress. The routers may also wish to maintain a 330 separate buffer for servicing the handover traffic. Finally, the 331 access routers could transfer network-resident contexts, such as 332 access control, QoS, header compression, in conjunction with handover 333 (although the context transfer process itself is not specified in 334 this document). For all these operations, the protocol provides 335 "Handover Initiate (HI)" and "Handover Acknowledge (HAck)" messages 336 (see Section 6.2). Both of these messages SHOULD be used. The 337 access routers MUST have necessary security association established 338 by means outside the scope of this document. 340 3.2. Protocol Operation 342 The protocol begins when a MN sends RtSolPr to its access router to 343 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 by 350 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 358 should be sent from PAR's link whenever feasible. For instance, an 359 internal link-specific trigger could enable FBU transmission from the 360 previous link. 362 When it is not feasible, FBU is sent from the new link. 364 The format and semantics of FBU processing are specified in 365 Section 6.3.1. The FBU message MUST contain the BADF option (see 366 Section 6.5.4) to secure the message. 368 Depending on whether an FBack is received or not on the previous 369 link, which clearly depends on whether FBU was sent in the first 370 place, there are two modes of operation. 372 1. The MN receives FBack on the previous link. This means that 373 packet tunneling would already be in progress by the time the MN 374 handovers to NAR. The MN SHOULD send UNA immediately after 375 attaching to NAR, so that arriving as well as buffered packets can 376 be forwarded to the MN right away. 377 Before sending FBack to MN, PAR can determine whether NCoA is 378 acceptable to NAR through the exchange of HI and HAck messages. 379 When assigned addressing (i.e., addresses are assigned by the 380 router) is used, the proposed NCoA in FBU is carried in HI, and 381 NAR MAY assign the proposed NCoA. Such an assigned NCoA MUST be 382 returned in HAck, and PAR MUST in turn provide the assigned NCoA 383 in FBack. If there is an assigned NCoA returned in FBack, the MN 384 MUST use the assigned address (and not the proposed address in 385 FBU) upon attaching to NAR. 387 2. The MN does not receive FBack on the previous link. One 388 reason for this is that the MN has not sent the FBU. The other is 389 that the MN has left the link after sending the FBU, which may be 390 lost, but before receiving an FBack. Without receiving an FBack 391 in the latter case, the MN cannot ascertain whether PAR has 392 successfully processed the FBU. Hence, the MN (re)sends FBU 393 immediately after sending the UNA message. If NAR chooses to 394 supply a different IP address to use than the NCoA, it MAY sends a 395 Router Advertisement with "Neighbor Advertisement Acknowledge 396 (NAACK)" option in which it includes an alternate IP address for 397 the MN to use. Detailed UNA processing rules are specified in 398 Section 6.4. 400 The scenario in which a MN sends FBU and receives FBack on PAR's link 401 is illustrated in Figure 2. For convenience, this scenario is called 402 "predictive" mode of operation. The scenario in which the MN sends 403 FBU from NAR's link is illustrated in Figure 3. For convenience, 404 this scenario is called "reactive" mode of operation. Note that the 405 reactive mode also includes the case when FBU has been sent from 406 PAR's link but FBack has not been received yet. The Figure is 407 intended to illustrate that the FBU is forwarded through NAR, but it 408 is processed only by the PAR. 410 Finally, the PrRtAdv message may be sent unsolicited, i.e., without 411 the MN first sending RtSolPr. This mode is described in Section 3.3. 413 3.3. Protocol Operation during Network-initiated Handover 415 In some wireless technologies, the handover control may reside in the 416 network even though the decision to undergo handover may be arrived 417 at by cooperation between the MN and the network. In such networks, 418 the PAR can send an unsolicited PrRtAdv containing the link layer 419 address, IP address and subnet prefix of the NAR when the network 420 decides that a handover is imminent. The MN MUST process this 421 PrRtAdv to configure a new care of address on the new subnet, and 422 MUST send an FBU to PAR prior to switching to the new link. After 423 transmitting PrRtAdv, the PAR MUST continue to forward packets to the 424 MN on its current link until the FBU is received. The rest of the 425 operation is the same as that described in Section 3.2. 427 The unsolicited PrRtAdv also allows the network to inform the MN 428 about geographically adjacent subnets without the MN having to 429 explicitly request that information. This can reduce the amount of 430 wireless traffic required for the MN to obtain a neighborhood 431 topology map of links and subnets. Such usage of PrRtAdv is 432 decoupled from the actual handover. See Section 6.1.2. 434 MN PAR NAR 435 | | | 436 |------RtSolPr------->| | 437 |<-----PrRtAdv--------| | 438 | | | 439 |------FBU----------->|----------HI--------->| 440 | |<--------HAck---------| 441 | <--FBack---|--FBack---> | 442 | | | 443 disconnect forward | 444 | packets ===============>| 445 | | | 446 | | | 447 connect | | 448 | | | 449 |------------UNA --------------------------->| 450 |<=================================== deliver packets 451 | | 453 Figure 2: Predictive Fast Handover 455 MN PAR NAR 456 | | | 457 |------RtSolPr------->| | 458 |<-----PrRtAdv--------| | 459 | | | 460 disconnect | | 461 | | | 462 | | | 463 connect | | 464 |-------UNA-----------|--------------------->| 465 |-------FBU-----------|---------------------)| 466 | |<-------FBU----------)| 467 | |<------HI/HAck------->| 468 | | (if necessary) | 469 | forward | 470 | packets(including FBAck)=====>| 471 | | | 472 |<=================================== deliver packets 473 | | 475 Figure 3: Reactive Fast Handover 477 4. Protocol Details 479 All description makes use of Figure 1 as the reference. 481 After discovering one or more nearby access points, the MN sends 482 RtSolPr in order to resolve access point identifiers to subnet router 483 information. A convenient time to do this is after performing router 484 discovery. However, the MN can send RtSolPr at any time, e.g., when 485 one or more new access points are discovered. The MN can also send 486 RtSolPr more than once during its attachment to PAR. The trigger for 487 sending RtSolPr can originate from a link-specific event, such as the 488 promise of a better signal strength from another access point coupled 489 with fading signal quality with the current access point. Such 490 events, often broadly referred to as "L2 triggers", are outside the 491 scope of this document. Nevertheless, they serve as events that 492 invoke this protocol. For instance, when a "link up" indication is 493 obtained on the new link, protocol messages (e.g., UNA) can be 494 immediately transmitted. Implementations SHOULD make use of such 495 triggers whenever available. 497 The RtSolPr message contains one or more AP-IDs. A wildcard requests 498 all available tuples. 500 As a response to RtSolPr, PAR sends a PrRtAdv message which indicates 501 one of the following possible conditions. 503 1. If the PAR does not have an entry corresponding to the new 504 access point, it responds indicating that the new access point is 505 unknown. The MN MUST stop fast handover protocol operations on 506 the current link. The MN MAY send an FBU from its new link. 508 2. If the new access point is connected to the PAR's current 509 interface (to which MN is attached), PAR responds with a Code 510 value indicating that the new access point is connected to the 511 current interface, but not send any prefix information. This 512 scenario could arise, for example, when several wireless access 513 points are bridged into a wired network. No further protocol 514 action is necessary. 516 3. If the new access point is known and the PAR has information 517 about it, then PAR responds indicating that the new access point 518 is known and supply the [AP-ID, AR-Info] tuple. If the new access 519 point is known, but does not support fast handover, the PAR MUST 520 indicate this with Code 3 (see Section 6.1.2). 522 4. If a wildcard is supplied as an identifier for the new access 523 point, the PAR SHOULD supply neighborhood [AP-ID, AR-Info] tuples 524 subject to path MTU restrictions (i.e., provide any 'n' tuples 525 without exceeding the link MTU). 527 When further protocol action is necessary, some implementations may 528 choose to provide buffering support at PAR to address the scenario in 529 which a MN leaves without sending an FBU message from the PAR's link. 530 While the protocol does not forbid such an implementation support, 531 care must be taken to ensure that the PAR continues forwarding 532 packets to the PCoA (i.e., uses a buffer and forward approach). The 533 PAR should also stop buffering once it processes the FBU message. 535 The method by which Access Routers exchange information about their 536 neighbors and thereby allow construction of Proxy Router 537 Advertisements with information about neighboring subnets is outside 538 the scope of this document. 540 The RtSolPr and PrRtAdv messages MUST be implemented by a MN and an 541 access router that supports fast handovers. However, when the 542 parameters necessary for the MN to send packets immediately upon 543 attaching to the NAR are supplied by the link layer handover 544 mechanism itself, use of above messages is optional on such links. 546 After a PrRtAdv message is processed, the MN sends FBU and includes 547 the proposed NCoA. The MN SHOULD send FBU from PAR's link whenever 548 "anticipation" of handover is feasible. When anticipation is not 549 feasible or when it has not received an FBack, the MN sends FBU 550 immediately after attaching to NAR's link. In response to FBU, PAR 551 establishes a binding between PCoA ("Home Address") and NCoA, and 552 sends FBack to MN. Prior to establishing this binding, PAR SHOULD 553 send a HI message to NAR, and receive HAck in response. In order to 554 determine the NAR's address for the HI message, the PAR can perform 555 longest prefix match of NCoA (in FBU) with the prefix list of 556 neighboring access routers. When the source IP address of FBU is 557 PCoA, i.e., the FBU is sent from the PAR's link, the HI message MUST 558 have a Code value set to 0. See Section 6.2.1. When the source IP 559 address of FBU is not PCoA, i.e., the FBU is sent from the NAR's 560 link, the HI message MUST have a Code value of 1. See Section 6.2.1. 562 The HI message contains the PCoA, link-layer address and the NCoA of 563 the MN. In response to processing a HI message with Code 0, the NAR 565 1. determines whether NCoA supplied in the HI message is a valid 566 address for use, and if it is, starts proxying [rfc4861] the 567 address for PROXY_ND_LIFETIME during which the MN is expected to 568 connect to NAR. In case there is already an NCoA present, NAR may 569 verify if the LLA is the same as its own or that of the MN itself. 570 If so, NAR may allow the use of NCoA. 572 2. allocates NCoA for the MN when assigned addressing is used, 573 creates a proxy neighbor cache entry and begins defending it. The 574 NAR MAY allocate the NCoA proposed in HI. 576 3. MAY create a host route entry for PCoA (on the interface to 577 which the MN is attaching to) in case NCoA cannot be accepted or 578 assigned. This host route entry SHOULD be implemented such that 579 until the MN's presence is detected, either through explicit 580 announcement by the MN or by other means, arriving packets do not 581 invoke neighbor discovery. The NAR SHOULD also set up a reverse 582 tunnel to PAR in this case. 584 4. provides the status of handover request in Handover Acknowledge 585 (HAck) message. 587 When the Code value in HI is 1, NAR MUST skip the above operations. 588 However, it SHOULD be prepared to process any other options which may 589 be defined in the future. Sending a HI message with Code 1 allows 590 NAR to validate the neighbor cache entry it creates for the MN during 591 UNA processing. That is, NAR can make use of the knowledge that its 592 trusted peer (i.e., PAR) has a trust relationship with the MN. 594 If HAck contains an assigned NCoA, it must be included in FBack, and 595 the MN MUST use it. The PAR MAY send FBack to the previous link as 596 well to facilitate faster reception in the event the MN be still 597 present there. The result of FBU and FBack processing is that PAR 598 begins tunneling MN's packets to NCoA. If the MN does not receive an 599 FBack message even after re-transmitting FBU for FBU_RETRIES, it must 600 assume that fast handover support is not available and stop the 601 protocol operation. 603 As soon as the MN establishes link connectivity with the NAR, it 605 1. sends a UNA message (see Section 6.4). If the MN has not 606 received an FBack by the time UNA is being sent, it SHOULD send an 607 FBU message following the UNA message. 609 2. joins the all-nodes multicast group and the solicited-node 610 multicast group corresponding to the NCoA 612 3. starts a DAD probe for NCoA. See [rfc4862]. 614 When a NAR receives a UNA message, it 616 1. deletes its proxy neighbor cache entry, if it exists, updates 617 the state to STALE, and forwards arriving and buffered packets. 619 2. updates an entry in INCOMPLETE state, if it exists, to STALE 620 and forwards arriving and buffered packets. This would be the 621 case if NAR had previously sent a Neighbor Solicitation which went 622 unanswered perhaps because the MN had not yet attached to the 623 link. 625 The buffer for handover traffic should be linked to this UNA 626 processing. The exact mechanism is implementation dependent. 628 The NAR may choose to provide different IP address other than the 629 NCoA. This is possible if it is proxying the NCoA. In such a case, 630 it 632 1. MAY send a Router Advertisement with the NAACK option in which 633 it includes an alternate IP address for use. This message MUST be 634 sent to the source IP address present in UNA using the same Layer 635 2 address present in UNA. 637 If the MN receives an IP address in the NAACK option, it MUST use it 638 and send an FBU using the new CoA. As a special case, the address 639 supplied in NAACK could be PCoA itself, in which case the MN MUST NOT 640 send any more FBUs. The Status codes for NAACK option are specified 641 in Section 6.5.5. 643 Once the MN has confirmed its NCoA (either through DAD or when 644 provided for by the NAR), it SHOULD send a Neighbor Advertisement 645 message with the 'O' bit set, to the all-nodes multicast address. 646 This message allows MN's neighbors to update their neighbor cache 647 entries. 649 For data forwarding, the PAR tunnels packets using its global IP 650 address valid on the interface to which the MN was attached. The MN 651 reverse tunnels its packets to the same global address of PAR. The 652 tunnel end-point addresses must be configured accordingly. When PAR 653 receives a reverse tunneled packet, it must verify if a secure 654 binding exists for the MN identified by PCoA in the tunneled packet, 655 before forwarding the packet. 657 5. Other Considerations 659 5.1. Handover Capability Exchange 661 The MN expects a PrRtAdv in response to its RtSolPr message. If the 662 MN does not receive a PrRtAdv message even after RTSOLPR_RETRIES, it 663 must assume that PAR does not support the fast handover protocol and 664 stop sending any more RtSolPr messages. 666 Even if a MN's current access router is capable of providing fast 667 handover support, the new access router may not be capable of 668 providing such support. This is indicated to the MN during 669 "runtime", through the PrRtAdv message with a Code value of 3 (see 670 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. This NCoA 676 can be provided to NAR in the HI message. NAR provides a disposition 677 of HI, and hence the NCoA itself, in the HAck message indicating 678 whether NCoA is acceptable. However, the MN itself does not have to 679 wait on PAR's link for this exchange to take place. It can handover 680 any time after sending the FBU message; sometimes it may be forced to 681 handover without sending the FBU. In any case, it can still confirm 682 using NCoA from NAR's link by sending the UNA message. 684 If PrRtAdv message carries a NCoA, the MN MUST use it as its 685 prospective NCoA. 687 When DHCP is used, the protocol supports forwarding for PCoA only. 688 In this case, the MN MUST perform DHCP operations once it attaches to 689 the NAR even though it formulates an NCoA for transmitting the FBU. 690 This is indicated in the PrRtAdv message with Code = 5. 692 5.3. Prefix Management 694 As defined in Section 2, the Prefix part of ``AR-Info'' is the prefix 695 valid on the interface to which the AP is attached. This document 696 does not specify how this Prefix is managed, it's length and 697 assignment policies. The protocol operation specified in this 698 document works regardless of these considerations. Often, but not 699 necessarily always, this Prefix may be the aggregate prefix (such as 700 /48) valid on the interface. In some deployments, each MN may have 701 its own per-mobile prefix (such as a /64) used for generating the 702 NCoA. Some point-to-point links may use such a deployment. 704 When per-mobile prefix assignment is used, the ``AR-Info'' advertised 705 in PrRtAdv still includes the (aggregate) prefix valid on the 706 interface to which the target AP is attached, unless the access 707 routers communicate with each other (using HI and HAck messages) to 708 manage per-mobile prefix. The MN still formulates an NCoA using the 709 aggregate prefix. However, an alternate NCoA based on the per-mobile 710 prefix is returned by NAR in the HAck message. This alternate NCoA 711 is provided to the MN in either the FBack message or in the NAACK 712 option. 714 5.4. Packet Loss 716 Handover involves link switching, which may not be exactly co- 717 ordinated with fast handover signaling. Furthermore, the arrival 718 pattern of packets is dependent on many factors, including 719 application characteristics, network queuing behaviors etc. Hence, 720 packets may arrive at NAR before the MN is able to establish its link 721 there. These packets will be lost unless they are buffered by the 722 NAR. Similarly, if the MN attaches to NAR and then sends an FBU 723 message, packets arriving at PAR until FBU is processed will be lost 724 unless they are buffered. This protocol provides an option to 725 indicate request for buffering at the NAR in the HI message. When 726 the PAR requests this feature (for the MN), it SHOULD also provide 727 its own support for buffering. 729 5.5. DAD Handling 731 Duplicate Address Detection (DAD) was defined in [rfc4862] to avoid 732 address duplication on links when stateless address auto- 733 configuration is used. The use of DAD to verify the uniqueness of an 734 IPv6 address configured through stateless auto-configuration adds 735 delays to a handover. The probability of an interface identifier 736 duplication on the same subnet is very low, however it cannot be 737 ignored. So, this protocol SHOULD only be used in deployments where 738 the probability of such address collisions is extremely low. 740 This document specifies messages which can be used to provide 741 duplicate-free addresses but the document does not specify how to 742 create or manage such duplicate-free addresses. In some cases the 743 NAR may already have the knowledge required to assess whether the 744 MN's address is a duplicate or not before the MN moves to the new 745 subnet. For example, in some deployments, the NAR may maintain a 746 pool of duplicate-free addresses in a list for handover purposes. In 747 such cases, the NAR can provide this disposition in the HAck message 748 (see Section 6.2.2) or in the NAACK option (see Section 6.5.5). 750 In deployments where an access router does not provide duplicate-free 751 addresses, this protocol SHOULD only be used where the probability of 752 address collision is extremely low. The recovery operations that 753 take place when the highly improbable random collisions occur are 754 described in Appendix B. 756 5.6. Fast or Erroneous Movement 758 Although this specification is for fast handover, the protocol has 759 its limits in terms of how fast a MN can move. A special case of 760 fast movement is ping-pong, where a MN moves between the same two 761 access points rapidly. Another instance of the same problem is 762 erroneous movement i.e., the MN receives information prior to a 763 handover that it is moving to a new access point but it either moves 764 to a different one or aborts movement altogether. All of the above 765 behaviors are usually the result of link layer idiosyncrasies and 766 thus are often tackled at the link layer itself. 768 IP layer mobility, however, introduces its own limits. IP layer 769 handovers should occur at a rate suitable for the MN to update the 770 binding of, at least, its Home Agent and preferably that of every CN 771 with which it is in communication. A MN that moves faster than 772 necessary for this signaling to complete, which may be of the order 773 of few seconds, may start losing packets. The signaling overhead 774 over the air and in the network may increase significantly, 775 especially in the case of rapid movement between several access 776 routers. To avoid the signaling overhead, the following measures are 777 suggested. 779 A MN returning to the PAR before updating the necessary bindings when 780 present on NAR MUST send a Fast Binding Update with Home Address 781 equal to the MN's PCoA and a lifetime of zero, to the PAR. The MN 782 should have a security association with the PAR since it performed a 783 fast handover to the NAR. The PAR, on receiving this Fast Binding 784 Update, will check its set of outgoing (temporary fast handover) 785 tunnels. If it finds a match it SHOULD terminate that tunnel; i.e., 786 start delivering packets directly to the node instead. In order for 787 PAR to process such an FBU, the lifetime of the security association 788 has to be at least that of the tunnel itself. 790 Temporary tunnels for the purposes of fast handovers should use short 791 lifetimes (of the order of a small number of seconds or less). The 792 lifetime of such tunnels should be enough to allow a MN to update all 793 its active bindings. The default lifetime of the tunnel should be 794 the same as the lifetime value in the FBU message. 796 The effect of erroneous movement is typically limited to loss of 797 packets since routing can change and the PAR may forward packets 798 towards another router before the MN actually connects to that 799 router. If the MN discovers itself on an unanticipated access 800 router, it SHOULD send a new Fast Binding Update to the PAR. This 801 FBU supersedes the existing binding at PAR and the packets will be 802 redirected to the new confirmed location of the MN. 804 6. Message Formats 806 All the ICMPv6 messages have a common Type specified in [rfc2463]. 807 The messages are distinguished based on the Subtype field (see 808 below). For all the ICMPv6 messages, the checksum is defined in 809 [rfc2463]. 811 6.1. New Neighborhood Discovery Messages 813 6.1.1. Router Solicitation for Proxy Advertisement (RtSolPr) 815 Mobile Nodes send Router Solicitation for Proxy Advertisement in 816 order to prompt routers for Proxy Router Advertisements. All the 817 link-layer address options have the format defined in Section 6.5.2. 819 0 1 2 3 820 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 821 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 822 | Type | Code | Checksum | 823 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 824 | Subtype | Reserved | Identifier | 825 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 826 | Options ... 827 +-+-+-+-+-+-+-+-+-+-+-+- 828 Figure 4: Router Solicitation for Proxy Advertisement (RtSolPr) 829 Message 831 IP Fields: 833 Source Address: An IP address assigned to the sending interface 835 Destination Address: The address of the Access Router or the 836 all routers multicast address. 838 Hop Limit: 255. See RFC 2461. 840 ICMP Fields: 842 Type: To be assigned by IANA 844 Code: 0 846 Checksum: The ICMPv6 checksum. 848 Subtype: 2 850 Reserved: MUST be set to zero by the sender and ignored by the 851 receiver. 853 Identifier: MUST be set by the sender so that replies can be 854 matched to this Solicitation. 856 Valid Options: 858 Source Link-layer Address: When known, the link-layer address 859 of the sender SHOULD be included using the Link-Layer Address 860 option. See LLA option format below. 862 New Access Point Link-layer Address: The link-layer address or 863 identification of the access point for which the MN requests 864 routing advertisement information. It MUST be included in all 865 RtSolPr messages. More than one such address or identifier can 866 be present. This field can also be a wildcard address. See 867 LLA Option below. 869 Future versions of this protocol may define new option types. 870 Receivers MUST silently ignore any options that they do not recognize 871 and continue processing the rest of the message. 873 Including the source LLA option allows the receiver to record the 874 sender's L2 address so that neighbor discovery, when the receiver 875 needs to send packets back to the sender (of RtSolPr message), can be 876 avoided. 878 When a wildcard is used for New Access Point LLA, no other New Access 879 Point LLA options must be present. 881 A Proxy Router Advertisement (PrRtAdv) message should be received by 882 the MN as a response to RtSolPr. If such a message is not received 883 in a short time period but no less than twice the typical round trip 884 time (RTT) over the access link or 100 milliseconds if RTT is not 885 known, it SHOULD resend RtSolPr message. Subsequent retransmissions 886 can be up to RTSOLPR_RETRIES, but MUST use an exponential backoff in 887 which the timeout period (i.e., 2xRTT or 100 milliseconds) is doubled 888 prior to each instance of retransmission. If Proxy Router 889 Advertisement is not received by the time the MN disconnects from the 890 PAR, the MN SHOULD send FBU immediately after configuring a new CoA. 892 When RtSolPr messages are sent more than once, they MUST be rate 893 limited with MAX|RTSOLPR|RATE per second. During each use of 894 RtSolPr, exponential backoff is used for retransmissions. 896 6.1.2. Proxy Router Advertisement (PrRtAdv) 898 Access routers send out Proxy Router Advertisement message 899 gratuitously if the handover is network-initiated or as a response to 900 RtSolPr message from a MN, providing the link-layer address, IP 901 address and subnet prefixes of neighboring routers. All the link- 902 layer address options have the format defined in 6.4.3. 904 0 1 2 3 905 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 906 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 907 | Type | Code | Checksum | 908 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 909 | Subtype | Reserved | Identifier | 910 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 911 | Options ... 912 +-+-+-+-+-+-+-+-+-+-+-+- 914 Figure 5: Proxy Router Advertisement (PrRtAdv) Message 916 IP Fields: 918 Source Address: MUST be the link-local address assigned to the 919 interface from which this message is sent. 921 Destination Address: The Source Address of an invoking Router 922 Solicitation for Proxy Advertisement or the address of the node 923 the Access Router is instructing to handover. 925 Hop Limit: 255. See RFC 2461. 927 ICMP Fields: 929 Type: To be assigned by IANA 931 Code: 0, 1, 2, 3, 4 or 5. See below. 933 Checksum: The ICMPv6 checksum. 935 Subtype: 3 937 Reserved: MUST be set to zero by the sender and ignored by the 938 receiver. 940 Identifier: Copied from Router Solicitation for Proxy 941 Advertisement or set to Zero if unsolicited. 943 Valid Options in the following order: 945 Source Link-layer Address: When known, the link-layer address 946 of the sender SHOULD be included using the Link-Layer Address 947 option. See LLA option format below. 949 New Access Point Link-layer Address: The link-layer address or 950 identification of the access point is copied from RtSolPr 951 message. This option MUST be present. 953 New Router's Link-layer Address: The link-layer address of the 954 Access Router for which this message is proxied for. This 955 option MUST be included when Code is 0 or 1. 957 New Router's IP Address: The IP address of NAR. This option 958 MUST be included when Code is 0 or 1. 960 New Router Prefix Information Option: Specifies the prefix of 961 the Access Router the message is proxied for and is used for 962 address auto-configuration. This option MUST be included when 963 Code is 0 or 1. However, when this prefix is the same as what 964 is used in the New Router's IP Address option (above), the 965 Prefix Information option need not be present. 967 New CoA Option: MAY be present when PrRtAdv is sent 968 unsolicited. PAR MAY compute new CoA using NAR's prefix 969 information and the MN's L2 address, or by any other means. 971 Future versions of this protocol may define new option types. 972 Receivers MUST silently ignore any options they do not recognize and 973 continue processing the message. 975 Currently, Code values 0, 1, 2, 3, 4 and 5 are defined. 977 A Proxy Router Advertisement with Code 0 means that the MN should use 978 the [AP-ID, AR-Info] tuple (present in the options above) for 979 movement detection and NCoA formulation. The Option-Code field in 980 the New Access Point LLA option in this case is 1 reflecting the LLA 981 of the access point for which the rest of the options are related. 982 Multiple tuples may be present. 984 A Proxy Router Advertisement with Code 1 means that the message is 985 sent unsolicited. If a New CoA option is present following the New 986 Router Prefix Information option, the MN SHOULD use the supplied NCoA 987 and send FBU immediately or else stand to lose service. This message 988 acts as a network-initiated handover trigger. See Section 3.3. The 989 Option-Code field in the New Access Point LLA option (see below) in 990 this case is 1 reflecting the LLA of the access point for which the 991 rest of the options are related. 993 A Proxy Router Advertisement with Code 2 means that no new router 994 information is present. Each New Access Point LLA option contains an 995 Option-Code value (described below) which indicates a specific 996 outcome. 998 When the Option-Code field in the New Access Point LLA option is 999 5, handover to that access point does not require change of CoA. 1000 No other options are required in this case. 1002 When the Option-Code field in the New Access Point LLA option is 1003 6, PAR is not aware of the Prefix Information requested. The MN 1004 SHOULD attempt to send FBU as soon as it regains connectivity with 1005 the NAR. No other options are required in this case. 1007 When the Option-Code field in the New Access Point LLA option is 1008 7, it means that the NAR does not support fast handover. The MN 1009 MUST stop fast handover protocol operations. No other options are 1010 required in this case. 1012 A Proxy Router Advertisement with Code 3 means that new router 1013 information is present only for a subset of access points requested. 1014 The Option-Code field values (defined above including a value of 1) 1015 distinguish different outcomes for individual access points. 1017 A Proxy Router Advertisement with Code 4 means that the subnet 1018 information regarding neighboring access points is sent unsolicited, 1019 but the message is not a handover trigger, unlike when the message is 1020 sent with Code 1. Multiple tuples may be present. 1022 A Proxy Router Advertisement with Code 5 means that the MN may use 1023 the new router information present for detecting movement to a new 1024 subnet, but the MN must perform DHCP [rfc3315] upon attaching to the 1025 NAR's link. The PAR and NAR will forward packets to the PCoA of the 1026 MN. The MN must still formulate an NCoA for transmitting FBU (using 1027 the information sent in this message), but that NCoA will not be used 1028 for forwarding packets. 1030 When a wildcard AP identifier is supplied in the RtSolPr message, the 1031 PrRtAdv message should include any 'n' [Access Point Identifier, 1032 Link-layer address option, Prefix Information Option] tuples 1033 corresponding to the PAR's neighborhood. 1035 6.2. Inter-Access Router Messages 1037 6.2.1. Handover Initiate (HI) 1039 The Handover Initiate (HI) is an ICMPv6 message sent by an Access 1040 Router (typically PAR) to another Access Router (typically NAR) to 1041 initiate the process of a MN's handover. 1043 0 1 2 3 1044 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 1045 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1046 | Type | Code | Checksum | 1047 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1048 | Subtype |S|U| Reserved | Identifier | 1049 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1050 | Options ... 1051 +-+-+-+-+-+-+-+-+-+-+-+- 1052 Figure 6: Handover Initiate (HI) Message 1054 IP Fields: 1056 Source Address: The IP address of the PAR 1058 Destination Address: The IP address of the NAR 1060 ICMP Fields: 1062 Type: To be assigned by IANA 1064 Code: 0 or 1. See below 1066 Checksum: The ICMPv6 checksum. 1068 Subtype: 4 1070 'S' flag: Assigned address configuration flag. When set, this 1071 message requests a new CoA to be returned by the destination. 1072 May be set when Code = 0. MUST be 0 when Code = 1. 1074 'U' flag: Buffer flag. When set, the destination SHOULD buffer 1075 any packets towards the node indicated in the options of this 1076 message. Used when Code = 0, SHOULD be set to 0 when Code = 1. 1078 Reserved: MUST be set to zero by the sender and ignored by the 1079 receiver. 1081 Identifier: MUST be set by the sender so replies can be matched 1082 to this message. 1084 Valid Options: 1086 Link-layer address of MN: The link-layer address of the MN that is 1087 undergoing handover to the destination (i.e., NAR). This option 1088 MUST be included so that the destination can recognize the MN. 1090 Previous Care of Address: The IP address used by the MN while 1091 attached to the originating router. This option SHOULD be 1092 included so that host route can be established in case necessary. 1094 New Care of Address: The IP address the MN wishes to use when 1095 connected to the destination. When the `S' bit is set, NAR MAY 1096 assign this address. 1098 The PAR uses a Code value of 0 when it processes an FBU with PCoA as 1099 source IP address. The PAR uses a Code value of 1 when it processes 1100 an FBU whose source IP address is not PCoA. 1102 If Handover Acknowledge (HAck) message is not received as a response 1103 in a short time period but no less than twice the typical round trip 1104 time (RTT) between source and destination, or 100 milliseconds if RTT 1105 is not known, the Handover Initiate SHOULD be re-sent. Subsequent 1106 retransmissions can be up to HI_RETRIES, but MUST use exponential 1107 backoff in which the timeout period (i.e., 2xRTT or 100 milliseconds) 1108 is doubled during each instance of retransmission. 1110 6.2.2. Handover Acknowledge (HAck) 1112 The Handover Acknowledgment message is a new ICMPv6 message that MUST 1113 be sent (typically by NAR to PAR) as a reply to the Handover Initiate 1114 message. 1116 0 1 2 3 1117 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 1118 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1119 | Type | Code | Checksum | 1120 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1121 | Subtype | Reserved | Identifier | 1122 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1123 | Options ... 1124 +-+-+-+-+-+-+-+-+-+-+-+- 1126 Figure 7: Handover Acknowledge (HAck) Message 1128 IP Fields: 1130 Source Address: Copied from the destination address of the 1131 Handover Initiate Message to which this message is a response. 1133 Destination Address: Copied from the source address of the 1134 Handover Initiate Message to which this message is a response. 1136 ICMP Fields: 1138 Type: To be assigned by IANA 1139 Code: 1141 0: Handover Accepted, NCoA valid 1142 1: Handover Accepted, NCoA not valid or in use 1143 2: Handover Accepted, NCoA assigned (used in Assigned 1144 addressing) 1145 3: Handover Accepted, use PCoA 1146 4: Message sent unsolicited, usually to trigger a HI message 1147 128: Handover Not Accepted, reason unspecified 1148 129: Administratively prohibited 1149 130: Insufficient resources 1151 Checksum: The ICMPv6 checksum. 1153 Subtype: 5 1155 Reserved: MUST be set to zero by the sender and ignored by the 1156 receiver. 1158 Identifier: Copied from the corresponding field in the Handover 1159 Initiate message this message is in response to. 1161 Valid Options: 1163 New Care of Address: If the S flag in the Handover Initiate message 1164 is set, this option MUST be used to provide NCoA the MN should use 1165 when connected to this router. This option MAY be included even when 1166 `S' bit is not set, e.g., Code 2 above. 1168 Upon receiving a HI message, the NAR MUST respond with a Handover 1169 Acknowledge message. If the `S' flag is set in the HI message, the 1170 NAR SHOULD include the New Care of Address option and a Code 3. 1172 The NAR MAY provide support for PCoA (instead of accepting or 1173 assigning NCoA), using a host route entry to forward packets to the 1174 PCoA, and using a tunnel to the PAR to forward packets from the MN 1175 (sent with PCoA as source IP address). This host route entry SHOULD 1176 be used to forward packets once the NAR detects that the particular 1177 MN is attached to its link. The NAR indicates forwarding support for 1178 PCoA using Code value 3 in the HAck message. Subsequently, PAR 1179 establishes a tunnel to NAR in order to forward packets arriving for 1180 PCoA. 1182 When responding to a HI message containing a Code value 1, the Code 1183 values 1, 2, and 4 in the HAck message are not relevant. 1185 Finally, the new access router can always refuse handover, in which 1186 case it should indicate the reason in one of the available Code 1187 values. 1189 6.3. New Mobility Header Messages 1191 Mobile IPv6 uses a new IPv6 header type called Mobility Header 1192 [rfc3775]. The Fast Binding Update, Fast Binding Acknowledgment and 1193 Fast Neighbor Advertisement messages use the Mobility Header. 1195 6.3.1. Fast Binding Update (FBU) 1197 The Fast Binding Update message is identical to the Mobile IPv6 1198 Binding Update (BU) message. However, the processing rules are 1199 slightly different. 1201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1202 | Sequence # | 1203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1204 |A|H|L|K| Reserved | Lifetime | 1205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1206 | | 1207 . . 1208 . Mobility options . 1209 . . 1210 | | 1211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1213 Figure 8: Fast Binding Update (FBU) Message 1215 IP Fields: 1217 Source address: The PCoA or NCoA 1219 Destination Address: The IP address of the Previous Access 1220 Router 1222 `A' flag: MUST be set to one to request PAR to send a Fast Binding 1223 Acknowledgment message. 1225 `H' flag: MUST be set to one. See [rfc3775]. 1227 `L' flag: See [rfc3775]. 1229 `K' flag: See [rfc3775]. 1231 Reserved: This field is unused. MUST be set zero. 1233 Sequence Number: See See [rfc3775]. 1235 Lifetime: The requested time in seconds for which the sender 1236 wishes to have a binding. 1238 Mobility Options: MUST contain alternate CoA option set to NCoA IP 1239 address when FBU is sent from PAR's link. MUST contain the 1240 Binding Authorization Data for FMIP (BADF) option. See 1241 Section 6.5.4. MAY contain the Mobility Header LLA option (see 1242 Section 6.5.3). 1244 The MN sends FBU message any time after receiving a PrRtAdv message. 1245 If the MN moves prior to receiving a PrRtAdv message, it SHOULD send 1246 a FBU to the PAR after configuring NCoA on the NAR according to 1247 Neighbor Discovery and IPv6 Address Configuration protocols. When 1248 the MN moves without having received a PrRtAdv message, it cannot 1249 transmit a UNA message upon attaching to the NAR's link. 1251 The source IP address is PCoA when FBU is sent from PAR's link, and 1252 the source IP address is NCoA when sent from NAR's link. 1254 The FBU MUST also include the Home Address Option set to PCoA when 1255 the source IP address is not PCoA. A FBU message MUST be protected 1256 so that PAR is able to determine that the FBU message is sent by a MN 1257 that legitimately owns the PCoA. 1259 6.3.2. Fast Binding Acknowledgment (FBack) 1261 The Fast Binding Acknowledgment message is sent by the PAR to 1262 acknowledge receipt of a Fast Binding Update message in which the `A' 1263 bit is set. If PAR sends a HI message to the NAR after processing an 1264 FBU, the FBack message SHOULD NOT be sent to the MN before the PAR 1265 receives a HAck message from the NAR. The PAR MAY send the FBack 1266 immediately in the reactive mode however. The Fast Binding 1267 Acknowledgment MAY also be sent to the MN on the old link. 1269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1270 | Status |K| Reserved | 1271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1272 | Sequence # | Lifetime | 1273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1274 | | 1275 . . 1276 . Mobility options . 1277 . . 1278 | | 1279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1281 Figure 9: Fast Binding Acknowledgment (FBack) Message 1283 IP Fields: 1285 Source address: The IP address of the Previous Access Router 1287 Destination Address: The NCoA, and optionally PCoA 1289 Status: 8-bit unsigned integer indicating the disposition of the 1290 Fast Binding Update. Values of the Status field less than 128 1291 indicate that the Binding Update was accepted by the receiving 1292 node. The following such Status values are currently defined: 1294 0 Fast Binding Update accepted 1295 1 Fast Binding Update accepted but NCoA is invalid. Use NCoA 1296 supplied in ``alternate'' CoA 1298 Values of the Status field greater than or equal to 128 indicate 1299 that the Binding Update was rejected by the receiving node. The 1300 following such Status values are currently defined: 1302 128: Reason unspecified 1303 129: Administratively prohibited 1304 130: Insufficient resources 1305 131: Incorrect interface identifier length 1307 `K' flag: See See [rfc3775]. 1309 Reserved: An unused field. MUST be set to zero. 1311 Sequence Number: Copied from FBU message for use by the MN in 1312 matching this acknowledgment with an outstanding FBU. 1314 Lifetime: The granted lifetime in seconds for which the sender of 1315 this message will retain a binding for traffic redirection. 1317 Mobility Options: MUST contain ``alternate'' CoA if Status is 1. 1318 MUST contain the Binding Authorization Data for FMIP (BADF) 1319 option. See 6.4.5. 1321 6.4. Unsolicited Neighbor Advertisement (UNA) 1323 This is the same message as in [rfc4861] with the requirement that 1324 the 'O' bit is always set to zero. Since this is an unsolicited 1325 message, the 'S' bit is zero, and since this is sent by a MN, the 'R' 1326 bit is also zero. 1328 If NAR is proxying the NCoA (as a result of HI and HAck exchange), 1329 then UNA processing has additional steps (see below). If NAR is not 1330 proxying the NCoA (for instance, HI and HAck exchange has not taken 1331 place), then UNA processing follows the same procedure as specified 1332 in [rfc4861]. Implementations MAY retransmit UNA subject to the 1333 specification in [rfc4861] (Section 7.2.6) while noting that the 1334 default RetransTimer value is large for handover purposes. 1336 The Source Address in UNA MUST be the NCoA. The Destination Address 1337 is typically the all-nodes multicast address; however, some 1338 deployments may not prefer transmission to a multicast address. In 1339 such cases, the Destination Address SHOULD be the NAR's IP address. 1341 The Target Address MUST include the NCoA, and Target link-layer 1342 address MUST include the MN's LLA. 1344 The MN sends a UNA message to the NAR, as soon as it regains 1345 connectivity on the new link. Arriving or buffered packets can be 1346 immediately forwarded. If NAR is proxying NCoA, it creates a 1347 neighbor cache entry in STALE state but forwards packets as it 1348 determines bidirectional reachability according to the standard 1349 Neighbor Discovery procedure. If there is an entry in INCOMPLETE 1350 state without a link-layer address, it sets it to STALE, again 1351 according to the procedure in [rfc4861]. 1353 The NAR MAY wish to provide a different IP address to the MN than the 1354 one in UNA message. In such a case, NAR MUST delete the proxy entry 1355 for NCoA and send a Router Advertisement with NAACK option containing 1356 the new IP address. 1358 The combination of NCoA (present in source IP address) and the Link- 1359 Layer Address (present as a Target LLA) SHOULD be used to distinguish 1360 the MN from other nodes. 1362 6.5. New Options 1364 All the options are of the form shown in Figure 10. 1366 The Type values are defined from the Neighbor Discovery options 1367 space. The Length field is in units of 8 octets, except for the 1368 Mobility Header Link-Layer Address option, whose Length field is in 1369 units of octets in accordance with Section 6.2 in [rfc3775]. And, 1370 Option-Code provides additional information for each of the options 1371 (see individual options below). 1373 0 1 2 3 1374 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 1375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1376 | Type | Length | Option-Code | | 1377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1378 ~ ... ~ 1379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1381 Figure 10: Option Format 1383 6.5.1. IP Address/Prefix Option 1385 This option is sent in the Proxy Router Advertisement, the Handover 1386 Initiate, and Handover Acknowledge messages. 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 | Prefix Length | 1392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1393 | Reserved | 1394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1395 | | 1396 + + 1397 | | 1398 + IPv6 Address + 1399 | | 1400 + + 1401 | | 1402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1403 Figure 11: IPv6 Address/Prefix Option 1405 Type: 17 1407 Length: The size of this option in 8 octets including the Type, 1408 Option-Code and Length fields. 1410 Option-Code: 1412 1: Old Care-of Address 1413 2: New Care-of Address 1414 3: NAR's IP address 1415 4: NAR's Prefix, sent in PrRtAdv. The Prefix Length field 1416 contains the number of valid leading bits in the prefix. The 1417 bits in the prefix after the prefix length are reserved and 1418 MUST be initialized to zero by the sender and ignored by the 1419 receiver. 1421 Prefix Length: 8-bit unsigned integer that indicates the length of 1422 the IPv6 Address Prefix. The value ranges from 0 to 128. 1424 Reserved: MUST be set to zero by the sender and MUST be ignored by 1425 the receiver. 1427 IPv6 address: The IP address defined by the Option-Code field. 1429 6.5.2. Link-layer Address (LLA) Option 1431 0 1 2 3 1432 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 1433 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1434 | Type | Length | Option-Code | LLA... 1435 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1437 Figure 12: Link-Layer Address Option 1439 Type: 19 1441 Length: The size of this option in 8 octets including the Type, 1442 Option-Code and Length fields. 1444 Option-Code: 1446 0: wildcard requesting resolution for all nearby access points 1447 1: Link-layer Address of the New Access Point 1448 2: Link-layer Address of the MN 1449 3: Link-layer Address of the NAR (i.e., Proxied Originator) 1450 4: Link-layer Address of the source of RtSolPr or PrRtAdv 1451 message 1452 5: The access point identified by the LLA belongs to the 1453 current interface of the router 1454 6: No prefix information available for the access point 1455 identified by the LLA 1456 7: No fast handovers support available for the access point 1457 identified by the LLA 1459 LLA: The variable length link-layer address. 1461 The LLA Option does not have a length field for the LLA itself. The 1462 implementations must consult the specific link layer over which the 1463 protocol is run in order to determine the content and length of the 1464 LLA. 1466 Depending on the size of individual LLA option, appropriate padding 1467 MUST be used to ensure that the entire option size is a multiple of 8 1468 octets. 1470 The New Access Point Link Layer address contains the link-layer 1471 address of the access point for which handover is about to be 1472 attempted. This is used in the Router Solicitation for Proxy 1473 Advertisement message. 1475 The MN Link-Layer address option contains the link-layer address of a 1476 MN. It is used in the Handover Initiate message. 1478 The NAR (i.e., Proxied Originator) Link-Layer address option contains 1479 the Link Layer address of the Access Router for which the Proxy 1480 Router Solicitation message refers to. 1482 6.5.3. Mobility Header Link-layer Address (MH-LLA) Option 1484 This option is identical to the LLA option, but is carried in the 1485 Mobility Header messages, e.g., FBU. In the future, other Mobility 1486 Header messages may also make use of this option. The format of the 1487 option is shown in Figure 13. There are no alignment requirements 1488 for this option. 1490 0 1 2 3 1491 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 1492 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1493 | Type | Length | 1494 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1495 | Option-Code | LLA .... 1496 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1498 Figure 13: Mobility Header Link-Layer Address Option 1500 Type: 7 1502 Length: The size of this option in octets not including the Type 1503 and Length fields. 1505 Option-Code: 2 Link-layer Address of the MN 1507 LLA: The variable length link-layer address. 1509 6.5.4. Binding Authorization Data for FMIPv6 (BADF) 1511 This option MUST be present in FBU and FBack messages. The security 1512 association between the MN and the PAR is established by companion 1513 protocols [rfc-ho-send]. This option specifies how to compute and 1514 verify a MAC using the established security association. 1516 The format of this option is shown in Figure 14. 1518 0 1 2 3 1519 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 1520 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1521 | Type | Option Length | 1522 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1523 | SPI | 1524 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1525 | | 1526 + + 1527 | Authenticator | 1528 + + 1529 | | 1530 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1532 Figure 14: Binding Authorization Data for FMIPv6 (BADF) Option 1533 Type: To be assigned by IANA 1535 Option Length: The length of the Authenticator in bytes 1537 SPI: Security Parameter Index. SPI = 0 is reserved for the 1538 Authenticator computed using SEND-based handover keys. 1540 Authenticator: Same as in RFC 3775, with "correspondent" replaced 1541 by PAR's IP address, and Kbm replaced by the shared key between 1542 the MN and the PAR. 1544 The default MAC calculation is done using HMAC_SHA1 with the first 96 1545 bits used for the MAC. Since there is an Option Length field, 1546 implementations can use other algorithms such as HMAC_SHA256 for 1547 instance. 1549 This option MUST be the last Mobility Option present. 1551 6.5.5. Neighbor Advertisement Acknowledgment (NAACK) 1553 0 1 2 3 1554 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 1555 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1556 | Type | Length | Option-Code | Status | 1557 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1558 | Reserved | 1559 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1561 Figure 15: Neighbor Advertisement Acknowledgment Option 1563 Type: 20 1565 Length: 8-bit unsigned integer. Length of the option, in 8 1566 octets. The length is 1 when a new CoA is not supplied. The 1567 length is 3 when a new CoA is present (immediately following the 1568 Reserved field) 1570 Option-Code: 0 1572 Status: 8-bit unsigned integer indicating the disposition of the 1573 Unsolicited Neighbor Advertisement message. The following Status 1574 values are currently defined: 1576 1: NCoA is invalid, perform address configuration 1577 2: NCoA is invalid, use the supplied NCoA. The supplied NCoA 1578 (in the form of an IP Address Option) MUST be present following 1579 the Reserved field. 1580 3: NCoA is invalid, use NAR's IP address as NCoA in FBU 1581 4: PCoA supplied, do not send FBU 1582 128: Link Layer Address unrecognized 1584 Reserved: MUST be set to zero by the sender and MUST be ignored by 1585 the receiver. 1587 The NAR responds to UNA with the NAACK option to notify the MN to use 1588 a different NCoA than the one that the MN has used. If the NAR 1589 proposes a different NCoA, the Router Advertisement MUST use the 1590 source IP address in the UNA message as the destination address, and 1591 use the L2 address present in UNA. The MN MUST use the NCoA if it is 1592 supplied with the NAACK option. If the NAACK indicates that the Link 1593 Layer Address is unrecognized, the MN MUST NOT use the NCoA or the 1594 PCoA and SHOULD start immediately the process of acquiring different 1595 NCoA at the NAR. 1597 In the future, new option types may be defined. 1599 7. Related Protocol and Device Considerations 1601 The protocol specified here, as a design principle, introduces no or 1602 minimal changes to related protocols. For example, no changes to the 1603 base Mobile IPv6 protocol are needed in order to implement this 1604 protocol. Similarly, no changes to the IPv6 stateless address 1605 autoconfiguration protocol [rfc4862] and DHCP [rfc3315] are 1606 introduced. The protocol specifies an optional extension to Neighbor 1607 Discovery [rfc4861] in which an access router may send a router 1608 advertisement as a response to the UNA message (see Section 1609 Section 6.4). 1611 The protocol does not require changes to any intermediate layer 2 1612 device between a MN and its access router which support this 1613 specification. This includes the wireless access points, switches, 1614 snooping devices and so on. 1616 8. Configurable Parameters 1618 +-------------------+---------------+---------------+ 1619 | Parameter Name | Default Value | Definition | 1620 +-------------------+---------------+---------------+ 1621 | RTSOLPR_RETRIES | 3 | Section 6.1.1 | 1622 | MAX_RTSOLPR_RATE | 3 | Section 6.1.1 | 1623 | FBU_RETRIES | 3 | Section 6.3.1 | 1624 | PROXY_ND_LIFETIME | 1.5 seconds | Section 6.2.2 | 1625 | HI_RETRIES | 3 | Section 6.2.1 | 1626 +-------------------+---------------+---------------+ 1628 9. Security Considerations 1630 The following security vulnerabilities are identified, and suggested 1631 solutions mentioned. 1633 Insecure FBU: in this case, packets meant for one address could be 1634 stolen, or redirected to some unsuspecting node. This concern is 1635 the same as that in a MN and Home Agent relationship. 1636 Hence, the PAR MUST ensure that the FBU packet arrived from a node 1637 that legitimately owns the PCoA. The access router and its hosts 1638 may use any available mechanism to establish a security 1639 association which MUST be used to secure FBU. The current version 1640 of this protocol relies on a companion protocol [rfc-ho-send]. to 1641 establish such a security association. Using the shared handover 1642 key from [rfc-ho-send], the Authenticator in BADF option (see 1643 Section 6.5.4) MUST be computed, and the BADF option included in 1644 FBU and FBack messages. 1646 Secure FBU, malicious or inadvertent redirection: in this case, 1647 the FBU is secured, but the target of binding happens to be an 1648 unsuspecting node either due to inadvertent operation or due to 1649 malicious intent. This vulnerability can lead to a MN with 1650 genuine security association with its access router redirecting 1651 traffic to an incorrect address. 1652 However, the target of malicious traffic redirection is limited to 1653 an interface on an access router with which the PAR has a security 1654 association. The PAR MUST verify that the NCoA to which PCoA is 1655 being bound actually belongs to NAR's prefix. In order to do 1656 this, HI and HAck message exchanges are to be used. When NAR 1657 accepts NCoA in HI (with Code = 0), it proxies NCoA so that any 1658 arriving packets are not sent on the link until the MN attaches 1659 and announces itself through UNA. So, any inadvertent or 1660 malicious redirection to a host is avoided. It is still possible 1661 to jam NAR's buffer with redirected traffic. However, since NAR's 1662 handover state corresponding to NCoA has a finite (and short) 1663 lifetime corresponding to a small multiple of anticipated handover 1664 latency, the extent of this vulnerability is arguably small. 1666 Sending FBU from NAR's link: a malicious node may send FBU from 1667 NAR's link providing an unsuspecting node's address as NCoA. This 1668 is similar to base Mobile IP where the MN can provide some other 1669 node's IP address as its CoA to its Home Agent. As in base Mobile 1670 IP, the extent of such a misdelivery can be controlled and 1671 recovery is possible. In addition, it is possible to isolate the 1672 MN if it continues to misbehave. 1674 Apart from the above, the RtSolPr (Section 6.1.1) and PrRtAdv 1675 (Section 6.1.2) messages inherit the weaknesses of Neighbor Discovery 1676 protocol [rfc4861]. Specifically, when its access router is 1677 compromised, the MN's RtSolPr message may be answered by an attacker 1678 that provides a rogue router as the resolution. Should the MN attach 1679 to such a rogue router, its communication can be compromised. 1680 Similarly, a network-initiated PrRtAdv message (see Section 3.3) from 1681 an attacker could cause a MN to handover to a rogue router. Where 1682 these weaknesses are a concern, a solution such as Secure Neighbor 1683 Discovery (SEND) [rfc3971] SHOULD be considered. 1685 The HI and HAck messages between the access routers need to be 1686 secure. For this, the protocol assumes a secure network connection 1687 between the two routers. The mechanism used for securing this 1688 connection is not specified by this document, and is beyond the scope 1689 of this document. 1691 10. IANA Considerations 1693 This document defines the following ICMPv6 messages, all of which can 1694 share a single ICMPv6 Type from the registry in 1695 http://www.iana.org/assignments/icmpv6-parameters. 1697 +------+-------------+---------------+ 1698 | Type | Description | Reference | 1699 +------+-------------+---------------+ 1700 | TBD | RtSolPr | Section 6.1.1 | 1701 | TBD | PrRtAdv | Section 6.1.2 | 1702 | TBD | HI | Section 6.2.1 | 1703 | TBD | HAck | Section 6.2.2 | 1704 +------+-------------+---------------+ 1706 The document defines a new Mobility Option which needs Type 1707 assignment from the Mobility Options Type registry at 1708 http://www.iana.org/assignments/mobility-parameters: 1710 1. Binding Authorization Data for FMIPv6 (BADF) option, described 1711 in Section 6.5.4 1713 The document has already received Type assignments for the following 1714 (see [rfc4068]): 1716 The document defines the following Neighbor Discovery [rfc4861] 1717 options which have received Type assignment from IANA. 1719 +---------+-----------------------------------------+---------------+ 1720 | Subtype | Description | Reference | 1721 +---------+-----------------------------------------+---------------+ 1722 | 17 | IP Address/Prefix Option | Section 6.5.1 | 1723 | 19 | Link-layer Address Option | Section 6.5.2 | 1724 | 20 | Neighbor Advertisement Acknowledgment | Section 6.5.5 | 1725 | | Option | | 1726 +---------+-----------------------------------------+---------------+ 1728 The document defines the following Mobility Header messages which 1729 have received Type allocation from the Mobility Header Types registry 1730 at http://www.iana.org/assignments/mobility-parameters: 1732 1. Fast Binding Update, described in Section 6.3.1 1734 2. Fast Binding Acknowledgment, described in Section 6.3.2 1736 The document defines the following Mobility Option which has received 1737 Type assignment from the Mobility Options Type registry at 1738 http://www.iana.org/assignments/mobility-parameters: 1740 1. Mobility Header Link-Layer Address option, described in 1741 Section 6.5.3 1743 11. Acknowledgments 1745 The editor would like to thank all those who have provided feedback 1746 on this specification, and acknowledges the following people: Vijay 1747 Devarapalli, Youn-Hee Han, Emil Ivov, Syam Madanapalli, Suvidh 1748 Mathur, Andre Martin, Javier Martin, Koshiro Mitsuya, Gabriel 1749 Montenegro, Takeshi Ogawa, Sun Peng, YC Peng, Alex Petrescu, Domagoj 1750 Premec, Subba Reddy, K. Raghav, Ranjit Wable and Jonathan Wood. 1751 Behcet Sarikaya and Frank Xia are acknowledged for the feedback on 1752 operation over point-point links. The editor would like to 1753 acknowledge the contribution from James Kempf to improve this 1754 specification. The editor would also like to thank [mipshop] working 1755 group chair Gabriel Montenegro and the erstwhile [mobile ip] working 1756 group chairs Basavaraj Patil and Phil Roberts for providing much 1757 support for this work. 1759 12. References 1761 12.1. Normative References 1763 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1764 Requirement Levels", BCP 14, RFC 2119, March 1997. 1766 [rfc-ho-send] 1767 Kempf, J. and R. Koodli, "Distributing a Symmetric FMIPv6 1768 Handover Key using SEND (work in progress)", 1769 September 2007. 1771 [rfc2463] Conta, A. and S. Deering, "Internet Control Message 1772 Protocol (ICMPv6) for the Internet Protocol Version 6 1773 (IPv6) Specification", RFC 2463, December 1998, 1774 . 1776 [rfc3315] Droms (Editor), R., "Dynamic Host Configuration Protocol 1777 for IPv6 (DHCPv6)", RFC 3315, July 2003, 1778 . 1780 [rfc3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 1781 in IPv6", RFC 3775, June 2004, 1782 . 1784 [rfc4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 1785 "Neighbor Discovery for IP Version 6 (IPv6)", RFC 4861, 1786 September 2007, . 1788 [rfc4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 1789 Address Autoconfiguration", RFC 4862, September 2007, 1790 . 1792 12.2. Informative References 1794 [rfc3971] Arkko (Editor), J., Kempf, J., Zill, B., and P. Nikander, 1795 "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005. 1797 [rfc4065] Kempf, J., "Instructions for Seamoby and Experimental 1798 Mobility Protocol IANA Allocations", RFC 4065, June 2004. 1800 [rfc4068] Koodli, R., "Fast Handovers for Mobile IPv6", RFC 4068, 1801 July 2005. 1803 Appendix A. Contributors 1805 This document has its origins in the fast handover design team in the 1806 erstwhile [mobile ip] working group. The members of this design team 1807 in alphabetical order were; Gopal Dommety, Karim El-Malki, Mohammed 1808 Khalil, Charles Perkins, Hesham Soliman, George Tsirtsis and Alper 1809 Yegin. 1811 Appendix B. 1813 In this section, we describe the scenarios involving recovery 1814 operations when a highly improbable random address collision occurs. 1816 1. The MN sends FBU from the previous link which results in 1817 packet forwarding to NCoA. These packets may arrive before the MN 1818 attaches to NAR, and hence the latter may invoke Neighbor 1819 Discovery. In the event that there is another node which already 1820 owns the NCoA, NAR (incorrectly) forwards those packets to such a 1821 node. When the MN arrives on the link, it immediately sends a UNA 1822 message, which allows NAR to detect a collision. NAR responds 1823 with a Router Advertisement with NAACK option, forcing the MN to 1824 either use another NCoA supplied in NAACK or reconfigure a new 1825 one. The MN then sends an FBU following the NCoA configuration. 1826 As a special case, the NCoA may be that of NAR itself, which 1827 allows the MN to send FBU that binds its PCoA to NAR's address. 1828 This recovers from temporary misdelivery of packets. Where this 1829 is a concern, using HI and HAck exchange mitigates the problem by 1830 allowing NAR to proxy the NCoA; such a proxying itself can detect 1831 a collision if an entry already exists in the neighbor cache 1832 entry. 1834 2. The MN sends a UNA message followed by an FBU from the new 1835 link. When NAR processes the UNA message, either there is already 1836 an entry for NCoA or there is no entry. If there is an entry, it 1837 either belongs to the MN itself (e.g., in INCOMPLETE state) or the 1838 entry belongs to another node. These entries can be distinguished 1839 by the LLA; the entry with INCOMPLETE state has no LLA. If the 1840 entry belongs to another node, NAR immediately sends a Router 1841 Advertisement with NAACK option (as above) and the MN immediately 1842 sends a new FBU to PAR with a different NCoA. Hence, the extent 1843 of any misdelivery is minimized. 1844 If there is no existing entry for NCoA but there is another node 1845 which owns NCoA, the scenario is more involved. According to 1846 [rfc4861], the UNA message does not create any entry if there is 1847 none to begin with. However, NAR performs Neighbor Solicitation 1848 when packets arrive from PAR (due to FBU processing). Both the MN 1849 and the rightful owner respond with Neighbor Advertisement (NA), 1850 but the MN's Neighbor Advertisement will have the 'O' bit cleared. 1851 If the MN's NA arrives first, NAR starts forwarding to it, but 1852 redirects those packets once the NA from the rightful owner is 1853 processed. At the time of updating the neighbor cache entry, the 1854 NAR sends a Router Advertisement with NAACK option to the MN (as 1855 above), and the MN immediately sends a new FBU to the PAR. If the 1856 MN's NA arrives after the NA from the rightful owner, NAR 1857 similarly sends a Router Advertisement with NAACK option, and the 1858 MN sends a new FBU to the PAR. In both the cases, the extent of 1859 misdelivery can be controlled and recovery is possible. 1861 Appendix C. Change Log 1863 The following revisions were done as part of the AD review 1865 - added a section on "Related Protocol and Node Considerations" 1867 - clarified usage of UNA, which can now update an entry and 1868 send an RA only if NAR is proxying NCoA. Recommendation to 1869 create an entry in STALE state, when none exists, is removed. 1870 (Section 6.4, Section 4) 1872 - clarified protocol usage when DHCP is used for NCoA 1873 formulation (Sections 6.1.2, 3.1, 5.2). Added a new Code value 1874 (5) in PrRtAdv (Section 6.1.2) 1876 - revised Security Considerations 1878 - clarified using HoA in FBU when sent with PCoA as source IP 1879 address 1881 - editorial revisions 1883 - LC comments for 4068bis 1885 - RFC4068bis: all the issues in the tracker since the publication 1886 of RFC 4068. (http://www.mip4.org/issues/tracker/mipshop) 1888 The following changes pre-date RFC 4068 publication. So, the section 1889 numbers probably do not match. 1891 - Added IPSec AH reference. 1893 - Changed options format to make use of RFC 2461 options Type 1894 space. Revised IANA Considerations section accordingly. 1896 - Added exponential backoff for retransmissions. Added rate 1897 limiting for RtSolPr message. 1899 - Replaced ``attachment point'' with ``access point'' for 1900 consistency. 1902 - Clarified [AP-ID, AR-Info] in terminology. Clarified use of 1903 Prefix Information Option 1905 - Separated MH-LLA from LLA to future-proof LLA option. 1907 The following changes refer up to version 02 (under mipshop). The 1908 Section numbers refer to version 06 (under mobile ip). 1910 - New ICMPv6 format incorporated. ID Nits conformance. 1912 - Last Call comments incorporated 1914 - Revised the security considerations section in v07 1916 - Refined and added a section on network-initiated handover v07 1918 - Section 3 format change 1920 - Section 4 format change (i.e., no subsections). 1922 - Description in Section 4.4 merged with ``Fast or Erroneous 1923 Movement'' 1925 - Section 4.5 deprecated 1927 - Section 4.6 deprecated 1929 - Revision of some message formats in Section 6 1931 Author's Address 1933 Rajeev Koodli 1934 Nokia Siemens Networks 1935 313 Fairchild Drive 1936 Mountain View, CA 94043 1937 USA 1939 Email: rajeev.koodli@nokia.com 1941 Full Copyright Statement 1943 Copyright (C) The IETF Trust (2007). 1945 This document is subject to the rights, licenses and restrictions 1946 contained in BCP 78, and except as set forth therein, the authors 1947 retain all their rights. 1949 This document and the information contained herein are provided on an 1950 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1951 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1952 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1953 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1954 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1955 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1957 Intellectual Property 1959 The IETF takes no position regarding the validity or scope of any 1960 Intellectual Property Rights or other rights that might be claimed to 1961 pertain to the implementation or use of the technology described in 1962 this document or the extent to which any license under such rights 1963 might or might not be available; nor does it represent that it has 1964 made any independent effort to identify any such rights. Information 1965 on the procedures with respect to rights in RFC documents can be 1966 found in BCP 78 and BCP 79. 1968 Copies of IPR disclosures made to the IETF Secretariat and any 1969 assurances of licenses to be made available, or the result of an 1970 attempt made to obtain a general license or permission for the use of 1971 such proprietary rights by implementers or users of this 1972 specification can be obtained from the IETF on-line IPR repository at 1973 http://www.ietf.org/ipr. 1975 The IETF invites any interested party to bring to its attention any 1976 copyrights, patents or patent applications, or other proprietary 1977 rights that may cover technology that may be required to implement 1978 this standard. Please address the information to the IETF at 1979 ietf-ipr@ietf.org. 1981 Acknowledgment 1983 Funding for the RFC Editor function is provided by the IETF 1984 Administrative Support Activity (IASA).