idnits 2.17.1 draft-ietf-dna-link-information-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 22. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 785. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 796. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 803. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 809. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 15, 2007) is 6278 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2462 (Obsoleted by RFC 4862) ** Obsolete normative reference: RFC 2472 (Obsoleted by RFC 5072, RFC 5172) ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 2461 (Obsoleted by RFC 4861) Summary: 4 errors (**), 0 flaws (~~), 1 warning (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Krishnan, Ed. 3 Internet-Draft Ericsson Research 4 Intended status: Informational N. Montavont 5 Expires: August 19, 2007 LSIIT - University Louis Pasteur 6 E. Njedjou 7 France Telecom 8 S. Veerepalli 9 Qualcomm 10 A. Yegin, Ed. 11 Samsung AIT 12 February 15, 2007 14 Link-layer Event Notifications for Detecting Network Attachments 15 draft-ietf-dna-link-information-06 17 Status of this Memo 19 By submitting this Internet-Draft, each author represents that any 20 applicable patent or other IPR claims of which he or she is aware 21 have been or will be disclosed, and any of which he or she becomes 22 aware will be disclosed, in accordance with Section 6 of BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as Internet- 27 Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt. 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 This Internet-Draft will expire on August 19, 2007. 42 Copyright Notice 44 Copyright (C) The IETF Trust (2007). 46 Abstract 48 Certain network access technologies are capable of providing various 49 types of link-layer status information to IP. Link-layer event 50 notifications can help IP expeditiously detect configuration changes. 51 This document provides a non-exhaustive catalogue of information 52 available from well-known access technologies. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 58 3. Link-Layer Event Notifications . . . . . . . . . . . . . . . . 6 59 3.1. GPRS/3GPP . . . . . . . . . . . . . . . . . . . . . . . . 7 60 3.2. cdma2000/3GPP2 . . . . . . . . . . . . . . . . . . . . . . 8 61 3.3. IEEE 802.11/WiFi . . . . . . . . . . . . . . . . . . . . . 9 62 3.4. IEEE 802.3 CSMA/CD . . . . . . . . . . . . . . . . . . . . 10 63 3.4.1. Link Integrity Tests in 802.3 Networks . . . . . . . . 11 64 3.4.2. IEEE 802.1D Bridging and Its Effects on Link-layer 65 Event Notifications . . . . . . . . . . . . . . . . . 11 66 3.4.3. 802.1AB Link-Layer Discovery Protocol . . . . . . . . 13 67 3.4.4. Other heuristics . . . . . . . . . . . . . . . . . . . 13 68 3.4.5. Summary . . . . . . . . . . . . . . . . . . . . . . . 13 69 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 70 5. Security Considerations . . . . . . . . . . . . . . . . . . . 16 71 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 17 72 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 73 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 74 8.1. Normative References . . . . . . . . . . . . . . . . . . . 19 75 8.2. Informative References . . . . . . . . . . . . . . . . . . 21 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 77 Intellectual Property and Copyright Statements . . . . . . . . . . 24 79 1. Introduction 81 It is not an uncommon occurrence for a node to change its point of 82 attachment to the network. This can happen due to mobile usage 83 (e.g., a mobile phone moving among base stations) or nomadic usage 84 (e.g., road-warrior case). 86 A node changing its point of attachment to the network may end up 87 changing its IP subnet and therefore require re-configuration of IP- 88 layer parameters, such as IP address, default gateway information, 89 and DNS server address. Detecting the subnet change can usually use 90 network-layer indications (such as a change in the advertised 91 prefixes for IPv6). But such indications may not be always available 92 (e.g. DNAv6) to the node upon changing its point of attachment. 94 Additional information can be conveyed along with the event, such as 95 the identifier of the network attachment point (e.g., IEEE 802.11 96 BSSID and SSID), or network-layer configuration parameters obtained 97 via the link-layer attachment process if available. It is envisaged 98 that such event notifications can in certain circumstances be used to 99 expedite the inter-subnet movement detection and reconfiguration 100 process. For example, the notification indicating that the node has 101 established a new link-layer connection may be used for immediately 102 probing the network for a possible configuration change. In the 103 absence of such a notification from the link layer, IP has to wait 104 for indications that are not immediately available, such as receipt 105 of next scheduled router advertisement, unreachability of the default 106 gateway, etc. 108 It should be noted that a link-layer event notification does not 109 always translate into a subnet change. Even if the node has torn 110 down a link-layer connection with one attachment point and 111 established a new connection with another, it may still be attached 112 to the same IP subnet. For example, several IEEE 802.11 access 113 points can be attached to the same IP subnet. Moving among these 114 access points does not warrant any IP-layer configuration change. 116 In order to enable an enhanced scheme for detecting change of subnet, 117 we need to define link-layer event notifications that can be 118 realistically expected from various access technologies. The 119 objective of this draft is to provide a catalogue of link-layer 120 events and notifications in various architectures. While this 121 document mentions the utility of this information for detecting 122 change of subnet (or, detecting network attachment - DNA), the 123 detailed usage is left to other documents, namely DNA solution 124 specifications. 126 The document limits itself to the minimum set of information that is 127 necessary for solving the DNA problem [RFC4135]. A broader set of 128 information (e.g., signal strength, packet loss, etc.) and events 129 (e.g. link down) may be used for other problem spaces, such as 130 anticipation-based Mobile IP fast handovers 131 [I-D.ietf-mobileip-lowlatency-handoffs-v4], 132 [I-D.ietf-mipshop-fast-mipv6] etc. 134 These event notifications are considered with hosts in mind, although 135 they may also be available on the network side (e.g., on the access 136 points and routers). An API or protocol-based standard interface may 137 be defined between the link layer and IP for conveying this 138 information. That activity is beyond the scope of this document. 140 2. Terminology 142 Link: is a communication facility or medium over which network nodes 143 can communicate. Each link is associated with a minimum of two 144 endpoints. An "attachment point" is the link endpoint on the link to 145 which the node is currently connected, such as an access point, a 146 base station, or a wired switch. 148 Link up: is an event provided by the link layer that signifies a 149 state change associated with the interface becoming capable of 150 communicating data packets. This event is associated with a link- 151 layer connection between the node and an attachment point. 153 BSSID: Basic Service Set Identification 155 DNA: Detecting Network Attachment 157 GPRS: GSM Packet Radio System 159 PDP: Packet Data Protocol 161 SSID: Service Set Identifier 163 3. Link-Layer Event Notifications 165 Link-layer event notifications are considered to be one of the inputs 166 to the DNA process. A DNA process is likely to take other inputs 167 (e.g., presence of advertised prefixes, reachability of default 168 gateways) before determining whether IP-layer configuration must be 169 updated. It is expected that the DNA process can take advantage of 170 link-layer notifications when they are made available to IP. While 171 by itself a link-layer notification may not constitute all the input 172 DNA needs, it can at least be useful for prompting the DNA process to 173 collect further information (i.e., other inputs to the process). For 174 example, the node may send a router solicitation as soon as it learns 175 that a new link-layer connection is established. 177 The link-layer event that is considered most useful to DNA process is 178 the link up event. The associated notifications can be provided to 179 the IP-layer after the event concludes successfully. The link up 180 events and notifications are associated with a network interface on 181 the node. The IP module may receive simultaneous independent 182 notifications from each one of the network interfaces on the node. 184 The actual event is managed by the link layer of the node through 185 execution of link-layer protocols and mechanisms. Once the event 186 successfully completes within the link layer, its notification must 187 be delivered to the IP-layer. By the time the notification is 188 delivered, the link layer of the node must be ready to accept IP 189 packets from the IP and the physical-layers. Each time an interface 190 changes its point of attachment, a link up event should be generated. 192 There is a non-deterministic usage of the link up notification to 193 accomodate implementations that desire to indicate the link is up but 194 the data transmission may be blocked in the network (see IEEE 802.3 195 discussion). A link up notification may be generated with an 196 appropriate attribute, conveying its non-deterministic nature, to 197 convey the event. Alternatively, the link-layer implementation may 198 choose to delay the link up notification until the risk conditions 199 cease to exist. 201 If a non-deterministic link up was generated, another link up must 202 follow as soon as the link layer is capable of generating a 203 deterministic notification. The event attributes may indicate 204 whether the packets transmitted since the previous notification were 205 presumed to be blocked or allowed by the network, if the link layer 206 could determine the exact conditions. 208 The deterministic link up event following a non-deterministic link up 209 event can be treated differently by consumers of the link up event. 210 e.g. The second link up event need not trigger a confirmation 211 process, if the first one already did. 213 A node may have to change its IP-layer configuration even when the 214 link-layer connection stays the same. An example scenario is the 215 IPv6 subnet renumbering [RFC2461]. Therefore, there exist cases 216 where IP-layer configuration may have to change even without the IP 217 layer receiving a link up notification. Therefore, a link-layer 218 notification is not a mandatory indication of a subnet change. 220 A link up notification may optionally deliver information relating to 221 the attachment point. Such auxiliary information may include the 222 identity of the attachment point (e.g., base station identifier), or 223 the IP-layer configuration parameters associated with the attached 224 subnet (e.g., subnet prefix, default gateway address, etc.). While 225 merely knowing that a new link-layer connection is established may 226 prompt the DNA process to immediately seek other clues for detecting 227 a network configuration change, auxiliary information may constitute 228 further clues (and even the final answers sometimes). In cases where 229 there is a one-to-one mapping between the attachment point 230 identifiers and the IP-layer configurations, learning the former can 231 reveal the latter. Furthermore, IP-layer configuration parameters 232 obtained during the link-layer connection may be exactly what the DNA 233 process is trying to discover. 235 The link-layer process leading to a link up event depends on the link 236 technology. While a link-layer notification must always indicate 237 that the link up event occurred, the availability and types of 238 auxiliary information on the attachment point depends on the link- 239 layer technology as well. The following subsections examine four 240 link-layer technologies and describe when a link-layer notification 241 must be generated and what information must be included in it. 243 3.1. GPRS/3GPP 245 GSM Packet Radio System (GPRS) provides packet switched data 246 transmission over a cellular network[GPRS][GPRS-LINK]. 248 The GPRS architecture consists of a Radio Access Network and a packet 249 domain Core Network. 251 - The GPRS Radio Access Network is composed of Mobile Terminals (MT), 252 a Base Station Subsystem and Serving GPRS Support Nodes (SGSN). 254 - An IP Core Network that acts as the transport backbone of user 255 datagrams between SGSNs and Gateway GPRS Support Nodes (GGSN). The 256 GGSN ensures the GPRS IP core network connectivity with external 257 networks, such as the Internet or Local Area Networks. The GGSN acts 258 as the default IP gateway for the MT. 260 A GPRS MT that wants to establish IP connectivity establishes first a 261 connection to the GPRS network and one or more PDP Context 262 associations between the MT and the GGSN. It is only after the PDP 263 Context has been established, address autoconfiguration and tunneling 264 mechanism have taken place that the MT's IP packets can be forwarded 265 to and from its remote IP peers. The aim of PDP Context 266 establishment is also to provide IP-level configuration on top of the 267 GPRS link-layer attachment. 269 Successful establishment of a PDP Context on a GPRS link signifies 270 the availability of IP service to the MT. Therefore, this link-layer 271 event must generate a link up event notification sent to the IP 272 layer. 274 An MT has the possibility to establish a secondary PDP Context while 275 re-using the IP configuration acquired from a previously established 276 and active PDP Context. Such a secondary PDP Context does not 277 provide additional information to the IP layer and only allows 278 another QoS profile to be used. The activation of such a secondary 279 PDP context does not usually generate a link up event since it does 280 not require new IP parameters. However, other additional PDP Context 281 activiations are to be treated as indicated earlier. 283 With IPv4, the auxiliary information carried along with this 284 notification must be the IPv4 address of the MT which is obtained as 285 part of the PDP Context. With IPv6, the PDP Context activation 286 response does not come along with a usable IPv6 address. 287 Effectively, the IPv6 address received from the GGSN in the PDP 288 address field of the message does not contain a valid prefix. The MN 289 actually only uses the interface-identifier extracted from that field 290 to form a link-local address, that it uses afterwards to obtain a 291 valid prefix (e.g., by stateless [RFC2462][GPRS-CN] or stateful 292 [RFC3315] [GPRS-GSSA] address configuration). Therefore no IPv6- 293 related auxiliary information is provided to the IP layer. 295 3.2. cdma2000/3GPP2 297 cdma2000-based 3GPP2 packet data services provide mobile users wide 298 area high-speed access to packet switched networks [CDMA2K]. Some of 299 the major components of the 3GPP2 packet network architecture consist 300 of: 302 - Mobile Station (MS), which allows mobile access to packet-switched 303 networks over a wireless connection. 305 - Radio Access Network, which consists of the Base Station 306 Transceivers, Base Station Controllers, and the Packet Control 307 Function. 309 - Network Access Server known as the Packet Data Switching Node 310 (PDSN). The PDSN also serves as default IP gateway for the IP MS. 312 3GPP2 networks use the Point-to-Point Protocol (PPP [RFC1661]) as the 313 link-layer protocol between the MS and the PDSN. Before any IP 314 packets may be sent or received, PPP must reach the Network-Layer 315 Protocol phase, and the IP Control Protocol (IPCP [RFC1332], IPV6CP 316 [RFC2472]) reach the Opened state. When these states are reached in 317 PPP, a link up event notification must be delivered to the IP layer. 319 When the PPP is used for 3GPP2 Simple (i.e., non-Mobile) IPv4 320 Service, IPCP enables configuration of an IPv4 address on the MS. 321 This IPv4 address must be provided as the auxiliary information along 322 with the link up notification. IPV6CP used for Simple IPv6 service 323 does not provide an IPv6 address, but the interface identifiers for 324 local and remote endpoints of the PPP link. Since there is no 325 standards-mandated correlation between the interface identifier and 326 other IP-layer configuration parameters, this information is deemed 327 not useful for DNA (nevertheless it may be provided as auxiliary 328 information for other uses). 330 3.3. IEEE 802.11/WiFi 332 IEEE 802.11-based WiFi networks are the wireless extension of the 333 Local Area Networks. Currently available standards are IEEE 802.11b 334 [IEEE-802.11b], IEEE 802.11g [IEEE-802.11g], and IEEE 802.11a 335 [IEEE-802.11a]. The specifications define both the MAC-layer and the 336 physical-layer. The MAC layer is the same for all these 337 technologies. 339 Two operating modes are available in the IEEE 802.11 series, either 340 infrastructure mode or ad-hoc mode. In infrastructure mode, all 341 link-layer frames are transmitted to an access point (AP) which then 342 forwards them to the final receiver. A station (STA) establishes an 343 IEEE 802.11 association with an AP in order to send and receive IP 344 packets. In a WiFi network that uses Robust Secure Network (RSN 345 [IEEE-802.11i]), successful completion of the 4-way handshake between 346 the STA and AP commences the availability of IP service. The link up 347 event notification must be generated upon this event. In non-RSN- 348 based networks, successful association or re-association events on 349 the link layer must cause a link up notification sent to the IP- 350 layer. 352 As part of the link establishment, the STA learns the Basic Service 353 Set Identification (BSSID) and Service Set Identifier (SSID) 354 associated with the AP. The BSSID is a unique identifier of the AP, 355 usually set to the MAC address of the wireless interface of the AP. 356 The SSID carries the identifier of the Extended Service Set (ESS) - 357 the set composed of APs and associated STAs that share a common 358 distribution system. BSSID and SSID may be provided as auxiliary 359 information along with the link up notification. Unfortunately this 360 information does not provide a deterministic indication of whether 361 the IP-layer configuration must be changed upon movement. There is 362 no standards-mandated one-to-one relation between the BSSID/SSID 363 pairs and IP subnets. An AP with a given BSSID can connect a STA to 364 any one of multiple IP subnets. Similarly, an ESS with the given 365 SSID may span multiple IP subnets. And finally, the SSIDs are not 366 globally unique. The same SSID may be used by multiple independent 367 ESSs. Nevertheless, BSSID/SSID information may be used in a 368 probabilistic way by the DNA process, hence it is provided with the 369 link up event notification. 371 In ad-hoc mode, mobile stations (STA) in range may directly 372 communicate with each other, i.e., without any infrastructure or 373 intermediate hop. The set of communicating STAs is called IBSS for 374 Independent Basic Service Set. In an IBSS, only STA services are 375 available, i.e. authentication, deauthentication, privacy and MSDU 376 delivery. STAs do not associate with each other, and therefore may 377 exchange data frames in state 2 (authenticated and not associated) or 378 even in state 1 (unauthenticated and unassociated) if the 379 Distribution System is not used (i.e., "To DS" and "From DS" bits are 380 clear). If authentication is performed, a link up indication can be 381 generated upon authentication. Concerning the link layer 382 identification, both the BSSID (which is a random MAC address chosen 383 by a STA of the IBSS) and SSID may be used to identify a link, but 384 not to make any assumptions on the IP network configuration. 386 3.4. IEEE 802.3 CSMA/CD 388 IEEE 802.3 CSMA/CD (commonly referred to as Ethernet) is the most 389 commonly deployed Local Area Network technology in use today. As 390 deployed today, it is specified by a physical layer/medium access 391 control (MAC) layer specification [IEEE-802.3]. In order to provide 392 connection of different LANs together into a larger network, 802.3 393 LANs are often bridged together [IEEE-802.1D]. 395 In this section, the terms 802.3 and Ethernet are used 396 interchangeably. This section describes some issues in providing 397 link-layer indications on Ethernet networks, and shows how bridging 398 affects these indications. 400 In Ethernet networks, hosts are connected by wires or by optic fibre 401 to a switch (bridge), a bus (e.g., co-axial cable), a repeater (hub), 402 or directly to another Ethernet device. Interfaces are symmetric, in 403 that while many different physical layers may be present, medium 404 access control is uniform for all devices. 406 In order to determine whether the physical medium is ready for frame 407 transfer, IEEE 802.3 Ethernet specifies its own link monitoring 408 mechanism, which is defined for some, but not all classes of media. 409 Where available, this Link Integrity Test operation is used to 410 identify when packets are able to be received on an Ethernet segment. 411 It is applicable to both wired and optical physical layers, although 412 details vary between technologies (link pulses in twisted pair 413 copper, light levels in fibre). 415 3.4.1. Link Integrity Tests in 802.3 Networks 417 Link Integrity Tests in 802.3 networks typically occur at initial 418 physical connection time (for example, at the auto-negotiation 419 stage), and periodically afterwards. It makes use of physical-layer 420 specific operations to determine if a medium is able to support link- 421 layer frames [IEEE-802.3]. 423 The status of the link as determined by the Link Integrity Test is 424 stored in the variable 'link_status'. Changes to the value of 425 link_status (for example due to Link Integrity Test failure) will 426 generate link indications if the technology dependent interface is 427 implemented on an Ethernet device [IEEE-802.3]. 429 The link_status has possible values of FAIL, READY and OK. When an 430 interface is in FAIL state, Link Integrity Tests have failed. Where 431 status is READY, the link segment has passed integrity tests, but 432 autonegotiation has not completed. OK state indicates that the 433 medium is able to send and receive packets. 435 Upon transition to a particular state the Physical Medium Attachment 436 subsystems generates a PMA_LINK.indicate(link_status). Indications 437 of OK state may be used to generate a link up event notification. 438 These indications do not definitively ensure that packets will be 439 able to be received through the bridge domain, though [see the next 440 section]. Such operations are governed by bridging. 442 3.4.2. IEEE 802.1D Bridging and Its Effects on Link-layer Event 443 Notifications 445 Ethernet networks commonly consist of LANs joined together by 446 transparent bridges (usually implemented as switches). Transparent 447 bridges require the active topology to be loop free. This is 448 achieved through the Spanning Tree Protocol (STP) or the Rapid 449 Spanning Tree Protocol (RSTP). These protocols exchange Bridge 450 Protocol Data Units (BPDUs), as defined in [IEEE-802.1D], which leads 451 to, where required, the blocking of ports (i.e., not forwarding). 453 By default, the spanning tree protocol does not know whether a 454 particular newly connected piece of Ethernet will cause a loop. 456 Therefore it will block all traffic from and to newly connected ports 457 with the exception of some unbridged management frames. The STP will 458 determine if the port can be connected to the network in a loop-free 459 manner. 461 For these technologies, even though the link layer appears available, 462 no data packet forwarding will occur until it is determined that the 463 port can be connected to the network in a loop-free environment. 465 For hosts which are providing indications to upper layer protocols, 466 even if the host itself does not implement bridging or STP, packet 467 delivery across the network can be affected by the presence of 468 bridges. 470 A host connected to a bridge port does not receive any explicit 471 indication that the bridge has started forwarding packets. 472 Therefore, a host may not know when STP operations have completed, 473 and when it is safe to inform upper layers to transmit packets. 475 Where it is not known that forwarding operations are available, a 476 host should assume that RSTP or STP is being performed. Hosts may 477 listen to STP/RSTP and 802.1AB messages to gain further information 478 about the timing of full connectivity on the link, for example, to 479 override an existing indication. 481 Notably, though, it is not easy for a host to distinguish between 482 Disabled bridge ports and non-bridge ports with no active 483 transmitters on them, as Disabled ports will have no traffic on them, 484 and incur 100% sender loss. 486 If no bridge configuration messages are received within the 487 Bridge_Max_Age interval (default 20s), then it is likely that there 488 is no visible bridge whose port is enabled for bridging (S8.4.5 of 489 [IEEE-802.1D]), since at least two BPDU hello messages would have 490 been lost. Upon this timeout, a link up notification must be 491 generated, if one has not been already. 493 If a BPDU is received, and the adjacent bridge is running the 494 original Spanning Tree Protocol, then a host cannot successfully send 495 packets until at least twice the ForwardDelay value in the received 496 BPDU has elapsed. After this time, a link up notification must be 497 generated. If the previous link up notification was non- 498 deterministic, then this notification includes an attribute 499 signifying that the packets sent within the prior interval were lost. 501 If the bridge is identified as performing Rapid Spanning Tree 502 Protocol (RSTP), it instead waits Bridge_Max_Age after packet 503 reception (advertised in the BPDU's Max Age field), before 504 forwarding. For ports which are known to be point-to-point through 505 autonegotiation, this delay is abbreviated to 3 seconds after 506 autonegotiation completes [IEEE-802.1D]. 508 3.4.3. 802.1AB Link-Layer Discovery Protocol 510 The recently defined 802.1AB Link-Layer Discovery Protocol (LLDP) 511 provides information to devices which are directly adjacent to them 512 on the local LAN [IEEE-802.1ab]. 514 LLDP sends information periodically, and at link status change time 515 to indicate the configuration parameters of the device. Devices may 516 either send or receive these messages, or both. 518 The LLDP message may contain a System Capabilities TLV, which 519 describes the MAC and IP layer functions which a device is currently 520 using. Where a host receives the Systems Capabilities TLV which 521 indicate that no Bridging is occurring on the LLDP transmitter, no 522 delays for STP calculation will be applied to packets sent through 523 this transmitter. This would allow the generation of a link up 524 notification. 526 Additionally, if a host receives a Systems Capabilities TLV which 527 indicates that the LLDP transmitter is a bridge, the host's 528 advertisement that it is an (end-host) Station-Only, may tell the 529 bridge not to run STP, and immediately allow forwarding. 531 Proprietary extensions may also indicate that data forwarding is 532 already available on such a port. Discussion of such optimizations 533 is out of scope for this document. 535 Because the protocol is new and not widely deployed, it is unclear 536 how this protocol will eventually affect DNA in IPv4 or IPv6 537 networks. 539 3.4.4. Other heuristics 541 In 802.3 networks, NICs are often capable of returning a speed and 542 duplex indication to the host, and that changes in these 543 characteristics may indicate a connection to a new layer 2 network. 545 3.4.5. Summary 547 Link-Layer indications in Ethernet-like networks are complicated by 548 additional unadvertised delays due to Spanning Tree calculations. 549 This may cause re-indication or retraction of indications previously 550 sent to upper layer protocols. 552 4. IANA Considerations 554 This document has no actions for IANA. 556 5. Security Considerations 558 Attackers may spoof various indications at the link layer, or 559 manipulate the physical medium directly in an effort to confuse the 560 host about the state of the link layer. For instance, attackers may 561 spoof error messages or disturb the wireless medium to cause the host 562 to move its connection elsewhere or to even disconnect. Attackers 563 may also spoof information to make the host believe it has a 564 connection when, in reality, it does not. In addition, wireless 565 networks such as 802.11 are susceptible to an attack called the "Evil 566 Twin" attack where an attacker sets up an Access Point with the same 567 SSID as a legitimate one and gets the use to connect to the fake 568 access point instead of the real one. These attacks may cause use of 569 non-preferred networks or even denial of service. 571 This specification does not provide any protection of its own for the 572 indications from the lower layers. But the vulnerabilities can be 573 mitigated through the use of techniques in other parts of the 574 protocol stack. In particular, it is recommended that 575 authentication, replay and integrity protection of link-layer 576 management messages is enabled when available. e.g. The IEEE 802.1ae 577 standard [IEEE-802.1ae] defines such mechanisms for IEEE 802 578 compliant MAC layers. Additionally, the protocol stack may also use 579 some network layer mechanisms to achieve partial protection. For 580 instance, SEND [RFC3971] could be used to confirm secure reachability 581 with a router. However, network layer mechanisms are unable to deal 582 with all problems, such as with insecure lower layer notifications 583 that lead to the link not functioning properly. 585 6. Contributors 587 In addition to the people listed in the author list, text for the 588 specific link-layer technologies covered by this document was 589 contributed by Thomas Noel (IEEE 802.11b), and Greg Daley (IEEE 590 802.3). The authors would like to thank them for their efforts in 591 bringing this document to fruition. 593 7. Acknowledgements 595 The authors would like to acknowledge Bernard Aboba, Sanjeev Athalye, 596 JinHyeock Choi, John Loughney, Pekka Nikander, Brett Pentland, Tom 597 Petch, Dan Romascanu, Pekka Savola, Steve Bellovin, Thomas Narten, 598 Matt Mathis, Alfred Hoenes and Muhammad Mukarram bin Tariq for their 599 useful comments and suggestions. 601 8. References 603 8.1. Normative References 605 [CDMA2K] "IS-835 - cdma2000 Wireless IP Network Standard", . 607 [GPRS] "Digital cellular telecommunications system (Phase 2+); 608 General Packet Radio Service (GPRS) Service description; 609 Stage 2", 3GPP TS 03.60 version 7.9.0 Release 98. 611 [GPRS-LINK] 612 "Digital cellular telecommunications system (Phase 2+); 613 Radio subsystem link control", 3GPP GSM 03.05 version 614 7.0.0 Release 98. 616 [IEEE-802.11a] 617 Institute of Electrical and Electronics Engineers, "IEEE 618 Std 802.11a-1999, supplement to IEEE Std 802.11-1999, Part 619 11: Wireless MAN Medium Access Control (MAC) and Physical 620 Layer (PHY) specifications: High-speed Physical Layer in 621 the 5 GHZ band", IEEE Standard 802.11a, September 1999. 623 [IEEE-802.11b] 624 Institute of Electrical and Electronics Engineers, "IEEE 625 Std 802 Part 11, Information technology - 626 Telecomunications and information exchange between systems 627 - Local and metropolitan area networks - Specific 628 requirements - Part 11: Wireless Lan Medium Access Control 629 (MAC) And Physical Layer (PHY) Specifications", 630 IEEE Standard 802.11b, August 1999. 632 [IEEE-802.11g] 633 Institute of Electrical and Electronics Engineers, "IEEE 634 Std 802.11g-2003, Amendment to IEEE Std 802.11, 1999 635 edition, Part 11: Wireless MAN Medium Access Control (MAC) 636 and Physical Layer (PHY) specifications. Amendment 4: 637 Further Higher Data Rate Extension in the 2.4 GHz Band", 638 IEEE Standard 802.11g, June 2003. 640 [IEEE-802.11i] 641 Institute of Electrical and Electronics Engineers, 642 "Supplement to STANDARD FOR Telecommunications and 643 Information Exchange between Systems - LAN/MAN Specific 644 Requirements - Part 11: Wireless Medium Access Control 645 (MAC) and physical layer (PHY) specifications: 646 Specification for Enhanced Security", IEEE IEEE 802.11i, 647 December 2004. 649 [IEEE-802.1D] 650 Institute of Electrical and Electronics Engineers, "IEEE 651 standard for local and metropolitan area networks - common 652 specifications - Media access control (MAC) Bridges", ISO/ 653 IEC IEEE Std 802.1D, 2004. 655 [IEEE-802.1ab] 656 Institute of Electrical and Electronics Engineers, "Draft 657 Standard for Local and Metropolitan Networks: Station and 658 Media Access Control Connectivity Discovery (Draft 13)", 659 IEEE draft Std 802.1AB, 2004. 661 [IEEE-802.1ae] 662 Institute of Electrical and Electronics Engineers, "IEEE 663 Std 802.1AE, Local and Metropolitan Area Networks - Media 664 Access Control (MAC) Security", IEEE Standard 802.1ae, 665 June 2006. 667 [IEEE-802.3] 668 Institute of Electrical and Electronics Engineers, "IEEE 669 standard for local and metropolitan area networks - 670 Specific Requirements, Part 3: Carrier Sense Multiple 671 Access with Collision Detection (CSMA/CD) Access Method 672 and Physical Layer Specifications", ISO/IEC IEEE 673 Std 802.3, 2002. 675 [RFC1332] McGregor, G., "The PPP Internet Protocol Control Protocol 676 (IPCP)", RFC 1332, May 1992. 678 [RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, 679 RFC 1661, July 1994. 681 [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address 682 Autoconfiguration", RFC 2462, December 1998. 684 [RFC2472] Haskin, D. and E. Allen, "IP Version 6 over PPP", 685 RFC 2472, December 1998. 687 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 688 and M. Carney, "Dynamic Host Configuration Protocol for 689 IPv6 (DHCPv6)", RFC 3315, July 2003. 691 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 692 Neighbor Discovery (SEND)", RFC 3971, March 2005. 694 [RFC4135] Choi, JH. and G. Daley, "Goals of Detecting Network 695 Attachment in IPv6", RFC 4135, August 2005. 697 8.2. Informative References 699 [GPRS-CN] "Technical Specification Group Core Network; 700 Internetworking between the Public Land Mobile Network 701 (PLMN) supporting packet based services and Packet Data 702 Networks (PDN) (Release 6)", 3GPP TS 29.061 version 6.1.0 703 2004-06. 705 [GPRS-GSSA] 706 "Technical Specification Group Services and System Aspect; 707 General Packet Radio Service (GPRS) Service description; 708 Stage 2 (Release 6)", 3GPP TS 23.060 version 6.5.0 709 2004-06. 711 [I-D.ietf-mipshop-fast-mipv6] 712 Koodli, R., "Fast Handovers for Mobile IPv6", 713 draft-ietf-mipshop-fast-mipv6-03 (work in progress), 714 October 2004. 716 [I-D.ietf-mobileip-lowlatency-handoffs-v4] 717 Malki, K., "Low Latency Handoffs in Mobile IPv4", 718 draft-ietf-mobileip-lowlatency-handoffs-v4-11 (work in 719 progress), October 2005. 721 [RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor 722 Discovery for IP Version 6 (IPv6)", RFC 2461, 723 December 1998. 725 Authors' Addresses 727 Suresh Krishnan (editor) 728 Ericsson Research 729 8400 Decarie Blvd. 730 Town of Mount Royal, QC 731 Canada 733 Email: suresh.krishnan@ericsson.com 735 Nicolas Montavont 736 LSIIT - University Louis Pasteur 737 Pole API, bureau C428 738 Boulevard Sebastien Brant 739 Illkirch 67400 740 France 742 Phone: +33 390 244 587 743 Email: montavont@dpt-info.u-strasbg.fr 745 Eric Njedjou 746 France Telecom 747 4, Rue du Clos Courtel BP 91226 748 Cesson Sevigne 35512 749 France 751 Phone: +33 299124202 752 Email: eric.njedjou@orange-ftgroup.com 754 Siva Veerepalli 755 Qualcomm 756 5775 Morehouse Drive 757 San Diego, CA 92131 758 USA 760 Phone: +1 858 658 4628 761 Email: sivav@qualcomm.com 762 Alper E. Yegin (editor) 763 Samsung Advanced Institute of Technology 764 75 West Plumeria Drive 765 San Jose, CA 95134 766 USA 768 Phone: +1 408 544 5656 769 Email: alper01.yegin@partner.samsung.com 771 Full Copyright Statement 773 Copyright (C) The IETF Trust (2007). 775 This document is subject to the rights, licenses and restrictions 776 contained in BCP 78, and except as set forth therein, the authors 777 retain all their rights. 779 This document and the information contained herein are provided on an 780 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 781 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 782 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 783 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 784 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 785 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 787 Intellectual Property 789 The IETF takes no position regarding the validity or scope of any 790 Intellectual Property Rights or other rights that might be claimed to 791 pertain to the implementation or use of the technology described in 792 this document or the extent to which any license under such rights 793 might or might not be available; nor does it represent that it has 794 made any independent effort to identify any such rights. Information 795 on the procedures with respect to rights in RFC documents can be 796 found in BCP 78 and BCP 79. 798 Copies of IPR disclosures made to the IETF Secretariat and any 799 assurances of licenses to be made available, or the result of an 800 attempt made to obtain a general license or permission for the use of 801 such proprietary rights by implementers or users of this 802 specification can be obtained from the IETF on-line IPR repository at 803 http://www.ietf.org/ipr. 805 The IETF invites any interested party to bring to its attention any 806 copyrights, patents or patent applications, or other proprietary 807 rights that may cover technology that may be required to implement 808 this standard. Please address the information to the IETF at 809 ietf-ipr@ietf.org. 811 Acknowledgment 813 Funding for the RFC Editor function is provided by the IETF 814 Administrative Support Activity (IASA).