idnits 2.17.1 draft-ietf-mipshop-fmipv6-rfc4068bis-01.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 13. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 2000. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1977. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1984. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1990. 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 : ---------------------------------------------------------------------------- ** There are 173 instances of too long lines in the document, the longest one being 4 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and 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? RFC 2119 keyword, line 290: '... When feasible, the MN SHOULD send FBU...' RFC 2119 keyword, line 292: '.... An FBU message MUST contain the Bind...' RFC 2119 keyword, line 299: '...irection, the MN SHOULD reverse tunnel...' RFC 2119 keyword, line 300: '...letes Binding Update. And, PAR SHOULD...' RFC 2119 keyword, line 345: '...f these messages SHOULD be used. The ...' (112 more instances...) == The 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (3 March 2007) is 6265 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) -- Looks like a reference, but probably isn't: 'AP-ID' on line 1939 -- Looks like a reference, but probably isn't: 'AR-Info' on line 1939 == Unused Reference: '6' is defined on line 1890, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2463 (ref. '2') (Obsoleted by RFC 4443) ** Obsolete normative reference: RFC 3775 (ref. '3') (Obsoleted by RFC 6275) ** Downref: Normative reference to an Experimental RFC: RFC 4065 (ref. '4') == Outdated reference: A later version (-03) exists of draft-ietf-mipshop-handover-key-00 ** Obsolete normative reference: RFC 2402 (ref. '6') (Obsoleted by RFC 4302, RFC 4305) ** Obsolete normative reference: RFC 4068 (ref. '7') (Obsoleted by RFC 5268) ** Obsolete normative reference: RFC 2461 (ref. '8') (Obsoleted by RFC 4861) ** Obsolete normative reference: RFC 2462 (ref. '9') (Obsoleted by RFC 4862) Summary: 10 errors (**), 0 flaws (~~), 4 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Mipshop Working Group Rajeev Koodli, Editor 2 INTERNET DRAFT Nokia Research Center 3 Category: Standards Track 3 March 2007 4 Updates: RFC 4068 5 Expires: September 3, 2007 7 Fast Handovers for Mobile IPv6 8 draft-ietf-mipshop-fmipv6-rfc4068bis-01.txt 10 By submitting this Internet-Draft, each author represents that any 11 applicable patent or other IPR claims of which he or she is aware 12 have been or will be disclosed, and any of which he or she becomes 13 aware will be disclosed, in accordance with Section 6 of BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note 17 that other groups may also distribute working documents as 18 Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at 22 any time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This document is a submission of the IETF MIP6 WG. Comments should be 32 directed to the MIP6 WG mailing list, mip6@ietf.org. 34 Abstract 36 Mobile IPv6 enables a Mobile Node to maintain its connectivity to 37 the Internet when moving from an Access Router to another, a process 38 referred to as handover. During this time, the Mobile Node is unable 39 to send or receive packets due to both link switching delay and IP 40 protocol operations. The "handover latency" resulting from standard 41 Mobile IPv6 procedures, namely, movement detection, new Care of 42 Address configuration and Binding Update, is often unacceptable 43 to real-time traffic such as Voice over IP. Reducing the handover 44 latency could be beneficial to non real-time, throughput-sensitive 45 applications as well. This document specifies a protocol to improve 46 handover latency due to Mobile IPv6 procedures. This document does 47 not address improving the link switching latency. 49 Contents 51 Abstract i 53 1. Introduction 2 55 2. Terminology 2 57 3. Protocol Overview 4 58 3.1. Addressing the Handover Latency . . . . . . . . . . . . . 4 59 3.2. Protocol Operation . . . . . . . . . . . . . . . . . . . 7 60 3.3. Protocol Operation during Network-initiated Handover . . 8 62 4. Protocol Details 9 64 5. Other Considerations 14 65 5.1. Handover Capability Exchange . . . . . . . . . . . . . . 14 66 5.2. Determining New Care of Address . . . . . . . . . . . . . 14 67 5.3. Packet Loss . . . . . . . . . . . . . . . . . . . . . . . 14 68 5.4. DAD Handling . . . . . . . . . . . . . . . . . . . . . . 15 69 5.5. Fast or Erroneous Movement . . . . . . . . . . . . . . . 16 71 6. Message Formats 17 72 6.1. New Neighborhood Discovery Messages . . . . . . . . . . . 18 73 6.1.1. Router Solicitation for Proxy Advertisement 74 (RtSolPr) . . . . . . . . . . . . . . . . . . . . 18 75 6.1.2. Proxy Router Advertisement (PrRtAdv) . . . . . . 20 76 6.2. Inter-Access Router Messages . . . . . . . . . . . . . . 23 77 6.2.1. Handover Initiate (HI) . . . . . . . . . . . . . 23 78 6.2.2. Handover Acknowledge (HAck) . . . . . . . . . . . 25 79 6.3. New Mobility Header Messages . . . . . . . . . . . . . . 27 80 6.3.1. Fast Binding Update (FBU) . . . . . . . . . . . . 27 81 6.3.2. Fast Binding Acknowledgment (FBack) . . . . . . . 28 82 6.3.3. Unsolicited Neighbor Advertisement (UNA) . . . . 30 83 6.4. New Options . . . . . . . . . . . . . . . . . . . . . . . 30 84 6.4.1. IP Address Option . . . . . . . . . . . . . . . . 31 85 6.4.2. New Router Prefix Information Option . . . . . . 32 86 6.4.3. Link-layer Address (LLA) Option . . . . . . . . . 33 87 6.4.4. Mobility Header Link-layer Address (MH-LLA) Option 34 88 6.4.5. Binding Authorization Data for FMIPv6 (BADF) . . 35 89 6.4.6. Neighbor Advertisement Acknowledgment (NAACK) . . 36 91 7. Configurable Parameters 38 93 8. Security Considerations 38 94 9. IANA Considerations 39 96 10. Acknowledgments 40 98 11. Normative References 41 100 12. Author's Address 41 102 13. Contributors 42 104 A. Change Log 42 106 Intellectual Property Statement 43 108 Disclaimer of Validity 43 110 Copyright Statement 43 112 Acknowledgment 44 113 1. Introduction 115 Mobile IPv6 [3] describes the protocol operations for a mobile node 116 to maintain connectivity to the Internet during its handover from 117 one access router to another. These operations involve movement 118 detection, IP address configuration, and location update. The 119 combined handover latency is often sufficient to affect real-time 120 applications. Throughput-sensitive applications can also benefit 121 from reducing this latency. This document describes a protocol to 122 reduce the handover latency. 124 This specification addresses the following problem: how to allow a 125 mobile node to send packets as soon as it detects a new subnet link, 126 and how to deliver packets to a mobile node as soon as its attachment 127 is detected by the new access router. The protocol defines IP 128 protocol messages necessary for its operation regardless of link 129 technology. It does this without depending on specific link-layer 130 features while allowing link-specific customizations. By definition, 131 this specification considers handovers that interwork with Mobile IP: 132 once attached to its new access router, a MN engages in Mobile IP 133 operations including Return Routability [3]. There are no special 134 requirements for a mobile node to behave differently with respect to 135 its standard Mobile IP operations. 137 2. Terminology 139 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 140 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "OPTIONAL", and 141 "silently ignore" in this document are to be interpreted as described 142 in RFC 2119 [1]. 144 The following terminology and abbreviations are used in this document 145 in addition to those defined in [3]. The reference handover scenario 146 is illustrated in Figure 1. 148 Mobile Node (MN) 149 A Mobile IPv6 host 151 Access Point (AP) 152 A Layer 2 device connected to an IP subnet that offers 153 wireless connectivity to a MN. An Access Point Identifier 154 (AP-ID) refers the AP's L2 address. Sometimes, AP-ID 155 is also referred to as a Basic Service Set IDentifier 156 (BSSID). 158 Access Router (AR) 159 The MN's default router 161 Previous Access Router (PAR) 162 The MN's default router prior to its handover 164 New Access Router (NAR) 165 The MN's anticipated default router subsequent to its 166 handover 168 Previous CoA (PCoA) 169 The MN's Care of Address valid on PAR's subnet 171 New CoA (NCoA) 172 The MN's Care of Address valid on NAR's subnet 174 Handover 175 A process of terminating existing connectivity and 176 obtaining new IP connectivity. 178 Router Solicitation for Proxy Advertisement (RtSolPr) 179 A message from the MN to the PAR requesting information 180 for a potential handover 182 Proxy Router Advertisement (PrRtAdv) 183 A message from the PAR to the MN that provides 184 information about neighboring links facilitating 185 expedited movement detection. The message can also act 186 as a trigger for network-initiated handover. 188 (AP-ID, AR-Info) tuple 189 Contains an access router's L2 and IP addresses, and 190 prefix valid on the interface to which the Access Point 191 (identified by AP-ID) is attached. The triplet [Router's 192 L2 address, Router's IP address and Prefix] is called 193 "AR-Info". 195 Assigned Addressing 196 A particular type of NCoA configuration in which the NAR 197 assigns an IPv6 address for the MN. The method by which 198 NAR manages its address pool is not specified in this 199 document. 201 Fast Binding Update (FBU) 202 A message from the MN instructing its PAR to redirect its 203 traffic (towards NAR) 205 Fast Binding Acknowledgment (FBack) 206 A message from the PAR in response to FBU 208 Unsolicited Neighbor Advertisement (UNA) 209 The message in [8] with 'O' bit cleared 211 Fast Neighbor Advertisement (FNA) 212 This message from RFC4068 [7] is deprecated. The 213 UNA message above is the preferred message in this 214 specification. 216 Handover Initiate (HI) 217 A message from the PAR to the NAR regarding a MN's 218 handover 220 Handover Acknowledge (HAck) 221 A message from the NAR to the PAR as a response to HI 223 v +--------------+ 224 +-+ | Previous | < 225 | | ------------ | Access | ------- >-----\ 226 +-+ | Router | < \ 227 MN | (PAR) | \ 228 | +--------------+ +---------------+ 229 | ^ IP | Correspondent | 230 | | Network | Node | 231 V | +---------------+ 232 v / 233 v +--------------+ / 234 +-+ | New | < / 235 | | ------------ | Access | ------- >-----/ 236 +-+ | Router | < 237 MN | (NAR) | 238 +--------------+ 240 Figure 1: Reference Scenario for Handover 242 3. Protocol Overview 244 3.1. Addressing the Handover Latency 246 The ability to immediately send packets from a new subnet link 247 depends on the "IP connectivity" latency, which in turn depends 248 on the movement detection latency and the new CoA configuration 249 latency. Once a MN is IP-capable on the new subnet link, it can send 250 a Binding Update to its Home Agent and one or more correspondents. 251 Once its correspondents successfully process the Binding Update, 252 which typically involves the Return Routability procedure, the MN can 253 receive packets at the new CoA. So, the ability to receive packets 254 from correspondents directly at its new CoA depends on the Binding 255 Update latency as well as the IP connectivity latency. 257 The protocol enables a MN to quickly detect that it has moved to 258 a new subnet by providing the new access point and the associated 259 subnet prefix information when the MN is still connected to its 260 current subnet (i.e., PAR in Figure 1). For instance, a MN may 261 discover available access points using link-layer specific mechanisms 262 (e.g., a "scan" in WLAN) and then request subnet information 263 corresponding to one or more of those discovered access points. The 264 MN may do this after performing router discovery. The MN may also 265 do this at any time while connected to its current router. The 266 result of resolving an identifier associated with an access point is 267 a [AP-ID, AR-Info] tuple, which a MN can use in readily detecting 268 movement: when attachment to an access point with AP-ID takes place, 269 the MN knows the corresponding new router's co-ordinates including 270 its prefix, IP address and L2 address. The "Router Solicitation 271 for Proxy Advertisement (RtSolPr)" and "Proxy Router Advertisement 272 (PrRtAdv)" messages 6.1 are used for aiding movement detection. 274 Through the RtSolPr and PrRtAdv messages, the MN also formulates a 275 prospective new CoA (NCoA), when it is still present on the PAR's 276 link. Hence, the latency due to new prefix discovery subsequent to 277 handover is eliminated. Furthermore, this prospective address can 278 be used immediately after attaching to the new subnet link (i.e., 279 NAR's link) when the MN has received a "Fast Binding Acknowledgment 280 (FBack)" message prior to its movement. In the event it moves 281 without receiving an FBack, the MN can still start using NCoA 282 after announcing its attachment through an unsolicited Neighbor 283 Advertisement message (with the 'O' bit set to zero) message [8]; 284 NAR responds to to this UNA message in case the tentative address is 285 already in use. In this way, NCoA configuration latency is reduced. 287 In order to reduce the Binding Update latency, the protocol specifies 288 a binding between the Previous CoA (PCoA) and NCoA. A MN sends 289 a "Fast Binding Update" message to its Previous Access Router 290 to establish this tunnel. When feasible, the MN SHOULD send FBU 291 from PAR's link. Otherwise, it should send it immediately after 292 detecting attachment to NAR. An FBU message MUST contain the Binding 293 Authorization Data for FMIPv6 (BADF) option (see Section 6.4.5) in 294 order to ensure that only a legitimate MN that owns the PCoA is able 295 to establish a binding. Subsequent sections describe the protocol 296 mechanics. In any case, the result is that PAR begins tunneling 297 packets arriving for PCoA to NCoA. Such a tunnel remains active 298 until the MN completes the Binding Update with its correspondents. 299 In the opposite direction, the MN SHOULD reverse tunnel packets 300 to PAR, again until it completes Binding Update. And, PAR SHOULD 301 forward the inner packet in the tunnel to its destination (i.e., 302 to the MN's correspondent). Such a reverse tunnel ensures that 303 packets containing PCoA as source IP address are not dropped due 304 to ingress filtering. Even though the MN is IP-capable on the new 305 link, it cannot use NCoA directly with its correspondents without the 306 correspondents first establishing a binding cache entry (for NCoA). 307 Forwarding support for PCoA is provided through a reverse tunnel 308 between the MN and the PAR. 310 Setting up a tunnel alone does not ensure that the MN receives 311 packets as soon as attaching to a new subnet link, unless NAR can 312 detect the MN's presence. A neighbor discovery operation involving 313 a neighbor's address resolution (i.e., Neighbor Solicitation and 314 Neighbor Advertisement) typically results in considerable delay, 315 sometimes lasting multiple seconds. For instance, when arriving 316 packets trigger NAR to send Neighbor Solicitation before the MN 317 attaches, subsequent re-transmissions of address resolution are 318 separated by a default period of one second each. In order to 319 circumvent this delay, a MN announces its attachment immediately with 320 an UNA message that allows NAR to forward packets to the MN right 321 away. As a response to UNA, the NAR creates an entry or updates 322 an existing one (while taking any conflicts into account) in order 323 to forward packets to the MN (see details below). Through tunnel 324 establishment for PCoA and fast advertisement, the protocol provides 325 expedited forwarding of packets to the MN. 327 The protocol also provides the following important functionalities. 328 The access routers can exchange messages to confirm that a proposed 329 NCoA is acceptable. For instance, when a MN sends FBU from PAR's 330 link, FBack can be delivered after NAR considers NCoA acceptable to 331 use. This is especially useful when addresses are assigned by the 332 access router. The NAR can also rely on its trust relationship with 333 PAR before providing forwarding support for the MN. That is, it may 334 create a forwarding entry for NCoA subject to "approval" from PAR 335 which it trusts. In addition, buffering for handover traffic may 336 be desirable. Even though the Neighbor Discovery protocol provides 337 a small buffer (typically one or two packets) for packets awaiting 338 address resolution, this buffer may be inadequate for traffic such as 339 VoIP already in progress. The routers may also wish to maintain a 340 separate buffer for servicing the handover traffic as well. Finally, 341 the access routers could transfer network-resident contexts, such 342 as access control, QoS, header compression, in conjunction with 343 handover. For all these operations, the protocol provides "Handover 344 Initiate (HI)" and "Handover Acknowledge (HAck)" messages. Both 345 of these messages SHOULD be used. The access routers MUST have 346 necessary security association established by means outside the scope 347 of this document. 349 3.2. Protocol Operation 351 The protocol begins when a MN sends RtSolPr to its access router 352 to resolve one or more Access Point Identifiers to subnet-specific 353 information. In response, the access router (e.g., PAR in Figure 1) 354 sends a PrRtAdv message which contains one or more [AP-ID, AR-Info] 355 tuples. The MN may send RtSolPr at any convenient time, for instance 356 as a response to some link-specific event (a ``trigger'') or simply 357 after performing router discovery. However, the expectation is that 358 prior to sending RtSolPr, the MN has discovered the available APs 359 by link-specific methods. The RtSolPr and PrRtAdv messages do not 360 establish any state at the access router, and their packet formats 361 are defined in Section 6.1. 363 With the information provided in the PrRtAdv message, the MN 364 formulates a prospective NCoA and sends an FBU message. The purpose 365 of FBU is to authorize PAR to bind PCoA to NCoA, so that arriving 366 packets can be tunneled to the new location of the MN. The FBU should 367 be sent from PAR's link whenever feasible. For instance, an internal 368 link-specific trigger could enable FBU transmission from the previous 369 link. 371 When it is not feasible, FBU is sent from the new link. Care must 372 be taken to ensure that NCoA used in FBU does not conflict with an 373 address already in use by some other node on link. 375 The format and semantics of FBU processing are specified in 376 Section 6.3.1. The FBU message MUST contain the BADF option (see 377 Section 6.4.5) to secure the message. 379 Depending on whether an FBack is received or not on the previous 380 link, which clearly depends on whether FBU was sent in the first 381 place, there are two modes of operation. 383 1. The MN receives FBack on the previous link. This means that 384 packet tunneling would already be in progress by the time the 385 MN handovers to NAR. The MN SHOULD send UNA immediately after 386 attaching to NAR, so that arriving as well as buffered packets 387 can be forwarded to the MN right away. 389 Before sending FBack to MN, PAR can determine whether NCoA is 390 acceptable to NAR through the exchange of HI and HAck messages. 391 When assigned addressing (i.e., addresses are assigned by the 392 router) is used, the proposed NCoA in FBU is carried in HI, and 393 NAR MAY assign the proposed NCoA. Such an assigned NCoA MUST be 394 returned in HAck, and PAR MUST in turn provide the assigned NCoA 395 in FBack. If there is an assigned NCoA returned in FBack, the MN 396 MUST use the assigned address (and not the proposed address in 397 FBU) upon attaching to NAR. 399 2. The MN does not receive FBack on the previous link. One reason 400 for this is that the MN has not sent the FBU. The other is that 401 the MN has left the link after sending the FBU, which may be 402 lost, but before receiving an FBack. Without receiving an FBack 403 in the latter case, the MN cannot ascertain whether PAR has 404 successfully processed the FBU. Hence, the MN (re)sends FBU 405 immediately after sending the UNA message. If NAR detects that 406 NCoA is in use when processing UNA, for instance while creating 407 a neighbor entry, it sends a Router Advertisement with "Neighbor 408 Advertisement Acknowledge (NAACK)" option in which NAR MAY 409 include an alternate IP address for the MN to use. Detailed UNA 410 processing rules are specified in Section 6.3.3. 412 The scenario in which a MN sends FBU and receives FBack on PAR's link 413 is illustrated in Figure 2. For convenience, this scenario is called 414 "predictive" mode of operation. The scenario in which the MN sends 415 FBU from NAR's link is illustrated in Figure 3. For convenience, 416 this scenario is called "reactive" mode of operation. Note that 417 the reactive mode also includes the case when FBU has been sent 418 from PAR's link but FBack has not been received yet. The Figure is 419 intended to illustrate that the FBU is forwarded through NAR, but it 420 is processed only by the PAR. 422 Finally, the PrRtAdv message may be sent unsolicited, i.e., without 423 the MN first sending RtSolPr. This mode is described in Section 3.3. 425 3.3. Protocol Operation during Network-initiated Handover 427 In some wireless technologies, the handover control may reside in the 428 network even though the decision to undergo handover may be arrived 429 at by cooperation between the MN and the network. In such networks, 430 the PAR can send an unsolicited PrRtAdv containing the link layer 431 address, IP address and subnet prefix of the NAR when the network 432 decides that a handover is imminent. The MN MUST process this 433 PrRtAdv to configure a new care of address on the new subnet, and 434 MUST send an FBU to PAR prior to switching to the new link. After 435 transmitting PrRtAdv, the PAR MUST continue to forward packets to the 436 MN on its current link until the FBU is received. The rest of the 437 operation is the same as that described in Section 3.2. 439 The unsolicited PrRtAdv also allows the network to inform the MN 440 about geographically adjacent subnets without the MN having to 441 explicitly request that information. This can reduce the amount 442 of wireless traffic required for the MN to obtain a neighborhood 443 topology map of links and subnets. Such usage of PrRtAdv is 444 decoupled from the actual handover. See Section 6.1.2. 446 MN PAR NAR 447 | | | 448 |------RtSolPr------->| | 449 |<-----PrRtAdv--------| | 450 | | | 451 |------FBU----------->|----------HI--------->| 452 | |<--------HAck---------| 453 | <--FBack---|--FBack---> | 454 | | | 455 disconnect forward | 456 | packets ===============>| 457 | | | 458 | | | 459 connect | | 460 | | | 461 |------------UNA --------------------------->| 462 |<=================================== deliver packets 463 | | 465 Figure 2: "Predictive" Fast Handover 467 4. Protocol Details 469 All description makes use of Figure 1 as the reference. 471 After discovering one or more nearby access points, the MN sends 472 RtSolPr in order to resolve access point identifiers to subnet router 473 information. A convenient time to do this is after performing router 474 discovery. However, the MN can send RtSolPr at any time, e.g., when 475 one or more new access points are discovered. The MN can also send 476 RtSolPr more than once during its attachment to PAR. The trigger for 477 sending RtSolPr can originate from a link-specific event, such as 478 the promise of a better signal strength from another access point 479 coupled with fading signal quality with the current access point. 480 Such events, often broadly referred to as "L2 triggers", are outside 481 the scope of this document. Nevertheless, they serve as events that 482 invoke this protocol. For instance, when a "link up" indication 483 is obtained on the new link, protocol messages (e.g., UNA) can be 484 immediately transmitted. Implementations SHOULD make use of such 485 triggers whenever available. 487 MN PAR NAR 488 | | | 489 |------RtSolPr------->| | 490 |<-----PrRtAdv--------| | 491 | | | 492 disconnect | | 493 | | | 494 | | | 495 connect | | 496 |-------UNA-----------|--------------------->| 497 |-------FBU-----------|---------------------)| 498 | |<-------FBU----------)| 499 | forward | 500 | packets(including FBAck)=====>| 501 | | | 502 |<=================================== deliver packets 503 | | 505 Figure 3: "Reactive" Fast Handover 507 The RtSolPr message contains one or more AP-IDs. A wildcard requests 508 all available tuples. 510 As a response to RtSolPr, PAR sends a PrRtAdv message which indicates 511 one of the following possible conditions. 513 1. If the PAR does not have an entry corresponding to the new access 514 point, it responds indicating that the new access point is 515 unknown. The MN MUST stop fast handover protocol operations on 516 the current link. The MN MAY send an FBU from its new link. 518 2. If the new access point is connected to the PAR's current 519 interface (to which MN is attached), PAR responds with a Code 520 value indicating that the new access point is connected to the 521 current interface, but not send any prefix information. This 522 scenario could arise, for example, when several wireless access 523 points are bridged into a wired network. No further protocol 524 action is necessary. 526 3. If the new access point is known and the PAR has information 527 about it, then PAR responds indicating that the new access point 528 is known and supply the [AP-ID, AR-Info] tuple. If the new 529 access point is known, but does not support fast handover, the 530 PAR MUST indicate this with Code 3 (See Section 6.1.2). 532 4. If a wildcard is supplied as an identifier for the new access 533 point, the PAR SHOULD supply neighborhood [AP-ID, AR-Info] tuples 534 subject to path MTU restrictions (i.e., provide any 'n' tuples 535 without exceeding the link MTU). 537 When further protocol action is necessary, some implementations may 538 choose to provide buffering support at PAR to address the scenario in 539 which a MN leaves without sending an FBU message from the PAR's link. 540 While the protocol does not forbid such an implementation support, 541 care must be taken to ensure that the PAR continues forwaring packets 542 to the PCoA (i.e., uses a buffer and forward approach). The PAR 543 should also stop buffering once it processes the FBU message. 545 The method by which Access Routers exchange information about 546 their neighbors and thereby allow construction of Proxy Router 547 Advertisements with information about neighboring subnets is outside 548 the scope of this document. 550 The RtSolPr and PrRtAdv messages MUST be implemented by a MN and 551 an access router that supports fast handovers. However, when 552 the parameters necessary for the MN to send packets immediately 553 upon attaching to the NAR are supplied by the link layer handover 554 mechanism itself, use of above messages is optional on such links. 556 After a PrRtAdv message is processed, the MN sends FBU and includes 557 the proposed NCoA. The MN SHOULD send FBU from PAR's link whenever 558 "anticipation" of handover is feasible. When anticipation is not 559 feasible or when it has not received an FBack, the MN sends FBU 560 immediately after attaching to NAR's link. In response to FBU, PAR 561 establishes a binding between PCoA ("Home Address") and NCoA, and 562 sends FBack to MN. Prior to establishing this binding, PAR SHOULD 563 send a HI message to NAR, and receive HAck in response. In order 564 to determine the NAR's address for the HI message, the PAR can 565 perform longest prefix match of NCoA (in FBU) with the prefix list 566 of neighboring access routers. When the source IP address of FBU 567 is PCoA, i.e., the FBU is sent from the PAR's link, the HI message 568 MUST have a Code value set to 0. See Section 6.2.1. When the source 569 IP address of FBU is not PCoA, i.e., the FBU is sent from the NAR's 570 link, the HI message MUST have a Code value of 1. See Section 6.2.1. 572 The HI message contains the PCoA, link-layer address and the NCoA of 573 the MN. In response to processing a HI message with Code 0, the NAR 575 1. determines whether NCoA supplied in the HI message is a valid 576 address for use, and if it is, starts proxying [8] the address 577 for PROXY_ND_LIFETIME during which the MN is expected to connect 578 to NAR. In case there is already an NCoA present, NAR may verify 579 if the LLA is the same as its own or that of the MN itself. If 580 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. 584 The 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 588 or assigned. This host route entry SHOULD be implemented such 589 that 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 609 an FBack message even after re-transmitting FBU for FBU|RETRIES, it 610 must 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 6.3.3). If the MN has not received 616 an FBack by the time UNA is being sent, it SHOULD send an FBU 617 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 [9]. 624 When a NAR receives a UNA message, it 625 1. SHOULD create a neighbor cache entry for NCoA if none exists and 626 set it to STALE. This allows it to forward any arriving packets 627 while it probes bidirectional reachability. 629 2. updates an entry in INCOMPLETE state, if it exists, to STALE and 630 forwards arriving and buffered packets. This would be the case 631 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 3. deletes its proxy neighbor cache entry, if any, updates the state 636 to STALE, and forwards arriving and buffered packets. 638 The buffer for handover traffic should be linked to this UNA 639 processing. The exact mechanism is implementation dependent. 641 The NAR may detect that NCoA is in use by another node when 642 processing the UNA message, in which case it 644 1. MUST NOT update the existing entry. 646 2. MUST send a Router Advertisement with the NAACK option in which 647 it MAY include an alternate NCoA for use. This message MUST be 648 sent to the source IP address present in UNA using the same Layer 649 2 address present in UNA. 651 If the MN receives an IP address in the NAACK option, it MUST use it 652 and send an FBU using the new CoA. As a special case, the address 653 supplied in NAACK could be PCoA itself, in which case the MN MUST NOT 654 send any more FBUs. The Status codes for NAACK option are specified 655 in Section 6.4.6. 657 Once the MN has confirmed its NCoA (either through DAD or when 658 provided for by the NAR), it SHOULD send a Neighbor Advertisement 659 message with the 'O' bit set, to the all-nodes multicast address. 660 This message allows MN's neighbors to update their neighbor cache 661 entries. 663 For data forwarding, the PAR tunnels packets using its global IP 664 address valid on the interface to which the MN was attached. The 665 MN reverse tunnels its packets to the same global address of PAR. 666 The tunnel end-point addresses must be configured accordingly. When 667 PAR receives a reverse tunneled packet, it must verify if a secure 668 binding exists for the MN identified by PCoA in the tunneled packet, 669 before forwarding the packet. 671 5. Other Considerations 673 5.1. Handover Capability Exchange 675 The MN expects a PrRtAdv in response to its RtSolPr message. If the 676 MN does not receive a PrRtAdv message even after RTSOLPR|RETRIES, it 677 must assume that PAR does not support the fast handover protocol and 678 stop sending any more RtSolPr messages. 680 Even if a MN's current access router is capable of providing 681 fast handover support, the new access router may not be capable 682 of providing such support. This is indicated to the MN during 683 "runtime", through the PrRtAdv message with a Code value of 3 (see 684 Section 6.1.2). 686 5.2. Determining New Care of Address 688 Typically, the MN formulates its prospective NCoA using the 689 information provided in a PrRtAdv message, and sends FBU. This NCoA 690 can be provided to NAR in the HI message. NAR provides a disposition 691 of HI, and hence the NCoA itself, in the HAck message indicating 692 whether NCoA is acceptable. However, the MN itself does not have to 693 wait on PAR's link for this exchange to take place. It can handover 694 any time after sending the FBU message; sometimes it may be forced to 695 handover without sending the FBU. In any case, it can still confirm 696 using NCoA from NAR's link by sending the UNA message. 698 If PrRtAdv message carries a NCoA, the MN MUST use it as its 699 prospective NCoA. 701 5.3. Packet Loss 703 Handover involves link switching, which may not be exactly 704 co-ordinated with fast handover signaling. Furthermore, the 705 arrival pattern of packets is dependent on many factors, including 706 application characteristics, network queuing behaviors etc. Hence, 707 packets may arrive at NAR before the MN is able to establish its 708 link there. These packets will be lost unless they are buffered 709 by the NAR. Similarly, if the MN attaches to NAR and then sends an 710 FBU message, packets arriving at PAR until FBU is processed will be 711 lost unless they are buffered. This protocol provides an option to 712 indicate request for buffering at the NAR in the HI message. When 713 the PAR requests this feature (for the MN), it SHOULD also provide 714 its own support for buffering. 716 5.4. DAD Handling 718 Duplicate Address Detection (DAD) was defined in [9] to avoid address 719 duplication on links when stateless address auto-configuration is 720 used. The use of DAD to verify the uniqueness of an IPv6 address 721 configured through stateless auto-configuration adds delays to a 722 handover. 724 The probability of an interface identifier duplication on the same 725 subnet is very low, however it cannot be ignored. In this draft 726 certain precautions are proposed to minimize the effects of a 727 duplicate address occurrence as well as recovery actions in the event 728 of a collision. 730 In some cases the NAR may already have the knowledge required to 731 assess whether the MN's address is a duplicate or not before the 732 MN moves to the new subnet. For example, the NAR can have a list 733 of all nodes on its subnet for access control, and by searching 734 this list, it can confirm whether the MN's address is a duplicate 735 or not. In some other deployments, the NAR may maintain a pool of 736 duplicate-free addresses in a list for handover purposes. The result 737 of NCoA disposition is sent back to the PAR in the HAck message. The 738 NAR can also indicate this in the NAACK option as a response to the 739 UNA message. When there is a duplicate, NAR can propose (in NAACK 740 option) an alternative NCoA or support the PCoA using the host route 741 forwarding. When no such support is available, the MN would have to 742 follow the address configuration procedure according to [9] after 743 attaching to the NAR. 745 In deployments where NAR does not have means to assess and inform 746 the uniqueness of NCoA or cannot provide a duplicate-free address 747 using HI and HAck exchange, the following scenarios are possible, 748 although highly improbable considering that the probability of a 749 random address collision is very small. 751 1. The MN sends FBU from the previous link which results in packet 752 forwarding to NCoA. These packets may arrive before the MN 753 attaches to NAR, and hence the latter may invoke Neighbor 754 Discovery. In the event that there is another node which already 755 owns the NCoA, NAR (incorrectly) forwards those packets to such 756 a node. When the MN arrives on the link, it immediately sends 757 a UNA message, which allows NAR to detect a collision. NAR 758 immediately sends a Router Advertisement with NAACK option, 759 forcing the MN to either use another NCoA supplied in NAACK or 760 reconfigure a new one. The MN must send an FBU immediately 761 following the NCoA configuration. As a special case, the NCoA 762 may be that of NAR itself, which allows the MN to send FBU that 763 binds its PCoA to NAR's address. This recovers from temporary 764 misdelivery of packets. Where this is a concern, the deployments 765 SHOULD use HI and HAck exchange which mitigates the problem by 766 allowing NAR to proxy the NCoA; such a proxying itself can detect 767 a collision if an entry already exists in the neighbor cache 768 entry. 770 2. The MN sends a UNA message followed by an FBU from the new link. 771 When NAR processes the UNA message, either there is already an 772 entry for NCoA or there is no entry. If there is an entry, it 773 either belongs to the MN itself (e.g., in INCOMPLETE state) 774 or the entry belongs to another node. These entries can be 775 distinguished by the LLA; the entry with INCOMPLETE state has no 776 LLA. If the entry belongs to another node, NAR immediately sends 777 a Router Advertisement with NAACK option (as above) and the MN 778 MUST immediately send a new FBU to PAR with a different NCoA. 779 Hence, extent of any misdelivery is minimized. 781 If there is no existing entry for NCoA but there is another node 782 which owns NCoA, the scenario is more complicated. According 783 to [8], the UNA message does not create any entry if there is 784 none to begin with. However, NAR performs Neighbor Solicitation 785 when packets arrive from PAR (due to FBU processing). Both the 786 MN and the rightful owner respond with Neighbor Advertisement 787 (NA), but the MN's Neighbor Advertisement will have the 'O' bit 788 cleared. If the MN's NA arrives first, NAR starts forwarding to 789 it, but redirects those packets once the NA from the rightful 790 owner is processed. At the time of updating the neighbor cache 791 entry, the NAR must send a Router Advertisement with NAACK option 792 to the MN (as above), and the MN MUST immediately send a new 793 FBU to the PAR. If the MN's NA arrives after the NA from the 794 rightful owner, NAR similarly sends a Router Advertisement with 795 NAACK option, and the MN sends a new FBU to the PAR. In both the 796 cases, the extent of misdelivery can be controlled and recovery 797 is possible. 799 The scenario where NAR has no entry for NCoA at all when packets 800 arrive is possible even when using HI and HAck messages. The 801 available options in this case appear to be a) performing DAD 802 for a set of addresses beforehand for handover purposes, and b) 803 maintaining a table of IP addresses of all nodes on the link 804 (similar to Mobile IPv4 visitor list). The NAR can then provide 805 a conflict-free address in the HAck message or the NAACK option. 807 5.5. Fast or Erroneous Movement 809 Although this specification is for fast handover, the protocol has 810 its limits in terms of how fast a MN can move. A special case of 811 fast movement is ping-pong, where a MN moves between the same two 812 access points rapidly. Another instance of the same problem is 813 erroneous movement i.e., the MN receives information prior to a 814 handover that it is moving to a new access point but it either moves 815 to a different one or aborts movement altogether. All of the above 816 behaviors are usually the result of link layer idiosyncrasies and 817 thus are often tackled at the link layer itself. 819 IP layer mobility, however, introduces its own limits. IP layer 820 handovers should occur at a rate suitable for the MN to update 821 the binding of, at least, its Home Agent and preferably that of 822 every CN with which it is in communication. A MN that moves faster 823 than necessary for this signaling to complete, which may be of the 824 order of few seconds, may start losing packets. The signaling 825 overhead over the air and in the network may increase significantly, 826 especially in the case of rapid movement between several access 827 routers. To avoid the signaling overhead, the following measures are 828 suggested. 830 A MN returning to the PAR before updating the necessary bindings when 831 present on NAR MUST send a Fast Binding Update with Home Address 832 equal to the MN's PCoA and a lifetime of zero, to the PAR. The MN 833 should have a security association with the PAR since it performed 834 a fast handover to the NAR. The PAR, on receiving this Fast Binding 835 Update, will check its set of outgoing (temporary fast handover) 836 tunnels. If it finds a match it SHOULD terminate that tunnel; i.e., 837 start delivering packets directly to the node instead. 839 Temporary tunnels for the purposes of fast handovers should use short 840 lifetimes (of the order of a small number of seconds or less). The 841 lifetime of such tunnels should be enough to allow a MN to update all 842 its active bindings. The default lifetime of the tunnel should be 843 the same as the lifetime value in the FBU message. 845 The effect of erroneous movement is typically limited to loss of 846 packets since routing can change and the PAR may forward packets 847 towards another router before the MN actually connects to that 848 router. If the MN discovers itself on an unanticipated access 849 router, it SHOULD send a new Fast Binding Update to the PAR. This 850 FBU supercedes the existing binding at PAR and the packets will be 851 redirected to the new confirmed location of the MN. 853 6. Message Formats 855 All the ICMPv6 messages have a common Type specified in [4]. The 856 messages are distinguished based on the Subtype field (see below). 857 The values for the Subtypes are specified in Section 9. For all the 858 ICMPv6 messages, the checksum is defined in [2]. 860 6.1. New Neighborhood Discovery Messages 862 6.1.1. Router Solicitation for Proxy Advertisement (RtSolPr) 864 Mobile Nodes send Router Solicitation for Proxy Advertisement in 865 order to prompt routers for Proxy Router Advertisements. All the 866 link-layer address options have the format defined in 6.4.3. 868 0 1 2 3 869 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 870 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 871 | Type | Code | Checksum | 872 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 873 | Subtype | Reserved | Identifier | 874 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 875 | Options ... 876 +-+-+-+-+-+-+-+-+-+-+-+- 878 Figure 4: Router Solicitation for Proxy 879 Advertisement (RtSolPr) Message 881 IP Fields: 883 Source Address 884 An IP address assigned to the sending interface 886 Destination Address 887 The address of the Access Router or the all routers 888 multicast address. 890 Hop Limit 255. See RFC 2461. 892 ICMP Fields: 894 Type The Experimental Mobility Protocol Type. See [4]. 896 Code 0 898 Checksum The ICMPv6 checksum. 900 Subtype 2 902 Reserved MUST be set to zero by the sender and ignored by 903 the receiver. 905 Identifier MUST be set by the sender so that replies can be 906 matched to this Solicitation. 908 Valid Options: 910 Source Link-layer Address 911 When known, the link-layer address of the sender 912 SHOULD be included using the Link-Layer Address 913 option. See LLA option format below. 915 New Access Point Link-layer Address 916 The link-layer address or identification of the 917 access point for which the MN requests routing 918 advertisement information. It MUST be included 919 in all RtSolPr messages. More than one such address 920 or identifier can be present. This field can also 921 be a wildcard address. See LLA Option below. 923 Future versions of this protocol may define new option types. 924 Receivers MUST silently ignore any options that they do not recognize 925 and continue processing the rest of the message. 927 Including the source LLA option allows the receiver to record the 928 sender's L2 address so that neighbor discovery, when the receiver 929 needs to send packets back to the sender (of RtSolPr message), can be 930 avoided. 932 When a wildcard is used for New Access Point LLA, no other New Access 933 Point LLA options must be present. 935 A Proxy Router Advertisement (PrRtAdv) message should be received by 936 the MN as a response to RtSolPr. If such a message is not received 937 in a short time period but no less than twice the typical round trip 938 time (RTT) over the access link or 100 milliseconds if RTT is not 939 known, it SHOULD resend RtSolPr message. Subsequent retransmissions 940 can be up to RTSOLPR_RETRIES, but MUST use an exponential backoff 941 in which the timeout period (i.e., 2xRTT or 100 milliseconds) is 942 doubled prior to each instance of retransmission. If Proxy Router 943 Advertisement is not received by the time the MN disconnects from the 944 PAR, the MN SHOULD send FBU immediately after configuring a new CoA. 946 When RtSolPr messages are sent more than once, they MUST be rate 947 limited with MAX_RTSOLPR_RATE per second. During each use of 948 RtSolPr, exponential backoff is used for retransmissions. 950 6.1.2. Proxy Router Advertisement (PrRtAdv) 952 Access routers send out Proxy Router Advertisement message 953 gratuitously if the handover is network-initiated or as a response 954 to RtSolPr message from a MN, providing the link-layer address, 955 IP address and subnet prefixes of neighboring routers. All the 956 link-layer address options have the format defined in 6.4.3. 958 0 1 2 3 959 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 960 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 961 | Type | Code | Checksum | 962 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 963 | Subtype | Reserved | Identifier | 964 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 965 | Options ... 966 +-+-+-+-+-+-+-+-+-+-+-+- 968 Figure 5: Proxy Router Advertisement (PrRtAdv) Message 970 IP Fields: 972 Source Address 973 MUST be the link-local address assigned to the 974 interface from which this message is sent. 976 Destination Address 977 The Source Address of an invoking Router 978 Solicitation for Proxy Advertisement or the address 979 of the node the Access Router is instructing to 980 handover. 982 Hop Limit 255. See RFC 2461. 984 ICMP Fields: 986 Type The Experimental Mobility Protocol Type. See [4]. 988 Code 0, 1, 2, 3 or 4. See below. 990 Checksum The ICMPv6 checksum. 992 Subtype 3 994 Reserved MUST be set to zero by the sender and ignored by 995 the receiver. 997 Identifier Copied from Router Solicitation for Proxy 998 Advertisement or set to Zero if unsolicited. 1000 Valid Options in the following order: 1002 Source Link-layer Address 1003 When known, the link-layer address of the sender 1004 SHOULD be included using the Link-Layer Address 1005 option. See LLA option format below. 1007 New Access Point Link-layer Address 1008 The link-layer address or identification of the 1009 access point is copied from RtSolPr 1010 message. This option MUST be present. 1012 New Router's Link-layer Address 1013 The link-layer address of the Access Router for 1014 which this message is proxied for. This option MUST be 1015 included when Code is 0 or 1. 1017 New Router's IP Address 1018 The IP address of NAR. This option MUST be 1019 included when Code is 0 or 1. 1021 New Router Prefix Information Option. 1022 Specifies the prefix of the Access 1023 Router the message is proxied for and is used 1024 for address auto-configuration. This option MUST be 1025 included when Code is 0 or 1. However, when this 1026 prefix is the same as what is used in the New 1027 Router's IP Address option (above), the Prefix 1028 Information option need not be present. 1030 New CoA Option 1031 MAY be present when PrRtAdv is sent 1032 unsolicited. PAR MAY compute new CoA using NAR's 1033 prefix information and the MN's L2 address, or by 1034 any other means. 1036 Future versions of this protocol may define new option types. 1037 Receivers MUST silently ignore any options they do not recognize and 1038 continue processing the message. 1040 Currently, Code values 0, 1, 2, 3 and 4 are defined. 1042 A Proxy Router Advertisement with Code 0 means that the MN should 1043 use the [AP-ID, AR-Info] tuple (present in the options above) for 1044 movement detection and NCoA formulation. The Option-Code field in 1045 the New Access Point LLA option in this case is 1 reflecting the LLA 1046 of the access point for which the rest of the options are related. 1047 Multiple tuples may be present. 1049 A Proxy Router Advertisement with Code 1 means that the message is 1050 sent unsolicited. If a New CoA option is present following the New 1051 Router Prefix Information option, the MN SHOULD use the supplied NCoA 1052 and send FBU immediately or else stand to lose service. This message 1053 acts as a network-initiated handover trigger. See Section 3.3. The 1054 Option-Code field in the New Access Point LLA option (see below) in 1055 this case is 1 reflecting the LLA of the access point for which the 1056 rest of the options are related. 1058 A Proxy Router Advertisement with Code 2 means that no new router 1059 information is present. Each New Access Point LLA option contains 1060 an Option-Code value (described below) which indicates a specific 1061 outcome. 1063 - When the Option-Code field in the New Access Point LLA option is 1064 5, handover to that access point does not require change of CoA. 1065 No other options are required in this case. 1067 - When the Option-Code field in the New Access Point LLA option is 1068 6, PAR is not aware of the Prefix Information requested. The MN 1069 SHOULD attempt to send FBU as soon as it regains connectivity 1070 with the NAR. No other options are required in this case. 1072 - When the Option-Code field in the New Access Point LLA option is 1073 7, it means that the NAR does not support fast handover. The MN 1074 MUST stop fast handover protocol operations. No other options 1075 are required in this case. 1077 A Proxy Router Advertisement with Code 3 means that new router 1078 information is present only for a subset of access points requested. 1079 The Option-Code field values (defined above including a value of 1) 1080 distinguish different outcomes for individual access points. 1082 A Proxy Router Advertisement with Code 4 means that the subnet 1083 information regarding neighboring access points is sent unsolicited, 1084 but the message is not a handover trigger, unlike when the message is 1085 sent with Code 1. Multiple tuples may be present. 1087 When a wildcard AP identifier is supplied in the RtSolPr message, 1088 the PrRtAdv message should include any 'n' [Access Point Identifier, 1089 Link-layer address option, Prefix Information Option] tuples 1090 corresponding to the PAR's neighborhood. 1092 6.2. Inter-Access Router Messages 1094 6.2.1. Handover Initiate (HI) 1096 The Handover Initiate (HI) is an ICMPv6 message sent by an Access 1097 Router (typically PAR) to another Access Router (typically NAR) to 1098 initiate the process of a MN's handover. 1100 0 1 2 3 1101 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 1102 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1103 | Type | Code | Checksum | 1104 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1105 | Subtype |S|U| Reserved | Identifier | 1106 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1107 | Options ... 1108 +-+-+-+-+-+-+-+-+-+-+-+- 1110 Figure 6: Handover Initiate (HI) Message 1112 IP Fields: 1114 Source Address 1115 The IP address of the PAR 1117 Destination Address 1118 The IP address of the NAR 1120 Hop Limit 255. See RFC 2461. 1122 ICMP Fields: 1124 Type The Experimental Mobility Protocol Type. See [4]. 1126 Code 0 or 1. See below 1128 Checksum The ICMPv6 checksum. 1130 Subtype 4 1132 S Assigned address configuration flag. When set, this 1133 message requests a new CoA to be returned by the 1134 destination. May be set when Code = 0. MUST be 0 1135 when Code = 1. 1137 U Buffer flag. When set, the destination SHOULD buffer 1138 any packets towards the node indicated in the options 1139 of this message. Used when Code = 0, SHOULD be set 1140 to 0 when Code = 1. 1142 Reserved MUST be set to zero by the sender and ignored by 1143 the receiver. 1145 Identifier MUST be set by the sender so replies can be matched 1146 to this message. 1148 Valid Options: 1150 Link-layer address of MN 1151 The link-layer address of the MN that is 1152 undergoing handover to the destination (i.e., NAR). 1153 This option MUST be included so that the destination 1154 can recognize the MN. 1156 Previous Care of Address 1157 The IP address used by the MN while 1158 attached to the originating router. This option 1159 SHOULD be included so that host route can be 1160 established in case necessary. 1162 New Care of Address 1163 The IP address the MN wishes to use when 1164 connected to the destination. When the `S' bit is 1165 set, NAR MAY assign this address. 1167 The PAR uses a Code value of 0 when it processes an FBU with PCoA as 1168 source IP address. The PAR uses a Code value of 1 when it processes 1169 an FBU whose source IP address is not PCoA. 1171 If Handover Acknowledge (HAck) message is not received as a response 1172 in a short time period but no less than twice the typical round trip 1173 time (RTT) between source and destination, or 100 milliseconds if RTT 1174 is not known, the Handover Initiate SHOULD be re-sent. Subsequent 1175 retransmissions can be up to HI_RETRIES, but MUST use exponential 1176 backoff in which the timeout period (i.e., 2xRTT or 100 milliseconds) 1177 is doubled during each instance of retransmission. 1179 6.2.2. Handover Acknowledge (HAck) 1181 The Handover Acknowledgment message is a new ICMPv6 message that MUST 1182 be sent (typically by NAR to PAR) as a reply to the Handover Initiate 1183 message. 1185 0 1 2 3 1186 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 1187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1188 | Type | Code | Checksum | 1189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1190 | Subtype | Reserved | Identifier | 1191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1192 | Options ... 1193 +-+-+-+-+-+-+-+-+-+-+-+- 1195 Figure 7: Handover Acknowledge (HAck) Message 1197 IP Fields: 1199 Source Address 1200 Copied from the destination address of the Handover 1201 Initiate Message to which this message is a 1202 response. 1204 Destination Address 1205 Copied from the source address of the Handover 1206 Initiate Message to which this message is a 1207 response. 1209 Hop Limit 255. See RFC 2461. 1211 ICMP Fields: 1213 Type The Experimental Mobility Protocol Type. See [4]. 1215 Code 1216 0: Handover Accepted, NCoA valid 1217 1: Handover Accepted, NCoA not valid 1218 2: Handover Accepted, NCoA in use 1219 3: Handover Accepted, NCoA assigned 1220 (used in Assigned addressing) 1222 4: Handover Accepted, NCoA not assigned 1223 (used in Assigned addressing) 1224 5: Handover Accepted, use PCoA 1225 128: Handover Not Accepted, reason unspecified 1226 129: Administratively prohibited 1227 130: Insufficient resources 1229 Checksum The ICMPv6 checksum. 1231 Subtype 5 1233 Reserved MUST be set to zero by the sender and ignored by 1234 the receiver. 1236 Identifier Copied from the corresponding field in the Handover 1237 Initiate message this message is in response to. 1239 Valid Options: 1241 New Care of Address 1242 If the S flag in the Handover Initiate message is set, 1243 this option MUST be used to provide NCoA the MN should 1244 use when connected to this router. This option MAY be 1245 included even when `S' bit is not set, e.g., Code 2 1246 above. 1248 Upon receiving a HI message, the NAR MUST respond with a Handover 1249 Acknowledge message. If the `S' flag is set in the HI message, the 1250 NAR SHOULD include the New Care of Address option and a Code 3. 1252 The NAR MAY provide support for PCoA (instead of accepting or 1253 assigning NCoA), using a host route entry to forward packets to the 1254 PCoA, and using a tunnel to the PAR to forward packets from the MN 1255 (sent with PCoA as source IP address). This host route entry SHOULD 1256 be used to forward packets once the NAR detects that the particular 1257 MN is attached to its link. The NAR indicates forwarding support 1258 for PCoA using Code value 5 in the HAck message. Subsequently, PAR 1259 establishes a tunnel to NAR in order to forward packets arriving for 1260 PCoA. 1262 When responding to a HI message containing a Code value 1, the Code 1263 values 1, 2, and 4 in the HAck message are not relevant. 1265 Finally, the new access router can always refuse handover, in which 1266 case it should indicate the reason in one of the available Code 1267 values. 1269 6.3. New Mobility Header Messages 1271 Mobile IPv6 uses a new IPv6 header type called Mobility Header [3]. 1272 The Fast Binding Update, Fast Binding Acknowledgment and Fast 1273 Neighbor Advertisement messages use the Mobility Header. 1275 6.3.1. Fast Binding Update (FBU) 1277 The Fast Binding Update message is identical to the Mobile IPv6 1278 Binding Update (BU) message. However, the processing rules are 1279 slightly different. 1281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1282 | Sequence # | 1283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1284 |A|H|L|K| Reserved | Lifetime | 1285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1286 | | 1287 . . 1288 . Mobility options . 1289 . . 1290 | | 1291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1293 Figure 8: Fast Binding Update (FBU) Message 1295 IP fields: 1297 Source address The PCoA or NCoA 1299 Destination Address 1300 The IP address of the Previous Access 1301 Router 1303 `A' flag MUST be set to one to request PAR to send a Fast 1304 Binding Acknowledgment message. 1306 `H' flag MUST be set to one. See [3]. 1308 `L' flag See [3]. 1310 `K' flag See [3]. 1312 Reserved This field is unused. MUST be set zero. 1314 Sequence Number See [3]. 1316 Lifetime The requested time in seconds for which the sender 1317 wishes to have a binding. 1319 Mobility Options 1320 MUST contain alternate CoA option set to NCoA IP 1321 address when FBU is sent from PAR's link. MUST 1322 contain the Binding Authorization Data for FMIP 1323 (BADF) option. See 6.4.5. 1325 The MN sends FBU message any time after receiving a PrRtAdv message. 1326 If the MN moves prior to receiving a PrRtAdv message, it SHOULD send 1327 a FBU to the PAR after configuring NCoA on the NAR according to 1328 Neighbor Discovery and IPv6 Address Configuration protocols. 1330 The source IP address is PCoA when FBU is sent from PAR's link, and 1331 the source IP address is NCoA when sent from NAR's link. 1333 The FBU MUST also include the Home Address Option and the Home 1334 Address is PCoA. A FBU message MUST be protected so that PAR is able 1335 to determine that the FBU message is sent by a genuine MN. 1337 6.3.2. Fast Binding Acknowledgment (FBack) 1339 The Fast Binding Acknowledgment message is sent by the PAR to 1340 acknowledge receipt of a Fast Binding Update message in which the `A' 1341 bit is set. If PAR sends a HI message to the NAR after processing 1342 an FBU, the FBack message SHOULD NOT be sent to the MN before the 1343 PAR receives a HAck message from the NAR. The PAR MAY send the 1344 FBack immediately in the reactive mode however. The Fast Binding 1345 Acknowledgment MAY also be sent to the MN on the old link. 1347 IP fields: 1349 Source address The IP address of the Previous Access 1350 Router 1352 Destination Address The NCoA 1354 Status 1355 8-bit unsigned integer indicating the 1356 disposition of the Fast Binding Update. Values 1357 of the Status field less than 128 indicate that 1358 the Binding Update was accepted by the receiving 1359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1360 | Status |K| Reserved | 1361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1362 | Sequence # | Lifetime | 1363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1364 | | 1365 . . 1366 . Mobility options . 1367 . . 1368 | | 1369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1371 Figure 9: Fast Binding Acknowledgment (FBack) Message 1373 node. The following such Status values are 1374 currently defined: 1376 0 Fast Binding Update accepted 1377 1 Fast Binding Update accepted but NCoA is 1378 invalid. Use NCoA supplied in ``alternate'' CoA 1380 Values of the Status field greater than or equal 1381 to 128 indicate that the Binding Update was 1382 rejected by the receiving node. The following 1383 such Status values are currently defined: 1385 128 Reason unspecified 1386 129 Administratively prohibited 1387 130 Insufficient resources 1388 131 Incorrect interface identifier length 1390 `K' flag See [3]. 1392 Reserved An unused field. MUST be set to zero. 1394 Sequence Number Copied from FBU message for use by the MN in 1395 matching this acknowledgment with an outstanding 1396 FBU. 1398 Lifetime 1399 The granted lifetime in seconds for which the 1400 sender of this message will retain a binding for 1401 traffic redirection. 1403 Mobility Options MUST contain ``alternate'' CoA if Status is 1. 1404 MUST contain the Binding Authorization Data for 1405 FMIP (BADF) option. See 6.4.5. 1407 6.3.3. Unsolicited Neighbor Advertisement (UNA) 1409 This is the same message as in [8] with the requirement that the 'O' 1410 bit is always set to zero. Since this is an unsolicited message, the 1411 'S' bit is zero, and since this is sent by a MN, the 'R' bit is also 1412 zero. 1414 The Source Address must be the NCoA. The Destination Address is 1415 typically the all-nodes multicast address. 1417 The Target Address must include the NCoA, and Target link-layer 1418 address must include the MN's LLA. 1420 The MN sends a UNA message to the NAR, as soon as it regains 1421 connectivity on the new link. Arriving or buffered packets can 1422 be immediately forwarded. If NAR is proxying NCoA, it creates a 1423 neighbor cache entry in STALE state but forwards packets as it 1424 determines bidirectional reachability. If there is an entry in 1425 INCOMPLETE state without a link-layer address, it sets it to STALE. 1426 If there is no entry at all, creating an entry in STALE state is 1427 recommended since forwarding can immediately begin when packets 1428 arrive without first invoking Neighbor Solicitation and Advertisement 1429 (which may involve retransmission delay in the event of messages 1430 being lost). During the process of creating a neighbor cache entry, 1431 NAR can also detect if NCoA is in use, and immediately sends a Router 1432 Advertisement with NAACK option in the event of collision (see 1433 Section 5.4 for more details). 1435 The combination of NCoA (present in source IP address) and the 1436 Link-Layer Address (present as a Target LLA) SHOULD be used to 1437 distinguish the MN from other nodes. 1439 6.4. New Options 1441 All the options are of the form shown in Figure 10. 1443 The Type values are defined from the Neighbor Discovery options 1444 space. The Length field is in units of 8 octets, except for the 1446 0 1 2 3 1447 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 1448 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1449 | Type | Length | Option-Code | | 1450 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1451 ~ ... ~ 1452 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1454 Figure 10: Option Format 1456 Mobility Header Link-Layer Address option, whose Length field 1457 is in units of octets in accordance with [3], Section 6.2. And, 1458 Option-Code provides additional information for each of the options 1459 (See individual options below). 1461 6.4.1. IP Address Option 1463 This option is sent in the Proxy Router Advertisement, the Handover 1464 Initiate, and Handover Acknowledge messages. 1466 0 1 2 3 1467 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 1468 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1469 | Type | Length | Option-Code | Prefix Length | 1470 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1471 | Reserved | 1472 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1473 | | 1474 + + 1475 | | 1476 + IPv6 Address + 1477 | | 1478 + + 1479 | | 1480 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1482 Figure 11: IPv6 Address Option 1484 Type 1485 To be assigned by IANA 1487 Length 1488 The size of this option in 8 octets including the Type, 1489 Option-Code and Length fields. 1491 Option-Code 1492 1 Old Care-of Address 1493 2 New Care-of Address 1494 3 NAR's IP address 1496 Prefix Length 1497 The Length of the IPv6 Address Prefix. 1499 Reserved 1500 MUST be set to zero by the sender and MUST be 1501 ignored by the receiver. 1503 IPv6 address 1504 The IP address defined by the Option-Code field. 1506 6.4.2. New Router Prefix Information Option 1508 This option is sent in the PrRtAdv message in order to provide the 1509 prefix information valid on the NAR. 1511 Type 1512 To be assigned by IANA 1514 Length 1515 The size of this option in 8 octets including the Type, 1516 Option-Code and Length fields. 1518 Option-Code 1519 0 1521 Prefix Length 1522 8-bit unsigned integer. The number of leading bits in the 1523 Prefix that are valid. The value ranges from 0 to 128. 1525 Reserved 1526 MUST be set to zero by the sender and MUST be 1527 ignored by the receiver. 1529 0 1 2 3 1530 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 1531 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1532 | Type | Length | Option-Code | Prefix Length | 1533 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1534 | Reserved | 1535 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1536 | | 1537 + + 1538 | | 1539 + Prefix + 1540 | | 1541 + + 1542 | | 1543 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1545 Figure 12: New Router Prefix Information Option 1547 Prefix 1548 An IP address or a prefix of an IP address. The Prefix Length 1549 field contains the number of valid leading bits in the prefix. 1550 The bits in the prefix after the prefix length are reserved 1551 and MUST be initialized to zero by the sender and ignored by 1552 the receiver. 1554 6.4.3. Link-layer Address (LLA) Option 1556 0 1 2 3 1557 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 1558 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1559 | Type | Length | Option-Code | LLA... 1560 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1562 Figure 13: Link-Layer Address Option 1564 Type 1565 To be assigned by IANA 1567 Length 1568 The size of this option in 8 octets including the Type, 1569 Option-Code and Length fields. 1571 Option-Code 1572 0 wildcard requesting resolution for all nearby access points 1573 1 Link-layer Address of the New Access Point 1574 2 Link-layer Address of the MN 1575 3 Link-layer Address of the NAR (i.e., Proxied Originator) 1576 4 Link-layer Address of the source of RtSolPr or PrRtAdv 1577 message 1578 5 The access point identified by the LLA belongs to the 1579 current interface of the router 1580 6 No prefix information available for the access point 1581 identified by the LLA 1582 7 No fast handovers support available for the access point 1583 identified by the LLA 1585 LLA 1586 The variable length link-layer address. 1588 The LLA Option does not have a length field for the LLA itself. The 1589 implementations must consult the specific link layer over which the 1590 protocol is run in order to determine the content and length of the 1591 LLA. 1593 Depending on the size of individual LLA option, appropriate padding 1594 MUST be used to ensure that the entire option size is a multiple of 8 1595 octects. 1597 The New Access Point Link Layer address contains the link-layer 1598 address of the access point for which handover is about to be 1599 attempted. This is used in the Router Solicitation for Proxy 1600 Advertisement message. 1602 The MN Link-Layer address option contains the link-layer address of a 1603 MN. It is used in the Handover Initiate message. 1605 The NAR (i.e., Proxied Originator) Link-Layer address option contains 1606 the Link Layer address of the Access Router for which the Proxy 1607 Router Solicitation message refers to. 1609 6.4.4. Mobility Header Link-layer Address (MH-LLA) Option 1611 This option is identical to the LLA option, but is carried in the 1612 Mobility Header messages, e.g., FBU. In the future, other Mobility 1613 Header messages may also make use of this option. The format of the 1614 option is shown in Figure 14. There are no alignment requirements 1615 for this option. 1617 0 1 2 3 1618 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 1619 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1620 | Type | Length | 1621 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1622 | Option-Code | LLA .... 1623 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1625 Figure 14: Mobility Header Link-Layer Address Option 1627 Type 1628 To be assigned by IANA 1630 Length 1631 The size of this option in octets not including the Type 1632 and Length fields. 1634 Option-Code 1635 2 Link-layer Address of the MN 1637 LLA 1638 The variable length link-layer address. 1640 6.4.5. Binding Authorization Data for FMIPv6 (BADF) 1642 This option MUST be present in FBU and FBack messages. The security 1643 association between the MN and the PAR is established by companion 1644 protocols [5]. This option specifies how to compute and verify a MAC 1645 using the established security association. 1647 The format of this option is shown in Figure 15. 1649 Type 1650 To be assigned by IANA 1652 Option Length 1653 The length of the Authenticator in bytes 1655 0 1 2 3 1656 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 1657 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1658 | Type | Option Length | 1659 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1660 | SPI | 1661 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1662 | | 1663 + + 1664 | Authenticator | 1665 + + 1666 | | 1667 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1669 Figure 15: Binding Authorization Data for FMIPv6 (BADF) Option 1671 SPI 1672 Security Parameter Index. SPI = 0 is reserved for the 1673 Authenticator computed using SEND-based handover keys. 1675 Authenticator 1676 Same as in RFC 3775, with "correspondent" replaced by 1677 PAR's IP address, and Kbm replaced by the shared key 1678 between the MN and the PAR. 1680 The default MAC calculation is done using HMAC|SHA1 with the first 1681 96 bits used for the MAC. Since there is an Option Length field, 1682 implementations can use other algorithms such as HMAC|SHA256 for 1683 instance. 1685 This option MUST be the last Mobility Option present. 1687 6.4.6. Neighbor Advertisement Acknowledgment (NAACK) 1689 Type 1690 To be assigned by IANA. 1692 Length 1693 8-bit unsigned integer. Length of the option, in 8 1695 0 1 2 3 1696 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 1697 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1698 | Type | Length | Option-Code | Status | 1699 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1700 | Reserved | 1701 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1703 Figure 16: Neighbor Advertisement Acknowledgment Option 1705 octets. The length is 1 when a new CoA is not supplied. The 1706 length is 3 when a new CoA is present (immediately following 1707 the Reserved field) 1709 Option-Code 1710 0 1712 Status 1713 8-bit unsigned integer indicating the disposition of the Fast 1714 Neighbor Advertisement message. The following Status 1715 values are currently defined: 1717 1 The New CoA is invalid 1718 2 The New CoA is invalid, use the supplied CoA. The New 1719 CoA (in the form of an IP Address Option) MUST be 1720 present following the Reserved field. 1721 3 The New CoA is invalid, use NAR's IP address as NCoA in 1722 FBU 1723 4 PCoA supplied, do not send FBU 1724 128 Link Layer Address unrecognized 1726 Reserved 1728 MUST be set to zero by the sender and MUST be 1729 ignored by the receiver. 1731 The NAR responds to UNA with the NAACK option to notify the MN 1732 to use a different NCoA if there is address collision. If the 1733 NCoA is invalid, the Router Advertisement MUST use the NCoA as the 1734 destination address but use the L2 address present in UNA. The MN 1735 SHOULD use the NCoA if it is supplied with the NAACK option. If the 1736 NAACK indicates that the Link Layer Address is unrecognized the MN 1737 MUST NOT use the NCoA or the PCoA and SHOULD start immediately the 1738 process of acquiring different NCoA at the NAR. 1740 In the future, new option types may be defined. 1742 7. Configurable Parameters 1744 Parameter Name Default Value Definition 1745 ------------------- ---------------------- ------- 1746 RTSOLPR_RETRIES 3 Section6.1.1 1747 MAX_RTSOLPR_RATE 3 Section6.1.1 1748 FBU_RETRIES 3 Section 4 1749 PROXY_ND_LIFETIME 1.5 seconds Section 6.2.2 1750 HI_RETRIES 3 Section 6.2.1 1752 8. Security Considerations 1754 The following security vulnerabilities are identified, and suggested 1755 solutions mentioned. 1757 1. Insecure FBU: in this case, packets meant for one address could 1758 be stolen, or redirected to some unsuspecting node. This concern 1759 is the same as that in a MN and Home Agent relationship. 1761 Hence, the PAR MUST ensure that the FBU packet arrived from a 1762 node that legitimately owns the PCoA. The access router and its 1763 hosts may use any available mechanism to establish a security 1764 association which MUST be used to secure FBU. The current version 1765 of this protocol relies on a companion protocol [5] to establish 1766 such a security association. Using the shared handover key 1767 from [5], the Authenticator in BADF option (see 6.4.5) MUST be 1768 computed, and the BADF option included in FBU and FBack messages. 1770 If an access router can ensure that the source IP address in 1771 an arriving packet could only have originated from the node 1772 whose link-layer address is in the router's neighbor cache, then 1773 a bogus node cannot use a victim's IP address for malicious 1774 redirection of traffic. Such an operation is recommended at 1775 least on neighbor discovery messages including the RtSolPr 1776 message. 1778 2. Secure FBU, malicious or inadvertent redirection: in this case, 1779 the FBU is secured, but the target of binding happens to be an 1780 unsuspecting node either due to inadvertent operation or due 1781 to malicious intent. This vulnerability can lead to a MN with 1782 genuine security association with its access router redirecting 1783 traffic to an incorrect address. 1785 However, the target of malicious traffic redirection is limited 1786 to an interface on an access router with which the PAR has a 1787 security association. The PAR MUST verify that the NCoA to 1788 which PCoA is being bound actually belongs to NAR's prefix. In 1789 order to do this, HI and HAck message exchanges are to be used. 1790 When NAR accepts NCoA in HI (with Code = 0), it proxies NCoA so 1791 that any arriving packets are not sent on the link until the MN 1792 attaches and announces itself through UNA. So, any inadvertent or 1793 malicious redirection to a host is avoided. It is still possible 1794 to jam NAR's buffer with redirected traffic. However, since 1795 NAR's handover state corresponding to NCoA has a finite (and 1796 short) lifetime corresponding to a small multiple of anticipated 1797 handover latency, the extent of this vulnerability is arguably 1798 small. 1800 3. Sending FBU from NAR's link: a malicious node may send FBU from 1801 NAR's link providing an unsuspecting node's address as NCoA. 1802 This is similar to base Mobile IP where the MN can provide some 1803 other's node as its CoA to its Home Agent. As discussed in 1804 Section 5.4, the extent of such a misdelivery can be controlled 1805 and recovery is possible. In addition, it is possible to isolate 1806 the MN if it continues to misbehave. 1808 9. IANA Considerations 1810 This document defines four new experimental ICMPv6 messages which use 1811 the Experimental Mobility Protocol ICMPv6 format [4]. These require 1812 four new Subtype value assignments out of the Experimental Mobility 1813 Protocol Subtype Registry [4] as follows: 1815 Subtype Description Reference 1816 ------- ----------- --------- 1817 2 RtSolPr Section 6.1.1 1818 3 PrRtAdv Section 6.1.2 1819 4 HI Section 6.2.1 1820 5 HAck Section 6.2.2 1822 The document defines four new Neighbor Discovery [8] options which 1823 need Type assignment from IANA. 1825 Option-Type Description Reference 1826 ----------- ----------- --------- 1827 TBD IP Address Option Section 6.4.1 1828 TBD New Router Prefix 1829 Information Option Section 6.4.2 1830 TBD Link-layer Address 1831 Option Section 6.4.3 1832 TBD Neighbor Advertisement 1833 Acknowledgment Option Section 6.4.6 1835 The document defines three new Mobility Header messages which 1836 need type allocation from the Mobility Header Types registry at 1837 http://www.iana.org/assignments/mobility-parameters: 1839 1. Fast Binding Update, described in Section 6.3.1 1841 2. Fast Binding Acknowledgment, described in Section 6.3.2, and 1843 The document defines two new Mobility Options which need 1844 type assignment from the Mobility Options Type registry at 1845 http://www.iana.org/assignments/mobility-parameters: 1847 1. Mobility Header Link-Layer Address option, described in 1848 Section 6.4.4. 1850 2. Binding Authorization Data for FMIPv6 (BADF) option, described in 1851 Section 6.4.5. 1853 10. Acknowledgments 1855 The editor would like to thank all those who have provided feedback 1856 on this specification, and acknowledges the following people: Vijay 1857 Devarapalli, Youn-Hee Han, Emil Ivov, Syam Madanapalli, Suvidh 1858 Mathur, Andre Martin, Javier Martin, Koshiro Mitsuya, Gabriel 1859 Montenegro, Takeshi Ogawa, Sun Peng, YC Peng, Alex Petrescu, Domagoj 1860 Premec, Subba Reddy, K. Raghav, Ranjit Wable and Jonathan Wood. The 1861 editor would like to acknowledge the contribution from James Kempf 1862 to improve this specification. The editor would also like to thank 1863 [mipshop] working group chair Gabriel Montenegro and the erstwhile 1864 [mobile ip] working group chairs Basavaraj Patil and Phil Roberts for 1865 providing much support for this work. 1867 11. Normative References 1869 [1] S. Bradner, ``Key words for use in RFCs to Indicate Requirement 1870 Levels,'' Request for Comments (Best Current Practice) 2119, 1871 Internet Engineering Task Force, March 1997. 1873 [2] A. Conta and S. Deering, ``Internet Control Message 1874 Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) 1875 Specification'', Request for Comments (Draft Standard) 2463, 1876 Internet Engineering Task Force, December 1998. 1878 [3] D. Johnson, C. E. Perkins, and J. Arkko, ``Mobility Support in 1879 IPv6'', Request for Comments (Proposed Standard) 3775, Internet 1880 Engineering Task Force, June 2004. 1882 [4] J. Kempf, ``Instructions for Seamoby and Experimental Mobility 1883 Protocol IANA Allocations," RFC 4065, Internet Engineering Task 1884 Force, June 2004. 1886 [5] J. Kempf and R. Koodli, "Distributing a Symmetric FMIPv6 1887 Handover Key using SEND," draft-ietf-mipshop-handover-key-00.txt 1888 (work in progress), February 2007. 1890 [6] S. Kent and R. Atkinson, ``IP Authentication Header'', Request 1891 for Comments (Draft Standard) 2402, Internet Engineering Task 1892 Force, November 1998. 1894 [7] R. Koodli (Editor), "Fast Handovers for Mobile IPv6," Request 1895 For Comments 4068, Internet Engineering Task Force, July 2005. 1897 [8] T. Narten, E. Nordmark, and W. Simpson, ``Neighbor Discovery for 1898 IP Version 6 (IPv6)'', Request for Comments (Draft Standard) 1899 2461, Internet Engineering Task Force, December 1998. 1901 [9] S. Thomson and T. Narten, ``IPv6 Stateless Address 1902 Autoconfiguration'', Request for Comments (Draft Standard) 2462, 1903 Internet Engineering Task Force, December 1998. 1905 12. Author's Address 1907 Rajeev Koodli, Editor 1908 Nokia Research Center 1909 313 Fairchild Drive 1910 Mountain View, CA 94043 USA 1911 E-Mail: Rajeev.Koodli@nokia.com 1913 13. 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 A. Change Log 1923 - RFC4068bis: all the issues in the tracker since the publication 1924 of RFC 4068. (http://www.mip4.org/issues/tracker/mipshop) 1926 The following changes pre-date RFC 4068 publication. 1928 - Added IPSec AH reference. 1930 - Changed options format to make use of RFC 2461 options Type 1931 space. Revised IANA Considerations section accordingly. 1933 - Added exponential backoff for retransmissions. Added rate 1934 limiting for RtSolPr message. 1936 - Replaced ``attachment point'' with ``access point'' for 1937 consistency. 1939 - Clarified [AP-ID, AR-Info] in Section 2. Clarified use of Prefix 1940 Information Option in Section 6.1.2. 1942 - Separated MH-LLA from LLA to future-proof LLA option. 1944 The following changes refer up to version 02 (under mipshop). The 1945 Section numbers refer to version 06 (under mobile ip). 1947 - New ICMPv6 format incorporated. ID Nits conformance. 1949 - Last Call comments incorporated 1951 - Revised the security considerations section in v07 1953 - Refined and added a section on network-initiated handover v07 1955 - Section 3 format change 1957 - Section 4 format change (i.e., no subsections). 1959 - Description in Section 4.4 merged with ``Fast or Erroneous 1960 Movement'' 1962 - Section 4.5 deprecated 1964 - Section 4.6 deprecated 1966 - Revision of some message formats in Section 6 1968 Intellectual Property Statement 1970 The IETF takes no position regarding the validity or scope of any 1971 Intellectual Property Rights or other rights that might be claimed to 1972 pertain to the implementation or use of the technology described in 1973 this document or the extent to which any license under such rights 1974 might or might not be available; nor does it represent that it has 1975 made any independent effort to identify any such rights. Information 1976 on the procedures with respect to rights in RFC documents can be 1977 found in BCP 78 and BCP 79. 1979 Copies of IPR disclosures made to the IETF Secretariat and any 1980 assurances of licenses to be made available, or the result of an 1981 attempt made to obtain a general license or permission for the 1982 use of such proprietary rights by implementers or users of this 1983 specification can be obtained from the IETF on-line IPR repository at 1984 http://www.ietf.org/ipr. 1986 The IETF invites any interested party to bring to its attention any 1987 copyrights, patents or patent applications, or other proprietary 1988 rights that may cover technology that may be required to implement 1989 this standard. Please address the information to the IETF at 1990 ietf-ipr@ietf.org. 1992 Disclaimer of Validity 1994 This document and the information contained herein are provided on an 1995 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1996 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1997 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1998 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1999 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2000 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2002 Copyright Statement 2004 Copyright (C) The IETF Trust (2007). 2006 This document is subject to the rights, licenses and restrictions 2007 contained in BCP 78, and except as set forth therein, the authors 2008 retain all their rights. 2010 Acknowledgment 2012 Funding for the RFC Editor function is currently provided by the 2013 Internet Society.