idnits 2.17.1 draft-ietf-dna-link-information-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 22. -- Found old boilerplate from RFC 3978, Section 5.5 on line 830. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 807. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 814. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 820. ** 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 -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 6, 2006) is 6410 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 378, but not defined == Unused Reference: 'IEEE-802.11a' is defined on line 625, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-mobileip-lowlatency-handoffs-v4' is defined on line 719, 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 (~~), 5 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: April 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 October 6, 2006 14 Link-layer Event Notifications for Detecting Network Attachments 15 draft-ietf-dna-link-information-04 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 April 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 link-layer status information to IP. Link-layer event notifications 50 can help IP expeditiously detect configuration changes. This 51 document provides a non-exhaustive catalogue of information available 52 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 . . . . . . . . . . . . . . . . . . . . . . 8 61 2.3. IEEE 802.11/WiFi . . . . . . . . . . . . . . . . . . . . . 8 62 2.4. IEEE 802.3 CSMA/CD . . . . . . . . . . . . . . . . . . . . 10 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 . . . . . . . . . . . . . . . . . 11 66 2.4.3. 802.1AB Link-Layer Discovery Protocol . . . . . . . . 13 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 Appendix A. Change History . . . . . . . . . . . . . . . . . . . 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 prefixes 91 (i.e., appearance and disappearance of prefixes). But generally 92 reliance on such indications does not yield rapid detection, since 93 these indications are not readily available upon node changing its 94 point of attachment. 96 The changes to the underlying link-layer status can be relayed to IP 97 in the form of link-layer event notifications. Establishment and 98 tear down of a link-layer connection are two basic events types. 99 Additional information can be conveyed in addition to the event type, 100 such as the identifier of the network attachment point (e.g., IEEE 101 802.11 BSSID and SSID), or network-layer configuration parameters 102 obtained via the link-layer attachment process if available. It is 103 envisaged that such event notifications can in certain circumstances 104 be used to expedite the inter-subnet movement detection and 105 reconfiguration process. For example, the notification indicating 106 that the node has established a new link-layer connection MAY be used 107 for immediately probing the network for a possible configuration 108 change. In the absence of such a notification from the link-layer, 109 IP has to wait for indications that are not immediately available, 110 such as receipt of next scheduled router advertisement, 111 unreachability of the default gateway, etc. 113 It should be noted that a link-layer event notification does not 114 always translate into a subnet change. Even if the node has torn 115 down a link-layer connection with one attachment point and 116 established a new connection with another, it may still be attached 117 to the same IP subnet. For example, several IEEE 802.11 access 118 points can be attached to the same IP subnet. Moving among these 119 access points does not warrant any IP-layer configuration change. 121 In order to enable an enhanced scheme for detecting change of subnet, 122 we need to define link-layer event notifications that can be 123 realistically expected from various access technologies. The 124 objective of this draft is to provide a catalogue of link-layer 125 events and notifications in various architectures. While this 126 document mentions the utility of this information for detecting 127 change of subnet (or, detecting network attachment - DNA), the 128 detailed usage is left to other documents, namely DNA solution 129 specifications. 131 The document limits itself to the minimum set of information that is 132 necessary for solving the DNA problem [RFC4135]. A broader set of 133 information (e.g., signal strength, packet loss, etc.) and events 134 (e.g. link down) may be used for other problem spaces, such as 135 anticipation-based Mobile IP fast handovers [I-D.ietf-mobileip- 136 lowlatency-handoffs-v4] 137 [I-D.ietf-mipshop-fast-mipv6]. Separate documents that are backward- 138 compatible with this one can be generated to discuss further 139 enhancements. 141 These event notifications are considered with hosts in mind, although 142 they may also be available on the network side (e.g., on the access 143 points and routers). An API or protocol-based standard interface may 144 be defined between the link-layer and IP for conveying this 145 information. That activity is beyond the scope of this document. 147 1.1. Requirements notation 149 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 150 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 151 document are to be interpreted as described in [RFC2119]. 153 2. Link-Layer Event Notifications 155 Link-layer event notifications are considered to be one of the inputs 156 to the DNA process. A DNA process is likely to take other inputs 157 (e.g., presence of advertised prefixes, reachability of default 158 gateways) before determining whether IP-layer configuration must be 159 updated. It is expected that the DNA process can take advantage of 160 link-layer notifications when they are made available to IP. While 161 by itself a link-layer notification may not constitute all the input 162 DNA needs, it can at least be useful for prompting the DNA process to 163 collect further information (i.e., other inputs to the process). For 164 example, the node may send a router solicitation as soon as it learns 165 that a new link-layer connection is established. 167 The link-layer event that is considered most useful to DNA process is 168 the link up event. The link up event is deterministic, and the link 169 up notification is provided to IP-layer after the event successfully 170 concludes. The link up events and notifications are associated with 171 a network interface on the node. The IP module may receive 172 simultaneous independent notifications from each one of the network 173 interfaces on the node. 175 "Link" is a communication facility or medium over which network nodes 176 can communicate. Each link is associated with a minimum of two 177 endpoints. An "attachment point" is the link endpoint on the link to 178 which the node is currently connected, such as an access point, a 179 base station, or a wired switch. 181 "Link up" is an event provided by the link-layer that signifies a 182 state change associated with the interface becoming capable of 183 communicating data packets. This event is associated with a link- 184 layer connection between the node and an attachment point. 186 The actual event is managed by the link-layer of the node through 187 execution of link-layer protocols and mechanisms. Once the event 188 successfully completes within the link-layer, its notification MUST 189 be delivered to the IP-layer. By the time the notification is 190 delivered, the link-layer of the node MUST be ready to accept IP 191 packets from the IP and the physical-layers. Each time an interface 192 changes its point of attachment, a link up event SHOULD be generated. 194 There is a non-deterministic usage of link up notification to 195 accomodate implementations that desire to indicate the link is up but 196 the data transmission may be blocked in the network (see IEEE 802.3 197 discussion). A link up notification MAY be generated with an 198 appropriate attribute (e.g., "risk" indicated by R-flag) to convey 199 the event. Alternatively, the link-layer implementation MAY choose 200 to delay the link up notification until the risk conditions cease to 201 exist. 203 If a link up with the R-flag set was generated, another link up MUST 204 follow up as soon as the link-layer is capable of generating a 205 deterministic notification. The event attributes MUST indicate 206 whether the packets transmitted since the previous notification were 207 presumed to be blocked (B-flag) or allowed (A-flag) by the network if 208 the link-layer could determine the exact conditions. If the link- 209 layer cannot make a determination about the faith of these packets, 210 it MUST generate a link up without any additional indications (no 211 flags set). 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 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 DNA process to immediately seek other clues for detecting 227 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 link-layer connection may be exactly what the DNA 233 process is trying to discover (e.g., IP address configured during PPP 234 link establishment). 236 The link-layer process leading to a link up event depends on the link 237 technology. While a link-layer notification MUST always indicate 238 that the link up event occurred, the availability and types of 239 auxiliary information on the attachment point depends on the link- 240 layer technology as well. The following subsections examine four 241 link-layer technologies and describe when a link-layer notification 242 must be generated and what information must be included in it. 244 2.1. GPRS/3GPP 246 GPRS is an enhancement to the GSM data transmission architecture and 247 capabilities, designed to allow for packet switching in user data 248 transmission within the GPRS network as well as for higher quality of 249 service for the IP traffic of Mobile Terminals with external Packets 250 Data Networks such as the Internet or corporate LANs [GPRS][GPRS- 251 LINK]. 253 The GPRS architecture consists of a Radio Access Network and a packet 254 domain Core Network. 256 - The GPRS Radio Access Network is composed of Mobile Terminals (MT), 257 a Base Station Subsystem and Serving GPRS Support Nodes (SGSN). 259 - An IP Core Network that acts as the transport backbone of user 260 datagrams between SGSNs and Gateway GPRS Support Nodes (GGSN). The 261 GGSN ensures the GPRS IP core network connectivity with external 262 networks, such as Internet or Local Area Networks. GGSN acts as the 263 default IP gateway for the MT. 265 A GPRS MT that wants to establish IP-level connections MUST first 266 perform a GPRS attach to the SGSN. This MUST be followed by a 267 request to the GPRS network to settle the necessary soft state 268 mechanism (GPRS tunneling protocol) between its serving SGSN and the 269 GGSN. The soft state maintained between the MT, the SGSN and the 270 GGSN is called a PDP Context. It is used for guaranteeing a 271 negotiated quality of service for the IP flows exchanged between the 272 GPRS MT and an external Packet Data Network such as Internet. It is 273 only after the PDP Context has been established, address 274 autoconfiguration and tunneling mechanism have taken place that the 275 MT's IP packets can be forwarded to and from its remote IP peers. 276 The aim of PDP Context establishment is also to provide IP-level 277 configuration on top of the GPRS link-layer attachment. 279 Successful establishment of a PDP Context on a GPRS link signifies 280 the availability of IP service to the MT. Therefore, this link-layer 281 event MUST generate a link up event notification sent to IP-layer. 282 An MT has the possibility to establish a secondary PDP Context while 283 re-using the IP configuration acquired from a previously established 284 and active PDP Context. Establishment of a secondary PDP Context 285 does not provide additional information to IP-layer. Such a second 286 PDP Context would basically have a different QoS profile so that a 287 different type of application can be served. In that case, 288 activation of the secondary PDP Context MUST NOT generate another 289 link up event notification. However, a secondary PDP Context 290 establishment that triggers a new IP configuration is to be treated 291 from the IP layer as indicated above. 293 With IPv4, the auxiliary information carried along with this 294 notification MUST be the IPv4 address of the MT which is obtained as 295 part of the PDP Context. With IPv6, the PDP Context activation 296 response does not come along with a usable IPv6 address. 298 Effectively, the IPv6 address received from the GGSN in the PDP 299 address field of the message does not contain a valid prefix. The MN 300 actually only uses the interface-identifier extracted from that field 301 to form a link-local address, that it uses afterwards to obtain a 302 valid prefix (e.g., by stateless [RFC2462][GPRS-CN] or stateful 303 [RFC3315] [GPRS-GSSA] address configuration). Therefore no IPv6- 304 related auxiliary information is provided to IP-layer. 306 2.2. cdma2000/3GPP2 308 cdma2000-based 3GPP2 packet data services provide mobile users wide 309 area high-speed access to packet switched networks [CDMA2K]. Some of 310 the major components of the 3GPP2 packet network architecture consist 311 of: 313 - Mobile Station (MS), which allows mobile access to packet-switched 314 networks over a wireless connection. 316 - Radio Access Network, which consists of the Base Station 317 Transceivers, Base Station Controllers, and the Packet Control 318 Function. 320 - Network Access Server known as the Packet Data Switching Node 321 (PDSN). The PDSN also serves as default IP gateway for the IP MS. 323 3GPP2 networks use the Point-to-Point Protocol (PPP [RFC1661]) as the 324 link-layer protocol between the MS and the PDSN. Before any IP 325 packets may be sent or received, PPP MUST reach the Network-Layer 326 Protocol phase, and the IP Control Protocol (IPCP [RFC1332], IPV6CP 327 [RFC2472]) reach the Opened state. When these states are reached in 328 PPP, a link up event notification MUST be delivered to the IP-layer. 330 When the PPP is used for 3GPP2 Simple (i.e., non-Mobile) IPv4 331 Service, IPCP enables configuration of IPv4 address on the MS. This 332 IPv4 address MUST be provided as the auxiliary information along with 333 the link up notification. IPV6CP used for Simple IPv6 service does 334 not provide an IPv6 address, but the interface-identifiers for local 335 and remote end-points of the PPP link. Since there is no standards- 336 mandated correlation between the interface-identifier and other IP- 337 layer configuration parameters, this information is deemed not useful 338 for DNA (nevertheless it MAY be provided as auxiliary information for 339 other uses). 341 2.3. IEEE 802.11/WiFi 343 IEEE 802.11-based WiFi networks are the wireless extension of the 344 Local Area Networks. Currently available standards are IEEE 802.11b 345 [IEEE-802.11b], IEEE 802.11g [IEEE-802.11g], and IEEE 802.11a [IEEE- 346 802.11a]. The specifications define both the MAC-layer and the 347 physical-layer. The MAC layer is the same for all these 348 technologies. 350 Two operating modes are available in the IEEE 802.11 series, either 351 infrastructure mode or ad-hoc mode. In infrastructure mode, all 352 link-layer frames are transmitted to an access point (AP) which then 353 forwards them to the final receiver. A station (STA) MUST establish 354 a IEEE 802.11 link with an AP in order to send and receive IP 355 packets. In a WiFi network that supports Robust Secure Network (RSN 356 [IEEE-802.11i]), successful completion of 4-way handshake between the 357 STA and AP commences the availability of IP service. The link up 358 event notification MUST be generated upon this event. In non-RSN- 359 based networks, successful association or re-association events on 360 the link-layer MUST cause a link up notification sent to the IP- 361 layer. 363 As part of the link establishment, Basic Service Set Identification 364 (BSSID) and Service Set Identifier (SSID) associated with the AP is 365 learned by the STA. BSSID is a unique identifier of the AP, usually 366 set to the MAC address of the wireless interface of the AP. SSID 367 carries the identifier of the Extended Service Set (ESS) - the set 368 composed of APs and associated STAs that share a common distribution 369 system. BSSID and SSID MUST be provided as auxiliary information 370 along with the link up notification. Unfortunately this information 371 does not provide a deterministic indication of whether the IP-layer 372 configuration MUST be changed upon movement. There is no standards- 373 mandated one-to-one relation between the BSSID/SSID pairs and IP 374 subnets. An AP with a given BSSID can connect a STA to any one of 375 multiple IP subnets. Similarly, an ESS with the given SSID may span 376 multiple IP subnets. And finally, the SSIDs are not globally unique. 377 The same SSID may be used by multiple independent ESSs. See Appendix 378 A of [DNA4] for a detailed discussion. Nevertheless, BSSID/SSID 379 information may be used in a probabilistic way by the DNA process, 380 hence it is provided with the link up event notification. 382 In ad-hoc mode, mobile stations (STA) in range may directly 383 communicate with each other, i.e., without any infrastructure or 384 intermediate hop. The set of communicating STAs is called IBSS for 385 Independent Basic Service Set. In an IBSS, only STA services are 386 available, i.e. authentication, deauthentication, privacy and MSDU 387 delivery. STAs do not associate with each other, and therefore may 388 exchange data frames in state 2 (authenticated and not associated) or 389 even in state 1 (unauthenticated and unassociated) if the 390 Distribution System is not used (i.e., "To DS" and "From DS" bits are 391 clear). If authentication is performed, a link up indication can be 392 generated upon authentication. Concerning the link layer 393 identification, both the BSSID (which is a random MAC address chosen 394 by a STA of the IBSS) and SSID may be used to identify a link, but 395 not to make any assumptions on the IP network configuration. 397 2.4. IEEE 802.3 CSMA/CD 399 IEEE 802.3 CSMA/CD (commonly referred to as Ethernet) is the most 400 commonly deployed Local Area Network technology in use today. As 401 deployed today, it is specified by a physical layer/medium access 402 control (MAC) layer specification [IEEE-802.3]. In order to provide 403 connection of different LANs together into a larger network, 802.3 404 LANs are often bridged together [IEEE-802.1D]. 406 In this section, the terms 802.3 and Ethernet are used 407 interchangeably. This section describes some issues in providing 408 link-layer indications on Ethernet networks, and shows how bridging 409 affects these indications. 411 In Ethernet networks, hosts are connected by wires or by optic fibre 412 to a switch (bridge), a bus (e.g., co-axial cable), a repeater (hub), 413 or directly to another Ethernet device. Interfaces are symmetric, in 414 that while many different physical layers may be present, medium 415 access control is uniform for all devices. 417 In order to determine whether the physical medium is ready for frame 418 transfer, IEEE 802.3 Ethernet specifies its own link monitoring 419 mechanism, which is defined for some, but not all classes of media. 420 Where available, this Link Integrity Test operation is used to 421 identify when packets are able to be received on an Ethernet segment. 422 It is applicable to both wired and optical physical layers, although 423 details vary between technologies (link pulses in twisted pair 424 copper, light levels in fibre). 426 2.4.1. Link Integrity Tests in 802.3 Networks 428 Link Integrity Tests in 802.3 networks typically occur at initial 429 physical connection time (for example, at the auto-negotiation 430 stage), and periodically afterwards. It makes use of physical-layer 431 specific operations to determine if a medium is able to support link- 432 layer frames [IEEE-802.3]. 434 The status of the link as determined by the Link Integrity Test is 435 stored in the variable 'link_status'. Changes to the value of 436 link_status (for example due to Link Integrity Test failure) will 437 generate link indications if the technology dependent interface is 438 implemented on an Ethernet device [IEEE-802.3]. 440 The link_status has possible values of FAIL, READY and OK. When an 441 interface is in FAIL state, Link Integrity Tests have failed. Where 442 status is READY, the link segment has passed integrity tests, but 443 autonegotiation has not completed. OK state indicates that the 444 medium is able to send and receive packets. 446 Upon transition to a particular state the Physical Medium Attachment 447 subsystems generates a PMA_LINK.indicate(link_status). Indications 448 of OK state MAY be used to generate a link up event notification. 449 This indication do not definitively ensure that packets will be able 450 to be received through the bridge domain, though [see the next 451 section]. Such operations are governed by bridging. 453 2.4.2. IEEE 802.1D Bridging and Its Effects on Link-layer Event 454 Notifications 456 Ethernet networks commonly consist of LANs joined together by 457 transparent bridges (usually implemented as switches). Transparent 458 bridges require the active topology to be loop free. The Spanning 459 Tree Protocol (STP) achieves this by the exchange of Bridge Protocol 460 Data Unit (BPDU), as defined in [IEEE-802.1D], which leads to, where 461 required, the blocking of ports (i.e., not forwarding). 463 By default, the spanning tree protocol does not know whether a 464 particular newly connected piece of Ethernet will cause a loop. 466 Therefore it will block all traffic from and to newly connected ports 467 with the exception of some unbridged management frames. The STP will 468 determine if the port can be connected to the network in a loop-free 469 manner. 471 For these technologies, even though the link-layer appears available, 472 no data packet forwarding will occur until it is determined that the 473 port can be connected to the network in a loop-free environment. 475 For hosts which are providing indications to upper layer protocols, 476 even if the host itself does not implement bridging or STP, packet 477 delivery across the network can be affected by the presence of 478 bridges. 480 Where the host is not running STP itself, no explicit indication that 481 forwarding has begun is sent from a bridge. Therefore, a host may 482 not know when STP operations have completed, and when it is safe to 483 inform upper layers to transmit packets. 485 Where it is not known that forwarding operations are available, a 486 host needs to assume that STP is being performed, and may indicate 487 full connectivity only based on timeouts or reception of BPDUs. 489 Most hosts today do not listen to BPDU frames. For these hosts, 490 connectivity to the a port which is potentially bridged (any Ethernet 491 port) carries the potential of frame loss if transmissions occur 492 before any bridges' ForwardDelay timers have expired twice. This 493 timeout defaults to 30 seconds (2 * 15 seconds), but may be as high 494 as 60s [IEEE-802.1D]. When sending indications to upper layers, the 495 period where frame forwarding is potentially unavailable should be 496 indicated to upper-layer protocols. 498 Alternatively, a host can listen for BPDUs and use them to determine 499 the length of port blockage which will occur in their particular 500 circumstances. 502 In either case, as soon as link_status becomes OK a link up 503 notification with the attribute (R-flag) that indicates the risk of 504 packet loss MAY be sent. 506 Upon learning that an adjacent port is running STP or RSTP, the host 507 MUST send a link up notification upon expiry of calculated delays to 508 indicate that general packet transfer is available across the LAN. 510 If no bridge configuration messages are received within the 511 Bridge_Max_Age interval (default 20s), then it is likely that there 512 is no visible bridge whose port is enabled for bridging (S8.4.5 of 513 [IEEE-802.1D]), since at least two BPDU hello messages would have 514 been lost. Upon this timeout, a link up notification MUST be 515 generated. 517 It is not easy for a non-STP host to distinguish between Disabled 518 bridge ports and non-bridge ports with no IP nodes on them, as 519 Disabled ports will have no traffic on them, and incur 100% sender 520 loss. 522 Upon this Bridge_Max_Age timeout, a link up notification must be 523 generated. If an earlier link up was generated with the R-flag set, 524 this new one MUST set the A-flag showing that packets sent within the 525 prior interval were likely to have traversed the forwarding path 526 (unless the port is disabled). 528 If a BPDU is received, and the adjacent bridge is running the 529 original Spanning Tree Protocol, then a host cannot successfully send 530 packets until at least twice the ForwardDelay value in the received 531 BPDU has elapsed. After this time, a link up notification MUST be 532 generated. If the previous link up notification had the R-flag set, 533 then the B-flag) MUST be set in this notification. The B-flag 534 signifies that the packets sent within the prior interval were lost. 536 If the bridge is identified as performing Rapid Spanning Tree 537 Protocol (RSTP), it instead waits Bridge_Max_Age after packet 538 reception (advertised in the BPDU's Max Age field), before 539 forwarding. For ports which are known to be point-to-point through 540 autonegotiation, this delay is abbreviated to 3 seconds after 541 autonegotiation completes [IEEE-802.1D]. 543 2.4.3. 802.1AB Link-Layer Discovery Protocol 545 The recently defined 802.1AB Link-Layer Discovery Protocol (LLDP) 546 provides information to devices which are directly adjacent to them 547 on the local LAN [IEEE-802.1ab]. 549 LLDP sends information periodically, and at link status change time 550 to indicate the configuration parameters of the device. Devices may 551 either send or receive these messages, or both. 553 The LLDP message may contain a System Capabilities TLV, which 554 describes the MAC and IP layer functions which a device is currently 555 using. Where a host receives the Systems Capabilities TLV which 556 indicate that no Bridging or Repeating is occurring on the LLDP 557 transmitter, then no delays for STP calculation will be applied to 558 packets sent through this transmitter, if the host does not perform 559 STP itself. This would allow the generation of a link up 560 notification. 562 Additionally, if a host receives a Systems Capabilities TLV which 563 indicates that the LLDP transmitter is a bridge, the host's 564 advertisement that it is an (end-host) Station-Only, may tell the 565 bridge not to run STP, and immediately allow forwarding. 567 Proprietary extensions may also indicate that data forwarding is 568 already available on such a port. Discussion of such optimizations 569 is out-of-scope for this document. 571 Due to the protocol's newness and lack of deployment, it is unclear 572 how this protocol will eventually affect DNA in IPv4 or IPv6 573 networks. 575 2.4.4. Summary 577 Link-Layer indications in Ethernet-like networks are complicated by 578 additional unadvertised delays due to Spanning Tree calculations. 579 This may cause re-indication (link up with A-flag) or retraction 580 (link up with B-flag) of indications previously sent to upper layer 581 protocols. 583 3. IANA Considerations 585 This document has no actions for IANA. 587 4. Security Considerations 589 A faked link-layer event notification can be used to launch a 590 denial-of service attack on the node and the associated network. 591 Secure generation and delivery of these notifications MUST be 592 ensured. This is a subject for link-layer and network stack designs 593 and therefore it is outside the scope of this document. 595 5. Contributors 597 In addition to the people listed in the author list, text for the 598 specific link-layer technologies covered by this document was 599 contributed by Thomas Noel (IEEE 802.11b), and Greg Daley (IEEE 600 802.3). The authors would like to thank them for their efforts in 601 bringing this document to fruition. 603 6. Acknowledgements 605 The authors would like to acknowledge Bernard Aboba, Sanjeev Athalye, 606 JinHyeock Choi, John Loughney, Pekka Nikander, Brett Pentland, Tom 607 Petch, Dan Romascanu, Pekka Savola, and Muhammad Mukarram bin Tariq 608 for their useful comments and suggestions. 610 7. References 612 7.1. Normative References 614 [CDMA2K] "IS-835 - cdma2000 Wireless IP Network Standard", . 616 [GPRS] "Digital cellular telecommunications system (Phase 2+); 617 General Packet Radio Service (GPRS) Service description; 618 Stage 2", 3GPP 3GPP TS 03.60 version 7.9.0 Release 98. 620 [GPRS-LINK] 621 "Digital cellular telecommunications system (Phase 2+); 622 Radio subsystem link control", 3GPP GSM 03.05 version 623 7.0.0 Release 98. 625 [IEEE-802.11a] 626 Institute of Electrical and Electronics Engineers, "IEEE 627 Std 802.11a-1999, supplement to IEEE Std 802.11-1999, Part 628 11: Wireless MAN Medium Access Control (MAC) and Physical 629 Layer (PHY) specifications: High-speed Physical Layer in 630 the 5 GHZ band", IEEE Standard 802.11a, September 1999. 632 [IEEE-802.11b] 633 Institute of Electrical and Electronics Engineers, "IEEE 634 Std 802 Part 11, Information technology - 635 Telecomunications and information exchange between systems 636 - Local and metropolitan area networks - Specific 637 requirements - Part 11: Wireless Lan Medium Access Control 638 (MAC) And Physical Layer (PHY) Specifications", 639 IEEE Standard 802.11b, August 1999. 641 [IEEE-802.11g] 642 Institute of Electrical and Electronics Engineers, "IEEE 643 Std 802.11g-2003, Amendment to IEEE Std 802.11, 1999 644 edition, Part 11: Wireless MAN Medium Access Control (MAC) 645 and Physical Layer (PHY) specifications. Amendment 4: 646 Further Higher Data Rate Extension in the 2.4 GHz Band", 647 IEEE Standard 802.11g, June 2003. 649 [IEEE-802.11i] 650 Institute of Electrical and Electronics Engineers, 651 "Supplement to STANDARD FOR Telecommunications and 652 Information Exchange between Systems - LAN/MAN Specific 653 Requirements - Part 11: Wireless Medium Access Control 654 (MAC) and physical layer (PHY) specifications: 655 Specification for Enhanced Security", IEEE IEEE 802.11i, 656 December 2004. 658 [IEEE-802.1D] 659 Institute of Electrical and Electronics Engineers, "IEEE 660 standard for local and metropolitan area networks - common 661 specific ations - Media access control (MAC) Bridges", 662 ISO/IEC IEEE Std 802.1D, 2004. 664 [IEEE-802.1ab] 665 Institute of Electrical and Electronics Engineers, "Draft 666 Standard for Local and Metropolitan Networks: Station and 667 Media Access Control Connectivity Discovery (Draft 13)", 668 IEEE draft Std 802.1AB, 2004. 670 [IEEE-802.3] 671 Institute of Electrical and Electronics Engineers, "IEEE 672 standard for local and metropolitan area networks - 673 Specific Require ments, Part 3: Carrier Sense Multiple 674 Access with Collision Detection (CSMA/CD) Access Method 675 and Physical Layer Specifications", ISO/IEC IEEE 676 Std 802.3, 2002. 678 [RFC1332] McGregor, G., "The PPP Internet Protocol Control Protocol 679 (IPCP)", RFC 1332, May 1992. 681 [RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, 682 RFC 1661, July 1994. 684 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 685 Requirement Levels", BCP 14, RFC 2119, March 1997. 687 [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address 688 Autoconfiguration", RFC 2462, December 1998. 690 [RFC2472] Haskin, D. and E. Allen, "IP Version 6 over PPP", 691 RFC 2472, December 1998. 693 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 694 and M. Carney, "Dynamic Host Configuration Protocol for 695 IPv6 (DHCPv6)", RFC 3315, July 2003. 697 [RFC4135] Choi, JH. and G. Daley, "Goals of Detecting Network 698 Attachment in IPv6", RFC 4135, August 2005. 700 7.2. Informative References 702 [GPRS-CN] "Technical Specification Group Core Network; 703 Internetworking between the Public Land Mobile Network 704 (PLMN) supporting packet based services and Packet Data 705 Networks (PDN) (Release 6)", 3GPP 3GPP TS 29.061 version 706 6.1.0 2004-06. 708 [GPRS-GSSA] 709 "Technical Specification Group Services and System Aspect; 710 General Packet Radio Service (GPRS) Service description; 711 Stage 2 (Release 6)", 3GPP 3GPP TS 23.060 version 6.5.0 712 2004-06. 714 [I-D.ietf-mipshop-fast-mipv6] 715 Koodli, R., "Fast Handovers for Mobile IPv6", 716 draft-ietf-mipshop-fast-mipv6-03 (work in progress), 717 October 2004. 719 [I-D.ietf-mobileip-lowlatency-handoffs-v4] 720 Malki, K., "Low Latency Handoffs in Mobile IPv4", 721 draft-ietf-mobileip-lowlatency-handoffs-v4-11 (work in 722 progress), October 2005. 724 [RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor 725 Discovery for IP Version 6 (IPv6)", RFC 2461, 726 December 1998. 728 Appendix A. Change History 730 The following changes were made on draft version 00: 732 - IEEE 802.11 ad-hoc mode discussion added. 734 - IPv6 address configuration over 3GPP networks clarified. 736 The following changes were made on draft version 01: 738 - Text for IEEE 802.3 added. 740 - Multiple 3GPP PDP Contexts scenario clarified. 742 The following change was made on draft version 02: 744 - Editorial fixes as suggested by WG last call feedback. 746 The following change was made on draft version 03: 748 Link down events were removed since they are not relevant to DNA 750 References updated 752 Authors' Addresses 754 Suresh Krishnan (editor) 755 Ericsson Research 756 8400 Decarie Blvd. 757 Town of Mount Royal, QC 758 Canada 760 Email: suresh.krishnan@ericsson.com 762 Nicolas Montavont 763 LSIIT - University Louis Pasteur 764 Pole API, bureau C428 765 Boulevard Sebastien Brant 766 Illkirch 67400 767 France 769 Phone: +33 390 244 587 770 Email: montavont@dpt-info.u-strasbg.fr 772 Eric Njedjou 773 France Telecom 774 4, Rue du Clos Courtel BP 91226 775 Cesson Sevigne 35512 776 France 778 Phone: +33 299124202 779 Email: eric.njedjou@france-telecom.com 781 Siva Veerepalli 782 Qualcomm 783 5775 Morehouse Drive 784 San Diego, CA 92131 785 USA 787 Phone: +1 858 658 4628 788 Email: sivav@qualcomm.com 789 Alper E. Yegin (editor) 790 Samsung Advanced Institute of Technology 791 75 West Plumeria Drive 792 San Jose, CA 95134 793 USA 795 Phone: +1 408 544 5656 796 Email: alper01.yegin@partner.samsung.com 798 Intellectual Property Statement 800 The IETF takes no position regarding the validity or scope of any 801 Intellectual Property Rights or other rights that might be claimed to 802 pertain to the implementation or use of the technology described in 803 this document or the extent to which any license under such rights 804 might or might not be available; nor does it represent that it has 805 made any independent effort to identify any such rights. Information 806 on the procedures with respect to rights in RFC documents can be 807 found in BCP 78 and BCP 79. 809 Copies of IPR disclosures made to the IETF Secretariat and any 810 assurances of licenses to be made available, or the result of an 811 attempt made to obtain a general license or permission for the use of 812 such proprietary rights by implementers or users of this 813 specification can be obtained from the IETF on-line IPR repository at 814 http://www.ietf.org/ipr. 816 The IETF invites any interested party to bring to its attention any 817 copyrights, patents or patent applications, or other proprietary 818 rights that may cover technology that may be required to implement 819 this standard. Please address the information to the IETF at 820 ietf-ipr@ietf.org. 822 Disclaimer of Validity 824 This document and the information contained herein are provided on an 825 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 826 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 827 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 828 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 829 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 830 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 832 Copyright Statement 834 Copyright (C) The Internet Society (2006). This document is subject 835 to the rights, licenses and restrictions contained in BCP 78, and 836 except as set forth therein, the authors retain all their rights. 838 Acknowledgment 840 Funding for the RFC Editor function is currently provided by the 841 Internet Society.