idnits 2.17.1 draft-ietf-dna-link-information-05.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 on line 807. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 784. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 791. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 797. ** 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. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 317 has weird spacing: '...ss, but the i...' -- 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 (November 5, 2006) is 6375 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'DNA4' is mentioned on line 361, but not defined == Missing Reference: 'RFC 3971' is mentioned on line 566, but not defined == Unused Reference: 'IEEE-802.11a' is defined on line 602, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-mobileip-lowlatency-handoffs-v4' is defined on line 696, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'CDMA2K' -- Possible downref: Non-RFC (?) normative reference: ref. 'GPRS' -- Possible downref: Non-RFC (?) normative reference: ref. 'GPRS-LINK' -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE-802.11a' -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE-802.11b' -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE-802.11g' -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE-802.11i' -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE-802.1D' -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE-802.1ab' -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE-802.3' ** 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) ** Downref: Normative reference to an Informational RFC: RFC 4135 -- Obsolete informational reference (is this intentional?): RFC 2461 (Obsoleted by RFC 4861) Summary: 7 errors (**), 0 flaws (~~), 7 warnings (==), 18 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 Expires: May 9, 2007 N. Montavont 5 LSIIT - University Louis Pasteur 6 E. Njedjou 7 France Telecom 8 S. Veerepalli 9 Qualcomm 10 A. Yegin, Ed. 11 Samsung AIT 12 November 5, 2006 14 Link-layer Event Notifications for Detecting Network Attachments 15 draft-ietf-dna-link-information-05 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 May 9, 2007. 42 Copyright Notice 44 Copyright (C) The Internet Society (2006). 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 1.1 Requirements notation . . . . . . . . . . . . . . . . . . 4 58 2. Link-Layer Event Notifications . . . . . . . . . . . . . . . . 5 59 2.1 GPRS/3GPP . . . . . . . . . . . . . . . . . . . . . . . . 6 60 2.2 cdma2000/3GPP2 . . . . . . . . . . . . . . . . . . . . . . 7 61 2.3 IEEE 802.11/WiFi . . . . . . . . . . . . . . . . . . . . . 8 62 2.4 IEEE 802.3 CSMA/CD . . . . . . . . . . . . . . . . . . . . 9 63 2.4.1 Link Integrity Tests in 802.3 Networks . . . . . . . . 10 64 2.4.2 IEEE 802.1D Bridging and Its Effects on Link-layer 65 Event Notifications . . . . . . . . . . . . . . . . . 10 66 2.4.3 802.1AB Link-Layer Discovery Protocol . . . . . . . . 12 67 2.4.4 Summary . . . . . . . . . . . . . . . . . . . . . . . 13 68 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 69 4. Security Considerations . . . . . . . . . . . . . . . . . . . 15 70 5. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 16 71 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 72 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 73 7.1 Normative References . . . . . . . . . . . . . . . . . . . 18 74 7.2 Informative References . . . . . . . . . . . . . . . . . . 19 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 20 76 A. Change History . . . . . . . . . . . . . . . . . . . . . . . . 22 77 Intellectual Property and Copyright Statements . . . . . . . . 23 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 generally reliance on such indications does 92 not yield rapid detection, since these indications are not readily 93 available upon node changing its point of attachment. 95 Additional information can be conveyed along with the event, such as 96 the identifier of the network attachment point (e.g., IEEE 802.11 97 BSSID and SSID), or network-layer configuration parameters obtained 98 via the link-layer attachment process if available. It is envisaged 99 that such event notifications can in certain circumstances be used to 100 expedite the inter-subnet movement detection and reconfiguration 101 process. For example, the notification indicating that the node has 102 established a new link-layer connection MAY be used for immediately 103 probing the network for a possible configuration change. In the 104 absence of such a notification from the link-layer, IP has to wait 105 for indications that are not immediately available, such as receipt 106 of next scheduled router advertisement, unreachability of the default 107 gateway, etc. 109 It should be noted that a link-layer event notification does not 110 always translate into a subnet change. Even if the node has torn 111 down a link-layer connection with one attachment point and 112 established a new connection with another, it may still be attached 113 to the same IP subnet. For example, several IEEE 802.11 access 114 points can be attached to the same IP subnet. Moving among these 115 access points does not warrant any IP-layer configuration change. 117 In order to enable an enhanced scheme for detecting change of subnet, 118 we need to define link-layer event notifications that can be 119 realistically expected from various access technologies. The 120 objective of this draft is to provide a catalogue of link-layer 121 events and notifications in various architectures. While this 122 document mentions the utility of this information for detecting 123 change of subnet (or, detecting network attachment - DNA), the 124 detailed usage is left to other documents, namely DNA solution 125 specifications. 127 The document limits itself to the minimum set of information that is 128 necessary for solving the DNA problem [RFC4135]. A broader set of 129 information (e.g., signal strength, packet loss, etc.) and events 130 (e.g. link down) may be used for other problem spaces, such as 131 anticipation-based Mobile IP fast handovers [I-D.ietf-mobileip- 132 lowlatency-handoffs-v4] 133 [I-D.ietf-mipshop-fast-mipv6]. Separate documents that are backward- 134 compatible with this one can be generated to discuss further 135 enhancements. 137 These event notifications are considered with hosts in mind, although 138 they may also be available on the network side (e.g., on the access 139 points and routers). An API or protocol-based standard interface may 140 be defined between the link-layer and IP for conveying this 141 information. That activity is beyond the scope of this document. 143 1.1 Requirements notation 145 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 146 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 147 document are to be interpreted as described in [RFC2119]. 149 2. Link-Layer Event Notifications 151 Link-layer event notifications are considered to be one of the inputs 152 to the DNA process. A DNA process is likely to take other inputs 153 (e.g., presence of advertised prefixes, reachability of default 154 gateways) before determining whether IP-layer configuration must be 155 updated. It is expected that the DNA process can take advantage of 156 link-layer notifications when they are made available to IP. While 157 by itself a link-layer notification may not constitute all the input 158 DNA needs, it can at least be useful for prompting the DNA process to 159 collect further information (i.e., other inputs to the process). For 160 example, the node may send a router solicitation as soon as it learns 161 that a new link-layer connection is established. 163 The link-layer event that is considered most useful to DNA process is 164 the link up event. The associated notifications can be provided to 165 the IP-layer after the event concludes successfully. The link up 166 events and notifications are associated with a network interface on 167 the node. The IP module may receive simultaneous independent 168 notifications from each one of the network interfaces on the node. 170 "Link" is a communication facility or medium over which network nodes 171 can communicate. Each link is associated with a minimum of two 172 endpoints. An "attachment point" is the link endpoint on the link to 173 which the node is currently connected, such as an access point, a 174 base station, or a wired switch. 176 "Link up" is an event provided by the link-layer that signifies a 177 state change associated with the interface becoming capable of 178 communicating data packets. This event is associated with a link- 179 layer connection between the node and an attachment point. 181 The actual event is managed by the link-layer of the node through 182 execution of link-layer protocols and mechanisms. Once the event 183 successfully completes within the link-layer, its notification MUST 184 be delivered to the IP-layer. By the time the notification is 185 delivered, the link-layer of the node MUST be ready to accept IP 186 packets from the IP and the physical-layers. Each time an interface 187 changes its point of attachment, a link up event SHOULD be generated. 189 There is a non-deterministic usage of link up notification to 190 accomodate implementations that desire to indicate the link is up but 191 the data transmission may be blocked in the network (see IEEE 802.3 192 discussion). A link up notification MAY be generated with an 193 appropriate attribute (e.g., "risk" indicated by R-flag) to convey 194 the event. Alternatively, the link-layer implementation MAY choose 195 to delay the link up notification until the risk conditions cease to 196 exist. 198 If a link up with the R-flag set was generated, another link up MUST 199 follow up as soon as the link-layer is capable of generating a 200 deterministic notification. The event attributes MUST indicate 201 whether the packets transmitted since the previous notification were 202 presumed to be blocked (B-flag) or allowed (A-flag) by the network if 203 the link-layer could determine the exact conditions. If the link- 204 layer cannot make a determination about the fate of these packets, it 205 MUST generate a link up without any additional indications (no flags 206 set). 208 A node may have to change its IP-layer configuration even when the 209 link-layer connection stays the same. An example scenario is the 210 IPv6 subnet renumbering [RFC2461]. Therefore, there exist cases 211 where IP-layer configuration may have to change even without the IP- 212 layer receiving a link up notification. Therefore, a link-layer 213 notification is not a mandatory indication of a subnet change. 215 A link up notification may optionally deliver information relating to 216 the attachment point. Such auxiliary information may include 217 identity of the attachment point (e.g., base station identifier), or 218 the IP-layer configuration parameters associated with the attached 219 subnet (e.g., subnet prefix, default gateway address, etc.). While 220 merely knowing that a new link-layer connection is established may 221 prompt DNA process to immediately seek other clues for detecting 222 network configuration change, auxiliary information may constitute 223 further clues (and even the final answers sometimes). In cases where 224 there is a one-to-one mapping between the attachment point 225 identifiers and the IP-layer configurations, learning the former can 226 reveal the latter. Furthermore, IP-layer configuration parameters 227 obtained during link-layer connection may be exactly what the DNA 228 process is trying to discover (e.g., IP address configured during PPP 229 link establishment). 231 The link-layer process leading to a link up event depends on the link 232 technology. While a link-layer notification MUST always indicate 233 that the link up event occurred, the availability and types of 234 auxiliary information on the attachment point depends on the link- 235 layer technology as well. The following subsections examine four 236 link-layer technologies and describe when a link-layer notification 237 must be generated and what information must be included in it. 239 2.1 GPRS/3GPP 241 GSM Packet Radio System (GPRS) provides packet switched data 242 transmission over a cellular network[GPRS][GPRS-LINK]. 244 The GPRS architecture consists of a Radio Access Network and a packet 245 domain Core Network. 247 - The GPRS Radio Access Network is composed of Mobile Terminals (MT), 248 a Base Station Subsystem and Serving GPRS Support Nodes (SGSN). 250 - An IP Core Network that acts as the transport backbone of user 251 datagrams between SGSNs and Gateway GPRS Support Nodes (GGSN). The 252 GGSN ensures the GPRS IP core network connectivity with external 253 networks, such as Internet or Local Area Networks. GGSN acts as the 254 default IP gateway for the MT. 256 A GPRS MT that wants to establish IP connectivity establishes first a 257 connection to the GPRS network and one or more PDP Context 258 associations between the MT and the GGSN. It is only after the PDP 259 Context has been established, address autoconfiguration and tunneling 260 mechanism have taken place that the MT's IP packets can be forwarded 261 to and from its remote IP peers. The aim of PDP Context 262 establishment is also to provide IP-level configuration on top of the 263 GPRS link-layer attachment. 265 Successful establishment of a PDP Context on a GPRS link signifies 266 the availability of IP service to the MT. Therefore, this link-layer 267 event MUST generate a link up event notification sent to IP-layer. 268 An MT has the possibility to establish a secondary PDP Context while 269 re-using the IP configuration acquired from a previously established 270 and active PDP Context. Such a secondary PDP Context does not 271 provide additional information to IP-layer and only allows another 272 QoS profile to be used. The activiation of a such secondary PDP 273 Context MUST NOT generate another link up event notification. 274 However, other additional PDP Context activiations are to be treated 275 as indicated earlier. 277 With IPv4, the auxiliary information carried along with this 278 notification MUST be the IPv4 address of the MT which is obtained as 279 part of the PDP Context. With IPv6, the PDP Context activation 280 response does not come along with a usable IPv6 address. 281 Effectively, the IPv6 address received from the GGSN in the PDP 282 address field of the message does not contain a valid prefix. The MN 283 actually only uses the interface-identifier extracted from that field 284 to form a link-local address, that it uses afterwards to obtain a 285 valid prefix (e.g., by stateless [RFC2462][GPRS-CN] or stateful 286 [RFC3315] [GPRS-GSSA] address configuration). Therefore no IPv6- 287 related auxiliary information is provided to IP-layer. 289 2.2 cdma2000/3GPP2 291 cdma2000-based 3GPP2 packet data services provide mobile users wide 292 area high-speed access to packet switched networks [CDMA2K]. Some of 293 the major components of the 3GPP2 packet network architecture consist 294 of: 296 - Mobile Station (MS), which allows mobile access to packet-switched 297 networks over a wireless connection. 299 - Radio Access Network, which consists of the Base Station 300 Transceivers, Base Station Controllers, and the Packet Control 301 Function. 303 - Network Access Server known as the Packet Data Switching Node 304 (PDSN). The PDSN also serves as default IP gateway for the IP MS. 306 3GPP2 networks use the Point-to-Point Protocol (PPP [RFC1661]) as the 307 link-layer protocol between the MS and the PDSN. Before any IP 308 packets may be sent or received, PPP MUST reach the Network-Layer 309 Protocol phase, and the IP Control Protocol (IPCP [RFC1332], IPV6CP 310 [RFC2472]) reach the Opened state. When these states are reached in 311 PPP, a link up event notification MUST be delivered to the IP-layer. 313 When the PPP is used for 3GPP2 Simple (i.e., non-Mobile) IPv4 314 Service, IPCP enables configuration of IPv4 address on the MS. This 315 IPv4 address MUST be provided as the auxiliary information along with 316 the link up notification. IPV6CP used for Simple IPv6 service does 317 not provide an IPv6 address, but the interface-identifiers for local 318 and remote end-points of the PPP link. Since there is no standards- 319 mandated correlation between the interface-identifier and other IP- 320 layer configuration parameters, this information is deemed not useful 321 for DNA (nevertheless it MAY be provided as auxiliary information for 322 other uses). 324 2.3 IEEE 802.11/WiFi 326 IEEE 802.11-based WiFi networks are the wireless extension of the 327 Local Area Networks. Currently available standards are IEEE 802.11b 328 [IEEE-802.11b], IEEE 802.11g [IEEE-802.11g], and IEEE 802.11a [IEEE- 329 802.11a]. The specifications define both the MAC-layer and the 330 physical-layer. The MAC layer is the same for all these 331 technologies. 333 Two operating modes are available in the IEEE 802.11 series, either 334 infrastructure mode or ad-hoc mode. In infrastructure mode, all 335 link-layer frames are transmitted to an access point (AP) which then 336 forwards them to the final receiver. A station (STA) establishes a 337 IEEE 802.11 association with an AP in order to send and receive IP 338 packets. In a WiFi network that uses Robust Secure Network (RSN 339 [IEEE-802.11i]), successful completion of the 4-way handshake between 340 the STA and AP commences the availability of IP service. The link up 341 event notification MUST be generated upon this event. In non-RSN- 342 based networks, successful association or re-association events on 343 the link-layer MUST cause a link up notification sent to the IP- 344 layer. 346 As part of the link establishment, Basic Service Set Identification 347 (BSSID) and Service Set Identifier (SSID) associated with the AP is 348 learned by the STA. BSSID is a unique identifier of the AP, usually 349 set to the MAC address of the wireless interface of the AP. SSID 350 carries the identifier of the Extended Service Set (ESS) - the set 351 composed of APs and associated STAs that share a common distribution 352 system. BSSID and SSID MAY be provided as auxiliary information 353 along with the link up notification. Unfortunately this information 354 does not provide a deterministic indication of whether the IP-layer 355 configuration MUST be changed upon movement. There is no standards- 356 mandated one-to-one relation between the BSSID/SSID pairs and IP 357 subnets. An AP with a given BSSID can connect a STA to any one of 358 multiple IP subnets. Similarly, an ESS with the given SSID may span 359 multiple IP subnets. And finally, the SSIDs are not globally unique. 360 The same SSID may be used by multiple independent ESSs. See Appendix 361 A of [DNA4] for a detailed discussion. Nevertheless, BSSID/SSID 362 information may be used in a probabilistic way by the DNA process, 363 hence it is provided with the link up event notification. 365 In ad-hoc mode, mobile stations (STA) in range may directly 366 communicate with each other, i.e., without any infrastructure or 367 intermediate hop. The set of communicating STAs is called IBSS for 368 Independent Basic Service Set. In an IBSS, only STA services are 369 available, i.e. authentication, deauthentication, privacy and MSDU 370 delivery. STAs do not associate with each other, and therefore may 371 exchange data frames in state 2 (authenticated and not associated) or 372 even in state 1 (unauthenticated and unassociated) if the 373 Distribution System is not used (i.e., "To DS" and "From DS" bits are 374 clear). If authentication is performed, a link up indication can be 375 generated upon authentication. Concerning the link layer 376 identification, both the BSSID (which is a random MAC address chosen 377 by a STA of the IBSS) and SSID may be used to identify a link, but 378 not to make any assumptions on the IP network configuration. 380 2.4 IEEE 802.3 CSMA/CD 382 IEEE 802.3 CSMA/CD (commonly referred to as Ethernet) is the most 383 commonly deployed Local Area Network technology in use today. As 384 deployed today, it is specified by a physical layer/medium access 385 control (MAC) layer specification [IEEE-802.3]. In order to provide 386 connection of different LANs together into a larger network, 802.3 387 LANs are often bridged together [IEEE-802.1D]. 389 In this section, the terms 802.3 and Ethernet are used 390 interchangeably. This section describes some issues in providing 391 link-layer indications on Ethernet networks, and shows how bridging 392 affects these indications. 394 In Ethernet networks, hosts are connected by wires or by optic fibre 395 to a switch (bridge), a bus (e.g., co-axial cable), a repeater (hub), 396 or directly to another Ethernet device. Interfaces are symmetric, in 397 that while many different physical layers may be present, medium 398 access control is uniform for all devices. 400 In order to determine whether the physical medium is ready for frame 401 transfer, IEEE 802.3 Ethernet specifies its own link monitoring 402 mechanism, which is defined for some, but not all classes of media. 403 Where available, this Link Integrity Test operation is used to 404 identify when packets are able to be received on an Ethernet segment. 405 It is applicable to both wired and optical physical layers, although 406 details vary between technologies (link pulses in twisted pair 407 copper, light levels in fibre). 409 2.4.1 Link Integrity Tests in 802.3 Networks 411 Link Integrity Tests in 802.3 networks typically occur at initial 412 physical connection time (for example, at the auto-negotiation 413 stage), and periodically afterwards. It makes use of physical-layer 414 specific operations to determine if a medium is able to support link- 415 layer frames [IEEE-802.3]. 417 The status of the link as determined by the Link Integrity Test is 418 stored in the variable 'link_status'. Changes to the value of 419 link_status (for example due to Link Integrity Test failure) will 420 generate link indications if the technology dependent interface is 421 implemented on an Ethernet device [IEEE-802.3]. 423 The link_status has possible values of FAIL, READY and OK. When an 424 interface is in FAIL state, Link Integrity Tests have failed. Where 425 status is READY, the link segment has passed integrity tests, but 426 autonegotiation has not completed. OK state indicates that the 427 medium is able to send and receive packets. 429 Upon transition to a particular state the Physical Medium Attachment 430 subsystems generates a PMA_LINK.indicate(link_status). Indications 431 of OK state MAY be used to generate a link up event notification. 432 This indication do not definitively ensure that packets will be able 433 to be received through the bridge domain, though [see the next 434 section]. Such operations are governed by bridging. 436 2.4.2 IEEE 802.1D Bridging and Its Effects on Link-layer Event 437 Notifications 439 Ethernet networks commonly consist of LANs joined together by 440 transparent bridges (usually implemented as switches). Transparent 441 bridges require the active topology to be loop free. This is 442 achieved through the Spanning Tree Protocol (STP) or the Rapid 443 Spanning Tree Protocol (RSTP). These protocols exchange Bridge 444 Protocol Data Units (BPDUs), as defined in [IEEE-802.1D], which leads 445 to, where required, the blocking of ports (i.e., not forwarding). 447 By default, the spanning tree protocol does not know whether a 448 particular newly connected piece of Ethernet will cause a loop. 450 Therefore it will block all traffic from and to newly connected ports 451 with the exception of some unbridged management frames. The STP will 452 determine if the port can be connected to the network in a loop-free 453 manner. 455 For these technologies, even though the link-layer appears available, 456 no data packet forwarding will occur until it is determined that the 457 port can be connected to the network in a loop-free environment. 459 For hosts which are providing indications to upper layer protocols, 460 even if the host itself does not implement bridging or STP, packet 461 delivery across the network can be affected by the presence of 462 bridges. 464 Where the host is not running STP itself, no explicit indication that 465 forwarding has begun is sent from a bridge. Therefore, a host may 466 not know when STP operations have completed, and when it is safe to 467 inform upper layers to transmit packets. 469 Where it is not known that forwarding operations are available, a 470 host SHOULD assume that RSTP or STP is being performed. Hosts MAY 471 listen to STP/RSTP and 802.1AB messages to gain further information 472 about the timing of full connectivity on the link, for example, to 473 override an existing indication. 475 Notably, though, it is not easy for a host to distinguish between 476 Disabled bridge ports and non-bridge ports with no active 477 transmitters on them, as Disabled ports will have no traffic on them, 478 and incur 100% sender loss. 480 If no bridge configuration messages are received within the 481 Bridge_Max_Age interval (default 20s), then it is likely that there 482 is no visible bridge whose port is enabled for bridging (S8.4.5 of 483 [IEEE-802.1D]), since at least two BPDU hello messages would have 484 been lost. Upon this timeout, a link up notification MUST be 485 generated, if one has not been already. 487 If a BPDU is received, and the adjacent bridge is running the 488 original Spanning Tree Protocol, then a host cannot successfully send 489 packets until at least twice the ForwardDelay value in the received 490 BPDU has elapsed. After this time, a link up notification MUST be 491 generated. If the previous link up notification had the R-flag set, 492 then the B-flag) MUST be set in this notification. The B-flag 493 signifies that the packets sent within the prior interval were lost. 495 If the bridge is identified as performing Rapid Spanning Tree 496 Protocol (RSTP), it instead waits Bridge_Max_Age after packet 497 reception (advertised in the BPDU's Max Age field), before 498 forwarding. For ports which are known to be point-to-point through 499 autonegotiation, this delay is abbreviated to 3 seconds after 500 autonegotiation completes [IEEE-802.1D]. 502 2.4.3 802.1AB Link-Layer Discovery Protocol 504 The recently defined 802.1AB Link-Layer Discovery Protocol (LLDP) 505 provides information to devices which are directly adjacent to them 506 on the local LAN [IEEE-802.1ab]. 508 LLDP sends information periodically, and at link status change time 509 to indicate the configuration parameters of the device. Devices may 510 either send or receive these messages, or both. 512 The LLDP message may contain a System Capabilities TLV, which 513 describes the MAC and IP layer functions which a device is currently 514 using. Where a host receives the Systems Capabilities TLV which 515 indicate that no Bridging or Repeating is occurring on the LLDP 516 transmitter, then no delays for STP calculation will be applied to 517 packets sent through this transmitter, if the host does not perform 518 STP itself. This would allow the generation of a link up 519 notification. 521 Additionally, if a host receives a Systems Capabilities TLV which 522 indicates that the LLDP transmitter is a bridge, the host's 523 advertisement that it is an (end-host) Station-Only, may tell the 524 bridge not to run STP, and immediately allow forwarding. 526 Proprietary extensions may also indicate that data forwarding is 527 already available on such a port. Discussion of such optimizations 528 is out-of-scope for this document. 530 Due to the protocol's newness and lack of deployment, it is unclear 531 how this protocol will eventually affect DNA in IPv4 or IPv6 532 networks. 534 2.4.4 Summary 536 Link-Layer indications in Ethernet-like networks are complicated by 537 additional unadvertised delays due to Spanning Tree calculations. 538 This may cause re-indication (link up with A-flag) or retraction 539 (link up with B-flag) of indications previously sent to upper layer 540 protocols. 542 3. IANA Considerations 544 This document has no actions for IANA. 546 4. Security Considerations 548 Attackers may spoof various indications at the link-layer, or 549 manipulate the physical medium directly in an effort to confuse the 550 host about the state of the link-layer. For instance, attackers may 551 spoof error messages or disturb the wireless medium to cause the host 552 to move its connection elsewhere or to even disconnect. Attackers 553 may also spoof information to make the host believe it has a 554 connection when, in reality, it does not. 556 These attacks may cause use of non-preferred networks or even denial- 557 of-service. 559 This specification does not provide any protection of its own for the 560 the indications from the lower layers. But the vulnerabilities can 561 be mitigated through the use of techniques in other parts of the 562 protocol stack. In particular, it is RECOMMENDED that 563 authentication, replay and integrity protection of link-layer 564 management messages is enabled when available. Additionally, the 565 protocol stack may also use some network layer mechanisms to achieve 566 partial protection. For instance, SEND [RFC 3971] could be used to 567 confirm secure reachability with a router. However, network layer 568 mechanisms are unable to deal with all problems, such as with 569 insecure lower layer notifications that lead to the link not 570 functioning properly 572 5. Contributors 574 In addition to the people listed in the author list, text for the 575 specific link-layer technologies covered by this document was 576 contributed by Thomas Noel (IEEE 802.11b), and Greg Daley (IEEE 577 802.3). The authors would like to thank them for their efforts in 578 bringing this document to fruition. 580 6. Acknowledgements 582 The authors would like to acknowledge Bernard Aboba, Sanjeev Athalye, 583 JinHyeock Choi, John Loughney, Pekka Nikander, Brett Pentland, Tom 584 Petch, Dan Romascanu, Pekka Savola, and Muhammad Mukarram bin Tariq 585 for their useful comments and suggestions. 587 7. References 589 7.1 Normative References 591 [CDMA2K] "IS-835 - cdma2000 Wireless IP Network Standard", . 593 [GPRS] "Digital cellular telecommunications system (Phase 2+); 594 General Packet Radio Service (GPRS) Service description; 595 Stage 2", 3GPP 3GPP TS 03.60 version 7.9.0 Release 98. 597 [GPRS-LINK] 598 "Digital cellular telecommunications system (Phase 2+); 599 Radio subsystem link control", 3GPP GSM 03.05 version 600 7.0.0 Release 98. 602 [IEEE-802.11a] 603 Institute of Electrical and Electronics Engineers, "IEEE 604 Std 802.11a-1999, supplement to IEEE Std 802.11-1999, Part 605 11: Wireless MAN Medium Access Control (MAC) and Physical 606 Layer (PHY) specifications: High-speed Physical Layer in 607 the 5 GHZ band", IEEE Standard 802.11a, September 1999. 609 [IEEE-802.11b] 610 Institute of Electrical and Electronics Engineers, "IEEE 611 Std 802 Part 11, Information technology - 612 Telecomunications and information exchange between systems 613 - Local and metropolitan area networks - Specific 614 requirements - Part 11: Wireless Lan Medium Access Control 615 (MAC) And Physical Layer (PHY) Specifications", 616 IEEE Standard 802.11b, August 1999. 618 [IEEE-802.11g] 619 Institute of Electrical and Electronics Engineers, "IEEE 620 Std 802.11g-2003, Amendment to IEEE Std 802.11, 1999 621 edition, Part 11: Wireless MAN Medium Access Control (MAC) 622 and Physical Layer (PHY) specifications. Amendment 4: 623 Further Higher Data Rate Extension in the 2.4 GHz Band", 624 IEEE Standard 802.11g, June 2003. 626 [IEEE-802.11i] 627 Institute of Electrical and Electronics Engineers, 628 "Supplement to STANDARD FOR Telecommunications and 629 Information Exchange between Systems - LAN/MAN Specific 630 Requirements - Part 11: Wireless Medium Access Control 631 (MAC) and physical layer (PHY) specifications: 632 Specification for Enhanced Security", IEEE IEEE 802.11i, 633 December 2004. 635 [IEEE-802.1D] 636 Institute of Electrical and Electronics Engineers, "IEEE 637 standard for local and metropolitan area networks - common 638 specific ations - Media access control (MAC) Bridges", 639 ISO/IEC IEEE Std 802.1D, 2004. 641 [IEEE-802.1ab] 642 Institute of Electrical and Electronics Engineers, "Draft 643 Standard for Local and Metropolitan Networks: Station and 644 Media Access Control Connectivity Discovery (Draft 13)", 645 IEEE draft Std 802.1AB, 2004. 647 [IEEE-802.3] 648 Institute of Electrical and Electronics Engineers, "IEEE 649 standard for local and metropolitan area networks - 650 Specific Require ments, Part 3: Carrier Sense Multiple 651 Access with Collision Detection (CSMA/CD) Access Method 652 and Physical Layer Specifications", ISO/IEC IEEE 653 Std 802.3, 2002. 655 [RFC1332] McGregor, G., "The PPP Internet Protocol Control Protocol 656 (IPCP)", RFC 1332, May 1992. 658 [RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, 659 RFC 1661, July 1994. 661 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 662 Requirement Levels", BCP 14, RFC 2119, March 1997. 664 [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address 665 Autoconfiguration", RFC 2462, December 1998. 667 [RFC2472] Haskin, D. and E. Allen, "IP Version 6 over PPP", 668 RFC 2472, December 1998. 670 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 671 and M. Carney, "Dynamic Host Configuration Protocol for 672 IPv6 (DHCPv6)", RFC 3315, July 2003. 674 [RFC4135] Choi, JH. and G. Daley, "Goals of Detecting Network 675 Attachment in IPv6", RFC 4135, August 2005. 677 7.2 Informative References 679 [GPRS-CN] "Technical Specification Group Core Network; 680 Internetworking between the Public Land Mobile Network 681 (PLMN) supporting packet based services and Packet Data 682 Networks (PDN) (Release 6)", 3GPP 3GPP TS 29.061 version 683 6.1.0 2004-06. 685 [GPRS-GSSA] 686 "Technical Specification Group Services and System Aspect; 687 General Packet Radio Service (GPRS) Service description; 688 Stage 2 (Release 6)", 3GPP 3GPP TS 23.060 version 6.5.0 689 2004-06. 691 [I-D.ietf-mipshop-fast-mipv6] 692 Koodli, R., "Fast Handovers for Mobile IPv6", 693 draft-ietf-mipshop-fast-mipv6-03 (work in progress), 694 October 2004. 696 [I-D.ietf-mobileip-lowlatency-handoffs-v4] 697 Malki, K., "Low Latency Handoffs in Mobile IPv4", 698 draft-ietf-mobileip-lowlatency-handoffs-v4-11 (work in 699 progress), October 2005. 701 [RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor 702 Discovery for IP Version 6 (IPv6)", RFC 2461, 703 December 1998. 705 Authors' Addresses 707 Suresh Krishnan (editor) 708 Ericsson Research 709 8400 Decarie Blvd. 710 Town of Mount Royal, QC 711 Canada 713 Email: suresh.krishnan@ericsson.com 715 Nicolas Montavont 716 LSIIT - University Louis Pasteur 717 Pole API, bureau C428 718 Boulevard Sebastien Brant 719 Illkirch 67400 720 France 722 Phone: +33 390 244 587 723 Email: montavont@dpt-info.u-strasbg.fr 724 Eric Njedjou 725 France Telecom 726 4, Rue du Clos Courtel BP 91226 727 Cesson Sevigne 35512 728 France 730 Phone: +33 299124202 731 Email: eric.njedjou@france-telecom.com 733 Siva Veerepalli 734 Qualcomm 735 5775 Morehouse Drive 736 San Diego, CA 92131 737 USA 739 Phone: +1 858 658 4628 740 Email: sivav@qualcomm.com 742 Alper E. Yegin (editor) 743 Samsung Advanced Institute of Technology 744 75 West Plumeria Drive 745 San Jose, CA 95134 746 USA 748 Phone: +1 408 544 5656 749 Email: alper01.yegin@partner.samsung.com 751 Appendix A. Change History 753 The following changes were made on draft version 00: 755 - IEEE 802.11 ad-hoc mode discussion added. 757 - IPv6 address configuration over 3GPP networks clarified. 759 The following changes were made on draft version 01: 761 - Text for IEEE 802.3 added. 763 - Multiple 3GPP PDP Contexts scenario clarified. 765 The following change was made on draft version 02: 767 - Editorial fixes as suggested by WG last call feedback. 769 The following change was made on draft version 03: 771 Link down events were removed since they are not relevant to DNA 773 References updated 775 Intellectual Property Statement 777 The IETF takes no position regarding the validity or scope of any 778 Intellectual Property Rights or other rights that might be claimed to 779 pertain to the implementation or use of the technology described in 780 this document or the extent to which any license under such rights 781 might or might not be available; nor does it represent that it has 782 made any independent effort to identify any such rights. Information 783 on the procedures with respect to rights in RFC documents can be 784 found in BCP 78 and BCP 79. 786 Copies of IPR disclosures made to the IETF Secretariat and any 787 assurances of licenses to be made available, or the result of an 788 attempt made to obtain a general license or permission for the use of 789 such proprietary rights by implementers or users of this 790 specification can be obtained from the IETF on-line IPR repository at 791 http://www.ietf.org/ipr. 793 The IETF invites any interested party to bring to its attention any 794 copyrights, patents or patent applications, or other proprietary 795 rights that may cover technology that may be required to implement 796 this standard. Please address the information to the IETF at 797 ietf-ipr@ietf.org. 799 Disclaimer of Validity 801 This document and the information contained herein are provided on an 802 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 803 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 804 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 805 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 806 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 807 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 809 Copyright Statement 811 Copyright (C) The Internet Society (2006). This document is subject 812 to the rights, licenses and restrictions contained in BCP 78, and 813 except as set forth therein, the authors retain all their rights. 815 Acknowledgment 817 Funding for the RFC Editor function is currently provided by the 818 Internet Society.