idnits 2.17.1 draft-ietf-mipshop-fmipv6-rfc4068bis-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 2035. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2046. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2053. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2059. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 25, 2008) is 5897 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 1985, but not defined == Missing Reference: 'AR-Info' is mentioned on line 1985, but not defined Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MIPSHOP Working Group Rajeev. Koodli (Editor) 3 Internet-Draft February 25, 2008 4 Intended status: Standards Track 5 Expires: August 28, 2008 7 Mobile IPv6 Fast Handovers 8 draft-ietf-mipshop-fmipv6-rfc4068bis-06.txt 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on August 28, 2008. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2008). 39 Abstract 41 Mobile IPv6 enables a Mobile Node to maintain its connectivity to the 42 Internet when moving from an Access Router to another, a process 43 referred to as handover. During this time, the Mobile Node is unable 44 to send or receive packets due to both link switching delay and IP 45 protocol operations. The "handover latency" resulting from standard 46 Mobile IPv6 procedures, namely, movement detection, new Care of 47 Address configuration and Binding Update, is often unacceptable to 48 real-time traffic such as Voice over IP. Reducing the handover 49 latency could be beneficial to non real-time, throughput-sensitive 50 applications as well. This document specifies a protocol to improve 51 handover latency due to Mobile IPv6 procedures. This document does 52 not address improving the link switching latency. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 6 59 3.1. Addressing the Handover Latency . . . . . . . . . . . . . 6 60 3.2. Protocol Operation . . . . . . . . . . . . . . . . . . . . 9 61 3.3. Protocol Operation during Network-initiated Handover . . . 10 62 4. Protocol Details . . . . . . . . . . . . . . . . . . . . . . . 12 63 5. Other Considerations . . . . . . . . . . . . . . . . . . . . . 16 64 5.1. Handover Capability Exchange . . . . . . . . . . . . . . . 16 65 5.2. Determining New Care of Address . . . . . . . . . . . . . 16 66 5.3. Prefix Management . . . . . . . . . . . . . . . . . . . . 17 67 5.4. Packet Loss . . . . . . . . . . . . . . . . . . . . . . . 17 68 5.5. DAD Handling . . . . . . . . . . . . . . . . . . . . . . . 18 69 5.6. Fast or Erroneous Movement . . . . . . . . . . . . . . . . 18 70 6. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 19 71 6.1. New Neighborhood Discovery Messages . . . . . . . . . . . 19 72 6.1.1. Router Solicitation for Proxy Advertisement 73 (RtSolPr) . . . . . . . . . . . . . . . . . . . . . . 19 74 6.1.2. Proxy Router Advertisement (PrRtAdv) . . . . . . . . . 21 75 6.2. Inter-Access Router Messages . . . . . . . . . . . . . . . 25 76 6.2.1. Handover Initiate (HI) . . . . . . . . . . . . . . . . 25 77 6.2.2. Handover Acknowledge (HAck) . . . . . . . . . . . . . 26 78 6.3. New Mobility Header Messages . . . . . . . . . . . . . . . 28 79 6.3.1. Fast Binding Update (FBU) . . . . . . . . . . . . . . 28 80 6.3.2. Fast Binding Acknowledgment (FBack) . . . . . . . . . 30 81 6.4. Unsolicited Neighbor Advertisement (UNA) . . . . . . . . . 31 82 6.5. New Options . . . . . . . . . . . . . . . . . . . . . . . 32 83 6.5.1. IP Address/Prefix Option . . . . . . . . . . . . . . . 33 84 6.5.2. Link-layer Address (LLA) Option . . . . . . . . . . . 34 85 6.5.3. Mobility Header Link-layer Address (MH-LLA) Option . . 35 86 6.5.4. Binding Authorization Data for FMIPv6 (BADF) . . . . . 36 87 6.5.5. Neighbor Advertisement Acknowledgment (NAACK) . . . . 37 88 7. Related Protocol and Device Considerations . . . . . . . . . . 38 89 8. Configurable Parameters . . . . . . . . . . . . . . . . . . . 38 90 9. Security Considerations . . . . . . . . . . . . . . . . . . . 39 91 9.1. Peer Authorization Database Entries when using IKEv2 . . . 40 92 9.2. Security Policy Database Entries . . . . . . . . . . . . . 41 93 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41 94 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 43 95 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 43 96 12.1. Normative References . . . . . . . . . . . . . . . . . . . 43 97 12.2. Informative References . . . . . . . . . . . . . . . . . . 44 98 Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 44 99 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 44 100 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 46 101 Intellectual Property and Copyright Statements . . . . . . . . . . 48 103 1. Introduction 105 Mobile IPv6 [rfc3775] describes the protocol operations for a mobile 106 node to maintain connectivity to the Internet during its handover 107 from one access router to another. These operations involve link 108 layer procedures, movement detection, IP address configuration, and 109 location update. The combined handover latency is often sufficient 110 to affect real-time applications. Throughput-sensitive applications 111 can also benefit from reducing this latency. This document describes 112 a protocol to reduce the handover latency. 114 This specification addresses the following problem: how to allow a 115 mobile node to send packets as soon as it detects a new subnet link, 116 and how to deliver packets to a mobile node as soon as its attachment 117 is detected by the new access router. The protocol defines IP 118 protocol messages necessary for its operation regardless of link 119 technology. It does this without depending on specific link-layer 120 features while allowing link-specific customizations. By definition, 121 this specification considers handovers that interwork with Mobile IP: 122 once attached to its new access router, a MN engages in Mobile IP 123 operations including Return Routability [rfc3775]. There are no 124 special requirements for a mobile node to behave differently with 125 respect to its standard Mobile IP operations. 127 2. Terminology 129 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 130 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "OPTIONAL", and 131 "silently ignore" in this document are to be interpreted as described 132 in RFC 2119 [RFC2119]. 134 The following terminology and abbreviations are used in this document 135 in addition to those defined in [rfc3775]. The reference handover 136 scenario is illustrated in Figure 1. 138 Mobile Node (MN): A Mobile IPv6 host 140 Access Point (AP): A Layer 2 device connected to an IP subnet that 141 offers wireless connectivity to a MN. An Access Point Identifier 142 (AP-ID) refers the AP's L2 address. Sometimes, AP-ID is also 143 referred to as a Basic Service Set IDentifier (BSSID). 145 Access Router (AR): The MN's default router 147 Previous Access Router (PAR): The MN's default router prior to its 148 handover 149 New Access Router (NAR): The MN's anticipated default router 150 subsequent to its handover 152 Previous CoA (PCoA): The MN's Care of Address valid on PAR's 153 subnet 155 New CoA (NCoA): The MN's Care of Address valid on NAR's subnet 157 Handover: A process of terminating existing connectivity and 158 obtaining new IP connectivity 160 Router Solicitation for Proxy Advertisement (RtSolPr): A message 161 from the MN to the PAR requesting information for a potential 162 handover 164 Proxy Router Advertisement (PrRtAdv): A message from the PAR to 165 the MN that provides information about neighboring links 166 facilitating expedited movement detection. The message can also 167 act as a trigger for network-initiated handover. 169 (AP-ID, AR-Info) tuple: Contains an access router's L2 and IP 170 addresses, and prefix valid on the interface to which the Access 171 Point (identified by AP-ID) is attached. The triplet [Router's L2 172 address, Router's IP address and Prefix] is called "AR-Info". See 173 also Section 5.3. 175 Neighborhood Discovery: The process of resolving neighborhood AP- 176 IDs to AR-Info 178 Assigned Addressing: A particular type of NCoA configuration in 179 which the NAR assigns an IPv6 address for the MN. The method by 180 which NAR manages its address pool is not specified in this 181 document. 183 Fast Binding Update (FBU): A message from the MN instructing its 184 PAR to redirect its traffic (towards NAR) 186 Fast Binding Acknowledgment (FBack): A message from the PAR in 187 response to FBU 189 Predictive Fast Handover: The fast handover in which a MN is able 190 to send FBU when it is attached to the PAR, which then establishes 191 forwarding for its traffic (even before the MN attaches to the 192 NAR) 193 Reactive Fast Handover: The fast handover in which a MN is able to 194 send the FBU only after attaching to the NAR 196 Unsolicited Neighbor Advertisement (UNA): The message in [rfc4861] 197 with 'O' bit cleared 199 Fast Neighbor Advertisement (FNA): This message from RFC4068 200 [rfc4068] is deprecated. The UNA message above is the preferred 201 message in this specification. 203 Handover Initiate (HI): A message from the PAR to the NAR 204 regarding a MN's handover 206 Handover Acknowledge (HAck): A message from the NAR to the PAR as 207 a response to HI 209 v +--------------+ 210 +-+ | Previous | < 211 | | ------------ | Access | ------- >-----\ 212 +-+ | Router | < \ 213 MN | (PAR) | \ 214 | +--------------+ +---------------+ 215 | ^ IP | Correspondent | 216 | | Network | Node | 217 V | +---------------+ 218 v / 219 v +--------------+ / 220 +-+ | New | < / 221 | | ------------ | Access | ------- >-----/ 222 +-+ | Router | < 223 MN | (NAR) | 224 +--------------+ 226 Figure 1: Reference Scenario for Handover 228 3. Protocol Overview 230 3.1. Addressing the Handover Latency 232 The ability to immediately send packets from a new subnet link 233 depends on the "IP connectivity" latency, which in turn depends on 234 the movement detection latency and the new CoA configuration latency. 235 Once a MN is IP-capable on the new subnet link, it can send a Binding 236 Update to its Home Agent and one or more correspondents. Once its 237 correspondents successfully process the Binding Update, which 238 typically involves the Return Routability procedure, the MN can 239 receive packets at the new CoA. So, the ability to receive packets 240 from correspondents directly at its new CoA depends on the Binding 241 Update latency as well as the IP connectivity latency. 243 The protocol enables a MN to quickly detect that it has moved to a 244 new subnet by providing the new access point and the associated 245 subnet prefix information when the MN is still connected to its 246 current subnet (i.e., PAR in Figure 1). For instance, a MN may 247 discover available access points using link-layer specific mechanisms 248 (e.g., a "scan" in WLAN) and then request subnet information 249 corresponding to one or more of those discovered access points. The 250 MN may do this after performing router discovery. The MN may also do 251 this at any time while connected to its current router. The result 252 of resolving an identifier associated with an access point is a 253 [AP-ID, AR-Info] tuple, which a MN can use in readily detecting 254 movement: when attachment to an access point with AP-ID takes place, 255 the MN knows the corresponding new router's co-ordinates including 256 its prefix, IP address and L2 address. The "Router Solicitation for 257 Proxy Advertisement (RtSolPr)" and "Proxy Router Advertisement 258 (PrRtAdv)" messages in Section 6.1 are used for aiding movement 259 detection. 261 Through the RtSolPr and PrRtAdv messages, the MN also formulates a 262 prospective new CoA (NCoA), when it is still present on the PAR's 263 link. Hence, the latency due to new prefix discovery subsequent to 264 handover is eliminated. Furthermore, this prospective address can be 265 used immediately after attaching to the new subnet link (i.e., NAR's 266 link) when the MN has received a "Fast Binding Acknowledgment 267 (FBack)" (see Section 6.3.2) message prior to its movement. In the 268 event it moves without receiving an FBack, the MN can still start 269 using NCoA after announcing its attachment through an unsolicited 270 Neighbor Advertisement message (with the 'O' bit set to zero) message 271 [rfc4861]; NAR responds to to this UNA message in case it wishes to 272 provide a different IP address to use. In this way, NCoA 273 configuration latency is reduced. 275 The information provided in the PrRtAdv message can be used even when 276 DHCP [rfc3315] is used to configure an NCoA on the NAR's link. In 277 this case, the protocol supports forwarding using PCoA, and the MN 278 performs DHCP once it attaches to the NAR's link. The MN still 279 formulates an NCoA for FBU processing; however, it MUST NOT send 280 packets using this NCoA. 282 In order to reduce the Binding Update latency, the protocol specifies 283 a binding between the Previous CoA (PCoA) and NCoA. A MN sends a 284 "Fast Binding Update" (see Section 6.3.1) message to its Previous 285 Access Router to establish this tunnel. When feasible, the MN SHOULD 286 send FBU from PAR's link. Otherwise, it should send it immediately 287 after detecting attachment to NAR. An FBU message MUST contain the 288 Binding Authorization Data for FMIPv6 (BADF) option (see 289 Section 6.5.4) in order to ensure that only a legitimate MN that owns 290 the PCoA is able to establish a binding. Subsequent sections 291 describe the protocol mechanics. In any case, the result is that PAR 292 begins tunneling packets arriving for PCoA to NCoA. Such a tunnel 293 remains active until the MN completes the Binding Update with its 294 correspondents. In the opposite direction, the MN SHOULD reverse 295 tunnel packets to PAR, again until it completes Binding Update. And, 296 PAR SHOULD forward the inner packet in the tunnel to its destination 297 (i.e., to the MN's correspondent). Such a reverse tunnel ensures 298 that packets containing PCoA as source IP address are not dropped due 299 to ingress filtering. Even though the MN is IP-capable on the new 300 link, it cannot use NCoA directly with its correspondents without the 301 correspondents first establishing a binding cache entry (for NCoA). 302 Forwarding support for PCoA is provided through a reverse tunnel 303 between the MN and the PAR. 305 Setting up a tunnel alone does not ensure that the MN receives 306 packets as soon as attaching to a new subnet link, unless NAR can 307 detect the MN's presence. A neighbor discovery operation involving a 308 neighbor's address resolution (i.e., Neighbor Solicitation and 309 Neighbor Advertisement) typically results in considerable delay, 310 sometimes lasting multiple seconds. For instance, when arriving 311 packets trigger NAR to send Neighbor Solicitation before the MN 312 attaches, subsequent re-transmissions of address resolution are 313 separated by a default period of one second each. In order to 314 circumvent this delay, a MN announces its attachment immediately with 315 an UNA message that allows NAR to forward packets to the MN right 316 away. Through tunnel establishment for PCoA and fast advertisement, 317 the protocol provides expedited forwarding of packets to the MN. 319 The protocol also provides the following important functionalities. 320 The access routers can exchange messages to confirm that a proposed 321 NCoA is acceptable. For instance, when a MN sends FBU from PAR's 322 link, FBack can be delivered after NAR considers NCoA acceptable to 323 use. This is especially useful when addresses are assigned by the 324 access router. The NAR can also rely on its trust relationship with 325 PAR before providing forwarding support for the MN. That is, it may 326 create a forwarding entry for NCoA subject to "approval" from PAR 327 which it trusts. In addition, buffering for handover traffic may be 328 desirable. Even though the Neighbor Discovery protocol provides a 329 small buffer (typically one or two packets) for packets awaiting 330 address resolution, this buffer may be inadequate for traffic such as 331 VoIP already in progress. The routers may also wish to maintain a 332 separate buffer for servicing the handover traffic. Finally, the 333 access routers could transfer network-resident contexts, such as 334 access control, QoS, header compression, in conjunction with handover 335 (although the context transfer process itself is not specified in 336 this document). For all these operations, the protocol provides 337 "Handover Initiate (HI)" and "Handover Acknowledge (HAck)" messages 338 (see Section 6.2). Both of these messages SHOULD be used. The 339 access routers MUST have necessary security association established 340 by means outside the scope of this document. 342 3.2. Protocol Operation 344 The protocol begins when a MN sends RtSolPr to its access router to 345 resolve one or more Access Point Identifiers to subnet-specific 346 information. In response, the access router (e.g., PAR in Figure 1) 347 sends a PrRtAdv message which contains one or more [AP-ID, AR-Info] 348 tuples. The MN may send RtSolPr at any convenient time, for instance 349 as a response to some link-specific event (a ``trigger'') or simply 350 after performing router discovery. However, the expectation is that 351 prior to sending RtSolPr, the MN has discovered the available APs by 352 link-specific methods. The RtSolPr and PrRtAdv messages do not 353 establish any state at the access router, and their packet formats 354 are defined in Section 6.1. 356 With the information provided in the PrRtAdv message, the MN 357 formulates a prospective NCoA and sends an FBU message. The purpose 358 of FBU is to authorize PAR to bind PCoA to NCoA, so that arriving 359 packets can be tunneled to the new location of the MN. The FBU 360 should be sent from PAR's link whenever feasible. For instance, an 361 internal link-specific trigger could enable FBU transmission from the 362 previous link. 364 When it is not feasible, FBU is sent from the new link. 366 The format and semantics of FBU processing are specified in 367 Section 6.3.1. The FBU message MUST contain the BADF option (see 368 Section 6.5.4) to secure the message. 370 Depending on whether an FBack is received or not on the previous 371 link, which clearly depends on whether FBU was sent in the first 372 place, there are two modes of operation. 374 1. The MN receives FBack on the previous link. This means that 375 packet tunneling would already be in progress by the time the MN 376 handovers to NAR. The MN SHOULD send UNA immediately after 377 attaching to NAR, so that arriving as well as buffered packets can 378 be forwarded to the MN right away. 379 Before sending FBack to MN, PAR can determine whether NCoA is 380 acceptable to NAR through the exchange of HI and HAck messages. 381 When assigned addressing (i.e., addresses are assigned by the 382 router) is used, the proposed NCoA in FBU is carried in HI, and 383 NAR MAY assign the proposed NCoA. Such an assigned NCoA MUST be 384 returned in HAck, and PAR MUST in turn provide the assigned NCoA 385 in FBack. If there is an assigned NCoA returned in FBack, the MN 386 MUST use the assigned address (and not the proposed address in 387 FBU) upon attaching to NAR. 389 2. The MN does not receive FBack on the previous link. One 390 reason for this is that the MN has not sent the FBU. The other is 391 that the MN has left the link after sending the FBU, which may be 392 lost, but before receiving an FBack. Without receiving an FBack 393 in the latter case, the MN cannot ascertain whether PAR has 394 successfully processed the FBU. Hence, the MN (re)sends FBU 395 immediately after sending the UNA message. If NAR chooses to 396 supply a different IP address to use than the NCoA, it MAY sends a 397 Router Advertisement with "Neighbor Advertisement Acknowledge 398 (NAACK)" option in which it includes an alternate IP address for 399 the MN to use. Detailed UNA processing rules are specified in 400 Section 6.4. 402 The scenario in which a MN sends FBU and receives FBack on PAR's link 403 is illustrated in Figure 2. For convenience, this scenario is called 404 "predictive" mode of operation. The scenario in which the MN sends 405 FBU from NAR's link is illustrated in Figure 3. For convenience, 406 this scenario is called "reactive" mode of operation. Note that the 407 reactive mode also includes the case when FBU has been sent from 408 PAR's link but FBack has not been received yet. The Figure is 409 intended to illustrate that the FBU is forwarded through NAR, but it 410 is processed only by the PAR. 412 Finally, the PrRtAdv message may be sent unsolicited, i.e., without 413 the MN first sending RtSolPr. This mode is described in Section 3.3. 415 3.3. Protocol Operation during Network-initiated Handover 417 In some wireless technologies, the handover control may reside in the 418 network even though the decision to undergo handover may be arrived 419 at by cooperation between the MN and the network. In such networks, 420 the PAR can send an unsolicited PrRtAdv containing the link layer 421 address, IP address and subnet prefix of the NAR when the network 422 decides that a handover is imminent. The MN MUST process this 423 PrRtAdv to configure a new care of address on the new subnet, and 424 MUST send an FBU to PAR prior to switching to the new link. After 425 transmitting PrRtAdv, the PAR MUST continue to forward packets to the 426 MN on its current link until the FBU is received. The rest of the 427 operation is the same as that described in Section 3.2. 429 The unsolicited PrRtAdv also allows the network to inform the MN 430 about geographically adjacent subnets without the MN having to 431 explicitly request that information. This can reduce the amount of 432 wireless traffic required for the MN to obtain a neighborhood 433 topology map of links and subnets. Such usage of PrRtAdv is 434 decoupled from the actual handover. See Section 6.1.2. 436 MN PAR NAR 437 | | | 438 |------RtSolPr------->| | 439 |<-----PrRtAdv--------| | 440 | | | 441 |------FBU----------->|----------HI--------->| 442 | |<--------HAck---------| 443 | <--FBack---|--FBack---> | 444 | | | 445 disconnect forward | 446 | packets ===============>| 447 | | | 448 | | | 449 connect | | 450 | | | 451 |------------UNA --------------------------->| 452 |<=================================== deliver packets 453 | | 455 Figure 2: Predictive Fast Handover 457 MN PAR NAR 458 | | | 459 |------RtSolPr------->| | 460 |<-----PrRtAdv--------| | 461 | | | 462 disconnect | | 463 | | | 464 | | | 465 connect | | 466 |-------UNA-----------|--------------------->| 467 |-------FBU-----------|---------------------)| 468 | |<-------FBU----------)| 469 | |<------HI/HAck------->| 470 | | (if necessary) | 471 | forward | 472 | packets(including FBAck)=====>| 473 | | | 474 |<=================================== deliver packets 475 | | 477 Figure 3: Reactive Fast Handover 479 4. Protocol Details 481 All description makes use of Figure 1 as the reference. 483 After discovering one or more nearby access points, the MN sends 484 RtSolPr in order to resolve access point identifiers to subnet router 485 information. A convenient time to do this is after performing router 486 discovery. However, the MN can send RtSolPr at any time, e.g., when 487 one or more new access points are discovered. The MN can also send 488 RtSolPr more than once during its attachment to PAR. The trigger for 489 sending RtSolPr can originate from a link-specific event, such as the 490 promise of a better signal strength from another access point coupled 491 with fading signal quality with the current access point. Such 492 events, often broadly referred to as "L2 triggers", are outside the 493 scope of this document. Nevertheless, they serve as events that 494 invoke this protocol. For instance, when a "link up" indication is 495 obtained on the new link, protocol messages (e.g., UNA) can be 496 immediately transmitted. Implementations SHOULD make use of such 497 triggers whenever available. 499 The RtSolPr message contains one or more AP-IDs. A wildcard requests 500 all available tuples. 502 As a response to RtSolPr, PAR sends a PrRtAdv message which indicates 503 one of the following possible conditions. 505 1. If the PAR does not have an entry corresponding to the new 506 access point, it responds indicating that the new access point is 507 unknown. The MN MUST stop fast handover protocol operations on 508 the current link. The MN MAY send an FBU from its new link. 510 2. If the new access point is connected to the PAR's current 511 interface (to which MN is attached), PAR responds with a Code 512 value indicating that the new access point is connected to the 513 current interface, but not send any prefix information. This 514 scenario could arise, for example, when several wireless access 515 points are bridged into a wired network. No further protocol 516 action is necessary. 518 3. If the new access point is known and the PAR has information 519 about it, then PAR responds indicating that the new access point 520 is known and supply the [AP-ID, AR-Info] tuple. If the new access 521 point is known, but does not support fast handover, the PAR MUST 522 indicate this with Code 3 (see Section 6.1.2). 524 4. If a wildcard is supplied as an identifier for the new access 525 point, the PAR SHOULD supply neighborhood [AP-ID, AR-Info] tuples 526 subject to path MTU restrictions (i.e., provide any 'n' tuples 527 without exceeding the link MTU). 529 When further protocol action is necessary, some implementations may 530 choose to provide buffering support at PAR to address the scenario in 531 which a MN leaves without sending an FBU message from the PAR's link. 532 While the protocol does not forbid such an implementation support, 533 care must be taken to ensure that the PAR continues forwarding 534 packets to the PCoA (i.e., uses a buffer and forward approach). The 535 PAR should also stop buffering once it processes the FBU message. 537 The method by which Access Routers exchange information about their 538 neighbors and thereby allow construction of Proxy Router 539 Advertisements with information about neighboring subnets is outside 540 the scope of this document. 542 The RtSolPr and PrRtAdv messages MUST be implemented by a MN and an 543 access router that supports fast handovers. However, when the 544 parameters necessary for the MN to send packets immediately upon 545 attaching to the NAR are supplied by the link layer handover 546 mechanism itself, use of above messages is optional on such links. 548 After a PrRtAdv message is processed, the MN sends FBU and includes 549 the proposed NCoA. The MN SHOULD send FBU from PAR's link whenever 550 "anticipation" of handover is feasible. When anticipation is not 551 feasible or when it has not received an FBack, the MN sends FBU 552 immediately after attaching to NAR's link. In response to FBU, PAR 553 establishes a binding between PCoA ("Home Address") and NCoA, and 554 sends FBack to MN. Prior to establishing this binding, PAR SHOULD 555 send a HI message to NAR, and receive HAck in response. In order to 556 determine the NAR's address for the HI message, the PAR can perform 557 longest prefix match of NCoA (in FBU) with the prefix list of 558 neighboring access routers. When the source IP address of FBU is 559 PCoA, i.e., the FBU is sent from the PAR's link, the HI message MUST 560 have a Code value set to 0. See Section 6.2.1. When the source IP 561 address of FBU is not PCoA, i.e., the FBU is sent from the NAR's 562 link, the HI message MUST have a Code value of 1. See Section 6.2.1. 564 The HI message contains the PCoA, link-layer address and the NCoA of 565 the MN. In response to processing a HI message with Code 0, the NAR 567 1. determines whether NCoA supplied in the HI message is unique 568 before beginning to defend it. It sends a DAD probe [rfc4862] for 569 NCoA to verify uniqueness. However, in deployments where the 570 probability of address collisions is considered extremely low (and 571 hence not an issue), the parameter DupAddrDetectTransmits (see 572 [rfc4862]) is set to zero on NAR, allowing it to avoid performing 573 DAD on NCoA. The NAR similarly sets DupAddrDetectTransmits to 574 zero in other deployments where DAD is not a concern. Once NCoA 575 is determined to be unique, NAR starts proxying [rfc4861] the 576 address for PROXY_ND_LIFETIME during which the MN is expected to 577 connect to NAR. In case there is already an NCoA present in its 578 data structure (for instance, it has already processed a HI 579 message earlier), NAR may verify if the LLA is the same as its own 580 or that of the MN itself. If so, NAR may allow the use of NCoA. 582 2. allocates NCoA for the MN when assigned addressing is used, 583 creates a proxy neighbor cache entry and begins defending it. The 584 NAR MAY allocate the NCoA proposed in HI. 586 3. MAY create a host route entry for PCoA (on the interface to 587 which the MN is attaching to) in case NCoA cannot be accepted or 588 assigned. This host route entry SHOULD be implemented such that 589 until the MN's presence is detected, either through explicit 590 announcement by the MN or by other means, arriving packets do not 591 invoke neighbor discovery. The NAR SHOULD also set up a reverse 592 tunnel to PAR in this case. 594 4. provides the status of handover request in Handover Acknowledge 595 (HAck) message. 597 When the Code value in HI is 1, NAR MUST skip the above operations. 598 However, it SHOULD be prepared to process any other options which may 599 be defined in the future. Sending a HI message with Code 1 allows 600 NAR to validate the neighbor cache entry it creates for the MN during 601 UNA processing. That is, NAR can make use of the knowledge that its 602 trusted peer (i.e., PAR) has a trust relationship with the MN. 604 If HAck contains an assigned NCoA, it must be included in FBack, and 605 the MN MUST use it. The PAR MAY send FBack to the previous link as 606 well to facilitate faster reception in the event the MN be still 607 present there. The result of FBU and FBack processing is that PAR 608 begins tunneling MN's packets to NCoA. If the MN does not receive an 609 FBack message even after re-transmitting FBU for FBU_RETRIES, it must 610 assume that fast handover support is not available and stop the 611 protocol operation. 613 As soon as the MN establishes link connectivity with the NAR, it 615 1. sends a UNA message (see Section 6.4). If the MN has not 616 received an FBack by the time UNA is being sent, it SHOULD send an 617 FBU message following the UNA message. 619 2. joins the all-nodes multicast group and the solicited-node 620 multicast group corresponding to the NCoA 622 3. starts a DAD probe for NCoA. See [rfc4862]. 624 When a NAR receives a UNA message, it 626 1. deletes its proxy neighbor cache entry, if it exists, updates 627 the state to STALE, and forwards arriving and buffered packets. 629 2. updates an entry in INCOMPLETE state, if it exists, to STALE 630 and forwards arriving and buffered packets. This would be the 631 case if NAR had previously sent a Neighbor Solicitation which went 632 unanswered perhaps because the MN had not yet attached to the 633 link. 635 The buffer for handover traffic should be linked to this UNA 636 processing. The exact mechanism is implementation dependent. 638 The NAR may choose to provide different IP address other than the 639 NCoA. This is possible if it is proxying the NCoA. In such a case, 640 it 641 1. MAY send a Router Advertisement with the NAACK option in which 642 it includes an alternate IP address for use. This message MUST be 643 sent to the source IP address present in UNA using the same Layer 644 2 address present in UNA. 646 If the MN receives an IP address in the NAACK option, it MUST use it 647 and send an FBU using the new CoA. As a special case, the address 648 supplied in NAACK could be PCoA itself, in which case the MN MUST NOT 649 send any more FBUs. The Status codes for NAACK option are specified 650 in Section 6.5.5. 652 Once the MN has confirmed its NCoA (either through DAD or when 653 provided for by the NAR), it SHOULD send a Neighbor Advertisement 654 message with the 'O' bit set, to the all-nodes multicast address. 655 This message allows MN's neighbors to update their neighbor cache 656 entries. 658 For data forwarding, the PAR tunnels packets using its global IP 659 address valid on the interface to which the MN was attached. The MN 660 reverse tunnels its packets to the same global address of PAR. The 661 tunnel end-point addresses must be configured accordingly. When PAR 662 receives a reverse tunneled packet, it must verify if a secure 663 binding exists for the MN identified by PCoA in the tunneled packet, 664 before forwarding the packet. 666 5. Other Considerations 668 5.1. Handover Capability Exchange 670 The MN expects a PrRtAdv in response to its RtSolPr message. If the 671 MN does not receive a PrRtAdv message even after RTSOLPR_RETRIES, it 672 must assume that PAR does not support the fast handover protocol and 673 stop sending any more RtSolPr messages. 675 Even if a MN's current access router is capable of providing fast 676 handover support, the new access router may not be capable of 677 providing such support. This is indicated to the MN during 678 "runtime", through the PrRtAdv message with a Code value of 3 (see 679 Section 6.1.2). 681 5.2. Determining New Care of Address 683 Typically, the MN formulates its prospective NCoA using the 684 information provided in a PrRtAdv message, and sends FBU. This NCoA 685 can be provided to NAR in the HI message. NAR provides a disposition 686 of HI, and hence the NCoA itself, in the HAck message indicating 687 whether NCoA is acceptable. However, the MN itself does not have to 688 wait on PAR's link for this exchange to take place. It can handover 689 any time after sending the FBU message; sometimes it may be forced to 690 handover without sending the FBU. In any case, it can still confirm 691 using NCoA from NAR's link by sending the UNA message. 693 If PrRtAdv message carries a NCoA, the MN MUST use it as its 694 prospective NCoA. 696 When DHCP is used, the protocol supports forwarding for PCoA only. 697 In this case, the MN MUST perform DHCP operations once it attaches to 698 the NAR even though it formulates an NCoA for transmitting the FBU. 699 This is indicated in the PrRtAdv message with Code = 5. 701 5.3. Prefix Management 703 As defined in Section 2, the Prefix part of ``AR-Info'' is the prefix 704 valid on the interface to which the AP is attached. This document 705 does not specify how this Prefix is managed, it's length and 706 assignment policies. The protocol operation specified in this 707 document works regardless of these considerations. Often, but not 708 necessarily always, this Prefix may be the aggregate prefix (such as 709 /48) valid on the interface. In some deployments, each MN may have 710 its own per-mobile prefix (such as a /64) used for generating the 711 NCoA. Some point-to-point links may use such a deployment. 713 When per-mobile prefix assignment is used, the ``AR-Info'' advertised 714 in PrRtAdv still includes the (aggregate) prefix valid on the 715 interface to which the target AP is attached, unless the access 716 routers communicate with each other (using HI and HAck messages) to 717 manage per-mobile prefix. The MN still formulates an NCoA using the 718 aggregate prefix. However, an alternate NCoA based on the per-mobile 719 prefix is returned by NAR in the HAck message. This alternate NCoA 720 is provided to the MN in either the FBack message or in the NAACK 721 option. 723 5.4. Packet Loss 725 Handover involves link switching, which may not be exactly co- 726 ordinated with fast handover signaling. Furthermore, the arrival 727 pattern of packets is dependent on many factors, including 728 application characteristics, network queuing behaviors etc. Hence, 729 packets may arrive at NAR before the MN is able to establish its link 730 there. These packets will be lost unless they are buffered by the 731 NAR. Similarly, if the MN attaches to NAR and then sends an FBU 732 message, packets arriving at PAR until FBU is processed will be lost 733 unless they are buffered. This protocol provides an option to 734 indicate request for buffering at the NAR in the HI message. When 735 the PAR requests this feature (for the MN), it SHOULD also provide 736 its own support for buffering. 738 5.5. DAD Handling 740 Duplicate Address Detection (DAD) was defined in [rfc4862] to avoid 741 address duplication on links when stateless address auto- 742 configuration is used. The use of DAD to verify the uniqueness of an 743 IPv6 address configured through stateless auto-configuration adds 744 delays to a handover. The probability of an interface identifier 745 duplication on the same subnet is very low, however it cannot be 746 ignored. So, this protocol SHOULD only be used in deployments where 747 the probability of such address collisions is extremely low or it is 748 not a concern (because of the address management procedure deployed). 749 The protocol requires the NAR to send a DAD probe before it starts 750 defending NCoA. However, this DAD delay can be turned off by setting 751 DupAddrDetectTransmits to zero on NAR ([rfc4862]). 753 This document specifies messages which can be used to provide 754 duplicate-free addresses but the document does not specify how to 755 create or manage such duplicate-free addresses. In some cases the 756 NAR may already have the knowledge required to assess whether the 757 MN's address is a duplicate or not before the MN moves to the new 758 subnet. For example, in some deployments, the NAR may maintain a 759 pool of duplicate-free addresses in a list for handover purposes. In 760 such cases, the NAR can provide this disposition in the HAck message 761 (see Section 6.2.2) or in the NAACK option (see Section 6.5.5). 763 5.6. Fast or Erroneous Movement 765 Although this specification is for fast handover, the protocol has 766 its limits in terms of how fast a MN can move. A special case of 767 fast movement is ping-pong, where a MN moves between the same two 768 access points rapidly. Another instance of the same problem is 769 erroneous movement i.e., the MN receives information prior to a 770 handover that it is moving to a new access point but it either moves 771 to a different one or aborts movement altogether. All of the above 772 behaviors are usually the result of link layer idiosyncrasies and 773 thus are often tackled at the link layer itself. 775 IP layer mobility, however, introduces its own limits. IP layer 776 handovers should occur at a rate suitable for the MN to update the 777 binding of, at least, its Home Agent and preferably that of every CN 778 with which it is in communication. A MN that moves faster than 779 necessary for this signaling to complete, which may be of the order 780 of few seconds, may start losing packets. The signaling overhead 781 over the air and in the network may increase significantly, 782 especially in the case of rapid movement between several access 783 routers. To avoid the signaling overhead, the following measures are 784 suggested. 786 A MN returning to the PAR before updating the necessary bindings when 787 present on NAR MUST send a Fast Binding Update with Home Address 788 equal to the MN's PCoA and a lifetime of zero, to the PAR. The MN 789 should have a security association with the PAR since it performed a 790 fast handover to the NAR. The PAR, on receiving this Fast Binding 791 Update, will check its set of outgoing (temporary fast handover) 792 tunnels. If it finds a match it SHOULD terminate that tunnel; i.e., 793 start delivering packets directly to the node instead. In order for 794 PAR to process such an FBU, the lifetime of the security association 795 has to be at least that of the tunnel itself. 797 Temporary tunnels for the purposes of fast handovers should use short 798 lifetimes (of the order of a small number of seconds or less). The 799 lifetime of such tunnels should be enough to allow a MN to update all 800 its active bindings. The default lifetime of the tunnel should be 801 the same as the lifetime value in the FBU message. 803 The effect of erroneous movement is typically limited to loss of 804 packets since routing can change and the PAR may forward packets 805 towards another router before the MN actually connects to that 806 router. If the MN discovers itself on an unanticipated access 807 router, it SHOULD send a new Fast Binding Update to the PAR. This 808 FBU supersedes the existing binding at PAR and the packets will be 809 redirected to the new confirmed location of the MN. 811 6. Message Formats 813 All the ICMPv6 messages have a common Type specified in [rfc2463]. 814 The messages are distinguished based on the Subtype field (see 815 below). For all the ICMPv6 messages, the checksum is defined in 816 [rfc2463]. 818 6.1. New Neighborhood Discovery Messages 820 6.1.1. Router Solicitation for Proxy Advertisement (RtSolPr) 822 Mobile Nodes send Router Solicitation for Proxy Advertisement in 823 order to prompt routers for Proxy Router Advertisements. All the 824 link-layer address options have the format defined in Section 6.5.2. 826 0 1 2 3 827 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 828 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 829 | Type | Code | Checksum | 830 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 831 | Subtype | Reserved | Identifier | 832 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 833 | Options ... 834 +-+-+-+-+-+-+-+-+-+-+-+- 836 Figure 4: Router Solicitation for Proxy Advertisement (RtSolPr) 837 Message 839 IP Fields: 841 Source Address: An IP address assigned to the sending interface 843 Destination Address: The address of the Access Router or the 844 all routers multicast address. 846 Hop Limit: 255. See RFC 2461. 848 ICMP Fields: 850 Type: To be assigned by IANA 852 Code: 0 854 Checksum: The ICMPv6 checksum. 856 Subtype: 2 858 Reserved: MUST be set to zero by the sender and ignored by the 859 receiver. 861 Identifier: MUST be set by the sender so that replies can be 862 matched to this Solicitation. 864 Valid Options: 866 Source Link-layer Address: When known, the link-layer address 867 of the sender SHOULD be included using the Link-Layer Address 868 option. See LLA option format below. 870 New Access Point Link-layer Address: The link-layer address or 871 identification of the access point for which the MN requests 872 routing advertisement information. It MUST be included in all 873 RtSolPr messages. More than one such address or identifier can 874 be present. This field can also be a wildcard address. See 875 LLA Option below. 877 Future versions of this protocol may define new option types. 878 Receivers MUST silently ignore any options that they do not recognize 879 and continue processing the rest of the message. 881 Including the source LLA option allows the receiver to record the 882 sender's L2 address so that neighbor discovery, when the receiver 883 needs to send packets back to the sender (of RtSolPr message), can be 884 avoided. 886 When a wildcard is used for New Access Point LLA, no other New Access 887 Point LLA options must be present. 889 A Proxy Router Advertisement (PrRtAdv) message should be received by 890 the MN as a response to RtSolPr. If such a message is not received 891 in a short time period but no less than twice the typical round trip 892 time (RTT) over the access link or 100 milliseconds if RTT is not 893 known, it SHOULD resend RtSolPr message. Subsequent retransmissions 894 can be up to RTSOLPR_RETRIES, but MUST use an exponential backoff in 895 which the timeout period (i.e., 2xRTT or 100 milliseconds) is doubled 896 prior to each instance of retransmission. If Proxy Router 897 Advertisement is not received by the time the MN disconnects from the 898 PAR, the MN SHOULD send FBU immediately after configuring a new CoA. 900 When RtSolPr messages are sent more than once, they MUST be rate 901 limited with MAX_RTSOLPR_RATE per second. During each use of 902 RtSolPr, exponential backoff is used for retransmissions. 904 6.1.2. Proxy Router Advertisement (PrRtAdv) 906 Access routers send out Proxy Router Advertisement message 907 gratuitously if the handover is network-initiated or as a response to 908 RtSolPr message from a MN, providing the link-layer address, IP 909 address and subnet prefixes of neighboring routers. All the link- 910 layer address options have the format defined in 6.4.3. 912 0 1 2 3 913 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 914 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 915 | Type | Code | Checksum | 916 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 917 | Subtype | Reserved | Identifier | 918 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 919 | Options ... 920 +-+-+-+-+-+-+-+-+-+-+-+- 922 Figure 5: Proxy Router Advertisement (PrRtAdv) Message 924 IP Fields: 926 Source Address: MUST be the link-local address assigned to the 927 interface from which this message is sent. 929 Destination Address: The Source Address of an invoking Router 930 Solicitation for Proxy Advertisement or the address of the node 931 the Access Router is instructing to handover. 933 Hop Limit: 255. See RFC 2461. 935 ICMP Fields: 937 Type: To be assigned by IANA 939 Code: 0, 1, 2, 3, 4 or 5. See below. 941 Checksum: The ICMPv6 checksum. 943 Subtype: 3 945 Reserved: MUST be set to zero by the sender and ignored by the 946 receiver. 948 Identifier: Copied from Router Solicitation for Proxy 949 Advertisement or set to Zero if unsolicited. 951 Valid Options in the following order: 953 Source Link-layer Address: When known, the link-layer address 954 of the sender SHOULD be included using the Link-Layer Address 955 option. See LLA option format below. 957 New Access Point Link-layer Address: The link-layer address or 958 identification of the access point is copied from RtSolPr 959 message. This option MUST be present. 961 New Router's Link-layer Address: The link-layer address of the 962 Access Router for which this message is proxied for. This 963 option MUST be included when Code is 0 or 1. 965 New Router's IP Address: The IP address of NAR. This option 966 MUST be included when Code is 0 or 1. 968 New Router Prefix Information Option: Specifies the prefix of 969 the Access Router the message is proxied for and is used for 970 address auto-configuration. This option MUST be included when 971 Code is 0 or 1. However, when this prefix is the same as what 972 is used in the New Router's IP Address option (above), the 973 Prefix Information option need not be present. 975 New CoA Option: MAY be present when PrRtAdv is sent 976 unsolicited. PAR MAY compute new CoA using NAR's prefix 977 information and the MN's L2 address, or by any other means. 979 Future versions of this protocol may define new option types. 980 Receivers MUST silently ignore any options they do not recognize and 981 continue processing the message. 983 Currently, Code values 0, 1, 2, 3, 4 and 5 are defined. 985 A Proxy Router Advertisement with Code 0 means that the MN should use 986 the [AP-ID, AR-Info] tuple (present in the options above) for 987 movement detection and NCoA formulation. The Option-Code field in 988 the New Access Point LLA option in this case is 1 reflecting the LLA 989 of the access point for which the rest of the options are related. 990 Multiple tuples may be present. 992 A Proxy Router Advertisement with Code 1 means that the message is 993 sent unsolicited. If a New CoA option is present following the New 994 Router Prefix Information option, the MN SHOULD use the supplied NCoA 995 and send FBU immediately or else stand to lose service. This message 996 acts as a network-initiated handover trigger. See Section 3.3. The 997 Option-Code field in the New Access Point LLA option (see below) in 998 this case is 1 reflecting the LLA of the access point for which the 999 rest of the options are related. 1001 A Proxy Router Advertisement with Code 2 means that no new router 1002 information is present. Each New Access Point LLA option contains an 1003 Option-Code value (described below) which indicates a specific 1004 outcome. 1006 When the Option-Code field in the New Access Point LLA option is 1007 5, handover to that access point does not require change of CoA. 1008 This would be the case, for instance, when a number of access 1009 points are connected to the same router interface, or when network 1010 based mobility management mechanisms ensure that the specific 1011 mobile node always observes the same prefix regardless of whether 1012 there is a separate router attached to the target access point. 1013 No other options are required in this case. 1015 When the Option-Code field in the New Access Point LLA option is 1016 6, PAR is not aware of the Prefix Information requested. The MN 1017 SHOULD attempt to send FBU as soon as it regains connectivity with 1018 the NAR. No other options are required in this case. 1020 When the Option-Code field in the New Access Point LLA option is 1021 7, it means that the NAR does not support fast handover. The MN 1022 MUST stop fast handover protocol operations. No other options are 1023 required in this case. 1025 A Proxy Router Advertisement with Code 3 means that new router 1026 information is present only for a subset of access points requested. 1027 The Option-Code field values (defined above including a value of 1) 1028 distinguish different outcomes for individual access points. 1030 A Proxy Router Advertisement with Code 4 means that the subnet 1031 information regarding neighboring access points is sent unsolicited, 1032 but the message is not a handover trigger, unlike when the message is 1033 sent with Code 1. Multiple tuples may be present. 1035 A Proxy Router Advertisement with Code 5 means that the MN may use 1036 the new router information present for detecting movement to a new 1037 subnet, but the MN must perform DHCP [rfc3315] upon attaching to the 1038 NAR's link. The PAR and NAR will forward packets to the PCoA of the 1039 MN. The MN must still formulate an NCoA for transmitting FBU (using 1040 the information sent in this message), but that NCoA will not be used 1041 for forwarding packets. 1043 When a wildcard AP identifier is supplied in the RtSolPr message, the 1044 PrRtAdv message should include any 'n' [Access Point Identifier, 1045 Link-layer address option, Prefix Information Option] tuples 1046 corresponding to the PAR's neighborhood. 1048 6.2. Inter-Access Router Messages 1050 6.2.1. Handover Initiate (HI) 1052 The Handover Initiate (HI) is an ICMPv6 message sent by an Access 1053 Router (typically PAR) to another Access Router (typically NAR) to 1054 initiate the process of a MN's handover. 1056 0 1 2 3 1057 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 1058 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1059 | Type | Code | Checksum | 1060 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1061 | Subtype |S|U| Reserved | Identifier | 1062 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1063 | Options ... 1064 +-+-+-+-+-+-+-+-+-+-+-+- 1066 Figure 6: Handover Initiate (HI) Message 1068 IP Fields: 1070 Source Address: The IP address of the PAR 1072 Destination Address: The IP address of the NAR 1074 ICMP Fields: 1076 Type: To be assigned by IANA 1078 Code: 0 or 1. See below 1080 Checksum: The ICMPv6 checksum. 1082 Subtype: 4 1084 'S' flag: Assigned address configuration flag. When set, this 1085 message requests a new CoA to be returned by the destination. 1086 May be set when Code = 0. MUST be 0 when Code = 1. 1088 'U' flag: Buffer flag. When set, the destination SHOULD buffer 1089 any packets towards the node indicated in the options of this 1090 message. Used when Code = 0, SHOULD be set to 0 when Code = 1. 1092 Reserved: MUST be set to zero by the sender and ignored by the 1093 receiver. 1095 Identifier: MUST be set by the sender so replies can be matched 1096 to this message. 1098 Valid Options: 1100 Link-layer address of MN: The link-layer address of the MN that is 1101 undergoing handover to the destination (i.e., NAR). This option 1102 MUST be included so that the destination can recognize the MN. 1104 Previous Care of Address: The IP address used by the MN while 1105 attached to the originating router. This option SHOULD be 1106 included so that host route can be established in case necessary. 1108 New Care of Address: The IP address the MN wishes to use when 1109 connected to the destination. When the `S' bit is set, NAR MAY 1110 assign this address. 1112 The PAR uses a Code value of 0 when it processes an FBU with PCoA as 1113 source IP address. The PAR uses a Code value of 1 when it processes 1114 an FBU whose source IP address is not PCoA. 1116 If Handover Acknowledge (HAck) message is not received as a response 1117 in a short time period but no less than twice the typical round trip 1118 time (RTT) between source and destination, or 100 milliseconds if RTT 1119 is not known, the Handover Initiate SHOULD be re-sent. Subsequent 1120 retransmissions can be up to HI_RETRIES, but MUST use exponential 1121 backoff in which the timeout period (i.e., 2xRTT or 100 milliseconds) 1122 is doubled during each instance of retransmission. 1124 6.2.2. Handover Acknowledge (HAck) 1126 The Handover Acknowledgment message is a new ICMPv6 message that MUST 1127 be sent (typically by NAR to PAR) as a reply to the Handover Initiate 1128 message. 1130 0 1 2 3 1131 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 1132 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1133 | Type | Code | Checksum | 1134 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1135 | Subtype | Reserved | Identifier | 1136 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1137 | Options ... 1138 +-+-+-+-+-+-+-+-+-+-+-+- 1140 Figure 7: Handover Acknowledge (HAck) Message 1142 IP Fields: 1144 Source Address: Copied from the destination address of the 1145 Handover Initiate Message to which this message is a response. 1147 Destination Address: Copied from the source address of the 1148 Handover Initiate Message to which this message is a response. 1150 ICMP Fields: 1152 Type: To be assigned by IANA 1154 Code: 1156 0: Handover Accepted, NCoA valid 1157 1: Handover Accepted, NCoA not valid or in use 1158 2: Handover Accepted, NCoA assigned (used in Assigned 1159 addressing) 1160 3: Handover Accepted, use PCoA 1161 4: Message sent unsolicited, usually to trigger a HI message 1162 128: Handover Not Accepted, reason unspecified 1163 129: Administratively prohibited 1164 130: Insufficient resources 1166 Checksum: The ICMPv6 checksum. 1168 Subtype: 5 1170 Reserved: MUST be set to zero by the sender and ignored by the 1171 receiver. 1173 Identifier: Copied from the corresponding field in the Handover 1174 Initiate message this message is in response to. 1176 Valid Options: 1178 New Care of Address: If the S flag in the Handover Initiate message 1179 is set, this option MUST be used to provide NCoA the MN should use 1180 when connected to this router. This option MAY be included even when 1181 `S' bit is not set, e.g., Code 2 above. 1183 Upon receiving a HI message, the NAR MUST respond with a Handover 1184 Acknowledge message. If the `S' flag is set in the HI message, the 1185 NAR SHOULD include the New Care of Address option and a Code 3. 1187 The NAR MAY provide support for PCoA (instead of accepting or 1188 assigning NCoA), using a host route entry to forward packets to the 1189 PCoA, and using a tunnel to the PAR to forward packets from the MN 1190 (sent with PCoA as source IP address). This host route entry SHOULD 1191 be used to forward packets once the NAR detects that the particular 1192 MN is attached to its link. The NAR indicates forwarding support for 1193 PCoA using Code value 3 in the HAck message. Subsequently, PAR 1194 establishes a tunnel to NAR in order to forward packets arriving for 1195 PCoA. 1197 When responding to a HI message containing a Code value 1, the Code 1198 values 1, 2, and 4 in the HAck message are not relevant. 1200 Finally, the new access router can always refuse handover, in which 1201 case it should indicate the reason in one of the available Code 1202 values. 1204 6.3. New Mobility Header Messages 1206 Mobile IPv6 uses a new IPv6 header type called Mobility Header 1207 [rfc3775]. The Fast Binding Update, Fast Binding Acknowledgment and 1208 Fast Neighbor Advertisement messages use the Mobility Header. 1210 6.3.1. Fast Binding Update (FBU) 1212 The Fast Binding Update message is identical to the Mobile IPv6 1213 Binding Update (BU) message. However, the processing rules are 1214 slightly different. 1216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1217 | Sequence # | 1218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1219 |A|H|L|K| Reserved | Lifetime | 1220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1221 | | 1222 . . 1223 . Mobility options . 1224 . . 1225 | | 1226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1228 Figure 8: Fast Binding Update (FBU) Message 1230 IP Fields: 1232 Source address: The PCoA or NCoA 1234 Destination Address: The IP address of the Previous Access 1235 Router 1237 `A' flag: MUST be set to one to request PAR to send a Fast Binding 1238 Acknowledgment message. 1240 `H' flag: MUST be set to one. See [rfc3775]. 1242 `L' flag: See [rfc3775]. 1244 `K' flag: See [rfc3775]. 1246 Reserved: This field is unused. MUST be set zero. 1248 Sequence Number: See See [rfc3775]. 1250 Lifetime: The requested time in seconds for which the sender 1251 wishes to have a binding. 1253 Mobility Options: MUST contain alternate CoA option set to NCoA 1254 when FBU is sent from PAR's link. MUST contain the Binding 1255 Authorization Data for FMIP (BADF) option. See Section 6.5.4. 1256 MAY contain the Mobility Header LLA option (see Section 6.5.3). 1258 The MN sends FBU message any time after receiving a PrRtAdv message. 1259 If the MN moves prior to receiving a PrRtAdv message, it SHOULD send 1260 a FBU to the PAR after configuring NCoA on the NAR according to 1261 Neighbor Discovery and IPv6 Address Configuration protocols. When 1262 the MN moves without having received a PrRtAdv message, it cannot 1263 transmit a UNA message upon attaching to the NAR's link. 1265 The source IP address is PCoA when FBU is sent from PAR's link, and 1266 the source IP address is NCoA when sent from NAR's link. When source 1267 IP address is PCoA, the MN MUST include the alternate CoA option set 1268 to NCoA. The PAR MUST process the FBU even though the address in the 1269 alternate CoA option is different from that in the source IP address, 1270 and ensure that the address in the alternate CoA option is used in 1271 the New CoA option in the HI message to NAR. 1273 The FBU MUST also include the Home Address Option set to PCoA. A FBU 1274 message MUST be protected so that PAR is able to determine that the 1275 FBU message is sent by a MN that legitimately owns the PCoA. 1277 6.3.2. Fast Binding Acknowledgment (FBack) 1279 The Fast Binding Acknowledgment message is sent by the PAR to 1280 acknowledge receipt of a Fast Binding Update message in which the `A' 1281 bit is set. If PAR sends a HI message to the NAR after processing an 1282 FBU, the FBack message SHOULD NOT be sent to the MN before the PAR 1283 receives a HAck message from the NAR. The PAR MAY send the FBack 1284 immediately in the reactive mode however. The Fast Binding 1285 Acknowledgment MAY also be sent to the MN on the old link. 1287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1288 | Status |K| Reserved | 1289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1290 | Sequence # | Lifetime | 1291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1292 | | 1293 . . 1294 . Mobility options . 1295 . . 1296 | | 1297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1299 Figure 9: Fast Binding Acknowledgment (FBack) Message 1301 IP Fields: 1303 Source address: The IP address of the Previous Access Router 1304 Destination Address: The NCoA, and optionally PCoA 1306 Status: 8-bit unsigned integer indicating the disposition of the 1307 Fast Binding Update. Values of the Status field less than 128 1308 indicate that the Binding Update was accepted by the receiving 1309 node. The following such Status values are currently defined: 1311 0 Fast Binding Update accepted 1312 1 Fast Binding Update accepted but NCoA is invalid. Use NCoA 1313 supplied in ``alternate'' CoA 1315 Values of the Status field greater than or equal to 128 indicate 1316 that the Binding Update was rejected by the receiving node. The 1317 following such Status values are currently defined: 1319 128: Reason unspecified 1320 129: Administratively prohibited 1321 130: Insufficient resources 1322 131: Incorrect interface identifier length 1324 `K' flag: See See [rfc3775]. 1326 Reserved: An unused field. MUST be set to zero. 1328 Sequence Number: Copied from FBU message for use by the MN in 1329 matching this acknowledgment with an outstanding FBU. 1331 Lifetime: The granted lifetime in seconds for which the sender of 1332 this message will retain a binding for traffic redirection. 1334 Mobility Options: MUST contain ``alternate'' CoA if Status is 1. 1335 MUST contain the Binding Authorization Data for FMIP (BADF) 1336 option. See 6.4.5. 1338 6.4. Unsolicited Neighbor Advertisement (UNA) 1340 This is the same message as in [rfc4861] with the requirement that 1341 the 'O' bit is always set to zero. Since this is an unsolicited 1342 message, the 'S' bit is zero, and since this is sent by a MN, the 'R' 1343 bit is also zero. 1345 If NAR is proxying the NCoA (as a result of HI and HAck exchange), 1346 then UNA processing has additional steps (see below). If NAR is not 1347 proxying the NCoA (for instance, HI and HAck exchange has not taken 1348 place), then UNA processing follows the same procedure as specified 1349 in [rfc4861]. Implementations MAY retransmit UNA subject to the 1350 specification in [rfc4861] (Section 7.2.6) while noting that the 1351 default RetransTimer value is large for handover purposes. 1353 The Source Address in UNA MUST be the NCoA. The Destination Address 1354 is typically the all-nodes multicast address; however, some 1355 deployments may not prefer transmission to a multicast address. In 1356 such cases, the Destination Address SHOULD be the NAR's IP address. 1358 The Target Address MUST include the NCoA, and Target link-layer 1359 address MUST include the MN's LLA. 1361 The MN sends a UNA message to the NAR, as soon as it regains 1362 connectivity on the new link. Arriving or buffered packets can be 1363 immediately forwarded. If NAR is proxying NCoA, it creates a 1364 neighbor cache entry in STALE state but forwards packets as it 1365 determines bidirectional reachability according to the standard 1366 Neighbor Discovery procedure. If there is an entry in INCOMPLETE 1367 state without a link-layer address, it sets it to STALE, again 1368 according to the procedure in [rfc4861]. 1370 The NAR MAY wish to provide a different IP address to the MN than the 1371 one in UNA message. In such a case, NAR MUST delete the proxy entry 1372 for NCoA and send a Router Advertisement with NAACK option containing 1373 the new IP address. 1375 The combination of NCoA (present in source IP address) and the Link- 1376 Layer Address (present as a Target LLA) SHOULD be used to distinguish 1377 the MN from other nodes. 1379 6.5. New Options 1381 All the options are of the form shown in Figure 10. 1383 The Type values are defined from the Neighbor Discovery options 1384 space. The Length field is in units of 8 octets, except for the 1385 Mobility Header Link-Layer Address option, whose Length field is in 1386 units of octets in accordance with Section 6.2 in [rfc3775]. And, 1387 Option-Code provides additional information for each of the options 1388 (see individual options below). 1390 0 1 2 3 1391 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 1392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1393 | Type | Length | Option-Code | | 1394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1395 ~ ... ~ 1396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1398 Figure 10: Option Format 1400 6.5.1. IP Address/Prefix Option 1402 This option is sent in the Proxy Router Advertisement, the Handover 1403 Initiate, and Handover Acknowledge messages. 1405 0 1 2 3 1406 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 1407 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1408 | Type | Length | Option-Code | Prefix Length | 1409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1410 | Reserved | 1411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1412 | | 1413 + + 1414 | | 1415 + IPv6 Address + 1416 | | 1417 + + 1418 | | 1419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1421 Figure 11: IPv6 Address/Prefix Option 1423 Type: 17 1425 Length: The size of this option in 8 octets including the Type, 1426 Option-Code and Length fields. 1428 Option-Code: 1430 1: Old Care-of Address 1431 2: New Care-of Address 1432 3: NAR's IP address 1433 4: NAR's Prefix, sent in PrRtAdv. The Prefix Length field 1434 contains the number of valid leading bits in the prefix. The 1435 bits in the prefix after the prefix length are reserved and 1436 MUST be initialized to zero by the sender and ignored by the 1437 receiver. 1439 Prefix Length: 8-bit unsigned integer that indicates the length of 1440 the IPv6 Address Prefix. The value ranges from 0 to 128. 1442 Reserved: MUST be set to zero by the sender and MUST be ignored by 1443 the receiver. 1445 IPv6 address: The IP address defined by the Option-Code field. 1447 6.5.2. Link-layer Address (LLA) Option 1449 0 1 2 3 1450 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 1451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1452 | Type | Length | Option-Code | LLA... 1453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1455 Figure 12: Link-Layer Address Option 1457 Type: 19 1459 Length: The size of this option in 8 octets including the Type, 1460 Option-Code and Length fields. 1462 Option-Code: 1464 0: wildcard requesting resolution for all nearby access points 1465 1: Link-layer Address of the New Access Point 1466 2: Link-layer Address of the MN 1467 3: Link-layer Address of the NAR (i.e., Proxied Originator) 1468 4: Link-layer Address of the source of RtSolPr or PrRtAdv 1469 message 1470 5: The access point identified by the LLA belongs to the 1471 current interface of the router 1472 6: No prefix information available for the access point 1473 identified by the LLA 1474 7: No fast handovers support available for the access point 1475 identified by the LLA 1477 LLA: The variable length link-layer address. 1479 The LLA Option does not have a length field for the LLA itself. The 1480 implementations must consult the specific link layer over which the 1481 protocol is run in order to determine the content and length of the 1482 LLA. 1484 Depending on the size of individual LLA option, appropriate padding 1485 MUST be used to ensure that the entire option size is a multiple of 8 1486 octets. 1488 The New Access Point Link Layer address contains the link-layer 1489 address of the access point for which handover is about to be 1490 attempted. This is used in the Router Solicitation for Proxy 1491 Advertisement message. 1493 The MN Link-Layer address option contains the link-layer address of a 1494 MN. It is used in the Handover Initiate message. 1496 The NAR (i.e., Proxied Originator) Link-Layer address option contains 1497 the Link Layer address of the Access Router for which the Proxy 1498 Router Solicitation message refers to. 1500 6.5.3. Mobility Header Link-layer Address (MH-LLA) Option 1502 This option is identical to the LLA option, but is carried in the 1503 Mobility Header messages, e.g., FBU. In the future, other Mobility 1504 Header messages may also make use of this option. The format of the 1505 option is shown in Figure 13. There are no alignment requirements 1506 for this option. 1508 0 1 2 3 1509 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 1510 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1511 | Type | Length | 1512 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1513 | Option-Code | LLA .... 1514 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1516 Figure 13: Mobility Header Link-Layer Address Option 1518 Type: 7 1520 Length: The size of this option in octets not including the Type 1521 and Length fields. 1523 Option-Code: 2 Link-layer Address of the MN 1525 LLA: The variable length link-layer address. 1527 6.5.4. Binding Authorization Data for FMIPv6 (BADF) 1529 This option MUST be present in FBU and FBack messages. The security 1530 association between the MN and the PAR is established by companion 1531 protocols [rfc-ho-send]. This option specifies how to compute and 1532 verify a MAC using the established security association. 1534 The format of this option is shown in Figure 14. 1536 0 1 2 3 1537 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 1538 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1539 | Type | Option Length | 1540 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1541 | SPI | 1542 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1543 | | 1544 + + 1545 | Authenticator | 1546 + + 1547 | | 1548 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1550 Figure 14: Binding Authorization Data for FMIPv6 (BADF) Option 1552 Type: To be assigned by IANA 1554 Option Length: The length of the Authenticator in bytes 1556 SPI: Security Parameter Index. SPI = 0 is reserved for the 1557 Authenticator computed using SEND-based handover keys. 1559 Authenticator: Same as in RFC 3775, with "correspondent" replaced 1560 by PAR's IP address, and Kbm replaced by the shared key between 1561 the MN and the PAR. 1563 The default MAC calculation is done using HMAC_SHA1 with the first 96 1564 bits used for the MAC. Since there is an Option Length field, 1565 implementations can use other algorithms such as HMAC_SHA256 for 1566 instance. 1568 This option MUST be the last Mobility Option present. 1570 6.5.5. Neighbor Advertisement Acknowledgment (NAACK) 1572 0 1 2 3 1573 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 1574 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1575 | Type | Length | Option-Code | Status | 1576 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1577 | Reserved | 1578 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1580 Figure 15: Neighbor Advertisement Acknowledgment Option 1582 Type: 20 1584 Length: 8-bit unsigned integer. Length of the option, in 8 1585 octets. The length is 1 when a new CoA is not supplied. The 1586 length is 3 when a new CoA is present (immediately following the 1587 Reserved field) 1589 Option-Code: 0 1591 Status: 8-bit unsigned integer indicating the disposition of the 1592 Unsolicited Neighbor Advertisement message. The following Status 1593 values are currently defined: 1595 1: NCoA is invalid, perform address configuration 1596 2: NCoA is invalid, use the supplied NCoA. The supplied NCoA 1597 (in the form of an IP Address Option) MUST be present following 1598 the Reserved field. 1599 3: NCoA is invalid, use NAR's IP address as NCoA in FBU 1600 4: PCoA supplied, do not send FBU 1601 128: Link Layer Address unrecognized 1603 Reserved: MUST be set to zero by the sender and MUST be ignored by 1604 the receiver. 1606 The NAR responds to UNA with the NAACK option to notify the MN to use 1607 a different NCoA than the one that the MN has used. If the NAR 1608 proposes a different NCoA, the Router Advertisement MUST use the 1609 source IP address in the UNA message as the destination address, and 1610 use the L2 address present in UNA. The MN MUST use the NCoA if it is 1611 supplied with the NAACK option. If the NAACK indicates that the Link 1612 Layer Address is unrecognized, for instance if the MN uses an LLA 1613 valid on PAR's link but the same LLA is not valid on NAR's link due 1614 to a different access technology, the MN MUST NOT use the NCoA or the 1615 PCoA and SHOULD start immediately the process of acquiring different 1616 NCoA at the NAR. 1618 In the future, new option types may be defined. 1620 7. Related Protocol and Device Considerations 1622 The protocol specified here, as a design principle, introduces no or 1623 minimal changes to related protocols. For example, no changes to the 1624 base Mobile IPv6 protocol are needed in order to implement this 1625 protocol. Similarly, no changes to the IPv6 stateless address 1626 autoconfiguration protocol [rfc4862] and DHCP [rfc3315] are 1627 introduced. The protocol specifies an optional extension to Neighbor 1628 Discovery [rfc4861] in which an access router may send a router 1629 advertisement as a response to the UNA message (see Section 1630 Section 6.4). Other than this extension, the specfication does not 1631 modify Neighbor Discovery behavior (including the procedures 1632 performed when attached to the PAR and when attaching to the NAR). 1634 The protocol does not require changes to any intermediate layer 2 1635 device between a MN and its access router which support this 1636 specification. This includes the wireless access points, switches, 1637 snooping devices and so on. 1639 8. Configurable Parameters 1641 +-------------------+---------------+---------------+ 1642 | Parameter Name | Default Value | Definition | 1643 +-------------------+---------------+---------------+ 1644 | RTSOLPR_RETRIES | 3 | Section 6.1.1 | 1645 | MAX_RTSOLPR_RATE | 3 | Section 6.1.1 | 1646 | FBU_RETRIES | 3 | Section 6.3.1 | 1647 | PROXY_ND_LIFETIME | 1.5 seconds | Section 6.2.2 | 1648 | HI_RETRIES | 3 | Section 6.2.1 | 1649 +-------------------+---------------+---------------+ 1651 9. Security Considerations 1653 The following security vulnerabilities are identified, and suggested 1654 solutions mentioned. 1656 Insecure FBU: in this case, packets meant for one address could be 1657 stolen, or redirected to some unsuspecting node. This concern is 1658 the same as that in a MN and Home Agent relationship. 1659 Hence, the PAR MUST ensure that the FBU packet arrived from a node 1660 that legitimately owns the PCoA. The access router and its hosts 1661 may use any available mechanism to establish a security 1662 association which MUST be used to secure FBU. The current version 1663 of this protocol relies on a companion protocol [rfc-ho-send]. to 1664 establish such a security association. Using the shared handover 1665 key from [rfc-ho-send], the Authenticator in BADF option (see 1666 Section 6.5.4) MUST be computed, and the BADF option included in 1667 FBU and FBack messages. 1669 Secure FBU, malicious or inadvertent redirection: in this case, 1670 the FBU is secured, but the target of binding happens to be an 1671 unsuspecting node either due to inadvertent operation or due to 1672 malicious intent. This vulnerability can lead to a MN with 1673 genuine security association with its access router redirecting 1674 traffic to an incorrect address. 1675 However, the target of malicious traffic redirection is limited to 1676 an interface on an access router with which the PAR has a security 1677 association. The PAR MUST verify that the NCoA to which PCoA is 1678 being bound actually belongs to NAR's prefix. In order to do 1679 this, HI and HAck message exchanges are to be used. When NAR 1680 accepts NCoA in HI (with Code = 0), it proxies NCoA so that any 1681 arriving packets are not sent on the link until the MN attaches 1682 and announces itself through UNA. So, any inadvertent or 1683 malicious redirection to a host is avoided. It is still possible 1684 to jam NAR's buffer with redirected traffic. However, since NAR's 1685 handover state corresponding to NCoA has a finite (and short) 1686 lifetime corresponding to a small multiple of anticipated handover 1687 latency, the extent of this vulnerability is arguably small. 1689 Sending FBU from NAR's link: a malicious node may send FBU from 1690 NAR's link providing an unsuspecting node's address as NCoA. This 1691 is similar to base Mobile IP where the MN can provide some other 1692 node's IP address as its CoA to its Home Agent; here the PAR acts 1693 like a "temporary Home Agent" having a security association with 1694 the Mobile Node, and providing forwarding support for the handover 1695 traffic. As in base Mobile IP, this misdelivery is traceable to 1696 the MN which has a security association with the router. So, it 1697 is possible to isolate such an MN if it continues to misbehave. 1698 Similarly, a MN which has a security association with the PAR may 1699 provide the LLA of some other node on NAR's link, which can cause 1700 misdelivery of packets (meant for NCoA) to an unsuspecting node. 1701 It is possible to trace the MN in this case as well. 1703 Apart from the above, the RtSolPr (Section 6.1.1) and PrRtAdv 1704 (Section 6.1.2) messages inherit the weaknesses of Neighbor Discovery 1705 protocol [rfc4861]. Specifically, when its access router is 1706 compromised, the MN's RtSolPr message may be answered by an attacker 1707 that provides a rogue router as the resolution. Should the MN attach 1708 to such a rogue router, its communication can be compromised. 1709 Similarly, a network-initiated PrRtAdv message (see Section 3.3) from 1710 an attacker could cause a MN to handover to a rogue router. Where 1711 these weaknesses are a concern, a solution such as Secure Neighbor 1712 Discovery (SEND) [rfc3971] SHOULD be considered. 1714 The Handover Initiate (HI) and Handover Acknowledgement (HAck) 1715 messages exchanged between the PAR and NAR MUST be protected using 1716 end-to-end security association(s) offering integrity and data origin 1717 authentication. 1719 The PAR and the NAR MUST implement IPsec [rfc4301] for protecting the 1720 HI and HAck messages. IPsec ESP [rfc4303] in transport mode with 1721 mandatory integrity protection SHOULD be used for protecting the 1722 signaling messages. Confidentiality protection of these messages is 1723 not required. 1725 The security associations can be created by using either manual IPsec 1726 configuration or a dynamic key negotiation protocol such as IKEv2 1727 [rfc4306]. If IKEv2 is used, the PAR and the NAR can use any of the 1728 authentication mechanisms, as specified in RFC 4306, for mutual 1729 authentication. The following sections describe the Peer 1730 Authorization Database (PAD) and Security Policy Database (SPD) 1731 entries specified in [rfc4301] when IKEv2 is used for setting up the 1732 required IPsec security associations. 1734 9.1. Peer Authorization Database Entries when using IKEv2 1736 This section describes PAD entries on the PAR and the NAR. The PAD 1737 entries are only example configurations. Note that the PAD is a 1738 logical concept and a particular PAR or NAR implementation can 1739 implement the PAD in any implementation specific manner. The PAD 1740 state may also be distributed across various databases in a specific 1741 implementation. 1743 PAR PAD: 1745 - IF remote_identity = nar_identity_1 1746 THEN authenticate (shared secret/certificate/EAP) and authorize 1747 CHILD_SA for remote address nar_address_1 1749 NAR PAD: 1751 - IF remote_identity = par_identity_1 1752 THEN authenticate (shared secret/certificate/EAP) and authorize 1753 CHILD_SAs for remote address par_address_1 1755 The list of authentication mechanisms in the above examples is not 1756 exhaustive. There could be other credentials used for authentication 1757 stored in the PAD. 1759 9.2. Security Policy Database Entries 1761 This section describes the security policy entries on the PAR and the 1762 NAR required to protect the HI and HAck messages. The SPD entries 1763 are only example configurations. A particular PAR or NAR 1764 implementation could configure different SPD entries as long as they 1765 provide the required security. 1767 In the examples shown below, the identity of the PAR is assumed to be 1768 par_1, the address of the PAR is assumed to be par_address_1, and the 1769 address of the NAR is assumed to be nar_address_1. 1771 PAR SPD-S: 1773 - IF local_address = par_address_1 & remote_address = 1774 nar_address_1 & proto = ICMPv6 & local_icmpv6_type = HI & 1775 remote_icmpv6_type = HAck 1776 THEN use SA ESP transport mode Initiate using IDi = par_1 to 1777 address nar_address_1 1779 NAR SPD-S: 1781 - IF local_address = nar_address_1 & remote_address = 1782 par_address_1 & proto = ICMPv6 & local_icmpv6_type = HAck & 1783 remote_icmpv6_type = HI 1784 THEN use SA ESP transport mode 1786 10. IANA Considerations 1788 This document defines the following ICMPv6 messages, all of which can 1789 share a single ICMPv6 Type from the registry in 1790 http://www.iana.org/assignments/icmpv6-parameters. 1792 +------+-------------+---------------+ 1793 | Type | Description | Reference | 1794 +------+-------------+---------------+ 1795 | TBD | RtSolPr | Section 6.1.1 | 1796 | TBD | PrRtAdv | Section 6.1.2 | 1797 | TBD | HI | Section 6.2.1 | 1798 | TBD | HAck | Section 6.2.2 | 1799 +------+-------------+---------------+ 1801 The document defines a new Mobility Option which needs Type 1802 assignment from the Mobility Options Type registry at 1803 http://www.iana.org/assignments/mobility-parameters: 1805 1. Binding Authorization Data for FMIPv6 (BADF) option, described 1806 in Section 6.5.4 1808 The document has already received Type assignments for the following 1809 (see [rfc4068]): 1811 The document defines the following Neighbor Discovery [rfc4861] 1812 options which have received Type assignment from IANA. 1814 +---------+-----------------------------------------+---------------+ 1815 | Subtype | Description | Reference | 1816 +---------+-----------------------------------------+---------------+ 1817 | 17 | IP Address/Prefix Option | Section 6.5.1 | 1818 | 19 | Link-layer Address Option | Section 6.5.2 | 1819 | 20 | Neighbor Advertisement Acknowledgment | Section 6.5.5 | 1820 | | Option | | 1821 +---------+-----------------------------------------+---------------+ 1823 The document defines the following Mobility Header messages which 1824 have received Type allocation from the Mobility Header Types registry 1825 at http://www.iana.org/assignments/mobility-parameters: 1827 1. Fast Binding Update, described in Section 6.3.1 1829 2. Fast Binding Acknowledgment, described in Section 6.3.2 1831 The document defines the following Mobility Option which has received 1832 Type assignment from the Mobility Options Type registry at 1833 http://www.iana.org/assignments/mobility-parameters: 1835 1. Mobility Header Link-Layer Address option, described in 1836 Section 6.5.3 1838 11. Acknowledgments 1840 The editor would like to thank all those who have provided feedback 1841 on this specification, and acknowledges the following people: Vijay 1842 Devarapalli, Youn-Hee Han, Emil Ivov, Syam Madanapalli, Suvidh 1843 Mathur, Andre Martin, Javier Martin, Koshiro Mitsuya, Gabriel 1844 Montenegro, Takeshi Ogawa, Sun Peng, YC Peng, Alex Petrescu, Domagoj 1845 Premec, Subba Reddy, K. Raghav, Ranjit Wable and Jonathan Wood. 1846 Behcet Sarikaya and Frank Xia are acknowledged for the feedback on 1847 operation over point-point links. The editor would like to 1848 acknowledge the contribution from James Kempf to improve this 1849 specification. Vijay Devarapalli provided text for the security 1850 configuration between access routers in Section 9. Thanks to Jari 1851 Arkko for the detailed AD Review which has improved this document. 1852 The editor would also like to thank [mipshop] working group chair 1853 Gabriel Montenegro and the erstwhile [mobile ip] working group chairs 1854 Basavaraj Patil and Phil Roberts for providing much support for this 1855 work. 1857 12. References 1859 12.1. Normative References 1861 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1862 Requirement Levels", BCP 14, RFC 2119, March 1997. 1864 [rfc-ho-send] 1865 Kempf, J. and R. Koodli, "Distributing a Symmetric FMIPv6 1866 Handover Key using SEND (work in progress)", 1867 September 2007. 1869 [rfc2463] Conta, A. and S. Deering, "Internet Control Message 1870 Protocol (ICMPv6) for the Internet Protocol Version 6 1871 (IPv6) Specification", RFC 2463, December 1998, 1872 . 1874 [rfc3315] Droms (Editor), R., "Dynamic Host Configuration Protocol 1875 for IPv6 (DHCPv6)", RFC 3315, July 2003, 1876 . 1878 [rfc3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 1879 in IPv6", RFC 3775, June 2004, 1880 . 1882 [rfc4301] Kent, S. and K. Seo, "Security Architecture for the 1883 Internet Protocol", RFC 4301, December 2005, 1884 . 1886 [rfc4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 1887 RFC 4303, December 2005, 1888 . 1890 [rfc4306] Kaufman (Editor), C., "Internet Key Exchange (IKEv2) 1891 Protocol", RFC 4306, December 2005, 1892 . 1894 [rfc4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 1895 "Neighbor Discovery for IP Version 6 (IPv6)", RFC 4861, 1896 September 2007, . 1898 [rfc4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 1899 Address Autoconfiguration", RFC 4862, September 2007, 1900 . 1902 12.2. Informative References 1904 [rfc3971] Arkko (Editor), J., Kempf, J., Zill, B., and P. Nikander, 1905 "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005. 1907 [rfc4065] Kempf, J., "Instructions for Seamoby and Experimental 1908 Mobility Protocol IANA Allocations", RFC 4065, June 2004. 1910 [rfc4068] Koodli, R., "Fast Handovers for Mobile IPv6", RFC 4068, 1911 July 2005. 1913 Appendix A. Contributors 1915 This document has its origins in the fast handover design team in the 1916 erstwhile [mobile ip] working group. The members of this design team 1917 in alphabetical order were; Gopal Dommety, Karim El-Malki, Mohammed 1918 Khalil, Charles Perkins, Hesham Soliman, George Tsirtsis and Alper 1919 Yegin. 1921 Appendix B. Change Log 1923 The following revisions were done as part of the AD review (major 1924 revisions from v04 -> v05, v06 are listed). 1926 - added text about Alt-CoA check in FBU in 'FBU Section' 1928 - added inter-access router security configuration text in 1929 'Security Considerations' 1931 - Clarified that ND operations are a must in 'Related Proto 1932 Considerations' 1934 - clarified usage with DHCP in 'Protocol Overview' 1936 - added NETLMM case for Option-Code 5 in PrRtAdv 1938 - added clarification about unrecognized LLA in NAACK Section 1940 - clarified "PAR = temporary HA" for FBUs sent by a genuine MN 1941 to an unsuspecting CoA 1943 - added description of DAD requirement on NAR when determining 1944 NCoA uniqueness - Section 'Protocol Details' 1946 - Following are the changes in AD review from v03 -> v04 1948 - added a section on "Related Protocol and Node Considerations" 1950 - clarified usage of UNA, which can now update an entry and 1951 send an RA only if NAR is proxying NCoA. Recommendation to 1952 create an entry in STALE state, when none exists, is removed. 1953 (Section 6.4, Section 4) 1955 - clarified protocol usage when DHCP is used for NCoA 1956 formulation (Sections 6.1.2, 3.1, 5.2). Added a new Code value 1957 (5) in PrRtAdv (Section 6.1.2) 1959 - revised Security Considerations 1961 - clarified using HoA in FBU when sent with PCoA as source IP 1962 address 1964 - editorial revisions 1966 - LC comments for 4068bis 1968 - RFC4068bis: all the issues in the tracker since the publication 1969 of RFC 4068. (http://www.mip4.org/issues/tracker/mipshop) 1971 The following changes pre-date RFC 4068 publication. So, the section 1972 numbers probably do not match. 1974 - Added IPSec AH reference. 1976 - Changed options format to make use of RFC 2461 options Type 1977 space. Revised IANA Considerations section accordingly. 1979 - Added exponential backoff for retransmissions. Added rate 1980 limiting for RtSolPr message. 1982 - Replaced ``attachment point'' with ``access point'' for 1983 consistency. 1985 - Clarified [AP-ID, AR-Info] in terminology. Clarified use of 1986 Prefix Information Option 1988 - Separated MH-LLA from LLA to future-proof LLA option. 1990 The following changes refer up to version 02 (under mipshop). The 1991 Section numbers refer to version 06 (under mobile ip). 1993 - New ICMPv6 format incorporated. ID Nits conformance. 1995 - Last Call comments incorporated 1997 - Revised the security considerations section in v07 1999 - Refined and added a section on network-initiated handover v07 2001 - Section 3 format change 2003 - Section 4 format change (i.e., no subsections). 2005 - Description in Section 4.4 merged with ``Fast or Erroneous 2006 Movement'' 2008 - Section 4.5 deprecated 2010 - Section 4.6 deprecated 2012 - Revision of some message formats in Section 6 2014 Author's Address 2016 Rajeev Koodli (Editor) 2017 USA 2019 Email: rajeev.koodli@gmail.com 2021 Full Copyright Statement 2023 Copyright (C) The IETF Trust (2008). 2025 This document is subject to the rights, licenses and restrictions 2026 contained in BCP 78, and except as set forth therein, the authors 2027 retain all their rights. 2029 This document and the information contained herein are provided on an 2030 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2031 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 2032 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 2033 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 2034 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2035 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2037 Intellectual Property 2039 The IETF takes no position regarding the validity or scope of any 2040 Intellectual Property Rights or other rights that might be claimed to 2041 pertain to the implementation or use of the technology described in 2042 this document or the extent to which any license under such rights 2043 might or might not be available; nor does it represent that it has 2044 made any independent effort to identify any such rights. Information 2045 on the procedures with respect to rights in RFC documents can be 2046 found in BCP 78 and BCP 79. 2048 Copies of IPR disclosures made to the IETF Secretariat and any 2049 assurances of licenses to be made available, or the result of an 2050 attempt made to obtain a general license or permission for the use of 2051 such proprietary rights by implementers or users of this 2052 specification can be obtained from the IETF on-line IPR repository at 2053 http://www.ietf.org/ipr. 2055 The IETF invites any interested party to bring to its attention any 2056 copyrights, patents or patent applications, or other proprietary 2057 rights that may cover technology that may be required to implement 2058 this standard. Please address the information to the IETF at 2059 ietf-ipr@ietf.org. 2061 Acknowledgment 2063 Funding for the RFC Editor function is provided by the IETF 2064 Administrative Support Activity (IASA).