idnits 2.17.1 draft-ietf-mipshop-80211fh-04.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 3667, Section 5.1 on line 12. -- Found old boilerplate from RFC 3978, Section 5.5 on line 643. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 661. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 668. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 674. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) == There are 1 instance of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 2005) is 6972 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: 'AP-ID' on line 389 -- Looks like a reference, but probably isn't: 'AR-Info' on line 389 == Outdated reference: A later version (-03) exists of draft-ietf-mipshop-fast-mipv6-02 ** Downref: Normative reference to an Experimental draft: draft-ietf-mipshop-fast-mipv6 (ref. '2') -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' -- Possible downref: Non-RFC (?) normative reference: ref. '6' ** Obsolete normative reference: RFC 3775 (ref. '7') (Obsoleted by RFC 6275) Summary: 8 errors (**), 0 flaws (~~), 5 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft P. McCann 2 Document: draft-ietf-mipshop-80211fh-04.txt Lucent Technologies 3 Expires: August 2005 February 2005 5 Mobile IPv6 Fast Handovers for 802.11 Networks 7 Status of this Memo 9 By submitting this Internet-Draft, I certify that any applicable 10 patent or other IPR claims of which I am aware have been disclosed, 11 and any of which I become aware will be disclosed, in accordance with 12 RFC 3668. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 Abstract 31 This document describes how a Mobile IPv6 Fast Handover could be 32 implemented on link layers conforming to the 802.11 suite of 33 specifications. 35 802.11 Fast Handover February 2005 37 Conventions used in this document 39 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 40 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 41 document are to be interpreted as described in RFC-2119 [1]. 43 Table of Contents 45 1. Introduction...................................................2 46 2. Terminology....................................................3 47 3. Deployment Architectures for Mobile IPv6 on 802.11.............4 48 4. 802.11 Handovers in Detail.....................................5 49 5. FMIPv6 Message Exchanges.......................................7 50 6. Beacon Scanning and NAR Discovery..............................8 51 7. Scenarios......................................................9 52 7.1 Scenario 1abcdef23456g....................................10 53 7.2 Scenario ab123456cdefg....................................10 54 7.3 Scenario 123456abcdefg....................................10 55 8. Security Considerations.......................................11 56 9. Conclusions...................................................12 57 10. References...................................................13 58 11. Acknowledgments..............................................14 59 12. Author's Address.............................................14 61 1. Introduction 63 The Mobile IPv6 Fast Handover protocol [2] has been proposed as a way 64 to minimize the interruption in service experienced by a Mobile IPv6 65 node as it changes its point of attachment to the Internet. Without 66 such a mechanism, a mobile node cannot send or receive packets from 67 the time that it disconnects from one point of attachment in one 68 subnet to the time it registers a new care-of address from the new 69 point of attachment in a new subnet. Such an interruption would be 70 unacceptable for real-time services such as Voice-over-IP. 72 The basic idea behind a Mobile IPv6 fast handover is to leverage 73 information from the link-layer technology to either predict or 74 rapidly respond to a handover event. This allows IP connectivity to 75 be restored at the new point of attachment sooner than would 76 otherwise be possible. By tunneling data between the old and new 77 access routers, it is possible to provide IP connectivity in advance 78 of actual Mobile IP registration with the home agent or correspondent 79 node. This allows real-time services to be re-established without 80 waiting for such Mobile IP registration to complete. Because Mobile 81 IP registration involves time-consuming Internet round-trips, the 82 Mobile IPv6 fast handover can provide for a smaller interruption in 83 real-time services than an ordinary Mobile IP handover. 85 802.11 Fast Handover February 2005 87 The particular link-layer information available, as well as the 88 timing of its availability (before, during, or after a handover has 89 occurred), differs according to the particular link-layer technology 90 in use. This document gives a set of deployment examples for Mobile 91 IPv6 Fast Handovers on 802.11 networks. We begin with a brief 92 overview of relevant aspects of basic 802.11 [3]. We examine how and 93 when handover information might become available to the IP layers 94 that implement Fast Handover, both in the network infrastructure and 95 on the mobile node. Finally, we trace the protocol steps for Mobile 96 IPv6 Fast Handover in this environment. 98 2. Terminology 100 This document borrows all of the terminology from Mobile IPv6 Fast 101 Handovers [2], with the following additional terms from the 802.11 102 specification [3] (some definitions slightly modified for clarity): 104 Access Point (AP): Any entity that has station functionality and 105 provides access to the distribution services, via the 106 wireless medium (WM) for associated stations. 108 Association: The service used to establish access point/station 109 (AP/STA) mapping and enable STA access to the 110 Distribution System. 112 Basic Service Set (BSS): A set of stations controlled by a single 113 coordination function, where the coordination 114 function may be centralized (e.g., in a single AP) or 115 distributed (e.g., for an ad-hoc network). The BSS 116 can be thought of as the coverage area of a single 117 AP. 119 Distribution System (DS): A system used to interconnect a set of 120 basic service sets (BSSs) and integrated local area 121 networks (LANs) to create an extended service set 122 (ESS). 124 Extended Service Set (ESS): A set of one or more interconnected 125 basic service sets (BSSs) and integrated local area 126 networks (LANs) that appears as a single BSS to the 127 logical link control layer at any station associated 128 with one of those BSSs. The ESS can be thought of as 129 the coverage area provided by a collection of APs all 130 interconnected by the Distribution System. It may 131 consist of one or more IP subnets. 133 802.11 Fast Handover February 2005 135 Station (STA): Any device that contains an IEEE 802.11 conformant 136 medium access control (MAC) and physical layer (PHY) 137 interface to the wireless medium (WM). 139 3. Deployment Architectures for Mobile IPv6 on 802.11 141 In this section we describe the two most likely relationships between 142 Access Points (APs), Access Routers (ARs), and IP subnets that are 143 possible in an 802.11 network deployment. In this document our focus 144 is mainly on the infrastructure mode [3] of 802.11. Usually, a given 145 STA is associated with one and only one AP at any given instant; 146 however, implementations are possible [4] where multiple associations 147 per STA may be maintained as long as the APs are connected to 148 disjoint DSs. A STA may be in communication with an AP only when 149 radio propagation conditions permit. Note that, as with any layer-2 150 technology, handover from one layer-2 point of attachment (AP) to 151 another does not necessarily mean a change of AR or subnet. 153 AR AR 154 AR | AR AR | AR 155 \ | / \ | / 156 Subnet 1 Subnet 2 157 / / | \ \ / / | \ \ 158 / / | \ \ / / | \ \ 159 / | | | \ / | | | \ 160 AP1 AP2 AP3 AP4 AP5 AP6 AP7 AP8 AP9 AP10 162 Figure 1: An 802.11 deployment with relay APs. 164 Figure 1 depicts a typical 802.11 deployment with two IP subnets, 165 each with three Access Routers and five Access Points. Note that the 166 APs in this figure are acting as link-layer relays, which means that 167 they transport Ethernet-layer frames between the wireless medium and 168 the subnet. Note that APs do not generally implement any particular 169 spanning tree algorithm, yet are more sophisticated than simple 170 bridges that would relay all traffic; only traffic addressed to STAs 171 known to be associated on a given AP would be forwarded. Each subnet 172 is on top of a single LAN or VLAN, and we assume in this example that 173 APs 6-10 cannot reach the VLAN on which Subnet 1 is implemented. 174 Note that a handover from AP1 to AP2 does not require a change of AR 175 (here we assume the STA will be placed on the same VLAN during such a 176 handoff) because all three ARs are link-layer reachable from a STA 177 connected to any AP1-5. Therefore, such handoffs would not require 178 IP-layer mobility management, although some IP-layer signaling may be 179 required to determine that connectivity to the existing AR is still 180 802.11 Fast Handover February 2005 182 available. However, a handover from AP5 to AP6 would require a 183 change of AR, because AP6 cannot reach the VLAN on which Subnet 1 is 184 implemented and therefore the STA would be attaching to a different 185 subnet. An IP-layer handover mechanism would need to be invoked in 186 order to provide low-interruption handover between the two ARs. 188 Internet 189 / | \ 190 / | \ 191 / | \ 192 AR AR AR 193 AP1 AP2 AP3 195 Figure 2. An 802.11 deployment with integrated APs/ARs. 197 Figure 2 depicts an alternative 802.11 deployment where each AP is 198 integrated with exactly one AR on a disjoint VLAN. In this case, 199 every change of AP would result in a necessary change of AR, which 200 would require some IP-layer handover mechanism to provide for low- 201 interruption handover between the ARs. Also, the AR shares a MAC- 202 layer identifier with its attached AP. 204 In the next section, we examine the steps involved in any 802.11 205 handover. Subsequent sections discuss how these steps could be 206 integrated with an IP-layer handover mechanism in each of the above 207 deployment scenarios. 209 4. 802.11 Handovers in Detail 211 An 802.11 handover takes place when a STA changes its association 212 from one AP to another ("re-association"). This process consists of 213 the following steps: 215 0. The STA realizes that a handoff is necessary due to degrading 216 radio transmission environment for the current AP. 218 1. The STA performs a scan to see what APs are available. The 219 result of the scan is a list of APs together with physical 220 layer information, such as signal strength. 222 2. The STA chooses one of the APs and performs a join to 223 synchronize its physical and MAC layer timing parameters with 224 the selected AP. 226 802.11 Fast Handover February 2005 228 3. The STA requests authentication with the new AP. For an "Open 229 System", such authentication is a single round-trip message 230 exchange with null authentication. 232 4. The STA requests association or re-association with the new AP. 233 A re-association request contains the MAC-layer address of the 234 old AP, while a plain association request does not. 236 5. If operating in accordance with 802.11i [6] the STA and AP 237 would execute 802.1X EAP-on-LAN procedures to authenticate the 238 association (step 3 would have executed in "Open System" mode). 240 6. The new AP sends a Layer 2 Update frame on the local LAN 241 segment to update the learning tables of any connected Ethernet 242 bridges. 244 Although we preface step 1 with step 0 for illustration purposes, 245 there is no standardized trigger for step 1. It may be performed as 246 a result of decaying radio conditions on the current AP or at other 247 times as determined by local implementation decisions. Some NICs may 248 do scanning in the background, interleaving scans between data 249 packets. This decreases the time required to roam if the performance 250 of the current AP proves unsatisfactory, but it imposes more of a 251 burden on the AP, since typically the STA places it in power save 252 mode prior to the scan, then once the scan is complete, returns to 253 the AP channel in order to pick up enqueued packets. This can result 254 in buffer exhaustion on the AP, and attendant packet loss. 256 During step 2, the STA performs rate adjustment where it chooses the 257 best available transmission rate. Rate adjustment can be quite time 258 consuming as well as unpredictable. 260 Note that in some existing 802.11 implementations, steps 1-4 are 261 performed by firmware in rapid succession (note that even in these 262 implementations step 3 is sometimes performed in a host driver, 263 especially for newer implementations). This might make it impossible 264 for the host to take any actions (including sending or receiving IP 265 packets) before the handover is complete. In other 802.11 266 implementations, it is possible to invoke the scan (step 1) and join 267 (step 2) operations independently. This would make it possible to, 268 e.g., perform step 1 far in advance of the handover and perhaps in 269 advance of any real-time traffic. This could substantially reduce 270 the handover latency, as one study has concluded that the 802.11 271 beacon scanning function may take several hundred milliseconds to 272 complete [8] during which time sending and receiving IP packets is 273 not possible. However, scanning too far in advance may make the 274 information out-of-date by the time of handover, which would cause 275 the subsequent join operation to fail if radio conditions have 276 changed so much in the interim that the target AP is no longer 277 802.11 Fast Handover February 2005 279 reachable. So, a host may choose to do scanning based on, among 280 other considerations, the age of the previously scanned information. 281 In general, performing such subsequent scans is a policy issue that a 282 given implementation of FMIPv6 over 802.11 must consider carefully. 284 Even if steps 1 and 2 are performed in rapid succession, there is no 285 guarantee that an AP found during step 1 will be available during 286 step 2 because radio conditions can change dramatically from moment 287 to moment. The STA may then decide to associate with a completely 288 different AP. Often, this decision is implemented in firmware and 289 the attached host would have no control over which AP is chosen. 290 However, tools such as the host AP driver [10] offer full control 291 over when and to which AP the host needs to associate. Operation as 292 an Independent BSS (IBSS) or "ad-hoc mode" [3] may also permit the 293 necessary control, although in this latter case attachment to an 294 infrastructure AP would be impossible. Implementers can make use of 295 such tools to obtain the best combination of flexibility and 296 performance. 298 The coverage area of a single AP is known as a Basic Service Set 299 (BSS). An Extended Service Set (ESS) is formed from a collection of 300 APs that all broadcast the same ESSID. Note that a STA would only 301 send a re-association (which includes both the old and new AP 302 addresses) if the ESSID of the old and new APs are the same. 304 A change of BSS within an ESS may or may not require an IP-layer 305 handover, depending on whether the APs can send packets to the same 306 IP subnets. If an IP-layer handover is required, then FMIPv6 can 307 decrease the overall latency of the handover. The main goal of this 308 document is to describe the most reasonable scenarios for how the 309 events of an 802.11 handover may interleave with the message 310 exchanges in FMIPv6. 312 5. FMIPv6 Message Exchanges 314 An FMIPv6 handover nominally consists of the following messages: 316 a. The MN sends a Router Solicitation for Proxy (RtSolPr) to find 317 out about neighboring ARs. 319 b. The MN receives a Proxy Router Advertisement (PrRtAdv) 320 containing one or more [AP-ID, AR-Info] tuples. 322 c. The MN sends a Fast Binding Update (FBU) to the Previous Access 323 Router (PAR). 325 d. The PAR sends a Handover Initiate (HI) message to the New 326 Access Router (NAR). 328 802.11 Fast Handover February 2005 330 e. The NAR sends a Handover Acknowledge (HAck) message to the PAR. 332 f. The PAR sends a Fast Binding Acknowledgement (FBack) message to 333 the MS the new link. The FBack is also optionally sent on the 334 previous link if the FBU was sent from there. 336 g. The MN sends Fast Neighbor Advertisement (FNA) to the NAR after 337 attaching to it. 339 The MN may connect to NAR prior to sending the FBU if the handover is 340 un-anticipated. In this case, the FNA (step g) would contain the FBU 341 (listed as step c above) and then steps d, e, and f would take place 342 from there. 344 6. Beacon Scanning and NAR Discovery 346 The RtSolPr message is used to request information about the 347 router(s) connected to one or more APs. The APs are specified in the 348 New Access Point Link-Layer Address option in the RtSolPr and 349 associated IP-layer information is returned in the IP Address Option 350 of the PrRtAdv [2]. In the case of an 802.11 link, the link layer 351 address is the BSSID of some AP. 353 Beacon scanning (step 1 from Section 4) produces a list of available 354 APs along with signal strength information for each. This list would 355 supply the necessary addresses for the New Access Point Link-Layer 356 Address option(s) in the RtSolPr messages. To obtain this list the 357 host needs to invoke the MLME-SCAN.request primitive (See Section 358 10.3.2.1 of the 802.11 specification [3]). The BSSIDs returned by 359 this primitive are the link-layer addresses of the available APs. 361 Because beacon scanning takes on the order of a few hundred 362 milliseconds to complete, and because it is generally not possible to 363 send and receive IP packets during this time, the MN needs to 364 schedule these events with care so that they do not disrupt ongoing 365 real-time services. For example, the scan could be performed at the 366 time the MN attaches to the network prior to any real-time traffic. 367 However, if the interval between scanning and handover is too long, 368 the neighbor list may be out of date. For example, the signal 369 strengths of neighboring APs may have dramatically changed, and a 370 handover directed to the apparently best AP from the old list may 371 fail. If the handover is executed in firmware, the STA may even 372 choose a new target AP that is entirely missing from the old list 373 (after performing its own scan). Both cases would limit the ability 374 of the MN to choose the correct NAR for the FBU in step c during an 375 anticipated handover. Ongoing work in the IEEE 802.11k task group 376 may address extensions that allow interleaving beacon scanning with 377 802.11 Fast Handover February 2005 379 data transmission/reception along with buffering at APs to minimize 380 packet loss. 382 Note that, aside from physical layer parameters such as signal 383 strength, it may be possible to obtain all necessary information 384 about neighboring APs by using the wildcard form of the RtSolPr 385 message. This would cause the current access router to return a list 386 of neighboring APs, and would not interrupt ongoing communication 387 with the current AP. This request could be made at the time the MN 388 first attaches to the access router, and periodically thereafter. 389 This would enable the MN to cache the necessary [AP-ID, AR-Info] 390 tuples and might enable it to react more quickly when a handover 391 becomes necessary due to a changing radio environment. However, 392 because the information does not include up-to-date signal strength, 393 it would not enable the MN to predict accurately the next AP prior to 394 a handover. Also, if the scale of the network is such that a given 395 access router is attached to many APs, then it is possible that there 396 may not be room to list all APs in the PrRtAdv. 398 The time taken to scan for beacons is significant because it involves 399 iteration through all 802.11 channels and listening on each one for 400 active beacons. A more targeted approach would allow the STA to 401 scan, e.g., only one or two channels of interest, which would provide 402 for much shorter interruption of real-time traffic. However, such 403 optimizations are currently outside the scope of 802.11 404 specifications. 406 7. Scenarios 408 In this section we look at a few of the possible scenarios for using 409 FMIPv6 in an 802.11 context. Each scenario is labeled by the 410 sequence of events that take place, where the numbered events are 411 from Section 4 and the lettered events are from Section 5. For 412 example, "1abcde23456fg" represents step 1 from Section 4 followed 413 by steps a-e from Section 5 followed by steps 2-6 from Section 4 414 followed by steps f and g from Section 5. This is the sequence 415 where the MN performs a scan, then the MN executes the FMIPv6 416 messaging to obtain NAR information and send a binding update, then 417 the PAR initiates HI/HAck exchange, then the 802.11 handover 418 completes, and finally the HAck is received at the PAR and the MN 419 sends an FNA. 421 Each scenario is followed by a brief description and discussion of 422 the benefits and drawbacks. 424 802.11 Fast Handover February 2005 426 7.1 Scenario 1abcdef23456g 428 This scenario is the predictive mode of operation from the FMIPv6 429 specification. In this scenario, the host executes the scan sometime 430 prior to the handover, and is able to send the FBU prior to handover. 431 Only the FNA is sent after the handover. This mode of operation 432 requires that the scan and join operations (steps 1 and 2) can be 433 performed separately and under host control, so that steps a-f can be 434 inserted between 1 and 2. As mentioned previously, such control may 435 be possible in some implementations [10] but not in others. 437 Steps 1ab may be executed far in advance of the handover, which would 438 remove them from the critical path. This would minimize the service 439 interruption from beacon scanning, and allow at least one 440 RtSolPr/PrRtAdv exchange to complete so that the host has link layer 441 information about some NARs. Note that if steps ab were delayed 442 until handover is imminent, there would be no guarantee that the 443 RtSolPr/PrRtAdv exchange would complete especially in a radio 444 environment where the connection to the old AP is deteriorating 445 rapidly. However, if there were a long interval between the scan and 446 the handover, then the FBU (step c) would be created with out-of-date 447 information. There is no guarantee that the MN will actually attach 448 to the desired new AP after it has sent the FBU to the oAR, because 449 changing radio conditions may cause NAR to be suddenly unreachable. 450 If this were the case, then the handover would need to devolve into 451 one of the reactive cases given below. 453 7.2 Scenario ab123456cdefg 455 This is the reactive mode of operation from the FMIPv6 specification. 456 This scenario does not require host intervention between steps 1 and 457 2. 459 However, it does require that the MN obtain the link-layer address of 460 NAR prior to handover, so that it has a link-layer destination 461 address for outgoing packets (default router information). This 462 would then be used for sending the FNA (with encapsulated FBU) when 463 it reaches the new subnet. 465 7.3 Scenario 123456abcdefg 467 In this scenario the MN does not obtain any information about the NAR 468 prior to executing the handover. It is completely reactive, and 469 consists of soliciting a router advertisement after handover, and 470 then sending an FNA with encapsulated FBU immediately. 472 802.11 Fast Handover February 2005 474 This scenario may be appropriate when it is difficult to learn the 475 link-layer address of the NAR prior to handover. This may be the 476 case, e.g., if the scan primitive is not available to the host and 477 the wildcard PrRtAdv form returns too many results. It may be 478 possible to skip the router advertisement/solicitation steps (ab) in 479 some cases, if it is possible to learn the NAR's link-layer address 480 through some other means. In the deployment illustrated in Figure 2, 481 this would be exactly the new AP's MAC layer address, which can be 482 learned from the link-layer handover messages. However, in the case 483 of Figure 1, this information must be learned through router 484 discovery of some form. Also note that even in the case of Figure 2, 485 the MN must somehow be made aware that it is in fact operating in a 486 Figure 2 network and not a Figure 1 network. 488 8. Security Considerations 490 The security considerations applicable to FMIPv6 are described in the 491 base FMIPv6 specification [2]. In particular, the PAR must be 492 assured of the authenticity of the FBU before it begins to redirect 493 user traffic. However, if the association with the new AP is not 494 protected using mutual authentication, it may be possible for a rogue 495 AP to fool the MN into sending an FBU to the PAR when it is not in 496 its best interest to do so. 498 Note that step 6 from Section 4 installs layer-2 forwarding state 499 that can redirect user traffic and cause disruption of service if 500 they can be triggered by malicious nodes. 502 Note that step 3 from Section 4 could potentially provide some 503 security; however, due to the identified weaknesses in WEP shared key 504 security [9] this should not be relied upon. Instead, the Robust 505 Security Network [6] will require the STA to undergo 802.1X Port- 506 Based Network Access Control [5] before proceeding to steps 5 or 6. 507 802.1X defines a way to encapsulate EAP on 802 networks (EAPOL, for 508 "EAP over LANs"). With this method, the client and AP participate in 509 an EAP exchange which itself can encapsulate any of the various EAP 510 authentication methods. The EAPOL exchange can output a Master 511 Session Key (MSK) and Extended Master Session Key (EMSK), which can 512 then be used to derive transient keys, which in turn can be used to 513 encrypt/authenticate subsequent traffic. It is possible to use 514 802.1X pre-authentication [6] between a STA and a target AP while the 515 STA is associated with another AP; this would enable authentication 516 to be done in advance of handover, which would allow faster 517 resumption of service after roaming. However, because EAPOL frames 518 carry only MAC-layer instead of IP-layer addresses, this is currently 519 only specified to work within a single VLAN, where IP layer handover 520 mechanisms are not necessarily needed anyway. In the most 521 interesting case for FMIPv6 (roaming across subnet boundaries) the 522 802.11 Fast Handover February 2005 524 802.1X exchange would need to be performed after handover to the new 525 AP. This would introduce additional handover delay while the 802.1X 526 exchange takes place, which may also involve round-trips to RADIUS or 527 Diameter servers. The EAP exchange could be avoided if a pre- 528 existing Pairwise Master Key (PMK) is found between the STA and the 529 AP, which may be the case if the STA has previously visited that AP 530 or one that shares a common back-end infrastructure. 532 Perhaps faster cross-subnet authentication could be achieved with the 533 use of pre-authentication using an IP-layer mechanism that could 534 cross subnet boundaries. To our knowledge this sort of work is not 535 currently underway in the IEEE. The security considerations of these 536 new approaches would need to be carefully studied. 538 9. Conclusions 540 The Mobile IPv6 Fast Handover specification presents a protocol for 541 shortening the period of service interruption during a change in 542 link-layer point of attachment. This document attempts to show how 543 this protocol may be applied in the context of 802.11 access 544 networks. 546 Implementation of FMIPv6 must be done in the context of a particular 547 link layer implementation, which must provide the triggers for the 548 FMIPv6 message flows. For example, the host must be notified of such 549 events as degradation of signal strength or attachment to a new AP. 551 The particular implementation of the 802.11 hardware and firmware may 552 dictate how FMIPv6 is able to operate. For example, to execute a 553 predictive handover, the scan request primitive must be available to 554 the host and the firmware must execute join operations only under 555 host control [10], not autonomously in response to its own handover 556 criteria. Obtaining the desired PrRtAdv and sending an FBU 557 immediately prior to handover requires that messages be exchanged 558 over the wireless link during a period when connectivity is 559 degrading. In some cases the scenario given in Section 7.1 may not 560 complete successfully or the FBU may redirect traffic to the wrong 561 NAR. However, in these cases the handover may devolve to the 562 scenario from Section 7.2 or the scenario from Section 7.3. 563 Ultimately, falling back to basic Mobile IPv6 operation [7] and 564 sending a Binding Update directly to the Home Agent can be used to 565 recover from any failure of the FMIPv6 protocol. 567 802.11 Fast Handover February 2005 569 10. References 571 10.1 Normative References 573 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 574 Levels", BCP 14, RFC 2119, March 1997. 576 [2] Koodli, R. (editor), "Fast Handovers for Mobile IPv6", draft- 577 ietf-mipshop-fast-mipv6-02.txt, July 2004. Work In Progress. 579 [3] "Wireless LAN Medium Access Control (MAC) and Physical Layer 580 (PHY) Specifications", ANSI/IEEE Std 802.11, 1999 Edition. 582 [4] Bahl, P., Bahl, P., and Chandra, R., "MultiNet: Enabling 583 Simultaneous Connections to Multiple Wireless Networks Using a 584 Single Radio", Microsoft Tech Report, MSR-TR-2003-46, June 585 2003. 587 [5] "Port-Based Network Access Control", IEEE Std 802.1X-2004, July 588 2004. 590 [6] "Medium Access Control (MAC) Security Enhancements", IEEE Std 591 802.11i-2004, July 2004. 593 [7] Johnson, D., Perkins, C., and Arkko, J., "Mobility Support in 594 IPv6", RFC 3775, June 2004. 596 10.2 Informative References 598 [8] Mitra, A., Shin, M., and Arbaugh, W., "An Empirical Analysis of 599 the IEEE 802.11 MAC Layer Handoff Process", CS-TR-4395, 600 University of Maryland Department of Computer Science, 601 September 2002. 603 [9] Borisov, N., Goldberg, I., and Wagner, D., "Intercepting Mobile 604 Communications: The Insecurity of 802.11", Proceedings of the 605 Seventh Annual International Conference on Mobile Computing and 606 Networking, July 2001, pp. 180-188. 608 [10] Malinen, J., "Host AP driver for Intersil Prism2/2.5/3 and WPA 609 Supplicant", http://hostap.epitest.fi/, July 2004. 611 802.11 Fast Handover February 2005 613 11. Acknowledgments 615 Thanks to Bob O'Hara for providing explanation and insight on the 616 802.11 standards. Thanks to James Kempf, Erik Anderlind, Rajeev 617 Koodli, and Bernard Aboba for providing comments on earlier drafts. 619 12. Author's Address 621 Pete McCann 622 Lucent Technologies 623 Rm 9C-226R 624 1960 Lucent Lane 625 Naperville, IL 60563 626 Phone: +1 630 713 9359 627 Fax: +1 630 713 1921 628 Email: mccap@lucent.com 629 802.11 Fast Handover February 2005 631 Full Copyright Statement 633 Copyright (C) The Internet Society (2005). This document is subject 634 to the rights, licenses and restrictions contained in BCP 78, and 635 except as set forth therein, the authors retain all their rights. 637 This document and the information contained herein are provided on an 638 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 639 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 640 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 641 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 642 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 643 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 645 Intellectual Property 647 At the time of submission the author is not aware of any intellectual 648 property rights that pertain to the implementation or use of the 649 technology described in this document. However, this does not 650 preclude the possibility that Lucent Technologies, Inc. or other 651 entities may have such rights. The patent licensing policy of Lucent 652 Technologies, Inc. is on file with the IETF Secretariat. 654 The IETF takes no position regarding the validity or scope of any 655 Intellectual Property Rights or other rights that might be claimed to 656 pertain to the implementation or use of the technology described in 657 this document or the extent to which any license under such rights 658 might or might not be available; nor does it represent that it has 659 made any independent effort to identify any such rights. Information 660 on the procedures with respect to rights in RFC documents can be 661 found in BCP 78 and BCP 79. 663 Copies of IPR disclosures made to the IETF Secretariat and any 664 assurances of licenses to be made available, or the result of an 665 attempt made to obtain a general license or permission for the use of 666 such proprietary rights by implementers or users of this 667 specification can be obtained from the IETF on-line IPR repository at 668 http://www.ietf.org/ipr. 670 The IETF invites any interested party to bring to its attention any 671 copyrights, patents or patent applications, or other proprietary 672 rights that may cover technology that may be required to implement 673 this standard. Please address the information to the IETF at ietf- 674 ipr@ietf.org. 676 802.11 Fast Handover February 2005 678 Acknowledgement 680 Funding for the RFC Editor function is currently provided by the 681 Internet Society.