idnits 2.17.1 draft-ietf-mipshop-rfc5268bis-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 : ---------------------------------------------------------------------------- -- The draft header indicates that this document obsoletes RFC5268, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 4, 2009) is 5503 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 1104, but not defined == Missing Reference: 'AR-Info' is mentioned on line 1104, but not defined ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 3775 (Obsoleted by RFC 6275) ** Obsolete normative reference: RFC 4306 (Obsoleted by RFC 5996) -- Obsolete informational reference (is this intentional?): RFC 4068 (Obsoleted by RFC 5268) Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Koodli, Ed. 3 Internet-Draft Starent Networks 4 Obsoletes: 5268 (if approved) March 4, 2009 5 Intended status: Standards Track 6 Expires: September 5, 2009 8 Mobile IPv6 Fast Handovers 9 draft-ietf-mipshop-rfc5268bis-01.txt 11 Status of This Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on September 5, 2009. 34 Copyright Notice 36 Copyright (c) 2009 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents in effect on the date of 41 publication of this document (http://trustee.ietf.org/license-info). 42 Please review these documents carefully, as they describe your rights 43 and restrictions with respect to this document. 45 Abstract 47 Mobile IPv6 enables a Mobile Node (MN) to maintain its connectivity 48 to the Internet when moving from one Access Router to another, a 49 process referred to as handover. During handover, there is a period 50 during which the Mobile Node is unable to send or receive packets 51 because of link switching delay and IP protocol operations. This 52 "handover latency" resulting from standard Mobile IPv6 procedures, 53 namely movement detection, new Care-of Address configuration, and 54 Binding Update, is often unacceptable to real-time traffic such as 55 Voice over IP (VoIP). Reducing the handover latency could be 56 beneficial to non-real-time, throughput-sensitive applications as 57 well. This document specifies a protocol to improve handover latency 58 due to Mobile IPv6 procedures. This document does not address 59 improving the link switching latency. 61 This documents updates the packet formats for the Handover Initiate 62 (HI) and Handover Acknowledgement (HAck) messages to Mobility Header 63 Type. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 69 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 7 70 3.1. Addressing the Handover Latency . . . . . . . . . . . . . 7 71 3.2. Protocol Operation . . . . . . . . . . . . . . . . . . . . 9 72 3.3. Protocol Operation during Network-Initiated Handover . . . 12 73 4. Protocol Details . . . . . . . . . . . . . . . . . . . . . . . 13 74 5. Other Considerations . . . . . . . . . . . . . . . . . . . . . 17 75 5.1. Handover Capability Exchange . . . . . . . . . . . . . . . 17 76 5.2. Determining New Care-of Address . . . . . . . . . . . . . 17 77 5.3. Prefix Management . . . . . . . . . . . . . . . . . . . . 17 78 5.4. Packet Loss . . . . . . . . . . . . . . . . . . . . . . . 18 79 5.5. DAD Handling . . . . . . . . . . . . . . . . . . . . . . . 19 80 5.6. Fast or Erroneous Movement . . . . . . . . . . . . . . . . 20 81 6. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 21 82 6.1. New Neighborhood Discovery Messages . . . . . . . . . . . 21 83 6.1.1. Router Solicitation for Proxy Advertisement 84 (RtSolPr) . . . . . . . . . . . . . . . . . . . . . . 21 85 6.1.2. Proxy Router Advertisement (PrRtAdv) . . . . . . . . . 23 86 6.2. New Mobility Header Messages . . . . . . . . . . . . . . . 26 87 6.2.1. Inter - Access Router Messages . . . . . . . . . . . . 26 88 6.2.2. Fast Binding Update (FBU) . . . . . . . . . . . . . . 30 89 6.2.3. Fast Binding Acknowledgment (FBack) . . . . . . . . . 32 90 6.3. Unsolicited Neighbor Advertisement (UNA) . . . . . . . . . 33 91 6.4. New Options . . . . . . . . . . . . . . . . . . . . . . . 34 92 6.4.1. IP Address/Prefix Option . . . . . . . . . . . . . . . 35 93 6.4.2. Mobility Header IP Address/Prefix Option . . . . . . . 36 94 6.4.3. Link-Layer Address (LLA) Option . . . . . . . . . . . 37 95 6.4.4. Mobility Header Link-Layer Address (MH-LLA) Option . . 38 96 6.4.5. Binding Authorization Data for FMIPv6 (BADF) . . . . . 39 97 6.4.6. Neighbor Advertisement Acknowledgment (NAACK) . . . . 40 98 7. Related Protocol and Device Considerations . . . . . . . . . . 41 99 8. Evolution from and Compatibility with RFC 4068 . . . . . . . . 41 100 9. Configurable Parameters . . . . . . . . . . . . . . . . . . . 42 101 10. Security Considerations . . . . . . . . . . . . . . . . . . . 42 102 10.1. Peer Authorization Database Entries when Using IKEv2 . . . 44 103 10.2. Security Policy Database Entries . . . . . . . . . . . . . 45 104 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 45 105 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 47 106 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 47 107 13.1. Normative References . . . . . . . . . . . . . . . . . . . 47 108 13.2. Informative References . . . . . . . . . . . . . . . . . . 48 109 Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 49 110 Appendix B. Changes since RFC 5268 . . . . . . . . . . . . . . . 49 111 Appendix C. Changes since RFC 4068 . . . . . . . . . . . . . . . 50 113 1. Introduction 115 Mobile IPv6 [RFC3775] describes the protocol operations for a mobile 116 node to maintain connectivity to the Internet during its handover 117 from one access router to another. These operations involve link- 118 layer procedures, movement detection, IP address configuration, and 119 location update. The combined handover latency is often sufficient 120 to affect real-time applications. Throughput-sensitive applications 121 can also benefit from reducing this latency. This document describes 122 a protocol to reduce the handover latency. 124 This specification addresses the following problems: how to allow a 125 mobile node to send packets as soon as it detects a new subnet link 126 and how to deliver packets to a mobile node as soon as its attachment 127 is detected by the new access router. The protocol defines IP 128 protocol messages necessary for its operation regardless of link 129 technology. It does this without depending on specific link-layer 130 features while allowing link-specific customizations. By definition, 131 this specification considers handovers that interwork with Mobile IP. 132 Once attached to its new access router, an MN engages in Mobile IP 133 operations including Return Routability [RFC3775]. There are no 134 special requirements for a mobile node to behave differently with 135 respect to its standard Mobile IP operations. 137 This specification is applicable when a mobile node has to perform IP 138 layer operations as a result of handovers. This specification does 139 not address improving the link switching latency. It does not modify 140 or optimize procedures related to signaling with the home agent of a 141 mobile node. Indeed, while targeted for Mobile IPv6, it could be 142 used with any mechanism that allows communication to continue despite 143 movements. Finally, this specification does not address bulk 144 movement of nodes using aggregate prefixes. 146 This document updates the protocol header format for the Handover 147 Initiate (HI) and Handover Acknowledge (HAck) messages defined in 148 [rfc5268]. Both the Proxy Mobile IPv6 protocol [RFC5213] and the 149 Mobile IPv6 protocol use Mobility Header (MH) as the type for 150 carrying signaling related to route updates. Even though the Fast 151 Handover protocol uses Mobility Header for Mobile Node signaling 152 purposes, it has used ICMP for inter-access router communication. 153 Specifying Mobility Header for the HI and HAck messages enables 154 deployment of the protocol along-side PMIP6 and MIP6 protocols; the 155 reasons that led to this change are captured in Appendix B. Hence, 156 this document specifies the Mobility Header formats for HI and HAck 157 messages (Section 6.2.1) and the Mobility Header option format for 158 the IPv6 Address/Prefix option (Section 6.4.2), and deprecates the 159 use of ICMP for HI and HAck messages. 161 2. Terminology 163 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 164 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 165 document are to be interpreted as described in RFC 2119 [RFC2119]. 166 The use of the term, "silently ignore" is not defined in RFC 2119. 167 However, the term is used in this document and can be similarly 168 construed. 170 The following terminology and abbreviations are used in this document 171 in addition to those defined in [RFC3775]. The reference handover 172 scenario is illustrated in Figure 1. 174 v +--------------+ 175 +-+ | Previous | < 176 | | ------------ | Access | ------- >-----\ 177 +-+ | Router | < \ 178 MN | (PAR) | \ 179 | +--------------+ +---------------+ 180 | ^ IP | Correspondent | 181 | | Network | Node | 182 V | +---------------+ 183 v / 184 v +--------------+ / 185 +-+ | New | < / 186 | | ------------ | Access | ------- >-----/ 187 +-+ | Router | < 188 MN | (NAR) | 189 +--------------+ 191 Figure 1: Reference Scenario for Handover 193 Mobile Node (MN): A Mobile IPv6 host. 195 Access Point (AP): A Layer 2 device connected to an IP subnet that 196 offers wireless connectivity to an MN. An Access Point Identifier 197 (AP-ID) refers the AP's L2 address. Sometimes, AP-ID is also 198 referred to as a Basic Service Set IDentifier (BSSID). 200 Access Router (AR): The MN's default router. 202 Previous Access Router (PAR): The MN's default router prior to its 203 handover. 205 New Access Router (NAR): The MN's anticipated default router 206 subsequent to its handover. 208 Previous CoA (PCoA): The MN's Care-of Address valid on PAR's 209 subnet. 211 New CoA (NCoA): The MN's Care-of Address valid on NAR's subnet. 213 Handover: A process of terminating existing connectivity and 214 obtaining new IP connectivity. 216 Router Solicitation for Proxy Advertisement (RtSolPr): A message 217 from the MN to the PAR requesting information for a potential 218 handover. 220 Proxy Router Advertisement (PrRtAdv): A message from the PAR to 221 the MN that provides information about neighboring links 222 facilitating expedited movement detection. The message can also 223 act as a trigger for network-initiated handover. 225 (AP-ID, AR-Info) tuple: Contains an access router's L2 and IP 226 addresses, and prefix valid on the interface to which the Access 227 Point (identified by AP-ID) is attached. The triplet [Router's L2 228 address, Router's IP address, and Prefix] is called "AR-Info". 229 See also Section 5.3. 231 Neighborhood Discovery: The process of resolving neighborhood AP- 232 IDs to AR-Info. 234 Assigned Addressing: A particular type of NCoA configuration in 235 which the NAR assigns an IPv6 address for the MN. The method by 236 which NAR manages its address pool is not specified in this 237 document. 239 Fast Binding Update (FBU): A message from the MN instructing its 240 PAR to redirect its traffic (toward NAR). 242 Fast Binding Acknowledgment (FBack): A message from the PAR in 243 response to an FBU. 245 Predictive Fast Handover: The fast handover in which an MN is able 246 to send an FBU when it is attached to the PAR, which then 247 establishes forwarding for its traffic (even before the MN 248 attaches to the NAR). 250 Reactive Fast Handover: The fast handover in which an MN is able 251 to send the FBU only after attaching to the NAR. 253 Unsolicited Neighbor Advertisement (UNA): The message in [RFC4861] 254 with 'O' bit cleared. 256 Fast Neighbor Advertisement (FNA): This message from RFC 4068 257 [RFC4068] is deprecated. The UNA message above is the preferred 258 message in this specification. 260 Handover Initiate (HI): A message from the PAR to the NAR 261 regarding an MN's handover. 263 Handover Acknowledge (HAck): A message from the NAR to the PAR as 264 a response to HI. 266 3. Protocol Overview 268 3.1. Addressing the Handover Latency 270 The ability to immediately send packets from a new subnet link 271 depends on the "IP connectivity" latency, which in turn depends on 272 the movement detection latency and the new CoA configuration latency. 273 Once an MN is IP-capable on the new subnet link, it can send a 274 Binding Update to its Home Agent and one or more correspondents. 275 Once its correspondents process the Binding Update successfully, 276 which typically involves the Return Routability procedure, the MN can 277 receive packets at the new CoA. So, the ability to receive packets 278 from correspondents directly at its new CoA depends on the Binding 279 Update latency as well as the IP connectivity latency. 281 The protocol enables an MN to quickly detect that it has moved to a 282 new subnet by providing the new access point and the associated 283 subnet prefix information when the MN is still connected to its 284 current subnet (i.e., PAR in Figure 1). For instance, an MN may 285 discover available access points using link-layer specific mechanisms 286 (e.g., a "scan" in Wireless Local Area Network (WLAN)) and then 287 request subnet information corresponding to one or more of those 288 discovered access points. The MN may do this after performing router 289 discovery or at any time while connected to its current router. The 290 result of resolving an identifier associated with an access point is 291 a [AP-ID, AR-Info] tuple, which an MN can use in readily detecting 292 movement. When attachment to an access point with AP-ID takes place, 293 the MN knows the corresponding new router's coordinates including its 294 prefix, IP address, and L2 address. The "Router Solicitation for 295 Proxy Advertisement (RtSolPr)" and "Proxy Router Advertisement 296 (PrRtAdv)" messages in Section 6.1 are used for aiding movement 297 detection. 299 Through the RtSolPr and PrRtAdv messages, the MN also formulates a 300 prospective new CoA (NCoA) when it is still present on the PAR's 301 link. Hence, the latency due to new prefix discovery subsequent to 302 handover is eliminated. Furthermore, this prospective address can be 303 used immediately after attaching to the new subnet link (i.e., NAR's 304 link) when the MN has received a "Fast Binding Acknowledgment 305 (FBack)" (see Section 6.2.3) message prior to its movement. In the 306 event it moves without receiving an FBack, the MN can still start 307 using NCoA after announcing its attachment through an unsolicited 308 Neighbor Advertisement message (with the 'O' bit set to zero) 309 [RFC4861]; NAR responds to this UNA message in case it wishes to 310 provide a different IP address to use. In this way, NCoA 311 configuration latency is reduced. 313 The information provided in the PrRtAdv message can be used even when 314 DHCP [RFC3315] is used to configure an NCoA on the NAR's link. In 315 this case, the protocol supports forwarding using PCoA, and the MN 316 performs DHCP once it attaches to the NAR's link. The MN still 317 formulates an NCoA for FBU processing; however, it MUST NOT send data 318 packets using the NCoA in the FBU. 320 In order to reduce the Binding Update latency, the protocol specifies 321 a binding between the Previous CoA (PCoA) and NCoA. An MN sends a 322 "Fast Binding Update" (see Section 6.2.2) message to its Previous 323 Access Router to establish this tunnel. When feasible, the MN SHOULD 324 send an FBU from the PAR's link. Otherwise, the MN should send the 325 FBU immediately after detecting attachment to the NAR. An FBU 326 message MUST contain the Binding Authorization Data for FMIPv6 (BADF) 327 option (see Section 6.4.5) in order to ensure that only a legitimate 328 MN that owns the PCoA is able to establish a binding. Subsequent 329 sections describe the protocol mechanics. In any case, the result is 330 that the PAR begins tunneling packets arriving for PCoA to NCoA. 331 Such a tunnel remains active until the MN completes the Binding 332 Update with its correspondents. In the opposite direction, the MN 333 SHOULD reverse tunnel packets to the PAR, again until it completes 334 Binding Update. And, PAR MUST forward the inner packet in the tunnel 335 to its destination (i.e., to the MN's correspondent). Such a reverse 336 tunnel ensures that packets containing a PCoA as a source IP address 337 are not dropped due to ingress filtering. Even though the MN is IP- 338 capable on the new link, it cannot use the NCoA directly with its 339 correspondents without the correspondents first establishing a 340 binding cache entry (for the NCoA). Forwarding support for the PCoA 341 is provided through a reverse tunnel between the MN and the PAR. 343 Setting up a tunnel alone does not ensure that the MN receives 344 packets as soon as it is attached to a new subnet link, unless the 345 NAR can detect the MN's presence. A neighbor discovery operation 346 involving a neighbor's address resolution (i.e., Neighbor 347 Solicitation and Neighbor Advertisement) typically results in 348 considerable delay, sometimes lasting multiple seconds. For 349 instance, when arriving packets trigger the NAR to send Neighbor 350 Solicitation before the MN attaches, subsequent retransmissions of 351 address resolution are separated by a default period of one second 352 each. In order to circumvent this delay, an MN announces its 353 attachment immediately with an UNA message that allows the NAR to 354 forward packets to the MN right away. Through tunnel establishment 355 for PCoA and fast advertisement, the protocol provides expedited 356 forwarding of packets to the MN. 358 The protocol also provides the following important functionalities. 359 The access routers can exchange messages to confirm that a proposed 360 NCoA is acceptable. For instance, when an MN sends an FBU from the 361 PAR's link, FBack can be delivered after the NAR considers the NCoA 362 acceptable for use. This is especially useful when addresses are 363 assigned by the access router. The NAR can also rely on its trust 364 relationship with the PAR before providing forwarding support for the 365 MN. That is, it may create a forwarding entry for the NCoA, subject 366 to "approval" from the PAR, which it trusts. In addition, buffering 367 for handover traffic at the NAR may be desirable. Even though the 368 Neighbor Discovery protocol provides a small buffer (typically one or 369 two packets) for packets awaiting address resolution, this buffer may 370 be inadequate for traffic, such as VoIP, already in progress. The 371 routers may also wish to maintain a separate buffer for servicing the 372 handover traffic. Finally, the access routers could transfer 373 network-resident contexts, such as access control, Quality of Service 374 (QoS), and header compression, in conjunction with handover (although 375 the context transfer process itself is not specified in this 376 document). For all these operations, the protocol provides "Handover 377 Initiate (HI)" and "Handover Acknowledge (HAck)" messages (see 378 Section 6.2.1). Both of these messages SHOULD be used. The access 379 routers MUST have the necessary security association established by 380 means outside the scope of this document. 382 3.2. Protocol Operation 384 The protocol begins when an MN sends an RtSolPr message to its access 385 router to resolve one or more Access Point Identifiers to subnet- 386 specific information. In response, the access router (e.g., PAR in 387 Figure 1) sends a PrRtAdv message containing one or more [AP-ID, AR- 388 Info] tuples. The MN may send an RtSolPr at any convenient time, for 389 instance as a response to some link-specific event (a "trigger") or 390 simply after performing router discovery. However, the expectation 391 is that prior to sending an RtSolPr, the MN will have discovered the 392 available APs by link-specific methods. The RtSolPr and PrRtAdv 393 messages do not establish any state at the access router; their 394 packet formats are defined in Section 6.1. 396 With the information provided in the PrRtAdv message, the MN 397 formulates a prospective NCoA and sends an FBU message to the PAR. 398 The purpose of the FBU is to authorize the PAR to bind the PCoA to 399 the NCoA, so that arriving packets can be tunneled to the new 400 location of the MN. The FBU should be sent from the PAR's link 401 whenever feasible. For instance, an internal link-specific trigger 402 could enable FBU transmission from the previous link. 404 When it is not feasible, the FBU is sent from the new link. 406 The format and semantics of FBU processing are specified in 407 Section 6.2.2. The FBU message MUST contain the BADF option (see 408 Section 6.4.5) to secure the message. 410 Depending on whether an FBack is received on the previous link (which 411 clearly depends on whether the FBU was sent in the first place), 412 there are two modes of operation. 414 1. The MN receives FBack on the previous link. This means that 415 packet tunneling is already in progress by the time the MN 416 handovers to the NAR. The MN SHOULD send the UNA immediately 417 after attaching to the NAR, so that arriving as well as buffered 418 packets can be forwarded to the MN right away. Before sending 419 FBack to the MN, the PAR can determine whether the NCoA is 420 acceptable to the NAR through the exchange of HI and HAck 421 messages. When assigned addressing (i.e., addresses are assigned 422 by the router) is used, the proposed NCoA in the FBU is carried 423 in an HI message (from PAR to NAR), and NAR MAY assign the 424 proposed NCoA. Such an assigned NCoA MUST be returned in HAck 425 (from NAR to PAR), and PAR MUST in turn provide the assigned NCoA 426 in FBack. If there is an assigned NCoA returned in FBack, the MN 427 MUST use the assigned address (and not the proposed address in 428 FBU) upon attaching to NAR. 430 2. The MN does not receive the FBack on the previous link because 431 the MN has not sent the FBU or the MN has left the link after 432 sending the FBU (which itself may be lost), but before receiving 433 an FBack. Without receiving an FBack in the latter case, the MN 434 cannot ascertain whether the PAR has processed the FBU 435 successfully. Hence, the MN (re)sends the FBU message to the PAR 436 immediately after sending the UNA message. If the NAR chooses to 437 supply a different IP address to use than the NCoA, it MAY send a 438 Router Advertisement with "Neighbor Advertisement Acknowledge 439 (NAACK)" option in which it includes an alternate IP address for 440 the MN to use. Detailed UNA processing rules are specified in 441 Section 6.3. 443 The scenario in which an MN sends an FBU and receives an FBack on 444 PAR's link is illustrated in Figure 2. For convenience, this 445 scenario is characterized as the "predictive" mode of operation. The 446 scenario in which the MN sends an FBU from the NAR's link is 447 illustrated in Figure 3. For convenience, this scenario is 448 characterized as the "reactive" mode of operation. Note that the 449 reactive mode also includes the case in which an FBU has been sent 450 from the PAR's link but an FBack has not yet been received. The 451 figure is intended to illustrate that the FBU is forwarded through 452 the NAR, but it is processed only by the PAR. 454 MN PAR NAR 455 | | | 456 |------RtSolPr------->| | 457 |<-----PrRtAdv--------| | 458 | | | 459 |------FBU----------->|----------HI--------->| 460 | |<--------HAck---------| 461 | <--FBack---|--FBack---> | 462 | | | 463 disconnect forward | 464 | packets ===============>| 465 | | | 466 | | | 467 connect | | 468 | | | 469 |------------UNA --------------------------->| 470 |<=================================== deliver packets 471 | | 473 Figure 2: Predictive Fast Handover 475 MN PAR NAR 476 | | | 477 |------RtSolPr------->| | 478 |<-----PrRtAdv--------| | 479 | | | 480 disconnect | | 481 | | | 482 | | | 483 connect | | 484 |-------UNA-----------|--------------------->| 485 |-------FBU-----------|---------------------)| 486 | |<-------FBU----------)| 487 | |----------HI--------->| 488 | |<-------HAck----------| 489 | |(HI/HAck if necessary)| 490 | forward | 491 | packets(including FBAck)=====>| 492 | | | 493 |<=================================== deliver packets 494 | | 496 Figure 3: Reactive Fast Handover 498 Finally, the PrRtAdv message may be sent unsolicited, i.e., without 499 the MN first sending an RtSolPr. This mode is described in 500 Section 3.3. 502 3.3. Protocol Operation during Network-Initiated Handover 504 In some wireless technologies, the handover control may reside in the 505 network even though the decision to undergo handover may be mutually 506 arrived at between the MN and the network. In such networks, the PAR 507 can send an unsolicited PrRtAdv containing the link-layer address, IP 508 address, and subnet prefix of the NAR when the network decides that a 509 handover is imminent. The MN MUST process this PrRtAdv to configure 510 a new Care-of Address on the new subnet, and MUST send an FBU to PAR 511 prior to switching to the new link. After transmitting PrRtAdv, the 512 PAR MUST continue to forward packets to the MN on its current link 513 until the FBU is received. The rest of the operation is the same as 514 that described in Section 3.2. 516 The unsolicited PrRtAdv also allows the network to inform the MN 517 about geographically adjacent subnets without the MN having to 518 explicitly request that information. This can reduce the amount of 519 wireless traffic required for the MN to obtain a neighborhood 520 topology map of links and subnets. Such usage of PrRtAdv is 521 decoupled from the actual handover; see Section 6.1.2. 523 4. Protocol Details 525 All descriptions refer to Figure 1. 527 After discovering one or more nearby access points, the MN sends 528 RtSolPr to the PAR in order to resolve access point identifiers to 529 subnet router information. A convenient time to do this is after 530 performing router discovery. However, the MN can send RtSolPr at any 531 time, e.g., when one or more new access points are discovered. The 532 MN can also send RtSolPr more than once during its attachment to PAR. 533 The trigger for sending RtSolPr can originate from a link-specific 534 event, such as the promise of a better signal strength from another 535 access point coupled with fading signal quality with the current 536 access point. Such events, often broadly referred to as "L2 537 triggers", are outside the scope of this document. Nevertheless, 538 they serve as events that invoke this protocol. For instance, when a 539 "link up" indication is obtained on the new link, protocol messages 540 (e.g., UNA) can be transmitted immediately. Implementations SHOULD 541 make use of such triggers whenever available. 543 The RtSolPr message contains one or more AP-IDs. A wildcard requests 544 all available tuples. 546 As a response to RtSolPr, the PAR sends a PrRtAdv message that 547 indicates one of the following possible conditions. 549 1. If the PAR does not have an entry corresponding to the new access 550 point, it MUST respond indicating that the new access point is 551 unknown. The MN MUST stop fast handover protocol operations on 552 the current link. The MN MAY send an FBU from its new link. 554 2. If the new access point is connected to the PAR's current 555 interface (to which MN is attached), the PAR MUST respond with a 556 Code value indicating that the new access point is connected to 557 the current interface, but not send any prefix information. This 558 scenario could arise, for example, when several wireless access 559 points are bridged into a wired network. No further protocol 560 action is necessary. 562 3. If the new access point is known and the PAR has information 563 about it, then the PAR MUST respond indicating that the new 564 access point is known and supply the [AP-ID, AR-Info] tuple. If 565 the new access point is known, but does not support fast 566 handover, the PAR MUST indicate this with Code 3 (see 567 Section 6.1.2). 569 4. If a wildcard is supplied as an identifier for the new access 570 point, the PAR SHOULD supply neighborhood [AP-ID, AR-Info] tuples 571 that are subject to path MTU restrictions (i.e., provide any 'n' 572 tuples without exceeding the link MTU). 574 When further protocol action is necessary, some implementations MAY 575 choose to begin buffering copies of incoming packets at the PAR. If 576 such First In First Out (FIFO) buffering is used, the PAR MUST 577 continue forwarding the packets to the PCoA (i.e., buffer and 578 forward). While the protocol does not forbid such an implementation 579 support, care must be taken to ensure that the PAR continues 580 forwarding packets to the PCoA (i.e., uses a buffer and forward 581 approach). The PAR SHOULD stop buffering once it begins forwarding 582 packets to the NCoA. 584 The method by which access routers exchange information about their 585 neighbors and thereby allow construction of Proxy Router 586 Advertisements with information about neighboring subnets is outside 587 the scope of this document. 589 The RtSolPr and PrRtAdv messages MUST be implemented by an MN and an 590 access router that supports fast handovers. However, when the 591 parameters necessary for the MN to send packets immediately upon 592 attaching to the NAR are supplied by the link-layer handover 593 mechanism itself, use of the above messages is optional on such 594 links. 596 After a PrRtAdv message is processed, the MN sends an FBU at a time 597 determined by link-specific events, and includes the proposed NCoA. 598 The MN SHOULD send the FBU from the PAR's link whenever 599 "anticipation" of handover is feasible. When anticipation is not 600 feasible or when it has not received an FBack, the MN sends an FBU 601 immediately after attaching to NAR's link. In response to the FBU, 602 the PAR establishes a binding between the PCoA ("Home Address") and 603 the NCoA, and sends the FBack to the MN. Prior to establishing this 604 binding, the PAR SHOULD send an HI message to the NAR, and receive 605 HAck in response. In order to determine the NAR's address for the HI 606 message, the PAR can perform the longest prefix match of NCoA (in 607 FBU) with the prefix list of neighboring access routers. When the 608 source IP address of the FBU is the PCoA, i.e., the FBU is sent from 609 the PAR's link, the HI message MUST have a Code value set to 0; see 610 Section 6.2.1.1. When the source IP address of the FBU is not PCoA, 611 i.e., the FBU is sent from the NAR's link, the HI message MUST have a 612 Code value of 1; see Section 6.2.1.1. 614 The HI message contains the PCoA, link-layer address and the NCoA of 615 the MN. In response to processing an HI message with Code 0, the 616 NAR: 618 1. determines whether the NCoA supplied in the HI message is unique 619 before beginning to defend it. It sends a Duplicate Address 620 Detection (DAD) probe [RFC4862] for NCoA to verify uniqueness. 621 However, in deployments where the probability of address 622 collisions is considered extremely low (and hence not an issue), 623 the parameter DupAddrDetectTransmits (see [RFC4862]) is set to 624 zero on the NAR, allowing it to avoid performing DAD on the NCoA. 625 The NAR similarly sets DupAddrDetectTransmits to zero in other 626 deployments where DAD is not a concern. Once the NCoA is 627 determined to be unique, the NAR starts proxying [RFC4861] the 628 address for PROXY_ND_LIFETIME during which the MN is expected to 629 connect to the NAR. In case there is already an NCoA present in 630 its data structure (for instance, it has already processed an HI 631 message earlier), the NAR MAY verify if the LLA is the same as 632 its own or that of the MN itself. If so, the NAR MAY allow the 633 use of the NCoA. 635 2. allocates the NCoA for the MN when assigned addressing is used, 636 creates a proxy neighbor cache entry and begins defending it. 637 The NAR MAY allocate the NCoA proposed in HI. 639 3. MAY create a host route entry for the PCoA (on the interface to 640 which the MN is attaching to) in case the NCoA cannot be accepted 641 or assigned. This host route entry SHOULD be implemented such 642 that until the MN's presence is detected, either through explicit 643 announcement by the MN or by other means, arriving packets do not 644 invoke neighbor discovery. The NAR SHOULD also set up a reverse 645 tunnel to the PAR in this case. 647 4. provides the status of the handover request in the Handover 648 Acknowledge (HAck) message to the PAR. 650 When the Code value in HI is 1, the NAR MUST skip the above 651 operations. Sending an HI message with Code 1 allows the NAR to 652 validate the neighbor cache entry it creates for the MN during UNA 653 processing. That is, the NAR can make use of the knowledge that its 654 trusted peer (i.e., the PAR) has a trust relationship with the MN. 656 If HAck contains an assigned NCoA, the FBack MUST include it, and the 657 MN MUST use the address provided in the FBack. The PAR MAY send the 658 FBack to the previous link as well to facilitate faster reception in 659 the event that the MN is still present. The result of the FBU and 660 FBack processing is that PAR begins tunneling the MN's packets to the 661 NCoA. If the MN does not receive an FBack message even after 662 retransmitting the FBU for FBU_RETRIES, it must assume that fast 663 handover support is not available and stop the protocol operation. 665 As soon as the MN establishes link connectivity with the NAR, it: 667 1. sends an UNA message (see Section 6.3). If the MN has not 668 received an FBack by the time UNA is being sent, it SHOULD send 669 an FBU message following the UNA message. 671 2. joins the all-nodes multicast group and the solicited-node 672 multicast group corresponding to the NCoA. 674 3. starts a DAD probe for NCoA, see [RFC4862]. 676 When a NAR receives an UNA message, it: 678 1. deletes its proxy neighbor cache entry, if it exists, updates the 679 state to STALE [RFC4861], and forwards arriving and buffered 680 packets. 682 2. updates an entry in INCOMPLETE state [RFC4861], if it exists, to 683 STALE and forwards arriving and buffered packets. This would be 684 the case if NAR had previously sent a Neighbor Solicitation that 685 went unanswered perhaps because the MN had not yet attached to 686 the link. 688 The buffer for handover traffic should be linked to this UNA 689 processing. The exact mechanism is implementation dependent. 691 The NAR may choose to provide a different IP address other than the 692 NCoA. This is possible if it is proxying the NCoA. In such a case, 693 it: 695 1. MAY send a Router Advertisement with the NAACK option in which it 696 includes an alternate IP address for use. This message MUST be 697 sent to the source IP address present in UNA using the same Layer 698 2 address present in UNA. 700 If the MN receives an IP address in the NAACK option, it MUST use it 701 and send an FBU using the new CoA. As a special case, the address 702 supplied in NAACK could be the PCoA itself, in which case the MN MUST 703 NOT send any more FBUs. The Status codes for the NAACK option are 704 specified in Section 6.4.6. 706 Once the MN has confirmed its NCoA (either through DAD or when 707 provided for by the NAR), it SHOULD send a Neighbor Advertisement 708 message with the 'O' bit set, to the all-nodes multicast address. 709 This message allows MN's neighbors to update their neighbor cache 710 entries. 712 For data forwarding, the PAR tunnels packets using its global IP 713 address valid on the interface to which the MN was attached. The MN 714 reverse tunnels its packets to the same global address of PAR. The 715 tunnel end-point addresses must be configured accordingly. When the 716 PAR receives a reverse tunneled packet, it must verify if a secure 717 binding exists for the MN identified by the PCoA in the tunneled 718 packet, before forwarding the packet. 720 5. Other Considerations 722 5.1. Handover Capability Exchange 724 The MN expects a PrRtAdv in response to its RtSolPr message. If the 725 MN does not receive a PrRtAdv message even after RTSOLPR_RETRIES, it 726 must assume that the PAR does not support the fast handover protocol 727 and stop sending any more RtSolPr messages. 729 Even if an MN's current access router is capable of providing fast 730 handover support, the new access router to which the MN attaches may 731 be incapable of fast handover. This is indicated to the MN during 732 "runtime", through the PrRtAdv message with a Code value of 3 (see 733 Section 6.1.2). 735 5.2. Determining New Care-of Address 737 Typically, the MN formulates its prospective NCoA using the 738 information provided in a PrRtAdv message and sends the FBU. The PAR 739 MUST use the NCoA present in the FBU in its HI message. The NAR MUST 740 verify if the NCoA present in HI is already in use. In any case, the 741 NAR MUST respond to HI using a HAck, in which it may include another 742 NCoA to use, especially when assigned address configuration is used. 743 If there is a CoA present in HAck, the PAR MUST include it in the 744 FBack message. However, the MN itself does not have to wait on PAR's 745 link for this exchange to take place. It can handover any time after 746 sending the FBU message; sometimes it may be forced to handover 747 without sending the FBU. In any case, it can still confirm using 748 NCoA from NAR's link by sending the UNA message. 750 If a PrRtAdv message carries an NCoA, the MN MUST use it as its 751 prospective NCoA. 753 When DHCP is used, the protocol supports forwarding for PCoA only. 754 In this case, the MN MUST perform DHCP operations once it attaches to 755 the NAR even though it formulates an NCoA for transmitting the FBU. 756 This is indicated in the PrRtAdv message with Code = 5. 758 5.3. Prefix Management 760 As defined in Section 2, the Prefix part of "AR-Info" is the prefix 761 valid on the interface to which the AP is attached. This document 762 does not specify how this Prefix is managed, it's length and 763 assignment policies. The protocol operation specified in this 764 document works regardless of these considerations. Often, but not 765 necessarily always, this Prefix may be the aggregate prefix (such as 766 /48) valid on the interface. In some deployments, each MN may have 767 its own per-mobile prefix (such as a /64) used for generating the 768 NCoA. Some point-to-point links may use such a deployment. 770 When per-mobile prefix assignment is used, the "AR-Info" advertised 771 in PrRtAdv still includes the (aggregate) prefix valid on the 772 interface to which the target AP is attached, unless the access 773 routers communicate with each other (using HI and HAck messages) to 774 manage the per-mobile prefix. The MN still formulates an NCoA using 775 the aggregate prefix. However, an alternate NCoA based on the per- 776 mobile prefix is returned by NAR in the HAck message. This alternate 777 NCoA is provided to the MN in either the FBack message or in the 778 NAACK option. 780 5.4. Packet Loss 782 Handover involves link switching, which may not be exactly 783 coordinated with fast handover signaling. Furthermore, the arrival 784 pattern of packets is dependent on many factors, including 785 application characteristics, network queuing behaviors, etc. Hence, 786 packets may arrive at the NAR before the MN is able to establish its 787 link there. These packets will be lost unless they are buffered by 788 the NAR. Similarly, if the MN attaches to the NAR and then sends an 789 FBU message, packets arriving at the PAR until the FBU is processed 790 will be lost unless they are buffered. This protocol provides an 791 option to indicate request for buffering at the NAR in the HI 792 message. When the PAR requests this feature (for the MN), it SHOULD 793 also provide its own support for buffering. 795 Whereas buffering can enable a smooth handover, the buffer size and 796 the rate at which buffered packets are eventually forwarded are 797 important considerations when providing buffering support. There are 798 a number of aspects to consider: 800 o Some applications transmit less data over a given period of data 801 than others, and this implies different buffering requirements. 802 For instance, Voice over IP typically needs smaller buffers 803 compared to high-resolution streaming video, as the latter has 804 larger packet sizes and higher arrival rates. 806 o When the mobile node appears on the new link, having the buffering 807 router send a large number of packets in quick succession may 808 overtax the resources of the router, the mobile node itself, or 809 the path between these two. 811 In particular, transmitting a large amount of buffered packets in 812 succession can congest the path between the buffering router and 813 the mobile node. Furthermore, nodes (such as a base station) on 814 the path between the buffering router and the mobile node may drop 815 such packets. If a base station buffers too many such packets, 816 they may contribute to additional jitter for packets arriving 817 behind them, which is undesirable for real-time communication. 819 o Since routers are not involved in end-to-end communication, they 820 have no knowledge of transport conditions. 822 o The wireless connectivity of the mobile node may vary over time. 823 It may achieve a smaller or higher bandwidth on the new link, 824 signal strength may be weak at the time it just enters the area of 825 this access point, and so on. 827 As a result, it is difficult to design an algorithm that would 828 transmit buffered packets at appropriate spacing under all scenarios. 829 The purpose of fast handovers is to avoid packet loss. Yet, draining 830 buffered packets too fast can, by itself, cause loss of the packets, 831 as well as blocking or loss of following packets meant for the mobile 832 node. 834 This specification does not restrict implementations from providing 835 specialized buffering support for any specific situation. However, 836 attention must be paid to the rate at which buffered packets are 837 forwarded to the MN once attachment is complete. Routers 838 implementing this specification MUST implement at least the default 839 algorithm, which is based on the original arrival rates of the 840 buffered packets. A maximum of 5 packets MAY be sent one after 841 another, but all subsequent packets SHOULD use a sending rate that is 842 determined by metering the rate at which packets have entered the 843 buffer, potentially using smoothing techniques such as recent 844 activity over a sliding time window and weighted averages [RFC3290]. 846 It should be noted, however, that this default algorithm is crude and 847 may not be suitable for all situations. Future revisions of this 848 specification may provide additional algorithms, once enough 849 experience of the various conditions in deployed networks is 850 attained. 852 5.5. DAD Handling 854 Duplicate Address Detection (DAD) was defined in [RFC4862] to avoid 855 address duplication on links when stateless address auto- 856 configuration is used. The use of DAD to verify the uniqueness of an 857 IPv6 address configured through stateless auto-configuration adds 858 delays to a handover. The probability of an interface identifier 859 duplication on the same subnet is very low; however, it cannot be 860 ignored. Hence, the protocol specified in this document SHOULD only 861 be used in deployments where the probability of such address 862 collisions is extremely low or it is not a concern (because of the 863 address management procedure deployed). The protocol requires the 864 NAR to send a DAD probe before it starts defending the NCoA. 865 However, this DAD delay can be turned off by setting 866 DupAddrDetectTransmits to zero on the NAR ([RFC4862]). 868 This document specifies messages that can be used to provide 869 duplicate-free addresses, but the document does not specify how to 870 create or manage such duplicate-free addresses. In some cases, the 871 NAR may already have the knowledge required to assess whether or not 872 the MN's address is a duplicate before the MN moves to the new 873 subnet. For example, in some deployments, the NAR may maintain a 874 pool of duplicate-free addresses in a list for handover purposes. In 875 such cases, the NAR can provide this disposition in the HAck message 876 (see Section 6.2.1.2) or in the NAACK option (see Section 6.4.6). 878 5.6. Fast or Erroneous Movement 880 Although this specification is for fast handover, the protocol is 881 limited in terms of how fast an MN can move. A special case of fast 882 movement is ping-pong, where an MN moves between the same two access 883 points rapidly. Another instance of the same problem is erroneous 884 movement, i.e., the MN receives information prior to a handover that 885 it is moving to a new access point but it either moves to a different 886 one or it aborts movement altogether. All of the above behaviors are 887 usually the result of link-layer idiosyncrasies and thus are often 888 resolved at the link layer itself. 890 IP layer mobility, however, introduces its own limits. IP layer 891 handovers should occur at a rate suitable for the MN to update the 892 binding of, at least, its Home Agent and preferably that of every CN 893 with which it is in communication. An MN that moves faster than 894 necessary for this signaling to complete, which may be of the order 895 of few seconds, may start losing packets. The signaling cost over 896 the air interface and in the network may increase significantly, 897 especially in the case of rapid movement between several access 898 routers. To avoid the signaling overhead, the following measures are 899 suggested. 901 An MN returning to the PAR before updating the necessary bindings 902 when present on the NAR MUST send a Fast Binding Update with the Home 903 Address equal to the MN's PCoA and a lifetime of zero to the PAR. 904 The MN should have a security association with the PAR since it 905 performed a fast handover to the NAR. The PAR, upon receiving this 906 Fast Binding Update, will check its set of outgoing (temporary fast 907 handover) tunnels. If it finds a match, it SHOULD terminate that 908 tunnel; i.e., start delivering packets directly to the node instead. 909 In order for the PAR to process such an FBU, the lifetime of the 910 security association has to be at least that of the tunnel itself. 912 Temporary tunnels for the purposes of fast handovers should use short 913 lifetimes (of the order of at most a few tens of seconds or less). 914 The lifetime of such tunnels should be enough to allow an MN to 915 update all its active bindings. The default lifetime of the tunnel 916 should be the same as the lifetime value in the FBU message. 918 The effect of erroneous movement is typically limited to the loss of 919 packets since routing can change and the PAR may forward packets 920 toward another router before the MN actually connects to that router. 921 If the MN discovers itself on an unanticipated access router, it 922 SHOULD send a new Fast Binding Update to the PAR. This FBU 923 supersedes the existing binding at the PAR, and the packets will be 924 redirected to the newly confirmed location of the MN. 926 6. Message Formats 928 All the ICMPv6 messages have a common Type specified in [RFC4443]. 929 The messages are distinguished based on the Subtype field (see 930 below). For all the ICMPv6 messages, the checksum is defined in 931 [RFC4443]. 933 6.1. New Neighborhood Discovery Messages 935 6.1.1. Router Solicitation for Proxy Advertisement (RtSolPr) 937 Mobile Nodes send Router Solicitation for Proxy Advertisement in 938 order to prompt routers for Proxy Router Advertisements. All the 939 Link-Layer Address options have the format defined in Section 6.4.3. 941 0 1 2 3 942 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 943 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 944 | Type | Code | Checksum | 945 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 946 | Subtype | Reserved | Identifier | 947 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 948 | Options ... 949 +-+-+-+-+-+-+-+-+-+-+-+- 951 Figure 4: Router Solicitation for Proxy Advertisement (RtSolPr) 952 Message 954 IP Fields: 956 Source Address: An IP address assigned to the sending 957 interface. 959 Destination Address: The address of the access router or the 960 all routers multicast address. 962 Hop Limit: 255. See RFC 2461. 964 ICMP Fields: 966 Type: 154 968 Code: 0 970 Checksum: The ICMPv6 checksum. 972 Subtype: 2 974 Reserved: MUST be set to zero by the sender and ignored by the 975 receiver. 977 Identifier: MUST be set by the sender so that replies can be 978 matched to this Solicitation. 980 Valid Options: 982 Source Link-Layer Address: When known, the link-layer address 983 of the sender SHOULD be included using the Link-Layer Address 984 (LLA) option. See the LLA option format below. 986 New Access Point Link-Layer Address: The link-layer address or 987 identification of the access point for which the MN requests 988 routing advertisement information. It MUST be included in all 989 RtSolPr messages. More than one such address or identifier can 990 be present. This field can also be a wildcard address. See 991 the LLA option below. 993 Future versions of this protocol may define new option types. 994 Receivers MUST silently ignore any options that they do not recognize 995 and continue processing the rest of the message. 997 Including the source LLA option allows the receiver to record the 998 sender's L2 address so that neighbor discovery can be avoided when 999 the receiver needs to send packets back to the sender (of the RtSolPr 1000 message). 1002 When a wildcard is used for New Access Point LLA, no other New Access 1003 Point LLA options must be present. 1005 A Proxy Router Advertisement (PrRtAdv) message should be received by 1006 the MN in response to an RtSolPr. If such a message is not received 1007 in a timely manner (no less than twice the typical round trip time 1008 (RTT) over the access link or 100 milliseconds if RTT is not known), 1009 it SHOULD resend the RtSolPr message. Subsequent retransmissions can 1010 be up to RTSOLPR_RETRIES, but MUST use an exponential backoff in 1011 which the timeout period (i.e., 2xRTT or 100 milliseconds) is doubled 1012 prior to each instance of retransmission. If Proxy Router 1013 Advertisement is not received by the time the MN disconnects from the 1014 PAR, the MN SHOULD send an FBU immediately after configuring a new 1015 CoA. 1017 When RtSolPr messages are sent more than once, they MUST be rate 1018 limited with MAX_RTSOLPR_RATE per second. During each use of an 1019 RtSolPr, exponential backoff is used for retransmissions. 1021 6.1.2. Proxy Router Advertisement (PrRtAdv) 1023 Access routers send Proxy Router Advertisement messages gratuitously 1024 if the handover is network-initiated or as a response to an RtSolPr 1025 message from an MN, providing the link-layer address, IP address, and 1026 subnet prefixes of neighboring routers. All the Link-Layer Address 1027 options have the format defined in 6.4.3. 1029 0 1 2 3 1030 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 1031 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1032 | Type | Code | Checksum | 1033 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1034 | Subtype | Reserved | Identifier | 1035 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1036 | Options ... 1037 +-+-+-+-+-+-+-+-+-+-+-+- 1039 Figure 5: Proxy Router Advertisement (PrRtAdv) Message 1041 IP Fields: 1043 Source Address: MUST be the link-local address assigned to the 1044 interface from which this message is sent. 1046 Destination Address: The Source Address of an invoking Router 1047 Solicitation for Proxy Advertisement or the address of the node 1048 the access router is instructing to handover. 1050 Hop Limit: 255. See RFC 2461. 1052 ICMP Fields: 1054 Type: 154 1056 Code: 0, 1, 2, 3, 4, or 5. See below. 1058 Checksum: The ICMPv6 checksum. 1060 Subtype: 3 1062 Reserved: MUST be set to zero by the sender and ignored by the 1063 receiver. 1065 Identifier: Copied from Router Solicitation for Proxy 1066 Advertisement or set to zero if unsolicited. 1068 Valid Options in the following order: 1070 Source Link-Layer Address: When known, the link-layer address 1071 of the sender SHOULD be included using the Link-Layer Address 1072 option. See the LLA option format below. 1074 New Access Point Link-Layer Address: The link-layer address or 1075 identification of the access point is copied from RtSolPr 1076 message. This option MUST be present. 1078 New Router's Link-Layer Address: The link-layer address of the 1079 access router for which this message is proxied for. This 1080 option MUST be included when the Code is 0 or 1. 1082 New Router's IP Address: The IP address of the NAR. This 1083 option MUST be included when the Code is 0 or 1. 1085 New Router Prefix Information Option: Specifies the prefix of 1086 the access router the message is proxied for and is used for 1087 address auto-configuration. This option MUST be included when 1088 Code is 0 or 1. However, when this prefix is the same as what 1089 is used in the New Router's IP Address option (above), the 1090 Prefix Information option need not be present. 1092 New CoA Option: MAY be present when PrRtAdv is sent 1093 unsolicited. The PAR MAY compute a new CoA using the NAR's 1094 prefix information and the MN's L2 address or by any other 1095 means. 1097 Future versions of this protocol may define new option types. 1098 Receivers MUST silently ignore any options they do not recognize and 1099 continue processing the message. 1101 Currently, Code values 0, 1, 2, 3, 4, and 5 are defined. 1103 A Proxy Router Advertisement with Code 0 means that the MN should use 1104 the [AP-ID, AR-Info] tuple (present in the options above) for 1105 movement detection and NCoA formulation. The Option-Code field in 1106 the New Access Point LLA option in this case is 1 reflecting the LLA 1107 of the access point for which the rest of the options are related. 1108 Multiple tuples may be present. 1110 A Proxy Router Advertisement with Code 1 means that the message has 1111 been sent unsolicited. If a New CoA option is present following the 1112 New Router Prefix Information option, the MN MUST use the supplied 1113 NCoA and send an FBU immediately or else stand to lose service. This 1114 message acts as a network-initiated handover trigger; see 1115 Section 3.3. The Option-Code field in the New Access Point LLA 1116 option (see below) in this case is 1 reflecting the LLA of the access 1117 point for which the rest of the options are related. 1119 A Proxy Router Advertisement with Code 2 means that no new router 1120 information is present. Each New Access Point LLA option contains an 1121 Option-Code value (described below) that indicates a specific 1122 outcome. 1124 When the Option-Code field in the New Access Point LLA option is 1125 5, handover to that access point does not require a change of CoA. 1126 This would be the case, for instance, when a number of access 1127 points are connected to the same router interface, or when network 1128 based mobility management mechanisms ensure that the specific 1129 mobile node always observes the same prefix regardless of whether 1130 there is a separate router attached to the target access point. 1132 No other options are required in this case. 1134 When the Option-Code field in the New Access Point LLA option is 1135 6, the PAR is not aware of the Prefix Information requested. The 1136 MN SHOULD attempt to send an FBU as soon as it regains 1137 connectivity with the NAR. No other options are required in this 1138 case. 1140 When the Option-Code field in the New Access Point LLA option is 1141 7, it means that the NAR does not support fast handover. The MN 1142 MUST stop fast handover protocol operations. No other options are 1143 required in this case. 1145 A Proxy Router Advertisement with Code 3 means that new router 1146 information is only present for a subset of access points requested. 1147 The Option-Code field values (defined above including a value of 1) 1148 distinguish different outcomes for individual access points. 1150 A Proxy Router Advertisement with Code 4 means that the subnet 1151 information regarding neighboring access points is sent unsolicited, 1152 but the message is not a handover trigger, unlike when the message is 1153 sent with Code 1. Multiple tuples may be present. 1155 A Proxy Router Advertisement with Code 5 means that the MN may use 1156 the new router information present for detecting movement to a new 1157 subnet, but the MN must perform DHCP [RFC3315] upon attaching to the 1158 NAR's link. The PAR and NAR will forward packets to the PCoA of the 1159 MN. The MN must still formulate an NCoA for transmitting FBU (using 1160 the information sent in this message), but that NCoA will not be used 1161 for forwarding packets. 1163 When a wildcard AP identifier is supplied in the RtSolPr message, the 1164 PrRtAdv message should include any 'n' [Access Point Identifier, 1165 Link-Layer Address option, Prefix Information Option] tuples 1166 corresponding to the PAR's neighborhood. 1168 6.2. New Mobility Header Messages 1170 Mobile IPv6 uses a new IPv6 header type called Mobility Header 1171 [RFC3775]. The Handover Initiate, Handover Acknowledge, Fast Binding 1172 Update, Fast Binding Acknowledgment, and the (deprecated) Fast 1173 Neighbor Advertisement messages use the Mobility Header. 1175 6.2.1. Inter - Access Router Messages 1177 6.2.1.1. Handover Initiate (HI) 1179 The Handover Initiate (HI) is a Mobility Header message sent by an 1180 Access Router (typically PAR) to another access router (typically 1181 NAR) to initiate the process of an MN's handover. 1183 0 1 2 3 1184 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 1186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1187 | Sequence # | 1188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1189 |S|U| Reserved | Code | | 1190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . 1191 | | 1192 . . 1193 . Mobility options . 1194 . . 1195 | | 1196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1198 Figure 6: Handover Initiate (HI) Message 1200 IP Fields: 1202 Source Address: The IP address of the PAR 1204 Destination Address: The IP address of the NAR 1206 Sequence #: MUST be set by the sender so replies can be matched 1207 to this message. 1209 'S' flag: Assigned address configuration flag. When set, this 1210 message requests a new CoA to be returned by the destination. 1211 MAY be set when Code = 0. MUST be 0 when Code = 1. 1213 'U' flag: Buffer flag. When set, the destination SHOULD buffer 1214 any packets toward the node indicated in the options of this 1215 message. Used when Code = 0, SHOULD be set to 0 when Code = 1. 1217 Code: 0 or 1. See below 1219 Reserved: MUST be set to zero by the sender and ignored by the 1220 receiver. 1222 Valid Options: 1224 Link-Layer Address of MN: The link-layer address of the MN that 1225 is undergoing handover to the destination (i.e., NAR). This 1226 option MUST be included so that the destination can recognize 1227 the MN. 1229 Previous Care-of Address: The IP address used by the MN while 1230 attached to the originating router. This option SHOULD be 1231 included so that a host route can be established if necessary. 1233 New Care-of Address: The IP address the MN wishes to use when 1234 connected to the destination. When the 'S' bit is set, the NAR 1235 MAY assign this address. 1237 The PAR uses a Code value of 0 when it processes an FBU with PCoA as 1238 source IP address. The PAR uses a Code value of 1 when it processes 1239 an FBU whose source IP address is not PCoA. 1241 If a Handover Acknowledge (HAck) message is not received as a 1242 response in a short time period (no less than twice the typical round 1243 trip time (RTT) between source and destination, or 100 milliseconds 1244 if RTT is not known), the Handover Initiate SHOULD be resent. 1245 Subsequent retransmissions can be up to HI_RETRIES, but MUST use 1246 exponential backoff in which the timeout period (i.e., 2xRTT or 100 1247 milliseconds) is doubled during each instance of retransmission. 1249 6.2.1.2. Handover Acknowledge (HAck) 1251 The Handover Acknowledge message is a new Mobility Header message 1252 that MUST be sent (typically by the NAR to the PAR) as a reply to the 1253 Handover Initiate message. 1255 0 1 2 3 1256 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 1258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1259 | Sequence # | 1260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1261 | Reserved | Code | | 1262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . 1263 | | 1264 . . 1265 . Mobility options . 1266 . . 1267 | | 1268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1270 Figure 7: Handover Acknowledge (HAck) Message 1272 IP Fields: 1274 Source Address: Copied from the destination address of the 1275 Handover Initiate Message to which this message is a response. 1277 Destination Address: Copied from the source address of the 1278 Handover Initiate Message to which this message is a response. 1280 Sequence #: Copied from the corresponding field in the HI 1281 message to which this message is a response, to enable the 1282 receiver to match this HAck message with an oustanding HI 1283 message. 1285 Code: 1287 0: Handover Accepted, NCoA valid 1289 1: Handover Accepted, NCoA not valid or in use 1291 2: Handover Accepted, NCoA assigned (used in Assigned 1292 addressing) 1294 3: Handover Accepted, use PCoA 1296 4: Message sent unsolicited, usually to trigger an HI 1297 message 1299 128: Handover Not Accepted, reason unspecified 1301 129: Administratively prohibited 1303 130: Insufficient resources 1305 Reserved: MUST be set to zero by the sender and ignored by the 1306 receiver. 1308 Valid Options: 1310 New Care-of Address: If the S flag in the Handover Initiate 1311 message is set, this option MUST be used to provide NCoA the MN 1312 should use when connected to this router. This option MAY be 1313 included, even when the 'S' bit is not set, e.g., Code 2 above. 1315 Upon receiving an HI message, the NAR MUST respond with a Handover 1316 Acknowledge message. If the 'S' flag is set in the HI message, the 1317 NAR SHOULD include the New Care-of Address option and a Code 3. 1319 The NAR MAY provide support for the PCoA (instead of accepting or 1320 assigning an NCoA), establish a host route entry for the PCoA, and 1321 set up a tunnel to the PAR to forward the MN's packets sent with the 1322 PCoA as a source IP address. This host route entry SHOULD be used to 1323 forward packets once the NAR detects that the particular MN is 1324 attached to its link. The NAR indicates forwarding support for PCoA 1325 using Code value 3 in the HAck message. Subsequently, the PAR 1326 establishes a tunnel to the NAR in order to forward packets arriving 1327 for the PCoA. 1329 When responding to an HI message containing a Code value 1, the Code 1330 values 1, 2, and 4 in the HAck message are not relevant. 1332 Finally, the New Access Router can always refuse handover, in which 1333 case it should indicate the reason in one of the available Code 1334 values. 1336 6.2.2. Fast Binding Update (FBU) 1338 The Fast Binding Update message has a Mobility Header Type value of 1339 8. The FBU is identical to the Mobile IPv6 Binding Update (BU) 1340 message. However, the processing rules are slightly different. 1341 Furthermore, additional flags (as part of the Reserved field below) 1342 defined by other related protocols are not relevant in this message, 1343 and MUST be set to zero. 1345 0 1 2 3 1346 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 1348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1349 | Sequence # | 1350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1351 |A|H|L|K| Reserved | Lifetime | 1352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1353 | | 1354 . . 1355 . Mobility options . 1356 . . 1357 | | 1358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1360 Figure 8: Fast Binding Update (FBU) Message 1362 IP Fields: 1364 Source Address: The PCoA or NCoA 1365 Destination Address: The IP address of the Previous Access 1366 Router 1368 'A' flag: MUST be set to one to request that PAR send a Fast 1369 Binding Acknowledgment message. 1371 'H' flag: MUST be set to one. See [RFC3775]. 1373 'L' flag: See [RFC3775]. 1375 'K' flag: See [RFC3775]. 1377 Reserved: This field is unused. MUST be set to zero. 1379 Sequence Number: See [RFC3775]. 1381 Lifetime: The requested time in seconds for which the sender 1382 wishes to have a binding. 1384 Mobility Options: MUST contain an alternate CoA option set to the 1385 NCoA when an FBU is sent from the PAR's link. MUST contain the 1386 Binding Authorization Data for the FMIP (BADF) option. See 1387 Section 6.4.5. MAY contain the Mobility Header LLA option (see 1388 Section 6.4.4). 1390 The MN sends an FBU message any time after receiving a PrRtAdv 1391 message. If the MN moves prior to receiving a PrRtAdv message, it 1392 SHOULD send an FBU to the PAR after configuring the NCoA on the NAR 1393 according to Neighbor Discovery and IPv6 Address Configuration 1394 protocols. When the MN moves without having received a PrRtAdv 1395 message, it cannot transmit an UNA message upon attaching to the 1396 NAR's link. 1398 The source IP address is the PCoA when the FBU is sent from the PAR's 1399 link, and the source IP address is the NCoA when the FBU sent from 1400 the NAR's link. When the source IP address is the PCoA, the MN MUST 1401 include the alternate CoA option set to NCoA. The PAR MUST process 1402 the FBU even though the address in the alternate CoA option is 1403 different from that in the source IP address, and ensure that the 1404 address in the alternate CoA option is used in the New CoA option in 1405 the HI message to the NAR. 1407 The FBU MUST also include the Home Address Option set to PCoA. An 1408 FBU message MUST be protected so that the PAR is able to determine 1409 that the FBU message is sent by an MN that legitimately owns the 1410 PCoA. 1412 6.2.3. Fast Binding Acknowledgment (FBack) 1414 The FBack message format is identical to the Mobile IPv6 Binding 1415 Acknowledgement (BAck) message. However, the processing rules are 1416 slightly different. Furthermore, additional flags (as part of the 1417 Reserved field below) defined by other related protocols are not 1418 relevant in this message, and MUST be set to zero. 1420 The Fast Binding Acknowledgment message has a Mobility Header Type 1421 value of 9. The FBack message is sent by the PAR to acknowledge 1422 receipt of a Fast Binding Update message in which the 'A' bit is set. 1423 If PAR sends an HI message to the NAR after processing an FBU, the 1424 FBack message SHOULD NOT be sent to the MN before the PAR receives a 1425 HAck message from the NAR. The PAR MAY send the FBack immediately in 1426 the reactive mode however. The Fast Binding Acknowledgment MAY also 1427 be sent to the MN on the old link. 1429 0 1 2 3 1430 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 1432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1433 | Status |K| Reserved | 1434 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1435 | Sequence # | Lifetime | 1436 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1437 | | 1438 . . 1439 . Mobility options . 1440 . . 1441 | | 1442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1444 Figure 9: Fast Binding Acknowledgment (FBack) Message 1446 IP Fields: 1448 Source address: The IP address of the Previous Access Router 1450 Destination Address: The NCoA, and optionally the PCoA 1452 Status: 8-bit unsigned integer indicating the disposition of the 1453 Fast Binding Update. Values of the Status field that are less 1454 than 128 indicate that the Binding Update was accepted by the 1455 receiving node. The following such Status values are currently 1456 defined: 1458 0 Fast Binding Update accepted 1460 1 Fast Binding Update accepted but NCoA is invalid. Use NCoA 1461 supplied in "alternate" CoA 1463 Values of the Status field greater than or equal to 128 indicate 1464 that the Binding Update was rejected by the receiving node. The 1465 following such Status values are currently defined: 1467 128: Reason unspecified 1469 129: Administratively prohibited 1471 130: Insufficient resources 1473 131: Incorrect interface identifier length 1475 'K' flag: See [RFC3775]. 1477 Reserved: An unused field. MUST be set to zero. 1479 Sequence Number: Copied from the FBU message for use by the MN in 1480 matching this acknowledgment with an outstanding FBU. 1482 Lifetime: The granted lifetime in seconds for which the sender of 1483 this message will retain a binding for traffic redirection. 1485 Mobility Options: MUST contain an "alternate" CoA if Status is 1. 1486 MUST contain the Binding Authorization Data for FMIP (BADF) 1487 option. See 6.4.5. 1489 6.3. Unsolicited Neighbor Advertisement (UNA) 1491 This is the same message as in [RFC4861] with the requirement that 1492 the 'O' bit is always set to zero. Since this is an unsolicited 1493 message, the 'S' bit is zero, and since this is sent by an MN, the 1494 'R' bit is also zero. 1496 If the NAR is proxying the NCoA (as a result of HI and HAck 1497 exchange), then UNA processing has additional steps (see below). If 1498 the NAR is not proxying the NCoA (for instance, HI and HAck exchange 1499 has not taken place), then UNA processing follows the same procedure 1500 as specified in [RFC4861]. Implementations MAY retransmit UNA 1501 subject to the specification in Section 7.2.6 of [RFC4861] while 1502 noting that the default RetransTimer value is large for handover 1503 purposes. 1505 The Source Address in UNA MUST be the NCoA. The destination address 1506 is typically the all-nodes multicast address; however, some 1507 deployments may not prefer transmission to a multicast address. In 1508 such cases, the destination address SHOULD be the NAR's IP address. 1510 The Target Address MUST include the NCoA, and the Target link-layer 1511 address MUST include the MN's LLA. 1513 The MN sends an UNA message to the NAR, as soon as it regains 1514 connectivity on the new link. Arriving or buffered packets can be 1515 immediately forwarded. If the NAR is proxying the NCoA, it creates a 1516 neighbor cache entry in STALE state but forwards packets as it 1517 determines bidirectional reachability according to the standard 1518 Neighbor Discovery procedure. If there is an entry in INCOMPLETE 1519 state without a link-layer address, it sets it to STALE, again 1520 according to the procedure in [RFC4861]. 1522 The NAR MAY wish to provide a different IP address to the MN than the 1523 one in the UNA message. In such a case, the NAR MUST delete the 1524 proxy entry for the NCoA and send a Router Advertisement with NAACK 1525 option containing the new IP address. 1527 The combination of the NCoA (present in source IP address) and the 1528 Link-Layer Address (present as a Target LLA) SHOULD be used to 1529 distinguish the MN from other nodes. 1531 6.4. New Options 1533 All the options, with the exception of Binding Data Authorization for 1534 FMIPv6 (BADF) discussed in Section 6.4.5, use Type, Length, and 1535 Option-Code format shown in Figure 10. 1537 The Type values are defined from the Neighbor Discovery options space 1538 and Mobility Header options space. The Length field is in units of 8 1539 octets for Neighbor Discovery options, and is in units of octets for 1540 Mobility Header options. And, Option-Code provides additional 1541 information for each of the options (see individual options below). 1543 0 1 2 3 1544 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 1545 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1546 | Type | Length | Option-Code | | 1547 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1548 ~ ... ~ 1549 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1551 Figure 10: Option Format 1553 6.4.1. IP Address/Prefix Option 1555 This option is sent in the Proxy Router Advertisement message. 1557 0 1 2 3 1558 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1559 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1560 | Type | Length | Option-Code | Prefix Length | 1561 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1562 | Reserved | 1563 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1564 | | 1565 + + 1566 | | 1567 + IPv6 Address + 1568 | | 1569 + + 1570 | | 1571 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1573 Figure 11: IPv6 Address/Prefix Option 1575 Type: 17 1577 Length: The size of this option in 8 octets including the Type, 1578 Option-Code, and Length fields. 1580 Option-Code: 1582 1: Old Care-of Address 1584 2: New Care-of Address 1586 3: NAR's IP address 1588 4: NAR's Prefix, sent in PrRtAdv. The Prefix Length field 1589 contains the number of valid leading bits in the prefix. The 1590 bits in the prefix after the prefix length are reserved and 1591 MUST be initialized to zero by the sender and ignored by the 1592 receiver. 1594 Prefix Length: 8-bit unsigned integer that indicates the length of 1595 the IPv6 Address Prefix. The value ranges from 0 to 128. 1597 Reserved: MUST be set to zero by the sender and MUST be ignored by 1598 the receiver. 1600 IPv6 address: The IP address defined by the Option-Code field. 1602 6.4.2. Mobility Header IP Address/Prefix Option 1604 This option is sent in the Handover Initiate, and Handover 1605 Acknowledge messages. This option has an alignment requirement of 1606 8n+4. 1608 0 1 2 3 1609 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 1610 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1611 | Type | Length | Option-Code | Prefix Length | 1612 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1613 | | 1614 + + 1615 | | 1616 + IPv6 Address/Prefix + 1617 | | 1618 + + 1619 | | 1620 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1622 Figure 12: Mobility Header IPv6 Address/Prefix Option 1624 Type: 17 1626 Length: The size of this option in octets excluding the Type, and 1627 Length fields. 1629 Option-Code: 1631 1: Old Care-of Address 1633 2: New Care-of Address 1635 3: NAR's IP address 1637 4: NAR's Prefix, sent in PrRtAdv. The Prefix Length field 1638 contains the number of valid leading bits in the prefix. The 1639 bits in the prefix after the prefix length are reserved and 1640 MUST be initialized to zero by the sender and ignored by the 1641 receiver. 1643 Prefix Length: 8-bit unsigned integer that indicates the length of 1644 the IPv6 Address Prefix. The value ranges from 0 to 128. 1646 IPv6 address/prefix: The IP address/prefix defined by the Option- 1647 Code field. 1649 6.4.3. Link-Layer Address (LLA) Option 1651 0 1 2 3 1652 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 1653 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1654 | Type | Length | Option-Code | LLA... 1655 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1657 Figure 13: Link-Layer Address Option 1659 Type: 19 1661 Length: The size of this option in 8 octets including the Type, 1662 Option-Code, and Length fields. 1664 Option-Code: 1666 0: wildcard requesting resolution for all nearby access points 1668 1: Link-Layer Address of the New Access Point 1670 2: Link-Layer Address of the MN 1672 3: Link-Layer Address of the NAR (i.e., Proxied Originator) 1674 4: Link-Layer Address of the source of RtSolPr or PrRtAdv 1675 message 1677 5: The access point identified by the LLA belongs to the 1678 current interface of the router 1680 6: No prefix information available for the access point 1681 identified by the LLA 1683 7: No fast handovers support available for the access point 1684 identified by the LLA 1686 LLA: The variable length link-layer address. 1688 The LLA option does not have a length field for the LLA itself. The 1689 implementations must consult the specific link layer over which the 1690 protocol is run in order to determine the content and length of the 1691 LLA. 1693 Depending on the size of individual LLA option, appropriate padding 1694 MUST be used to ensure that the entire option size is a multiple of 8 1695 octets. 1697 The New Access Point Link-Layer Address contains the link-layer 1698 address of the access point for which handover is about to be 1699 attempted. This is used in the Router Solicitation for Proxy 1700 Advertisement message. 1702 The MN Link-Layer Address option contains the link-layer address of 1703 an MN. It is used in the Handover Initiate message. 1705 The NAR (i.e., Proxied Originator) Link-Layer Address option contains 1706 the link-layer address of the access router to which the Proxy Router 1707 Solicitation message refers. 1709 6.4.4. Mobility Header Link-Layer Address (MH-LLA) Option 1711 This option is identical to the LLA option, but is carried in the 1712 Mobility Header messages, e.g., FBU. In the future, other Mobility 1713 Header messages may also make use of this option. The format of the 1714 option is shown in Figure 14. There are no alignment requirements 1715 for this option. 1717 0 1 2 3 1718 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 1719 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1720 | Type | Length | 1721 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1722 | Option-Code | LLA .... 1723 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1725 Figure 14: Mobility Header Link-Layer Address Option 1727 Type: 7 1729 Length: The size of this option in octets not including the Type 1730 and Length fields. 1732 Option-Code: 2 Link-Layer Address of the MN. 1734 LLA: The variable length link-layer address. 1736 6.4.5. Binding Authorization Data for FMIPv6 (BADF) 1738 This option MUST be present in FBU and FBack messages. The security 1739 association between the MN and the PAR is established by companion 1740 protocols [RFC5269]. This option specifies how to compute and verify 1741 a Message Authentication Code (MAC) using the established security 1742 association. 1744 The format of this option is shown in Figure 15. 1746 0 1 2 3 1747 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 1748 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1749 | Type | Option Length | 1750 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1751 | SPI | 1752 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1753 | | 1754 + + 1755 | Authenticator | 1756 + + 1757 | | 1758 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1760 Figure 15: Binding Authorization Data for FMIPv6 (BADF) Option 1762 Type: 21 1764 Option Length: The length of the Authenticator in bytes 1766 SPI: Security Parameter Index. SPI = 0 is reserved for the 1767 Authenticator computed using SEND-based handover keys. 1769 Authenticator: Same as in RFC 3775, with "correspondent" replaced 1770 by the PAR's IP address, and Kbm replaced by the shared key 1771 between the MN and the PAR. 1773 The default MAC calculation is done using HMAC_SHA1 with the first 96 1774 bits used for the MAC. Since there is an Option Length field, 1775 implementations can use other algorithms such as HMAC_SHA256. 1777 This option MUST be the last Mobility Option present. 1779 6.4.6. Neighbor Advertisement Acknowledgment (NAACK) 1781 0 1 2 3 1782 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 1783 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1784 | Type | Length | Option-Code | Status | 1785 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1786 | Reserved | 1787 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1789 Figure 16: Neighbor Advertisement Acknowledgment Option 1791 Type: 20 1793 Length: 8-bit unsigned integer. Length of the option, in 8 1794 octets. The length is 1 when a new CoA is not supplied. The 1795 length is 3 when a new CoA is present (immediately following the 1796 Reserved field) 1798 Option-Code: 0 1800 Status: 8-bit unsigned integer indicating the disposition of the 1801 Unsolicited Neighbor Advertisement message. The following Status 1802 values are currently defined: 1804 1: NCoA is invalid, perform address configuration 1806 2: NCoA is invalid, use the supplied NCoA. The supplied NCoA 1807 (in the form of an IP Address Option) MUST be present following 1808 the Reserved field. 1810 3: NCoA is invalid, use NAR's IP address as NCoA in FBU 1812 4: PCoA supplied, do not send FBU 1814 128: Link-Layer Address unrecognized 1816 Reserved: MUST be set to zero by the sender and MUST be ignored by 1817 the receiver. 1819 The NAR responds to UNA with the NAACK option to notify the MN to use 1820 a different NCoA than the one that the MN has used. If the NAR 1821 proposes a different NCoA, the Router Advertisement MUST use the 1822 source IP address in the UNA message as the destination address, and 1823 use the L2 address present in UNA. The MN MUST use the NCoA if it is 1824 supplied with the NAACK option. If the NAACK indicates that the 1825 Link-Layer Address is unrecognized, for instance, if the MN uses an 1826 LLA valid on PAR's link but the same LLA is not valid on NAR's link 1827 due to a different access technology, the MN MUST NOT use the NCoA or 1828 the PCoA and SHOULD start immediately the process of acquiring a 1829 different NCoA at the NAR. 1831 In the future, new option types may be defined. 1833 7. Related Protocol and Device Considerations 1835 The protocol specified here, as a design principle, introduces no or 1836 minimal changes to related protocols. For example, no changes to the 1837 base Mobile IPv6 protocol are needed in order to implement this 1838 protocol. Similarly, no changes to the IPv6 stateless address auto- 1839 configuration protocol [RFC4862] and DHCP [RFC3315] are introduced. 1840 The protocol specifies an optional extension to Neighbor Discovery 1841 [RFC4861] in which an access router may send a router advertisement 1842 as a response to the UNA message (see Section Section 6.3). Other 1843 than this extension, the specification does not modify Neighbor 1844 Discovery behavior (including the procedures performed when attached 1845 to the PAR and when attaching to the NAR). 1847 The protocol does not require changes to any intermediate Layer 2 1848 device between an MN and its access router that supports this 1849 specification. This includes the wireless access points, switches, 1850 snooping devices, and so on. 1852 8. Evolution from and Compatibility with RFC 4068 1854 This document has evolved from [RFC4068]. Specifically, a new 1855 handover key establishment protocol (see [RFC5269]) has been defined 1856 to enable a security association between a mobile node and its access 1857 router. This allows the secure update of the routing of packets 1858 during a handover. In the future, new specifications may be defined 1859 to establish such security associations depending on the particular 1860 deployment scenario. 1862 The protocol has improved from the experiences in implementing 1863 [RFC4068], and from experimental usage. The input has improved the 1864 specification of parameter fields (such as lifetime, codepoints, 1865 etc.) as well as inclusion of new parameter fields in the existing 1866 messages. As of this writing, there are two publicly available 1867 implementations, [fmipv6] and [tarzan], and multiple proprietary 1868 implementations. Some experience suggests that the protocol meets 1869 the delay and packet loss requirements when used appropriately with 1870 particular radio access protocols. For instance, see [RFC5184], and 1871 [mip6-book]. Nevertheless, it is important to recognize that 1872 handover performance is a function of both IP layer operations, which 1873 this protocol specifies, and the particular radio access technology 1874 itself, which this protocol relies upon but does not modify. 1876 An existing implementation of [RFC4068] needs to be updated in order 1877 to support this specification. The primary addition is the 1878 establishment of a security association between an MN and its access 1879 router (i.e., MN and PAR). One way to establish such a security 1880 association is specified in [RFC5269]. An implementation that 1881 complies with the specification in this document is likely to also 1882 work with [RFC4068], except for the Binding Authorization Data for 1883 FMIPv6 option (see Section 6.4.5) that can only be processed when 1884 security association is in place between a mobile node and its access 1885 router. This specification deprecates the Fast Neighbor 1886 Advertisement (FNA) message. However, it is acceptable for a NAR to 1887 process this message from a mobile node as specified in [RFC4068]. 1889 9. Configurable Parameters 1891 Mobile nodes rely on configuration parameters shown in the table 1892 below. Each mobile node MUST have a configuration mechanism to 1893 adjust the parameters. Such a configuration mechanism may be either 1894 local (such as a command line interface) or based on central 1895 management of a number of mobile nodes. 1897 +-------------------+---------------+-----------------+ 1898 | Parameter Name | Default Value | Definition | 1899 +-------------------+---------------+-----------------+ 1900 | RTSOLPR_RETRIES | 3 | Section 6.1.1 | 1901 | MAX_RTSOLPR_RATE | 3 | Section 6.1.1 | 1902 | FBU_RETRIES | 3 | Section 6.2.2 | 1903 | PROXY_ND_LIFETIME | 1.5 seconds | Section 6.2.1.2 | 1904 | HI_RETRIES | 3 | Section 6.2.1.1 | 1905 +-------------------+---------------+-----------------+ 1907 10. Security Considerations 1909 The following security vulnerabilities are identified and suggested 1910 solutions are mentioned. 1912 Insecure FBU: in this case, packets meant for one address could be 1913 stolen or redirected to some unsuspecting node. This concern is 1914 the same as that in an MN and Home Agent relationship. 1916 Hence, the PAR MUST ensure that the FBU packet arrived from a node 1917 that legitimately owns the PCoA. The access router and its hosts 1918 may use any available mechanism to establish a security 1919 association that MUST be used to secure FBU. The current version 1920 of this protocol relies on a companion protocol [RFC5269] to 1921 establish such a security association. Using the shared handover 1922 key from [RFC5269], the Authenticator in BADF option (see 1923 Section 6.4.5) MUST be computed, and the BADF option included in 1924 FBU and FBack messages. 1926 Secure FBU, malicious or inadvertent redirection: in this case, 1927 the FBU is secured, but the target of binding happens to be an 1928 unsuspecting node either due to inadvertent operation or due to 1929 malicious intent. This vulnerability can lead to an MN with a 1930 genuine security association with its access router redirecting 1931 traffic to an incorrect address. 1933 However, the target of malicious traffic redirection is limited to 1934 an interface on an access router with which the PAR has a security 1935 association. The PAR MUST verify that the NCoA to which PCoA is 1936 being bound actually belongs to NAR's prefix. In order to do 1937 this, HI and HAck message exchanges are to be used. When NAR 1938 accepts NCoA in HI (with Code = 0), it proxies NCoA so that any 1939 arriving packets are not sent on the link until the MN attaches 1940 and announces itself through UNA. Therefore, any inadvertent or 1941 malicious redirection to a host is avoided. It is still possible 1942 to jam a NAR's buffer with redirected traffic. However, since a 1943 NAR's handover state corresponding to an NCoA has a finite (and 1944 short) lifetime corresponding to a small multiple of anticipated 1945 handover latency, the extent of this vulnerability is arguably 1946 small. 1948 Sending an FBU from a NAR's link: A malicious node may send an FBU 1949 from a NAR's link providing an unsuspecting node's address as an 1950 NCoA. This is similar to base Mobile IP where the MN can provide 1951 some other node's IP address as its CoA to its Home Agent; here 1952 the PAR acts like a "temporary Home Agent" having a security 1953 association with the Mobile Node and providing forwarding support 1954 for the handover traffic. As in base Mobile IP, this misdelivery 1955 is traceable to the MN that has a security association with the 1956 router. So, it is possible to isolate such an MN if it continues 1957 to misbehave. Similarly, an MN that has a security association 1958 with the PAR may provide the LLA of some other node on NAR's link, 1959 which can cause misdelivery of packets (meant for the NCoA) to an 1960 unsuspecting node. It is possible to trace the MN in this case as 1961 well. 1963 Apart from the above, the RtSolPr (Section 6.1.1) and PrRtAdv 1964 (Section 6.1.2) messages inherit the weaknesses of Neighbor Discovery 1965 protocol [RFC4861]. Specifically, when its access router is 1966 compromised, the MN's RtSolPr message may be answered by an attacker 1967 that provides a rogue router as the resolution. Should the MN attach 1968 to such a rogue router, its communication can be compromised. 1970 Similarly, a network-initiated PrRtAdv message (see Section 3.3) from 1971 an attacker could cause an MN to handover to a rogue router. Where 1972 these weaknesses are a concern, a solution such as Secure Neighbor 1973 Discovery (SEND) [RFC3971] SHOULD be considered. 1975 The protocol provides support for buffering packets during an MN's 1976 handover. This is done by securely exchanging the Handover Initiate 1977 (HI) and Handover Acknowledgment (HAck) messages in response to the 1978 FBU message from an MN. It is possible that an MN may fail, either 1979 inadvertently or purposely, to undergo handover to the NAR, which 1980 typically provides buffering support. This can cause the NAR to 1981 waste its memory containing the buffered packets, and in the worst 1982 case, could create resource exhaustion concerns. Hence, 1983 implementations must limit the size of the buffer as a local policy 1984 configuration, which may consider parameters such as the average 1985 handover delay, expected size of packets, and so on. 1987 The Handover Initiate (HI) and Handover Acknowledgement (HAck) 1988 messages exchanged between the PAR and NAR MUST be protected using 1989 end-to-end security association(s) offering integrity and data origin 1990 authentication. 1992 The PAR and the NAR MUST implement IPsec [RFC4301] for protecting the 1993 HI and HAck messages. IPsec Encapsulating Security Payload (ESP) 1994 [RFC4303] in transport mode with mandatory integrity protection 1995 SHOULD be used for protecting the signaling messages. 1996 Confidentiality protection of these messages is not required. 1998 The security associations can be created by using either manual IPsec 1999 configuration or a dynamic key negotiation protocol such as Internet 2000 Key Exchange Protocol version 2 (IKEv2) [RFC4306]. If IKEv2 is used, 2001 the PAR and the NAR can use any of the authentication mechanisms, as 2002 specified in RFC 4306, for mutual authentication. However, to ensure 2003 a baseline interoperability, the implementations MUST support shared 2004 secrets for mutual authentication. The following sections describe 2005 the Peer Authorization Database (PAD) and Security Policy Database 2006 (SPD) entries specified in [RFC4301] when IKEv2 is used for setting 2007 up the required IPsec security associations. 2009 10.1. Peer Authorization Database Entries when Using IKEv2 2011 This section describes PAD entries on the PAR and the NAR. The PAD 2012 entries are only example configurations. Note that the PAD is a 2013 logical concept and a particular PAR or NAR implementation can 2014 implement the PAD in any implementation specific manner. The PAD 2015 state may also be distributed across various databases in a specific 2016 implementation. 2018 PAR PAD: 2020 - IF remote_identity = nar_identity_1 2021 THEN authenticate (shared secret/certificate/EAP) and authorize 2022 CHILD_SA for remote address nar_address_1 2024 NAR PAD: 2026 - IF remote_identity = par_identity_1 2027 THEN authenticate (shared secret/certificate/EAP) and authorize 2028 CHILD_SAs for remote address par_address_1 2030 The list of authentication mechanisms in the above examples is not 2031 exhaustive. There could be other credentials used for authentication 2032 stored in the PAD. 2034 10.2. Security Policy Database Entries 2036 This section describes the security policy entries on the PAR and the 2037 NAR required to protect the HI and HAck messages. The SPD entries 2038 are only example configurations. A particular PAR or NAR 2039 implementation could configure different SPD entries as long as they 2040 provide the required security. 2042 In the examples shown below, the identity of the PAR is assumed to be 2043 par_1, the address of the PAR is assumed to be par_address_1, and the 2044 address of the NAR is assumed to be nar_address_1. 2046 PAR SPD-S: 2048 - IF local_address = par_address_1 & remote_address = 2049 nar_address_1 & proto = MH & local_mh_type = HI & 2050 remote_mh_type = HAck 2051 THEN use SA ESP transport mode Initiate using IDi = par_1 to 2052 address nar_address_1 2054 NAR SPD-S: 2056 - IF local_address = nar_address_1 & remote_address = 2057 par_address_1 & proto = MH & local_mh_type = HAck & 2058 remote_mh_type = HI 2059 THEN use SA ESP transport mode 2061 11. IANA Considerations 2063 This document defines two new Mobility Header messages which need 2064 allocation from the Mobility Header Type registry at 2065 http://www.iana.org/assignments/mobility-parameters 2066 TBD Handover Initiate Message (Section 6.2.1.1) 2068 TBD Handover Acknowledge Message (Section 6.2.1.2) 2070 This document defines a new Mobility Option that needs Type 2071 assignment from the Mobility Options Type registry at 2072 http://www.iana.org/assignments/mobility-parameters 2074 1. Mobility Header IPv6 Address/Prefix option, described in 2075 Section 6.4.2 2077 This document defines a new ICMPv6 message, which has been allocated 2078 from the ICMPv6 Type registry. 2080 154 FMIPv6 Messages 2082 This document creates a new registry for the 'Subtype' field in the 2083 above ICMPv6 message, called the "FMIPv6 Message Types". IANA has 2084 assigned the following values. 2086 +---------+-------------------+-----------------+ 2087 | Subtype | Description | Reference | 2088 +---------+-------------------+-----------------+ 2089 | 2 | RtSolPr | Section 6.1.1 | 2090 | 3 | PrRtAdv | Section 6.1.2 | 2091 | 4 | HI - Deprecated | Section 6.2.1.1 | 2092 | 5 | HAck - Deprecated | Section 6.2.1.2 | 2093 +---------+-------------------+-----------------+ 2095 The values '0' and '1' are reserved. The upper limit is 255. An RFC 2096 is required for new message assignment. The Subtype values 4 and 5 2097 are deprecated and are marked as unassigned for future allocations. 2099 The document defines a new Mobility Option that has received Type 2100 assignment from the Mobility Options Type registry. 2102 1. Binding Authorization Data for FMIPv6 (BADF) option, described in 2103 Section 6.4.5 2105 The document has already received Type assignments for the following 2106 (see [RFC4068]): 2108 The document defines the following Neighbor Discovery [RFC4861] 2109 options that have received Type assignment from IANA. 2111 +------+--------------------------------------------+---------------+ 2112 | Type | Description | Reference | 2113 +------+--------------------------------------------+---------------+ 2114 | 17 | IP Address/Prefix Option | Section 6.4.1 | 2115 | 19 | Link-layer Address Option | Section 6.4.3 | 2116 | 20 | Neighbor Advertisement Acknowledgment | Section 6.4.6 | 2117 | | Option | | 2118 +------+--------------------------------------------+---------------+ 2120 The document defines the following Mobility Header messages that have 2121 received Type allocation from the Mobility Header Types registry. 2123 1. Fast Binding Update, described in Section 6.2.2 2125 2. Fast Binding Acknowledgment, described in Section 6.2.3 2127 The document defines the following Mobility Option that has received 2128 Type assignment from the Mobility Options Type registry. 2130 1. Mobility Header Link-Layer Address option, described in 2131 Section 6.4.4 2133 12. Acknowledgments 2135 The editor would like to thank all those who have provided feedback 2136 on this specification, but can only mention a few here: Vijay 2137 Devarapalli, Youn-Hee Han, Emil Ivov, Syam Madanapalli, Suvidh 2138 Mathur, Andre Martin, Javier Martin, Koshiro Mitsuya, Gabriel 2139 Montenegro, Takeshi Ogawa, Sun Peng, YC Peng, Alex Petrescu, Domagoj 2140 Premec, Subba Reddy, K. Raghav, Ranjit Wable, and Jonathan Wood. 2141 Behcet Sarikaya and Frank Xia are acknowledged for the feedback on 2142 operation over point-to-point links. The editor would like to 2143 acknowledge a contribution from James Kempf to improve this 2144 specification. Vijay Devarapalli provided text for the security 2145 configuration between access routers in Section 10. Thanks to Jari 2146 Arkko for the detailed AD Review, which has improved this document. 2147 The editor would also like to thank the [mipshop] working group chair 2148 Gabriel Montenegro and the erstwhile [mobile ip] working group chairs 2149 Basavaraj Patil and Phil Roberts for providing much support for this 2150 work. 2152 13. References 2154 13.1. Normative References 2156 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2157 Requirement Levels", BCP 14, RFC 2119, March 1997. 2159 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 2160 and M. Carney, "Dynamic Host Configuration Protocol for 2161 IPv6 (DHCPv6)", RFC 3315, July 2003. 2163 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility 2164 Support in IPv6", RFC 3775, June 2004. 2166 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 2167 Internet Protocol", RFC 4301, December 2005. 2169 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 2170 RFC 4303, December 2005. 2172 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 2173 RFC 4306, December 2005. 2175 [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control 2176 Message Protocol (ICMPv6) for the Internet Protocol 2177 Version 6 (IPv6) Specification", RFC 4443, March 2006. 2179 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 2180 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 2181 September 2007. 2183 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 2184 Address Autoconfiguration", RFC 4862, September 2007. 2186 [RFC5269] Kempf, J. and R. Koodli, "Distributing a Symmetric Fast 2187 Mobile IPv6 (FMIPv6) Handover Key Using SEcure Neighbor 2188 Discovery (SEND)", RFC 5269, June 2008. 2190 [rfc5268] Koodli(Editor), R., "Mobile IPv6 Fast Handovers", 2191 RFC 5268, June 2008, 2192 . 2194 13.2. Informative References 2196 [RFC3290] Bernet, Y., Blake, S., Grossman, D., and A. Smith, "An 2197 Informal Management Model for Diffserv Routers", 2198 RFC 3290, May 2002. 2200 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 2201 Neighbor Discovery (SEND)", RFC 3971, March 2005. 2203 [RFC4068] Koodli, R., "Fast Handovers for Mobile IPv6", RFC 4068, 2204 July 2005. 2206 [RFC5184] Teraoka, F., Gogo, K., Mitsuya, K., Shibui, R., and K. 2208 Mitani, "Unified Layer 2 (L2) Abstractions for Layer 3 2209 (L3)-Driven Fast Handover", RFC 5184, May 2008. 2211 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, 2212 K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, 2213 August 2008. 2215 [dsmipv6] Soliman (Editor), H., "Mobile IPv6 Support for Dual 2216 Stack Hosts and Routers", 2217 draft-ietf-mext-nemo-v4traversal-09.txt, Feb 2009. 2219 [fmipv6] "fmipv6.org : Home Page", http://fmipv6.org . 2221 [mip6-book] Koodli, R. and C. Perkins, "Mobile Internetworking with 2222 IPv6, Chapter 22, John Wiley & Sons.", , July 2007. 2224 [pfmipv6] Yokota, H. and et. al, "Fast Handovers for Proxy Mobile 2225 IPv6", draft-ietf-mipshop-pfmipv6-01.txt, Feb 2009. 2227 [tarzan] "Nautilus6 - Tarzan", 2228 http://software.nautilus6.org/TARZAN/ . 2230 [x.p0057] "E-UTRAN - eHRPD Connectivity and Interworking: Core 2231 Network Aspects", http://www.3gpp2.org/Public_html/ 2232 Misc/ 2233 X.P0057-0_v0.13_E-UTRAN- 2234 eHRPD_Interworking_VV_Due_5_December-2008.pdf. 2236 Appendix A. Contributors 2238 This document has its origins in the fast handover design team in the 2239 erstwhile [mobile ip] working group. The members of this design team 2240 in alphabetical order were; Gopal Dommety, Karim El-Malki, Mohammed 2241 Khalil, Charles Perkins, Hesham Soliman, George Tsirtsis, and Alper 2242 Yegin. 2244 Appendix B. Changes since RFC 5268 2246 Defined the Mobility Header format for HI and HAck messages, and 2247 Mobility Header Option format for IPv6 Address/Prefix option. The 2248 use of ICMP for HI and HAck messages is deprecated. The following 2249 developments led the WG to adopt this change: 2251 o The Proxy Mobile IPv6 protocol [RFC5213] has been adopted for 2252 the deployment of fourth-generation mobile networks. This has 2253 established Mobility Header as the default type for critical IP 2254 mobility signaling. 2256 o The Mobile IPv6 protocol [RFC3775] (particularly, the Dual-stack 2257 MIP6 or DSMIP6 [dsmipv6]) protocol, which is also expected to be 2258 deployed in the fourth-generation mobile networks, similarly 2259 relies on Mobility Header for critical IP mobility signaling. 2261 o The Fast Handover protocol specified in this document is used as 2262 the basis for the Fast Handover for Proxy MIP6 [pfmipv6], which is 2263 adopted by the "enhanced HRPD" (CDMA) networks [x.p0057]. Hence, 2264 the Fast Handover protocol, when used in deployments using either 2265 PMIP6 or MIP6, needs to support the Mobility Header for all its 2266 critical mobility signaling messages. At the same time, use of 2267 ICMP, primarily due to legacy, is unlikely to facilitate critical 2268 IP mobility signaling without a non-trivial departure from 2269 deploying the new Mobility Header signaling protocols. 2271 Therefore, it follows that specifying Mobility Header for the HI and 2272 HAck messages is necessary for the deployment of the protocol along- 2273 side PMIP6 and MIP6 protocols. 2275 Appendix C. Changes since RFC 4068 2277 Following are the major changes and clarifications: 2279 o Specified security association between the MN and its Access 2280 Router in the companion document [RFC5269]. 2282 o Specified Binding Authorization Data for Fast Handovers (BADF) 2283 option to carry the security parameters used for verifying the 2284 authenticity of FBU and FBack messages. The handover key used for 2285 computing the Authenticator is specified in companion documents. 2287 o Specified the security configuration for inter - access router 2288 signaling (HI, HAck). 2290 o Added a section on prefix management between access routers and 2291 illustrated protocol operation over point-to-point links. 2293 o Deprecated FNA, which is a Mobility Header message. In its place, 2294 the Unsolicited Neighbor Advertisement (UNA) message from RFC 4861 2295 is used. 2297 o Combined the IPv6 Address Option and IPv6 Prefix Option. 2299 o Added description of DAD requirement on NAR when determining NCoA 2300 uniqueness in Section 4, "Protocol Details". 2302 o Added a new code value for gratuitous HAck message to trigger a HI 2303 message. 2305 o Added Option-Code 5 in PrRtAdv message to indicate NETLMM usage. 2307 o Clarified protocol usage when DHCP is used for NCoA formulation 2308 (Sections 6.1.2, 3.1, and 5.2). Added a new Code value (5) in 2309 PrRtAdv (Section 6.1.2). 2311 o Clarified that IPv6 Neighbor Discovery operations are a must in 2312 Section 7, "Related Proto Considerations". 2314 o Clarified "PAR = temporary HA" for FBUs sent by a genuine MN to an 2315 unsuspecting CoA. 2317 Author's Address 2319 Rajeev Koodli (editor) 2320 Starent Networks 2321 USA 2323 EMail: rkoodli@starentnetworks.com