idnits 2.17.1 draft-mccann-mobileip-80211fh-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: ---------------------------------------------------------------------------- == 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([2], [3]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. 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 (October 2002) is 7863 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '1' on line 13 looks like a reference -- Missing reference section? '2' on line 106 looks like a reference -- Missing reference section? '3' on line 301 looks like a reference -- Missing reference section? '4' on line 40 looks like a reference -- Missing reference section? '5' on line 71 looks like a reference -- Missing reference section? '6' on line 227 looks like a reference -- Missing reference section? '7' on line 400 looks like a reference -- Missing reference section? '8' on line 438 looks like a reference -- Missing reference section? '9' on line 456 looks like a reference -- Missing reference section? '10' on line 447 looks like a reference -- Missing reference section? '11' on line 462 looks like a reference -- Missing reference section? '12' on line 478 looks like a reference -- Missing reference section? '13' on line 501 looks like a reference Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 15 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Mobile IP 3 Internet Draft P. McCann 4 Document: draft-mccann-mobileip-80211fh-01.txt Lucent Technologies 5 Expires: April 2003 October 2002 7 Mobile IPv6 Fast Handovers for 802.11 Networks 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026 [1]. 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 [2] could be 32 implemented on a link layers conforming to the 802.11 suite of 33 specifications [3]. 35 Conventions used in this document 37 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 38 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 39 document are to be interpreted as described in RFC-2119 [4]. 41 Table of Contents 43 1. Introduction...................................................2 44 2. Terminology....................................................3 45 3. Deployment Architectures for Mobile IPv6 on 802.11.............4 46 4. 802.11 Handovers in Detail.....................................5 47 802.11 Fast Handover October 2002 49 5. Anticipated Handover...........................................7 50 6. Tunnel-based Handover..........................................8 51 7. Security Considerations........................................9 52 8. Conclusions...................................................10 53 References.......................................................12 54 Acknowledgments..................................................13 55 Author's Address.................................................13 57 1. Introduction 59 The Mobile IPv6 Fast Handover protocol [2] has been proposed as a way 60 to minimize the interruption in service experienced by a Mobile IPv6 61 node as it changes its point of attachment to the Internet. Without 62 such a mechanism, a mobile node cannot send or receive packets from 63 the time that it disconnects from one point of attachment in one 64 subnet to the time it registers a new care-of address from the new 65 point of attachment in a new subnet. Such an interruption would be 66 unacceptable for real-time services such as Voice-over-IP. 68 Note that there may be other sources of service interruption that may 69 be "built-in" to the link-layer handoff. For example, a recent study 70 has concluded that the 802.11 beacon scanning function may take 71 several hundred milliseconds to complete [5] during which time 72 sending and receiving IP packets is not possible. This sort of 73 interruption may present an obstacle to real-time service deployment 74 that needs further optimization; however, such optimization is 75 outside the scope of this document. 77 The basic idea behind a Mobile IPv6 fast handover is to leverage 78 information from the link-layer technology to either predict or 79 rapidly respond to a handover event. This allows IP connectivity to 80 be restored at the new point of attachment sooner than would 81 otherwise be possible. By tunneling data between the old and new 82 access routers, it is possible to provide IP connectivity in advance 83 of actual Mobile IP registration with the home agent or correspondent 84 node. This removes such Mobile IP registration, which may require 85 time-consuming Internet round-trips, from the critical path before 86 real-time service is re-established. 88 The particular link-layer information available, as well as the 89 timing of its availability (before, during, or after a handover has 90 occurred), differs according to the particular link-layer technology 91 in use. This document gives a set of deployment examples for Mobile 92 IPv6 Fast Handovers on 802.11 networks. We begin with a brief 93 overview of relevant aspects of basic 802.11 [3]. We examine how and 94 when handover information might become available to the IP layers 95 that implement Fast Handover, both in the network infrastructure and 96 on the mobile node. Finally, we give details on how the proposed 97 802.11 Fast Handover October 2002 99 Mobile IPv6 Fast Handover protocol would work in this environment and 100 evaluate the feasibility of the different IP-layer fast handover 101 mechanisms available. 103 2. Terminology 105 This document borrows all of the terminology from Mobile IPv6 Fast 106 Handovers [2], with the following additional terms from the 802.11 107 specification [3] (some definitions slightly modified for clarity): 109 Access Point (AP): Any entity that has station functionality and 110 provides access to the distribution services, via the 111 wireless medium (WM) for associated stations. 113 Association: The service used to establish access point/station 114 (AP/STA) mapping and enable STA access to the 115 Distribution System. 117 Basic Service Set (BSS): A set of stations controlled by a single 118 coordination function, where the coordination 119 function may be centralized (e.g., in a single AP) or 120 distributed (e.g., for an ad-hoc network). The BSS 121 can be thought of as the coverage area of a single 122 AP. 124 Distribution System (DS): A system used to interconnect a set of 125 basic service sets (BSSs) and integrated local area 126 networks (LANs) to create an extended service set 127 (ESS). 129 Extended Service Set (ESS): A set of one or more interconnected 130 basic service sets (BSSs) and integrated local area 131 networks (LANs) that appears as a single BSS to the 132 logical link control layer at any station associated 133 with one of those BSSs. The ESS can be thought of as 134 the coverage area provided by a collection of APs all 135 interconnected by the Distribution System. It may 136 consist of one or more IP subnets. 138 Inter-Access Point Protocol (IAPP): A protocol defined for use 139 between access points [6] at handover time that 140 allows for the old association with the old AP to be 141 deleted, and for context to be transferred to the new 142 AP. 144 Station (STA): Any device that contains an IEEE 802.11 conformant 145 medium access control (MAC) and physical layer (PHY) 146 interface to the wireless medium (WM). 148 802.11 Fast Handover October 2002 150 3. Deployment Architectures for Mobile IPv6 on 802.11 152 In this section we describe the two most likely relationships between 153 Access Points (APs), Access Routers (ARs), and IP subnets that are 154 possible in an 802.11 network deployment. Here we consider only the 155 infrastructure mode [3] of 802.11. A given STA may be associated 156 with one and only one AP at any given point in time; when a STA moves 157 out of the coverage area of a given AP it must handover (re- 158 associate) with a new AP. It is important to understand that 802.11 159 offers great flexibility, and that handover from one AP to another 160 does not necessarily mean a change of AR or subnet. 162 AR AR 163 AR | AR AR | AR 164 \ | / \ | / 165 Subnet 1 Subnet 2 166 / / | \ \ / / | \ \ 167 / / | \ \ / / | \ \ 168 / | | | \ / | | | \ 169 AP1 AP2 AP3 AP4 AP5 AP6 AP7 AP8 AP9 AP10 171 Figure 1: An 802.11 deployment with relay APs. 173 Figure 1 depicts a typical 802.11 deployment with two IP subnets, 174 each with three Access Routers and five Access Points. Note that the 175 APs in this figure are acting as link-layer relays, which means that 176 they transport Ethernet-layer frames between the wireless medium and 177 the subnet. Each subnet is implemented as a single LAN or VLAN. 178 Note that a handover from AP1 to AP2 does not require a change of AR 179 because all three ARs are link-layer reachable from a STA connected 180 to any AP1-5. Therefore, such handoffs are outside the scope of IP- 181 layer handover mechanisms. However, a handoff from AP5 to AP6 would 182 require a change of AR, because the STA would be attaching to a 183 different subnet. An IP-layer handover mechanism would need to be 184 invoked in order to provide low-interruption handover between the two 185 ARs. 187 Internet 188 / | \ 189 / | \ 190 / | \ 191 AR AR AR 192 AP1 AP2 AP3 193 802.11 Fast Handover October 2002 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. In this case, every change of AP 199 would result in a necessary change of AR, which would require some 200 IP-layer handover mechanism to provide for low-interruption handover 201 between the ARs. Also, the AR shares a MAC-layer identifier with its 202 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 1. The STA performs a scan to see what APs are available. The 216 result of the scan is a list of APs together with physical layer 217 information, such as signal strength. 218 2. The STA chooses one of the APs and performs a join to 219 synchronize its physical and MAC layer timing parameters with 220 the selected AP. 221 3. The STA requests authentication with the new AP. For an "Open 222 System", such authentication is a single round-trip message 223 exchange with null authentication. 224 4. The STA requests association or re-association with the new AP. 225 A re-association request contains the MAC-layer address of the 226 old AP, while a plain association request does not. 227 5. If operating in accordance with the IAPP [6], the new AP 228 performs a lookup based on MAC-layer address to obtain the IP 229 address of the old AP by consulting a local table or RADIUS 230 server. It opens a UDP or TCP connection, protected by IPSec 231 encryption, to the old AP. Via the secure connection, it 232 informs the old AP of the re-association so that information 233 about the STA is deleted from the old AP. Note that IAPP can 234 only be invoked based on a re-association message, as the plain 235 association message does not contain the old AP's MAC-layer 236 address. 237 6. The new AP sends a Layer 2 Update frame on the local LAN segment 238 to update the learning tables of any connected Ethernet bridges. 240 802.11 Fast Handover October 2002 242 Note that in most existing 802.11 implementations, steps 1-4 are 243 performed by firmware that is on-board the 802.11 PCMCIA card. This 244 might make it impossible for the host to take any actions (including 245 sending or receiving IP packets) before the handoff is complete. 247 During step 5, IAPP is used to communicate with the old AP. The 248 IPSec tunnel between the two APs is originally established with key 249 distribution via RADIUS, but can be subsequently re-used for 250 different MNs that may need to handover between the same pair of APs. 251 Note that the SA is between the pair of APs and has nothing to do 252 with any security association that might be in place between the MN 253 and either of the APs. During IAPP operation, link-layer context may 254 be transferred from the old AP to the new AP. The IAPP defines a 255 container for context information. However, no such context has 256 currently been defined or standardized by IEEE. 258 Also note that there is no guarantee that an AP found during step 1 259 will be available during step 2 because radio conditions can change 260 dramatically from moment to moment. The STA may then decide to 261 associate with a completely different AP. Usually, this decision is 262 implemented in firmware and the attached host would have no control 263 over which AP is chosen. 265 There is no standardized trigger for step 1. It may be performed as 266 a result of decaying radio conditions on the current AP or at other 267 times as determined by local implementation decisions. Usually this 268 step will be performed autonomously by firmware in the NIC using 269 proprietary scanning algorithms. 271 The coverage area of a single AP is known as a Basic Service Set 272 (BSS). Note that both APs in the above description are considered to 273 belong to the same Extended Service Set (ESS). This is to trigger a 274 re-association (rather than plain association) from the STA, which 275 contains information about both the old and new AP. All APs should 276 therefore broadcast the same ESSID. If two APs belong to different 277 administrative domains, this may require some inter-domain 278 coordination of the ESSID. Otherwise, there may not be sufficient 279 information to construct the link-layer triggers required by some 280 handover mechanisms. 282 A change of BSS within an ESS may or may not require an IP-layer 283 handover, depending on whether the APs provide STAs access to 284 different or the same IP subnets. The next two sections detail how 285 each mechanism from the Mobile IPv6 Fast Handover specification might 286 accomplish the necessary IP-layer reconfiguration. First we consider 287 Anticipated handover and then move on to Tunnel-based handover. 289 802.11 Fast Handover October 2002 291 5. Anticipated Handover 293 Because all 802.11 handovers are mobile initiated, the network- 294 initiated Anticipated Handover is not applicable to 802.11. 296 In mobile initiated Anticipated Handover, the MN first sends a Router 297 Solicitation for Proxy (RtSolPr) to the oAR containing the link-layer 298 address of the new Access Point. This would happen between steps 1 299 and 2 from Section 4. Note that for this to be possible, the MLME- 300 SCAN.request primitive (See Section 10.3.2.1 of the 802.11 301 specification [3]) must be available to the host, and the card 302 firmware must not make autonomous handover decisions. The oAR maps 303 the new AP's link-layer address into the IP address of the nAR that 304 should be used by the MN on the new link. Note that this requires a 305 mapping table to be maintained at oAR, either by manual configuration 306 or with the use of unspecified discovery protocols. Then, the oAR 307 determines whether stateful or stateless addressing is used by nAR. 308 For stateless addresses, the oAR picks an nCoA on the new subnet 309 (using the MN's interface identifier) and proposes it to the nAR 310 using HI/HACK. For stateful addresses, the oAR must request an 311 address from nAR with the HI/HACK exchange. The oAR returns a Proxy 312 Router Advertisement (PrRtAdv) to the MN. This PrRtAdv may be sent 313 in parallel with HI/HACK, in the case of stateless address 314 configuration, but must be serialized after HI/HACK in the case of 315 stateful address configuration. The MN then sends a Fast Binding 316 Update (F-BU) to the oAR with a binding to the new care-of address 317 (nCoA). 319 At this point the MN should move to nAR (steps 2-6 from Section 4). 320 Note that here we assume the host can send IP layer messages such as 321 F-BU prior to step 2, which implies that the interface firmware did 322 not autonomously skip to step 2 without permission from the host. 323 Once re-associated with the new AP, the MN will hopefully receive the 324 F-BACK indicating that the oAR received its F-BU and also that the 325 nCoA is valid. This message is sent on both the old and new links 326 because the MN is in transit between them. Packets from the oAR will 327 be forwarded to nAR based on the F-BU. If it doesn't receive the F- 328 BACK right away, the MN retransmits the F-BU and indicates its 329 presence to the nAR with a Fast Neighbor Advertisement (F-NA). The 330 nAR should return a Router Advertisement containing a Neighbor 331 Advertisement Acknowledgement (NAACK) indicating whether the nCoA is 332 valid. If not, the MN can continue to use oCoA as a source address 333 for packets while it obtains a valid nCoA. Either the F-BACK or the 334 Router Advertisement informs the MN which link-layer address to use 335 as its default router on subsequent outbound packets. 337 Note that Anticipated Handover requires that the MN send a RtSolPr 338 and receive a PrRtAdv prior to executing the layer-two handover. 339 Otherwise, the MN will not have any information about the new subnet, 340 802.11 Fast Handover October 2002 342 and will need to begin neighbor discovery and care-of address 343 configuration from scratch once it has completed the layer-two 344 handover. There is no guarantee that the RtSolPr/PrRtAdv exchange 345 will complete especially in a radio environment where the connection 346 to the old AP is deteriorating rapidly. Also, there is no guarantee 347 that the MN will actually attach to the given new AP after it has 348 sent the F-BU to the oAR, because changing radio conditions may cause 349 nAR to be suddenly unreachable. The precise impact of these factors 350 in an Anticipated Handover can only be evaluated after 351 experimentation in a particular deployment. 353 6. Tunnel-based Handover 355 In a Tunnel-based Handover, the oAR and nAR collaborate to establish 356 a bi-directional edge tunnel (BET) in reaction to a layer-2 handover 357 event. In an 802.11 network, this event would be step 4 from 358 Section 4 (target trigger) or perhaps step 5 at the old AP (source 359 trigger). If the network looks like Figure 2, where the APs are 360 integrated with the ARs, then the L2-TT (or L2-ST) is available at 361 nAR (or oAR) through some internal interface. However, if the 362 network is deployed like Figure 1, then some network message will 363 need to be sent from the new AP (or old AP) to nAR (or oAR). This 364 message might be the object of future standardization efforts. Note 365 also that there may be several ARs present on the new subnet, and the 366 new AP must choose one to which to deliver the trigger, which becomes 367 nAR. The Layer 2 Update frame sent by the new AP might be of some 368 assistance in constructing L2-TT; however, this message is broadcast 369 to all ARs on the new subnet and does not indicate which one is to be 370 chosen as the endpoint of the tunnel. Also, it does not contain the 371 MAC address of the old AP that would enable discovery of oAR. 373 The AR that received the trigger sends a HI message to the other AR, 374 who in turn responds with a HACK. Note that this requires a mapping 375 table to be maintained, similar to the one for Anticipated handover, 376 which yields the IP address of an AR given the link-layer address of 377 an AP. This table must be maintained manually or with the aid of 378 some unspecified discovery protocol. The re-association provides L2- 379 LD and L2-LU triggers to oAR and nAR, respectively. At this point 380 the BET is established and traffic is tunneled between the two ARs so 381 that the MN continues to receive service, using oCoA, without the 382 need to exchange any messages immediately before, during, or 383 immediately after the handoff. At some future time, the MN may 384 obtain an nCoA and register from the new network, perhaps using 385 completely standard Mobile IPv6 mechanisms to do movement detection 386 and registration. 388 Note that the MN must somehow obtain the link-layer address of nAR 389 before service can resume, so that it has a link-layer destination 390 802.11 Fast Handover October 2002 392 address for outgoing packets (default router information). In the 393 deployment illustrated in Figure 2, this would be exactly the AP's 394 MAC layer address, which can be learned from the link-layer handoff 395 messages. However, in the case of Figure 1, this information must be 396 learned through other means currently unspecified. Also note that 397 even in the case of Figure 2, the MN must somehow be made aware that 398 it is in fact operating in a Figure 2 network and not a Figure 1 399 network. One option might be the Candidate Access Router (CAR) 400 discovery protocol [7] currently being worked in the Seamoby working 401 group. Interestingly, this information is also available from the 402 PrRtAdv message, although its use is currently prohibited in tunnel- 403 based handover. A MN could conceivably obtain advertisements from 404 all neighboring APs well in advance of the handover, even if it 405 intended to use a Tunnel-Based instead of Anticipated handover. 407 Note that the BET is established at the behest of layer-2 messages. 408 Because this is a redirection of the MN's traffic, care must be taken 409 to ensure that the layer-2 messages are secure. This issue is 410 discussed in more detail in Section 7. 412 For now we do not discuss the Handoff to Third (HTT) mechanism of a 413 Tunnel-based handover. Its configuration and security implications 414 are similar to the basic scheme. 416 7. Security Considerations 418 As stated in the Mobile IPv6 fast handover specification, the 419 security considerations of Anticipated Handover are very similar to 420 those required of any Mobile IPv6 Binding Update message. The oAR 421 and MN are assumed to have a security association for the Binding 422 Updates, which also provides authentic PrRtAdv messages to the MN. 423 However, creating such a security association for a roaming MN is 424 still an open problem. Also, security must be established between 425 all possible (oAR, nAR) pairs so that PrRtAdv/HI/HACK messages may be 426 authenticated. This might be achieved through manual configuration 427 or automatic discovery, using whatever means was used to set up the 428 mapping table discussed in Section 5. 430 Similar to Anticipated handover, Tunnel-based handover also requires 431 a secure means to establish neighbor-mapping tables, so that tunnels 432 can be established securely between oAR and nAR based on the L2 433 triggers. In addition, the security of a Tunnel-based handover 434 depends on the link-layer security in place. This is because a BET 435 is established and MN traffic is redirected purely in reaction to 436 link-layer handoff messages. Note that step 3 from Section 4 could 437 potentially provide some security; however, due to the identified 438 weaknesses in WEP shared key security [8], there is currently no 439 802.11 Fast Handover October 2002 441 authentication algorithm for step 3 that is both standardized and 442 secure. 444 It may be the case that many deployments are configured as "Open 445 Systems", which will rely instead on higher-layer authentication such 446 as 802.1X Port-Based Network Access Control [9], or, ultimately, the 447 future output of the PANA working group [10]. According to published 448 standards, such authentication techniques would happen only after 449 association or re-association takes place, which leaves the re- 450 association messages unprotected. This would allow malicious nodes 451 to redirect traffic to a different subnet in a Tunnel-based handover 452 environment, or to a different AP on the same subnet even in an 453 Anticipated handover environment. Work is currently underway to 454 better integrate 802.1X with 802.11 [11] but it is not yet complete. 456 The 802.1X standard [9] defines a way to encapsulate EAP on 802 457 networks (EAPOL, for "EAP over LANs"). With this method, the client 458 and AP participate in an EAP exchange which itself can encapsulate 459 any of the various EAP authentication methods. The EAPOL exchange 460 can output a master key, which can then be used to derive transient 461 keys, which in turn can be used to encipher/authenticate subsequent 462 traffic. It is possible to use 802.1X pre-authentication [11] 463 between a STA and a target AP while the STA is associated with 464 another AP; this would enable authentication to be done in advance of 465 handover, which would both protect the re-association message and 466 allow fast resumption of service after roaming. However, because 467 EAPOL frames carry only MAC-layer instead of IP-layer addresses, this 468 is currently only specified to work within a single subnet, where IP 469 layer handoff mechanisms are not needed anyway. In our case (roaming 470 across subnet boundaries) the 802.1X exchange would need to be 471 performed after roaming to, but prior to re-association with, the new 472 AP. This would introduce additional handover delay while the 802.1X 473 exchange takes place, which may also involve round-trips to RADIUS or 474 Diameter servers. 476 Perhaps faster cross-subnet authentication could be achieved by 477 leveraging the context transfer features of the IAPP to carry 478 security credentials [12], or with the use of pre-authentication 479 using PANA. To our knowledge this sort of work is not currently 480 underway in the IEEE. The security considerations of these new 481 approaches would need to be carefully studied. 483 8. Conclusions 485 The Mobile IPv6 Fast Handoff specification presents two alternative 486 protocols for shortening the period of service interruption during a 487 change in link-layer point of attachment. This document has 488 802.11 Fast Handover October 2002 490 attempted to show how each may be applied in the context of 802.11 491 access networks. 493 There are currently serious security problems in the published 494 specifications that define the 802.11 handover process that must be 495 fixed before even intra-subnet mobility can be considered secure. 496 Tunnel-based handovers would depend on these mechanisms to secure 497 cross-subnet mobility. In-progress specifications may fix these 498 problems but may also introduce additional delay for handover across 499 different subnets. Usually, only the APs themselves are aware that 500 good link-layer security is in place. This information could be made 501 available to ARs with the use of a new protocol (e.g., [13]), but as 502 such mechanisms are prone to be link-layer specific, we recommend 503 that work on Tunnel-based handovers be progressed in the IEEE rather 504 than the IETF. 506 Anticipated handover places requirements that messages be exchanged 507 over the wireless link prior to handover, during a period that is 508 normally under the control of low-level firmware. The performance 509 impact of this requirement, and of the failure to meet it in certain 510 radio conditions, must be critically evaluated with experimental 511 data. Also, given a particular firmware implementation of handover, 512 it may be impossible for a host to send the required IP-layer 513 messages at the proper time. 515 Both schemes rely on unspecified mechanisms for mapping AP L2 516 addresses into AR IP addresses (Anticipated and Tunnel-based) or AR 517 L2 addresses (Tunnel-based). This problem is arguably more severe 518 with Tunnel-based handovers, especially on networks like Figure 1, 519 because the MN itself does the unspecified mapping and it cannot be 520 handled by manual configuration. In Anticipated handover, the oAR 521 must be configured with this information so that it can send the 522 proper PrRtAdv to the MN. 524 The relationship between the PrRtAdv and Candidate Access Router 525 discovery protocols needs further study. Some similar functionality 526 seems to be provided by each and it may not be necessary to 527 standardize both mechanisms independently. 529 For these reasons, we recommend that the draft be refocused to 530 concentrate on the specification and security considerations for the 531 F-BU and F-BACK messages only. This allows for updating the oAR with 532 the current MN location under any circumstance, whether the handover 533 is anticipated or not. The other mechanisms outlined in the draft 534 either need more support from the link layer, and should be moved 535 into the IEEE, or require further study to determine their 536 relationship with other work in the IETF. 538 802.11 Fast Handover October 2002 540 References 542 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 543 9, RFC 2026, October 1996. 545 2 Dommety, G. (editor), Yegin, A., Perkins, C., Tsirtsis, G., El- 546 Malki, K., and Khalil, K., "Fast Handovers for Mobile IPv6", 547 draft-ietf-mobileip-fast-mipv6-04.txt, March 2002. Work In 548 Progress. 550 3 "Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) 551 Specifications", ANSI/IEEE Std 802.11, 1999 Edition. 553 4 Bradner, S., "Key words for use in RFCs to Indicate Requirement 554 Levels", BCP 14, RFC 2119, March 1997. 556 5 Mitra, A., Shin, M., and Arbaugh, W., "An Empirical Analysis of 557 the IEEE 802.11 MAC Layer Handoff Process", CS-TR-4395, University 558 of Maryland Department of Computer Science, September 2002. 560 6 "Recommended Practice for Multi-Vendor Access Point 561 Interoperability via an Inter-Access Point Protocol Across 562 Distribution Systems Supporting IEEE 802.11 Operation", IEEE Std 563 802.11f/D4, July 2002. Work In Progress. 565 7 Krishnamurthi, G. (editor), "Requirements for CAR Discovery 566 Protocols", draft-ietf-seamoby-card-requirements-01.txt, August, 567 2002. Work In Progress. 569 8 Borisov, N., Goldberg, I., and Wagner, D., "Intercepting Mobile 570 Communications: The Insecurity of 802.11", Proceedings of the 571 Seventh Annual International Conference on Mobile Computing and 572 Networking, July 2001, pp. 180-188. 574 9 "Port-Based Network Access Control", IEEE Std 802.1X-2001, 575 October, 2001. 577 10 Penno, R. (editor), Yegin, A., Ohba, Y., Tsirtsis, G, and Wang, 578 C., "Protocol for Carrying Authentication for Network Access 579 (PANA) Requriements and Terminology", draft-ietf-pana- 580 requirements-02.txt, June 2002. Work In Progress. 582 11 "Draft Supplement to IEEE 802.11: Specification for Enhanced 583 Security", IEEE Std 802.11i/D2.2, July 2002. Work In Progress. 585 802.11 Fast Handover October 2002 587 12 Aboba, B., and Moore, T., "A Model for Context Transfer in IEEE 588 802", draft-aboba-802-context-02.txt, April, 2002. Work In 589 Progress. 591 13 Yegin, A., "Link-layer Triggers Protocol", draft-yegin-l2- 592 triggers-00.txt, June 2002. Work In Progress. 594 Acknowledgments 596 Thanks to Bob O'Hara for providing explanation and insight on the 597 802.11 standards. Thanks to James Kempf and Erik Anderlind for 598 providing comments on an earlier draft. 600 Author's Address 602 Pete McCann 603 Lucent Technologies 604 Rm 9C-226R 605 1960 Lucent Lane 606 Naperville, IL 60563 607 Phone: +1 630 713 9359 608 Fax: +1 630 713 1921 609 Email: mccap@lucent.com 611 Intellectual Property Statement 613 At the time of submission the author is not aware of any intellectual 614 property rights that pertain to the implementation or use of the 615 technology described in this document. However, this does not 616 preclude the possibility that Lucent Technologies, Inc. or other 617 entities may have such rights. The patent licensing policy of Lucent 618 Technologies, Inc. is on file with the IETF Secretariat. 620 The IETF takes no position regarding the validity or scope of any 621 intellectual property or other rights that might be claimed to 622 pertain to the implementation or use of the technology described in 623 this document or the extent to which any license under such rights 624 might or might not be available; neither does it represent that it 625 has made any effort to identify any such rights. Information on the 626 IETF's procedures with respect to rights in standards-track and 627 standards-related documentation can be found in BCP-11. Copies of 628 claims of rights made available for publication and any assurances of 629 licenses to be made available, or the result of an attempt made to 630 obtain a general license or permission for the use of such 631 802.11 Fast Handover October 2002 633 proprietary rights by implementers or users of this specification can 634 be obtained from the IETF Secretariat. 636 The IETF invites any interested party to bring to its attention any 637 copyrights, patents or patent applications, or other proprietary 638 rights, which may cover technology that may be required to practice 639 this standard. Please address the information to the IETF Executive 640 Director. 642 Full Copyright Statement 644 Copyright (C) The Internet Society (2002). All Rights Reserved. 646 This document and translations of it may be copied and furnished to 647 others, and derivative works that comment on or otherwise explain it 648 or assist in its implementation may be prepared, copied, published 649 and distributed, in whole or in part, without restriction of any 650 kind, provided that the above copyright notice and this paragraph are 651 included on all such copies and derivative works. However, this 652 document itself may not be modified in any way, such as by removing 653 the copyright notice or references to the Internet Society or other 654 Internet organizations, except as needed for the purpose of 655 developing Internet standards in which case the procedures for 656 copyrights defined in the Internet Standards process must be 657 followed, or as required to translate it into languages other than 658 English. 660 The limited permissions granted above are perpetual and will not be 661 revoked by the Internet Society or its successors or assigns. 663 This document and the information contained herein is provided on an 664 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 665 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 666 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 667 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 668 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.