idnits 2.17.1 draft-daley-mobileip-movedetect-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 96 has weird spacing: '...lidated becau...' == Line 125 has weird spacing: '...scovery with ...' == Line 165 has weird spacing: '... of the curre...' == Line 602 has weird spacing: '... ms require...' == Line 736 has weird spacing: '...ent and where...' == (1 more instance...) == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 2003) is 7645 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) == Unused Reference: 'CGA-00' is defined on line 1019, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2461 (Obsoleted by RFC 4861) ** Obsolete normative reference: RFC 2462 (Obsoleted by RFC 4862) -- Possible downref: Non-RFC (?) normative reference: ref. 'FASTRA-02' -- Possible downref: Non-RFC (?) normative reference: ref. 'FRD-00' -- Possible downref: Non-RFC (?) normative reference: ref. 'MIPv6-20' -- Possible downref: Non-RFC (?) normative reference: ref. 'SEND-psreq-01' Summary: 5 errors (**), 0 flaws (~~), 10 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Mobile-IP Working Group Greg Daley 3 INTERNET-DRAFT Monash University CTIE 4 Expires: December 2003 JinHyoeck Choi 5 Samsung AIT 6 May 2003 8 Movement Detection Optimization in Mobile IPv6 9 draft-daley-mobileip-movedetect-01.txt 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that other 18 groups may also distribute working documents as 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 any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or 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/lid-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 an individual submission to the IETF. Comments 32 should be directed to the authors. 34 Definitions of requirements keywords are in accordance with the IETF 35 Best Current Practice - [RFC-2119] 37 Abstract 39 This draft describes the state of the art techniques in movement 40 detection and elaborates on their application to Mobile IPv6 41 networks. The aim of the draft is to describe the applicability of 42 each mechanism and stimulate discussion on such techniques. 44 Table of Contents 46 Status of this Memo.......................................... 1 47 Abstract..................................................... 1 48 Table of Contents............................................ 1 49 1.0 Introduction............................................. 2 50 2.0 Movement Detection Overview.............................. 3 51 2.1 Handoff Process.......................................... 3 52 2.2 Movement Detection Mechanism............................. 4 53 2.3 Movement Detection Performance with Neighbor Discovery... 7 54 3.0 Movement Detection Schemes............................... 8 55 3.1 Periodic Router Advertisement Beaconing.................. 8 56 3.2 RA caching in Link-layer Access Points................... 9 57 3.3 Solicitation on Interval Timeout......................... 9 58 3.4 Link-up Triggers on the Mobile Node...................... 10 59 3.5 Fast Router Advertisement ............................... 11 60 4.0 Performance Considerations............................... 12 61 4.1 Effects of Solicitation Delays........................... 12 62 4.2 Performance Comparisons.................................. 13 63 4.3 Avoiding NUD without eager binding....................... 14 64 4.4 Effects of Packet Loss................................... 14 65 5.0 Combining Movement Detection Optimizations............... 15 66 6.0 Predictive Handover Effects.............................. 15 67 7.0 IANA Considerations...................................... 16 68 8.0 Security Considerations.................................. 16 69 Normative References......................................... 17 70 Non-Normative References..................................... 18 71 Acknowledgements............................................. 18 72 Authors' Address............................................. 18 73 Appendix..................................................... 74 Changes Since Last Revision.................................. 76 1.0 Introduction 78 Seamless handoff systems aim at reducing the disruption caused by 79 moving between IP networks. Movement Detection is a prerequisite 80 task necessary for a Mobile IPv6 (MIPv6) Mobile Node (MN) to perform 81 handover signaling[MIPv6-20]. As defined in the base MIPv6 82 specification, detection of movement is accomplished through 83 reception of Router Advertisements (RAs), and comparison of these 84 messages with previously received router information. 86 Other handover operations, such as Duplicate Address Detection(DAD) 87 and movement binding signaling occur subsequently to movement 88 detection. Since Movement Detection is a the first operation to 89 occur in a non-predicted handover, Movement detection optimizations 90 aim at reducing the time before the RA is received by the MN. This 91 reduction of movement detection time reduces handover duration. 93 The MN inspects RA messages to determine if a router on that 94 interface is providing routing information which supercedes or 95 invalidates a current Care-of-Address (CoA). The CoA may be 96 invalidated because a router retracts a prefix (valid lifetime=0), 97 timers expire which deprecate the existing CoA and Router entries or 98 a heuristic is in place assumes movement if an RA is received with a 99 new prefix, from a new router. In MIPv6, detection of movement 100 causes configuration or selection of new Care of Addresses, and 101 binding signaling is commenced. 103 2.0 The Current Status of Movement Detection 105 Movement detection is one of a series of stages in accomplishing 106 MIPv6 handover. The section below indicates the steps required for 107 handovers to occur. 109 2.1. Handoff Process 111 When an active MN moves to a new IP subnet, it changes its point of 112 attachment to the network through the following handoff process. 114 First Link-layer handoff occurs to change the wireless AP to which MN 115 is associated. After a new Link-layer connection is established, 116 Network-layer handoff is performed, which broadly involves movement 117 detection, IP address configuration and location update. Initially, 118 the MN's IP protocol implementation may be unaware of the link 119 change, or may have been informed of the arrival by a link- trigger. 120 Alternatively, the network itself may be aware of the MN's movement 121 and may make use of this information to aid movement detection. 123 The MN then checks the reachability of current AR. If the MN 124 determines the AR is no longer reachable, the MN performs Router 125 Discovery with new AR and subsequently a Router Advertisement with 126 all options arrives from a new AR. 128 Once the MN discovers a new AR with necessary informations, stateless 129 or stateful address configuration including DAD is 130 performed[RFC-2462]. This entails waiting for address validation to 131 complete, before further packets may be sent or received by the MN. 133 Mobility signaling procedures are then started, with the MN sending a 134 Binding Update (BU) to its Home Agent. Additionally Return 135 Routability (RR) procedures are started for route optimized 136 conversations with Correspondent Nodes (CNs). As the Return 137 Routability tests are completed, further BU messages are sent to CNs. 139 Since Movement Detection is prerequisite for other network-layer 140 handoff operations, for seamless handoff, it is necessary to detect 141 movement as fast as possible given the underlying link technology. 143 Proposals for predictive handovers change these assumptions and 144 ordering. The role played by movement detection in predictive 145 handovers is defined in section 6.0. 147 2.2. Movement Detection Overview 149 The primary movement detection mechanism for Mobile IPv6 defined in 150 [MIPv6-20] uses the facilities of IPv6 Neighbor Discovery, including 151 Router Discovery (RD) and Neighbor Unreachability Detection (NUD). 153 In Movement Detection, an MN should check the (partial) reachability 154 of the current AR and the validity of the current CoA. This allows 155 the MN to distinguish between link-layer and network-layer handovers. 156 In case of IP subnet change, an MN should also discover a new AR with 157 necessary information, including on-link prefix to form a new CoA. 159 In brief, the Movement Detection process is as follows: 161 First there is some hint that MN may have moved to another subnet. 162 This hint itself doesn't confirm movement. 164 Then the MN probes the current AR to check its reachability and the 165 validity of the current CoA. 167 If it turns out that MN has actually moved, it searches for a new AR 168 with Router Discovery. After an RA from a new AR arrives with 169 necessary information, the MN performs further operations, 170 forming a CoA and sending Binding Updates. 172 There are 3 entities which may change in connection with MN movement, 173 Access Point (Link-layer connection), Access Router and On-link 174 Prefixes (IP Subnet). 176 These changes are indicated to MN with the following: 177 1) Link-layer trigger (Some information from lower layer which 178 notifies link change) 180 2) a new IP address (in source address field of RA) 182 3) a new Subnet Prefix (in Prefix Information Option in RA) 184 To get the above indications, MN can perform NS/NA exchange, RS/RA 185 exchange or just receive unsolicited RAs. 187 The source address of the RA is a Link-Local address, its uniqueness 188 is not guaranteed outside a link. Hence the fact that MN receives 189 the RA with the same address doesn't guarantee that it comes from 190 current AR. 192 ARs may omit a Prefix Information Option for efficiency. Hence the 193 lack of the prefix of the current CoA in RA doesn't mean that current 194 CoA is not valid. 196 The above defects may results in the problem like this. Assume MN 197 moves from AR1 to AR2. If AR1 and AR2 have the same link-local 198 address, the MN may not detect its movement even after several RAs. 200 The entities may change together or separately. Therfore any 201 indications can't represent subnet movement precisely by itself. 203 ------- ------- 204 | AR1 | | AR2 | 205 ------- ------- 206 C::3 | |D::4 207 | | 208 |AP1 | 209 /-------------\ | 210 / \ |AP2 211 / /-------\-------\ 212 \ / \ \ 213 \ / / \ 214 Cell 1 \ \ / ------ \ 215 Coverage \-----\-------/ | MN | / 216 \ ------ / Cell 2 217 \---------------/ Coverage 219 Figure 1. MN moving between two networks 221 For example, in Figure 1, MN moves from AP1 to AP2 and all three 222 entities change. 224 ------- ------- 225 | AR1 | | AR2 | 226 ------- ------- 227 A::1 | | A::2 228 |-----------------| 229 | | 230 /-------------\ | 231 / \ | 232 / /-------\-------\ 233 \ / \ \ 234 \ / / \ 235 Cell 1 \ \ / ------ \ 236 Coverage \-----\-------/ | MN | / 237 \ ------ / Cell 2 238 \---------------/ Coverage 240 Figure 2. MN sees two access routers on the same subnet 242 In Figure 2, AR1 and AR2 are routers on the link. Each advertise a 243 prefix A:: to hosts. When the MN moves from AP1 to AP2, it changes 244 AP and AR but remains in same IP subnet. 246 ------- ------- 247 | AR1 | | AR2 | 248 ------- ------- 249 C::3 | | D::4 250 |-----------------| 251 | 252 /-------------\ 253 / \ 254 / \ 255 \ ------ \ 256 \ | MN | / 257 Cell 1 \ ------ / 258 Coverage \-------------/ 260 Figure 3. Two Access routers on the same subnet 262 In Figure 3, AR1 and AR2 are routers on the link which share a common 263 AP. Each advertise a prefix C:: or D:: to hosts. Assume AR1 is MN's 264 current default router. Then the arrival of a RA from AR2 doesn't 265 mean MN has moved. 267 ------- 268 | AR1 | 269 ------- 270 C::3 | 271 |-----------------| 272 | | 273 /-------------\ | 274 / \ | 275 / /-------\-------\ 276 \ / ------ \ \ 277 \ / | MN | / \ 278 Cell 1 \ \ ------ / \ 279 Coverage \-----\-------/ / 280 \ / Cell 2 281 \---------------/ Coverage 283 Figure 4. MN moves between wireless links in the same subnet 285 In Figure 4, If MN moves AP1 to AP2, it still remains at same IP 286 subnet even though it receives link-layer change notification from 287 lower layer. 289 An MN's Movement Detection scheme should combine available 290 information to detect movement correctly. It should not mistake some 291 hint as movement while the MN hasn't moved. That may result in 292 continual handoff, and hence excessive mobility signaling. If the MN 293 moves, it needs to detect movement sufficiently fast so that it can 294 complete handover signaling without significantly degrading 295 application performance. 297 On the other hand, if the MN doesn't move though it receives some 298 hints (like Figure 3,4), it is not imperative to detect its non- 299 movement so fast. It will not degrade performance even if MN can't 300 quickly confirm that it still remains at the same subnet. 302 A movement detection scheme should not result in excessive signaling 303 traffic. It should not flood the network with unnecessary RS/RA or 304 NS/NA messages. 306 2.3. Movement Detection Mechanism 308 Movement Detection Mechanism consists of following steps. 309 Step 1. Hint 310 Step 2. Checking the reachability of the current AR 311 Step 3. Checking the validity of the current CoA 312 Step 4. Discovering new AR with necessary information. 314 2.3.1 Receiving Movement Hints 316 There is a set of hints which can indicate that Network-layer 317 movement has occurred. The hints can be Link-layer trigger, the 318 receipt of a new RA or the lack of RA from current AR. This hint 319 itself doesn't confirm L3 movement. 321 2.3.2 Checking the reachability of the current AR 323 An MN checks whether current AR is still reachable by probing. The 324 MN may probe with NS or RS. 326 In case of NS probing similar to NUD, an MN sends unicast NS messages 327 to the current AR. If the current AR replies with a NA, the MN can 328 be sure that it is still reachable. If an NA doesn't arrive after 1 329 sec, the MN resends the NS. After 3 probe attempts, the MN decides 330 that the AR is no longer reachable. 332 If an MN actually has moved to new IP subnet, it will take 3 seconds 333 to detect that the current AR is not reachable (sending 3 NS probes, 334 plus waiting 1 second for each). With NUD, we can detect a node's 335 presence very quickly. Conversely, it takes substantial time (3 Sec) 336 to detect that node is NOT there. 338 In order to reduce the time taken to detect a router's non-presence, 339 the MN may use a timeout. Instead of retransmitting, the MN just 340 sends one NS, and waits for a reply for fixed time. If the MN times 341 out before receiving a reply, it assumes that it has moved. 343 Attempts at avoiding the cost of NUD without resorting to eager 344 bindings or NS/NA heuristics are discussed in section 4.3. 346 2.3.3. Checking the validity of the current CoA 348 When the NS/NA exchange is for the AR's link-local address, the MN 349 can't be sure that it still remains at the same IP subnet since link- 350 local scoped addresses uniqueness is only guaranteed on the link. 351 The MN may have moved to a new AR which happens to have the same 352 link-local address as the current AR. 354 Hence MN also has to confirm the validity of the current CoA by 355 checking on-link prefixes. The MN sends a unicast RA to current AR. 356 When a solicited RA with all options arrives, the MN checks whether 357 it contains the prefix of current CoA in any of its Prefix 358 Information Options. 360 As an alternative solution, the MN may send the NS to a globally 361 unique router address, if it is carried in a MIPv6 modified Prefix 362 Information Option advertised by the current router. An NA response 363 from this router address can uniquely provide reachability 364 confirmation for the router, since only the current router may have 365 this address. 367 2.3.4. Discovering a new AR 369 If it turns out that MN has actually moved, it has to find a new AR 370 using Router Discovery[RFC-2461]. The MN sends a Router Solicitation 371 to the All-routers multicast address. When a solicited RA with all 372 options arrives, the MN selects a new AR, forms a new CoA and perform 373 further operations. 375 We can perform Movement Detection Steps 2,3,4, with only one RS/RA 376 exchange as illustrated below. 378 To check the reachability of current AR, instead of using NS, the MN 379 sends an RS to the All-Routers multicast address. 381 If current AR is still reachable, MN will receive an RA with all 382 options within roughly 1.5 Sec (1 Sec random RS delay and 0.5 sec 383 random RA delay). Since RA messages do not explicitly indicate if 384 they are solicited, we can't say that the current AR is reachable if 385 we receive an RA. We can say though, if we don't receive a RA in 386 time, it's highly probable that the current AR is not reachable. 388 If a solicited RA with all options arrives from current AR, the MN 389 can confirm that current AR can still reach MN and current CoA is 390 still valid. 392 If no RA arrives from the current AR, but the MN receives several RAs 393 from new ARs, the MN chooses a new default AR. 395 Though the MN can't confirm reachability of the new AR, if its RA 396 contains a Source Link-Layer Address option, the MN will gain a stale 397 Neighbor Cache entry for the router. This means the MN can start 398 sending packets. Moreover the solicited RA from the new AR contains 399 all the necessary information for IP configuration. Hence the MN can 400 perform further operations immediately without additional signaling 401 messages or delay. After the handoff process is completed, the MN 402 can perform NUD with the new AR to confirm the reachability at its 403 leisure. 405 Below is a comparison of the comparitive merits of RS/RA and NS/NA 406 probing 408 The benefits and drawbacks of NS/NA probing are: 410 1) Since there is no Random Delay, MN and AR can send NS and NA 411 immediately. 413 2) The solicited flag confirms bi-directional reachability. 415 3) The MN needs to perform at least one RS/RA exchange afterwards. 416 (Unless a globally unique router address is probed). 418 The benefits and drawbacks of RS/RA probing are: 420 1) With only one RS/RA exchange, MN can check the (partial) 421 reachability of a current AR, validity of current CoA and 422 receive all the necessary information from a new AR. 424 2) There are two random delays of up to 1 Sec for RS and 0.5 Sec for 425 RA. Hence it take more time to RS/RA exchange with RA timouts 426 being set appropriately. This may be solved with FastRA (Section 427 3.5). 429 3) It may cause excessive multicast RA traffic. 431 4) MN can't confirm reachability of AR. 433 We may shorten the time taken to detect movement by performing 434 multiple operations in parallel. For example, by sending NS to 435 current AR and RS to all-routers multicast address at the same 436 time, we can perform Step 2, 3, 4 simultaneously. If there are 437 many wrong movement hints, this may cause excessive multicast 438 traffic. 440 There is still much to investigate about the necessary steps of 441 Movement Detection, their order of performance order, efficient 442 (NS and RS) probing mechanisms and the trade-off between 443 Movement Detection time and signaling traffic. 445 2.4. Movement Detection Performance with Neighbor Discovery 447 Movement detection algorithms are based on Neighbor and Router 448 Discovery mechanisms[RFC-2461]. Neighbor Discovery allows 449 solicitation of NA in order to confirm reachability. Router 450 Discovery allows the periodic multicast of RAs to nodes on a (fixed) 451 IPv6 network. [RFC-2461] additionally allows solicitation of RAs in 452 order to confirm network identity, or speed device configuration. 454 Neighbor Discovery protocol constants were sized for networks of many 455 nodes, where it was sufficient to provide configuration within a few 456 seconds. This has caused significant delays to be built into 457 Neighbor and Router Discovery[RFC-2461]. Networks supporting MIPv6 458 MNs need to be able to check (partial) reachability and receive RAs 459 in shorter time intervals than are available for standard Neighbor 460 Discovery. This is important if Mobile Nodes have existing higher- 461 layer sessions when Movement Detection is performed, which may be 462 affected by slow handover times. 464 Movement detection performance is measured from the time when the new 465 Link-layer connection is established until Movement Detection is 466 completed through suitable RA reception from new AR. 468 At first MN receives a hint that it may have moved. The time taken 469 to receive for this hint varies. With Link-layer trigger support, it 470 can be done instantly. 472 Alternatively an MN can monitor periodic RA beacons. The base MIPv6 473 document uses RA Interval Timer expiry as a hint. An MN may 474 implement its own policy to determining the number of missing RAs 475 which it will interprets as hint for possible movement. 477 With payload traffic tracking, we may get a hint earlier. An MN may 478 implement its own policy to determining the interval of idle time 479 with no traffic which it will interprets as a hint for possible 480 movement. Care should be taken in this case to ensure that spurious 481 hints do not cause unnecessary probing of the network. 483 Without schemes such as those above to provide hints, the MN must 484 wait to receive an RA from a new AR before undertaking Movement 485 Detection. Hence the detection delay depends on the frequency of 486 Router Advertisements. 488 Periodic RA beaconing transmits packets within an interval varying 489 randomly between MinRtrAdvInterval to MaxRtrAdvInterval seconds. In 490 [RFC-2461] minimums for these values are 3 and 4 seconds, 491 respectively. Since MN movement is unrelated to the advertisement 492 time on the new network, the MN is expected to arrive on average half 493 way through the interval. This is about 1.75 seconds with [RFC-2461] 494 advertisement rates. Worst case performance (without packet loss) is 495 when the MN arrives just after an RA, and the next RA is scheduled 496 close to MaxRtrAdvInterval. If [MIPv6-20] advertisement intervals 497 are in use, these values drop to 0.025 and 0.70 seconds respectively. 499 Next the MN probes the current AR to check its reachability and CoA 500 validity. There is no single agreed way mandated for this. 502 For example, assume the MN uses NS probing. If the MN probes with NS 503 using NUD-like retries, the AR's unreachability will be detected 504 after 3 sec for the case when the MN actually has moved. If the MN 505 uses one NS and a timeout, the duration depends on the timeout value. 506 We may set timeout value as 2 * RTT time from MN to AR. There is no 507 consensus on timeout values yet and the RTT time in wireless 508 environment may be highly volatile. 510 Afterwards, an MN should perform one RS/RA exchange, whether the 511 current AR is reachable or not. This is subject to routers delaying 512 0-500 ms before responding to the RS, and the advice that the MN 513 delays 0-1000 ms before sending an RS [RFC-2461]. Additionally, if 514 there is no verified link-address available for Router Solicitation, 515 the router must respond with a multicast RA. 517 Movement detection optimizations seek to lower the time taken to 518 perform Neighbor and Router Discovery, either through MN 519 solicitation, or timely unsolicited advertisement of router 520 information. To achieve this aim, modifications to NUD and Router 521 Discovery are made on mobile-supporting networks and MNs. 523 3.0 Movement Detection Schemes 525 3.1 Periodic Router Advertisement Beaconing 527 Beaconing is a term used to refer to multicasting of network 528 identification information at regular intervals. Mobile IPv6 reduces 529 the lower bound of the MinRtrAdvInterval and MaxRtrAdvIntervals to 30 530 and 70 ms respectively[MIPv6-20]. With these settings, beacons will 531 be sent no more closely than 30 ms apart, and with no greater 532 separation than 70ms. Routers are required to send the beacons at 533 random times within this interval. This means that an MN will 534 receive an RA within 70ms of arriving on the link, and may expect to 535 receive an RA within 25ms, if we assume MN entry into the network to 536 be randomly distributed in the interval. 538 This technique requires no action on the part of the MN other than 539 listening to RA multicasts. The bandwidth consumption by multicast 540 beacons is 14 kbps when RAs only include one Prefix Information 541 option. Addition of a Source-Link-layer-Address option and a MIPv6 542 Advertisement Interval option typically increase this to 16.6 kbps. 544 On some networks, such overhead (~20 multicast packets per second) 545 causes a serious burden on network bandwidth. In these cases, 546 [RFC-2461] specified intervals SHOULD be used, if other movement 547 detection mechanisms are available. 549 Additionally, the reduced interval between messages may have side 550 effects for non-MIPv6 nodes on the same networks. The 551 AdvDefaultLifetime value is used to set the lifetime of the default 552 router in seconds, as advertised in the Router Lifetime field of the 553 RA. The minimum value specified in [RFC-2461] for this value is 554 MaxRtrAdvInterval. This value is less than one second when using 555 MIPv6 specified advertisement intervals. Even if default router 556 lifetimes are rounded up to the nearest second, nodes which assume 557 MaxRtrAdvInterval is at [RFC-2461] values could be confused about the 558 lifetime of their default router. Routers SHOULD ensure that 559 AdvDefaultLifetime is greater than or equal to 4 seconds, in order to 560 avoid this confusion. 562 3.2 RA caching in Link-layer Access Points (Fast Router Discovery 563 [FRD-00]) 565 One method which requires no solicitation from the MN is network 566 triggering of RA. Router advertisements are sent to the MN when it 567 attaches to an access point (AP) associated with this network. 569 In network deployments, the router may not be the link-layer device 570 which the MN connects to, and therefore may be unaware of MN link- 571 connection. Only in the case where the the AP advises the router of 572 connection or AAA state, can the router send (unscheduled) 573 unsolicited RAs before receiving packets from the MN. 575 The Fast Router Discovery (FRD) draft[FRD-00] places the 576 responsibility of sending triggered RA messages upon APs. The Access 577 Points cache RA's recently sent from the router, and deliver a frame 578 to the MN when it connects. This frame is datalink-unicast to the MN 579 and contains the most recent unsolicited RA. 581 In this case, less frequent transmission of unsolicited multicast RA 582 messages may be used. At the same time, the first frame which is 583 queued for the MN is the RA required for movement detection. 585 Deployment of FRD requires each of the APs for the network to be 586 capable of both the caching and triggered sending operations. 587 Analysis and experimental results indicate that this is potentially 588 the fastest network-layer based movement detection optimization, 589 dependent on AP processing capacity. 591 3.3 Solicitation on Interval Timeout 593 As specified in MIPv6, the Advertisement Interval Option describes 594 the maximum time between unsolicited RA messages (MaxRtrAdvInterval). 595 This option is used in movement detection as a packet loss management 596 system, where after elapse of one or more Advertisement Intervals 597 without RA reception, the MN can send a router solicitation. 599 In the case where MNs send RSs after the loss of multicast RA 600 messages, all MN's which have not received the RAs will time out at 601 the same instant. [RFC-2461] specifies an additional delay of 0-1000 602 ms required for the purposes of desynchronizing RS messages sent 603 from many hosts. An MN which does not have other confirmation that 604 it has moved SHOULD follow this policy. Further details of this 605 issue, especially with regard to simultaneous movement, are presented 606 in section 4.1. 608 In the case where the MN moves by itself, this algorithm provides 609 best performance when the MN connects to a new network just before an 610 interval passes. If the MN is acting upon one packet's loss then 611 this provides an RS immediately. If the timer elapses when there is 612 no connection to a link, it is implementation dependent whether the 613 RS packet is lost. Typically though, the MN will leave the previous 614 access network on average half way through the mean RA interval. The 615 expected time left until the Advertisement Interval elapses upon the 616 MN leaving the network is: 618 ExpIval = 0.75*MaxRtrAdvInterval - 0.25*MinRtrAdvInterval 620 This does not account for the link-layer handover time, which may be 621 tens or hundreds of milliseconds. When these values are the minimums 622 described by [RFC-2461], this value is 2.25 seconds and therefore 623 does not seem to provide significant benefit unless faster (MIPv6) 624 beacons are being sent. At the MN specified beacon rate, the 625 expected residual interval is 45 ms. 627 Any of the methods which require responses to Router Solicitations as 628 specified by [RFC-2461] also incur an additional delay of between 0 629 and 500 ms before a response is sent by the router. Section 3.5 630 describes a mechanism to cope with this issue. 632 3.4 Link-up Triggers on the Mobile Node 634 For situations where RA packets have been transmitted correctly, the 635 Advertisement Interval's best case occurs when the timeout occurs 636 just after the MN joins a new link. In environments where the MN can 637 receive an indication a link has been joined, this information can be 638 used to trigger an RS immediately[MIPv6-20], although once again a 639 random delay before sending RS's is advised by [RFC-2461]. 641 Additionally, even if the MN doesn't send an RS upon receiving a 642 link-up trigger, it can use the trigger to validate received RA 643 messages for movement detection with eager-binding. The MN may be 644 able to enter an 'eager-binding' state until it receives its first RA 645 on the new link. If it receives an RA from a previously unseen 646 router at this time, it may be useful to confirm bidirectional 647 reachability with this outer, and then undertake movement signaling. 649 Upon entering a new subnet, there is a small chance that the MN will 650 have a duplicate address collision with another device's Link-Local 651 address[RFC-2462]. When an MN solicits an RA, it typically sends 652 from the Link-Local address, unless this address is 653 tentative[RFC-2461]. If the MN sends from the Link-Local address, 654 unicast responses are allowed, and in this case, rate limiting of 655 multicast RA messages is avoided. 657 If the MN joins a link, then until it knows the identity of the link 658 (has received an RA), it MUST assume that it is on a new link, where 659 its Link-Local address is tentative. This means that RS messages 660 will either be deferred until DAD operations have been performed on 661 the Link-Local address or the RS MUST be sent with an unspecified 662 address. A multicast response will be scheduled no sooner than: 664 Max(LastMcastRATime + MinDelayBetweenRAs, 665 now + 0-500 ms RS Response Delay) 667 Where MinDelayBetweenRAs could be as high as 3 seconds. Even if the 668 response is not multicast, the RS response delay is still incurred. 670 3.5 Fast Router Advertisement [FASTRA-02] 672 Fast Router Advertisement (FastRA) removes the random delay required 673 of a router before it responds to RS messages. It relies upon only 674 one router on a subnet being configured for FastRA, so that responses 675 are not simultaneous. FastRA principally aims at delivery of unicast 676 RA messages, since the rate limiting of multicast RA messages 677 specified in [RFC-2461] specifies that RA messages may not be sent 678 within 3 seconds of each other. 680 Similar action could be performed with multicast RA responses if 681 FastRA adopted the MinDelayBetweenRAs as in [MIPv6-20]. In this 682 case, the response would only be delayed if the last multicast RA 683 occurred more recently than MinDelayBetweenRAs ago (or MaxFastRAs has 684 been consumed). This could work well if the arrival of mobile nodes 685 occurred much less frequently than the unsolicited multicast RA 686 interval. 688 FastRA incorporates a rate limiting feature aimed at diminishing the 689 potential effect of FastRA traffic on nodes which are already 690 connected to the network. Routers may transmit no more than 691 MaxFastRAs advertisements in an interval before discarding 692 solicitations until the next unsolicited multicast RA. 694 Either of the solicitation mechanisms may be used to get FastRA 695 response from a router, although Advertisement Interval timeout will 696 only be invoked on packet loss if Link-triggers are available. 698 Movement detections times are bounded only by the time to send the 699 Multicast RS message and send the unicast RA response. Recent 700 testing has indicated 95% of RAs were received within 15 ms of 701 sending an RS on 802.11b networks, when Neighbor Discovery was being 702 performed on the MN's Link-Local address. If RS messages include 703 Source link-layer Address options[RFC-2461] or are multicast 704 responses with no timer delays, movement detection time will be 705 lower. 707 4.0 Performance Considerations 709 4.1 Effects of Solicitation Delays 711 [RFC-2461] specifies that a node SHOULD delay a random interval of 712 between 0 and 1000 (MAX_RTR_SOLICITATION_DELAY) ms before sending an 713 RS if it is the first packet the node sends on the link [RFC-2461]. 714 A similar delay is stipulated for DAD packets in [RFC-2462], for the 715 same circumstances. 717 These delays are provided for the case where many devices are 718 configuring on the link at the same time. In a mobility environment, 719 this may occur if many MNs are traveling together, for example on a 720 train, or at peak hours on a freeway. For this environment, there is 721 some possibility that the MNs' simultaneous transmission of multicast 722 RS or DAD packets will will cause interference or backoff and 723 retransmission. 725 The effect of such simultaneous movement and subsequent multicast 726 transmission is the topic of current research. On several wireless 727 technologies, the effect is thought to be minimal, especially where 728 discrete codes or data channels are provided to each subscriber. 730 There are certainly other environments where many devices 731 simultaneously transmitting have a detrimental effect though, and in 732 these cases, the configuration by MNs SHOULD be serialized. The 733 serialization provided by a random timer is one mechanism by which 734 simultaneous transmission may be avoided. Other methods, are reliant 735 upon serializing effects in the link-layer, such as AAA operations. 736 These effects are link-dependent and where they provide protection, 737 MNs SHOULD take advantage of them to avoid random timer delays. 739 It should be noted that multicast bombing may occur even in when no 740 RS is performed, if many nodes simultaneously receive an RA beacon 741 from a new router. These MNs' first operation is to undertake DAD 742 procedures. Link procedures are unlikely to provide serialization in 743 this case, since all MNs will receive the multicast at approximately 744 the same time. 746 In any case, the MN SHOULD undertake the RFC-2461 and RFC-2462 747 prescribed delays if any of the following is true: 749 * The MN has no upper-layer sessions 751 * The MN has no sessions which have sent or received data within 752 UPPER_LAYER_ACTIVITY seconds. The value of UPPER_LAYER_ACTIVITY 753 is implementation specific, but defaults to 120 seconds. 755 * The MN has more highly preferred interfaces which have the 756 currently bound CoAs configured for all current sessions. 757 Also, these CoAs are known to be successfully receiving and 758 sending data. 760 This limits the effect of link contention to active devices requiring 761 an expedited handover service. 763 4.2 Performance Comparisons 765 A table is provided which indicates the relative performance of 766 several movement detection schemes. 768 These handovers do not include delays due to DAD for unicast 769 responses, nor do they include RS/DAD delays to avoid multicast link 770 bombing. Additionally, the cost of determining reachability with the 771 current AR is ignored. 773 Presented times are on a wireless link of ~2 Mbps, which is capable 774 of multicast at 1 Mbps. 775 |--------------------------------------------------------------| 776 | | Uni/Multicast| overhead | Move Detection Time (ms) | 777 | | Advertisement| (kbps) | Avg | Max | 778 |--------------------------------------------------------------| 779 |Beacon | Multicast | >14 | 25 | 70 | 780 | | | | | | 781 |--------------------------------------------------------------| 782 |FRD | Multicast L3 | <1 | <10 | <20 | 783 | | (unicast L2?)| | | | 784 |--------------------------------------------------------------| 785 |Timer(a) | Unicast | <1 |ExpIval|MaxRtrAdvInterval | 786 | | | | +250 | +500 | 787 |--------------------------------------------------------------| 788 |LinkRS | Multicast | <1 | 250 | 530 | 789 |tentative| | | | | 790 |--------------------------------------------------------------| 791 |LinkRS | Unicast | <1 | 250 | 500 | 792 |unicast | | | | | 793 |--------------------------------------------------------------| 794 |FastRA | Multicast | <1 | <10 | 60 | 795 |tentative| | | | | 796 |--------------------------------------------------------------| 797 |FastRA | Unicast | <1 | <10 | <30 | 798 |unicast | | | | | 799 |--------------------------------------------------------------| 800 Notes: 802 (a) These duration values include link-layer handover time, 803 where no other row does. 805 4.3 Avoiding NUD without eager binding 807 The cost of performing NUD to the current AR in order to check 808 whether movement has occurred is expensive in the case that it has. 809 Proposals to avoid using NUD with the current access router have been 810 made in the mobile-ip working group. 812 One set of proposals which rely upon information in received router 813 advertisements to guarantee that a previously configured router is 814 uncontactable. 816 It is also possible to make use of link-layer information which 817 indicates a network domain change. Link-layer triggers pass 818 information to the network-layer which either explicitly provide 819 movement detection[WLANPIO-00], or disambiguate subsequently received 820 RA information. 822 Further reference will be made to drafts elaborating on these ideas 823 as they become available. 825 4.4 Effects of Packet Loss 827 Packet loss from (network and MN) triggered systems can be a 828 significant factor MIPv6 handovers performance. When a quickly 829 delivered RA message is lost, then the MN may wait until the next 830 unsolicited multicast RA message, which can take up to four seconds 831 (RFC-2461 MaxRtrAdvInterval). 833 In MN triggered systems, if RS messages are lost and have to be 834 resent, movement detection times are increased by up to four seconds. 835 This timeout is governed by the value of the Neighbor Discovery 836 constant RTR_SOLICITATION_INTERVAL. 838 In solicited RA environments, the exchange of RS/RA messages is 839 susceptible to loss of either packet, as is the case with NS/NA if 840 the router needs to perform Neighbor Discovery on the MN before 841 sending a unicast RA response. 843 Beacon systems which transmit RAs at high rate are less susceptible 844 to the adverse affects of packet loss, since replacement packets are 845 transmitted quickly after the packet loss event. 847 Backup effects from Advertisement Interval timers may play a part in 848 the solicitation of replacement RA messages, although unless link- 849 layer handover times are considered, these provide worse performance 850 than beacon based systems. 852 5.0 Combining Movement Detection Optimizations 854 When arriving on a network, an MN is unaware which movement detection 855 optimizations are in place on the network, or whether any are in use. 856 The MN may therefore choose to send an RS before it receives an 857 unsolicited RA, even though either FRD or RA beaconing are in place. 858 In all likelihood, both RA delivery mechanisms will be activated. 860 In this case, the movement detection time will typically not be 861 affected, except that more packets will be sent to the wireless 862 medium. Therefore, if an MN has received a link-trigger, and the MN 863 subsequently receives an RA before it has scheduled an RS packet to 864 be sent, the MN SHOULD NOT send the RS. 866 In most cases without packet loss, the presence of fast beacons will 867 not significantly affect the performance of FastRA or FRD systems. 869 As mentioned in section 4.4 though, the harm caused by packet loss is 870 significantly lowered if beacons are received within a short period. 871 If the overhead of running beaconing systems is sufficiently low for 872 the wireless link type, then beacons MAY be used with either of FRD 873 and FastRA. 875 Networks with either of FRD or FastRA capability are unlikely to also 876 use the other technology on their systems, since FRD and FastRA are 877 closely matched in performance and have low latency times. If the 878 network has both capabilities, there is some chance that RA messages 879 from AP and Router attempt to be delivered simultaneously to the MN. 880 Since there is no way for the MN to know that FRD is in use when 881 soliciting, it MAY send an RS in any case, if it has not received an 882 RA already from this link. 884 6.0 Predictive Handover Effects 886 Movement detection optimizations' applicability is principally in 887 non-predictive movement environments, although there may be some 888 benefit for anticipated/fast handover systems as movement 889 confirmation and correction mechanisms. 891 Handover prediction allows MNs to select the network to which they 892 move, and perform handover signaling in anticipation of this event. 893 This allows the tunneling and buffering of MN traffic within network 894 routers while the link-layer handover is occurring. 896 With some link environments, it may not be possible to guarantee that 897 the MN will arrive on the selected link, nor that the MN has indeed 898 arrived on that link. In these cases, it is still necessary to 899 confirm that the MN is arrived on the link through movement detection 900 algorithms. This allows the MN to send corrective binding signaling 901 in the case that the network is a different one than was the 902 anticipated destination. 904 7.0 IANA Considerations 906 No new message formats or services are defined in this document. 908 8.0 Security Considerations 910 Movement detection optimizations are reliant upon reception of a 911 Router Advertisement with properly configured Prefix Information 912 Options [RFC-2461]. 914 Since Movement Detection is based on Neighbor Discovery, its trust 915 models and threats are similar to the ones presented in [SEND- 916 psreq-01]. The attacks described in 4.0 of [SEND-psreq-01] can be 917 applied to Movement Detection too. Movement Detection schemes SHOULD 918 incorporate the solutions developed in IETF SEND Working Group if 919 available, where threat assessment indicates such procedures are 920 required. 922 Moreover the threats described in 4.2 of [SEND-psreq-01] may cause 923 more serious problems. When there is an indication that the current 924 IP connection has changed (Link down, New Router Advertisement et 925 cetera), non-mobile nodes will first perform NUD[RFC-2461]. The 926 MIPv6 handoff process (including Movement Detection) is time 927 sensitive. So mobile nodes may start an eager handoff without 928 Neighbor Unreachability Detection. 930 If higher layer notification of connectivity is not available, and 931 eager handoff strategies are in place, any node or router which 932 advertises an RA with a false prefix will cause MNs to perform 933 spurious handover signaling and DAD operations. 935 For non-mobile case, if a node receives a bogus RA which doesn't 936 include the prefix of its current address, it doesn't assume that its 937 current prefix becomes off-link. In Neighbor Discovery, the only way 938 to cancel a previous on-link indication is to advertise that prefix 939 with the L-bit set and the Lifetime set to zero [RFC-2461]. Hence the 940 node keeps using the current address and not so much harm is done. 942 In the mobile case, the threat is more serious. Assume an attacker 943 sends an RA which includes only false Prefix Information Options. If 944 a MN receives a bogus RA which doesn't include the prefix of the 945 current CoA, it will assume that movement has occurred. The MN will 946 start DAD (with the bogus prefix) and send BUs (with a false CoA). 947 Hence MN will be disconnected, or its packets will be intercepted and 948 subject to man-in-the-middle attack[SEND-psreq-01]. 950 Moreover if we configure MNs to send RS and DAD without delay, this 951 bogus RA attack may cause multicast bombing too. An attacker can 952 send a bogus RA without source link-layer Address option. Then all 953 MNs will receive the bogus RA at the same time and start Neighbor 954 Discovery simultaneously. They will send RS without delay at the 955 same time and cause RS congestion. An attacker can deceive all MNs 956 to believe they have moved simultaneously by sending a suitable bogus 957 RA. In this case, DAD would be performed by all nodes on the link 958 immediately on multicast RA reception. 960 The security issues described above are not specific to any Movement 961 Detection scheme presented in this draft but are inherent in any 962 mechanism which uses only Router Discovery for movement detection. 964 Information from lower layers will be useful to mitigate the above 965 threats. Assume there is an MN for which link-layer trigger is 966 provided to notify link-layer change. If the link-layer trigger 967 precedes a new RA, it is likely that the RA is valid and the MN has 968 actually moved. 970 When the MN moves to a new IP subnet, link-layer change usually 971 precede movement. So first link-layer change is notified to the MN 972 and it anticipates movement. Hence when a new RA arrives, the MN can 973 reasonably believe it. 975 On the other hand, if the MN receives a new RA without the 976 notification of link layer change, it is likely that the RA is bogus. 977 In this case, the MN SHOULD be suspicious: 979 Before initiating the handoff process, it SHOULD perform Neighbor 980 Unreachability Detection to request a RA from its default router. 981 Also, without link-layer information, RFC-2461 and 2462 delays before 982 sending RS and DAD messages SHOULD be performed, until NUD has 983 completed. 985 This document references several other documents, each of which 986 defines its own security considerations. Readers are referred to 987 these documents for further information. 989 Normative References 991 [RFC-2119] S. Bradner. Key words for use in RFCs to Indicate 992 Requirement Levels. Request for Comments (Best Current Practice) 993 2119 (BCP 14), Internet Engineering Task Force, March 1997 995 [RFC-2461] T. Narten, E.Nordmark, W. Simpson. Neighbor Discovery for 996 IP Version 6 (IPv6). Request for Comments (Draft Standard) 2461, 997 Internet Engineering Task Force, December 1998. 999 [RFC-2462] S. Thomson, T. Narten. IPv6 Stateless Address 1000 Autoconfiguration. Request for Comments (Draft Standard) 2462, 1001 Internet Engineering Task Force, December 1998. 1003 [FASTRA-02] M. Khalil, J. Kempf, B. Pentland. IPv6 Fast Router 1004 Advertisement (FastRA), Internet Draft (work in progress), 1005 October 2002. 1007 [FRD-00] JinHyoeck Choi, DongYun Shin. Fast Router Discovery with RA 1008 Caching in AP. Internet Draft (work in progress), Feb 2003. 1010 [MIPv6-20] D. Johnson, C. Perkins, J. Arkko. Mobility Support in 1011 IPv6. Internet Draft (work in progress), January 2003. 1013 [SEND-psreq-01] P. Nikander (Ed.), J. Kempf, E. Nordmark. IPv6 1014 Neighbor Discovery trust models and threats. Internet Draft 1015 (work in progress), January 2003. 1017 Non-Normative References 1019 [CGA-00] Tuomas Aura. Cryptographically Generated Addresses (CGA). 1020 Internet Draft (work in progress), February 2003. 1022 [WLANPIO-00] Paul Tan. Recommendations for Achieving Seamless IPv6 1023 Handover in IEEE 802.11 Networks. Internet Draft (work in 1024 progress), February 2003. 1026 Acknowledgements 1028 Thanks to the authors and editors of the MIPv6 (David Johnson, 1029 Charles Perkins Jari Arkko), FastRA (Mohammed Khalil, James Kempf 1030 and Brett Pentland), and FastRD (JinHyeock Choi {thx from Greg} and 1031 DongYun Shin) drafts. We have relied heavily upon their work and aim 1032 only to illuminate their good ideas. Additionally, we thank Ed 1033 Remmell and Erik Nordmark for their contributions in the working 1034 group. We're sure they'll recognise some of their ideas presented 1035 here. 1037 Authors' Addresses: 1039 Greg Daley 1040 E-mail: greg.daley@eng.monash.edu.au 1041 Phone: +61-3-9905-4655 1043 Address: 1044 Centre for Telecommunications and Information Engineering 1045 Department of Electrical and Computer Systems Engineering 1046 Monash University 1047 Clayton 3800 Victoria 1048 Australia 1050 JinHyoeck Choi 1051 E-mail: athene@sait.samsung.co.kr 1052 Phone: +82-31-280-9233 1053 Address: 1054 i-Networking Lab, Samsung AIT (SAIT) 1056 Appendix: 1058 .. 1060 Changes Since Last Revision: 1062 Since 00: 1064 More diagrams indicating MD issues. 1066 Stronger elaboration of MD mechanisms(NUD/NS/NA/RD) 1068 Added stronger guidance for avoiding multicast bombing. 1070 Added section on avoiding NUD safely (w/placeholder for potential 1071 references to LinkIDs draft &etc). 1073 Added eager-binding heuristic after link-up trigger (EN). 1075 This document expires in December 2003.