idnits 2.17.1 draft-ietf-mipshop-fmipv6-rfc4068bis-02.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 2060. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2036. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2043. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2049. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 7 longer pages, the longest (page 5) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 67 instances of too long lines in the document, the longest one being 7 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 298: '...l. When feasible, the MN SHOULD send...' RFC 2119 keyword, line 300: '...nt to NAR. An FBU message MUST contain...' RFC 2119 keyword, line 307: '... the opposite direction, the MN SHOULD...' RFC 2119 keyword, line 309: '...date. And, PAR SHOULD forward the in...' RFC 2119 keyword, line 354: '... messages SHOULD be used. The acc...' (114 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.) -- Couldn't find a document date in the document -- date freshness check skipped. 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 1998 -- Looks like a reference, but probably isn't: 'AR-Info' on line 1998 == Unused Reference: '6' is defined on line 1946, 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 (~~), 5 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 Siemens Networks 3 Category: Standards Track July 9 2007 4 Updates: RFC 4068 5 Expires: January 8, 2008 7 Fast Handovers for Mobile IPv6 8 draft-ietf-mipshop-fmipv6-rfc4068bis-02.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 21 six months and may be updated, replaced, or obsoleted by other 22 documents at any time. It is inappropriate to use Internet-Drafts 23 as reference material or to cite them other than as "work in 24 progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This document is a submission of the IETF MIP6 WG. Comments should 33 be directed to the MIP6 WG mailing list, mip6@ietf.org. 35 Abstract 37 Mobile IPv6 enables a Mobile Node to maintain its connectivity 38 to the Internet when moving from an Access Router to another, a 39 process referred to as handover. During this time, the Mobile 40 Node is unable to send or receive packets due to both link 41 switching delay and IP protocol operations. The "handover latency" 42 resulting from standard Mobile IPv6 procedures, namely, movement 43 detection, new Care of Address configuration and Binding Update, 44 is often unacceptable to real-time traffic such as Voice over 45 IP. Reducing the handover latency could be beneficial to non 46 real-time, throughput-sensitive applications as well. This 47 document specifies a protocol to improve handover latency due to 48 Mobile IPv6 procedures. This document does not address improving 49 the link switching latency. 51 Contents 53 Abstract i 55 1. Introduction 2 57 2. Terminology 2 59 3. Protocol Overview 4 60 3.1. Addressing the Handover Latency . . . . . . . . . . 4 61 3.2. Protocol Operation . . . . . . . . . . . . . . 7 62 3.3. Protocol Operation during Network-initiated Handover . . . 8 64 4. Protocol Details 10 66 5. Other Considerations 13 67 5.1. Handover Capability Exchange . . . . . . . . . . . 13 68 5.2. Determining New Care of Address . . . . . . . . . . . 14 69 5.3. Prefix Management . . . . . . . . . . . . . . . . 14 70 5.4. Packet Loss . . . . . . . . . . . . . . . . . . 14 71 5.5. DAD Handling . . . . . . . . . . . . . . . . . 15 72 5.6. Fast or Erroneous Movement . . . . . . . . . . . . 17 74 6. Message Formats 18 75 6.1. New Neighborhood Discovery Messages . . . . . . . . . . 18 76 6.1.1. Router Solicitation for Proxy Advertisement 77 (RtSolPr) . . . . . . . . . . . . . . . 18 78 6.1.2. Proxy Router Advertisement (PrRtAdv) . . . . . 20 79 6.2. Inter-Access Router Messages . . . . . . . . . . . 23 80 6.2.1. Handover Initiate (HI) . . . . . . . . . . 23 81 6.2.2. Handover Acknowledge (HAck) . . . . . . . . . 25 82 6.3. New Mobility Header Messages . . . . . . . . . . . 27 83 6.3.1. Fast Binding Update (FBU) . . . . . . . . . . 27 84 6.3.2. Fast Binding Acknowledgment (FBack) . . . . . . 28 85 6.3.3. Unsolicited Neighbor Advertisement (UNA) . . . . 30 86 6.4. New Options . . . . . . . . . . . . . . . . . . 30 87 6.4.1. IP Address Option . . . . . . . . . . . . . 31 88 6.4.2. New Router Prefix Information Option . . . . . 32 89 6.4.3. Link-layer Address (LLA) Option . . . . . . . . 33 90 6.4.4. Mobility Header Link-layer Address (MH-LLA) 91 Option . . . . . . . . . . . . . . . . . 34 92 6.4.5. Binding Authorization Data for FMIPv6 (BADF) . . . 35 93 6.4.6. Neighbor Advertisement Acknowledgment (NAACK) . . . 36 95 7. Configurable Parameters 37 97 8. Security Considerations 37 98 9. IANA Considerations 39 100 10. Acknowledgments 40 102 11. Normative References 40 104 12. Author's Address 41 106 13. Contributors 41 108 A. Change Log 41 110 Intellectual Property Statement 42 112 Disclaimer of Validity 43 114 Copyright Statement 43 116 Acknowledgment 43 117 1. Introduction 119 Mobile IPv6 [3] describes the protocol operations for a mobile node 120 to maintain connectivity to the Internet during its handover from 121 one access router to another. These operations involve movement 122 detection, IP address configuration, and location update. The 123 combined handover latency is often sufficient to affect real-time 124 applications. Throughput-sensitive applications can also benefit 125 from reducing this latency. This document describes a protocol to 126 reduce the handover latency. 128 This specification addresses the following problem: how to 129 allow a mobile node to send packets as soon as it detects a new 130 subnet link, and how to deliver packets to a mobile node as soon 131 as its attachment is detected by the new access router. The 132 protocol defines IP protocol messages necessary for its operation 133 regardless of link technology. It does this without depending 134 on specific link-layer features while allowing link-specific 135 customizations. By definition, this specification considers 136 handovers that interwork with Mobile IP: once attached to its new 137 access router, a MN engages in Mobile IP operations including 138 Return Routability [3]. There are no special requirements for a 139 mobile node to behave differently with respect to its standard 140 Mobile IP operations. 142 2. Terminology 144 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 145 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "OPTIONAL", 146 and "silently ignore" in this document are to be interpreted as 147 described in RFC 2119 [1]. 149 The following terminology and abbreviations are used in this 150 document in addition to those defined in [3]. The reference 151 handover scenario is illustrated in Figure 1. 153 Mobile Node (MN) 154 A Mobile IPv6 host 156 Access Point (AP) 157 A Layer 2 device connected to an IP subnet that 158 offers wireless connectivity to a MN. An Access 159 Point Identifier (AP-ID) refers the AP's L2 address. 160 Sometimes, AP-ID is also referred to as a Basic Service 161 Set IDentifier (BSSID). 163 Access Router (AR) 164 The MN's default router 166 Previous Access Router (PAR) 167 The MN's default router prior to its handover 169 New Access Router (NAR) 170 The MN's anticipated default router subsequent to its 171 handover 173 Previous CoA (PCoA) 174 The MN's Care of Address valid on PAR's subnet 176 New CoA (NCoA) 177 The MN's Care of Address valid on NAR's subnet 179 Handover 180 A process of terminating existing connectivity and 181 obtaining new IP connectivity. 183 Router Solicitation for Proxy Advertisement (RtSolPr) 184 A message from the MN to the PAR requesting information 185 for a potential handover 187 Proxy Router Advertisement (PrRtAdv) 188 A message from the PAR to the MN that provides 189 information about neighboring links facilitating 190 expedited movement detection. The message can also act 191 as a trigger for network-initiated handover. 193 (AP-ID, AR-Info) tuple 194 Contains an access router's L2 and IP addresses, and 195 prefix valid on the interface to which the Access 196 Point (identified by AP-ID) is attached. The triplet 197 [Router's L2 address, Router's IP address and Prefix] 198 is called "AR-Info". See also Section 5.3. 200 Assigned Addressing 201 A particular type of NCoA configuration in which the 202 NAR assigns an IPv6 address for the MN. The method by 203 which NAR manages its address pool is not specified in 204 this document. 206 Fast Binding Update (FBU) 207 A message from the MN instructing its PAR to redirect 208 its traffic (towards NAR) 210 Fast Binding Acknowledgment (FBack) 211 A message from the PAR in response to FBU 213 Unsolicited Neighbor Advertisement (UNA) 214 The message in [8] with 'O' bit cleared 216 Fast Neighbor Advertisement (FNA) 217 This message from RFC4068 [7] is deprecated. The 218 UNA message above is the preferred message in this 219 specification. 221 Handover Initiate (HI) 222 A message from the PAR to the NAR regarding a MN's 223 handover 225 Handover Acknowledge (HAck) 226 A message from the NAR to the PAR as a response to HI 228 v +--------------+ 229 +-+ | Previous | < 230 | | ------------ | Access | ------- >-----\ 231 +-+ | Router | < \ 232 MN | (PAR) | \ 233 | +--------------+ +---------------+ 234 | ^ IP | Correspondent | 235 | | Network | Node | 236 V | +---------------+ 237 v / 238 v +--------------+ / 239 +-+ | New | < / 240 | | ------------ | Access | ------- >-----/ 241 +-+ | Router | < 242 MN | (NAR) | 243 +--------------+ 245 Figure 1: Reference Scenario for Handover 247 3. Protocol Overview 249 3.1. Addressing the Handover Latency 251 The ability to immediately send packets from a new subnet link 252 depends on the "IP connectivity" latency, which in turn depends 253 on the movement detection latency and the new CoA configuration 254 latency. Once a MN is IP-capable on the new subnet link, it 255 can send a Binding Update to its Home Agent and one or more 256 correspondents. Once its correspondents successfully process the 257 Binding Update, which typically involves the Return Routability 258 procedure, the MN can receive packets at the new CoA. So, the 259 ability to receive packets from correspondents directly at its 260 new CoA depends on the Binding Update latency as well as the IP 261 connectivity latency. 263 The protocol enables a MN to quickly detect that it has moved to 264 a new subnet by providing the new access point and the associated 265 subnet prefix information when the MN is still connected to 266 its current subnet (i.e., PAR in Figure 1). For instance, a MN 267 may discover available access points using link-layer specific 268 mechanisms (e.g., a "scan" in WLAN) and then request subnet 269 information corresponding to one or more of those discovered access 270 points. The MN may do this after performing router discovery. The 271 MN may also do this at any time while connected to its current 272 router. The result of resolving an identifier associated with an 273 access point is a [AP-ID, AR-Info] tuple, which a MN can use in 274 readily detecting movement: when attachment to an access point 275 with AP-ID takes place, the MN knows the corresponding new router's 276 co-ordinates including its prefix, IP address and L2 address. The 277 "Router Solicitation for Proxy Advertisement (RtSolPr)" and "Proxy 278 Router Advertisement (PrRtAdv)" messages 6.1 are used for aiding 279 movement detection. 281 Through the RtSolPr and PrRtAdv messages, the MN also formulates a 282 prospective new CoA (NCoA), when it is still present on the PAR's 283 link. Hence, the latency due to new prefix discovery subsequent to 284 handover is eliminated. Furthermore, this prospective address can 285 be used immediately after attaching to the new subnet link (i.e., 286 NAR's link) when the MN has received a "Fast Binding Acknowledgment 287 (FBack)" message prior to its movement. In the event it moves 288 without receiving an FBack, the MN can still start using NCoA 289 after announcing its attachment through an unsolicited Neighbor 290 Advertisement message (with the 'O' bit set to zero) message [8]; 291 NAR responds to to this UNA message in case the tentative address 292 is already in use. In this way, NCoA configuration latency is 293 reduced. 295 In order to reduce the Binding Update latency, the protocol 296 specifies a binding between the Previous CoA (PCoA) and NCoA. A 297 MN sends a "Fast Binding Update" message to its Previous Access 298 Router to establish this tunnel. When feasible, the MN SHOULD send 299 FBU from PAR's link. Otherwise, it should send it immediately 300 after detecting attachment to NAR. An FBU message MUST contain 301 the Binding Authorization Data for FMIPv6 (BADF) option (see 302 Section 6.4.5) in order to ensure that only a legitimate MN that 303 owns the PCoA is able to establish a binding. Subsequent sections 304 describe the protocol mechanics. In any case, the result is that 305 PAR begins tunneling packets arriving for PCoA to NCoA. Such a 306 tunnel remains active until the MN completes the Binding Update 307 with its correspondents. In the opposite direction, the MN SHOULD 308 reverse tunnel packets to PAR, again until it completes Binding 309 Update. And, PAR SHOULD forward the inner packet in the tunnel to 310 its destination (i.e., to the MN's correspondent). Such a reverse 311 tunnel ensures that packets containing PCoA as source IP address 312 are not dropped due to ingress filtering. Even though the MN is 313 IP-capable on the new link, it cannot use NCoA directly with its 314 correspondents without the correspondents first establishing a 315 binding cache entry (for NCoA). Forwarding support for PCoA is 316 provided through a reverse tunnel between the MN and the PAR. 318 Setting up a tunnel alone does not ensure that the MN receives 319 packets as soon as attaching to a new subnet link, unless NAR can 320 detect the MN's presence. A neighbor discovery operation involving 321 a neighbor's address resolution (i.e., Neighbor Solicitation and 322 Neighbor Advertisement) typically results in considerable delay, 323 sometimes lasting multiple seconds. For instance, when arriving 324 packets trigger NAR to send Neighbor Solicitation before the MN 325 attaches, subsequent re-transmissions of address resolution are 326 separated by a default period of one second each. In order to 327 circumvent this delay, a MN announces its attachment immediately 328 with an UNA message that allows NAR to forward packets to the MN 329 right away. As a response to UNA, the NAR creates an entry or 330 updates an existing one (while taking any conflicts into account) 331 in order to forward packets to the MN (see details below). Through 332 tunnel establishment for PCoA and fast advertisement, the protocol 333 provides expedited forwarding of packets to the MN. 335 The protocol also provides the following important functionalities. 336 The access routers can exchange messages to confirm that a 337 proposed NCoA is acceptable. For instance, when a MN sends FBU 338 from PAR's link, FBack can be delivered after NAR considers NCoA 339 acceptable to use. This is especially useful when addresses are 340 assigned by the access router. The NAR can also rely on its 341 trust relationship with PAR before providing forwarding support 342 for the MN. That is, it may create a forwarding entry for NCoA 343 subject to "approval" from PAR which it trusts. In addition, 344 buffering for handover traffic may be desirable. Even though the 345 Neighbor Discovery protocol provides a small buffer (typically 346 one or two packets) for packets awaiting address resolution, this 347 buffer may be inadequate for traffic such as VoIP already in 348 progress. The routers may also wish to maintain a separate buffer 349 for servicing the handover traffic as well. Finally, the access 350 routers could transfer network-resident contexts, such as access 351 control, QoS, header compression, in conjunction with handover. 352 For all these operations, the protocol provides "Handover Initiate 353 (HI)" and "Handover Acknowledge (HAck)" messages. Both of these 354 messages SHOULD be used. The access routers MUST have necessary 355 security association established by means outside the scope of this 356 document. 358 3.2. Protocol Operation 360 The protocol begins when a MN sends RtSolPr to its access router 361 to resolve one or more Access Point Identifiers to subnet-specific 362 information. In response, the access router (e.g., PAR in 363 Figure 1) sends a PrRtAdv message which contains one or more 364 [AP-ID, AR-Info] tuples. The MN may send RtSolPr at any convenient 365 time, for instance as a response to some link-specific event (a 366 ``trigger'') or simply after performing router discovery. However, 367 the expectation is that prior to sending RtSolPr, the MN has 368 discovered the available APs by link-specific methods. The RtSolPr 369 and PrRtAdv messages do not establish any state at the access 370 router, and their packet formats are defined in Section 6.1. 372 With the information provided in the PrRtAdv message, the MN 373 formulates a prospective NCoA and sends an FBU message. The 374 purpose of FBU is to authorize PAR to bind PCoA to NCoA, so that 375 arriving packets can be tunneled to the new location of the MN. 376 The FBU should be sent from PAR's link whenever feasible. For 377 instance, an internal link-specific trigger could enable FBU 378 transmission from the previous link. 380 When it is not feasible, FBU is sent from the new link. Care must 381 be taken to ensure that NCoA used in FBU does not conflict with an 382 address already in use by some other node on link. 384 The format and semantics of FBU processing are specified in 385 Section 6.3.1. The FBU message MUST contain the BADF option (see 386 Section 6.4.5) to secure the message. 388 Depending on whether an FBack is received or not on the previous 389 link, which clearly depends on whether FBU was sent in the first 390 place, there are two modes of operation. 392 1. The MN receives FBack on the previous link. This means that 393 packet tunneling would already be in progress by the time the 394 MN handovers to NAR. The MN SHOULD send UNA immediately after 395 attaching to NAR, so that arriving as well as buffered packets 396 can be forwarded to the MN right away. 398 Before sending FBack to MN, PAR can determine whether NCoA is 399 acceptable to NAR through the exchange of HI and HAck messages. 400 When assigned addressing (i.e., addresses are assigned by the 401 router) is used, the proposed NCoA in FBU is carried in HI, and 402 NAR MAY assign the proposed NCoA. Such an assigned NCoA MUST 403 be returned in HAck, and PAR MUST in turn provide the assigned 404 NCoA in FBack. If there is an assigned NCoA returned in FBack, 405 the MN MUST use the assigned address (and not the proposed 406 address in FBU) upon attaching to NAR. 408 2. The MN does not receive FBack on the previous link. One reason 409 for this is that the MN has not sent the FBU. The other is 410 that the MN has left the link after sending the FBU, which may 411 be lost, but before receiving an FBack. Without receiving an 412 FBack in the latter case, the MN cannot ascertain whether PAR 413 has successfully processed the FBU. Hence, the MN (re)sends 414 FBU immediately after sending the UNA message. If NAR detects 415 that NCoA is in use when processing UNA, for instance while 416 creating a neighbor entry, it sends a Router Advertisement with 417 "Neighbor Advertisement Acknowledge (NAACK)" option in which 418 NAR MAY include an alternate IP address for the MN to use. 419 Detailed UNA processing rules are specified in Section 6.3.3. 421 The scenario in which a MN sends FBU and receives FBack on PAR's 422 link is illustrated in Figure 2. For convenience, this scenario 423 is called "predictive" mode of operation. The scenario in which 424 the MN sends FBU from NAR's link is illustrated in Figure 3. For 425 convenience, this scenario is called "reactive" mode of operation. 426 Note that the reactive mode also includes the case when FBU has 427 been sent from PAR's link but FBack has not been received yet. The 428 Figure is intended to illustrate that the FBU is forwarded through 429 NAR, but it is processed only by the PAR. 431 Finally, the PrRtAdv message may be sent unsolicited, i.e., 432 without the MN first sending RtSolPr. This mode is described in 433 Section 3.3. 435 3.3. Protocol Operation during Network-initiated Handover 437 In some wireless technologies, the handover control may reside 438 in the network even though the decision to undergo handover may 439 be arrived at by cooperation between the MN and the network. In 440 such networks, the PAR can send an unsolicited PrRtAdv containing 441 the link layer address, IP address and subnet prefix of the NAR 442 when the network decides that a handover is imminent. The MN MUST 443 process this PrRtAdv to configure a new care of address on the 444 new subnet, and MUST send an FBU to PAR prior to switching to the 445 new link. After transmitting PrRtAdv, the PAR MUST continue to 446 forward packets to the MN on its current link until the FBU is 447 received. The rest of the operation is the same as that described 448 in Section 3.2. 450 The unsolicited PrRtAdv also allows the network to inform the MN 451 about geographically adjacent subnets without the MN having to 452 explicitly request that information. This can reduce the amount 453 of wireless traffic required for the MN to obtain a neighborhood 454 topology map of links and subnets. Such usage of PrRtAdv is 455 decoupled from the actual handover. See Section 6.1.2. 457 MN PAR NAR 458 | | | 459 |------RtSolPr------->| | 460 |<-----PrRtAdv--------| | 461 | | | 462 |------FBU----------->|----------HI--------->| 463 | |<--------HAck---------| 464 | <--FBack---|--FBack---> | 465 | | | 466 disconnect forward | 467 | packets ===============>| 468 | | | 469 | | | 470 connect | | 471 | | | 472 |------------UNA --------------------------->| 473 |<=================================== deliver packets 474 | | 476 Figure 2: "Predictive" Fast Handover 478 MN PAR NAR 479 | | | 480 |------RtSolPr------->| | 481 |<-----PrRtAdv--------| | 482 | | | 483 disconnect | | 484 | | | 485 | | | 486 connect | | 487 |-------UNA-----------|--------------------->| 488 |-------FBU-----------|---------------------)| 489 | |<-------FBU----------)| 490 | |<------HI/HAck------->| 491 | | (if necessary) | 492 | forward | 493 | packets(including FBAck)=====>| 494 | | | 495 |<=================================== deliver packets 496 | | 498 Figure 3: "Reactive" Fast Handover 500 4. Protocol Details 502 All description makes use of Figure 1 as the reference. 504 After discovering one or more nearby access points, the MN sends 505 RtSolPr in order to resolve access point identifiers to subnet 506 router information. A convenient time to do this is after 507 performing router discovery. However, the MN can send RtSolPr at 508 any time, e.g., when one or more new access points are discovered. 509 The MN can also send RtSolPr more than once during its attachment 510 to PAR. The trigger for sending RtSolPr can originate from a 511 link-specific event, such as the promise of a better signal 512 strength from another access point coupled with fading signal 513 quality with the current access point. Such events, often broadly 514 referred to as "L2 triggers", are outside the scope of this 515 document. Nevertheless, they serve as events that invoke this 516 protocol. For instance, when a "link up" indication is obtained 517 on the new link, protocol messages (e.g., UNA) can be immediately 518 transmitted. Implementations SHOULD make use of such triggers 519 whenever available. 521 The RtSolPr message contains one or more AP-IDs. A wildcard 522 requests all available tuples. 524 As a response to RtSolPr, PAR sends a PrRtAdv message which 525 indicates one of the following possible conditions. 527 1. If the PAR does not have an entry corresponding to the new 528 access point, it responds indicating that the new access point 529 is unknown. The MN MUST stop fast handover protocol operations 530 on the current link. The MN MAY send an FBU from its new link. 532 2. If the new access point is connected to the PAR's current 533 interface (to which MN is attached), PAR responds with a Code 534 value indicating that the new access point is connected to the 535 current interface, but not send any prefix information. This 536 scenario could arise, for example, when several wireless access 537 points are bridged into a wired network. No further protocol 538 action is necessary. 540 3. If the new access point is known and the PAR has information 541 about it, then PAR responds indicating that the new access 542 point is known and supply the [AP-ID, AR-Info] tuple. If the 543 new access point is known, but does not support fast handover, 544 the PAR MUST indicate this with Code 3 (See Section 6.1.2). 546 4. If a wildcard is supplied as an identifier for the new access 547 point, the PAR SHOULD supply neighborhood [AP-ID, AR-Info] 548 tuples subject to path MTU restrictions (i.e., provide any 'n' 549 tuples without exceeding the link MTU). 551 When further protocol action is necessary, some implementations may 552 choose to provide buffering support at PAR to address the scenario 553 in which a MN leaves without sending an FBU message from the PAR's 554 link. While the protocol does not forbid such an implementation 555 support, care must be taken to ensure that the PAR continues 556 forwaring packets to the PCoA (i.e., uses a buffer and forward 557 approach). The PAR should also stop buffering once it processes 558 the FBU message. 560 The method by which Access Routers exchange information about 561 their neighbors and thereby allow construction of Proxy Router 562 Advertisements with information about neighboring subnets is 563 outside the scope of this document. 565 The RtSolPr and PrRtAdv messages MUST be implemented by a MN and 566 an access router that supports fast handovers. However, when 567 the parameters necessary for the MN to send packets immediately 568 upon attaching to the NAR are supplied by the link layer handover 569 mechanism itself, use of above messages is optional on such links. 571 After a PrRtAdv message is processed, the MN sends FBU and includes 572 the proposed NCoA. The MN SHOULD send FBU from PAR's link whenever 573 "anticipation" of handover is feasible. When anticipation is not 574 feasible or when it has not received an FBack, the MN sends FBU 575 immediately after attaching to NAR's link. In response to FBU, PAR 576 establishes a binding between PCoA ("Home Address") and NCoA, and 577 sends FBack to MN. Prior to establishing this binding, PAR SHOULD 578 send a HI message to NAR, and receive HAck in response. In order 579 to determine the NAR's address for the HI message, the PAR can 580 perform longest prefix match of NCoA (in FBU) with the prefix list 581 of neighboring access routers. When the source IP address of FBU 582 is PCoA, i.e., the FBU is sent from the PAR's link, the HI message 583 MUST have a Code value set to 0. See Section 6.2.1. When the 584 source IP address of FBU is not PCoA, i.e., the FBU is sent from 585 the NAR's link, the HI message MUST have a Code value of 1. See 586 Section 6.2.1. 588 The HI message contains the PCoA, link-layer address and the NCoA 589 of the MN. In response to processing a HI message with Code 0, the 590 NAR 592 1. determines whether NCoA supplied in the HI message is a valid 593 address for use, and if it is, starts proxying [8] the address 594 for PROXY|ND|LIFETIME during which the MN is expected to 595 connect to NAR. In case there is already an NCoA present, NAR 596 may verify if the LLA is the same as its own or that of the MN 597 itself. If so, NAR may allow the use of NCoA. 599 2. allocates NCoA for the MN when assigned addressing is used, 600 creates a proxy neighbor cache entry and begins defending it. 601 The NAR MAY allocate the NCoA proposed in HI. 603 3. MAY create a host route entry for PCoA (on the interface to 604 which the MN is attaching to) in case NCoA cannot be accepted 605 or assigned. This host route entry SHOULD be implemented 606 such that until the MN's presence is detected, either through 607 explicit announcement by the MN or by other means, arriving 608 packets do not invoke neighbor discovery. The NAR SHOULD also 609 set up a reverse tunnel to PAR in this case. 611 4. provides the status of handover request in Handover Acknowledge 612 (HAck) message. 614 When the Code value in HI is 1, NAR MUST skip the above operations. 615 However, it SHOULD be prepared to process any other options which 616 may be defined in the future. Sending a HI message with Code 617 1 allows NAR to validate the neighbor cache entry it creates 618 for the MN during UNA processing. That is, NAR can make use 619 of the knowledge that its trusted peer (i.e., PAR) has a trust 620 relationship with the MN. 622 If HAck contains an assigned NCoA, it must be included in FBack, 623 and the MN must use it. The PAR MAY send FBack to the previous 624 link as well to facilitate faster reception in the event the MN 625 be still present there. The result of FBU and FBack processing 626 is that PAR begins tunneling MN's packets to NCoA. If the MN does 627 not receive an FBack message even after re-transmitting FBU for 628 FBU|RETRIES, it must assume that fast handover support is not 629 available and stop the protocol operation. 631 As soon as the MN establishes link connectivity with the NAR, it 633 1. sends a UNA message (see 6.3.3). If the MN has not received 634 an FBack by the time UNA is being sent, it SHOULD send an FBU 635 message following the UNA message. 637 2. joins the all-nodes multicast group and the solicited-node 638 multicast group corresponding to the NCoA 640 3. starts a DAD probe for NCoA. See [9]. 642 When a NAR receives a UNA message, it 644 1. SHOULD create a neighbor cache entry for NCoA if none exists 645 and set it to STALE. This allows it to forward any arriving 646 packets while it probes bidirectional reachability. 648 2. updates an entry in INCOMPLETE state, if it exists, to STALE 649 and forwards arriving and buffered packets. This would be the 650 case if NAR had previously sent a Neighbor Solicitation which 651 went unanswered perhaps because the MN had not yet attached to 652 the link. 654 3. deletes its proxy neighbor cache entry, if any, updates the 655 state to STALE, and forwards arriving and buffered packets. 657 The buffer for handover traffic should be linked to this UNA 658 processing. The exact mechanism is implementation dependent. 660 The NAR may detect that NCoA is in use by another node when 661 processing the UNA message, in which case it 663 1. MUST NOT update the existing entry. 665 2. MUST send a Router Advertisement with the NAACK option in which 666 it MAY include an alternate NCoA for use. This message MUST 667 be sent to the source IP address present in UNA using the same 668 Layer 2 address present in UNA. 670 If the MN receives an IP address in the NAACK option, it MUST 671 use it and send an FBU using the new CoA. As a special case, the 672 address supplied in NAACK could be PCoA itself, in which case the 673 MN MUST NOT send any more FBUs. The Status codes for NAACK option 674 are specified in Section 6.4.6. 676 Once the MN has confirmed its NCoA (either through DAD or when 677 provided for by the NAR), it SHOULD send a Neighbor Advertisement 678 message with the 'O' bit set, to the all-nodes multicast address. 679 This message allows MN's neighbors to update their neighbor cache 680 entries. 682 For data forwarding, the PAR tunnels packets using its global IP 683 address valid on the interface to which the MN was attached. The 684 MN reverse tunnels its packets to the same global address of PAR. 685 The tunnel end-point addresses must be configured accordingly. 686 When PAR receives a reverse tunneled packet, it must verify if a 687 secure binding exists for the MN identified by PCoA in the tunneled 688 packet, before forwarding the packet. 690 5. Other Considerations 692 5.1. Handover Capability Exchange 694 The MN expects a PrRtAdv in response to its RtSolPr message. 695 If the MN does not receive a PrRtAdv message even after 696 RTSOLPR|RETRIES, it must assume that PAR does not support the fast 697 handover protocol and stop sending any more RtSolPr messages. 699 Even if a MN's current access router is capable of providing 700 fast handover support, the new access router may not be capable 701 of providing such support. This is indicated to the MN during 702 "runtime", through the PrRtAdv message with a Code value of 3 (see 703 Section 6.1.2). 705 5.2. Determining New Care of Address 707 Typically, the MN formulates its prospective NCoA using the 708 information provided in a PrRtAdv message, and sends FBU. This 709 NCoA can be provided to NAR in the HI message. NAR provides a 710 disposition of HI, and hence the NCoA itself, in the HAck message 711 indicating whether NCoA is acceptable. However, the MN itself does 712 not have to wait on PAR's link for this exchange to take place. It 713 can handover any time after sending the FBU message; sometimes it 714 may be forced to handover without sending the FBU. In any case, it 715 can still confirm using NCoA from NAR's link by sending the UNA 716 message. 718 If PrRtAdv message carries a NCoA, the MN MUST use it as its 719 prospective NCoA. 721 5.3. Prefix Management 723 As defined in Section 2, the Prefix part of ``AR-Info'' is the 724 prefix valid on the interface to which the AP is attached. This 725 document does not specify how this Prefix is managed, it's length 726 and assignment policies. The protocol operation specified in this 727 document works regardless of these considerations. Often, but not 728 necessarily always, this Prefix may be the aggregate prefix (such 729 as /48) valid on the interface. In some deployments, each MN may 730 have its own per-mobile prefix (such as a /64) used for generating 731 the NCoA. Some point-to-point links may use such a deployment. 733 When per-mobile prefix assignment is used, the ``AR-Info'' 734 advertised in PrRtAdv still includes the (aggregate) prefix valid 735 on the interface to which the target AP is attached, unless the 736 access routers communicate with each other (using HI and HAck 737 messages) to manage per-mobile prefix. The MN still formulates an 738 NCoA using the aggregate prefix. However, an alternate NCoA based 739 on the per-mobile prefix is returned by NAR in the HAck message. 740 This alternate NCoA is provided to the MN in either the FBack 741 message or in the NAACK option. 743 5.4. Packet Loss 745 Handover involves link switching, which may not be exactly 746 co-ordinated with fast handover signaling. Furthermore, the 747 arrival pattern of packets is dependent on many factors, including 748 application characteristics, network queuing behaviors etc. Hence, 749 packets may arrive at NAR before the MN is able to establish its 750 link there. These packets will be lost unless they are buffered 751 by the NAR. Similarly, if the MN attaches to NAR and then sends an 752 FBU message, packets arriving at PAR until FBU is processed will be 753 lost unless they are buffered. This protocol provides an option to 754 indicate request for buffering at the NAR in the HI message. When 755 the PAR requests this feature (for the MN), it SHOULD also provide 756 its own support for buffering. 758 5.5. DAD Handling 760 Duplicate Address Detection (DAD) was defined in [9] to 761 avoid address duplication on links when stateless address 762 auto-configuration is used. The use of DAD to verify the 763 uniqueness of an IPv6 address configured through stateless 764 auto-configuration adds delays to a handover. 766 The probability of an interface identifier duplication on the 767 same subnet is very low, however it cannot be ignored. In this 768 draft certain precautions are proposed to minimize the effects of 769 a duplicate address occurrence as well as recovery actions in the 770 event of a collision. 772 In some cases the NAR may already have the knowledge required to 773 assess whether the MN's address is a duplicate or not before the 774 MN moves to the new subnet. For example, the NAR can have a list 775 of all nodes on its subnet for access control, and by searching 776 this list, it can confirm whether the MN's address is a duplicate 777 or not. In some other deployments, the NAR may maintain a pool 778 of duplicate-free addresses in a list for handover purposes. The 779 result of NCoA disposition is sent back to the PAR in the HAck 780 message. The NAR can also indicate this in the NAACK option as 781 a response to the UNA message. When there is a duplicate, NAR 782 can propose (in NAACK option) an alternative NCoA or support the 783 PCoA using the host route forwarding. When no such support is 784 available, the MN would have to follow the address configuration 785 procedure according to [9] after attaching to the NAR. 787 In deployments where NAR does not have means to assess and inform 788 the uniqueness of NCoA or cannot provide a duplicate-free address 789 using HI and HAck exchange, the following scenarios are possible, 790 although highly improbable considering that the probability of a 791 random address collision is very small. 793 1. The MN sends FBU from the previous link which results in 794 packet forwarding to NCoA. These packets may arrive before 795 the MN attaches to NAR, and hence the latter may invoke 796 Neighbor Discovery. In the event that there is another node 797 which already owns the NCoA, NAR (incorrectly) forwards those 798 packets to such a node. When the MN arrives on the link, it 799 immediately sends a UNA message, which allows NAR to detect 800 a collision. NAR immediately sends a Router Advertisement 801 with NAACK option, forcing the MN to either use another NCoA 802 supplied in NAACK or reconfigure a new one. The MN must send 803 an FBU immediately following the NCoA configuration. As a 804 special case, the NCoA may be that of NAR itself, which allows 805 the MN to send FBU that binds its PCoA to NAR's address. This 806 recovers from temporary misdelivery of packets. Where this 807 is a concern, the deployments SHOULD use HI and HAck exchange 808 which mitigates the problem by allowing NAR to proxy the NCoA; 809 such a proxying itself can detect a collision if an entry 810 already exists in the neighbor cache entry. 812 2. The MN sends a UNA message followed by an FBU from the new 813 link. When NAR processes the UNA message, either there is 814 already an entry for NCoA or there is no entry. If there is an 815 entry, it either belongs to the MN itself (e.g., in INCOMPLETE 816 state) or the entry belongs to another node. These entries 817 can be distinguished by the LLA; the entry with INCOMPLETE 818 state has no LLA. If the entry belongs to another node, NAR 819 immediately sends a Router Advertisement with NAACK option (as 820 above) and the MN MUST immediately send a new FBU to PAR with a 821 different NCoA. Hence, extent of any misdelivery is minimized. 823 If there is no existing entry for NCoA but there is another 824 node which owns NCoA, the scenario is more complicated. 825 According to [8], the UNA message does not create any entry 826 if there is none to begin with. However, NAR performs 827 Neighbor Solicitation when packets arrive from PAR (due to 828 FBU processing). Both the MN and the rightful owner respond 829 with Neighbor Advertisement (NA), but the MN's Neighbor 830 Advertisement will have the 'O' bit cleared. If the MN's NA 831 arrives first, NAR starts forwarding to it, but redirects those 832 packets once the NA from the rightful owner is processed. At 833 the time of updating the neighbor cache entry, the NAR must 834 send a Router Advertisement with NAACK option to the MN (as 835 above), and the MN MUST immediately send a new FBU to the PAR. 836 If the MN's NA arrives after the NA from the rightful owner, 837 NAR similarly sends a Router Advertisement with NAACK option, 838 and the MN sends a new FBU to the PAR. In both the cases, 839 the extent of misdelivery can be controlled and recovery is 840 possible. 842 The scenario where NAR has no entry for NCoA at all when 843 packets arrive is possible even when using HI and HAck 844 messages. The available options in this case appear to be a) 845 performing DAD for a set of addresses beforehand for handover 846 purposes, and b) maintaining a table of IP addresses of all 847 nodes on the link (similar to Mobile IPv4 visitor list). The 848 NAR can then provide a conflict-free address in the HAck 849 message or the NAACK option. 851 5.6. Fast or Erroneous Movement 853 Although this specification is for fast handover, the protocol has 854 its limits in terms of how fast a MN can move. A special case 855 of fast movement is ping-pong, where a MN moves between the same 856 two access points rapidly. Another instance of the same problem 857 is erroneous movement i.e., the MN receives information prior to 858 a handover that it is moving to a new access point but it either 859 moves to a different one or aborts movement altogether. All of the 860 above behaviors are usually the result of link layer idiosyncrasies 861 and thus are often tackled at the link layer itself. 863 IP layer mobility, however, introduces its own limits. IP layer 864 handovers should occur at a rate suitable for the MN to update the 865 binding of, at least, its Home Agent and preferably that of every 866 CN with which it is in communication. A MN that moves faster than 867 necessary for this signaling to complete, which may be of the order 868 of few seconds, may start losing packets. The signaling overhead 869 over the air and in the network may increase significantly, 870 especially in the case of rapid movement between several access 871 routers. To avoid the signaling overhead, the following measures 872 are suggested. 874 A MN returning to the PAR before updating the necessary bindings 875 when present on NAR MUST send a Fast Binding Update with Home 876 Address equal to the MN's PCoA and a lifetime of zero, to the PAR. 877 The MN should have a security association with the PAR since it 878 performed a fast handover to the NAR. The PAR, on receiving this 879 Fast Binding Update, will check its set of outgoing (temporary 880 fast handover) tunnels. If it finds a match it SHOULD terminate 881 that tunnel; i.e., start delivering packets directly to the node 882 instead. 884 Temporary tunnels for the purposes of fast handovers should use 885 short lifetimes (of the order of a small number of seconds or 886 less). The lifetime of such tunnels should be enough to allow a 887 MN to update all its active bindings. The default lifetime of the 888 tunnel should be the same as the lifetime value in the FBU message. 890 The effect of erroneous movement is typically limited to loss of 891 packets since routing can change and the PAR may forward packets 892 towards another router before the MN actually connects to that 893 router. If the MN discovers itself on an unanticipated access 894 router, it SHOULD send a new Fast Binding Update to the PAR. This 895 FBU supercedes the existing binding at PAR and the packets will be 896 redirected to the new confirmed location of the MN. 898 6. Message Formats 900 All the ICMPv6 messages have a common Type specified in [4]. The 901 messages are distinguished based on the Subtype field (see below). 902 The values for the Subtypes are specified in Section 9. For all 903 the ICMPv6 messages, the checksum is defined in [2]. 905 6.1. New Neighborhood Discovery Messages 907 6.1.1. Router Solicitation for Proxy Advertisement (RtSolPr) 909 Mobile Nodes send Router Solicitation for Proxy Advertisement in 910 order to prompt routers for Proxy Router Advertisements. All the 911 link-layer address options have the format defined in 6.4.3. 913 0 1 2 3 914 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 915 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 916 | Type | Code | Checksum | 917 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 918 | Subtype | Reserved | Identifier | 919 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 920 | Options ... 921 +-+-+-+-+-+-+-+-+-+-+-+- 923 Figure 4: Router Solicitation for Proxy 924 Advertisement (RtSolPr) Message 926 IP Fields: 928 Source Address 929 An IP address assigned to the sending interface 931 Destination Address 932 The address of the Access Router or the all routers 933 multicast address. 935 Hop Limit 255. See RFC 2461. 937 ICMP Fields: 939 Type The Experimental Mobility Protocol Type. See [4]. 941 Code 0 942 Checksum The ICMPv6 checksum. 944 Subtype 2 946 Reserved MUST be set to zero by the sender and ignored by 947 the receiver. 949 Identifier MUST be set by the sender so that replies can be 950 matched to this Solicitation. 952 Valid Options: 954 Source Link-layer Address 955 When known, the link-layer address of the sender 956 SHOULD be included using the Link-Layer Address 957 option. See LLA option format below. 959 New Access Point Link-layer Address 960 The link-layer address or identification of the 961 access point for which the MN requests routing 962 advertisement information. It MUST be included 963 in all RtSolPr messages. More than one such address 964 or identifier can be present. This field can also 965 be a wildcard address. See LLA Option below. 967 Future versions of this protocol may define new option types. 968 Receivers MUST silently ignore any options that they do not 969 recognize and continue processing the rest of the message. 971 Including the source LLA option allows the receiver to record the 972 sender's L2 address so that neighbor discovery, when the receiver 973 needs to send packets back to the sender (of RtSolPr message), can 974 be avoided. 976 When a wildcard is used for New Access Point LLA, no other New 977 Access Point LLA options must be present. 979 A Proxy Router Advertisement (PrRtAdv) message should be received 980 by the MN as a response to RtSolPr. If such a message is not 981 received in a short time period but no less than twice the typical 982 round trip time (RTT) over the access link or 100 milliseconds if 983 RTT is not known, it SHOULD resend RtSolPr message. Subsequent 984 retransmissions can be up to RTSOLPR|RETRIES, but MUST use an 985 exponential backoff in which the timeout period (i.e., 2xRTT or 100 986 milliseconds) is doubled prior to each instance of retransmission. 987 If Proxy Router Advertisement is not received by the time the MN 988 disconnects from the PAR, the MN SHOULD send FBU immediately after 989 configuring a new CoA. 991 When RtSolPr messages are sent more than once, they MUST be rate 992 limited with MAX|RTSOLPR|RATE per second. During each use of 993 RtSolPr, exponential backoff is used for retransmissions. 995 6.1.2. Proxy Router Advertisement (PrRtAdv) 997 Access routers send out Proxy Router Advertisement message 998 gratuitously if the handover is network-initiated or as a response 999 to RtSolPr message from a MN, providing the link-layer address, 1000 IP address and subnet prefixes of neighboring routers. All the 1001 link-layer address options have the format defined in 6.4.3. 1003 0 1 2 3 1004 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 1005 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1006 | Type | Code | Checksum | 1007 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1008 | Subtype | Reserved | Identifier | 1009 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1010 | Options ... 1011 +-+-+-+-+-+-+-+-+-+-+-+- 1013 Figure 5: Proxy Router Advertisement (PrRtAdv) Message 1015 IP Fields: 1017 Source Address 1018 MUST be the link-local address assigned to the 1019 interface from which this message is sent. 1021 Destination Address 1022 The Source Address of an invoking Router 1023 Solicitation for Proxy Advertisement or the address 1024 of the node the Access Router is instructing to 1025 handover. 1027 Hop Limit 255. See RFC 2461. 1029 ICMP Fields: 1031 Type The Experimental Mobility Protocol Type. See [4]. 1033 Code 0, 1, 2, 3 or 4. See below. 1035 Checksum The ICMPv6 checksum. 1037 Subtype 3 1039 Reserved MUST be set to zero by the sender and ignored by 1040 the receiver. 1042 Identifier Copied from Router Solicitation for Proxy 1043 Advertisement or set to Zero if unsolicited. 1045 Valid Options in the following order: 1047 Source Link-layer Address 1048 When known, the link-layer address of the sender 1049 SHOULD be included using the Link-Layer Address 1050 option. See LLA option format below. 1052 New Access Point Link-layer Address 1053 The link-layer address or identification of the 1054 access point is copied from RtSolPr 1055 message. This option MUST be present. 1057 New Router's Link-layer Address 1058 The link-layer address of the Access Router for 1059 which this message is proxied for. This option MUST be 1060 included when Code is 0 or 1. 1062 New Router's IP Address 1063 The IP address of NAR. This option MUST be 1064 included when Code is 0 or 1. 1066 New Router Prefix Information Option. 1067 Specifies the prefix of the Access 1068 Router the message is proxied for and is used 1069 for address auto-configuration. This option MUST be 1070 included when Code is 0 or 1. However, when this 1071 prefix is the same as what is used in the New 1072 Router's IP Address option (above), the Prefix 1073 Information option need not be present. 1075 New CoA Option 1076 MAY be present when PrRtAdv is sent 1077 unsolicited. PAR MAY compute new CoA using NAR's 1078 prefix information and the MN's L2 address, or by 1079 any other means. 1081 Future versions of this protocol may define new option types. 1082 Receivers MUST silently ignore any options they do not recognize 1083 and continue processing the message. 1085 Currently, Code values 0, 1, 2, 3 and 4 are defined. 1087 A Proxy Router Advertisement with Code 0 means that the MN should 1088 use the [AP-ID, AR-Info] tuple (present in the options above) for 1089 movement detection and NCoA formulation. The Option-Code field 1090 in the New Access Point LLA option in this case is 1 reflecting 1091 the LLA of the access point for which the rest of the options are 1092 related. Multiple tuples may be present. 1094 A Proxy Router Advertisement with Code 1 means that the message is 1095 sent unsolicited. If a New CoA option is present following the New 1096 Router Prefix Information option, the MN SHOULD use the supplied 1097 NCoA and send FBU immediately or else stand to lose service. 1098 This message acts as a network-initiated handover trigger. See 1099 Section 3.3. The Option-Code field in the New Access Point LLA 1100 option (see below) in this case is 1 reflecting the LLA of the 1101 access point for which the rest of the options are related. 1103 A Proxy Router Advertisement with Code 2 means that no new router 1104 information is present. Each New Access Point LLA option contains 1105 an Option-Code value (described below) which indicates a specific 1106 outcome. 1108 - When the Option-Code field in the New Access Point LLA option 1109 is 5, handover to that access point does not require change of 1110 CoA. No other options are required in this case. 1112 - When the Option-Code field in the New Access Point LLA option 1113 is 6, PAR is not aware of the Prefix Information requested. 1114 The MN SHOULD attempt to send FBU as soon as it regains 1115 connectivity with the NAR. No other options are required in 1116 this case. 1118 - When the Option-Code field in the New Access Point LLA option 1119 is 7, it means that the NAR does not support fast handover. 1120 The MN MUST stop fast handover protocol operations. No other 1121 options are required in this case. 1123 A Proxy Router Advertisement with Code 3 means that new router 1124 information is present only for a subset of access points 1125 requested. The Option-Code field values (defined above including 1126 a value of 1) distinguish different outcomes for individual access 1127 points. 1129 A Proxy Router Advertisement with Code 4 means that the 1130 subnet information regarding neighboring access points is sent 1131 unsolicited, but the message is not a handover trigger, unlike when 1132 the message is sent with Code 1. Multiple tuples may be present. 1134 When a wildcard AP identifier is supplied in the RtSolPr 1135 message, the PrRtAdv message should include any 'n' [Access Point 1136 Identifier, Link-layer address option, Prefix Information Option] 1137 tuples corresponding to the PAR's neighborhood. 1139 6.2. Inter-Access Router Messages 1141 6.2.1. Handover Initiate (HI) 1143 The Handover Initiate (HI) is an ICMPv6 message sent by an Access 1144 Router (typically PAR) to another Access Router (typically NAR) to 1145 initiate the process of a MN's handover. 1147 0 1 2 3 1148 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 1149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1150 | Type | Code | Checksum | 1151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1152 | Subtype |S|U| Reserved | Identifier | 1153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1154 | Options ... 1155 +-+-+-+-+-+-+-+-+-+-+-+- 1157 Figure 6: Handover Initiate (HI) Message 1159 IP Fields: 1161 Source Address 1162 The IP address of the PAR 1164 Destination Address 1165 The IP address of the NAR 1167 Hop Limit 255. See RFC 2461. 1169 ICMP Fields: 1171 Type The Experimental Mobility Protocol Type. See [4]. 1173 Code 0 or 1. See below 1175 Checksum The ICMPv6 checksum. 1177 Subtype 4 1179 S Assigned address configuration flag. When set, this 1180 message requests a new CoA to be returned by the 1181 destination. May be set when Code = 0. MUST be 0 1182 when Code = 1. 1184 U Buffer flag. When set, the destination SHOULD buffer 1185 any packets towards the node indicated in the options 1186 of this message. Used when Code = 0, SHOULD be set 1187 to 0 when Code = 1. 1189 Reserved MUST be set to zero by the sender and ignored by 1190 the receiver. 1192 Identifier MUST be set by the sender so replies can be matched 1193 to this message. 1195 Valid Options: 1197 Link-layer address of MN 1198 The link-layer address of the MN that is 1199 undergoing handover to the destination (i.e., NAR). 1200 This option MUST be included so that the destination 1201 can recognize the MN. 1203 Previous Care of Address 1204 The IP address used by the MN while 1205 attached to the originating router. This option 1206 SHOULD be included so that host route can be 1207 established in case necessary. 1209 New Care of Address 1210 The IP address the MN wishes to use when 1211 connected to the destination. When the `S' bit is 1212 set, NAR MAY assign this address. 1214 The PAR uses a Code value of 0 when it processes an FBU with PCoA 1215 as source IP address. The PAR uses a Code value of 1 when it 1216 processes an FBU whose source IP address is not PCoA. 1218 If Handover Acknowledge (HAck) message is not received as a 1219 response in a short time period but no less than twice the typical 1220 round trip time (RTT) between source and destination, or 100 1221 milliseconds if RTT is not known, the Handover Initiate SHOULD be 1222 re-sent. Subsequent retransmissions can be up to HI|RETRIES, but 1223 MUST use exponential backoff in which the timeout period (i.e., 1224 2xRTT or 100 milliseconds) is doubled during each instance of 1225 retransmission. 1227 6.2.2. Handover Acknowledge (HAck) 1229 The Handover Acknowledgment message is a new ICMPv6 message that 1230 MUST be sent (typically by NAR to PAR) as a reply to the Handover 1231 Initiate message. 1233 0 1 2 3 1234 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 1235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1236 | Type | Code | Checksum | 1237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1238 | Subtype | Reserved | Identifier | 1239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1240 | Options ... 1241 +-+-+-+-+-+-+-+-+-+-+-+- 1243 Figure 7: Handover Acknowledge (HAck) Message 1245 IP Fields: 1247 Source Address 1248 Copied from the destination address of the Handover 1249 Initiate Message to which this message is a 1250 response. 1252 Destination Address 1253 Copied from the source address of the Handover 1254 Initiate Message to which this message is a 1255 response. 1257 Hop Limit 255. See RFC 2461. 1259 ICMP Fields: 1261 Type The Experimental Mobility Protocol Type. See [4]. 1263 Code 1264 0: Handover Accepted, NCoA valid 1265 1: Handover Accepted, NCoA not valid 1266 2: Handover Accepted, NCoA in use 1267 3: Handover Accepted, NCoA assigned 1268 (used in Assigned addressing) 1269 4: Handover Accepted, NCoA not assigned 1270 (used in Assigned addressing) 1271 5: Handover Accepted, use PCoA 1272 6: Message sent unsolicited, usually to trigger a 1273 HI message 1274 128: Handover Not Accepted, reason unspecified 1275 129: Administratively prohibited 1276 130: Insufficient resources 1278 Checksum The ICMPv6 checksum. 1280 Subtype 5 1282 Reserved MUST be set to zero by the sender and ignored by 1283 the receiver. 1285 Identifier Copied from the corresponding field in the Handover 1286 Initiate message this message is in response to. 1288 Valid Options: 1290 New Care of Address 1291 If the S flag in the Handover Initiate message is set, 1292 this option MUST be used to provide NCoA the MN should 1293 use when connected to this router. This option MAY be 1294 included even when `S' bit is not set, e.g., Code 2 1295 above. 1297 Upon receiving a HI message, the NAR MUST respond with a Handover 1298 Acknowledge message. If the `S' flag is set in the HI message, the 1299 NAR SHOULD include the New Care of Address option and a Code 3. 1301 The NAR MAY provide support for PCoA (instead of accepting or 1302 assigning NCoA), using a host route entry to forward packets to 1303 the PCoA, and using a tunnel to the PAR to forward packets from 1304 the MN (sent with PCoA as source IP address). This host route 1305 entry SHOULD be used to forward packets once the NAR detects that 1306 the particular MN is attached to its link. The NAR indicates 1307 forwarding support for PCoA using Code value 5 in the HAck message. 1308 Subsequently, PAR establishes a tunnel to NAR in order to forward 1309 packets arriving for PCoA. 1311 When responding to a HI message containing a Code value 1, the Code 1312 values 1, 2, and 4 in the HAck message are not relevant. 1314 Finally, the new access router can always refuse handover, in which 1315 case it should indicate the reason in one of the available Code 1316 values. 1318 6.3. New Mobility Header Messages 1320 Mobile IPv6 uses a new IPv6 header type called Mobility Header [3]. 1321 The Fast Binding Update, Fast Binding Acknowledgment and Fast 1322 Neighbor Advertisement messages use the Mobility Header. 1324 6.3.1. Fast Binding Update (FBU) 1326 The Fast Binding Update message is identical to the Mobile IPv6 1327 Binding Update (BU) message. However, the processing rules are 1328 slightly different. 1330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1331 | Sequence # | 1332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1333 |A|H|L|K| Reserved | Lifetime | 1334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1335 | | 1336 . . 1337 . Mobility options . 1338 . . 1339 | | 1340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1342 Figure 8: Fast Binding Update (FBU) Message 1344 IP fields: 1346 Source address The PCoA or NCoA 1348 Destination Address 1349 The IP address of the Previous Access 1350 Router 1352 `A' flag MUST be set to one to request PAR to send a Fast 1353 Binding Acknowledgment message. 1355 `H' flag MUST be set to one. See [3]. 1357 `L' flag See [3]. 1359 `K' flag See [3]. 1361 Reserved This field is unused. MUST be set zero. 1363 Sequence Number See [3]. 1365 Lifetime The requested time in seconds for which the 1366 sender wishes to have a binding. 1368 Mobility Options 1369 MUST contain alternate CoA option set to NCoA 1370 IP address when FBU is sent from PAR's link. 1371 MUST contain the Binding Authorization Data for 1372 FMIP (BADF) option. See 6.4.5. MAY contain the 1373 Mobility Header LLA option (see Section 6.4.4). 1375 The MN sends FBU message any time after receiving a PrRtAdv 1376 message. If the MN moves prior to receiving a PrRtAdv message, 1377 it SHOULD send a FBU to the PAR after configuring NCoA on the NAR 1378 according to Neighbor Discovery and IPv6 Address Configuration 1379 protocols. 1381 The source IP address is PCoA when FBU is sent from PAR's link, and 1382 the source IP address is NCoA when sent from NAR's link. 1384 The FBU MUST also include the Home Address Option and the Home 1385 Address is PCoA. A FBU message MUST be protected so that PAR is 1386 able to determine that the FBU message is sent by a genuine MN. 1388 6.3.2. Fast Binding Acknowledgment (FBack) 1390 The Fast Binding Acknowledgment message is sent by the PAR to 1391 acknowledge receipt of a Fast Binding Update message in which 1392 the `A' bit is set. If PAR sends a HI message to the NAR after 1393 processing an FBU, the FBack message SHOULD NOT be sent to the MN 1394 before the PAR receives a HAck message from the NAR. The PAR MAY 1395 send the FBack immediately in the reactive mode however. The Fast 1396 Binding Acknowledgment MAY also be sent to the MN on the old link. 1398 IP fields: 1400 Source address The IP address of the Previous Access 1401 Router 1403 Destination Address The NCoA 1405 Status 1406 8-bit unsigned integer indicating the 1407 disposition of the Fast Binding Update. 1408 Values of the Status field less than 128 1409 indicate that the Binding Update was accepted 1410 by the receiving node. The following such 1411 Status values are currently defined: 1413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1414 | Status |K| Reserved | 1415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1416 | Sequence # | Lifetime | 1417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1418 | | 1419 . . 1420 . Mobility options . 1421 . . 1422 | | 1423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1425 Figure 9: Fast Binding Acknowledgment (FBack) Message 1427 0 Fast Binding Update accepted 1428 1 Fast Binding Update accepted but NCoA is 1429 invalid. Use NCoA supplied in ``alternate'' 1430 CoA 1432 Values of the Status field greater than or 1433 equal to 128 indicate that the Binding Update 1434 was rejected by the receiving node. The 1435 following such Status values are currently 1436 defined: 1438 128 Reason unspecified 1439 129 Administratively prohibited 1440 130 Insufficient resources 1441 131 Incorrect interface identifier length 1443 `K' flag See [3]. 1445 Reserved An unused field. MUST be set to zero. 1447 Sequence Number Copied from FBU message for use by the MN 1448 in matching this acknowledgment with an 1449 outstanding FBU. 1451 Lifetime 1452 The granted lifetime in seconds for which the 1453 sender of this message will retain a binding 1454 for traffic redirection. 1456 Mobility Options MUST contain ``alternate'' CoA if Status is 1. 1457 MUST contain the Binding Authorization Data 1458 for FMIP (BADF) option. See 6.4.5. 1460 6.3.3. Unsolicited Neighbor Advertisement (UNA) 1462 This is the same message as in [8] with the requirement that the 1463 'O' bit is always set to zero. Since this is an unsolicited 1464 message, the 'S' bit is zero, and since this is sent by a MN, the 1465 'R' bit is also zero. 1467 The Source Address must be the NCoA. The Destination Address 1468 is typically the all-nodes multicast address; however, some 1469 deployments may not prefer transmission to a multicast address. In 1470 such cases, the Destination Address SHOULD be the NAR's IP address. 1472 The Target Address must include the NCoA, and Target link-layer 1473 address must include the MN's LLA. 1475 The MN sends a UNA message to the NAR, as soon as it regains 1476 connectivity on the new link. Arriving or buffered packets can 1477 be immediately forwarded. If NAR is proxying NCoA, it creates 1478 a neighbor cache entry in STALE state but forwards packets as 1479 it determines bidirectional reachability. If there is an entry 1480 in INCOMPLETE state without a link-layer address, it sets it to 1481 STALE. If there is no entry at all, creating an entry in STALE 1482 state is recommended since forwarding can immediately begin when 1483 packets arrive without first invoking Neighbor Solicitation and 1484 Advertisement (which may involve retransmission delay in the event 1485 of messages being lost). During the process of creating a neighbor 1486 cache entry, NAR can also detect if NCoA is in use, and immediately 1487 sends a Router Advertisement with NAACK option in the event of 1488 collision (see Section 5.5 for more details). 1490 The combination of NCoA (present in source IP address) and the 1491 Link-Layer Address (present as a Target LLA) SHOULD be used to 1492 distinguish the MN from other nodes. 1494 6.4. New Options 1496 All the options are of the form shown in Figure 10. 1498 The Type values are defined from the Neighbor Discovery options 1499 space. The Length field is in units of 8 octets, except for the 1500 Mobility Header Link-Layer Address option, whose Length field is 1501 in units of octets in accordance with [3], Section 6.2. And, 1502 Option-Code provides additional information for each of the options 1503 (See individual options below). 1505 0 1 2 3 1506 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 1507 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1508 | Type | Length | Option-Code | | 1509 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1510 ~ ... ~ 1511 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1513 Figure 10: Option Format 1515 6.4.1. IP Address Option 1517 This option is sent in the Proxy Router Advertisement, the Handover 1518 Initiate, and Handover Acknowledge messages. 1520 0 1 2 3 1521 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 1522 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1523 | Type | Length | Option-Code | Prefix Length | 1524 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1525 | Reserved | 1526 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1527 | | 1528 + + 1529 | | 1530 + IPv6 Address + 1531 | | 1532 + + 1533 | | 1534 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1536 Figure 11: IPv6 Address Option 1538 Type 1539 To be assigned by IANA 1541 Length 1542 The size of this option in 8 octets including the Type, 1543 Option-Code and Length fields. 1545 Option-Code 1546 1 Old Care-of Address 1547 2 New Care-of Address 1548 3 NAR's IP address 1550 Prefix Length 1551 The Length of the IPv6 Address Prefix. 1553 Reserved 1554 MUST be set to zero by the sender and MUST be 1555 ignored by the receiver. 1557 IPv6 address 1558 The IP address defined by the Option-Code field. 1560 6.4.2. New Router Prefix Information Option 1562 This option is sent in the PrRtAdv message in order to provide the 1563 prefix information valid on the NAR. 1565 0 1 2 3 1566 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 1567 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1568 | Type | Length | Option-Code | Prefix Length | 1569 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1570 | Reserved | 1571 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1572 | | 1573 + + 1574 | | 1575 + Prefix + 1576 | | 1577 + + 1578 | | 1579 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1581 Figure 12: New Router Prefix Information Option 1583 Type 1584 To be assigned by IANA 1586 Length 1587 The size of this option in 8 octets including the Type, 1588 Option-Code and Length fields. 1590 Option-Code 1591 0 1593 Prefix Length 1594 8-bit unsigned integer. The number of leading bits in the 1595 Prefix that are valid. The value ranges from 0 to 128. 1597 Reserved 1598 MUST be set to zero by the sender and MUST be 1599 ignored by the receiver. 1601 Prefix 1602 An IP address or a prefix of an IP address. The Prefix Length 1603 field contains the number of valid leading bits in the prefix. 1604 The bits in the prefix after the prefix length are reserved 1605 and MUST be initialized to zero by the sender and ignored by 1606 the receiver. 1608 6.4.3. Link-layer Address (LLA) Option 1610 0 1 2 3 1611 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 1612 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1613 | Type | Length | Option-Code | LLA... 1614 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1616 Figure 13: Link-Layer Address Option 1618 Type 1619 To be assigned by IANA 1621 Length 1622 The size of this option in 8 octets including the Type, 1623 Option-Code and Length fields. 1625 Option-Code 1626 0 wildcard requesting resolution for all nearby access points 1627 1 Link-layer Address of the New Access Point 1628 2 Link-layer Address of the MN 1629 3 Link-layer Address of the NAR (i.e., Proxied Originator) 1630 4 Link-layer Address of the source of RtSolPr or PrRtAdv 1631 message 1632 5 The access point identified by the LLA belongs to the 1633 current interface of the router 1635 6 No prefix information available for the access point 1636 identified by the LLA 1637 7 No fast handovers support available for the access point 1638 identified by the LLA 1640 LLA 1641 The variable length link-layer address. 1643 The LLA Option does not have a length field for the LLA itself. 1644 The implementations must consult the specific link layer over which 1645 the protocol is run in order to determine the content and length of 1646 the LLA. 1648 Depending on the size of individual LLA option, appropriate padding 1649 MUST be used to ensure that the entire option size is a multiple of 1650 8 octects. 1652 The New Access Point Link Layer address contains the link-layer 1653 address of the access point for which handover is about to be 1654 attempted. This is used in the Router Solicitation for Proxy 1655 Advertisement message. 1657 The MN Link-Layer address option contains the link-layer address of 1658 a MN. It is used in the Handover Initiate message. 1660 The NAR (i.e., Proxied Originator) Link-Layer address option 1661 contains the Link Layer address of the Access Router for which the 1662 Proxy Router Solicitation message refers to. 1664 6.4.4. Mobility Header Link-layer Address (MH-LLA) Option 1666 This option is identical to the LLA option, but is carried in 1667 the Mobility Header messages, e.g., FBU. In the future, other 1668 Mobility Header messages may also make use of this option. The 1669 format of the option is shown in Figure 14. There are no alignment 1670 requirements for this option. 1672 Type 1673 To be assigned by IANA 1675 Length 1676 The size of this option in octets not including the Type 1677 and Length fields. 1679 Option-Code 1680 2 Link-layer Address of the MN 1682 LLA 1683 The variable length link-layer address. 1685 0 1 2 3 1686 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 1687 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1688 | Type | Length | 1689 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1690 | Option-Code | LLA .... 1691 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1693 Figure 14: Mobility Header Link-Layer Address Option 1695 6.4.5. Binding Authorization Data for FMIPv6 (BADF) 1697 This option MUST be present in FBU and FBack messages. The 1698 security association between the MN and the PAR is established by 1699 companion protocols [5]. This option specifies how to compute and 1700 verify a MAC using the established security association. 1702 The format of this option is shown in Figure 15. 1704 0 1 2 3 1705 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 1706 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1707 | Type | Option Length | 1708 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1709 | SPI | 1710 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1711 | | 1712 + + 1713 | Authenticator | 1714 + + 1715 | | 1716 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1718 Figure 15: Binding Authorization Data for FMIPv6 (BADF) Option 1720 Type 1721 To be assigned by IANA 1723 Option Length 1724 The length of the Authenticator in bytes 1726 SPI 1727 Security Parameter Index. SPI = 0 is reserved for the 1728 Authenticator computed using SEND-based handover keys. 1730 Authenticator 1731 Same as in RFC 3775, with "correspondent" replaced by 1732 PAR's IP address, and Kbm replaced by the shared key 1733 between the MN and the PAR. 1735 The default MAC calculation is done using HMAC_SHA1 with the first 1736 96 bits used for the MAC. Since there is an Option Length field, 1737 implementations can use other algorithms such as HMAC_SHA256 for 1738 instance. 1740 This option MUST be the last Mobility Option present. 1742 6.4.6. Neighbor Advertisement Acknowledgment (NAACK) 1744 0 1 2 3 1745 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 1746 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1747 | Type | Length | Option-Code | Status | 1748 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1749 | Reserved | 1750 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1752 Figure 16: Neighbor Advertisement Acknowledgment Option 1754 Type 1755 To be assigned by IANA. 1757 Length 1758 8-bit unsigned integer. Length of the option, in 8 1759 octets. The length is 1 when a new CoA is not supplied. The 1760 length is 3 when a new CoA is present (immediately following 1761 the Reserved field) 1763 Option-Code 1764 0 1766 Status 1767 8-bit unsigned integer indicating the disposition of the Fast 1768 Neighbor Advertisement message. The following Status 1769 values are currently defined: 1771 1 The New CoA is invalid 1772 2 The New CoA is invalid, use the supplied CoA. The New 1773 CoA (in the form of an IP Address Option) MUST be 1774 present following the Reserved field. 1775 3 The New CoA is invalid, use NAR's IP address as NCoA in 1776 FBU 1777 4 PCoA supplied, do not send FBU 1778 128 Link Layer Address unrecognized 1779 Reserved 1780 MUST be set to zero by the sender and MUST be 1781 ignored by the receiver. 1783 The NAR responds to UNA with the NAACK option to notify the MN 1784 to use a different NCoA if there is address collision. If the 1785 NCoA is invalid, the Router Advertisement MUST use the NCoA as the 1786 destination address but use the L2 address present in UNA. The MN 1787 SHOULD use the NCoA if it is supplied with the NAACK option. If 1788 the NAACK indicates that the Link Layer Address is unrecognized the 1789 MN MUST NOT use the NCoA or the PCoA and SHOULD start immediately 1790 the process of acquiring different NCoA at the NAR. 1792 In the future, new option types may be defined. 1794 7. Configurable Parameters 1796 Parameter Name Default Value Definition 1797 ------------------- ---------------------- ------- 1798 RTSOLPR_RETRIES 3 Section6.1.1 1799 MAX_RTSOLPR_RATE 3 Section6.1.1 1800 FBU_RETRIES 3 Section 4 1801 PROXY_ND_LIFETIME 1.5 seconds Section 6.2.2 1802 HI_RETRIES 3 Section 6.2.1 1804 8. Security Considerations 1806 The following security vulnerabilities are identified, and 1807 suggested solutions mentioned. 1809 1. Insecure FBU: in this case, packets meant for one address 1810 could be stolen, or redirected to some unsuspecting node. 1811 This concern is the same as that in a MN and Home Agent 1812 relationship. 1814 Hence, the PAR MUST ensure that the FBU packet arrived from a 1815 node that legitimately owns the PCoA. The access router and its 1816 hosts may use any available mechanism to establish a security 1817 association which MUST be used to secure FBU. The current 1818 version of this protocol relies on a companion protocol [5] 1819 to establish such a security association. Using the shared 1820 handover key from [5], the Authenticator in BADF option 1821 (see 6.4.5) MUST be computed, and the BADF option included in 1822 FBU and FBack messages. 1824 If an access router can ensure that the source IP address in an 1825 arriving packet could only have originated from the node whose 1826 link-layer address is in the router's neighbor cache, then 1827 a bogus node cannot use a victim's IP address for malicious 1828 redirection of traffic. Such an operation is recommended at 1829 least on neighbor discovery messages including the RtSolPr 1830 message. 1832 2. Secure FBU, malicious or inadvertent redirection: in this 1833 case, the FBU is secured, but the target of binding happens to 1834 be an unsuspecting node either due to inadvertent operation 1835 or due to malicious intent. This vulnerability can lead to a 1836 MN with genuine security association with its access router 1837 redirecting traffic to an incorrect address. 1839 However, the target of malicious traffic redirection is limited 1840 to an interface on an access router with which the PAR has a 1841 security association. The PAR MUST verify that the NCoA to 1842 which PCoA is being bound actually belongs to NAR's prefix. In 1843 order to do this, HI and HAck message exchanges are to be used. 1844 When NAR accepts NCoA in HI (with Code = 0), it proxies NCoA so 1845 that any arriving packets are not sent on the link until the MN 1846 attaches and announces itself through UNA. So, any inadvertent 1847 or malicious redirection to a host is avoided. It is still 1848 possible to jam NAR's buffer with redirected traffic. However, 1849 since NAR's handover state corresponding to NCoA has a finite 1850 (and short) lifetime corresponding to a small multiple of 1851 anticipated handover latency, the extent of this vulnerability 1852 is arguably small. 1854 3. Sending FBU from NAR's link: a malicious node may send FBU 1855 from NAR's link providing an unsuspecting node's address as 1856 NCoA. This is similar to base Mobile IP where the MN can 1857 provide some other's node as its CoA to its Home Agent. As 1858 discussed in Section 5.5, the extent of such a misdelivery can 1859 be controlled and recovery is possible. In addition, it is 1860 possible to isolate the MN if it continues to misbehave. 1862 9. IANA Considerations 1864 This document defines four new experimental ICMPv6 messages which 1865 use the Experimental Mobility Protocol ICMPv6 format [4]. These 1866 require four new Subtype value assignments out of the Experimental 1867 Mobility Protocol Subtype Registry [4] as follows: 1869 Subtype Description Reference 1870 ------- ----------- --------- 1871 2 RtSolPr Section 6.1.1 1872 3 PrRtAdv Section 6.1.2 1873 4 HI Section 6.2.1 1874 5 HAck Section 6.2.2 1876 The document defines four new Neighbor Discovery [8] options which 1877 need Type assignment from IANA. 1879 Option-Type Description Reference 1880 ----------- ----------- --------- 1881 TBD IP Address Option Section 6.4.1 1882 TBD New Router Prefix 1883 Information Option Section 6.4.2 1884 TBD Link-layer Address 1885 Option Section 6.4.3 1886 TBD Neighbor Advertisement 1887 Acknowledgment Option Section 6.4.6 1889 The document defines three new Mobility Header messages which 1890 need type allocation from the Mobility Header Types registry at 1891 http://www.iana.org/assignments/mobility-parameters: 1893 1. Fast Binding Update, described in Section 6.3.1 1895 2. Fast Binding Acknowledgment, described in Section 6.3.2, and 1897 The document defines two new Mobility Options which need 1898 type assignment from the Mobility Options Type registry at 1899 http://www.iana.org/assignments/mobility-parameters: 1901 1. Mobility Header Link-Layer Address option, described in 1902 Section 6.4.4. 1904 2. Binding Authorization Data for FMIPv6 (BADF) option, described 1905 in Section 6.4.5. 1907 10. Acknowledgments 1909 The editor would like to thank all those who have provided feedback 1910 on this specification, and acknowledges the following people: 1911 Vijay Devarapalli, Youn-Hee Han, Emil Ivov, Syam Madanapalli, 1912 Suvidh Mathur, Andre Martin, Javier Martin, Koshiro Mitsuya, 1913 Gabriel Montenegro, Takeshi Ogawa, Sun Peng, YC Peng, Alex 1914 Petrescu, Domagoj Premec, Subba Reddy, K. Raghav, Ranjit Wable and 1915 Jonathan Wood. Behcet Sarikaya and Frank Xia are acknowledged for 1916 the feedback on operation over point-point links. The editor would 1917 like to acknowledge the contribution from James Kempf to improve 1918 this specification. The editor would also like to thank [mipshop] 1919 working group chair Gabriel Montenegro and the erstwhile [mobile 1920 ip] working group chairs Basavaraj Patil and Phil Roberts for 1921 providing much support for this work. 1923 11. Normative References 1925 [1] S. Bradner, ``Key words for use in RFCs to Indicate 1926 Requirement Levels,'' Request for Comments (Best Current 1927 Practice) 2119, Internet Engineering Task Force, March 1997. 1929 [2] A. Conta and S. Deering, ``Internet Control Message 1930 Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) 1931 Specification'', Request for Comments (Draft Standard) 2463, 1932 Internet Engineering Task Force, December 1998. 1934 [3] D. Johnson, C. E. Perkins, and J. Arkko, ``Mobility Support 1935 in IPv6'', Request for Comments (Proposed Standard) 3775, 1936 Internet Engineering Task Force, June 2004. 1938 [4] J. Kempf, ``Instructions for Seamoby and Experimental Mobility 1939 Protocol IANA Allocations," RFC 4065, Internet Engineering 1940 Task Force, June 2004. 1942 [5] J. Kempf and R. Koodli, "Distributing a Symmetric FMIPv6 1943 Handover Key using SEND," draft-ietf-mipshop-handover-key-00.txt 1944 (work in progress), February 2007. 1946 [6] S. Kent and R. Atkinson, ``IP Authentication Header'', Request 1947 for Comments (Draft Standard) 2402, Internet Engineering Task 1948 Force, November 1998. 1950 [7] R. Koodli (Editor), "Fast Handovers for Mobile IPv6," Request 1951 For Comments 4068, Internet Engineering Task Force, July 2005. 1953 [8] T. Narten, E. Nordmark, and W. Simpson, ``Neighbor Discovery 1954 for IP Version 6 (IPv6)'', Request for Comments (Draft 1955 Standard) 2461, Internet Engineering Task Force, December 1956 1998. 1958 [9] S. Thomson and T. Narten, ``IPv6 Stateless Address 1959 Autoconfiguration'', Request for Comments (Draft Standard) 1960 2462, Internet Engineering Task Force, December 1998. 1962 12. Author's Address 1964 Rajeev Koodli, Editor 1965 Nokia Siemens Networks 1966 313 Fairchild Drive 1967 Mountain View, CA 94043 USA 1968 Phone: +1 650 625 2359 1969 Fax: +1 650 625 2502 1970 E-Mail: Rajeev.Koodli@nokia.com 1972 13. Contributors 1974 This document has its origins in the fast handover design team 1975 in the erstwhile [mobile ip] working group. The members of this 1976 design team in alphabetical order were; Gopal Dommety, Karim 1977 El-Malki, Mohammed Khalil, Charles Perkins, Hesham Soliman, George 1978 Tsirtsis and Alper Yegin. 1980 A. Change Log 1982 - RFC4068bis: all the issues in the tracker since the 1983 publication of RFC 4068. (http://www.mip4.org/issues/tracker/mipshop) 1985 The following changes pre-date RFC 4068 publication. 1987 - Added IPSec AH reference. 1989 - Changed options format to make use of RFC 2461 options Type 1990 space. Revised IANA Considerations section accordingly. 1992 - Added exponential backoff for retransmissions. Added rate 1993 limiting for RtSolPr message. 1995 - Replaced ``attachment point'' with ``access point'' for 1996 consistency. 1998 - Clarified [AP-ID, AR-Info] in Section 2. Clarified use of 1999 Prefix Information Option in Section 6.1.2. 2001 - Separated MH-LLA from LLA to future-proof LLA option. 2003 The following changes refer up to version 02 (under mipshop). The 2004 Section numbers refer to version 06 (under mobile ip). 2006 - New ICMPv6 format incorporated. ID Nits conformance. 2008 - Last Call comments incorporated 2010 - Revised the security considerations section in v07 2012 - Refined and added a section on network-initiated handover v07 2014 - Section 3 format change 2016 - Section 4 format change (i.e., no subsections). 2018 - Description in Section 4.4 merged with ``Fast or Erroneous 2019 Movement'' 2021 - Section 4.5 deprecated 2023 - Section 4.6 deprecated 2025 - Revision of some message formats in Section 6 2027 Intellectual Property Statement 2029 The IETF takes no position regarding the validity or scope of 2030 any Intellectual Property Rights or other rights that might be 2031 claimed to pertain to the implementation or use of the technology 2032 described in this document or the extent to which any license 2033 under such rights might or might not be available; nor does it 2034 represent that it has made any independent effort to identify any 2035 such rights. Information on the procedures with respect to rights 2036 in RFC documents can be found in BCP 78 and BCP 79. 2038 Copies of IPR disclosures made to the IETF Secretariat and any 2039 assurances of licenses to be made available, or the result of an 2040 attempt made to obtain a general license or permission for the 2041 use of such proprietary rights by implementers or users of this 2042 specification can be obtained from the IETF on-line IPR repository 2043 at http://www.ietf.org/ipr. 2045 The IETF invites any interested party to bring to its attention any 2046 copyrights, patents or patent applications, or other proprietary 2047 rights that may cover technology that may be required to implement 2048 this standard. Please address the information to the IETF at 2049 ietf-ipr@ietf.org. 2051 Disclaimer of Validity 2053 This document and the information contained herein are provided 2054 on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 2055 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 2056 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 2057 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 2058 WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 2059 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 2060 FOR A PARTICULAR PURPOSE. 2062 Copyright Statement 2064 Copyright (C) The IETF Trust (2007). 2066 This document is subject to the rights, licenses and restrictions 2067 contained in BCP 78, and except as set forth therein, the authors 2068 retain all their rights. 2070 Acknowledgment 2072 Funding for the RFC Editor function is currently provided by the 2073 Internet Society.