idnits 2.17.1 draft-ietf-mipshop-fmipv6-rfc4068bis-07.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 2107. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2118. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2125. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2131. 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 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 (April 17, 2008) is 5825 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 1030, but not defined == Missing Reference: 'AR-Info' is mentioned on line 1030, but not defined Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MIPSHOP Working Group Rajeev. Koodli (Editor) 3 Internet-Draft Starent Networks 4 Intended status: Standards Track April 17, 2008 5 Expires: October 19, 2008 7 Mobile IPv6 Fast Handovers 8 draft-ietf-mipshop-fmipv6-rfc4068bis-07.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 October 19, 2008. 35 Abstract 37 Mobile IPv6 enables a Mobile Node to maintain its connectivity to the 38 Internet when moving from one Access Router to another, a process 39 referred to as handover. During handover, there is a period during 40 which the Mobile Node is unable to send or receive packets because of 41 link switching delay and IP protocol operations. This "handover 42 latency" resulting from standard Mobile IPv6 procedures, namely 43 movement detection, new Care of Address configuration, and Binding 44 Update, is often unacceptable to real-time traffic such as Voice over 45 IP. Reducing the handover latency could be beneficial to non-real- 46 time, throughput-sensitive applications as well. This document 47 specifies a protocol to improve handover latency due to Mobile IPv6 48 procedures. This document does not address improving the link 49 switching latency. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 7 56 3.1. Addressing the Handover Latency . . . . . . . . . . . . . 7 57 3.2. Protocol Operation . . . . . . . . . . . . . . . . . . . . 9 58 3.3. Protocol Operation during Network-initiated Handover . . . 12 59 4. Protocol Details . . . . . . . . . . . . . . . . . . . . . . . 12 60 5. Other Considerations . . . . . . . . . . . . . . . . . . . . . 16 61 5.1. Handover Capability Exchange . . . . . . . . . . . . . . . 16 62 5.2. Determining New Care of Address . . . . . . . . . . . . . 17 63 5.3. Prefix Management . . . . . . . . . . . . . . . . . . . . 17 64 5.4. Packet Loss . . . . . . . . . . . . . . . . . . . . . . . 18 65 5.5. DAD Handling . . . . . . . . . . . . . . . . . . . . . . . 18 66 5.6. Fast or Erroneous Movement . . . . . . . . . . . . . . . . 19 67 6. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 20 68 6.1. New Neighborhood Discovery Messages . . . . . . . . . . . 20 69 6.1.1. Router Solicitation for Proxy Advertisement 70 (RtSolPr) . . . . . . . . . . . . . . . . . . . . . . 20 71 6.1.2. Proxy Router Advertisement (PrRtAdv) . . . . . . . . . 22 72 6.2. Inter-Access Router Messages . . . . . . . . . . . . . . . 25 73 6.2.1. Handover Initiate (HI) . . . . . . . . . . . . . . . . 25 74 6.2.2. Handover Acknowledge (HAck) . . . . . . . . . . . . . 27 75 6.3. New Mobility Header Messages . . . . . . . . . . . . . . . 29 76 6.3.1. Fast Binding Update (FBU) . . . . . . . . . . . . . . 29 77 6.3.2. Fast Binding Acknowledgment (FBack) . . . . . . . . . 31 78 6.4. Unsolicited Neighbor Advertisement (UNA) . . . . . . . . . 32 79 6.5. New Options . . . . . . . . . . . . . . . . . . . . . . . 33 80 6.5.1. IP Address/Prefix Option . . . . . . . . . . . . . . . 33 81 6.5.2. Link-layer Address (LLA) Option . . . . . . . . . . . 35 82 6.5.3. Mobility Header Link-layer Address (MH-LLA) Option . . 36 83 6.5.4. Binding Authorization Data for FMIPv6 (BADF) . . . . . 36 84 6.5.5. Neighbor Advertisement Acknowledgment (NAACK) . . . . 37 85 7. Related Protocol and Device Considerations . . . . . . . . . . 38 86 8. Evolution from and Compatibility with RFC 4068 . . . . . . . . 39 87 9. Configurable Parameters . . . . . . . . . . . . . . . . . . . 40 88 10. Security Considerations . . . . . . . . . . . . . . . . . . . 40 89 10.1. Peer Authorization Database Entries when using IKEv2 . . . 42 90 10.2. Security Policy Database Entries . . . . . . . . . . . . . 43 91 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43 92 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 44 93 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 45 94 13.1. Normative References . . . . . . . . . . . . . . . . . . . 45 95 13.2. Informative References . . . . . . . . . . . . . . . . . . 46 97 Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 46 98 Appendix B. Changes Since RFC 4068 . . . . . . . . . . . . . . . 46 99 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 47 100 Intellectual Property and Copyright Statements . . . . . . . . . . 48 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, an 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 This specification is applicable when a mobile node has to perform IP 127 layer operations as a result of handovers. This specification does 128 not address improving the link switching latency. It does not modify 129 or optimize procedures related to signaling with the home agent of a 130 mobile node. Indeed, while targeted for Mobile IPv6, it could be 131 used with any mechanism that allows communication to continue despite 132 movements. Finally, this specification does not address bulk 133 movement of nodes using aggregate prefixes. 135 2. Terminology 137 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 138 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 139 document are to be interpreted as described in RFC 2119 [RFC2119]. 140 The use of the term, "silently ignore" is not defined in RFC 2119. 141 However, the term is used in this document and can be similarly 142 construed. 144 The following terminology and abbreviations are used in this document 145 in addition to those defined in [rfc3775]. The reference handover 146 scenario is illustrated in Figure 1. 148 v +--------------+ 149 +-+ | Previous | < 150 | | ------------ | Access | ------- >-----\ 151 +-+ | Router | < \ 152 MN | (PAR) | \ 153 | +--------------+ +---------------+ 154 | ^ IP | Correspondent | 155 | | Network | Node | 156 V | +---------------+ 157 v / 158 v +--------------+ / 159 +-+ | New | < / 160 | | ------------ | Access | ------- >-----/ 161 +-+ | Router | < 162 MN | (NAR) | 163 +--------------+ 165 Figure 1: Reference Scenario for Handover 167 Mobile Node (MN): A Mobile IPv6 host 169 Access Point (AP): A Layer 2 device connected to an IP subnet that 170 offers wireless connectivity to a MN. An Access Point Identifier 171 (AP-ID) refers the AP's L2 address. Sometimes, AP-ID is also 172 referred to as a Basic Service Set IDentifier (BSSID). 174 Access Router (AR): The MN's default router 176 Previous Access Router (PAR): The MN's default router prior to its 177 handover 179 New Access Router (NAR): The MN's anticipated default router 180 subsequent to its handover 182 Previous CoA (PCoA): The MN's Care of Address valid on PAR's 183 subnet 185 New CoA (NCoA): The MN's Care of Address valid on NAR's subnet 187 Handover: A process of terminating existing connectivity and 188 obtaining new IP connectivity 190 Router Solicitation for Proxy Advertisement (RtSolPr): A message 191 from the MN to the PAR requesting information for a potential 192 handover 193 Proxy Router Advertisement (PrRtAdv): A message from the PAR to 194 the MN that provides information about neighboring links 195 facilitating expedited movement detection. The message can also 196 act as a trigger for network-initiated handover. 198 (AP-ID, AR-Info) tuple: Contains an access router's L2 and IP 199 addresses, and prefix valid on the interface to which the Access 200 Point (identified by AP-ID) is attached. The triplet [Router's L2 201 address, Router's IP address and Prefix] is called "AR-Info". See 202 also Section 5.3. 204 Neighborhood Discovery: The process of resolving neighborhood AP- 205 IDs to AR-Info 207 Assigned Addressing: A particular type of NCoA configuration in 208 which the NAR assigns an IPv6 address for the MN. The method by 209 which NAR manages its address pool is not specified in this 210 document. 212 Fast Binding Update (FBU): A message from the MN instructing its 213 PAR to redirect its traffic (toward NAR) 215 Fast Binding Acknowledgment (FBack): A message from the PAR in 216 response to FBU 218 Predictive Fast Handover: The fast handover in which an MN is able 219 to send FBU when it is attached to the PAR, which then establishes 220 forwarding for its traffic (even before the MN attaches to the 221 NAR) 223 Reactive Fast Handover: The fast handover in which an MN is able 224 to send the FBU only after attaching to the NAR 226 Unsolicited Neighbor Advertisement (UNA): The message in [rfc4861] 227 with 'O' bit cleared 229 Fast Neighbor Advertisement (FNA): This message from RFC4068 230 [rfc4068] is deprecated. The UNA message above is the preferred 231 message in this specification. 233 Handover Initiate (HI): A message from the PAR to the NAR 234 regarding an MN's handover 236 Handover Acknowledge (HAck): A message from the NAR to the PAR as 237 a response to HI 239 3. Protocol Overview 241 3.1. Addressing the Handover Latency 243 The ability to immediately send packets from a new subnet link 244 depends on the "IP connectivity" latency, which in turn depends on 245 the movement detection latency and the new CoA configuration latency. 246 Once an MN is IP-capable on the new subnet link, it can send a 247 Binding Update to its Home Agent and one or more correspondents. 248 Once its correspondents successfully process the Binding Update, 249 which typically involves the Return Routability procedure, the MN can 250 receive packets at the new CoA. So, the ability to receive packets 251 from correspondents directly at its new CoA depends on the Binding 252 Update latency as well as the IP connectivity latency. 254 The protocol enables an MN to quickly detect that it has moved to a 255 new subnet by providing the new access point and the associated 256 subnet prefix information when the MN is still connected to its 257 current subnet (i.e., PAR in Figure 1). For instance, an MN may 258 discover available access points using link-layer specific mechanisms 259 (e.g., a "scan" in WLAN) and then request subnet information 260 corresponding to one or more of those discovered access points. The 261 MN may do this after performing router discovery or at any time while 262 connected to its current router. The result of resolving an 263 identifier associated with an access point is a [AP-ID, AR-Info] 264 tuple, which an MN can use in readily detecting movement: when 265 attachment to an access point with AP-ID takes place, the MN knows 266 the corresponding new router's coordinates including its prefix, IP 267 address and L2 address. The "Router Solicitation for Proxy 268 Advertisement (RtSolPr)" and "Proxy Router Advertisement (PrRtAdv)" 269 messages in Section 6.1 are used for aiding movement detection. 271 Through the RtSolPr and PrRtAdv messages, the MN also formulates a 272 prospective new CoA (NCoA), when it is still present on the PAR's 273 link. Hence, the latency due to new prefix discovery subsequent to 274 handover is eliminated. Furthermore, this prospective address can be 275 used immediately after attaching to the new subnet link (i.e., NAR's 276 link) when the MN has received a "Fast Binding Acknowledgment 277 (FBack)" (see Section 6.3.2) message prior to its movement. In the 278 event it moves without receiving an FBack, the MN can still start 279 using NCoA after announcing its attachment through an unsolicited 280 Neighbor Advertisement message (with the 'O' bit set to zero) message 281 [rfc4861]; NAR responds to to this UNA message in case it wishes to 282 provide a different IP address to use. In this way, NCoA 283 configuration latency is reduced. 285 The information provided in the PrRtAdv message can be used even when 286 DHCP [rfc3315] is used to configure an NCoA on the NAR's link. In 287 this case, the protocol supports forwarding using PCoA, and the MN 288 performs DHCP once it attaches to the NAR's link. The MN still 289 formulates an NCoA for FBU processing; however, it MUST NOT send data 290 packets using the NCoA in the FBU. 292 In order to reduce the Binding Update latency, the protocol specifies 293 a binding between the Previous CoA (PCoA) and NCoA. A MN sends a 294 "Fast Binding Update" (see Section 6.3.1) message to its Previous 295 Access Router to establish this tunnel. When feasible, the MN SHOULD 296 send FBU from PAR's link. Otherwise, the MN should send the FBU 297 immediately after detecting attachment to NAR. An FBU message MUST 298 contain the Binding Authorization Data for FMIPv6 (BADF) option (see 299 Section 6.5.4) in order to ensure that only a legitimate MN that owns 300 the PCoA is able to establish a binding. Subsequent sections 301 describe the protocol mechanics. In any case, the result is that PAR 302 begins tunneling packets arriving for PCoA to NCoA. Such a tunnel 303 remains active until the MN completes the Binding Update with its 304 correspondents. In the opposite direction, the MN SHOULD reverse 305 tunnel packets to PAR, again until it completes Binding Update. And, 306 PAR MUST forward the inner packet in the tunnel to its destination 307 (i.e., to the MN's correspondent). Such a reverse tunnel ensures 308 that packets containing PCoA as source IP address are not dropped due 309 to ingress filtering. Even though the MN is IP-capable on the new 310 link, it cannot use NCoA directly with its correspondents without the 311 correspondents first establishing a binding cache entry (for NCoA). 312 Forwarding support for PCoA is provided through a reverse tunnel 313 between the MN and the PAR. 315 Setting up a tunnel alone does not ensure that the MN receives 316 packets as soon as it is attached to a new subnet link, unless the 317 NAR can detect the MN's presence. A neighbor discovery operation 318 involving a neighbor's address resolution (i.e., Neighbor 319 Solicitation and Neighbor Advertisement) typically results in 320 considerable delay, sometimes lasting multiple seconds. For 321 instance, when arriving packets trigger NAR to send Neighbor 322 Solicitation before the MN attaches, subsequent retransmissions of 323 address resolution are separated by a default period of one second 324 each. In order to circumvent this delay, an MN announces its 325 attachment immediately with an UNA message that allows NAR to forward 326 packets to the MN right away. Through tunnel establishment for PCoA 327 and fast advertisement, the protocol provides expedited forwarding of 328 packets to the MN. 330 The protocol also provides the following important functionalities. 331 The access routers can exchange messages to confirm that a proposed 332 NCoA is acceptable. For instance, when an MN sends an FBU from PAR's 333 link, FBack can be delivered after the NAR considers the NCoA 334 acceptable for use. This is especially useful when addresses are 335 assigned by the access router. The NAR can also rely on its trust 336 relationship with PAR before providing forwarding support for the MN. 337 That is, it may create a forwarding entry for the NCoA subject to 338 "approval" from PAR which it trusts. In addition, buffering for 339 handover traffic at NAR may be desirable. Even though the Neighbor 340 Discovery protocol provides a small buffer (typically one or two 341 packets) for packets awaiting address resolution, this buffer may be 342 inadequate for traffic such as VoIP already in progress. The routers 343 may also wish to maintain a separate buffer for servicing the 344 handover traffic. Finally, the access routers could transfer 345 network-resident contexts, such as access control, QoS, and header 346 compression, in conjunction with handover (although the context 347 transfer process itself is not specified in this document). For all 348 these operations, the protocol provides "Handover Initiate (HI)" and 349 "Handover Acknowledge (HAck)" messages (see Section 6.2). Both of 350 these messages SHOULD be used. The access routers MUST have 351 necessary security association established by means outside the scope 352 of this document. 354 3.2. Protocol Operation 356 The protocol begins when an MN sends an RtSolPr message to its access 357 router to resolve one or more Access Point Identifiers to subnet- 358 specific information. In response, the access router (e.g., PAR in 359 Figure 1) sends a PrRtAdv message containing one or more [AP-ID, AR- 360 Info] tuples. The MN may send a RtSolPr at any convenient time, for 361 instance as a response to some link-specific event (a ``trigger'') or 362 simply after performing router discovery. However, the expectation 363 is that prior to sending RtSolPr, the MN will have discovered the 364 available APs by link-specific methods. The RtSolPr and PrRtAdv 365 messages do not establish any state at the access router; their 366 packet formats are defined in Section 6.1. 368 With the information provided in the PrRtAdv message, the MN 369 formulates a prospective NCoA and sends an FBU message to the PAR. 370 The purpose of FBU is to authorize PAR to bind PCoA to NCoA, so that 371 arriving packets can be tunneled to the new location of the MN. The 372 FBU should be sent from PAR's link whenever feasible. For instance, 373 an internal link-specific trigger could enable FBU transmission from 374 the previous link. 376 When it is not feasible, FBU is sent from the new link. 378 The format and semantics of FBU processing are specified in 379 Section 6.3.1. The FBU message MUST contain the BADF option (see 380 Section 6.5.4) to secure the message. 382 Depending on whether an FBack is received on the previous link (which 383 clearly depends on whether FBU was sent in the first place), there 384 are two modes of operation. 386 1. The MN receives FBack on the previous link. This means that 387 packet tunneling is already in progress by the time the MN 388 handovers to NAR. The MN SHOULD send UNA immediately after 389 attaching to NAR, so that arriving as well as buffered packets can 390 be forwarded to the MN right away. 391 Before sending FBack to MN, PAR can determine whether NCoA is 392 acceptable to NAR through the exchange of HI and HAck messages. 393 When assigned addressing (i.e., addresses are assigned by the 394 router) is used, the proposed NCoA in FBU is carried in HI (from 395 PAR to NAR), and NAR MAY assign the proposed NCoA. Such an 396 assigned NCoA MUST be returned in HAck (from NAR to PAR), and PAR 397 MUST in turn provide the assigned NCoA in FBack. If there is an 398 assigned NCoA returned in FBack, the MN MUST use the assigned 399 address (and not the proposed address in FBU) upon attaching to 400 NAR. 402 2. The MN does not receive the FBack on the previous link because 403 the MN has not sent the FBU or the MN has left the link after 404 sending the FBU (which itself may be lost), but before receiving 405 an FBack. Without receiving an FBack in the latter case, the MN 406 cannot ascertain whether PAR has successfully processed the FBU. 407 Hence, the MN (re)sends the FBU message to PAR immediately after 408 sending the UNA message. If NAR chooses to supply a different IP 409 address to use than the NCoA, it MAY sends a Router Advertisement 410 with "Neighbor Advertisement Acknowledge (NAACK)" option in which 411 it includes an alternate IP address for the MN to use. Detailed 412 UNA processing rules are specified in Section 6.4. 414 The scenario in which an MN sends an FBU and receives an FBack on 415 PAR's link is illustrated in Figure 2. For convenience, this 416 scenario is characterized as "predictive" mode of operation. The 417 scenario in which the MN sends an FBU from NAR's link is illustrated 418 in Figure 3. For convenience, this scenario is characterized as 419 "reactive" mode of operation. Note that the reactive mode also 420 includes the case in which an FBU has been sent from PAR's link but 421 an FBack has not been received yet. The Figure is intended to 422 illustrate that the FBU is forwarded through NAR, but it is processed 423 only by the PAR. 425 MN PAR NAR 426 | | | 427 |------RtSolPr------->| | 428 |<-----PrRtAdv--------| | 429 | | | 430 |------FBU----------->|----------HI--------->| 431 | |<--------HAck---------| 432 | <--FBack---|--FBack---> | 433 | | | 434 disconnect forward | 435 | packets ===============>| 436 | | | 437 | | | 438 connect | | 439 | | | 440 |------------UNA --------------------------->| 441 |<=================================== deliver packets 442 | | 444 Figure 2: Predictive Fast Handover 446 MN PAR NAR 447 | | | 448 |------RtSolPr------->| | 449 |<-----PrRtAdv--------| | 450 | | | 451 disconnect | | 452 | | | 453 | | | 454 connect | | 455 |-------UNA-----------|--------------------->| 456 |-------FBU-----------|---------------------)| 457 | |<-------FBU----------)| 458 | |----------HI--------->| 459 | |<-------HAck--------->| 460 | |(HI/HAck if necessary)| 461 | forward | 462 | packets(including FBAck)=====>| 463 | | | 464 |<=================================== deliver packets 465 | | 467 Figure 3: Reactive Fast Handover 469 Finally, the PrRtAdv message may be sent unsolicited, i.e., without 470 the MN first sending a RtSolPr. This mode is described in 471 Section 3.3. 473 3.3. Protocol Operation during Network-initiated Handover 475 In some wireless technologies, the handover control may reside in the 476 network even though the decision to undergo handover may be mutually 477 arrived at between the MN and the network. In such networks, the PAR 478 can send an unsolicited PrRtAdv containing the link layer address, IP 479 address and subnet prefix of the NAR when the network decides that a 480 handover is imminent. The MN MUST process this PrRtAdv to configure 481 a new care of address on the new subnet, and MUST send an FBU to PAR 482 prior to switching to the new link. After transmitting PrRtAdv, the 483 PAR MUST continue to forward packets to the MN on its current link 484 until the FBU is received. The rest of the operation is the same as 485 that described in Section 3.2. 487 The unsolicited PrRtAdv also allows the network to inform the MN 488 about geographically adjacent subnets without the MN having to 489 explicitly request that information. This can reduce the amount of 490 wireless traffic required for the MN to obtain a neighborhood 491 topology map of links and subnets. Such usage of PrRtAdv is 492 decoupled from the actual handover; see Section 6.1.2. 494 4. Protocol Details 496 All descriptions refer to Figure 1. 498 After discovering one or more nearby access points, the MN sends 499 RtSolPr to PAR in order to resolve access point identifiers to subnet 500 router information. A convenient time to do this is after performing 501 router discovery. However, the MN can send RtSolPr at any time, 502 e.g., when one or more new access points are discovered. The MN can 503 also send RtSolPr more than once during its attachment to PAR. The 504 trigger for sending RtSolPr can originate from a link-specific event, 505 such as the promise of a better signal strength from another access 506 point coupled with fading signal quality with the current access 507 point. Such events, often broadly referred to as "L2 triggers", are 508 outside the scope of this document. Nevertheless, they serve as 509 events that invoke this protocol. For instance, when a "link up" 510 indication is obtained on the new link, protocol messages (e.g., UNA) 511 can be immediately transmitted. Implementations SHOULD make use of 512 such triggers whenever available. 514 The RtSolPr message contains one or more AP-IDs. A wildcard requests 515 all available tuples. 517 As a response to RtSolPr, PAR sends a PrRtAdv message which indicates 518 one of the following possible conditions. 520 1. If the PAR does not have an entry corresponding to the new 521 access point, it MUST respond indicating that the new access point 522 is unknown. The MN MUST stop fast handover protocol operations on 523 the current link. The MN MAY send an FBU from its new link. 525 2. If the new access point is connected to the PAR's current 526 interface (to which MN is attached), the PAR MUST respond with a 527 Code value indicating that the new access point is connected to 528 the current interface, but not send any prefix information. This 529 scenario could arise, for example, when several wireless access 530 points are bridged into a wired network. No further protocol 531 action is necessary. 533 3. If the new access point is known and the PAR has information 534 about it, then the PAR MUST respond indicating that the new access 535 point is known and supply the [AP-ID, AR-Info] tuple. If the new 536 access point is known, but does not support fast handover, the PAR 537 MUST indicate this with Code 3 (see Section 6.1.2). 539 4. If a wildcard is supplied as an identifier for the new access 540 point, the PAR SHOULD supply neighborhood [AP-ID, AR-Info] tuples 541 that are subject to path MTU restrictions (i.e., provide any 'n' 542 tuples without exceeding the link MTU). 544 When further protocol action is necessary, some implementations MAY 545 choose to begin buffering copies of incoming packets at the PAR. If 546 such FIFO buffering is used, the PAR MUST continue forwarding the 547 packets to PCoA (i.e., buffer and forward). While the protocol does 548 not forbid such an implementation support, care must be taken to 549 ensure that the PAR continues forwarding packets to the PCoA (i.e., 550 uses a buffer and forward approach). The PAR SHOULD stop buffering 551 once it begins forwarding packets to the NCoA. 553 The method by which Access Routers exchange information about their 554 neighbors and thereby allow construction of Proxy Router 555 Advertisements with information about neighboring subnets is outside 556 the scope of this document. 558 The RtSolPr and PrRtAdv messages MUST be implemented by an MN and an 559 access router that supports fast handovers. However, when the 560 parameters necessary for the MN to send packets immediately upon 561 attaching to the NAR are supplied by the link layer handover 562 mechanism itself, use of above messages is optional on such links. 564 After a PrRtAdv message is processed, the MN sends an FBU at a time 565 determined by link-specific events, and includes the proposed NCoA. 566 The MN SHOULD send the FBU from PAR's link whenever "anticipation" of 567 handover is feasible. When anticipation is not feasible or when it 568 has not received an FBack, the MN sends an FBU immediately after 569 attaching to NAR's link. In response to the FBU, the PAR establishes 570 a binding between PCoA ("Home Address") and NCoA, and sends the FBack 571 to the MN. Prior to establishing this binding, PAR SHOULD send an HI 572 message to NAR, and receive HAck in response. In order to determine 573 the NAR's address for the HI message, the PAR can perform the longest 574 prefix match of NCoA (in FBU) with the prefix list of neighboring 575 access routers. When the source IP address of the FBU is PCoA, i.e., 576 the FBU is sent from the PAR's link, the HI message MUST have a Code 577 value set to 0; see Section 6.2.1. When the source IP address of the 578 FBU is not PCoA, i.e., the FBU is sent from the NAR's link, the HI 579 message MUST have a Code value of 1; see Section 6.2.1. 581 The HI message contains the PCoA, Link-Layer Address and the NCoA of 582 the MN. In response to processing an HI message with Code 0, the NAR 584 1. determines whether NCoA supplied in the HI message is unique 585 before beginning to defend it. It sends a DAD probe [rfc4862] for 586 NCoA to verify uniqueness. However, in deployments where the 587 probability of address collisions is considered extremely low (and 588 hence not an issue), the parameter DupAddrDetectTransmits (see 589 [rfc4862]) is set to zero on NAR, allowing it to avoid performing 590 DAD on NCoA. The NAR similarly sets DupAddrDetectTransmits to 591 zero in other deployments where DAD is not a concern. Once NCoA 592 is determined to be unique, NAR starts proxying [rfc4861] the 593 address for PROXY_ND_LIFETIME during which the MN is expected to 594 connect to NAR. In case there is already an NCoA present in its 595 data structure (for instance, it has already processed a HI 596 message earlier), NAR MAY verify if the LLA is the same as its own 597 or that of the MN itself. If so, NAR MAY allow the use of NCoA. 599 2. allocates NCoA for the MN when assigned addressing is used, 600 creates a proxy neighbor cache entry and begins defending it. The 601 NAR MAY allocate the NCoA proposed in HI. 603 3. MAY create a host route entry for PCoA (on the interface to 604 which the MN is attaching to) in case NCoA cannot be accepted or 605 assigned. This host route entry SHOULD be implemented such that 606 until the MN's presence is detected, either through explicit 607 announcement by the MN or by other means, arriving packets do not 608 invoke neighbor discovery. The NAR SHOULD also set up a reverse 609 tunnel to the PAR in this case. 611 4. provides the status of the handover request in the Handover 612 Acknowledge (HAck) message to the PAR. 614 When the Code value in HI is 1, NAR MUST skip the above operations. 615 Sending an HI message with Code 1 allows NAR to validate the neighbor 616 cache entry it creates for the MN during UNA processing. That is, 617 NAR can make use of the knowledge that its trusted peer (i.e., PAR) 618 has a trust relationship with the MN. 620 If HAck contains an assigned NCoA, the FBack MUST include it, and the 621 MN MUST use the address provided in the FBack. The PAR MAY send the 622 FBack to the previous link as well to facilitate faster reception in 623 the event that the MN is still present. The result of the FBU and 624 FBack processing is that PAR begins tunneling the MN's packets to 625 NCoA. If the MN does not receive an FBack message even after 626 retransmitting the FBU for FBU_RETRIES, it must assume that fast 627 handover support is not available and stop the protocol operation. 629 As soon as the MN establishes link connectivity with the NAR, it 631 1. sends a UNA message (see Section 6.4). If the MN has not 632 received an FBack by the time UNA is being sent, it SHOULD send an 633 FBU message following the UNA message. 635 2. joins the all-nodes multicast group and the solicited-node 636 multicast group corresponding to the NCoA 638 3. starts a DAD probe for NCoA. See [rfc4862]. 640 When a NAR receives a UNA message, it 642 1. deletes its proxy neighbor cache entry, if it exists, updates 643 the state to STALE [rfc4861], and forwards arriving and buffered 644 packets. 646 2. updates an entry in INCOMPLETE state [rfc4861], if it exists, 647 to STALE and forwards arriving and buffered packets. This would 648 be the case if NAR had previously sent a Neighbor Solicitation 649 which went unanswered perhaps because the MN had not yet attached 650 to the link. 652 The buffer for handover traffic should be linked to this UNA 653 processing. The exact mechanism is implementation dependent. 655 The NAR may choose to provide different IP address other than the 656 NCoA. This is possible if it is proxying the NCoA. In such a case, 657 it 659 1. MAY send a Router Advertisement with the NAACK option in which 660 it includes an alternate IP address for use. This message MUST be 661 sent to the source IP address present in UNA using the same Layer 662 2 address present in UNA. 664 If the MN receives an IP address in the NAACK option, it MUST use it 665 and send an FBU using the new CoA. As a special case, the address 666 supplied in NAACK could be PCoA itself, in which case the MN MUST NOT 667 send any more FBUs. The Status codes for NAACK option are specified 668 in Section 6.5.5. 670 Once the MN has confirmed its NCoA (either through DAD or when 671 provided for by the NAR), it SHOULD send a Neighbor Advertisement 672 message with the 'O' bit set, to the all-nodes multicast address. 673 This message allows MN's neighbors to update their neighbor cache 674 entries. 676 For data forwarding, the PAR tunnels packets using its global IP 677 address valid on the interface to which the MN was attached. The MN 678 reverse tunnels its packets to the same global address of PAR. The 679 tunnel end-point addresses must be configured accordingly. When PAR 680 receives a reverse tunneled packet, it must verify if a secure 681 binding exists for the MN identified by PCoA in the tunneled packet, 682 before forwarding the packet. 684 5. Other Considerations 686 5.1. Handover Capability Exchange 688 The MN expects a PrRtAdv in response to its RtSolPr message. If the 689 MN does not receive a PrRtAdv message even after RTSOLPR_RETRIES, it 690 must assume that PAR does not support the fast handover protocol and 691 stop sending any more RtSolPr messages. 693 Even if an MN's current access router is capable of providing fast 694 handover support, the new access router to which the MN attaches may 695 be incapable of fast handover. This is indicated to the MN during 696 "runtime", through the PrRtAdv message with a Code value of 3 (see 697 Section 6.1.2). 699 5.2. Determining New Care of Address 701 Typically, the MN formulates its prospective NCoA using the 702 information provided in a PrRtAdv message and sends the FBU. The PAR 703 MUST use the NCoA present in the FBU in its HI message. The NAR MUST 704 verify if the NCoA present in HI is already in use. In any case, NAR 705 MUST respond to HI using a HAck, in which it may include another NCoA 706 to use, especially when assigned address configuration is used. If 707 there is a CoA present in HAck, the PAR MUST include it in the FBack 708 message. However, the MN itself does not have to wait on PAR's link 709 for this exchange to take place. It can handover any time after 710 sending the FBU message; sometimes it may be forced to handover 711 without sending the FBU. In any case, it can still confirm using 712 NCoA from NAR's link by sending the UNA message. 714 If a PrRtAdv message carries an NCoA, the MN MUST use it as its 715 prospective NCoA. 717 When DHCP is used, the protocol supports forwarding for PCoA only. 718 In this case, the MN MUST perform DHCP operations once it attaches to 719 the NAR even though it formulates an NCoA for transmitting the FBU. 720 This is indicated in the PrRtAdv message with Code = 5. 722 5.3. Prefix Management 724 As defined in Section 2, the Prefix part of ``AR-Info'' is the prefix 725 valid on the interface to which the AP is attached. This document 726 does not specify how this Prefix is managed, it's length and 727 assignment policies. The protocol operation specified in this 728 document works regardless of these considerations. Often, but not 729 necessarily always, this Prefix may be the aggregate prefix (such as 730 /48) valid on the interface. In some deployments, each MN may have 731 its own per-mobile prefix (such as a /64) used for generating the 732 NCoA. Some point-to-point links may use such a deployment. 734 When per-mobile prefix assignment is used, the ``AR-Info'' advertised 735 in PrRtAdv still includes the (aggregate) prefix valid on the 736 interface to which the target AP is attached, unless the access 737 routers communicate with each other (using HI and HAck messages) to 738 manage per-mobile prefix. The MN still formulates an NCoA using the 739 aggregate prefix. However, an alternate NCoA based on the per-mobile 740 prefix is returned by NAR in the HAck message. This alternate NCoA 741 is provided to the MN in either the FBack message or in the NAACK 742 option. 744 5.4. Packet Loss 746 Handover involves link switching, which may not be exactly co- 747 ordinated with fast handover signaling. Furthermore, the arrival 748 pattern of packets is dependent on many factors, including 749 application characteristics, network queuing behaviors etc. Hence, 750 packets may arrive at NAR before the MN is able to establish its link 751 there. These packets will be lost unless they are buffered by the 752 NAR. Similarly, if the MN attaches to NAR and then sends an FBU 753 message, packets arriving at PAR until FBU is processed will be lost 754 unless they are buffered. This protocol provides an option to 755 indicate request for buffering at the NAR in the HI message. When 756 the PAR requests this feature (for the MN), it SHOULD also provide 757 its own support for buffering. 759 Whereas buffering can enable a smooth handover, the buffer size and 760 the rate at which buffered packets are eventually forwarded are 761 important considerations when providing buffering support. For 762 instance, an application such as Voice over IP typically needs 763 smaller buffers compared to high-resolution streamig video, which has 764 larger packet sizes and higher arrival rates. This specification 765 does not restrict implementations to providing buffering support for 766 any specific application. However, the implementations should 767 recognize that the buffer size requirements are dependent on the 768 application characteristics (including the arrival rate, arrival 769 process, perceived performance loss in the event buffering is not 770 offered, and so on), and arrive at their own policy decisions. 771 Particular attention must be paid to the rate at which buffered 772 packets are forwarded to the MN once attachment is complete. Just as 773 in any network event where a router buffers packets, forwarding 774 buffered packets in a handover at a rate inconsistent with the policy 775 governing the outbound interface can cause performance degradation to 776 the existing sessions and connections. Implementations must take 777 care to prevent such occurances, just as routers do with buffered 778 packets on the Internet. 780 5.5. DAD Handling 782 Duplicate Address Detection (DAD) was defined in [rfc4862] to avoid 783 address duplication on links when stateless address auto- 784 configuration is used. The use of DAD to verify the uniqueness of an 785 IPv6 address configured through stateless auto-configuration adds 786 delays to a handover. The probability of an interface identifier 787 duplication on the same subnet is very low, however it cannot be 788 ignored. Hence, the protocol specified in this document SHOULD only 789 be used in deployments where the probability of such address 790 collisions is extremely low or it is not a concern (because of the 791 address management procedure deployed). The protocol requires the 792 NAR to send a DAD probe before it starts defending NCoA. However, 793 this DAD delay can be turned off by setting DupAddrDetectTransmits to 794 zero on NAR ([rfc4862]). 796 This document specifies messages which can be used to provide 797 duplicate-free addresses but the document does not specify how to 798 create or manage such duplicate-free addresses. In some cases the 799 NAR may already have the knowledge required to assess whether the 800 MN's address is a duplicate or not before the MN moves to the new 801 subnet. For example, in some deployments, the NAR may maintain a 802 pool of duplicate-free addresses in a list for handover purposes. In 803 such cases, the NAR can provide this disposition in the HAck message 804 (see Section 6.2.2) or in the NAACK option (see Section 6.5.5). 806 5.6. Fast or Erroneous Movement 808 Although this specification is for fast handover, the protocol is 809 limited in terms of how fast an MN can move. A special case of fast 810 movement is ping-pong, where an MN moves between the same two access 811 points rapidly. Another instance of the same problem is erroneous 812 movement i.e., the MN receives information prior to a handover that 813 it is moving to a new access point but it either moves to a different 814 one or it aborts movement altogether. All of the above behaviors are 815 usually the result of link layer idiosyncrasies and thus are often 816 resolved at the link layer itself. 818 IP layer mobility, however, introduces its own limits. IP layer 819 handovers should occur at a rate suitable for the MN to update the 820 binding of, at least, its Home Agent and preferably that of every CN 821 with which it is in communication. An MN that moves faster than 822 necessary for this signaling to complete, which may be of the order 823 of few seconds, may start losing packets. The signaling cost over 824 the air interface and in the network may increase significantly, 825 especially in the case of rapid movement between several access 826 routers. To avoid the signaling overhead, the following measures are 827 suggested. 829 An MN returning to the PAR before updating the necessary bindings 830 when present on the NAR MUST send a Fast Binding Update with the Home 831 Address equal to the MN's PCoA and a lifetime of zero to the PAR. 832 The MN should have a security association with the PAR since it 833 performed a fast handover to the NAR. The PAR,up on receiving this 834 Fast Binding Update, will check its set of outgoing (temporary fast 835 handover) tunnels. If it finds a match, it SHOULD terminate that 836 tunnel; i.e., start delivering packets directly to the node instead. 837 In order for PAR to process such an FBU, the lifetime of the security 838 association has to be at least that of the tunnel itself. 840 Temporary tunnels for the purposes of fast handovers should use short 841 lifetimes (of the order of atmost few tens of seconds or less). The 842 lifetime of such tunnels should be enough to allow a MN to update all 843 its active bindings. The default lifetime of the tunnel should be 844 the same as the lifetime value in the FBU message. 846 The effect of erroneous movement is typically limited to the loss of 847 packets since routing can change and the PAR may forward packets 848 toward another router before the MN actually connects to that router. 849 If the MN discovers itself on an unanticipated access router, it 850 SHOULD send a new Fast Binding Update to the PAR. This FBU 851 supersedes the existing binding at PAR and the packets will be 852 redirected to the newly confirmed location of the MN. 854 6. Message Formats 856 All the ICMPv6 messages have a common Type specified in [rfc2463]. 857 The messages are distinguished based on the Subtype field (see 858 below). For all the ICMPv6 messages, the checksum is defined in 859 [rfc2463]. 861 6.1. New Neighborhood Discovery Messages 863 6.1.1. Router Solicitation for Proxy Advertisement (RtSolPr) 865 Mobile Nodes send Router Solicitation for Proxy Advertisement in 866 order to prompt routers for Proxy Router Advertisements. All the 867 link-layer address options have the format defined in Section 6.5.2. 869 0 1 2 3 870 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 871 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 872 | Type | Code | Checksum | 873 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 874 | Subtype | Reserved | Identifier | 875 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 876 | Options ... 877 +-+-+-+-+-+-+-+-+-+-+-+- 879 Figure 4: Router Solicitation for Proxy Advertisement (RtSolPr) 880 Message 882 IP Fields: 884 Source Address: An IP address assigned to the sending interface 886 Destination Address: The address of the Access Router or the 887 all routers multicast address. 889 Hop Limit: 255. See RFC 2461. 891 ICMP Fields: 893 Type: To be assigned by IANA 895 Code: 0 897 Checksum: The ICMPv6 checksum. 899 Subtype: 2 901 Reserved: MUST be set to zero by the sender and ignored by the 902 receiver. 904 Identifier: MUST be set by the sender so that replies can be 905 matched to this Solicitation. 907 Valid Options: 909 Source Link-layer Address: When known, the link-layer address 910 of the sender SHOULD be included using the Link-Layer Address 911 option. See LLA option format below. 913 New Access Point Link-layer Address: The link-layer address or 914 identification of the access point for which the MN requests 915 routing advertisement information. It MUST be included in all 916 RtSolPr messages. More than one such address or identifier can 917 be present. This field can also be a wildcard address. See 918 LLA Option below. 920 Future versions of this protocol may define new option types. 921 Receivers MUST silently ignore any options that they do not recognize 922 and continue processing the rest of the message. 924 Including the source LLA option allows the receiver to record the 925 sender's L2 address so that neighbor discovery can be avoided when 926 the receiver needs to send packets back to the sender (of the RtSolPr 927 message). 929 When a wildcard is used for New Access Point LLA, no other New Access 930 Point LLA options must be present. 932 A Proxy Router Advertisement (PrRtAdv) message should be received by 933 the MN in response to a RtSolPr. If such a message is not received 934 in a timely manner (no less than twice the typical round trip time 935 (RTT) over the access link or 100 milliseconds if RTT is not known), 936 it SHOULD resend the RtSolPr message. Subsequent retransmissions can 937 be up to RTSOLPR_RETRIES, but MUST use an exponential backoff in 938 which the timeout period (i.e., 2xRTT or 100 milliseconds) is doubled 939 prior to each instance of retransmission. If Proxy Router 940 Advertisement is not received by the time the MN disconnects from the 941 PAR, the MN SHOULD send an FBU immediately after configuring a new 942 CoA. 944 When RtSolPr messages are sent more than once, they MUST be rate 945 limited with MAX_RTSOLPR_RATE per second. During each use of a 946 RtSolPr, exponential backoff is used for retransmissions. 948 6.1.2. Proxy Router Advertisement (PrRtAdv) 950 Access routers send Proxy Router Advertisement messages gratuitously 951 if the handover is network-initiated or as a response to a RtSolPr 952 message from an MN, providing the Link-Layer Address, IP address, and 953 subnet prefixes of neighboring routers. All the link-layer address 954 options have the format defined in 6.4.3. 956 0 1 2 3 957 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 958 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 959 | Type | Code | Checksum | 960 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 961 | Subtype | Reserved | Identifier | 962 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 963 | Options ... 964 +-+-+-+-+-+-+-+-+-+-+-+- 966 Figure 5: Proxy Router Advertisement (PrRtAdv) Message 968 IP Fields: 970 Source Address: MUST be the link-local address assigned to the 971 interface from which this message is sent. 973 Destination Address: The Source Address of an invoking Router 974 Solicitation for Proxy Advertisement or the address of the node 975 the Access Router is instructing to handover. 977 Hop Limit: 255. See RFC 2461. 979 ICMP Fields: 981 Type: To be assigned by IANA 983 Code: 0, 1, 2, 3, 4 or 5. See below. 985 Checksum: The ICMPv6 checksum. 987 Subtype: 3 989 Reserved: MUST be set to zero by the sender and ignored by the 990 receiver. 992 Identifier: Copied from Router Solicitation for Proxy 993 Advertisement or set to Zero if unsolicited. 995 Valid Options in the following order: 997 Source Link-layer Address: When known, the link-layer address 998 of the sender SHOULD be included using the Link-Layer Address 999 option. See LLA option format below. 1001 New Access Point Link-layer Address: The link-layer address or 1002 identification of the access point is copied from RtSolPr 1003 message. This option MUST be present. 1005 New Router's Link-layer Address: The link-layer address of the 1006 Access Router for which this message is proxied for. This 1007 option MUST be included when Code is 0 or 1. 1009 New Router's IP Address: The IP address of NAR. This option 1010 MUST be included when Code is 0 or 1. 1012 New Router Prefix Information Option: Specifies the prefix of 1013 the Access Router the message is proxied for and is used for 1014 address auto-configuration. This option MUST be included when 1015 Code is 0 or 1. However, when this prefix is the same as what 1016 is used in the New Router's IP Address option (above), the 1017 Prefix Information option need not be present. 1019 New CoA Option: MAY be present when PrRtAdv is sent 1020 unsolicited. PAR MAY compute new CoA using NAR's prefix 1021 information and the MN's L2 address, or by any other means. 1023 Future versions of this protocol may define new option types. 1024 Receivers MUST silently ignore any options they do not recognize and 1025 continue processing the message. 1027 Currently, Code values 0, 1, 2, 3, 4 and 5 are defined. 1029 A Proxy Router Advertisement with Code 0 means that the MN should use 1030 the [AP-ID, AR-Info] tuple (present in the options above) for 1031 movement detection and NCoA formulation. The Option-Code field in 1032 the New Access Point LLA option in this case is 1 reflecting the LLA 1033 of the access point for which the rest of the options are related. 1034 Multiple tuples may be present. 1036 A Proxy Router Advertisement with Code 1 means that the message is 1037 sent unsolicited. If a New CoA option is present following the New 1038 Router Prefix Information option, the MN MUST use the supplied NCoA 1039 and send FBU immediately or else stand to lose service. This message 1040 acts as a network-initiated handover trigger; see Section 3.3. The 1041 Option-Code field in the New Access Point LLA option (see below) in 1042 this case is 1 reflecting the LLA of the access point for which the 1043 rest of the options are related. 1045 A Proxy Router Advertisement with Code 2 means that no new router 1046 information is present. Each New Access Point LLA option contains an 1047 Option-Code value (described below) that indicates a specific 1048 outcome. 1050 When the Option-Code field in the New Access Point LLA option is 1051 5, handover to that access point does not require a change of CoA. 1052 This would be the case, for instance, when a number of access 1053 points are connected to the same router interface, or when network 1054 based mobility management mechanisms ensure that the specific 1055 mobile node always observes the same prefix regardless of whether 1056 there is a separate router attached to the target access point. 1057 No other options are required in this case. 1059 When the Option-Code field in the New Access Point LLA option is 1060 6, the PAR is not aware of the Prefix Information requested. The 1061 MN SHOULD attempt to send an FBU as soon as it regains 1062 connectivity with the NAR. No other options are required in this 1063 case. 1065 When the Option-Code field in the New Access Point LLA option is 1066 7, it means that the NAR does not support fast handover. The MN 1067 MUST stop fast handover protocol operations. No other options are 1068 required in this case. 1070 A Proxy Router Advertisement with Code 3 means that new router 1071 information is only present for a subset of access points requested. 1072 The Option-Code field values (defined above including a value of 1) 1073 distinguish different outcomes for individual access points. 1075 A Proxy Router Advertisement with Code 4 means that the subnet 1076 information regarding neighboring access points is sent unsolicited, 1077 but the message is not a handover trigger, unlike when the message is 1078 sent with Code 1. Multiple tuples may be present. 1080 A Proxy Router Advertisement with Code 5 means that the MN may use 1081 the new router information present for detecting movement to a new 1082 subnet, but the MN must perform DHCP [rfc3315] upon attaching to the 1083 NAR's link. The PAR and NAR will forward packets to the PCoA of the 1084 MN. The MN must still formulate an NCoA for transmitting FBU (using 1085 the information sent in this message), but that NCoA will not be used 1086 for forwarding packets. 1088 When a wildcard AP identifier is supplied in the RtSolPr message, the 1089 PrRtAdv message should include any 'n' [Access Point Identifier, 1090 Link-layer address option, Prefix Information Option] tuples 1091 corresponding to the PAR's neighborhood. 1093 6.2. Inter-Access Router Messages 1095 6.2.1. Handover Initiate (HI) 1097 The Handover Initiate (HI) is an ICMPv6 message sent by an Access 1098 Router (typically PAR) to another Access Router (typically NAR) to 1099 initiate the process of an MN's handover. 1101 0 1 2 3 1102 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 1103 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1104 | Type | Code | Checksum | 1105 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1106 | Subtype |S|U| Reserved | Identifier | 1107 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1108 | Options ... 1109 +-+-+-+-+-+-+-+-+-+-+-+- 1111 Figure 6: Handover Initiate (HI) Message 1113 IP Fields: 1115 Source Address: The IP address of the PAR 1117 Destination Address: The IP address of the NAR 1119 ICMP Fields: 1121 Type: To be assigned by IANA 1123 Code: 0 or 1. See below 1125 Checksum: The ICMPv6 checksum. 1127 Subtype: 4 1129 'S' flag: Assigned address configuration flag. When set, this 1130 message requests a new CoA to be returned by the destination. 1131 May be set when Code = 0. MUST be 0 when Code = 1. 1133 'U' flag: Buffer flag. When set, the destination SHOULD buffer 1134 any packets toward the node indicated in the options of this 1135 message. Used when Code = 0, SHOULD be set to 0 when Code = 1. 1137 Reserved: MUST be set to zero by the sender and ignored by the 1138 receiver. 1140 Identifier: MUST be set by the sender so replies can be matched 1141 to this message. 1143 Valid Options: 1145 Link-layer address of MN: The link-layer address of the MN that is 1146 undergoing handover to the destination (i.e., NAR). This option 1147 MUST be included so that the destination can recognize the MN. 1149 Previous Care of Address: The IP address used by the MN while 1150 attached to the originating router. This option SHOULD be 1151 included so that a host route can be established if necessary. 1153 New Care of Address: The IP address the MN wishes to use when 1154 connected to the destination. When the `S' bit is set, the NAR 1155 MAY assign this address. 1157 The PAR uses a Code value of 0 when it processes an FBU with PCoA as 1158 source IP address. The PAR uses a Code value of 1 when it processes 1159 an FBU whose source IP address is not PCoA. 1161 If a Handover Acknowledge (HAck) message is not received as a 1162 response in a short time period (no less than twice the typical round 1163 trip time (RTT) between source and destination, or 100 milliseconds 1164 if RTT is not known), the Handover Initiate SHOULD be resent. 1165 Subsequent retransmissions can be up to HI_RETRIES, but MUST use 1166 exponential backoff in which the timeout period (i.e., 2xRTT or 100 1167 milliseconds) is doubled during each instance of retransmission. 1169 6.2.2. Handover Acknowledge (HAck) 1171 The Handover Acknowledgment message is a new ICMPv6 message that MUST 1172 be sent (typically by NAR to PAR) as a reply to the Handover Initiate 1173 message. 1175 0 1 2 3 1176 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 1177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1178 | Type | Code | Checksum | 1179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1180 | Subtype | Reserved | Identifier | 1181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1182 | Options ... 1183 +-+-+-+-+-+-+-+-+-+-+-+- 1185 Figure 7: Handover Acknowledge (HAck) Message 1187 IP Fields: 1189 Source Address: Copied from the destination address of the 1190 Handover Initiate Message to which this message is a response. 1192 Destination Address: Copied from the source address of the 1193 Handover Initiate Message to which this message is a response. 1195 ICMP Fields: 1197 Type: To be assigned by IANA 1199 Code: 1201 0: Handover Accepted, NCoA valid 1202 1: Handover Accepted, NCoA not valid or in use 1203 2: Handover Accepted, NCoA assigned (used in Assigned 1204 addressing) 1205 3: Handover Accepted, use PCoA 1206 4: Message sent unsolicited, usually to trigger a HI message 1207 128: Handover Not Accepted, reason unspecified 1208 129: Administratively prohibited 1209 130: Insufficient resources 1211 Checksum: The ICMPv6 checksum. 1213 Subtype: 5 1215 Reserved: MUST be set to zero by the sender and ignored by the 1216 receiver. 1218 Identifier: Copied from the corresponding field in the Handover 1219 Initiate message to which this message is a response. 1221 Valid Options: 1223 New Care of Address: If the S flag in the Handover Initiate message 1224 is set, this option MUST be used to provide NCoA the MN should use 1225 when connected to this router. This option MAY be included, even 1226 when the 'S' bit is not set, e.g., Code 2 above. 1228 Upon receiving a HI message, the NAR MUST respond with a Handover 1229 Acknowledge message. If the `S' flag is set in the HI message, the 1230 NAR SHOULD include the New Care of Address option and a Code 3. 1232 The NAR MAY provide support for PCoA (instead of accepting or 1233 assigning NCoA), establish a host route entry for PCoA, and set up a 1234 tunnel to the PAR to forward MN's packets sent with PCoA as source IP 1235 address. This host route entry SHOULD be used to forward packets 1236 once the NAR detects that the particular MN is attached to its link. 1237 The NAR indicates forwarding support for PCoA using Code value 3 in 1238 the HAck message. Subsequently, PAR establishes a tunnel to NAR in 1239 order to forward packets arriving for PCoA. 1241 When responding to a HI message containing a Code value 1, the Code 1242 values 1, 2, and 4 in the HAck message are not relevant. 1244 Finally, the new access router can always refuse handover, in which 1245 case it should indicate the reason in one of the available Code 1246 values. 1248 6.3. New Mobility Header Messages 1250 Mobile IPv6 uses a new IPv6 header type called Mobility Header 1251 [rfc3775]. The Fast Binding Update, Fast Binding Acknowledgment and 1252 the (deprecated) Fast Neighbor Advertisement messages use the 1253 Mobility Header. 1255 6.3.1. Fast Binding Update (FBU) 1257 The Fast Binding Update message is identical to the Mobile IPv6 1258 Binding Update (BU) message. However, the processing rules are 1259 slightly different. 1261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1262 | Sequence # | 1263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1264 |A|H|L|K| Reserved | Lifetime | 1265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1266 | | 1267 . . 1268 . Mobility options . 1269 . . 1270 | | 1271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1273 Figure 8: Fast Binding Update (FBU) Message 1275 IP Fields: 1277 Source address: The PCoA or NCoA 1279 Destination Address: The IP address of the Previous Access 1280 Router 1282 `A' flag: MUST be set to one to request that PAR send a Fast 1283 Binding Acknowledgment message. 1285 `H' flag: MUST be set to one. See [rfc3775]. 1287 `L' flag: See [rfc3775]. 1289 `K' flag: See [rfc3775]. 1291 Reserved: This field is unused. MUST be set zero. 1293 Sequence Number: See See [rfc3775]. 1295 Lifetime: The requested time in seconds for which the sender 1296 wishes to have a binding. 1298 Mobility Options: MUST contain an alternate CoA option set to the 1299 NCoA when an FBU is sent from PAR's link. MUST contain the 1300 Binding Authorization Data for FMIP (BADF) option. See 1301 Section 6.5.4. MAY contain the Mobility Header LLA option (see 1302 Section 6.5.3). 1304 The MN sends an FBU message any time after receiving a PrRtAdv 1305 message. If the MN moves prior to receiving a PrRtAdv message, it 1306 SHOULD send an FBU to the PAR after configuring NCoA on the NAR 1307 according to Neighbor Discovery and IPv6 Address Configuration 1308 protocols. When the MN moves without having received a PrRtAdv 1309 message, it cannot transmit a UNA message upon attaching to the NAR's 1310 link. 1312 The source IP address is PCoA when the FBU is sent from PAR's link, 1313 and the source IP address is NCoA when the FBU sent from NAR's link. 1314 When source IP address is PCoA, the MN MUST include the alternate CoA 1315 option set to NCoA. The PAR MUST process the FBU even though the 1316 address in the alternate CoA option is different from that in the 1317 source IP address, and ensure that the address in the alternate CoA 1318 option is used in the New CoA option in the HI message to NAR. 1320 The FBU MUST also include the Home Address Option set to PCoA. An 1321 FBU message MUST be protected so that PAR is able to determine that 1322 the FBU message is sent by an MN that legitimately owns the PCoA. 1324 6.3.2. Fast Binding Acknowledgment (FBack) 1326 The Fast Binding Acknowledgment message is sent by the PAR to 1327 acknowledge receipt of a Fast Binding Update message in which the `A' 1328 bit is set. If PAR sends a HI message to the NAR after processing an 1329 FBU, the FBack message SHOULD NOT be sent to the MN before the PAR 1330 receives a HAck message from the NAR. The PAR MAY send the FBack 1331 immediately in the reactive mode however. The Fast Binding 1332 Acknowledgment MAY also be sent to the MN on the old link. 1334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1335 | Status |K| Reserved | 1336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1337 | Sequence # | Lifetime | 1338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1339 | | 1340 . . 1341 . Mobility options . 1342 . . 1343 | | 1344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1346 Figure 9: Fast Binding Acknowledgment (FBack) Message 1348 IP Fields: 1350 Source address: The IP address of the Previous Access Router 1352 Destination Address: The NCoA, and optionally PCoA 1354 Status: 8-bit unsigned integer indicating the disposition of the 1355 Fast Binding Update. Values of the Status field that are less 1356 than 128 indicate that the Binding Update was accepted by the 1357 receiving node. The following such Status values are currently 1358 defined: 1360 0 Fast Binding Update accepted 1361 1 Fast Binding Update accepted but NCoA is invalid. Use NCoA 1362 supplied in "alternate" CoA 1364 Values of the Status field greater than or equal to 128 indicate 1365 that the Binding Update was rejected by the receiving node. The 1366 following such Status values are currently defined: 1368 128: Reason unspecified 1369 129: Administratively prohibited 1370 130: Insufficient resources 1371 131: Incorrect interface identifier length 1373 `K' flag: See See [rfc3775]. 1375 Reserved: An unused field. MUST be set to zero. 1377 Sequence Number: Copied from FBU message for use by the MN in 1378 matching this acknowledgment with an outstanding FBU. 1380 Lifetime: The granted lifetime in seconds for which the sender of 1381 this message will retain a binding for traffic redirection. 1383 Mobility Options: MUST contain "alternate" CoA if Status is 1. 1384 MUST contain the Binding Authorization Data for FMIP (BADF) 1385 option. See 6.4.5. 1387 6.4. Unsolicited Neighbor Advertisement (UNA) 1389 This is the same message as in [rfc4861] with the requirement that 1390 the 'O' bit is always set to zero. Since this is an unsolicited 1391 message, the 'S' bit is zero, and since this is sent by an MN, the 1392 'R' bit is also zero. 1394 If NAR is proxying the NCoA (as a result of HI and HAck exchange), 1395 then UNA processing has additional steps (see below). If NAR is not 1396 proxying the NCoA (for instance, HI and HAck exchange has not taken 1397 place), then UNA processing follows the same procedure as specified 1398 in [rfc4861]. Implementations MAY retransmit UNA subject to the 1399 specification in [rfc4861] (Section 7.2.6) while noting that the 1400 default RetransTimer value is large for handover purposes. 1402 The Source Address in UNA MUST be the NCoA. The Destination Address 1403 is typically the all-nodes multicast address; however, some 1404 deployments may not prefer transmission to a multicast address. In 1405 such cases, the Destination Address SHOULD be the NAR's IP address. 1407 The Target Address MUST include the NCoA, and Target link-layer 1408 address MUST include the MN's LLA. 1410 The MN sends a UNA message to the NAR, as soon as it regains 1411 connectivity on the new link. Arriving or buffered packets can be 1412 immediately forwarded. If NAR is proxying NCoA, it creates a 1413 neighbor cache entry in STALE state but forwards packets as it 1414 determines bidirectional reachability according to the standard 1415 Neighbor Discovery procedure. If there is an entry in INCOMPLETE 1416 state without a link-layer address, it sets it to STALE, again 1417 according to the procedure in [rfc4861]. 1419 The NAR MAY wish to provide a different IP address to the MN than the 1420 one in UNA message. In such a case, NAR MUST delete the proxy entry 1421 for NCoA and send a Router Advertisement with NAACK option containing 1422 the new IP address. 1424 The combination of NCoA (present in source IP address) and the Link- 1425 Layer Address (present as a Target LLA) SHOULD be used to distinguish 1426 the MN from other nodes. 1428 6.5. New Options 1430 All the options, with the exception of Binding Data Authorization for 1431 FMIPv6 (BADF) discussed in Section 6.5.4, use Type, Length and 1432 Option-Code format shown in Figure 10. 1434 The Type values are defined from the Neighbor Discovery options 1435 space. The Length field is in units of 8 octets, except for the 1436 Mobility Header Link-Layer Address option, whose Length field is in 1437 units of octets in accordance with Section 6.2 in [rfc3775]. And, 1438 Option-Code provides additional information for each of the options 1439 (see individual options below). 1441 0 1 2 3 1442 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 1443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1444 | Type | Length | Option-Code | | 1445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1446 ~ ... ~ 1447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1449 Figure 10: Option Format 1451 6.5.1. IP Address/Prefix Option 1453 This option is sent in the Proxy Router Advertisement, the Handover 1454 Initiate, and Handover Acknowledge messages. 1456 0 1 2 3 1457 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 1458 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1459 | Type | Length | Option-Code | Prefix Length | 1460 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1461 | Reserved | 1462 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1463 | | 1464 + + 1465 | | 1466 + IPv6 Address + 1467 | | 1468 + + 1469 | | 1470 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1472 Figure 11: IPv6 Address/Prefix Option 1474 Type: 17 1476 Length: The size of this option in 8 octets including the Type, 1477 Option-Code and Length fields. 1479 Option-Code: 1481 1: Old Care-of Address 1482 2: New Care-of Address 1483 3: NAR's IP address 1484 4: NAR's Prefix, sent in PrRtAdv. The Prefix Length field 1485 contains the number of valid leading bits in the prefix. The 1486 bits in the prefix after the prefix length are reserved and 1487 MUST be initialized to zero by the sender and ignored by the 1488 receiver. 1490 Prefix Length: 8-bit unsigned integer that indicates the length of 1491 the IPv6 Address Prefix. The value ranges from 0 to 128. 1493 Reserved: MUST be set to zero by the sender and MUST be ignored by 1494 the receiver. 1496 IPv6 address: The IP address defined by the Option-Code field. 1498 6.5.2. Link-layer Address (LLA) Option 1500 0 1 2 3 1501 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 1502 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1503 | Type | Length | Option-Code | LLA... 1504 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1506 Figure 12: Link-Layer Address Option 1508 Type: 19 1510 Length: The size of this option in 8 octets including the Type, 1511 Option-Code and Length fields. 1513 Option-Code: 1515 0: wildcard requesting resolution for all nearby access points 1516 1: Link-layer Address of the New Access Point 1517 2: Link-layer Address of the MN 1518 3: Link-layer Address of the NAR (i.e., Proxied Originator) 1519 4: Link-layer Address of the source of RtSolPr or PrRtAdv 1520 message 1521 5: The access point identified by the LLA belongs to the 1522 current interface of the router 1523 6: No prefix information available for the access point 1524 identified by the LLA 1525 7: No fast handovers support available for the access point 1526 identified by the LLA 1528 LLA: The variable length link-layer address. 1530 The LLA Option does not have a length field for the LLA itself. The 1531 implementations must consult the specific link layer over which the 1532 protocol is run in order to determine the content and length of the 1533 LLA. 1535 Depending on the size of individual LLA option, appropriate padding 1536 MUST be used to ensure that the entire option size is a multiple of 8 1537 octets. 1539 The New Access Point Link Layer address contains the link-layer 1540 address of the access point for which handover is about to be 1541 attempted. This is used in the Router Solicitation for Proxy 1542 Advertisement message. 1544 The MN Link-Layer address option contains the link-layer address of 1545 an MN. It is used in the Handover Initiate message. 1547 The NAR (i.e., Proxied Originator) Link-Layer address option contains 1548 the Link Layer address of the Access Router for which the Proxy 1549 Router Solicitation message refers to. 1551 6.5.3. Mobility Header Link-layer Address (MH-LLA) Option 1553 This option is identical to the LLA option, but is carried in the 1554 Mobility Header messages, e.g., FBU. In the future, other Mobility 1555 Header messages may also make use of this option. The format of the 1556 option is shown in Figure 13. There are no alignment requirements 1557 for this option. 1559 0 1 2 3 1560 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 1561 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1562 | Type | Length | 1563 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1564 | Option-Code | LLA .... 1565 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1567 Figure 13: Mobility Header Link-Layer Address Option 1569 Type: 7 1571 Length: The size of this option in octets not including the Type 1572 and Length fields. 1574 Option-Code: 2 Link-layer Address of the MN 1576 LLA: The variable length link-layer address. 1578 6.5.4. Binding Authorization Data for FMIPv6 (BADF) 1580 This option MUST be present in FBU and FBack messages. The security 1581 association between the MN and the PAR is established by companion 1582 protocols [rfc-ho-send]. This option specifies how to compute and 1583 verify a MAC using the established security association. 1585 The format of this option is shown in Figure 14. 1587 0 1 2 3 1588 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 1589 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1590 | Type | Option Length | 1591 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1592 | SPI | 1593 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1594 | | 1595 + + 1596 | Authenticator | 1597 + + 1598 | | 1599 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1601 Figure 14: Binding Authorization Data for FMIPv6 (BADF) Option 1603 Type: To be assigned by IANA 1605 Option Length: The length of the Authenticator in bytes 1607 SPI: Security Parameter Index. SPI = 0 is reserved for the 1608 Authenticator computed using SEND-based handover keys. 1610 Authenticator: Same as in RFC 3775, with "correspondent" replaced 1611 by PAR's IP address, and Kbm replaced by the shared key between 1612 the MN and the PAR. 1614 The default MAC calculation is done using HMAC_SHA1 with the first 96 1615 bits used for the MAC. Since there is an Option Length field, 1616 implementations can use other algorithms such as HMAC_SHA256 for 1617 instance. 1619 This option MUST be the last Mobility Option present. 1621 6.5.5. Neighbor Advertisement Acknowledgment (NAACK) 1623 0 1 2 3 1624 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 1625 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1626 | Type | Length | Option-Code | Status | 1627 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1628 | Reserved | 1629 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1630 Figure 15: Neighbor Advertisement Acknowledgment Option 1632 Type: 20 1634 Length: 8-bit unsigned integer. Length of the option, in 8 1635 octets. The length is 1 when a new CoA is not supplied. The 1636 length is 3 when a new CoA is present (immediately following the 1637 Reserved field) 1639 Option-Code: 0 1641 Status: 8-bit unsigned integer indicating the disposition of the 1642 Unsolicited Neighbor Advertisement message. The following Status 1643 values are currently defined: 1645 1: NCoA is invalid, perform address configuration 1646 2: NCoA is invalid, use the supplied NCoA. The supplied NCoA 1647 (in the form of an IP Address Option) MUST be present following 1648 the Reserved field. 1649 3: NCoA is invalid, use NAR's IP address as NCoA in FBU 1650 4: PCoA supplied, do not send FBU 1651 128: Link Layer Address unrecognized 1653 Reserved: MUST be set to zero by the sender and MUST be ignored by 1654 the receiver. 1656 The NAR responds to UNA with the NAACK option to notify the MN to use 1657 a different NCoA than the one that the MN has used. If the NAR 1658 proposes a different NCoA, the Router Advertisement MUST use the 1659 source IP address in the UNA message as the destination address, and 1660 use the L2 address present in UNA. The MN MUST use the NCoA if it is 1661 supplied with the NAACK option. If the NAACK indicates that the Link 1662 Layer Address is unrecognized, for instance if the MN uses an LLA 1663 valid on PAR's link but the same LLA is not valid on NAR's link due 1664 to a different access technology, the MN MUST NOT use the NCoA or the 1665 PCoA and SHOULD start immediately the process of acquiring different 1666 NCoA at the NAR. 1668 In the future, new option types may be defined. 1670 7. Related Protocol and Device Considerations 1672 The protocol specified here, as a design principle, introduces no or 1673 minimal changes to related protocols. For example, no changes to the 1674 base Mobile IPv6 protocol are needed in order to implement this 1675 protocol. Similarly, no changes to the IPv6 stateless address 1676 autoconfiguration protocol [rfc4862] and DHCP [rfc3315] are 1677 introduced. The protocol specifies an optional extension to Neighbor 1678 Discovery [rfc4861] in which an access router may send a router 1679 advertisement as a response to the UNA message (see Section 1680 Section 6.4). Other than this extension, the specification does not 1681 modify Neighbor Discovery behavior (including the procedures 1682 performed when attached to the PAR and when attaching to the NAR). 1684 The protocol does not require changes to any intermediate layer 2 1685 device between an MN and its access router which support this 1686 specification. This includes the wireless access points, switches, 1687 snooping devices and so on. 1689 8. Evolution from and Compatibility with RFC 4068 1691 This document has evolved from [rfc4068]. Specifically, a new 1692 handover key establishment protocol (see [rfc-ho-send]) has been 1693 defined to enable a security association between a mobile node and 1694 its access router. This allows secure update of routing of packets 1695 during a handover. In the future, new specifications may be defined 1696 to establish such security associations depending on the particular 1697 deployment scenario. 1699 The protocol has improved from the experiences in implementing 1700 [rfc4068], and from experimental usage. The input has improved the 1701 specification of parameter fields (such as lifetime, codepoints etc.) 1702 as well as inclusion of new parameter fields in the existing 1703 messages. As of this writing, there are two publicly available 1704 implementations [fmipv6], [tarzan] and multiple proprietary 1705 implementations. Some experience suggests that the protocol meets 1706 the delay and packet loss requirements when used appropriately with 1707 particular radio access protocols. For instance, see [l2abs], and 1708 [mip6-book]. Nevertheless, it is important to recognize that 1709 handover performance is a function of both IP layer operations, which 1710 this protocol specifies, and the particular radio access technology 1711 itself, which this protocol relies upon but does not modify. 1713 An existing implementation of [rfc4068] needs to be updated in order 1714 to support this specification. The primary addition is the 1715 establishment of a security association between an MN and its access 1716 router (i.e., MN and PAR). One way to establish such a security 1717 association is specified in [rfc-ho-send]. An implementation that 1718 complies with the specification in this document is likely to also 1719 work with [rfc4068], except for the Binding Authorization Data for 1720 FMIPv6 option (see Section 6.5.4) which can only be processed when 1721 security association is in place between a mobile node and its access 1722 router. This specification deprecates the Fast Neighbor 1723 Advertisement (FNA) message. However, it is acceptable for a NAR to 1724 process this message from a mobile node as specified in [rfc4068]. 1726 9. Configurable Parameters 1728 Mobile nodes rely on configuration parameters shown in the table 1729 below. Each mobile node MUST have a configuration mechanism to 1730 adjust the parameters. Such a configuration mechanism may be either 1731 local (such as a command line interface) or based on central 1732 management of a number of mobile nodes. 1734 +-------------------+---------------+---------------+ 1735 | Parameter Name | Default Value | Definition | 1736 +-------------------+---------------+---------------+ 1737 | RTSOLPR_RETRIES | 3 | Section 6.1.1 | 1738 | MAX_RTSOLPR_RATE | 3 | Section 6.1.1 | 1739 | FBU_RETRIES | 3 | Section 6.3.1 | 1740 | PROXY_ND_LIFETIME | 1.5 seconds | Section 6.2.2 | 1741 | HI_RETRIES | 3 | Section 6.2.1 | 1742 +-------------------+---------------+---------------+ 1744 10. Security Considerations 1746 The following security vulnerabilities are identified, and suggested 1747 solutions are mentioned. 1749 Insecure FBU: in this case, packets meant for one address could be 1750 stolen, or redirected to some unsuspecting node. This concern is 1751 the same as that in an MN and Home Agent relationship. 1752 Hence, the PAR MUST ensure that the FBU packet arrived from a node 1753 that legitimately owns the PCoA. The access router and its hosts 1754 may use any available mechanism to establish a security 1755 association that MUST be used to secure FBU. The current version 1756 of this protocol relies on a companion protocol [rfc-ho-send] to 1757 establish such a security association. Using the shared handover 1758 key from [rfc-ho-send], the Authenticator in BADF option (see 1759 Section 6.5.4) MUST be computed, and the BADF option included in 1760 FBU and FBack messages. 1762 Secure FBU, malicious or inadvertent redirection: in this case, 1763 the FBU is secured, but the target of binding happens to be an 1764 unsuspecting node either due to inadvertent operation or due to 1765 malicious intent. This vulnerability can lead to an MN with a 1766 genuine security association with its access router redirecting 1767 traffic to an incorrect address. 1769 However, the target of malicious traffic redirection is limited to 1770 an interface on an access router with which the PAR has a security 1771 association. The PAR MUST verify that the NCoA to which PCoA is 1772 being bound actually belongs to NAR's prefix. In order to do 1773 this, HI and HAck message exchanges are to be used. When NAR 1774 accepts NCoA in HI (with Code = 0), it proxies NCoA so that any 1775 arriving packets are not sent on the link until the MN attaches 1776 and announces itself through UNA. Therefore, any inadvertent or 1777 malicious redirection to a host is avoided. It is still possible 1778 to jam NAR's buffer with redirected traffic. However, since NAR's 1779 handover state corresponding to NCoA has a finite (and short) 1780 lifetime corresponding to a small multiple of anticipated handover 1781 latency, the extent of this vulnerability is arguably small. 1783 Sending an FBU from NAR's link: A malicious node may send an FBU 1784 from NAR's link providing an unsuspecting node's address as NCoA. 1785 This is similar to base Mobile IP where the MN can provide some 1786 other node's IP address as its CoA to its Home Agent; here the PAR 1787 acts like a "temporary Home Agent" having a security association 1788 with the Mobile Node, and providing forwarding support for the 1789 handover traffic. As in base Mobile IP, this misdelivery is 1790 traceable to the MN which has a security association with the 1791 router. So, it is possible to isolate such an MN if it continues 1792 to misbehave. Similarly, a MN which has a security association 1793 with the PAR may provide the LLA of some other node on NAR's link, 1794 which can cause misdelivery of packets (meant for NCoA) to an 1795 unsuspecting node. It is possible to trace the MN in this case as 1796 well. 1798 Apart from the above, the RtSolPr (Section 6.1.1) and PrRtAdv 1799 (Section 6.1.2) messages inherit the weaknesses of Neighbor Discovery 1800 protocol [rfc4861]. Specifically, when its access router is 1801 compromised, the MN's RtSolPr message may be answered by an attacker 1802 that provides a rogue router as the resolution. Should the MN attach 1803 to such a rogue router, its communication can be compromised. 1804 Similarly, a network-initiated PrRtAdv message (see Section 3.3) from 1805 an attacker could cause an MN to handover to a rogue router. Where 1806 these weaknesses are a concern, a solution such as Secure Neighbor 1807 Discovery (SEND) [rfc3971] SHOULD be considered. 1809 The protocol provides support for buffering packets during an MN's 1810 handover. This is done by securely exchanging the Handover Initiate 1811 (HI) and Handover Acknowledgment (HAck) messages in response to the 1812 FBU message from an MN. It is possible that an MN may fail, either 1813 inadvertantly or purposely, to undergo handover to NAR which 1814 typically provides buffering support. This can cause the NAR to 1815 waste its memory containing the buffered packets, and in the worst 1816 case could create resource exhaustion concerns. Hence, 1817 implementations must limit the size of the buffer as a local policy 1818 configuration which may consider parameters such as the average 1819 handover delay, expected size of packets and so on. 1821 The Handover Initiate (HI) and Handover Acknowledgement (HAck) 1822 messages exchanged between the PAR and NAR MUST be protected using 1823 end-to-end security association(s) offering integrity and data origin 1824 authentication. 1826 The PAR and the NAR MUST implement IPsec [rfc4301] for protecting the 1827 HI and HAck messages. IPsec ESP [rfc4303] in transport mode with 1828 mandatory integrity protection SHOULD be used for protecting the 1829 signaling messages. Confidentiality protection of these messages is 1830 not required. 1832 The security associations can be created by using either manual IPsec 1833 configuration or a dynamic key negotiation protocol such as IKEv2 1834 [rfc4306]. If IKEv2 is used, the PAR and the NAR can use any of the 1835 authentication mechanisms, as specified in RFC 4306, for mutual 1836 authentication. However, to ensure a baseline interoperability, the 1837 implementations MUST support shared secrets for mutual 1838 authentication. The following sections describe the Peer 1839 Authorization Database (PAD) and Security Policy Database (SPD) 1840 entries specified in [rfc4301] when IKEv2 is used for setting up the 1841 required IPsec security associations. 1843 10.1. Peer Authorization Database Entries when using IKEv2 1845 This section describes PAD entries on the PAR and the NAR. The PAD 1846 entries are only example configurations. Note that the PAD is a 1847 logical concept and a particular PAR or NAR implementation can 1848 implement the PAD in any implementation specific manner. The PAD 1849 state may also be distributed across various databases in a specific 1850 implementation. 1852 PAR PAD: 1854 - IF remote_identity = nar_identity_1 1855 THEN authenticate (shared secret/certificate/EAP) and authorize 1856 CHILD_SA for remote address nar_address_1 1858 NAR PAD: 1860 - IF remote_identity = par_identity_1 1861 THEN authenticate (shared secret/certificate/EAP) and authorize 1862 CHILD_SAs for remote address par_address_1 1864 The list of authentication mechanisms in the above examples is not 1865 exhaustive. There could be other credentials used for authentication 1866 stored in the PAD. 1868 10.2. Security Policy Database Entries 1870 This section describes the security policy entries on the PAR and the 1871 NAR required to protect the HI and HAck messages. The SPD entries 1872 are only example configurations. A particular PAR or NAR 1873 implementation could configure different SPD entries as long as they 1874 provide the required security. 1876 In the examples shown below, the identity of the PAR is assumed to be 1877 par_1, the address of the PAR is assumed to be par_address_1, and the 1878 address of the NAR is assumed to be nar_address_1. 1880 PAR SPD-S: 1882 - IF local_address = par_address_1 & remote_address = 1883 nar_address_1 & proto = ICMPv6 & local_icmpv6_type = HI & 1884 remote_icmpv6_type = HAck 1885 THEN use SA ESP transport mode Initiate using IDi = par_1 to 1886 address nar_address_1 1888 NAR SPD-S: 1890 - IF local_address = nar_address_1 & remote_address = 1891 par_address_1 & proto = ICMPv6 & local_icmpv6_type = HAck & 1892 remote_icmpv6_type = HI 1893 THEN use SA ESP transport mode 1895 11. IANA Considerations 1897 This document defines the following ICMPv6 messages, all of which can 1898 share a single ICMPv6 Type from the registry in 1899 http://www.iana.org/assignments/icmpv6-parameters. 1901 +------+-------------+---------------+ 1902 | Type | Description | Reference | 1903 +------+-------------+---------------+ 1904 | TBD | RtSolPr | Section 6.1.1 | 1905 | TBD | PrRtAdv | Section 6.1.2 | 1906 | TBD | HI | Section 6.2.1 | 1907 | TBD | HAck | Section 6.2.2 | 1908 +------+-------------+---------------+ 1910 The document defines a new Mobility Option which needs Type 1911 assignment from the Mobility Options Type registry at 1912 http://www.iana.org/assignments/mobility-parameters: 1914 1. Binding Authorization Data for FMIPv6 (BADF) option, described 1915 in Section 6.5.4 1917 The document has already received Type assignments for the following 1918 (see [rfc4068]): 1920 The document defines the following Neighbor Discovery [rfc4861] 1921 options which have received Type assignment from IANA. 1923 +---------+-----------------------------------------+---------------+ 1924 | Subtype | Description | Reference | 1925 +---------+-----------------------------------------+---------------+ 1926 | 17 | IP Address/Prefix Option | Section 6.5.1 | 1927 | 19 | Link-layer Address Option | Section 6.5.2 | 1928 | 20 | Neighbor Advertisement Acknowledgment | Section 6.5.5 | 1929 | | Option | | 1930 +---------+-----------------------------------------+---------------+ 1932 The document defines the following Mobility Header messages which 1933 have received Type allocation from the Mobility Header Types registry 1934 at http://www.iana.org/assignments/mobility-parameters: 1936 1. Fast Binding Update, described in Section 6.3.1 1938 2. Fast Binding Acknowledgment, described in Section 6.3.2 1940 The document defines the following Mobility Option which has received 1941 Type assignment from the Mobility Options Type registry at 1942 http://www.iana.org/assignments/mobility-parameters: 1944 1. Mobility Header Link-Layer Address option, described in 1945 Section 6.5.3 1947 12. Acknowledgments 1949 The editor would like to thank all those who have provided feedback 1950 on this specification, but can only mention a few here: Vijay 1951 Devarapalli, Youn-Hee Han, Emil Ivov, Syam Madanapalli, Suvidh 1952 Mathur, Andre Martin, Javier Martin, Koshiro Mitsuya, Gabriel 1953 Montenegro, Takeshi Ogawa, Sun Peng, YC Peng, Alex Petrescu, Domagoj 1954 Premec, Subba Reddy, K. Raghav, Ranjit Wable and Jonathan Wood. 1956 Behcet Sarikaya and Frank Xia are acknowledged for the feedback on 1957 operation over point-point links. The editor would like to 1958 acknowledge a contribution from James Kempf to improve this 1959 specification. Vijay Devarapalli provided text for the security 1960 configuration between access routers in Section 10. Thanks to Jari 1961 Arkko for the detailed AD Review which has improved this document. 1962 The editor would also like to thank the [mipshop] working group chair 1963 Gabriel Montenegro and the erstwhile [mobile ip] working group chairs 1964 Basavaraj Patil and Phil Roberts for providing much support for this 1965 work. 1967 13. References 1969 13.1. Normative References 1971 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1972 Requirement Levels", BCP 14, RFC 2119, March 1997. 1974 [rfc-ho-send] 1975 Kempf, J. and R. Koodli, "Distributing a Symmetric FMIPv6 1976 Handover Key using SEND (work in progress)", 1977 September 2007. 1979 [rfc2463] Conta, A. and S. Deering, "Internet Control Message 1980 Protocol (ICMPv6) for the Internet Protocol Version 6 1981 (IPv6) Specification", RFC 2463, December 1998, 1982 . 1984 [rfc3315] Droms (Editor), R., "Dynamic Host Configuration Protocol 1985 for IPv6 (DHCPv6)", RFC 3315, July 2003, 1986 . 1988 [rfc3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 1989 in IPv6", RFC 3775, June 2004, 1990 . 1992 [rfc4301] Kent, S. and K. Seo, "Security Architecture for the 1993 Internet Protocol", RFC 4301, December 2005, 1994 . 1996 [rfc4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 1997 RFC 4303, December 2005, 1998 . 2000 [rfc4306] Kaufman (Editor), C., "Internet Key Exchange (IKEv2) 2001 Protocol", RFC 4306, December 2005, 2002 . 2004 [rfc4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 2005 "Neighbor Discovery for IP Version 6 (IPv6)", RFC 4861, 2006 September 2007, . 2008 [rfc4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 2009 Address Autoconfiguration", RFC 4862, September 2007, 2010 . 2012 13.2. Informative References 2014 [fmipv6] "http://fmipv6.org", . 2016 [l2abs] Teraoka, F., Gogo, K., Mitsuya, K., Shibui, R., and K. 2017 Mitani, "Unified L2 Abstractions for L3-Driven Fast 2018 Handover", , February 2008. 2020 [mip6-book] 2021 Koodli, R. and C. Perkins, "Mobile Internetworking with 2022 IPv6, Chapter 22, John Wiley & Sons.", , July 2007. 2024 [rfc3971] Arkko (Editor), J., Kempf, J., Zill, B., and P. Nikander, 2025 "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005. 2027 [rfc4065] Kempf, J., "Instructions for Seamoby and Experimental 2028 Mobility Protocol IANA Allocations", RFC 4065, June 2004. 2030 [rfc4068] Koodli, R., "Fast Handovers for Mobile IPv6", RFC 4068, 2031 July 2005. 2033 [tarzan] "http://software.nautilus6.org/TARZAN/", . 2035 Appendix A. Contributors 2037 This document has its origins in the fast handover design team in the 2038 erstwhile [mobile ip] working group. The members of this design team 2039 in alphabetical order were; Gopal Dommety, Karim El-Malki, Mohammed 2040 Khalil, Charles Perkins, Hesham Soliman, George Tsirtsis and Alper 2041 Yegin. 2043 Appendix B. Changes Since RFC 4068 2045 Following are the major changes and clarifications: 2047 o Specified security association between the MN and its Access 2048 Router in the companion document [rfc-ho-send]. 2050 o Specified Binding Authorization Data for Fast Handovers (BADF) 2051 option to carry the security parameters used for verifying the 2052 authenticity of FBU and FBack messages. The handover key used for 2053 computing the Authenticator is specified in companion documents. 2055 o Specified the security configuration for inter - access router 2056 signaling (HI, HAck). 2058 o Added a section on prefix management between access routers and 2059 illustrated protocol operation over point-point links. 2061 o Deprecated FNA, which is a Mobility Header message. In its 2062 place, the Unsolicited Neighbor Advertisement (UNA) message from 2063 RFC 4861 is used. 2065 o Combined the IPv6 Address Option and IPv6 Prefix Option. 2067 o Added description of DAD requirement on NAR when determining 2068 NCoA uniqueness - Section 'Protocol Details'. 2070 o Added a new code value for gratuitous HAck message to trigger a 2071 HI message. 2073 o Added Option-Code 5 in PrRtAdv message to indicate NETLMM usage 2075 o Clarified protocol usage when DHCP is used for NCoA formulation 2076 (Sections 6.1.2, 3.1, 5.2). Added a new Code value (5) in PrRtAdv 2077 (Section 6.1.2). 2079 o Clarified that IPv6 Neighbor Discovery operations are a must in 2080 'Related Proto Considerations'. 2082 o Clarified "PAR = temporary HA" for FBUs sent by a genuine MN to 2083 an unsuspecting CoA. 2085 Author's Address 2087 Rajeev Koodli (Editor) 2088 Starent Networks 2089 USA 2091 Email: rkoodli@starentnetworks.com 2093 Full Copyright Statement 2095 Copyright (C) The IETF Trust (2008). 2097 This document is subject to the rights, licenses and restrictions 2098 contained in BCP 78, and except as set forth therein, the authors 2099 retain all their rights. 2101 This document and the information contained herein are provided on an 2102 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2103 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 2104 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 2105 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 2106 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2107 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2109 Intellectual Property 2111 The IETF takes no position regarding the validity or scope of any 2112 Intellectual Property Rights or other rights that might be claimed to 2113 pertain to the implementation or use of the technology described in 2114 this document or the extent to which any license under such rights 2115 might or might not be available; nor does it represent that it has 2116 made any independent effort to identify any such rights. Information 2117 on the procedures with respect to rights in RFC documents can be 2118 found in BCP 78 and BCP 79. 2120 Copies of IPR disclosures made to the IETF Secretariat and any 2121 assurances of licenses to be made available, or the result of an 2122 attempt made to obtain a general license or permission for the use of 2123 such proprietary rights by implementers or users of this 2124 specification can be obtained from the IETF on-line IPR repository at 2125 http://www.ietf.org/ipr. 2127 The IETF invites any interested party to bring to its attention any 2128 copyrights, patents or patent applications, or other proprietary 2129 rights that may cover technology that may be required to implement 2130 this standard. Please address the information to the IETF at 2131 ietf-ipr@ietf.org.