idnits 2.17.1 draft-ietf-mipshop-fmipv6-rfc4068bis-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1909. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1920. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1927. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1933. 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 (October 17, 2007) is 6036 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 1857, but not defined == Missing Reference: 'AR-Info' is mentioned on line 1857, 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 October 17, 2007 5 Expires: April 19, 2008 7 Mobile IPv6 Fast Handovers 8 draft-ietf-mipshop-fmipv6-rfc4068bis-03.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 April 19, 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. Configurable Parameters . . . . . . . . . . . . . . . . . . . 37 89 8. Security Considerations . . . . . . . . . . . . . . . . . . . 37 90 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39 91 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 40 92 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 41 93 11.1. Normative References . . . . . . . . . . . . . . . . . . . 41 94 11.2. Informative References . . . . . . . . . . . . . . . . . . 41 95 Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 41 96 Appendix B. . . . . . . . . . . . . . . . . . . . . . . . . . . 42 97 Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 43 98 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 44 99 Intellectual Property and Copyright Statements . . . . . . . . . . 45 101 1. Introduction 103 Mobile IPv6 [rfc3775] describes the protocol operations for a mobile 104 node to maintain connectivity to the Internet during its handover 105 from one access router to another. These operations involve movement 106 detection, IP address configuration, and location update. The 107 combined handover latency is often sufficient to affect real-time 108 applications. Throughput-sensitive applications can also benefit 109 from reducing this latency. This document describes a protocol to 110 reduce the handover latency. 112 This specification addresses the following problem: how to allow a 113 mobile node to send packets as soon as it detects a new subnet link, 114 and how to deliver packets to a mobile node as soon as its attachment 115 is detected by the new access router. The protocol defines IP 116 protocol messages necessary for its operation regardless of link 117 technology. It does this without depending on specific link-layer 118 features while allowing link-specific customizations. By definition, 119 this specification considers handovers that interwork with Mobile IP: 120 once attached to its new access router, a MN engages in Mobile IP 121 operations including Return Routability [rfc3775]. There are no 122 special requirements for a mobile node to behave differently with 123 respect to its standard Mobile IP operations. 125 2. Terminology 127 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 128 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "OPTIONAL", and 129 "silently ignore" in this document are to be interpreted as described 130 in RFC 2119 [RFC2119]. 132 The following terminology and abbreviations are used in this document 133 in addition to those defined in [rfc3775]. The reference handover 134 scenario is illustrated in Figure 1. 136 Mobile Node (MN): A Mobile IPv6 host 138 Access Point (AP): A Layer 2 device connected to an IP subnet that 139 offers wireless connectivity to a MN. An Access Point Identifier 140 (AP-ID) refers the AP's L2 address. Sometimes, AP-ID is also 141 referred to as a Basic Service Set IDentifier (BSSID). 143 Access Router (AR): The MN's default router 145 Previous Access Router (PAR): The MN's default router prior to its 146 handover 147 New Access Router (NAR): The MN's anticipated default router 148 subsequent to its handover 150 Previous CoA (PCoA): The MN's Care of Address valid on PAR's 151 subnet 153 New CoA (NCoA): The MN's Care of Address valid on NAR's subnet 155 Handover: A process of terminating existing connectivity and 156 obtaining new IP connectivity 158 Router Solicitation for Proxy Advertisement (RtSolPr): A message 159 from the MN to the PAR requesting information for a potential 160 handover 162 Proxy Router Advertisement (PrRtAdv): A message from the PAR to 163 the MN that provides information about neighboring links 164 facilitating expedited movement detection. The message can also 165 act as a trigger for network-initiated handover. 167 (AP-ID, AR-Info) tuple: Contains an access router's L2 and IP 168 addresses, and prefix valid on the interface to which the Access 169 Point (identified by AP-ID) is attached. The triplet [Router's L2 170 address, Router's IP address and Prefix] is called "AR-Info". See 171 also Section 5.3. 173 Neighborhood Discovery: The process of resolving neighborhood AP- 174 IDs to AR-Info 176 Assigned Addressing: A particular type of NCoA configuration in 177 which the NAR assigns an IPv6 address for the MN. The method by 178 which NAR manages its address pool is not specified in this 179 document. 181 Fast Binding Update (FBU): A message from the MN instructing its 182 PAR to redirect its traffic (towards NAR) 184 Fast Binding Acknowledgment (FBack): A message from the PAR in 185 response to FBU 187 Predictive Fast Handover: The fast handover in which a MN is able 188 to send FBU when it is attached to the PAR, which then establishes 189 forwarding for its traffic (even before the MN attaches to the 190 NAR) 191 Reactive Fast Handover: The fast handover in which a MN is able to 192 send the FBU only after attaching to the NAR 194 Unsolicited Neighbor Advertisement (UNA): The message in [rfc2461] 195 with 'O' bit cleared 197 Fast Neighbor Advertisement (FNA): This message from RFC4068 198 [rfc4068] is deprecated. The UNA message above is the preferred 199 message in this specification. 201 Handover Initiate (HI): A message from the PAR to the NAR 202 regarding a MN's handover 204 Handover Acknowledge (HAck): A message from the NAR to the PAR as 205 a response to HI 207 v +--------------+ 208 +-+ | Previous | < 209 | | ------------ | Access | ------- >-----\ 210 +-+ | Router | < \ 211 MN | (PAR) | \ 212 | +--------------+ +---------------+ 213 | ^ IP | Correspondent | 214 | | Network | Node | 215 V | +---------------+ 216 v / 217 v +--------------+ / 218 +-+ | New | < / 219 | | ------------ | Access | ------- >-----/ 220 +-+ | Router | < 221 MN | (NAR) | 222 +--------------+ 224 Figure 1: Reference Scenario for Handover 226 3. Protocol Overview 228 3.1. Addressing the Handover Latency 230 The ability to immediately send packets from a new subnet link 231 depends on the "IP connectivity" latency, which in turn depends on 232 the movement detection latency and the new CoA configuration latency. 233 Once a MN is IP-capable on the new subnet link, it can send a Binding 234 Update to its Home Agent and one or more correspondents. Once its 235 correspondents successfully process the Binding Update, which 236 typically involves the Return Routability procedure, the MN can 237 receive packets at the new CoA. So, the ability to receive packets 238 from correspondents directly at its new CoA depends on the Binding 239 Update latency as well as the IP connectivity latency. 241 The protocol enables a MN to quickly detect that it has moved to a 242 new subnet by providing the new access point and the associated 243 subnet prefix information when the MN is still connected to its 244 current subnet (i.e., PAR in Figure 1). For instance, a MN may 245 discover available access points using link-layer specific mechanisms 246 (e.g., a "scan" in WLAN) and then request subnet information 247 corresponding to one or more of those discovered access points. The 248 MN may do this after performing router discovery. The MN may also do 249 this at any time while connected to its current router. The result 250 of resolving an identifier associated with an access point is a 251 [AP-ID, AR-Info] tuple, which a MN can use in readily detecting 252 movement: when attachment to an access point with AP-ID takes place, 253 the MN knows the corresponding new router's co-ordinates including 254 its prefix, IP address and L2 address. The "Router Solicitation for 255 Proxy Advertisement (RtSolPr)" and "Proxy Router Advertisement 256 (PrRtAdv)" messages in Section 6.1 are used for aiding movement 257 detection. 259 Through the RtSolPr and PrRtAdv messages, the MN also formulates a 260 prospective new CoA (NCoA), when it is still present on the PAR's 261 link. Hence, the latency due to new prefix discovery subsequent to 262 handover is eliminated. Furthermore, this prospective address can be 263 used immediately after attaching to the new subnet link (i.e., NAR's 264 link) when the MN has received a "Fast Binding Acknowledgment 265 (FBack)" (see Section 6.3.2) message prior to its movement. In the 266 event it moves without receiving an FBack, the MN can still start 267 using NCoA after announcing its attachment through an unsolicited 268 Neighbor Advertisement message (with the 'O' bit set to zero) message 269 [rfc2461]; NAR responds to to this UNA message in case the tentative 270 address is already in use. In this way, NCoA configuration latency 271 is reduced. 273 In order to reduce the Binding Update latency, the protocol specifies 274 a binding between the Previous CoA (PCoA) and NCoA. A MN sends a 275 "Fast Binding Update" (see Section 6.3.1) message to its Previous 276 Access Router to establish this tunnel. When feasible, the MN SHOULD 277 send FBU from PAR's link. Otherwise, it should send it immediately 278 after detecting attachment to NAR. An FBU message MUST contain the 279 Binding Authorization Data for FMIPv6 (BADF) option (see 280 Section 6.5.4) in order to ensure that only a legitimate MN that owns 281 the PCoA is able to establish a binding. Subsequent sections 282 describe the protocol mechanics. In any case, the result is that PAR 283 begins tunneling packets arriving for PCoA to NCoA. Such a tunnel 284 remains active until the MN completes the Binding Update with its 285 correspondents. In the opposite direction, the MN SHOULD reverse 286 tunnel packets to PAR, again until it completes Binding Update. And, 287 PAR SHOULD forward the inner packet in the tunnel to its destination 288 (i.e., to the MN's correspondent). Such a reverse tunnel ensures 289 that packets containing PCoA as source IP address are not dropped due 290 to ingress filtering. Even though the MN is IP-capable on the new 291 link, it cannot use NCoA directly with its correspondents without the 292 correspondents first establishing a binding cache entry (for NCoA). 293 Forwarding support for PCoA is provided through a reverse tunnel 294 between the MN and the PAR. 296 Setting up a tunnel alone does not ensure that the MN receives 297 packets as soon as attaching to a new subnet link, unless NAR can 298 detect the MN's presence. A neighbor discovery operation involving a 299 neighbor's address resolution (i.e., Neighbor Solicitation and 300 Neighbor Advertisement) typically results in considerable delay, 301 sometimes lasting multiple seconds. For instance, when arriving 302 packets trigger NAR to send Neighbor Solicitation before the MN 303 attaches, subsequent re-transmissions of address resolution are 304 separated by a default period of one second each. In order to 305 circumvent this delay, a MN announces its attachment immediately with 306 an UNA message that allows NAR to forward packets to the MN right 307 away. As a response to UNA, the NAR creates an entry or updates an 308 existing one (while taking any conflicts into account) in order to 309 forward packets to the MN (see details below). Through tunnel 310 establishment for PCoA and fast advertisement, the protocol provides 311 expedited forwarding of packets to the MN. 313 The protocol also provides the following important functionalities. 314 The access routers can exchange messages to confirm that a proposed 315 NCoA is acceptable. For instance, when a MN sends FBU from PAR's 316 link, FBack can be delivered after NAR considers NCoA acceptable to 317 use. This is especially useful when addresses are assigned by the 318 access router. The NAR can also rely on its trust relationship with 319 PAR before providing forwarding support for the MN. That is, it may 320 create a forwarding entry for NCoA subject to "approval" from PAR 321 which it trusts. In addition, buffering for handover traffic may be 322 desirable. Even though the Neighbor Discovery protocol provides a 323 small buffer (typically one or two packets) for packets awaiting 324 address resolution, this buffer may be inadequate for traffic such as 325 VoIP already in progress. The routers may also wish to maintain a 326 separate buffer for servicing the handover traffic. Finally, the 327 access routers could transfer network-resident contexts, such as 328 access control, QoS, header compression, in conjunction with handover 329 (although the context transfer process itself is not specified in 330 this document). For all these operations, the protocol provides 331 "Handover Initiate (HI)" and "Handover Acknowledge (HAck)" messages 332 (see Section 6.2). Both of these messages SHOULD be used. The 333 access routers MUST have necessary security association established 334 by means outside the scope of this document. 336 3.2. Protocol Operation 338 The protocol begins when a MN sends RtSolPr to its access router to 339 resolve one or more Access Point Identifiers to subnet-specific 340 information. In response, the access router (e.g., PAR in Figure 1) 341 sends a PrRtAdv message which contains one or more [AP-ID, AR-Info] 342 tuples. The MN may send RtSolPr at any convenient time, for instance 343 as a response to some link-specific event (a ``trigger'') or simply 344 after performing router discovery. However, the expectation is that 345 prior to sending RtSolPr, the MN has discovered the available APs by 346 link-specific methods. The RtSolPr and PrRtAdv messages do not 347 establish any state at the access router, and their packet formats 348 are defined in Section 6.1. 350 With the information provided in the PrRtAdv message, the MN 351 formulates a prospective NCoA and sends an FBU message. The purpose 352 of FBU is to authorize PAR to bind PCoA to NCoA, so that arriving 353 packets can be tunneled to the new location of the MN. The FBU 354 should be sent from PAR's link whenever feasible. For instance, an 355 internal link-specific trigger could enable FBU transmission from the 356 previous link. 358 When it is not feasible, FBU is sent from the new link. Care must be 359 taken to ensure that NCoA used in FBU does not conflict with an 360 address already in use by some other node on link. 362 The format and semantics of FBU processing are specified in 363 Section 6.3.1. The FBU message MUST contain the BADF option (see 364 Section 6.5.4) to secure the message. 366 Depending on whether an FBack is received or not on the previous 367 link, which clearly depends on whether FBU was sent in the first 368 place, there are two modes of operation. 370 1. The MN receives FBack on the previous link. This means that 371 packet tunneling would already be in progress by the time the MN 372 handovers to NAR. The MN SHOULD send UNA immediately after 373 attaching to NAR, so that arriving as well as buffered packets can 374 be forwarded to the MN right away. 375 Before sending FBack to MN, PAR can determine whether NCoA is 376 acceptable to NAR through the exchange of HI and HAck messages. 377 When assigned addressing (i.e., addresses are assigned by the 378 router) is used, the proposed NCoA in FBU is carried in HI, and 379 NAR MAY assign the proposed NCoA. Such an assigned NCoA MUST be 380 returned in HAck, and PAR MUST in turn provide the assigned NCoA 381 in FBack. If there is an assigned NCoA returned in FBack, the MN 382 MUST use the assigned address (and not the proposed address in 383 FBU) upon attaching to NAR. 385 2. The MN does not receive FBack on the previous link. One 386 reason for this is that the MN has not sent the FBU. The other is 387 that the MN has left the link after sending the FBU, which may be 388 lost, but before receiving an FBack. Without receiving an FBack 389 in the latter case, the MN cannot ascertain whether PAR has 390 successfully processed the FBU. Hence, the MN (re)sends FBU 391 immediately after sending the UNA message. If NAR detects that 392 NCoA is in use when processing UNA, for instance while creating a 393 neighbor entry, it sends a Router Advertisement with "Neighbor 394 Advertisement Acknowledge (NAACK)" option in which NAR MAY include 395 an alternate IP address for the MN to use. Detailed UNA 396 processing rules are specified in Section 6.4. 398 The scenario in which a MN sends FBU and receives FBack on PAR's link 399 is illustrated in Figure 2. For convenience, this scenario is called 400 "predictive" mode of operation. The scenario in which the MN sends 401 FBU from NAR's link is illustrated in Figure 3. For convenience, 402 this scenario is called "reactive" mode of operation. Note that the 403 reactive mode also includes the case when FBU has been sent from 404 PAR's link but FBack has not been received yet. The Figure is 405 intended to illustrate that the FBU is forwarded through NAR, but it 406 is processed only by the PAR. 408 Finally, the PrRtAdv message may be sent unsolicited, i.e., without 409 the MN first sending RtSolPr. This mode is described in Section 3.3. 411 3.3. Protocol Operation during Network-initiated Handover 413 In some wireless technologies, the handover control may reside in the 414 network even though the decision to undergo handover may be arrived 415 at by cooperation between the MN and the network. In such networks, 416 the PAR can send an unsolicited PrRtAdv containing the link layer 417 address, IP address and subnet prefix of the NAR when the network 418 decides that a handover is imminent. The MN MUST process this 419 PrRtAdv to configure a new care of address on the new subnet, and 420 MUST send an FBU to PAR prior to switching to the new link. After 421 transmitting PrRtAdv, the PAR MUST continue to forward packets to the 422 MN on its current link until the FBU is received. The rest of the 423 operation is the same as that described in Section 3.2. 425 The unsolicited PrRtAdv also allows the network to inform the MN 426 about geographically adjacent subnets without the MN having to 427 explicitly request that information. This can reduce the amount of 428 wireless traffic required for the MN to obtain a neighborhood 429 topology map of links and subnets. Such usage of PrRtAdv is 430 decoupled from the actual handover. See Section 6.1.2. 432 MN PAR NAR 433 | | | 434 |------RtSolPr------->| | 435 |<-----PrRtAdv--------| | 436 | | | 437 |------FBU----------->|----------HI--------->| 438 | |<--------HAck---------| 439 | <--FBack---|--FBack---> | 440 | | | 441 disconnect forward | 442 | packets ===============>| 443 | | | 444 | | | 445 connect | | 446 | | | 447 |------------UNA --------------------------->| 448 |<=================================== deliver packets 449 | | 451 Figure 2: Predictive Fast Handover 453 MN PAR NAR 454 | | | 455 |------RtSolPr------->| | 456 |<-----PrRtAdv--------| | 457 | | | 458 disconnect | | 459 | | | 460 | | | 461 connect | | 462 |-------UNA-----------|--------------------->| 463 |-------FBU-----------|---------------------)| 464 | |<-------FBU----------)| 465 | |<------HI/HAck------->| 466 | | (if necessary) | 467 | forward | 468 | packets(including FBAck)=====>| 469 | | | 470 |<=================================== deliver packets 471 | | 473 Figure 3: Reactive Fast Handover 475 4. Protocol Details 477 All description makes use of Figure 1 as the reference. 479 After discovering one or more nearby access points, the MN sends 480 RtSolPr in order to resolve access point identifiers to subnet router 481 information. A convenient time to do this is after performing router 482 discovery. However, the MN can send RtSolPr at any time, e.g., when 483 one or more new access points are discovered. The MN can also send 484 RtSolPr more than once during its attachment to PAR. The trigger for 485 sending RtSolPr can originate from a link-specific event, such as the 486 promise of a better signal strength from another access point coupled 487 with fading signal quality with the current access point. Such 488 events, often broadly referred to as "L2 triggers", are outside the 489 scope of this document. Nevertheless, they serve as events that 490 invoke this protocol. For instance, when a "link up" indication is 491 obtained on the new link, protocol messages (e.g., UNA) can be 492 immediately transmitted. Implementations SHOULD make use of such 493 triggers whenever available. 495 The RtSolPr message contains one or more AP-IDs. A wildcard requests 496 all available tuples. 498 As a response to RtSolPr, PAR sends a PrRtAdv message which indicates 499 one of the following possible conditions. 501 1. If the PAR does not have an entry corresponding to the new 502 access point, it responds indicating that the new access point is 503 unknown. The MN MUST stop fast handover protocol operations on 504 the current link. The MN MAY send an FBU from its new link. 506 2. If the new access point is connected to the PAR's current 507 interface (to which MN is attached), PAR responds with a Code 508 value indicating that the new access point is connected to the 509 current interface, but not send any prefix information. This 510 scenario could arise, for example, when several wireless access 511 points are bridged into a wired network. No further protocol 512 action is necessary. 514 3. If the new access point is known and the PAR has information 515 about it, then PAR responds indicating that the new access point 516 is known and supply the [AP-ID, AR-Info] tuple. If the new access 517 point is known, but does not support fast handover, the PAR MUST 518 indicate this with Code 3 (see Section 6.1.2). 520 4. If a wildcard is supplied as an identifier for the new access 521 point, the PAR SHOULD supply neighborhood [AP-ID, AR-Info] tuples 522 subject to path MTU restrictions (i.e., provide any 'n' tuples 523 without exceeding the link MTU). 525 When further protocol action is necessary, some implementations may 526 choose to provide buffering support at PAR to address the scenario in 527 which a MN leaves without sending an FBU message from the PAR's link. 528 While the protocol does not forbid such an implementation support, 529 care must be taken to ensure that the PAR continues forwarding 530 packets to the PCoA (i.e., uses a buffer and forward approach). The 531 PAR should also stop buffering once it processes the FBU message. 533 The method by which Access Routers exchange information about their 534 neighbors and thereby allow construction of Proxy Router 535 Advertisements with information about neighboring subnets is outside 536 the scope of this document. 538 The RtSolPr and PrRtAdv messages MUST be implemented by a MN and an 539 access router that supports fast handovers. However, when the 540 parameters necessary for the MN to send packets immediately upon 541 attaching to the NAR are supplied by the link layer handover 542 mechanism itself, use of above messages is optional on such links. 544 After a PrRtAdv message is processed, the MN sends FBU and includes 545 the proposed NCoA. The MN SHOULD send FBU from PAR's link whenever 546 "anticipation" of handover is feasible. When anticipation is not 547 feasible or when it has not received an FBack, the MN sends FBU 548 immediately after attaching to NAR's link. In response to FBU, PAR 549 establishes a binding between PCoA ("Home Address") and NCoA, and 550 sends FBack to MN. Prior to establishing this binding, PAR SHOULD 551 send a HI message to NAR, and receive HAck in response. In order to 552 determine the NAR's address for the HI message, the PAR can perform 553 longest prefix match of NCoA (in FBU) with the prefix list of 554 neighboring access routers. When the source IP address of FBU is 555 PCoA, i.e., the FBU is sent from the PAR's link, the HI message MUST 556 have a Code value set to 0. See Section 6.2.1. When the source IP 557 address of FBU is not PCoA, i.e., the FBU is sent from the NAR's 558 link, the HI message MUST have a Code value of 1. See Section 6.2.1. 560 The HI message contains the PCoA, link-layer address and the NCoA of 561 the MN. In response to processing a HI message with Code 0, the NAR 563 1. determines whether NCoA supplied in the HI message is a valid 564 address for use, and if it is, starts proxying [rfc2461] the 565 address for PROXY_ND_LIFETIME during which the MN is expected to 566 connect to NAR. In case there is already an NCoA present, NAR may 567 verify if the LLA is the same as its own or that of the MN itself. 568 If so, NAR may allow the use of NCoA. 570 2. allocates NCoA for the MN when assigned addressing is used, 571 creates a proxy neighbor cache entry and begins defending it. The 572 NAR MAY allocate the NCoA proposed in HI. 574 3. MAY create a host route entry for PCoA (on the interface to 575 which the MN is attaching to) in case NCoA cannot be accepted or 576 assigned. This host route entry SHOULD be implemented such that 577 until the MN's presence is detected, either through explicit 578 announcement by the MN or by other means, arriving packets do not 579 invoke neighbor discovery. The NAR SHOULD also set up a reverse 580 tunnel to PAR in this case. 582 4. provides the status of handover request in Handover Acknowledge 583 (HAck) message. 585 When the Code value in HI is 1, NAR MUST skip the above operations. 586 However, it SHOULD be prepared to process any other options which may 587 be defined in the future. Sending a HI message with Code 1 allows 588 NAR to validate the neighbor cache entry it creates for the MN during 589 UNA processing. That is, NAR can make use of the knowledge that its 590 trusted peer (i.e., PAR) has a trust relationship with the MN. 592 If HAck contains an assigned NCoA, it must be included in FBack, and 593 the MN MUST use it. The PAR MAY send FBack to the previous link as 594 well to facilitate faster reception in the event the MN be still 595 present there. The result of FBU and FBack processing is that PAR 596 begins tunneling MN's packets to NCoA. If the MN does not receive an 597 FBack message even after re-transmitting FBU for FBU_RETRIES, it must 598 assume that fast handover support is not available and stop the 599 protocol operation. 601 As soon as the MN establishes link connectivity with the NAR, it 603 1. sends a UNA message (see Section 6.4). If the MN has not 604 received an FBack by the time UNA is being sent, it SHOULD send an 605 FBU message following the UNA message. 607 2. joins the all-nodes multicast group and the solicited-node 608 multicast group corresponding to the NCoA 610 3. starts a DAD probe for NCoA. See [rfc2462]. 612 When a NAR receives a UNA message, it 614 1. SHOULD create a neighbor cache entry for NCoA if none exists 615 and set it to STALE. This allows it to forward any arriving 616 packets while it probes bidirectional reachability. 618 2. updates an entry in INCOMPLETE state, if it exists, to STALE 619 and forwards arriving and buffered packets. This would be the 620 case if NAR had previously sent a Neighbor Solicitation which went 621 unanswered perhaps because the MN had not yet attached to the 622 link. 624 3. deletes its proxy neighbor cache entry, if any, updates the 625 state to STALE, and forwards arriving and buffered packets. 627 The buffer for handover traffic should be linked to this UNA 628 processing. The exact mechanism is implementation dependent. 630 The NAR may detect that NCoA is in use by another node when 631 processing the UNA message, in which case it 633 1. MUST NOT update the existing entry. 635 2. MUST send a Router Advertisement with the NAACK option in 636 which it MAY include an alternate NCoA for use. This message MUST 637 be sent to the source IP address present in UNA using the same 638 Layer 2 address present in UNA. 640 If the MN receives an IP address in the NAACK option, it MUST use it 641 and send an FBU using the new CoA. As a special case, the address 642 supplied in NAACK could be PCoA itself, in which case the MN MUST NOT 643 send any more FBUs. The Status codes for NAACK option are specified 644 in Section 6.5.5. 646 Once the MN has confirmed its NCoA (either through DAD or when 647 provided for by the NAR), it SHOULD send a Neighbor Advertisement 648 message with the 'O' bit set, to the all-nodes multicast address. 649 This message allows MN's neighbors to update their neighbor cache 650 entries. 652 For data forwarding, the PAR tunnels packets using its global IP 653 address valid on the interface to which the MN was attached. The MN 654 reverse tunnels its packets to the same global address of PAR. The 655 tunnel end-point addresses must be configured accordingly. When PAR 656 receives a reverse tunneled packet, it must verify if a secure 657 binding exists for the MN identified by PCoA in the tunneled packet, 658 before forwarding the packet. 660 5. Other Considerations 662 5.1. Handover Capability Exchange 664 The MN expects a PrRtAdv in response to its RtSolPr message. If the 665 MN does not receive a PrRtAdv message even after RTSOLPR_RETRIES, it 666 must assume that PAR does not support the fast handover protocol and 667 stop sending any more RtSolPr messages. 669 Even if a MN's current access router is capable of providing fast 670 handover support, the new access router may not be capable of 671 providing such support. This is indicated to the MN during 672 "runtime", through the PrRtAdv message with a Code value of 3 (see 673 Section 6.1.2). 675 5.2. Determining New Care of Address 677 Typically, the MN formulates its prospective NCoA using the 678 information provided in a PrRtAdv message, and sends FBU. This NCoA 679 can be provided to NAR in the HI message. NAR provides a disposition 680 of HI, and hence the NCoA itself, in the HAck message indicating 681 whether NCoA is acceptable. However, the MN itself does not have to 682 wait on PAR's link for this exchange to take place. It can handover 683 any time after sending the FBU message; sometimes it may be forced to 684 handover without sending the FBU. In any case, it can still confirm 685 using NCoA from NAR's link by sending the UNA message. 687 If PrRtAdv message carries a NCoA, the MN MUST use it as its 688 prospective NCoA. 690 5.3. Prefix Management 692 As defined in Section 2, the Prefix part of ``AR-Info'' is the prefix 693 valid on the interface to which the AP is attached. This document 694 does not specify how this Prefix is managed, it's length and 695 assignment policies. The protocol operation specified in this 696 document works regardless of these considerations. Often, but not 697 necessarily always, this Prefix may be the aggregate prefix (such as 698 /48) valid on the interface. In some deployments, each MN may have 699 its own per-mobile prefix (such as a /64) used for generating the 700 NCoA. Some point-to-point links may use such a deployment. 702 When per-mobile prefix assignment is used, the ``AR-Info'' advertised 703 in PrRtAdv still includes the (aggregate) prefix valid on the 704 interface to which the target AP is attached, unless the access 705 routers communicate with each other (using HI and HAck messages) to 706 manage per-mobile prefix. The MN still formulates an NCoA using the 707 aggregate prefix. However, an alternate NCoA based on the per-mobile 708 prefix is returned by NAR in the HAck message. This alternate NCoA 709 is provided to the MN in either the FBack message or in the NAACK 710 option. 712 5.4. Packet Loss 714 Handover involves link switching, which may not be exactly co- 715 ordinated with fast handover signaling. Furthermore, the arrival 716 pattern of packets is dependent on many factors, including 717 application characteristics, network queuing behaviors etc. Hence, 718 packets may arrive at NAR before the MN is able to establish its link 719 there. These packets will be lost unless they are buffered by the 720 NAR. Similarly, if the MN attaches to NAR and then sends an FBU 721 message, packets arriving at PAR until FBU is processed will be lost 722 unless they are buffered. This protocol provides an option to 723 indicate request for buffering at the NAR in the HI message. When 724 the PAR requests this feature (for the MN), it SHOULD also provide 725 its own support for buffering. 727 5.5. DAD Handling 729 Duplicate Address Detection (DAD) was defined in [rfc2462] to avoid 730 address duplication on links when stateless address auto- 731 configuration is used. The use of DAD to verify the uniqueness of an 732 IPv6 address configured through stateless auto-configuration adds 733 delays to a handover. The probability of an interface identifier 734 duplication on the same subnet is very low, however it cannot be 735 ignored. So, this protocol SHOULD only be used in deployments where 736 the probability of such address collisions is extremely low. 738 This document specifies messages which can be used to provide 739 duplicate-free addresses but the document does not specify how to 740 create or manage such duplicate-free addresses. In some cases the 741 NAR may already have the knowledge required to assess whether the 742 MN's address is a duplicate or not before the MN moves to the new 743 subnet. For example, the NAR can have a list of all nodes on its 744 point-to-point radio network, and by searching this list, it can 745 confirm whether the MN's address is a duplicate or not. In some 746 other deployments, the NAR may maintain a pool of duplicate-free 747 addresses in a list for handover purposes. In such cases, the NAR 748 can provide this disposition in the HAck message (see Section 6.2.2) 749 or in the NAACK option (see Section 6.5.5). 751 In deployments where an access router does not provide duplicate-free 752 addresses, this protocol SHOULD only be used where the probability of 753 address collision is extremely low. The recovery operations that 754 take place when the highly improbable random collisions occur are 755 described in Appendix B. 757 5.6. Fast or Erroneous Movement 759 Although this specification is for fast handover, the protocol has 760 its limits in terms of how fast a MN can move. A special case of 761 fast movement is ping-pong, where a MN moves between the same two 762 access points rapidly. Another instance of the same problem is 763 erroneous movement i.e., the MN receives information prior to a 764 handover that it is moving to a new access point but it either moves 765 to a different one or aborts movement altogether. All of the above 766 behaviors are usually the result of link layer idiosyncrasies and 767 thus are often tackled at the link layer itself. 769 IP layer mobility, however, introduces its own limits. IP layer 770 handovers should occur at a rate suitable for the MN to update the 771 binding of, at least, its Home Agent and preferably that of every CN 772 with which it is in communication. A MN that moves faster than 773 necessary for this signaling to complete, which may be of the order 774 of few seconds, may start losing packets. The signaling overhead 775 over the air and in the network may increase significantly, 776 especially in the case of rapid movement between several access 777 routers. To avoid the signaling overhead, the following measures are 778 suggested. 780 A MN returning to the PAR before updating the necessary bindings when 781 present on NAR MUST send a Fast Binding Update with Home Address 782 equal to the MN's PCoA and a lifetime of zero, to the PAR. The MN 783 should have a security association with the PAR since it performed a 784 fast handover to the NAR. The PAR, on receiving this Fast Binding 785 Update, will check its set of outgoing (temporary fast handover) 786 tunnels. If it finds a match it SHOULD terminate that tunnel; i.e., 787 start delivering packets directly to the node instead. In order for 788 PAR to process such an FBU, the lifetime of the security association 789 has to be at least that of the tunnel itself. 791 Temporary tunnels for the purposes of fast handovers should use short 792 lifetimes (of the order of a small number of seconds or less). The 793 lifetime of such tunnels should be enough to allow a MN to update all 794 its active bindings. The default lifetime of the tunnel should be 795 the same as the lifetime value in the FBU message. 797 The effect of erroneous movement is typically limited to loss of 798 packets since routing can change and the PAR may forward packets 799 towards another router before the MN actually connects to that 800 router. If the MN discovers itself on an unanticipated access 801 router, it SHOULD send a new Fast Binding Update to the PAR. This 802 FBU supersedes the existing binding at PAR and the packets will be 803 redirected to the new confirmed location of the MN. 805 6. Message Formats 807 All the ICMPv6 messages have a common Type specified in [rfc2463]. 808 The messages are distinguished based on the Subtype field (see 809 below). For all the ICMPv6 messages, the checksum is defined in 810 [rfc2463]. 812 6.1. New Neighborhood Discovery Messages 814 6.1.1. Router Solicitation for Proxy Advertisement (RtSolPr) 816 Mobile Nodes send Router Solicitation for Proxy Advertisement in 817 order to prompt routers for Proxy Router Advertisements. All the 818 link-layer address options have the format defined in Section 6.5.2. 820 0 1 2 3 821 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 822 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 823 | Type | Code | Checksum | 824 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 825 | Subtype | Reserved | Identifier | 826 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 827 | Options ... 828 +-+-+-+-+-+-+-+-+-+-+-+- 830 Figure 4: Router Solicitation for Proxy Advertisement (RtSolPr) 831 Message 833 IP Fields: 835 Source Address: An IP address assigned to the sending interface 837 Destination Address: The address of the Access Router or the 838 all routers multicast address. 840 Hop Limit: 255. See RFC 2461. 842 ICMP Fields: 844 Type: To be assigned by IANA 846 Code: 0 848 Checksum: The ICMPv6 checksum. 850 Subtype: 2 852 Reserved: MUST be set to zero by the sender and ignored by the 853 receiver. 855 Identifier: MUST be set by the sender so that replies can be 856 matched to this Solicitation. 858 Valid Options: 860 Source Link-layer Address: When known, the link-layer address 861 of the sender SHOULD be included using the Link-Layer Address 862 option. See LLA option format below. 864 New Access Point Link-layer Address: The link-layer address or 865 identification of the access point for which the MN requests 866 routing advertisement information. It MUST be included in all 867 RtSolPr messages. More than one such address or identifier can 868 be present. This field can also be a wildcard address. See 869 LLA Option below. 871 Future versions of this protocol may define new option types. 872 Receivers MUST silently ignore any options that they do not recognize 873 and continue processing the rest of the message. 875 Including the source LLA option allows the receiver to record the 876 sender's L2 address so that neighbor discovery, when the receiver 877 needs to send packets back to the sender (of RtSolPr message), can be 878 avoided. 880 When a wildcard is used for New Access Point LLA, no other New Access 881 Point LLA options must be present. 883 A Proxy Router Advertisement (PrRtAdv) message should be received by 884 the MN as a response to RtSolPr. If such a message is not received 885 in a short time period but no less than twice the typical round trip 886 time (RTT) over the access link or 100 milliseconds if RTT is not 887 known, it SHOULD resend RtSolPr message. Subsequent retransmissions 888 can be up to RTSOLPR|RETRIES, but MUST use an exponential backoff in 889 which the timeout period (i.e., 2xRTT or 100 milliseconds) is doubled 890 prior to each instance of retransmission. If Proxy Router 891 Advertisement is not received by the time the MN disconnects from the 892 PAR, the MN SHOULD send FBU immediately after configuring a new CoA. 894 When RtSolPr messages are sent more than once, they MUST be rate 895 limited with MAX|RTSOLPR|RATE per second. During each use of 896 RtSolPr, exponential backoff is used for retransmissions. 898 6.1.2. Proxy Router Advertisement (PrRtAdv) 900 Access routers send out Proxy Router Advertisement message 901 gratuitously if the handover is network-initiated or as a response to 902 RtSolPr message from a MN, providing the link-layer address, IP 903 address and subnet prefixes of neighboring routers. All the link- 904 layer address options have the format defined in 6.4.3. 906 0 1 2 3 907 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 908 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 909 | Type | Code | Checksum | 910 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 911 | Subtype | Reserved | Identifier | 912 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 913 | Options ... 914 +-+-+-+-+-+-+-+-+-+-+-+- 916 Figure 5: Proxy Router Advertisement (PrRtAdv) Message 918 IP Fields: 920 Source Address: MUST be the link-local address assigned to the 921 interface from which this message is sent. 923 Destination Address: The Source Address of an invoking Router 924 Solicitation for Proxy Advertisement or the address of the node 925 the Access Router is instructing to handover. 927 Hop Limit: 255. See RFC 2461. 929 ICMP Fields: 931 Type: To be assigned by IANA 933 Code: 0, 1, 2, 3 or 4. See below. 935 Checksum: The ICMPv6 checksum. 937 Subtype: 3 939 Reserved: MUST be set to zero by the sender and ignored by the 940 receiver. 942 Identifier: Copied from Router Solicitation for Proxy 943 Advertisement or set to Zero if unsolicited. 945 Valid Options in the following order: 947 Source Link-layer Address: When known, the link-layer address 948 of the sender SHOULD be included using the Link-Layer Address 949 option. See LLA option format below. 951 New Access Point Link-layer Address: The link-layer address or 952 identification of the access point is copied from RtSolPr 953 message. This option MUST be present. 955 New Router's Link-layer Address: The link-layer address of the 956 Access Router for which this message is proxied for. This 957 option MUST be included when Code is 0 or 1. 959 New Router's IP Address: The IP address of NAR. This option 960 MUST be included when Code is 0 or 1. 962 New Router Prefix Information Option: Specifies the prefix of 963 the Access Router the message is proxied for and is used for 964 address auto-configuration. This option MUST be included when 965 Code is 0 or 1. However, when this prefix is the same as what 966 is used in the New Router's IP Address option (above), the 967 Prefix Information option need not be present. 969 New CoA Option: MAY be present when PrRtAdv is sent 970 unsolicited. PAR MAY compute new CoA using NAR's prefix 971 information and the MN's L2 address, or by any other means. 973 Future versions of this protocol may define new option types. 974 Receivers MUST silently ignore any options they do not recognize and 975 continue processing the message. 977 Currently, Code values 0, 1, 2, 3 and 4 are defined. 979 A Proxy Router Advertisement with Code 0 means that the MN should use 980 the [AP-ID, AR-Info] tuple (present in the options above) for 981 movement detection and NCoA formulation. The Option-Code field in 982 the New Access Point LLA option in this case is 1 reflecting the LLA 983 of the access point for which the rest of the options are related. 984 Multiple tuples may be present. 986 A Proxy Router Advertisement with Code 1 means that the message is 987 sent unsolicited. If a New CoA option is present following the New 988 Router Prefix Information option, the MN SHOULD use the supplied NCoA 989 and send FBU immediately or else stand to lose service. This message 990 acts as a network-initiated handover trigger. See Section 3.3. The 991 Option-Code field in the New Access Point LLA option (see below) in 992 this case is 1 reflecting the LLA of the access point for which the 993 rest of the options are related. 995 A Proxy Router Advertisement with Code 2 means that no new router 996 information is present. Each New Access Point LLA option contains an 997 Option-Code value (described below) which indicates a specific 998 outcome. 1000 When the Option-Code field in the New Access Point LLA option is 1001 5, handover to that access point does not require change of CoA. 1002 No other options are required in this case. 1004 When the Option-Code field in the New Access Point LLA option is 1005 6, PAR is not aware of the Prefix Information requested. The MN 1006 SHOULD attempt to send FBU as soon as it regains connectivity with 1007 the NAR. No other options are required in this case. 1009 When the Option-Code field in the New Access Point LLA option is 1010 7, it means that the NAR does not support fast handover. The MN 1011 MUST stop fast handover protocol operations. No other options are 1012 required in this case. 1014 A Proxy Router Advertisement with Code 3 means that new router 1015 information is present only for a subset of access points 1016 requested. The Option-Code field values (defined above including 1017 a value of 1) distinguish different outcomes for individual access 1018 points. 1019 A Proxy Router Advertisement with Code 4 means that the subnet 1020 information regarding neighboring access points is sent 1021 unsolicited, but the message is not a handover trigger, unlike 1022 when the message is sent with Code 1. Multiple tuples may be 1023 present. 1024 When a wildcard AP identifier is supplied in the RtSolPr message, 1025 the PrRtAdv message should include any 'n' [Access Point 1026 Identifier, Link-layer address option, Prefix Information Option] 1027 tuples corresponding to the PAR's neighborhood. 1029 6.2. Inter-Access Router Messages 1031 6.2.1. Handover Initiate (HI) 1033 The Handover Initiate (HI) is an ICMPv6 message sent by an Access 1034 Router (typically PAR) to another Access Router (typically NAR) to 1035 initiate the process of a MN's handover. 1037 0 1 2 3 1038 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 1039 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1040 | Type | Code | Checksum | 1041 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1042 | Subtype |S|U| Reserved | Identifier | 1043 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1044 | Options ... 1045 +-+-+-+-+-+-+-+-+-+-+-+- 1047 Figure 6: Handover Initiate (HI) Message 1049 IP Fields: 1051 Source Address: The IP address of the PAR 1053 Destination Address: The IP address of the NAR 1055 ICMP Fields: 1057 Type: To be assigned by IANA 1059 Code: 0 or 1. See below 1061 Checksum: The ICMPv6 checksum. 1063 Subtype: 4 1065 'S' flag: Assigned address configuration flag. When set, this 1066 message requests a new CoA to be returned by the destination. 1067 May be set when Code = 0. MUST be 0 when Code = 1. 1069 'U' flag: Buffer flag. When set, the destination SHOULD buffer 1070 any packets towards the node indicated in the options of this 1071 message. Used when Code = 0, SHOULD be set to 0 when Code = 1. 1073 Reserved: MUST be set to zero by the sender and ignored by the 1074 receiver. 1076 Identifier: MUST be set by the sender so replies can be matched 1077 to this message. 1079 Valid Options: 1081 Link-layer address of MN: The link-layer address of the MN that is 1082 undergoing handover to the destination (i.e., NAR). This option 1083 MUST be included so that the destination can recognize the MN. 1085 Previous Care of Address: The IP address used by the MN while 1086 attached to the originating router. This option SHOULD be 1087 included so that host route can be established in case necessary. 1089 New Care of Address: The IP address the MN wishes to use when 1090 connected to the destination. When the `S' bit is set, NAR MAY 1091 assign this address. 1093 The PAR uses a Code value of 0 when it processes an FBU with PCoA as 1094 source IP address. The PAR uses a Code value of 1 when it processes 1095 an FBU whose source IP address is not PCoA. 1097 If Handover Acknowledge (HAck) message is not received as a response 1098 in a short time period but no less than twice the typical round trip 1099 time (RTT) between source and destination, or 100 milliseconds if RTT 1100 is not known, the Handover Initiate SHOULD be re-sent. Subsequent 1101 retransmissions can be up to HI|RETRIES, but MUST use exponential 1102 backoff in which the timeout period (i.e., 2xRTT or 100 milliseconds) 1103 is doubled during each instance of retransmission. 1105 6.2.2. Handover Acknowledge (HAck) 1107 The Handover Acknowledgment message is a new ICMPv6 message that MUST 1108 be sent (typically by NAR to PAR) as a reply to the Handover Initiate 1109 message. 1111 0 1 2 3 1112 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 1113 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1114 | Type | Code | Checksum | 1115 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1116 | Subtype | Reserved | Identifier | 1117 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1118 | Options ... 1119 +-+-+-+-+-+-+-+-+-+-+-+- 1121 Figure 7: Handover Acknowledge (HAck) Message 1123 IP Fields: 1125 Source Address: Copied from the destination address of the 1126 Handover Initiate Message to which this message is a response. 1128 Destination Address: Copied from the source address of the 1129 Handover Initiate Message to which this message is a response. 1131 ICMP Fields: 1133 Type: To be assigned by IANA 1135 Code: 1137 0: Handover Accepted, NCoA valid 1138 1: Handover Accepted, NCoA not valid or in use 1139 2: Handover Accepted, NCoA assigned (used in Assigned 1140 addressing) 1141 3: Handover Accepted, use PCoA 1142 4: Message sent unsolicited, usually to trigger a HI message 1143 128: Handover Not Accepted, reason unspecified 1144 129: Administratively prohibited 1145 130: Insufficient resources 1147 Checksum: The ICMPv6 checksum. 1149 Subtype: 5 1151 Reserved: MUST be set to zero by the sender and ignored by the 1152 receiver. 1154 Identifier: Copied from the corresponding field in the Handover 1155 Initiate message this message is in response to. 1157 Valid Options: 1159 New Care of Address: If the S flag in the Handover Initiate message 1160 is set, this option MUST be used to provide NCoA the MN should use 1161 when connected to this router. This option MAY be included even when 1162 `S' bit is not set, e.g., Code 2 above. 1164 Upon receiving a HI message, the NAR MUST respond with a Handover 1165 Acknowledge message. If the `S' flag is set in the HI message, the 1166 NAR SHOULD include the New Care of Address option and a Code 3. 1168 The NAR MAY provide support for PCoA (instead of accepting or 1169 assigning NCoA), using a host route entry to forward packets to the 1170 PCoA, and using a tunnel to the PAR to forward packets from the MN 1171 (sent with PCoA as source IP address). This host route entry SHOULD 1172 be used to forward packets once the NAR detects that the particular 1173 MN is attached to its link. The NAR indicates forwarding support for 1174 PCoA using Code value 5 in the HAck message. Subsequently, PAR 1175 establishes a tunnel to NAR in order to forward packets arriving for 1176 PCoA. 1178 When responding to a HI message containing a Code value 1, the Code 1179 values 1, 2, and 4 in the HAck message are not relevant. 1181 Finally, the new access router can always refuse handover, in which 1182 case it should indicate the reason in one of the available Code 1183 values. 1185 6.3. New Mobility Header Messages 1187 Mobile IPv6 uses a new IPv6 header type called Mobility Header 1188 [rfc3775]. The Fast Binding Update, Fast Binding Acknowledgment and 1189 Fast Neighbor Advertisement messages use the Mobility Header. 1191 6.3.1. Fast Binding Update (FBU) 1193 The Fast Binding Update message is identical to the Mobile IPv6 1194 Binding Update (BU) message. However, the processing rules are 1195 slightly different. 1197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1198 | Sequence # | 1199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1200 |A|H|L|K| Reserved | Lifetime | 1201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1202 | | 1203 . . 1204 . Mobility options . 1205 . . 1206 | | 1207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1209 Figure 8: Fast Binding Update (FBU) Message 1211 IP Fields: 1213 Source address: The PCoA or NCoA 1215 Destination Address: The IP address of the Previous Access 1216 Router 1218 `A' flag: MUST be set to one to request PAR to send a Fast Binding 1219 Acknowledgment message. 1221 `H' flag: MUST be set to one. See [rfc3775]. 1223 `L' flag: See [rfc3775]. 1225 `K' flag: See [rfc3775]. 1227 Reserved: This field is unused. MUST be set zero. 1229 Sequence Number: See See [rfc3775]. 1231 Lifetime: The requested time in seconds for which the sender 1232 wishes to have a binding. 1234 Mobility Options: MUST contain alternate CoA option set to NCoA IP 1235 address when FBU is sent from PAR's link. MUST contain the 1236 Binding Authorization Data for FMIP (BADF) option. See 1237 Section 6.5.4. MAY contain the Mobility Header LLA option (see 1238 Section 6.5.3). 1240 The MN sends FBU message any time after receiving a PrRtAdv message. 1241 If the MN moves prior to receiving a PrRtAdv message, it SHOULD send 1242 a FBU to the PAR after configuring NCoA on the NAR according to 1243 Neighbor Discovery and IPv6 Address Configuration protocols. 1245 The source IP address is PCoA when FBU is sent from PAR's link, and 1246 the source IP address is NCoA when sent from NAR's link. 1248 The FBU MUST also include the Home Address Option and the Home 1249 Address is PCoA. A FBU message MUST be protected so that PAR is able 1250 to determine that the FBU message is sent by a genuine MN. 1252 6.3.2. Fast Binding Acknowledgment (FBack) 1254 The Fast Binding Acknowledgment message is sent by the PAR to 1255 acknowledge receipt of a Fast Binding Update message in which the `A' 1256 bit is set. If PAR sends a HI message to the NAR after processing an 1257 FBU, the FBack message SHOULD NOT be sent to the MN before the PAR 1258 receives a HAck message from the NAR. The PAR MAY send the FBack 1259 immediately in the reactive mode however. The Fast Binding 1260 Acknowledgment MAY also be sent to the MN on the old link. 1262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1263 | Status |K| Reserved | 1264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1265 | Sequence # | Lifetime | 1266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1267 | | 1268 . . 1269 . Mobility options . 1270 . . 1271 | | 1272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1274 Figure 9: Fast Binding Acknowledgment (FBack) Message 1276 IP Fields: 1278 Source address: The IP address of the Previous Access Router 1280 Destination Address: The NCoA, and optionally PCoA 1282 Status: 8-bit unsigned integer indicating the disposition of the 1283 Fast Binding Update. Values of the Status field less than 128 1284 indicate that the Binding Update was accepted by the receiving 1285 node. The following such Status values are currently defined: 1287 0 Fast Binding Update accepted 1288 1 Fast Binding Update accepted but NCoA is invalid. Use NCoA 1289 supplied in ``alternate'' CoA 1291 Values of the Status field greater than or equal to 128 indicate 1292 that the Binding Update was rejected by the receiving node. The 1293 following such Status values are currently defined: 1295 128: Reason unspecified 1296 129: Administratively prohibited 1297 130: Insufficient resources 1298 131: Incorrect interface identifier length 1300 `K' flag: See See [rfc3775]. 1302 Reserved: An unused field. MUST be set to zero. 1304 Sequence Number: Copied from FBU message for use by the MN in 1305 matching this acknowledgment with an outstanding FBU. 1307 Lifetime: The granted lifetime in seconds for which the sender of 1308 this message will retain a binding for traffic redirection. 1310 Mobility Options: MUST contain ``alternate'' CoA if Status is 1. 1311 MUST contain the Binding Authorization Data for FMIP (BADF) 1312 option. See 6.4.5. 1314 6.4. Unsolicited Neighbor Advertisement (UNA) 1316 This is the same message as in [rfc2461] with the requirement that 1317 the 'O' bit is always set to zero. Since this is an unsolicited 1318 message, the 'S' bit is zero, and since this is sent by a MN, the 'R' 1319 bit is also zero. 1321 The Source Address must be the NCoA. The Destination Address is 1322 typically the all-nodes multicast address; however, some deployments 1323 may not prefer transmission to a multicast address. In such cases, 1324 the Destination Address SHOULD be the NAR's IP address. 1326 The Target Address must include the NCoA, and Target link-layer 1327 address must include the MN's LLA. 1329 The MN sends a UNA message to the NAR, as soon as it regains 1330 connectivity on the new link. Arriving or buffered packets can be 1331 immediately forwarded. If NAR is proxying NCoA, it creates a 1332 neighbor cache entry in STALE state but forwards packets as it 1333 determines bidirectional reachability. If there is an entry in 1334 INCOMPLETE state without a link-layer address, it sets it to STALE. 1335 If there is no entry at all, creating an entry in STALE state is 1336 recommended since forwarding can immediately begin when packets 1337 arrive without first invoking Neighbor Solicitation and Advertisement 1338 (which may involve retransmission delay in the event of messages 1339 being lost). During the process of creating a neighbor cache entry, 1340 NAR can also detect if NCoA is in use, and immediately sends a Router 1341 Advertisement with NAACK option in the event of collision. 1343 The combination of NCoA (present in source IP address) and the Link- 1344 Layer Address (present as a Target LLA) SHOULD be used to distinguish 1345 the MN from other nodes. 1347 6.5. New Options 1349 All the options are of the form shown in Figure 10. 1351 The Type values are defined from the Neighbor Discovery options 1352 space. The Length field is in units of 8 octets, except for the 1353 Mobility Header Link-Layer Address option, whose Length field is in 1354 units of octets in accordance with Section 6.2 in [rfc3775]. And, 1355 Option-Code provides additional information for each of the options 1356 (see individual options below). 1358 0 1 2 3 1359 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 1360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1361 | Type | Length | Option-Code | | 1362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1363 ~ ... ~ 1364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1366 Figure 10: Option Format 1368 6.5.1. IP Address/Prefix Option 1370 This option is sent in the Proxy Router Advertisement, the Handover 1371 Initiate, and Handover Acknowledge messages. 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 | Prefix Length | 1377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1378 | Reserved | 1379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1380 | | 1381 + + 1382 | | 1383 + IPv6 Address + 1384 | | 1385 + + 1386 | | 1387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1389 Figure 11: IPv6 Address/Prefix Option 1391 Type: 17 1393 Length: The size of this option in 8 octets including the Type, 1394 Option-Code and Length fields. 1396 Option-Code: 1398 1: Old Care-of Address 1399 2: New Care-of Address 1400 3: NAR's IP address 1401 4: NAR's Prefix, sent in PrRtAdv. The Prefix Length field 1402 contains the number of valid leading bits in the prefix. The 1403 bits in the prefix after the prefix length are reserved and 1404 MUST be initialized to zero by the sender and ignored by the 1405 receiver. 1407 Prefix Length: 8-bit unsigned integer that indicates the length of 1408 the IPv6 Address Prefix. The value ranges from 0 to 128. 1410 Reserved: MUST be set to zero by the sender and MUST be ignored by 1411 the receiver. 1413 IPv6 address: The IP address defined by the Option-Code field. 1415 6.5.2. Link-layer Address (LLA) Option 1417 0 1 2 3 1418 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 1419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1420 | Type | Length | Option-Code | LLA... 1421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1423 Figure 12: Link-Layer Address Option 1425 Type: 19 1427 Length: The size of this option in 8 octets including the Type, 1428 Option-Code and Length fields. 1430 Option-Code: 1432 0: wildcard requesting resolution for all nearby access points 1433 1: Link-layer Address of the New Access Point 1434 2: Link-layer Address of the MN 1435 3: Link-layer Address of the NAR (i.e., Proxied Originator) 1436 4: Link-layer Address of the source of RtSolPr or PrRtAdv 1437 message 1438 5: The access point identified by the LLA belongs to the 1439 current interface of the router 1440 6: No prefix information available for the access point 1441 identified by the LLA 1442 7: No fast handovers support available for the access point 1443 identified by the LLA 1445 LLA: The variable length link-layer address. 1447 The LLA Option does not have a length field for the LLA itself. The 1448 implementations must consult the specific link layer over which the 1449 protocol is run in order to determine the content and length of the 1450 LLA. 1452 Depending on the size of individual LLA option, appropriate padding 1453 MUST be used to ensure that the entire option size is a multiple of 8 1454 octets. 1456 The New Access Point Link Layer address contains the link-layer 1457 address of the access point for which handover is about to be 1458 attempted. This is used in the Router Solicitation for Proxy 1459 Advertisement message. 1461 The MN Link-Layer address option contains the link-layer address of a 1462 MN. It is used in the Handover Initiate message. 1464 The NAR (i.e., Proxied Originator) Link-Layer address option contains 1465 the Link Layer address of the Access Router for which the Proxy 1466 Router Solicitation message refers to. 1468 6.5.3. Mobility Header Link-layer Address (MH-LLA) Option 1470 This option is identical to the LLA option, but is carried in the 1471 Mobility Header messages, e.g., FBU. In the future, other Mobility 1472 Header messages may also make use of this option. The format of the 1473 option is shown in Figure 13. There are no alignment requirements 1474 for this option. 1476 0 1 2 3 1477 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 1478 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1479 | Type | Length | 1480 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1481 | Option-Code | LLA .... 1482 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1484 Figure 13: Mobility Header Link-Layer Address Option 1486 Type: 7 1488 Length: The size of this option in octets not including the Type 1489 and Length fields. 1491 Option-Code: 2 Link-layer Address of the MN 1493 LLA: The variable length link-layer address. 1495 6.5.4. Binding Authorization Data for FMIPv6 (BADF) 1497 This option MUST be present in FBU and FBack messages. The security 1498 association between the MN and the PAR is established by companion 1499 protocols [rfc-ho-send]. This option specifies how to compute and 1500 verify a MAC using the established security association. 1502 The format of this option is shown in Figure 14. 1504 0 1 2 3 1505 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 1506 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1507 | Type | Option Length | 1508 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1509 | SPI | 1510 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1511 | | 1512 + + 1513 | Authenticator | 1514 + + 1515 | | 1516 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1518 Figure 14: Binding Authorization Data for FMIPv6 (BADF) Option 1519 Type: To be assigned by IANA 1521 Option Length: The length of the Authenticator in bytes 1523 SPI: Security Parameter Index. SPI = 0 is reserved for the 1524 Authenticator computed using SEND-based handover keys. 1526 Authenticator: Same as in RFC 3775, with "correspondent" replaced 1527 by PAR's IP address, and Kbm replaced by the shared key between 1528 the MN and the PAR. 1530 The default MAC calculation is done using HMAC_SHA1 with the first 96 1531 bits used for the MAC. Since there is an Option Length field, 1532 implementations can use other algorithms such as HMAC_SHA256 for 1533 instance. 1535 This option MUST be the last Mobility Option present. 1537 6.5.5. Neighbor Advertisement Acknowledgment (NAACK) 1539 0 1 2 3 1540 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 1541 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1542 | Type | Length | Option-Code | Status | 1543 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1544 | Reserved | 1545 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1547 Figure 15: Neighbor Advertisement Acknowledgment Option 1549 Type: 20 1551 Length: 8-bit unsigned integer. Length of the option, in 8 1552 octets. The length is 1 when a new CoA is not supplied. The 1553 length is 3 when a new CoA is present (immediately following the 1554 Reserved field) 1556 Option-Code: 0 1558 Status: 8-bit unsigned integer indicating the disposition of the 1559 Unsolicited Neighbor Advertisement message. The following Status 1560 values are currently defined: 1562 1: NCoA is invalid, perform address configuration 1563 2: NCoA is invalid, use the supplied NCoA. The supplied NCoA 1564 (in the form of an IP Address Option) MUST be present following 1565 the Reserved field. 1566 3: NCoA is invalid, use NAR's IP address as NCoA in FBU 1567 4: PCoA supplied, do not send FBU 1568 128: Link Layer Address unrecognized 1570 Reserved: MUST be set to zero by the sender and MUST be ignored by 1571 the receiver. 1573 The NAR responds to UNA with the NAACK option to notify the MN to use 1574 a different NCoA than the one that the MN has used. If the NAR 1575 proposes a different NCoA, the Router Advertisement MUST use the 1576 source IP address in the UNA message as the destination address, and 1577 use the L2 address present in UNA. The MN MUST use the NCoA if it is 1578 supplied with the NAACK option. If the NAACK indicates that the Link 1579 Layer Address is unrecognized, the MN MUST NOT use the NCoA or the 1580 PCoA and SHOULD start immediately the process of acquiring different 1581 NCoA at the NAR. 1583 In the future, new option types may be defined. 1585 7. Configurable Parameters 1587 +-------------------+---------------+---------------+ 1588 | Parameter Name | Default Value | Definition | 1589 +-------------------+---------------+---------------+ 1590 | RTSOLPR_RETRIES | 3 | Section 6.1.1 | 1591 | MAX_RTSOLPR_RATE | 3 | Section 6.1.1 | 1592 | FBU_RETRIES | 3 | Section 6.3.1 | 1593 | PROXY_ND_LIFETIME | 1.5 seconds | Section 6.2.2 | 1594 | HI_RETRIES | 3 | Section 6.2.1 | 1595 +-------------------+---------------+---------------+ 1597 8. Security Considerations 1599 The following security vulnerabilities are identified, and suggested 1600 solutions mentioned. 1602 Insecure FBU: in this case, packets meant for one address could be 1603 stolen, or redirected to some unsuspecting node. This concern is 1604 the same as that in a MN and Home Agent relationship. 1606 Hence, the PAR MUST ensure that the FBU packet arrived from a node 1607 that legitimately owns the PCoA. The access router and its hosts 1608 may use any available mechanism to establish a security 1609 association which MUST be used to secure FBU. The current version 1610 of this protocol relies on a companion protocol [rfc-ho-send]. to 1611 establish such a security association. Using the shared handover 1612 key from [rfc-ho-send], the Authenticator in BADF option (see 1613 Section 6.5.4) MUST be computed, and the BADF option included in 1614 FBU and FBack messages. 1615 If an access router can ensure that the source IP address in an 1616 arriving packet could only have originated from the node whose 1617 link-layer address is in the router's neighbor cache, then a bogus 1618 node cannot use a victim's IP address for malicious redirection of 1619 traffic. Such an operation is recommended at least on neighbor 1620 discovery messages including the RtSolPr message. 1622 Secure FBU, malicious or inadvertent redirection: in this case, 1623 the FBU is secured, but the target of binding happens to be an 1624 unsuspecting node either due to inadvertent operation or due to 1625 malicious intent. This vulnerability can lead to a MN with 1626 genuine security association with its access router redirecting 1627 traffic to an incorrect address. 1628 However, the target of malicious traffic redirection is limited to 1629 an interface on an access router with which the PAR has a security 1630 association. The PAR MUST verify that the NCoA to which PCoA is 1631 being bound actually belongs to NAR's prefix. In order to do 1632 this, HI and HAck message exchanges are to be used. When NAR 1633 accepts NCoA in HI (with Code = 0), it proxies NCoA so that any 1634 arriving packets are not sent on the link until the MN attaches 1635 and announces itself through UNA. So, any inadvertent or 1636 malicious redirection to a host is avoided. It is still possible 1637 to jam NAR's buffer with redirected traffic. However, since NAR's 1638 handover state corresponding to NCoA has a finite (and short) 1639 lifetime corresponding to a small multiple of anticipated handover 1640 latency, the extent of this vulnerability is arguably small. 1642 Sending FBU from NAR's link: a malicious node may send FBU from 1643 NAR's link providing an unsuspecting node's address as NCoA. This 1644 is similar to base Mobile IP where the MN can provide some other 1645 node's IP address as its CoA to its Home Agent. As in base Mobile 1646 IP, the extent of such a misdelivery can be controlled and 1647 recovery is possible. In addition, it is possible to isolate the 1648 MN if it continues to misbehave. 1650 Apart from the above, the RtSolPr (Section 6.1.1) and PrRtAdv 1651 (Section 6.1.2) messages inherit the weaknesses of Neighbor Discovery 1652 protocol [rfc2461]. Specifically, when its access router is 1653 compromised, the MN's RtSolPr message may be answered by an attacker 1654 that provides a rogue router as the resolution. Should the MN attach 1655 to such a rogue router, its communication can be compromised. 1656 Similarly, a network-initiated PrRtAdv message (see Section 3.3) from 1657 an attacker could cause a MN to handover to a rogue router. Where 1658 these weaknesses are a concern, a solution such as Secure Neighbor 1659 Discovery (SEND) [rfc3971] SHOULD be considered. 1661 The HI and HAck messages between the access routers need to be 1662 secured using a pre-existing security association between the access 1663 routers to ensure at least message integrity and authentication, and 1664 should also include encryption. For this, IPsec ESP [rfc2406] 1665 authentication MUST be used and IPsec ESP encryption SHOULD be used. 1667 9. IANA Considerations 1669 This document defines the following ICMPv6 messages, all of which can 1670 share a single ICMPv6 Type from the registry in 1671 http://www.iana.org/assignments/icmpv6-parameters. 1673 +------+-------------+---------------+ 1674 | Type | Description | Reference | 1675 +------+-------------+---------------+ 1676 | TBD | RtSolPr | Section 6.1.1 | 1677 | TBD | PrRtAdv | Section 6.1.2 | 1678 | TBD | HI | Section 6.2.1 | 1679 | TBD | HAck | Section 6.2.2 | 1680 +------+-------------+---------------+ 1682 The document defines a new Mobility Option which needs Type 1683 assignment from the Mobility Options Type registry at 1684 http://www.iana.org/assignments/mobility-parameters: 1686 1. Binding Authorization Data for FMIPv6 (BADF) option, described 1687 in Section 6.5.4 1689 The document has already received Type assignments for the following 1690 (see [rfc4068]): 1692 The document defines the following Neighbor Discovery [rfc2461] 1693 options which have received Type assignment from IANA. 1695 +---------+-----------------------------------------+---------------+ 1696 | Subtype | Description | Reference | 1697 +---------+-----------------------------------------+---------------+ 1698 | 17 | IP Address/Prefix Option | Section 6.5.1 | 1699 | 19 | Link-layer Address Option | Section 6.5.2 | 1700 | 20 | Neighbor Advertisement Acknowledgment | Section 6.5.5 | 1701 | | Option | | 1702 +---------+-----------------------------------------+---------------+ 1704 The document defines the following Mobility Header messages which 1705 have received Type allocation from the Mobility Header Types registry 1706 at http://www.iana.org/assignments/mobility-parameters: 1708 1. Fast Binding Update, described in Section 6.3.1 1710 2. Fast Binding Acknowledgment, described in Section 6.3.2 1712 The document defines the following Mobility Option which has received 1713 Type assignment from the Mobility Options Type registry at 1714 http://www.iana.org/assignments/mobility-parameters: 1716 1. Mobility Header Link-Layer Address option, described in 1717 Section 6.5.3 1719 10. Acknowledgments 1721 The editor would like to thank all those who have provided feedback 1722 on this specification, and acknowledges the following people: Vijay 1723 Devarapalli, Youn-Hee Han, Emil Ivov, Syam Madanapalli, Suvidh 1724 Mathur, Andre Martin, Javier Martin, Koshiro Mitsuya, Gabriel 1725 Montenegro, Takeshi Ogawa, Sun Peng, YC Peng, Alex Petrescu, Domagoj 1726 Premec, Subba Reddy, K. Raghav, Ranjit Wable and Jonathan Wood. 1727 Behcet Sarikaya and Frank Xia are acknowledged for the feedback on 1728 operation over point-point links. The editor would like to 1729 acknowledge the contribution from James Kempf to improve this 1730 specification. The editor would also like to thank [mipshop] working 1731 group chair Gabriel Montenegro and the erstwhile [mobile ip] working 1732 group chairs Basavaraj Patil and Phil Roberts for providing much 1733 support for this work. 1735 11. References 1736 11.1. Normative References 1738 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1739 Requirement Levels", BCP 14, RFC 2119, March 1997. 1741 [rfc-ho-send] 1742 Kempf, J. and R. Koodli, "Distributing a Symmetric FMIPv6 1743 Handover Key using SEND (work in progress)", 1744 September 2007. 1746 [rfc2406] Kent, S. and R. Atkinson, "IP Encapsulating Security 1747 Payload (ESP)", RFC 2406, November 1998, 1748 . 1750 [rfc2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor 1751 Discovery for IP Version 6 (IPv6)", RFC 2461, 1752 December 1998, . 1754 [rfc2462] Thomson, S. and T. Narten, "IPv6 Stateless Address 1755 Autoconfiguration", RFC 2462, December 1998, 1756 . 1758 [rfc2463] Conta, A. and S. Deering, "Internet Control Message 1759 Protocol (ICMPv6) for the Internet Protocol Version 6 1760 (IPv6) Specification", RFC 2463, December 1998, 1761 . 1763 [rfc3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 1764 in IPv6", RFC 3775, June 2004, 1765 . 1767 11.2. Informative References 1769 [rfc3971] Arkko (Editor), J., Kempf, J., Zill, B., and P. Nikander, 1770 "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005. 1772 [rfc4065] Kempf, J., "Instructions for Seamoby and Experimental 1773 Mobility Protocol IANA Allocations", RFC 4065, June 2004. 1775 [rfc4068] Koodli, R., "Fast Handovers for Mobile IPv6", RFC 4068, 1776 July 2005. 1778 Appendix A. Contributors 1780 This document has its origins in the fast handover design team in the 1781 erstwhile [mobile ip] working group. The members of this design team 1782 in alphabetical order were; Gopal Dommety, Karim El-Malki, Mohammed 1783 Khalil, Charles Perkins, Hesham Soliman, George Tsirtsis and Alper 1784 Yegin. 1786 Appendix B. 1788 In this section, we describe the scenarios involving recovery 1789 operations when a highly improbable random address collision occurs. 1791 1. The MN sends FBU from the previous link which results in 1792 packet forwarding to NCoA. These packets may arrive before the MN 1793 attaches to NAR, and hence the latter may invoke Neighbor 1794 Discovery. In the event that there is another node which already 1795 owns the NCoA, NAR (incorrectly) forwards those packets to such a 1796 node. When the MN arrives on the link, it immediately sends a UNA 1797 message, which allows NAR to detect a collision. NAR responds 1798 with a Router Advertisement with NAACK option, forcing the MN to 1799 either use another NCoA supplied in NAACK or reconfigure a new 1800 one. The MN then sends an FBU following the NCoA configuration. 1801 As a special case, the NCoA may be that of NAR itself, which 1802 allows the MN to send FBU that binds its PCoA to NAR's address. 1803 This recovers from temporary misdelivery of packets. Where this 1804 is a concern, using HI and HAck exchange mitigates the problem by 1805 allowing NAR to proxy the NCoA; such a proxying itself can detect 1806 a collision if an entry already exists in the neighbor cache 1807 entry. 1809 2. The MN sends a UNA message followed by an FBU from the new 1810 link. When NAR processes the UNA message, either there is already 1811 an entry for NCoA or there is no entry. If there is an entry, it 1812 either belongs to the MN itself (e.g., in INCOMPLETE state) or the 1813 entry belongs to another node. These entries can be distinguished 1814 by the LLA; the entry with INCOMPLETE state has no LLA. If the 1815 entry belongs to another node, NAR immediately sends a Router 1816 Advertisement with NAACK option (as above) and the MN immediately 1817 sends a new FBU to PAR with a different NCoA. Hence, the extent 1818 of any misdelivery is minimized. 1819 If there is no existing entry for NCoA but there is another node 1820 which owns NCoA, the scenario is more involved. According to 1821 [rfc2461], the UNA message does not create any entry if there is 1822 none to begin with. However, NAR performs Neighbor Solicitation 1823 when packets arrive from PAR (due to FBU processing). Both the MN 1824 and the rightful owner respond with Neighbor Advertisement (NA), 1825 but the MN's Neighbor Advertisement will have the 'O' bit cleared. 1826 If the MN's NA arrives first, NAR starts forwarding to it, but 1827 redirects those packets once the NA from the rightful owner is 1828 processed. At the time of updating the neighbor cache entry, the 1829 NAR sends a Router Advertisement with NAACK option to the MN (as 1830 above), and the MN immediately sends a new FBU to the PAR. If the 1831 MN's NA arrives after the NA from the rightful owner, NAR 1832 similarly sends a Router Advertisement with NAACK option, and the 1833 MN sends a new FBU to the PAR. In both the cases, the extent of 1834 misdelivery can be controlled and recovery is possible. 1836 Appendix C. Change Log 1838 - LC comments for 4068bis 1840 - RFC4068bis: all the issues in the tracker since the publication 1841 of RFC 4068. (http://www.mip4.org/issues/tracker/mipshop) 1843 The following changes pre-date RFC 4068 publication. So, the section 1844 numbers probably do not match. 1846 - Added IPSec AH reference. 1848 - Changed options format to make use of RFC 2461 options Type 1849 space. Revised IANA Considerations section accordingly. 1851 - Added exponential backoff for retransmissions. Added rate 1852 limiting for RtSolPr message. 1854 - Replaced ``attachment point'' with ``access point'' for 1855 consistency. 1857 - Clarified [AP-ID, AR-Info] in terminology. Clarified use of 1858 Prefix Information Option 1860 - Separated MH-LLA from LLA to future-proof LLA option. 1862 The following changes refer up to version 02 (under mipshop). The 1863 Section numbers refer to version 06 (under mobile ip). 1865 - New ICMPv6 format incorporated. ID Nits conformance. 1867 - Last Call comments incorporated 1869 - Revised the security considerations section in v07 1871 - Refined and added a section on network-initiated handover v07 1872 - Section 3 format change 1874 - Section 4 format change (i.e., no subsections). 1876 - Description in Section 4.4 merged with ``Fast or Erroneous 1877 Movement'' 1879 - Section 4.5 deprecated 1881 - Section 4.6 deprecated 1883 - Revision of some message formats in Section 6 1885 Author's Address 1887 Rajeev Koodli 1888 Nokia Siemens Networks 1889 313 Fairchild Drive 1890 Mountain View, CA 94043 1891 USA 1893 Email: rajeev.koodli@nokia.com 1895 Full Copyright Statement 1897 Copyright (C) The IETF Trust (2007). 1899 This document is subject to the rights, licenses and restrictions 1900 contained in BCP 78, and except as set forth therein, the authors 1901 retain all their rights. 1903 This document and the information contained herein are provided on an 1904 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1905 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1906 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1907 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1908 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1909 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1911 Intellectual Property 1913 The IETF takes no position regarding the validity or scope of any 1914 Intellectual Property Rights or other rights that might be claimed to 1915 pertain to the implementation or use of the technology described in 1916 this document or the extent to which any license under such rights 1917 might or might not be available; nor does it represent that it has 1918 made any independent effort to identify any such rights. Information 1919 on the procedures with respect to rights in RFC documents can be 1920 found in BCP 78 and BCP 79. 1922 Copies of IPR disclosures made to the IETF Secretariat and any 1923 assurances of licenses to be made available, or the result of an 1924 attempt made to obtain a general license or permission for the use of 1925 such proprietary rights by implementers or users of this 1926 specification can be obtained from the IETF on-line IPR repository at 1927 http://www.ietf.org/ipr. 1929 The IETF invites any interested party to bring to its attention any 1930 copyrights, patents or patent applications, or other proprietary 1931 rights that may cover technology that may be required to implement 1932 this standard. Please address the information to the IETF at 1933 ietf-ipr@ietf.org. 1935 Acknowledgment 1937 Funding for the RFC Editor function is provided by the IETF 1938 Administrative Support Activity (IASA).