idnits 2.17.1 draft-iab-link-indications-00.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 13. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1457. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 1463), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 35. ** 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 seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ( - It does however have an RFC 2026 Section 10.4(A) Disclaimer.) ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation -- however, there's a paragraph with a matching beginning. Boilerplate error? ( - It does however have an RFC 2026 Section 10.4(B) IPR Disclosure Invitation.) ** 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: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 31 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 32 pages 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 an Authors' Addresses Section. ** There are 3 instances of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 441 has weird spacing: '...link is usefu...' == Line 518 has weird spacing: '...s, from half ...' == Line 557 has weird spacing: '...lead to the d...' == Line 902 has weird spacing: '...ich the link ...' -- 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 (14 October 2004) is 7133 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC791' is defined on line 1223, but no explicit reference was found in the text == Unused Reference: 'RFC792' is defined on line 1226, but no explicit reference was found in the text == Unused Reference: 'RFC3748' is defined on line 1255, but no explicit reference was found in the text == Unused Reference: 'PPPIANA' is defined on line 1373, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 2861 (Obsoleted by RFC 7661) -- Obsolete informational reference (is this intentional?): RFC 3775 (Obsoleted by RFC 6275) -- Obsolete informational reference (is this intentional?): RFC 3921 (Obsoleted by RFC 6121) == Outdated reference: A later version (-13) exists of draft-ietf-dccp-spec-07 == Outdated reference: A later version (-18) exists of draft-ietf-dhc-dna-ipv4-08 == Outdated reference: A later version (-15) exists of draft-tschofenig-eap-ikev2-03 == Outdated reference: A later version (-02) exists of draft-eggert-tcpm-tcp-retransmit-now-00 == Outdated reference: A later version (-04) exists of draft-giaretta-mip6-authorization-eap-01 == Outdated reference: A later version (-10) exists of draft-josefsson-pppext-eap-tls-eap-09 == Outdated reference: A later version (-01) exists of draft-yegin-l2-triggers-00 Summary: 12 errors (**), 0 flaws (~~), 18 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B. Aboba, Ed. 3 INTERNET-DRAFT Internet Architecture Board 4 Category: Informational IAB 5 6 14 October 2004 8 Architectural Implications of Link Layer Indications 10 By submitting this Internet-Draft, I certify that any applicable 11 patent or other IPR claims of which I am aware have been disclosed, 12 and any of which I become aware will be disclosed, in accordance with 13 RFC 3668. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 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 to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on April 22, 2005. 33 Copyright Notice 35 Copyright (C) The Internet Society (2004). All Rights Reserved. 37 Abstract 38 As a performance optimization, proposals have been made for utilizing 39 link layer indications (also known as "triggers" or "hints") to 40 influence the behavior of the Internet, Transport or Application 41 layers. This document briefly summarizes current proposals and 42 describes architectural issues relating to link layer indications. 44 Table of Contents 46 1. Introduction.............................................. 3 47 1.1 Requirements ....................................... 3 48 1.2 Terminology ........................................ 3 49 1.3 Link Indications ................................... 5 50 1.4 Proposals .......................................... 6 51 1.5 Layering Model ..................................... 7 52 1.6 Link Behavior ...................................... 10 53 1.7 Implementation Differences ......................... 11 54 2. Architectural considerations ............................. 12 55 2.1 Model Validation ................................... 13 56 2.2 Robustness ......................................... 15 57 2.3 Effectiveness ...................................... 18 58 2.4 Interoperability Issues ............................ 19 59 2.5 Race Conditions .................................... 19 60 2.6 Layer Compression .................................. 23 61 2.7 Remoting Implications .............................. 24 62 2.8 Security Considerations ............................ 25 63 3. Future Work .............................................. 26 64 4. References ............................................... 27 65 4.1 Normative References ............................... 27 66 4.2 Informative References ............................. 27 67 Appendix A - IAB Members ..................................... 31 68 Intellectual Property Statement .............................. 31 69 Disclaimer of Validity ....................................... 31 70 Copyright Statement .......................................... 32 71 1. Introduction 73 As evidence mounts that correct utilization of link layer indications 74 can provide real benefits, and that incorrect utilization can degrade 75 performance, the importance of understanding the role of link 76 indications in the Internet architecture has grown in importance. 78 This document is an attempt to summarize current understanding of the 79 role of link layer indications, as well as to provide advice to 80 document authors considering the role of link layer indications 81 within their own work. 83 In Section 1 of this document we present a brief overview of current 84 proposals, as well as recent research on link behavior. Based on the 85 overview, Section 2 provides advice to document authors. Section 3 86 describes future work. 88 1.1. Requirements 90 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 91 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 92 document are to be interpreted as described in [RFC2119]. 94 1.2. Terminology 96 Access Point (AP) 97 A station that provides access to the distribution services, via 98 the wireless medium (WM) for associated stations. 100 Association 101 The service used to establish an access point/station (AP/STA) 102 mapping and enable STA access to the Distribution System. 104 Basic Service Set (BSS) 105 A set of stations controlled by a single coordination function, 106 where the coordination function may be centralized (e.g., in a 107 single AP) or distributed (e.g., for an ad-hoc network). The BSS 108 can be thought of as the coverage area of a single AP. 110 Care of Address (CoA) 111 A unicast routable address associated with a mobile node while 112 visiting a foreign link; the subnet prefix of this IP address is a 113 foreign subnet prefix. Among the multiple care-of addresses that a 114 mobile node may have at any given time (e.g., with different subnet 115 prefixes), the one registered with the mobile node's home agent for 116 a given home address is called its "primary" care-of address. 118 Correspondent Node 119 A peer node with which a mobile node is communicating. The 120 correspondent node may be either mobile or stationary. 122 Distribution System (DS) 123 A system used to interconnect a set of basic service sets (BSSs) 124 and integrated local area networks (LANs) to create an extended 125 service set (ESS). 127 Dynamic Host Configuration Protocol (DHCP) client 128 A DHCP client or "client" is an Internet host using DHCP [RFC2131] 129 to obtain configuration parameters such as a network address. 131 DHCP server 132 A DHCP server or "server" is an Internet host that returns 133 configuration parameters to DHCP clients. 135 Extended Service Set (ESS) 136 A set of one or more interconnected basic service sets (BSSs) and 137 integrated local area networks (LANs) that appears as a single BSS 138 to the logical link control layer at any station associated with 139 one of those BSSs. The ESS can be thought of as the coverage area 140 provided by a collection of APs all interconnected by the 141 Distribution System. It may consist of one or more IP subnets. 143 Home Address (HoA) 144 A unicast routable address assigned to a mobile node, used as the 145 permanent address of the mobile node. This address is within the 146 mobile node's home link. Standard IP routing mechanisms will 147 deliver packets destined for a mobile node's home address to its 148 home link. Mobile nodes can have multiple home addresses, for 149 instance when there are multiple home prefixes on the home link. 151 Inter-Access Point Protocol (IAPP) 152 A protocol used between access points that assures that the station 153 may only be connected to a single AP within the ESS at a time, and 154 also provides for transfer of context to the new AP. 156 Link A communication facility or medium over which nodes can communicate 157 at the link layer, such as an Ethernet (simple or bridged). The 158 link layer is the layer immediately below IP. 160 Link Indication 161 Information provided by the link layer to higher layers relating to 162 the state of the link. 164 Mobile Node 165 A node that can change its point of attachment from one link to 166 another, while still being reachable via its home address. 168 Point of Attachment 169 A location within the network where a host may be connected. This 170 attachment point can be characterized by its address prefix and 171 next hop routing information. 173 Most Likely Point of Attachment (MLPA) 174 The point of attachment heuristically determined by the host to be 175 most likely, based on hints from the network. 177 Routable address 178 In this specification, the term "routable address" refers to any 179 address other than an IPv4 Link-Local address. This includes 180 private addresses as specified in [RFC1918]. 182 Station (STA) 183 Any device that contains an IEEE 802.11 conformant medium access 184 control (MAC) and physical layer (PHY) interface to the wireless 185 medium (WM). 187 Valid address 188 The term "valid address" refers to either a static IPv4 address, or 189 an address assigned via DHCPv4 which has not been relinquished, and 190 whose lease has not yet expired. 192 Weak End-System Model 193 In the Weak End-System Model, packets sent out an interface need 194 not necessarily have a source address configured on that interface. 196 1.3. Link Indications 198 A link indication represents information provided by the link layer 199 to higher layers relating to the state of the link. 201 While link layer indications vary considerably between media, 202 abstraction models have been proposed. For example, [GenTrig] 203 defines "generic triggers", including "Link Up", "Link Down", "Link 204 Going Down", "Link Going Up", "Link Quality Crosses Threshold", 205 "Trigger Rollback", and "Better Signal Quality AP Available". Other 206 link indications include the current link rate (which may vary with 207 time and location), link identifiers (e.g. SSID, BSSID in 802.11), 208 and statistics relating to link performance (such as the delay or 209 loss rate). 211 Among the most commonly implemented link indications are the "Link 212 Up" and "Link Down" indications, which are based on an idealized link 213 behavior model originally developed for wired networks. This model 214 assumes that links in the "Up" state experience low frame loss in 215 both directions and are ready to send and receive IP data packets. 216 Similarly, it is assumed that a link that is in the "Down" state is 217 unsuitable for sending and receiving IP data packets in either 218 direction. 220 Link indications based on signal quality, such as "Link Doing Down", 221 "Link Going Up", and "Link Quality Crosses Threshold" are primarily 222 intended for use in handoff optimization. These indications assume 223 an idealized model of radio propagation, where signal strength varies 224 smoothly and frame loss is well predicted by signal strength and 225 distance. 227 1.4. Proposals 229 Within the Internet Layer, proposals have been made for utilizing 230 link layer indications to optimize IP configuration, to improve the 231 usefulness of routing metrics, and to optimize aspects of Mobile IP 232 handoff. 234 In "Detection of Network Attachment (DNA) in IPv4" [DNAv4], link 235 layer indications are utilized to optimize Internet layer 236 configuration. This enables a host that has moved to a new point of 237 attachment but remained within the same subnet to rapidly confirm a 238 currently valid configuration, rather than utilizing the DHCP 239 protocol [RFC2131]. 241 "A High-Throughput Path Metric for Multi-Hop Wireless Routing" [ETX] 242 describes how routing metrics can be improved by utilizing the 243 Expected Transmission Count (ETX) metric, which takes link layer loss 244 rates into account, enabling the selection of routes maximizing 245 available throughput. While the ETX metric did not take the 246 negotiated rate into account, this was noted as a subject for further 247 study. 249 In "L2 Triggers Optimized Mobile IPv6 Vertical Handover: The 250 802.11/GPRS Example" [Park] the authors propose that the mobile node 251 send a router solicitation on receipt of a "Link Up" indication in 252 order provide lower handoff latency than would be possible using 253 generic movement detection [RFC3775]. The authors also suggest 254 immediate invalidation of the Care-Of-Address (CoA) on receipt of a 255 "Link Down" indication. 257 Within the Transport Layer, proposals have focused on countering the 258 effects of handoff-induced packet loss. This includes proposals for 259 improving transport parameter estimation, as well as triggering 260 immediate retransmission on availability of an interface or 261 intervening link. 263 "Framework and Requirements for TRIGTRAN" [TRIGTRAN] discusses 264 optimizations to recover earlier from a retransmission timeout 265 incurred during a period in which an interface or intervening link 266 was down. 268 "Link-layer Triggers Protocol" [Yegin] describes transport issues 269 arising from lack of host awareness of link conditions on downstream 270 Access Points and routers. A link-layer trigger remoting is proposed 271 to address the issue. 273 In "TCP Extensions for Immediate Retransmissions" [Eggert], it is 274 proposed that in addition to regularly scheduled retransmissions that 275 retransmission be attempted by the transport layer on receipt of an 276 indication that connectivity to a peer node may have been restored. 277 End-to-end connectivity restoration indications include "Link Up", 278 confirmation of first-hop router reachability, confirmation of 279 Internet layer configuration, and receipt of other traffic from the 280 peer. 282 In "The BU-trigger method for improving TCP performance over Mobile 283 IPv6" [Kim], the authors note that handoff-related packet loss is 284 interpreted as congestion by the transport layer. In the case where 285 the correspondent node is sending to the mobile node, it is proposed 286 that receipt of a Binding Update by the correspondent node be used as 287 a signal to the transport layer to adjust cwnd and ssthresh values, 288 which may have been reduced due to handoff-induced packet loss. The 289 authors recommend that cwnd and ssthresh be recovered to pre-timeout 290 values, regardless of whether the link parameters have changed. The 291 paper does not discuss the behavior of a mobile node sending a 292 Binding Update, in the case where the mobile node is sending to the 293 correspondent node. 295 At the application layer, the usage of "Link Down" indications has 296 been proposed to augment presence systems. In such systems, client 297 devices periodically refresh their presence state using application 298 layer protocols such as SIMPLE [RFC3428] or XMPP [RFC3921]. If the 299 client should become disconnected, their unavailability will not be 300 detected until the presence status times out, which can take many 301 minutes. However, if a link goes down, and a disconnect indication 302 can be sent to the presence server (presumably by the access point, 303 which remains connected), the status of the user's communication 304 application can be updated nearly instantaneously. 306 1.5. Layering Model 308 A simplified layered indication model is shown in Figure 1. This 309 model includes both internally generated link indications as well as 310 Internet and Transport layer indications arising out of external 311 interactions (such as receipt of Mobile IP Binding Updates, and 312 detection of path changes via routing protocols and TTL changes). 314 In this model, link indications provided to higher layers include the 315 frame loss rate (before retransmissions), the current link rate, the 316 link state (up/down), and link identifiers. These link indications 317 are inter-dependent. For example, the rate adjustment and detection 318 algorithms are typically influenced by frame loss, and in turn, the 319 determination of a "Link Down" indication may be influenced by the 320 detection and search process. Link Identifiers are typically 321 obtained in the process of bringing the link to the "Up" state. 323 Link indications may be utilized by the Internet layer in order to 324 optimize aspects of IP configuration, routing and mobility. As noted 325 in [DNAv4], "Link Up" indications and link Identifiers may be useful 326 in validation of an existing IP configuration. Once the IP 327 configuration is confirmed, it may be determined that an IP address 328 change has occurred. 330 As described in [ETX], the frame loss rate as well as the current 331 link rate may be utilized in the calculation of routing metrics. 332 Within "Weak End-System Model" implementations, changes in routing 333 metrics may in turn result in a change in the outgoing interface for 334 one or more transport connections. Routes may also be added or 335 withdrawn, resulting in loss or gain of peer connectivity. The 336 Internet layer may also become aware of path changes, by other 337 mechanisms such as a change in the IP TTL of received packets. 339 A change in the outgoing interface may in turn influence the mobility 340 sub-layer if present, causing a change in the incoming interface. 341 The mobility sub-layer may also become aware of a change in the 342 incoming interface of a peer (via receipt of a Mobile IP binding 343 update). 345 Internet layer indications such as IP address and path changes are 346 provided to the Transport layer, which also receives Link layer 347 indications such as the loss rate, and "Link Up"/"Link Down". 349 Based on these Internet layer indications, the transport layer may 350 wish to modify transport parameter estimates (such as by reseting 351 parameter estimates of connections undergoing a path change), or tear 352 down transport connections (due to invalidation of a connection's 353 originating IP address). It is also possible for the transport layer 354 to utilize "Link Up"/"Link Down" indications, and Loss Rate 355 information to improve transport parameter estimates. However, the 356 required algorithms not well understood. 358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 359 Application | | 360 Layer | | 361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 362 ^ ^ ^ 363 | | | 364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 365 | | | | | | 366 | | + | | | 367 | ^ | ^ ^ | 368 Transport | Transport Parameter | + | Teardown | 369 Layer | Estimation | | | | 370 | (e.g. RTT, RTO, Reset) | + Conxn.| Management| 371 | | | | | 372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 373 ^ ^ ^ ^ ^ 374 | | | | | 375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 376 | | | Incoming | MIP | | | 377 | | | Interface | BU | | | 378 | | | Change |Receipt| | | 379 | ^ ^ ^ ^ ^ | 380 | | | | | | | 381 | | | | | | | 382 | | | Mobility | | | | 383 Internet | | | | | | | 384 Layer +-+- -+- - - - - -+- -+- -+- - - - -+- - - - - -+ 385 | | | Outgoing | | | | IP | 386 | | | Interface | + | | Address | 387 | ^ ^ Change ^ | ^ ^ Change | 388 | | Path + | | 389 | | Change | | | 390 | | Routing + | IP Configuration | 391 | | | | | 392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 393 ^ ^ ^ ^ 394 | | | | 395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 396 | | | | | | 397 Link | ^ ^ ^ ^ | 398 Layer + Frame -> Rate -> Link Link + 399 | Loss Adjustment Up/Down Identifiers | 400 | Rate | 401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 403 Figure 1. Layered Indication Model 405 In addition to Internet layer indications propagated to the 406 Application layer (such as IP address changes), the Transport layer 407 propagates its own indications, such as connection teardown. In most 408 cases applications can obtain the information they need from Internet 409 and Transport layer indications so that they do not need to directly 410 consume link indications. 412 1.6. Link Behavior 414 In order to understand the applicability of the layered indication 415 model it is instructive to review recent research relating to link 416 performance. 418 In "Measurement and Analysis of the Error Characteristics of an In- 419 Building Wireless Network" [Eckhardt], the authors characterize the 420 performance of an AT&T Wavelan 2 Mbps in-building WLAN operating in 421 Infrastructure mode on the Carnegie-Mellon Campus. In this study, 422 very low frame loss was experienced. As a result, links could either 423 be assumed to operate very well or not at all. 425 In "Performance of Multihop Wireless Networks: Shortest Path is Not 426 Enough" [Shortest] the authors studied the performance of both an 427 indoor and outdoor mesh network. By measuring inter-node throughput, 428 the best path between nodes was computed. The throughput of the best 429 path was compared with the throughput of the shortest path computed 430 based on a hop-count metric. In almost all cases, the shortest path 431 route offered considerably lower throughput than the best path. 433 In examining link behavior, the authors found that rather than 434 exhibiting a bi-modal distribution between "up" (low loss rate) and 435 "down" (high loss rates), many links exhibited intermediate loss 436 rates. Asymmetry was also common, with 30 percent of links 437 demonstrating substantial differences between in the loss rates in 438 each direction. As a result, on wireless networks the measured 439 throughput can differ substantially from the negotiated rate due to 440 retransmissions, and successful delivery of routing packets is not 441 necessarily an indication that the link is useful for delivery of 442 data. 444 "Link-level Measurements from an 802.11b Mesh Network" [Aguayo] 445 analyzes the causes of frame loss in a 38-node urban multi-hop 802.11 446 ad-hoc network. In most cases, links that are very bad in one 447 direction tend to be bad in both directions, and links that are very 448 good in one direction tend to be good in both directions. However, 449 30 percent of links exhibited loss rates differing substantially in 450 each direction. 452 Signal to noise ratio and distance showed little value in predicting 453 loss rates, and rather than exhibiting a step-function transition 454 between "up" (low loss) or "down" (high loss) states, inter-node 455 loss rates varied widely, demonstrating a nearly uniform distribution 456 over the range at the lower rates. The authors attribute the 457 observed effects to multi-path fading, rather than attenuation or 458 interference. 460 The findings of [Eckhardt] and [Aguayo] demonstrate the diversity of 461 loss conditions observed in practice. There is a fundamental 462 difference between infrastructure networks in which site surveys and 463 careful measurement can assist in promoting ideal behavior and ad- 464 hoc/mesh networks in which node mobility and external factors such as 465 weather may not be easily controlled. 467 1.7. Implementation Differences 469 The literature also describes the effect of implementation 470 differences on link indications. For the purposes of illustration, 471 we will restrict ourself to literature relating to IEEE 802.11 472 implementations. 474 "An Empirical Analysis of the IEEE 802.11 MAC Layer Handoff Process" 475 [Mishra] investigates handoff latencies obtained with three mobile 476 STAs implementations communicating with two APs. The study found 477 that there is large variation in handoff latency among STA and AP 478 implementations and that implementations utilize different message 479 sequences. For example, one STA sends a Reassociation Request prior 480 to authentication, which results in receipt of a Deauthenticate 481 message. The study divided handoff latency into discovery, 482 authentication and reassociation exchanges, concluding that the 483 discovery phase was the dominant component of handoff delay. 484 Detection was not investigated. 486 "Techniques to reduce IEEE 802.11b MAC layer handover time" [Velayos] 487 measured handover times for a stationary STA after the AP was turned 488 off. This study divided handover times into detection (determination 489 of the need for handover), search (discovery of alternative 490 attachment points), and execution phases (authentication and 491 association exchanges). These measurements indicated that the 492 detection phase was longest in duration. The duration of the 493 detection phase is determined by the number of non-acknowledged 494 frames triggering the search phase and precursors such as RTS/CTS and 495 rate adaptation. 497 Detection behavior varied widely between implementations. For 498 example, NICs designed for desktops attempted more retransmissions 499 prior to triggering search as compared with laptop designs, since 500 they assumed that the AP is always in range, regardless of Beacon 501 reception. 503 The study recommends that the duration of the detection phase be 504 reduced by initiating the search phase as soon as collisions can be 505 excluded as the cause of non-acknowledged transmissions; the authors 506 recommend three consecutive transmission failures as the cutoff. 507 Where the STA is not sending, it is recommended that Beacon 508 reception be tracked if no data frames are being received, and that 509 Beacon spacing be reduced to 60 ms in order to reduce detection 510 times. In order to compensate for more frequent triggering of the 511 search phase, the authors recommend algorithms for wait time 512 reduction, as well as interleaving of search with data transmission. 514 "Roaming Interval Measurements" [Alimian] presents data on stationary 515 STAs after the AP signal has been shut off. This study highlighted 516 implementation differences in rate adaptation as well as detection, 517 scanning and handoff. As in [Velayos], performance varied widely 518 between implementations, from half an order variation in rate 519 adaptation to an order of magnitude difference in connectivity 520 detection times, two orders of magnitude in scanning, and one and a 521 half orders of magnitude in handoff times. 523 "An experimental study of IEEE 802.11b handoff performance and its 524 effect on voice traffic" [Vatn] describes handover behavior observed 525 when the signal from AP is gradually attenuated, which is more 526 representative of field experience than the shutoff techniques used 527 in [Velayos]. Stations were configured to initiate handover when 528 signal strength dipped below a threshold, rather than purely based on 529 frame loss, so that they could begin handover while still connected 530 to the current AP. It was noted that stations continue to receive 531 data frames during the search phase. Station-initiated 532 Disassociation and pre-authentication were not observed in this 533 study. 535 2. Architectural considerations 537 While the literature on the usage of link layer indications provides 538 persuasive evidence of their utility, experience shows that a number 539 of difficulties can arise in making effective use of them. These 540 issues include: 542 a. Model validation 543 b. Robustness 544 c. Effectiveness 545 d. Interoperability Issues 546 e. Race conditions 547 f. Layer compression 548 g. Remoting implications 549 h. Security implications 551 The sections that follow discuss each of these issues in turn. 553 2.1. Model Validation 555 In "The mistaken axioms of wireless-network research" [Kotz], the 556 authors conclude that mistaken assumptions relating to link 557 performance may lead to the design of network protocols that may not 558 work in practice. In order to avoid these pitfalls, documents 559 dependent on link indications should explicitly articulate the 560 assumptions of the link model and describe the circumstances in which 561 it applies. 563 Authors need to be careful to avoid use of simplified network models 564 in circumstances where the model does not apply. For example, 565 generic "trigger" models assume that a link is either in a state 566 experiencing low frame loss ("Link Up") or in a state where few if 567 any frames are delivered ("Link Down"). Often symmetry is assumed as 568 well, so that a link is assumed to be either "Up" in both directions 569 or "Down" in both directions. In wireless networks, particularly in 570 the case of ad-hoc or mesh deployments, these assumptions may prove 571 invalid. 573 Furthermore, where links are in intermediate states between "Up" and 574 "Down" and asymmetry is encountered, generic "triggers" such as "Link 575 Going Down", "Link Going Up", "Link Quality Crosses Threshold" may 576 prove difficult to define and may prove to be unreliable predictors 577 of future link performance. 579 Once the network model is defined, considerable effort may be 580 required to map the model to common link types. In practice the 581 definition of "Link Up" or "Link Down" may vary according to the link 582 layer. For example, within PPP [RFC1661], either peer may send an 583 LCP-Terminate frame in order to terminate the PPP link layer, and a 584 link may only be assumed to be usable for sending network protocol 585 packets once NCP negotiation has completed for that protocol. 587 Within IEEE 802.11, the definition of "Link Up" and "Link Down" 588 depends on whether the station is mobile or stationary, whether 589 infrastructure or ad-hoc mode is in use, and whether security and 590 Inter-Access Point Protocol (IAPP) is implemented. 592 Where a mobile 802.11 STA encounters a series of consecutive non- 593 acknowledged frames, the most likely cause is that the station has 594 moved out of range of the AP. As a result, [Velayos] recommends that 595 the station begin the search phase after collisions can be ruled out, 596 after three consecutive non-acknowledged frames. Only when no 597 alternative point of attachment is found is a "Link Down" indication 598 returned. 600 In a stationary point-to-point installation, the most likely cause of 601 an outage is that the link has become impaired. As a result, 602 implementations tend to be more persistent and a "Link Down" 603 indication may be returned later. 605 In Infrastructure mode, IEEE 802.11-2003 enables reception of data 606 frames only in State 3 ("Authenticated" and "Associated"). As a 607 result, a transition to State 3 (e.g. completion of a successful 608 Association or Reassociation exchange) enables sending and receiving 609 of network protocol packets and a transition from State 3 to State 2 610 (reception of a "Disassociate" frame) or State 1 (reception of a "De- 611 authenticate" frame) disables sending and receiving of network 612 protocol packets. As a result, IEEE 802.11 stations typically signal 613 "Link Up" on receipt of a successful Association or Reassociation 614 response. 616 Within the [IEEE80211f] specification, after sending a Reassociation 617 Response, an Access Point will send a frame with the station's source 618 address to a multicast destination. This causes switches within the 619 Distribution System (DS) to update their learning tables, readying 620 the DS to forward frames to the station at its new point of 621 attachment. Were the AP to not send this "spoofed" frame, the 622 station's location would not be updated within the DS until it sent 623 its first frame at the new location. Thus IAPP serves to equalize 624 uplink and downlink handover times. 626 The signalling of "Link Down" is considerably more complex. Even 627 though a transition to State 2 or State 1 results in the station 628 being unable to send or receive IP packets, this does not necessarily 629 imply that such a transition should be considered a "Link Down" 630 indication. In an infrastructure network, a station may have a 631 choice of multiple access points offering connection to the same 632 network. In such an environment, a station that is unable to reach 633 State 3 with one access point may instead choose to attach to another 634 access point. Rather than registering a "Link Down" indication with 635 each move, the station may instead register a series of "Link Up" 636 indications. 638 In [IEEE80211i] forwarding of frames from the station to the 639 distribution system is only feasible after the completion of the 640 4-way handshake and group-key handshake, so that entering State 3 is 641 no longer sufficient. 643 Unfortunately, other elements of the IEEE 802.11 specification such 644 as IEEE 802.11f continue to recognize the Reassociation Response as 645 the "Link Up" definition. By spoofing a multicast frame with the 646 station's source address once it sends a Reassociation Response, 647 Access Points implementing IEEE 802.11f cause the learning tables 648 within switches comprising the DS to be updated. This enables an 649 attacker to deny service to attached stations by sending a 650 Reassociation Request from anywhere within the ESS. Without the 651 spoofing recommended in IEEE 802.11f, such an attack would only be 652 able to disassociate stations on the AP to which the Reassociation 653 Request was sent. 655 [IEEE80211i] implementations utilizing the "Link Up" definition from 656 [IEEE80211] or [IEEE80211f] have also encountered difficulty in IP 657 address assignment, since they may trigger DHCP [RFC2131] or RS/RA 658 prior to when the link is usable by the Internet layer. As a result, 659 Internet layer configuration may fail. 661 In contrast, in 802.11 ad-hoc mode with no security, reception of 662 data frames is enabled in State 1 ("Unauthenticated" and "Un- 663 associated"). As a result, reception of data frames is enabled at 664 any time, and no explicit "Link Up" indication exists. 666 2.2. Robustness 668 Implementation experience provides us with several examples of 669 situations in which improper consideration of link layer indications 670 can result in operational malfunctions. Given the potential 671 problems, proposals for consideration of link layer indications must 672 demonstrate robustness against misleading indications. Elements of 673 robustness include: 675 a. Indication validation 676 b. Damping and hysterisis 678 2.2.1. Indication Validation 680 As noted in Section 1.6 and 1.7, radio propagation and implementation 681 differences can impact the reliability of link layer indications. 682 [Kotz] notes that the three-dimensional nature of wireless 683 propagation can result in large signal strength changes over short 684 distances, generating short-lived "Link Down" and "Link Up" 685 indications that are not be predicted by a two dimensional radio 686 propagation model. 688 As described in [Aguayo], wireless links often exhibit loss rates 689 intermediate between "up" (low loss) and "down" (high loss) states, 690 as well as substantial asymmetry. In these circumstances, a "Link 691 Up" indication may not imply bi-directional reachability. Also, a 692 reachability demonstration based on small packets may not mean that 693 the link is suitable for carrying larger data packets. As a result, 694 "Link Up" and "Link Down" indications may not reliably determine 695 whether a link is suitable for carrying IP traffic. 697 Where the reliability of a link layer indication is suspect, it is 698 best to treat the indication as a "hint" that is advisory in nature, 699 rather than a "trigger" forcing a given action. In order to provide 700 increased robustness, heuristics can be developed to determine 701 whether the "hint" is valid or should be discarded. 703 In addition, a recovery step may be utilized in order to limit the 704 potential damage from link indications determined to be invalid after 705 they have been acted on. 707 To provide robustness in the face of potentially misleading link 708 indications, in [DNAv4] "Link Up" indications are assumed to be 709 inherently unreliable, so that bi-directional reachability needs to 710 be demonstrated prior to validating an existing IP configuration. 711 However, in the case of a link of intermediate loss rate, success 712 with the [DNAv4] reachability test does not guarantee that the link 713 is suitable for carrying data. 715 Another example of link indication validation occurs occurs in IPv4 716 Link-Local address configuration. Prior to configuration of an IPv4 717 Link-Local address, it is necessary to run a claim and defend 718 protocol [RFC3927]. Since a host needs to be present to defend its 719 address against another claimant, and address conflicts are 720 relatively likely, a host returning from sleep mode or receiving a 721 "Link Up" indication could encounter an address conflict were it to 722 utilize a formerly configured Link-Local Link-Local address without 723 rerunning claim and defend. 725 2.2.2. Damping and Hysterisis 727 Damping and hysterisis can be utilized to ensure that stability is 728 maintained in the face of jittery link indications. These limits 729 typically place constraints on the number of times a given action can 730 be performed within a time period or introduce damping mechanisms to 731 prevent instability. 733 While [Aguayo] found that frame loss was relatively stable for 734 stationary stations, obstacles to radio propagation and multipath 735 interference can result in rapid changes in signal strength for a 736 mobile station. As a result, it is possible for mobile stations to 737 encounter rapid changes in link performance, including changes in the 738 negotiated rate, frame loss and even "Link Up"/"Link Down" 739 indications. 741 Where link-aware routing metrics are implemented, this can result in 742 rapid metric changes, potentially resulting in frequent changes in 743 the outgoing interface for "Weak End-System" implementations. As a 744 result, it may be necessary to introduce route flap dampening. 746 However, the benefits of damping need to be weighed against the 747 additional latency that can be introduced. For example, in order to 748 filter out spurious "Link Down" indications, these indications may be 749 delayed until it can be determined that a "Link Up" indication will 750 not follow shortly thereafter. However, in situations where multiple 751 Beacons are missed such a delay may not be needed, since there is no 752 evidence of a suitable point of attachment in the vicinity. 754 In some cases, it may be desirable to ignore link indications 755 entirely. Since it is possible for a host to transition from an ad- 756 hoc network to a network with centralized address management, a host 757 receiving a "Link Up" indication cannot necessarily conclude that it 758 is appropriate to configure a IPv4 Link-Local address at all. 760 It can be argued that reliable transport protocol implementations 761 should ignore "Link Down" indications, rather than tearing down 762 connections, regardless of the cause of the "Link Down" indication. 764 Where the "Link Down" indication results from frame loss rather than 765 an explicit exchange, the indication may be transient, rapidly 766 followed by a "Link Up" indication. Even where the "Link Down" 767 indication results from an explicit exchange such as a PPP LCP- 768 Terminate or an 802.11 Disassociation or Deauthenticate, an 769 alternative point of attachment may be available, allowing 770 connectivity to be quickly restored. As a result, robustness is best 771 served by allowing connections to remain up until the connection 772 source address is invalidated by an address change, or the connection 773 times out. 775 Where link indications are used to optimize transport performance, 776 authors must demonstrate that effective congestion control is 777 maintained [RFC2914] in the face of rapidly changing link 778 indications. 780 In addition, where a proposal involves "recovery" from a handoff 781 event, it is important to demonstrate that the recovered parameters 782 (such as the adjusted RTT, RTO, congestion window, etc.) remain 783 valid, as noted in [RFC2861]. 785 Consider a proposal where a "Link Up" indication is used by a router 786 to signal retransmission a previously sent packet, in order to enable 787 ACK reception prior to expiration of the host's retransmission timer. 788 Where "Link Up" indications follow in rapid succession, this could 789 result in a burst of retransmitted packets, violating the law of 790 conservation of packets. 792 At the Application Layer, link layer indications have been utilized 793 by applications such as Presence [RFC2778] in order to optimize 794 registration and user interface update operations. For example, 795 implementations may attempt presence registration on receipt of a 796 "Link Up" indication, and presence deregistration by a surrogate 797 receiving a "Link Down" indication. Presence implementations using 798 "Link Up"/"Link Down" indications this way violate the principle of 799 "conservation of packets" when link indications are generated on a 800 time scale of RTO or less. The problem is magnified since for each 801 presence update, notifications can be delivered to many watchers. 803 The issue can be addressed by one or more of the following 804 techniques: 806 [a] Rate limiting. A limit of one packet per RTO can be imposed on 807 packets generated from receipt of link indications. 809 [b] Utilization of upper layer indications. Instead of consuming a 810 "Link Up" indication, applications can consume alternative upper 811 layer indications such as an IP address change notification. 813 [c] Keepalives. Instead of consuming a "Link Down" indication, an 814 application can utilize an application keepalive or consume 815 transport layer indications such as connection teardown. 817 2.3. Effectiveness 819 While link layer indications may show promise, it may be difficult to 820 prove that processing of a given indication provides benefits in a 821 wide variety of circumstances. Where link layer indications are 822 utilized for the purpose of optimization, proposals need to carefully 823 analyze the effectiveness of the optimizations in the face of 824 unreliable link layer indications. Since optimizations typically 825 bring with them increased complexity, an optimization that does not 826 bring about a performance improvement is not useful. 828 As with any optimization, the usefulness of link layer indications 829 lies in demonstrated effectiveness of the optimization under 830 consideration. This in turn may depend heavily on the penalty to be 831 paid for false positives and false negatives. 833 As noted in [DNAv4], it is simultaneously possible for a link layer 834 indication to be highly reliable, as well as for that indication to 835 provide no net benefit, depending on the probability of a false 836 indication and the penalty paid for the false indication. 838 In the case of [DNAv4], the benefits of successful optimization are 839 modest, but the penalty for falsely concluding that the subnet 840 remains unchanged is a lengthy timeout. The result is that link 841 layer indications may not be worth considering if they are incorrect 842 even just a small fraction of the time. 844 For example, it can be argued that a change in the Service Set 845 Identifier (SSID) in [IEEE80211] is not a sufficiently reliable 846 indication of subnet change. Within IEEE 802.11, the Service Set 847 Identifier (SSID) functions as a non-unique identifier of the 848 administrative domain of a Wireless LAN. Since the SSID is non- 849 unique, many different operators may share the same SSID, and Access 850 Points typically ship with a default value for the SSID (e.g. 851 "default"). Since the SSID relates to the administrative domain and 852 not the network topology, multiple SSIDs may provide access to the 853 same prefix, and a single SSID may provide access to multiple 854 prefixes at one or multiple locations. 856 Given this, it is unreliable to use the SSID alone for the purpose of 857 movement detection. A host moving from one point of attachment to 858 another, both with the same SSID, may have remained within the same 859 subnet, or may have changed subnets. Similarly, a host discovering 860 that the SSID has changed may have changed subnets, or it may not 861 have. Moreover, where private address space is in use, it is 862 possible for the SSID, the prefix (e.g. 192.168/16) and even the 863 default gateway IP address to remain unchanged, yet for the host to 864 have moved to a different point of attachment. Were the host to make 865 decisions relating to configuration of the IP layer (such as address 866 assignment) based solely on the SSID, address conflicts are likely. 868 2.4. Interoperability Issues 870 Since link layer indications are often processed by upper layers for 871 the purpose of optimization, proposals must demonstrate that 872 interoperability remains possible (though potentially with degraded 873 performance) even if one or more participants do not implement the 874 proposals. 876 Where link layer indications are proposed for use in optimizing 877 configuration of the Internet layer, it is necessary to demonstrate 878 that the proposal does not interfere with routing protocol behavior, 879 make address collisions more likely, or compromise Duplicate Address 880 Detection (DAD). 882 2.5. Race Conditions 884 It is possible for link layer indications to be utilized directly by 885 multiple layers of the stack in situations in which strict layering 886 may not be observed. In these situations, it is possible for race 887 conditions to occur. 889 For example, as discussed earlier, link layer indications have been 890 shown to be useful in optimizing aspects of Internet Protocol layer 891 addressing and configuration as well as routing. Although [Kim] 892 describes situations in which link layer indications are first 893 processed by the Internet Protocol layer (e.g. MIPv6) before being 894 consumed by the Transport Layer, in some situations it may be 895 desirable for the Transport Layer to consume link layer indications 896 directly. 898 For example, in situations where the "Weak End-System Model" is 899 implemented, a change of outgoing interface may occur at the same 900 time the Transport Layer is modifying transport parameters based on 901 other link layer indications. As a result, transport behavior may 902 differ depending on the order in which the link indications are 903 processed. 905 Whee a multi-homed host experiences high frame loss on one of its 906 interfaces, the ETX metric computed for that interface will rise, 907 causing a change in the outgoing interface for one or more transport 908 connections. This may trigger Mobile IP signaling so as to cause a 909 change in the incoming path as well. At the same time, the Transport 910 Layer may be estimating transport parameters based on the former 911 outgoing interface, and may not properly adjust for the changes in 912 outgoing and incoming paths. 914 To avoid race conditions, the following measures are recommended: 916 a. Path change processing 917 b. Layering 918 c. Metric consistency 920 2.5.1. Path Change Processing 922 When the Internet layer detects a path change, such as a change in 923 the outgoing or incoming interface of the host or the incoming 924 interface of a peer, or perhaps a substantial change in the TTL of 925 received IP packets, it may be worth considering whether to reset 926 transport parameters to their initial values and allow them to be re- 927 estimated. This ensures that estimates based on the former path do 928 not persist after they have become invalid. 930 2.5.2. Layering 932 Another technique to avoid race conditions is to rely on layering to 933 damp potentially misleading indications and provide greater link 934 layer independence. 936 The Internet layer is responsible for routing as well as IP 937 configuration, and mobility, providing higher layers with an 938 abstraction that is independent of link layer technologies. Since 939 one of the major objectives of the Internet layer is maintaining link 940 layer independence, upper layers relying on Internet Layer 941 indications rather than consuming link layer indications directly can 942 avoid link layer dependencies. 944 For example, in order to provide robustness, it is necessary to 945 demonstrate that a link providing a "Link Up" indication is likely to 946 be usable for the transmission of IP data packets prior to using it. 947 While applications can in principle incorporate their own versions of 948 such a test, efficiency and maintenance considerations argue for 949 providing this facility within the Internet layer. 951 Many "Link Up" indications do not result in a change of Internet 952 Layer configuration, and many changes in link rate or frame loss do 953 not result in a change of outgoing interface. By filtering "Link Up" 954 indications, and selecting outgoing and incoming interfaces based on 955 the link rate and frame loss, the Internet Layer enables upper layers 956 to avoid writing their own code to filter and validate link 957 indications. 959 The transport layer consumes Internet layer indication such as 960 changes in the incoming/outgoing interface and Internet layer 961 configuration changes, as well as potentially utilizing link layer 962 indications directly. For example, the Internet layer may receive a 963 "Link Down" indication followed by a subsequent "Link Up" indication. 964 This information may be of interest to the Transport layer even if 965 the Internet layer configuration does not change, since it may 966 provide information about the validity of the transport parameters 967 estimates. 969 In general, it is advisable for applications to consume indications 970 from the Internet or Transport layers rather than consuming link 971 indications directly, since this enables applications to leverage 972 layered indication processing, resulting in improved robustness and 973 scalability. For example, instead of directly consuming "Link Down" 974 indications, applications may wish to rely on Application layer 975 keepalives or the Transport layer to determine whether connections 976 should be torn down; instead of consuming "Link Up" indications, 977 applications can consume IP address change indications. 979 2.5.3. Metric Consistency 981 Once a link is in the "Up" state, its effectiveness in transmission 982 of data packets can be determined. For example, frame loss may be 983 used in rate adjustment and detection of when to roam to an 984 alternative point of attachment. While connected, the effective 985 throughput may be determined based on the negotiated rate and frame 986 loss, and used in calculation of the routing metric, as described in 987 [ETX]. 989 However, prior to sending data packets over the link, other measures 990 of suitability are required. As noted in [Shortest], the ability of 991 a link to successfully transmit short frames utilized for control, 992 management or routing is not indicative of its usefulness in carrying 993 IP data packets. As a result, it is typically not possible to 994 predict the negotiated rate or data frame loss rate in advance of a 995 roaming decision. 997 As a result, 802.11 stations evaluating the suitability of candidate 998 APs often utilize received signal strength and/or AP load as a 999 primary selection criteria. Similarly, in order to enable stations 1000 to roam prior to encountering packet loss, studies such as [Vatn] 1001 have suggested using signal strength as a detection mechanism, rather 1002 than frame loss, as suggested in [Velayos]. 1004 The "Link Going Down", "Link Going Up", "Link Quality Crosses 1005 Threshold" indications were developed primarily to assist with 1006 handoff between interfaces, and are oriented toward inferred rather 1007 than measured suitability. 1009 Research indicates that this approach may have some promise. For 1010 example, [Vertical] proposes use of signal strength and link 1011 utilization in order to optimize vertical handoff and demonstrates 1012 improved TCP throughput. However, without careful design, potential 1013 differences between link indications used in routing and those used 1014 in roaming and/or link enablement can result in instability, 1015 particularly in multi-homed hosts. 1017 For example, receipt of "Link Going Down" or "Link Quality Crosses 1018 Threshold" indications could be used as a signal to enable another 1019 interface. However, unless the new interface is the preferred route 1020 for one or more destination prefixes, a "Weak End-System" 1021 implementation will not use the new interface for outgoing traffic. 1022 Where "idle timeout" functionality is implemented, the unused 1023 interface will be brought down, only to be brought up again by the 1024 link enablement algorithm. 1026 As noted in [Aguayo], signal strength and distance are not good 1027 predictors of frame loss or negotiated rate, due to the potential 1028 effects of multi-path interference. As a result a link brought up 1029 due to good signal strength may subsequently exhibit significant 1030 frame loss, and a low negotiated rate. Similarly, an AP 1031 demonstrating low utilization may not necessarily be the best choice, 1032 since utilization may be low due to hardware or software problems. 1033 As noted in [Villamizar], link utilization-based routing metrics have 1034 a history of instability, so that they are rarely deployed. 1036 2.6. Layer compression 1038 In many situations, the exchanges required for a host to complete a 1039 handoff and reestablish connectivity are considerable. This includes 1040 link layer scanning, authentication and connectivity establishment; 1041 Internet layer configuration, routing and mobility exchanges; 1042 transport layer retransmission and recovery; security association re- 1043 establishment; application protocol reauthentication and 1044 reregistration exchanges, etc. Given this, it is natural to consider 1045 combining exchanges occurring within multiple layers into a single 1046 exchange. 1048 Often this combined exchange occurs within the link layer. For 1049 example, in [EAPIKEv2], a link layer EAP exchange may be used for the 1050 purpose of IP address assignment, potentially bypassing Internet 1051 layer configuration. Within [PEAP], it is proposed that a link layer 1052 EAP exchange be used for the purpose of carrying Mobile IPv6 Binding 1053 Updates. [MIPEAP] proposes that EAP exchanges be used for 1054 configuration of Mobile IPv6. 1056 While the goals of layer compression are laudable, care needs to be 1057 taken to avoid compromising interoperability and introducing link 1058 layer dependencies into the Internet and Transport layers. For 1059 example, where Link layer and Internet or Transport layer mechanisms 1060 are combined, it is necessary for hosts to maintain the ability to 1061 interoperate without layer compression schemes, in order to permit 1062 operation on networks where they are not available. 1064 As noted earlier, while the layered handling of link indications 1065 introduces latency, it also increases robustness. As a result, 1066 layer compression schemes need to take care to avoid introducing 1067 unnecessary brittleness. For example, in order to optimize IP 1068 address assignment, it has been proposed that prefixes be advertised 1069 at the link layer. While in theory such a proposal addresses the 1070 non-uniqueness issues found with the use of the SSID for movement 1071 detection, it suffers from its own set of problems. 1073 For example, [IEEE8021X] enables the VLANID to by assigned 1074 dynamically. As a result, a prefix advertised at the link layer need 1075 not correspond to the prefix assigned to the host once it connects to 1076 the link. Were IP configuration to be based on such hints, errors 1077 are likely. 1079 2.7. Remoting implications 1081 Proposals which include support for remoting of link layer 1082 indications need to carefully consider the layering, security and 1083 transport implications. 1085 While facilities such as ICMP "source quench" were originally 1086 provided at the Internet layer, these facilities have fallen into 1087 disuse due to their questionable value for the Transport layer. In 1088 general, the Transport layer is able to determine an appropriate (and 1089 conservative) response to congestion based on packet loss or explicit 1090 congestion notification, so that ICMP "source quench" indications are 1091 not needed, and in fact the sending of additional "source quench" 1092 packets during periods of congestion may be detrimental. 1094 On the other hand, proposals such as [ETX] imply that hosts 1095 participating in the routing mesh may gain knowledge of remote link 1096 conditions where link-aware routing metrics are used. This can be 1097 accomplished securely if routing protocol security is implemented. 1099 For example, when a link experiences frame loss, the ETX metric will 1100 increase, possibly resulting in selection of an alternate route. If 1101 the troubled link represents the only path to a prefix and the link 1102 experiences high frame loss ("Down"), the route will be withdrawn or 1103 the metric will become infinite. Thus, where link-indication aware 1104 routing metrics are implemented, "link indication remoting" can be 1105 accomplished via host participation in the routing mesh, and 1106 transport layer response to path changes. 1108 Proposals involving remoting of link layer indications need to 1109 demonstrate the following: 1111 [a] Absence of alternatives. By default, alternative solutions not 1112 requiring explicit remoting of link layer indications are 1113 preferred, and the burden of proof rests on remoting advocates to 1114 show that alternatives (including link-indication aware routing 1115 metrics) are unsuitable. 1117 [b] Conservative behavior. Due to past experience with ICMP "source 1118 quench", the burden of proof rests on advocates of remoting 1119 proposals to demonstrate that proposals do not violate conservation 1120 of packets. 1122 [c] Security. Remoting proposals need to describe how security issues 1123 can be addressed. Where insecure remoted link layer indications are 1124 transported over the Internet, an attack can be launched without 1125 requiring access to the link. 1127 [d] Identifiers. When link indications are remoted, it is generally 1128 for the purposes of saying something about Internet, Transport or 1129 Application layer operations at a remote element. These layers use 1130 different identifiers, and so it is necessary to match the link 1131 indication with relevant higher layer state. The burden rests on 1132 remoting advocates to demonstrate how the link indication can be 1133 mapped to the right higher layer state. As an example, if a 1134 presence server is receiving remote indications about "Link 1135 Up"/"Link Down" status for a particular MAC address, the presence 1136 server will need to associate that MAC address with the identity of 1137 the user (pres:user@example.com) to whom that link status change is 1138 relevant. 1140 2.8. Security Considerations 1142 Since link layer indications are typically insecure, proposals 1143 incorporating them need to consider the potential security 1144 implications of spoofed or modified link layer indications, as well 1145 as the potential denial of service attacks. This is particularly 1146 important in situations where insecure link layer indications are as 1147 a substitute for secure mechanisms operating at a higher layer. 1149 For example, within [IEEE80211f], "Link Up" is considered to occur 1150 when an Access Point sends a Reassociation Response. At that point, 1151 the AP sends a frame with the station's source address to a multicast 1152 address, thereby causing switches within the Distribution System to 1153 learn the station's MAC address, enabling forwarding of frames to the 1154 station at the new point of attachment. Unfortunately, this does not 1155 take security into account, since the station is not capable of 1156 sending and receiving IP packets on the link until completion of the 1157 key exchange protocol defined in [IEEE80211i]. As a result, link 1158 layer indications as implemented in [IEEE80211f] enable an attacker 1159 to disassociate a station located anywhere within the ESS, simply by 1160 sending a Reassociation Request frame. 1162 Another example of the potential security implications of link layer 1163 indications occurs within DNAv4, where link layer indications are 1164 used for optimization of IP configuration, rather than using a 1165 secured configuration mechanism such as authenticated DHCP [RFC3118], 1166 thereby increasing vulnerability to spoofing. 1168 3. Further work 1170 While Figure 1 presents an overview of how link indications are 1171 consumed by the Internet, Transport and Application layers, further 1172 work is needed to investigate this in more detail. 1174 Given that recent proposals such as [IEEE80211e] incorporate burst 1175 ACKs, the relationship between 802.11 link throughput and frame loss 1176 is growing more complex, which may necessitate the development of 1177 revised routing metrics, taking the more complex transmission 1178 behavior as well as the negotiated rate into account. 1180 At the link and Internet layers, more work is needed to reconcile pre 1181 and post-connection metrics, such as reconciling metrics utilized in 1182 handoff (e.g. signal strength and link utilization) with link-aware 1183 routing metrics (e.g. frame loss and negotiated rate). 1185 At the Transport layer, more work is needed to understand how to 1186 react Internet layer indications such as path changes. For example, 1187 in an early draft of DCCP [DCCP], a "Reset Congestion State" option 1188 was proposed in Section 4. This option was removed in part because 1189 the conditions under which it was to be used were not fully 1190 understood: 1192 An HC-Receiver sends the Reset Congestion State option to its sender 1193 to force the sender to reset its congestion state -- that is, to 1194 "slow start", as if the connection were beginning again. ... 1195 The Reset Congestion State option is reserved for the very few cases 1196 when an endpoint knows that the congestion properties of a path have 1197 changed. Currently, this reduces to mobility: a DCCP endpoint on a 1198 mobile host MUST send Reset Congestion State to its peer after the 1199 mobile host changes address or path. 1201 It may also make sense for the Transport layer to adjust transport 1202 parameter estimates in response to "Link Up"/"Link Down" indications 1203 and frame loss. For example, it is unclear that the Transport layer 1204 should adjust transport parameters as though congestion were detected 1205 when loss is occurring in the link layer or a "Link Down" indication 1206 has been received. 1208 Finally, more work is needed to determine how link layers may utilize 1209 information from the transport layer. For example, it is undesirable 1210 for a link layer to retransmit so aggressively that the link layer 1211 round-trip time approaches that of the end-to-end transport 1212 connection. 1214 4. References 1216 4.1. Normative References 1218 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1219 Requirement Levels", BCP 14, RFC 2119, March 1997. 1221 4.2. Informative References 1223 [RFC791] Postel, J., "Internet Protocol", RFC 791, USC/Information 1224 Sciences Institute, September 1981. 1226 [RFC792] Postel, J., "Internet Control Message Protocol", RFC 792, 1227 USC/Information Sciences Institute, September 1981. 1229 [RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1230 1661, July 1994. 1232 [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, D. and 1233 E. Lear, "Address Allocation for Private Internets", RFC 1918, 1234 February 1996. 1236 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, 1237 March 1997. 1239 [RFC2778] Day, M., Rosenberg, J., Sugano, H., "A Model for Presence and 1240 Instant Messaging", RFC 2778, February 2000. 1242 [RFC2861] Handley, M., Padhye, J. and S. Floyd, "TCP Congestion Window 1243 Validation", RFC 2861, June 2000. 1245 [RFC2914] Floyd, S., "Congestion Control Principles", RFC 2914, BCP 41, 1246 September 2000. 1248 [RFC3118] Droms, R. and B. Arbaugh, "Authentication for DHCP Messages", 1249 RFC 3118, June 2001. 1251 [RFC3428] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C. and 1252 D. Gurle, "Session Initiation Protocol (SIP) Extension for 1253 Instant Messaging", RFC 3428, December 2002. 1255 [RFC3748] Aboba, B., , "Extensible Authentication Protocol (EAP)", RFC 1256 3748, June 2004. 1258 [RFC3775] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in 1259 IPv6", RFC 3775, June 2004. 1261 [RFC3921] Saint-Andre, P., "Extensible Messaging and Presence protocol 1262 (XMPP): Instant Messaging and Presence", RFC 3921, October 1263 2004. 1265 [RFC3927] Cheshire, S., Aboba, B. and E. Guttman, "Dynamic Configuration 1266 of Link-Local IPv4 Addresses", RFC 3927, October 2004. 1268 [802.11fh] 1269 McCann, P., "Mobile IPv6 Fast Handovers for 802.11 Networks", 1270 draft-ietf-mipshop-80211fh-01.txt, Internet draft (work in 1271 progress), July 2004. 1273 [Alimian] Alimian, A., "Roaming Interval Measurements", 1274 11-04-0378-00-roaming-intervals-measurements.ppt, IEEE 802.11 1275 submission (work in progress), March 2004. 1277 [Aguayo] Aguayo, D., Bicket, J., Biswas, S., Judd, G. and R. Morris, 1278 "Link-level Measurements from an 802.11b Mesh Network", 1279 SIGCOMM '04, September 2004, Portland, Oregon. 1281 [DCCP] Kohler, E., Handley, M. and S. Floyd, "Datagram Congestion 1282 Control Protocol (DCCP)", Internet drafts (work in progress), 1283 draft-ietf-dccp-spec-07.txt, July 2004. 1285 [DNAv4] Aboba, B., "Detection of Network Attachment in IPv4", draft- 1286 ietf-dhc-dna-ipv4-08.txt, Internet draft (work in progress), 1287 July 2004. 1289 [EAPIKEv2] 1290 Tschofenig, H., D. Kroeselberg and Y. Ohba, "EAP IKEv2 1291 Method", draft-tschofenig-eap-ikev2-03.txt, Internet draft 1292 (work in progress), February 2004. 1294 [Eckhardt] 1295 Eckhardt, D. and P. Steenkiste, "Measurement and Analysis of 1296 the Error Characteristics of an In-Building Wireless Network", 1297 SIGCOMM '96, August 1996, Stanford, CA. 1299 [Eggert] Eggert, L., Schuetz, S. and S. Schmid, "TCP Extensions for 1300 Immediate Retransmissions", draft-eggert-tcpm-tcp-retransmit- 1301 now-00.txt, Internet draft (work in progress), July 2004. 1303 [ETX] Douglas S. J. De Couto, Daniel Aguayo, John Bicket, and Robert 1304 Morris, "A High-Throughput Path Metric for Multi-Hop Wireless 1305 Routing", Proceedings of the 9th ACM International Conference 1306 on Mobile Computing and Networking (MobiCom '03), San Diego, 1307 California, September 2003. 1309 [GenTrig] Gupta, V. and D. Johnston, "A Generalized Model for Link Layer 1310 Triggers", submission to IEEE 802.21 (work in progress), March 1311 2004, available at: 1312 http://www.ieee802.org/handoff/march04_meeting_docs/ 1313 Generalized_triggers-02.pdf 1315 [IEEE8021X] 1316 Institute of Electrical and Electronics Engineers, "Local and 1317 Metropolitan Area Networks: Port-Based Network Access 1318 Control", IEEE Standard 802.1X, November 2004. 1320 [IEEE80211] 1321 Institute of Electrical and Electronics Engineers, "Wireless 1322 LAN Medium Access Control (MAC) and Physical Layer (PHY) 1323 Specifications", IEEE Standard 802.11, 2003. 1325 [IEEE80211e] 1326 Institute of Electrical and Electronics Engineers, "Amendment 1327 7: Medium Access Control (MAC) Quality of Service (QoS) 1328 Enhancements", IEEE 802.11e, October 2003. 1330 [IEEE80211f] 1331 Institute of Electrical and Electronics Engineers, "IEEE 1332 Trial-Use Recommended Practice for Multi-Vendor Access Point 1333 Interoperability via an Inter-Access Point Protocol Across 1334 Distribution Systems Supporting IEEE 802.11 Operation", IEEE 1335 802.11f, June 2003. 1337 [IEEE80211i] 1338 Institute of Electrical and Electronics Engineers, "Supplement 1339 to Standard for Telecommunications and Information Exchange 1340 Between Systems - LAN/MAN Specific Requirements - Part 11: 1341 Wireless LAN Medium Access Control (MAC) and Physical Layer 1342 (PHY) Specifications: Specification for Enhanced Security", 1343 IEEE 802.11i, November 2004. 1345 [Kim] Kim, K., Park, Y., Suh, K., and Y. Park, "The BU-trigger 1346 method for improving TCP performance over Mobile IPv6", draft- 1347 kim-tsvwg-butrigger-00.txt, Internet draft (work in progress), 1348 August 2004. 1350 [Kotz] Kotz, D., Newport, C. and C. Elliot, "The mistaken axioms of 1351 wireless-network research", Dartmouth College Computer Science 1352 Technical Report TR2003-467, July 2003. 1354 [MIPEAP] Giaretta, C., Guardini, I., Demaria, E., Bournelle, J., and M. 1355 Laurent-Maknavicius, "MIPv6 Authorization and Configuration 1356 based on EAP", draft-giaretta-mip6-authorization-eap-01.txt, 1357 Internet draft (work in progress), July 2004. 1359 [Mishra] Mitra, A., Shin, M., and W. Arbaugh, "An Empirical Analysis of 1360 the IEEE 802.11 MAC Layer Handoff Process", CS-TR-4395, 1361 University of Maryland Department of Computer Science, 1362 September 2002. 1364 [PEAP] Palekar, A., et al, "Protected EAP Protocol (PEAP) Version 2", 1365 draft-josefsson-pppext-eap-tls-eap-09.txt, Internet draft 1366 (work in progress), October 2004. 1368 [Park] Park, S., Njedjou, E. and N. Montavont, "L2 Triggers Optimized 1369 Mobile IPv6 Vertical Handover: The 802.11/GPRS Example", 1370 draft-daniel-mip6-optimized-vertical-handover-00.txt, July 1371 2004. 1373 [PPPIANA] Schryver, V., "IANA Considerations for the Point to Point 1374 Protocol (PPP)", draft-schryver-pppext-iana-01.txt, August 1375 2003. 1377 [Shortest] 1378 Douglas S. J. De Couto, Daniel Aguayo, Benjamin A. Chambers, 1379 and Robert Morris, "Performance of Multihop Wireless Networks: 1380 Shortest Path is Not Enough", Proceedings of the First 1381 Workshop on Hot Topics in Networking (HotNets-I), Princeton, 1382 New Jersey, October 2002. 1384 [TRIGTRAN] 1385 Dawkins, S., et al., "Framework and Requirements for 1386 TRIGTRAN", draft-dawkins-trigtran-framework-00.txt, Internet 1387 draft (work in progress), August 2003. 1389 [Vatn] Vatn, J., "An experimental study of IEEE 802.11b handover 1390 performance and its effect on voice traffic", TRITA-IMIT-TSLAB 1391 R 03:01, KTH Royal Institute of Technology, Stockholm, Sweden, 1392 July 2003. 1394 [Yegin] Yegin, A., "Link-layer Triggers Protocol", draft-yegin- 1395 l2-triggers-00.txt, Internet Draft (work in progress), June 1396 2002. 1398 [Velayos] Velayos, H. and G. Karlsson, "Techniques to Reduce IEEE 1399 802.11b MAC Layer Handover Time", TRITA-IMIT-LCN R 03:02, KTH 1400 Royal Institute of Technology, Stockholm, Sweden, April 2003. 1402 [Vertical] 1403 Zhang, Q., Guo, C., Guo, Z. and W. Zhu, "Efficient Mobility 1404 Management for Vertical Handoff between WWAN and WLAN", IEEE 1405 Communications Magazine, November 2003. 1407 [Villamizar] 1408 Villamizar, C., "OSPF Optimized Multipath (OSPF-OMP)", draft- 1409 ietf-ospf-omp-02.txt, Internet draft (work in progress), 1410 February 1999. 1412 Appendix A. IAB Members at the time of this writing 1414 Bernard Aboba 1415 Rob Austein 1416 Leslie Daigle 1417 Patrik Falstrom 1418 Sally Floyd 1419 Mark Handley 1420 Bob Hinden 1421 Geoff Huston 1422 Jun-Ichiro Itojun Hagino 1423 Eric Rescorla 1424 Pete Resnick 1425 Jonathan Rosenberg 1427 Intellectual Property Statement 1429 The IETF takes no position regarding the validity or scope of any 1430 intellectual property or other rights that might be claimed to 1431 pertain to the implementation or use of the technology described in 1432 this document or the extent to which any license under such rights 1433 might or might not be available; neither does it represent that it 1434 has made any effort to identify any such rights. Information on the 1435 IETF's procedures with respect to rights in standards-track and 1436 standards-related documentation can be found in BCP-11. Copies of 1437 claims of rights made available for publication and any assurances of 1438 licenses to be made available, or the result of an attempt made to 1439 obtain a general license or permission for the use of such 1440 proprietary rights by implementors or users of this specification can 1441 be obtained from the IETF Secretariat. 1443 The IETF invites any interested party to bring to its attention any 1444 copyrights, patents or patent applications, or other proprietary 1445 rights which may cover technology that may be required to practice 1446 this standard. Please address the information to the IETF Executive 1447 Director. 1449 Disclaimer of Validity 1451 This document and the information contained herein are provided on an 1452 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1453 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1454 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1455 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1456 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1457 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1459 Copyright Statement 1461 Copyright (C) The Internet Society (2004). This document is subject 1462 to the rights, licenses and restrictions contained in BCP 78, and 1463 except as set forth therein, the authors retain all their rights.