idnits 2.17.1 draft-ietf-dna-link-information-02.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 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 820. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 797. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 804. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 810. ** 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 355 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 (July 8, 2005) is 6866 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 404, but not defined == Unused Reference: 'IEEE-802.11a' is defined on line 663, 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' ** Downref: Normative reference to an Informational draft: draft-ietf-dna-goals (ref. 'I-D.ietf-dna-goals') -- 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) == Outdated reference: A later version (-11) exists of draft-ietf-mobileip-lowlatency-handoffs-v4-09 -- Obsolete informational reference (is this intentional?): RFC 2461 (Obsoleted by RFC 4861) Summary: 7 errors (**), 0 flaws (~~), 6 warnings (==), 18 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Yegin, Ed. 3 Internet-Draft Samsung AIT 4 Expires: January 9, 2006 July 8, 2005 6 Link-layer Event Notifications for Detecting Network Attachments 7 draft-ietf-dna-link-information-02.txt 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on January 19, 2006. 34 Copyright Notice 36 Copyright (C) The Internet Society (2005). 38 Abstract 40 Certain network access technologies are capable of providing various 41 link-layer status information to IP. Link-layer event notifications 42 can help IP expeditiously detect configuration changes. This 43 document provides a non-exhaustive catalogue of information available 44 from well-known access technologies. 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 49 1.1 Requirements notation . . . . . . . . . . . . . . . . . . 4 50 2. Link-Layer Event Notifications . . . . . . . . . . . . . . . . 5 51 2.1 GPRS/3GPP . . . . . . . . . . . . . . . . . . . . . . . . 7 52 2.2 cdma2000/3GPP2 . . . . . . . . . . . . . . . . . . . . . . 8 53 2.3 IEEE 802.11/WiFi . . . . . . . . . . . . . . . . . . . . . 9 54 2.4 IEEE 802.3 CSMA/CD . . . . . . . . . . . . . . . . . . . . 10 55 2.4.1 Link Integrity Tests in 802.3 Networks . . . . . . . . 11 56 2.4.2 IEEE 802.1D Bridging and Its Effects on Link-layer 57 Event Notifications . . . . . . . . . . . . . . . . . 12 58 2.4.3 802.1AB Link-Layer Discovery Protocol . . . . . . . . 14 59 2.4.4 Summary . . . . . . . . . . . . . . . . . . . . . . . 14 60 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 61 4. Security Considerations . . . . . . . . . . . . . . . . . . . 16 62 5. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 17 63 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 64 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 65 7.1 Normative References . . . . . . . . . . . . . . . . . . . 19 66 7.2 Informative References . . . . . . . . . . . . . . . . . . 20 67 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 21 68 A. Change History . . . . . . . . . . . . . . . . . . . . . . . . 22 69 Intellectual Property and Copyright Statements . . . . . . . . 23 71 1. Introduction 73 It is not an uncommon occurrence for a node to change its point-of 74 attachment to the network. This can happen due to mobile usage 75 (e.g., a mobile phone moving among base stations) or nomadic usage 76 (e.g., road-warrior case). 78 A node changing its point-of attachment to the network may end up 79 changing its IP subnet and therefore require re-configuration of IP- 80 layer parameters, such as IP address, default gateway information, 81 and DNS server address. Detecting the subnet change can usually use 82 network-layer indications such as a change in the advertised prefixes 83 (i.e., appearance and disappearance of prefixes). But generally 84 reliance on such indications does not yield rapid detection, since 85 these indications are not readily available upon node changing its 86 point of attachment. 88 The changes on the underlying link-layer status can be relayed to IP 89 in the form of link-layer event notifications. Establishment and 90 tear down of a link-layer connection are two basic events types. 91 Additional information can be conveyed in addition to the event type, 92 such as the identifier of the network attachment point (e.g., IEEE 93 802.11 BSSID and SSID), or network-layer configuration parameters 94 obtained via the link-layer attachment process if available. It is 95 envisaged that such event notifications can in certain circumstances 96 be used to expedite the inter-subnet movement detection and 97 reconfiguration process. For example, the notification indicating 98 that the node has established a new link-layer connection MAY be used 99 for immediately probing the network for a possible configuration 100 change. In the absence of such a notification from the link-layer, 101 IP has to wait for indications that are not immediately available, 102 such as receipt of next scheduled router advertisement, 103 unreachability of the default gateway, etc. 105 It be noted that a link-layer event notification does not always 106 translate into a subnet change. Even if the node has torn down a 107 link-layer connection with one attachment point and established a new 108 connection with another, it may still be attached to the same IP 109 subnet. For example, several IEEE 802.11 access points can be 110 attached to the same IP subnet. Moving among these access points 111 does not warrant any IP-layer configuration change. 113 In order to enable an enhanced scheme for detecting change of subnet, 114 we need to define link-layer event notifications that can be 115 realistically expected from various access technologies. The 116 objective of this draft is to provide a catalogue of link-layer 117 events and notifications in various architectures. While this 118 document mentions the utility of this information for detecting 119 change of subnet (or, detecting network attachment - DNA), the 120 detailed usage is left to other documents, namely DNA solution 121 specifications. 123 The document limits itself to the minimum set of information that is 124 necessary for solving the DNA problem [I-D.ietf-dna-goals]. A 125 broader set of information (e.g., signal strenght, packet loss, etc.) 126 may be used for other problem spaces, such as anticipation-based 127 Mobile IP fast handovers [I-D.ietf-mobileip-lowlatency-handoffs-v4] 128 [I-D.ietf-mipshop-fast-mipv6]. Separate documents that are backward- 129 compatible with this one can be generated to discuss further 130 enhancements. 132 These event notifications are considered with hosts in mind, although 133 they may also be available on the network side (e.g., on the access 134 points and routers). An API or protocol-based standard interface may 135 be defined between the link-layer and IP for conveying this 136 information. That activity is beyond the scope of this document. 138 1.1 Requirements notation 140 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 141 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 142 document are to be interpreted as described in [RFC2119]. 144 2. Link-Layer Event Notifications 146 Link-layer event notifications are considered to be one of the inputs 147 to the DNA process. A DNA process is likely to take other inputs 148 (e.g., presence of advertised prefixes, reachability of default 149 gateways) before determining whether IP-layer configuration must be 150 updated. It is expected that the DNA process can take advantage of 151 link-layer notifications when they are made available to IP. While 152 by itself a link-layer notification may not constitute all the input 153 DNA needs, it can at least be useful for prompting the DNA process to 154 collect further information (i.e., other inputs to the process). For 155 example, the node may send a router solicitation as soon as it learns 156 that a new link-layer connection is established. 158 Two basic link-layer events are considered potentially useful to DNA 159 process: link up and link down. Both of these events are 160 deterministic, and their notifications are provided to IP-layer after 161 the events successfully conclude. These events and notifications are 162 associated with a network interface on the node. The IP module may 163 receive simultaneous independent notifications from each one of the 164 network interfaces on the node. 166 "Link" is a communication facility or medium over which network nodes 167 can communicate. Each link is associated with a minimum of two 168 endpoints. An "attachment point" is the link endpoint on the link to 169 which the node is currently connected, such as an access point, a 170 base station, or a wired switch. 172 "Link up" is an event provided by the link-layer that signifies a 173 state change associated with the interface becoming capable of 174 communicating data packets. This event is associated with a link- 175 layer connection between the node and an attachment point. 177 The actual event is managed by the link-layer of the node through 178 execution of link-layer protocols and mechanisms. Once the event 179 successfully completes within the link-layer, its notification MUST 180 be delivered to the IP-layer. By the time the notification is 181 delivered, the link-layer of the node MUST be ready to accept IP 182 packets from the IP and the physical-layers. 184 There is a non-deterministic usage of link up notification to 185 accomodate implementations that desire to indicate the link is up but 186 the data transmission may be blocked in the network (see IEEE 802.3 187 discussion). A link up notification MAY be generated with an 188 appropriate attribute (e.g., "risk" indicated by R-flag) to convey 189 the event. Alternatively, the link-layer implementation MAY choose 190 to delay the link up notification until the risk conditions cease to 191 exist. 193 If a link up with the R-flag set was generated, another link up MUST 194 follow up as soon as the link-layer is capable of generating a 195 deterministic notification. The event attributes MUST indicate 196 whether the packets transmitted since the previous notification were 197 presumed to be blocked (B-flag) or allowed (A-flag) by the network if 198 the link-layer could determine the exact conditions. If the link- 199 layer cannot make a determination about the faith of these packets, 200 it MUST generate a link up without any additional indications (no 201 flags set). 203 "Link down" is an event provided by the link-layer that signifies a 204 state change associated with the interface no longer being capable of 205 communicating data packets. A link down event is only generated once 206 the link-layer considers the link unusable; transient periods of high 207 frame loss are not sufficient. When the link-layer connection is 208 physically or logically torn down and it can no longer carry data 209 packets, this is considered to be a link down event. 211 Among these two events the first one to take place after an interface 212 becomes enabled MUST be a link up event. During the time a network 213 interface is enabled, it may go through a series of link up and down 214 events. Each time the interface changes its point of attachment, a 215 link down event with the previous attachment point MUST be followed 216 by a link up event with the new one. Finally, when the network 217 interface is disabled, this MUST generate a link down event. Each 218 one of these events MUST generate a notification in the order they 219 occur. 221 A node may have to change its IP-layer configuration even when the 222 link-layer connection stays the same. An example scenario is the 223 IPv6 subnet renumbering [RFC2461]. Therefore, there exist cases 224 where IP-layer configuration may have to change even without the IP- 225 layer receiving a link up notification. Therefore, a link-layer 226 notification is not a mandatory indication of a subnet change. 228 In addition to the type of the event (link up, link down), a link- 229 layer notification may also optionally deliver information relating 230 to the attachment point. Such auxiliary information may include 231 identity of the attachment point (e.g., base station identifier), or 232 the IP-layer configuration parameters associated with the attached 233 subnet (e.g., subnet prefix, default gateway address, etc.). While 234 merely knowing that a new link-layer connection is established may 235 prompt DNA process to immediately seek other clues for detecting 236 network configuration change, auxiliary information may constitute 237 further clues (and even the final answers sometimes). In cases where 238 there is a one-to-one mapping between the attachment point 239 identifiers and the IP-layer configurations, learning the former can 240 reveal the latter. Furthermore, IP-layer configuration parameters 241 obtained during link-layer connection may be exactly what the DNA 242 process is trying to discover (e.g., IP address configured during PPP 243 link establishment). 245 The link-layer process leading to a link up or link down event 246 depends on the link technology. While a link-layer notification MUST 247 always indicate the event type, the availability and types of 248 auxiliary information on the attachment point depends on the link- 249 layer technology as well. The following subsections examine four 250 link-layer technologies and describe when a link-layer notification 251 must be generated and what information must be included in it. 253 2.1 GPRS/3GPP 255 GPRS is an enhancement to the GSM data transmission architecture and 256 capabilities, designed to allow for packet switching in user data 257 transmission within the GPRS network as well as for higher quality of 258 service for the IP traffic of Mobile Terminals with external Packets 259 Data Networks such as the Internet or corporate LANs [GPRS][GPRS- 260 LINK]. 262 The GPRS architecture consists of a Radio Access Network and a packet 263 domain Core Network. 265 - The GPRS Radio Access Network is composed of Mobile Terminals (MT), 266 a Base Station Subsystem and Serving GPRS Support Nodes (SGSN). 268 - An IP Core Network that acts as the transport backbone of user 269 datagrams between SGSNs and Gateway GPRS Support Nodes (GGSN). The 270 GGSN ensures the GPRS IP core network connectivity with external 271 networks, such as Internet or Local Area Networks. GGSN acts as the 272 default IP gateway for the MT. 274 A GPRS MT that wants to establish IP-level connections MUST first 275 perform a GPRS attach to the SGSN. This MUST be followed by a 276 request to the GPRS network to settle the necessary soft state 277 mechanism (GPRS tunneling protocol) between its serving SGSN and the 278 GGSN. The soft state maintained between the MT, the SGSN and the 279 GGSN is called a PDP Context. It is used for guaranteeing a 280 negotiated quality of service for the IP flows exchanged between the 281 GPRS MT and an external Packet Data Network such as Internet. It is 282 only after the PDP Context has been established, address 283 autoconfiguration and tunneling mechanism have taken place that the 284 MT's IP packets can be forwarded to and from its remote IP peers. 285 The aim of PDP Context establishment is also to provide IP-level 286 configuration on top of the GPRS link-layer attachment. 288 Successful establishment of a PDP Context on a GPRS link signifies 289 the availability of IP service to the MT. Therefore, this link-layer 290 event MUST generate a link up event notification sent to IP-layer. 291 An MT has the possibility to establish a secondary PDP Context while 292 re-using the IP configuration acquired from a previously established 293 and active PDP Context. Establishment of a secondary PDP Context 294 does not provide additional information to IP-layer. Such a second 295 PDP Context would basically have a different QoS profile so that a 296 different type of application can be served. In that case, 297 activation of the secondary PDP Context MUST NOT generate another 298 link up event notification. However, a secondary PDP Context 299 establishment that triggers a new IP configuration is to be treated 300 from the IP layer as indicated above. 302 With IPv4, the auxiliary information carried along with this 303 notification MUST be the IPv4 address of the MT which is obtained as 304 part of the PDP Context. With IPv6, the PDP Context activation 305 response does not come along with a usable IPv6 address. 306 Effectively, the IPv6 address received from the GGSN in the PDP 307 address field of the message does not contain a valid prefix. The MN 308 actually only uses the interface-identifier extracted from that field 309 to form a link-local address, that it uses afterwards to obtain a 310 valid prefix (e.g., by stateless [RFC2462][GPRS-CN] or stateful 311 [RFC3315] [GPRS-GSSA] address configuration). Therefore no IPv6- 312 related auxiliary information is provided to IP-layer. 314 PDP Context deactivation is used to generate link down event 315 notifications. Considering there may be multiple PDP Contexts with 316 the same IP configuration parameters (e.g., primary and secondary 317 contexts), the deactivation of the PDP Context that has the only 318 instance of a given IP configuration MUST generate a link down event 319 notification. For example, both the primary and the secondary PDP 320 Contexts may be using the same configuration parameters. In that 321 case, deactivation of the primary context would not generate a link 322 down notification while the secondary context is active. If the 323 primary context is deactivated first, and than the secondary is 324 deactivated, only the latter action would generate the link down 325 notification. 327 2.2 cdma2000/3GPP2 329 cdma2000-based 3GPP2 packet data services provide mobile users wide 330 area high-speed access to packet switched networks [CDMA2K]. Some of 331 the major components of the 3GPP2 packet network architecture consist 332 of: 334 - Mobile Station (MS), which allows mobile access to packet-switched 335 networks over a wireless connection. 337 - Radio Access Network, which consists of the Base Station 338 Transceivers, Base Station Controllers, and the Packet Control 339 Function. 341 - Network Access Server known as the Packet Data Switching Node 342 (PDSN). The PDSN also serves as default IP gateway for the IP MS. 344 3GPP2 networks use the Point-to-Point Protocol (PPP [RFC1661]) as the 345 link-layer protocol between the MS and the PDSN. Before any IP 346 packets may be sent or received, PPP MUST reach the Network-Layer 347 Protocol phase, and the IP Control Protocol (IPCP [RFC1332], IPV6CP 348 [RFC2472]) reach the Opened state. When these states are reached in 349 PPP, a link up event notification MUST be delivered to the IP-layer. 351 When the PPP is used for 3GPP2 Simple (i.e., non-Mobile) IPv4 352 Service, IPCP enables configuration of IPv4 address on the MS. This 353 IPv4 address MUST be provided as the auxiliary information along with 354 the link up notification. IPV6CP used for Simple IPv6 service does 355 not provide an IPv6 address, but the interface-identifiers for local 356 and remote end-points of the PPP link. Since there is no standards- 357 mandated correlation between the interface-identifier and other IP- 358 layer configuration parameters, this information is deemed not useful 359 for DNA (nevertheless it MAY be provided as auxiliary information for 360 other uses). 362 IPCP/IPV6CP termination, or the underlying LCP or NCP reaching Closed 363 State signify the end of corresponding IP service on the PPP link. 364 This event MUST generate a link down notification delivered to the 365 IP-layer. 367 2.3 IEEE 802.11/WiFi 369 IEEE 802.11-based WiFi networks are the wireless extension of the 370 Local Area Networks. Currently available standards are IEEE 802.11b 371 [IEEE-802.11b], IEEE 802.11g [IEEE-802.11g], and IEEE 802.11a [IEEE- 372 802.11a]. The specifications define both the MAC-layer and the 373 physical-layer. The MAC layer is the same for all these 374 technologies. 376 Two operating modes are available in the IEEE 802.11 series, either 377 infrastructure mode or ad-hoc mode. In infrastructure mode, all 378 link-layer frames are transmitted to an access point (AP) which then 379 forwards them to the final receiver. A station (STA) MUST establish 380 a IEEE 802.11 link with an AP in order to send and receive IP 381 packets. In a WiFi network that supports Robust Secure Network (RSN 382 [IEEE-802.11i]), successful completion of 4-way handshake between the 383 STA and AP commences the availability of IP service. The link up 384 event notification MUST be generated upon this event. In non-RSN- 385 based networks, successful association or re-association events on 386 the link-layer MUST cause a link up notification sent to the IP- 387 layer. 389 As part of the link establishment, Basic Service Set Identification 390 (BSSID) and Service Set Identifier (SSID) associated with the AP is 391 learned by the STA. BSSID is a unique identifier of the AP, usually 392 set to the MAC address of the wireless interface of the AP. SSID 393 carries the identifier of the Extended Service Set (ESS) - the set 394 composed of APs and associated STAs that share a common distribution 395 system. BSSID and SSID MUST be provided as auxiliary information 396 along with the link up notification. Unfortunately this information 397 does not provide a deterministic indication of whether the IP-layer 398 configuration MUST be changed upon movement. There is no standards- 399 mandated one-to-one relation between the BSSID/SSID pairs and IP 400 subnets. An AP with a given BSSID can connect a STA to any one of 401 multiple IP subnets. Similarly, an ESS with the given SSID may span 402 multiple IP subnets. And finally, the SSIDs are not globally unique. 403 The same SSID may be used by multiple independent ESSs. See Appendix 404 A of [DNA4] for a detailed discussion. Nevertheless, BSSID/SSID 405 information may be used in a probabilistic way by the DNA process, 406 hence it is provided with the link up event notification. 408 Disassociation event in RSN-based, and de-authentication and 409 disassociation events in non-RSN-based WiFi networks MUST translate 410 to link down events, and generate the corresponding link-layer 411 notifications. 413 In ad-hoc mode, mobile station (STA) in range may directly 414 communicate with others, i.e., without any infrastructure or 415 intermediate hop. The set of communicating STAs is called IBSS for 416 Independent Basic Service Set. In an IBSS, only STA services are 417 available, i.e. authentication, deauthentication, privacy and MSDU 418 delivery. STAs do not associate with each other, and therefore may 419 exchange data frames in state 2 (authenticated and not associated) or 420 even in state 1 (unauthenticated and unassociated) if the 421 Distribution System is not used (i.e., "To DS" and "From DS" bits are 422 clear). If authentication is performed, a link up indication can be 423 generated upon authentication, and a link down indication can be 424 generated upon deauthentication. Concerning the link layer 425 identification, both the BSSID (which is a random MAC address chosen 426 by a STA of the IBSS) and SSID may be used to identify a link, but 427 not to make any assumptions on the IP network configuration. 429 2.4 IEEE 802.3 CSMA/CD 431 IEEE 802.3 CSMA/CD (commonly referred to as Ethernet) is the most 432 commonly deployed Local Area Network technology in use today. As 433 deployed today, it is specified by both a physical layer/medium 434 access control (MAC) layer specification [IEEE-802.3]. In order to 435 provide connection of different LANs together into a larger network, 436 802.3 LANs are often bridged together [IEEE-802.1D]. 438 In this section, the terms 802.3 and Ethernet are used 439 interchangeably. This section describes some issues in providing 440 link-layer indications on Ethernet networks, and shows how bridging 441 affects these indications. 443 In Ethernet networks, hosts are connected by wires or by optic fibre 444 to a switch (bridge), a bus (e.g., co-axial cable), a repeater (hub), 445 or directly to another Ethernet device. Interfaces are symmetric, in 446 that while many different physical layers may be present, medium 447 access control is uniform for all devices. 449 In order to determine whether the physical medium is ready for frame 450 transfer, IEEE 802.3 Ethernet specifies its own link monitoring 451 mechanism, which is defined for some, but not all classes of media. 452 Where available, this Link Integrity Test operation is used to 453 identify when packets are able to be received on an Ethernet segment. 454 It is applicable to both wired and optical physical layers, although 455 details vary between technologies (link pulses in twisted pair 456 copper, light levels in fibre). 458 2.4.1 Link Integrity Tests in 802.3 Networks 460 Link Integrity Tests in 802.3 networks typically occur at initial 461 physical connection time (for example, at the auto-negotiation 462 stage), and periodically afterwards. It makes use of physical-layer 463 specific operations to determine if a medium is able to support link- 464 layer frames [IEEE-802.3]. 466 The status of the link as determined by the Link Integrity Test is 467 stored in the variable 'link_status'. Changes to the value of 468 link_status (for example due to Link Integrity Test failure) will 469 generate link indications if the technology dependent interface is 470 implemented on an Ethernet device [IEEE-802.3]. 472 The link_status has possible values of FAIL, READY and OK. When an 473 interface is in FAIL state, Link Integrity Tests have failed. Where 474 status is READY, the link segment has passed integrity tests, but 475 autonegotiation has not completed. OK state indicates that the 476 medium is able to send and receive packets. 478 Upon transition to a particular state the Physical Medium Attachment 479 subsystems generates a PMA_LINK.indicate(link_status). Indications 480 of OK state MAY be used to generate a link up event notification. 482 This indication do not definitively ensure that packets will be able 483 to be received through the bridge domain, though [see the next 484 section]. Such operations are governed by bridging. 485 PMA_LINK.indicate(FAIL) MUST be used to generate a link down 486 notification. 488 2.4.2 IEEE 802.1D Bridging and Its Effects on Link-layer Event 489 Notifications 491 Ethernet networks commonly consist of LANs joined together by 492 transparent bridges (usually implemented as switches). Tranparent 493 bridges require the active topology to be loop free. The Spanning 494 Tree Protocol (STP) achieves this by the exchange of Bridge Protocol 495 Data Unit (BPDU), as defined in [IEEE-802.1D], which leads to, where 496 required, the blocking of ports (i.e., not forwarding). 498 By default, the spanning tree protocol does not know whether a 499 particular newly connected piece of Ethernet will cause a loop. 501 Therefore it will block all traffic from and to newly connected ports 502 with the exception of some unbridged management frames. The STP will 503 determine if the port can be connected to the network in a loop-free 504 manner. 506 For these technologies, even though the link-layer appears available, 507 no data packet forwarding will occur until it is determined that the 508 port can be connected to the network in a loop-free environment. 510 For hosts which are providing indications to upper layer protocols, 511 even if the host itself does not implement bridging or STP, packet 512 delivery across the network can be affected by the presence of 513 bridges. 515 Where the host is not running STP itself, no explicit indication that 516 forwarding has begun is sent from a bridge. Therefore, a host may 517 not know when STP operations have completed, and when it is safe to 518 inform upper layers to transmit packets. 520 Where it is not known that forwarding operations are available, a 521 host needs to assume that STP is being performed, and may indicate 522 full connectivity only based on timeouts or reception of BPDUs. 524 Most hosts today do not listen to BPDU frames. For these hosts, 525 connectivity to the a port which is potentially bridged (any Ethernet 526 port) carries the potential of frame loss if transmissions occur 527 before any bridges' ForwardDelay timers have expired twice. This 528 timeout defaults to 30 seconds (2 * 15 seconds), but may be as high 529 as 60s [IEEE-802.1D]. When sending indications to upper layers, the 530 period where frame forwarding is potentially unavailable should be 531 indicated to upper-layer protocols. 533 Alternatively, a host can listen for BPDUs and use them to determine 534 the length of port blockage which will occur in their particular 535 circumstances. 537 In either case, as soon as link_status becomes OK a link up 538 notification with the attribute (R-flag) that indicates the risk of 539 packet loss MAY be sent. 541 Upon learning that an adjacent port is running STP or RSTP, the host 542 MUST send a link up notification upon expiry of calculated delays to 543 indicate that general packet transfer is available across the LAN. 545 If no bridge configuration messages are received within the 546 Bridge_Max_Age interval (default 20s), then it is likely that there 547 is no visible bridge whose port is enabled for bridging (S8.4.5 of 548 [IEEE-802.1D]), since at least two BPDU hello messages would have 549 been lost. Upon this timeout, a link up notification MUST be 550 generated. 552 It is not easy for a non-STP host to distinguish between Disabled 553 bridge ports and non-bridge ports with no IP nodes on them, as 554 Disabled ports will have no traffic on them, and incur 100% sender 555 loss. 557 Upon this Bridge_Max_Age timeout, a link up notification must be 558 generated. If an earlier link up was generated with the R-flag set, 559 this new one MUST set the A-flag showing that packets sent within the 560 prior interval were likely to have traversed the forwarding path 561 (unless the port is disabled). 563 If a BPDU is received, and the adjacent bridge is running the 564 original Spanning Tree Protocol, then a host cannot successfully send 565 packets until at least twice the ForwardDelay value in the received 566 BPDU has elapsed. After this time, a link up notification MUST be 567 generated. If the previous link up notification had the R-flag set, 568 then the B-flag) MUST be set in this notification. The B-flag 569 signifies that the packets sent within the prior interval were lost. 571 If the bridge is identified as performing Rapid Spanning Tree 572 Protocol (RSTP), it instead waits Bridge_Max_Age after packet 573 reception (advertised in the BPDU's Max Age field), before 574 forwarding. For ports which are known to be point-to-point through 575 autonegotiation, this delay is abbreviated to 3 seconds after 576 autonegotiation completes [IEEE-802.1D]. 578 2.4.3 802.1AB Link-Layer Discovery Protocol 580 The recently defined 802.1AB Link-Layer Discovery Protocol (LLDP) 581 provides information to devices which are directly adjacent to them 582 on the local LAN [IEEE-802.1ab]. 584 LLDP sends information periodically, and at link status change time 585 to indicate the configuration parameters of the device. Devices may 586 either send or receive these messages, or both. 588 The LLDP message may contain a System Capabilities TLV, which 589 describes the MAC and IP layer functions which a device is currently 590 using. Where a host receives the Systems Capabilities TLV which 591 indicate that no Bridging or Repeating is occurring on the LLDP 592 transmitter, then no delays for STP calculation will be applied to 593 packets sent through this transmitter, if the host does not perform 594 STP itself. This would allow the generation of a link up 595 notification. 597 Additionally, if a host receives a Systems Capabilities TLV which 598 indicates that the LLDP transmitter is a bridge, the host's 599 advertisement that it is an (end-host) Station-Only, may tell the 600 bridge not to run STP, and immediately allow forwarding. 602 Proprietary extensions may also indicate that data forwarding is 603 already available on such a port. Discussion of such optimizations 604 is out-of-scope for this document. 606 Due to the protocol's newness and lack of deployment, it is unclear 607 how this protocol will eventually affect DNA in IPv4 or IPv6 608 networks. 610 2.4.4 Summary 612 Link-Layer indications in Ethernet-like networks are complicated by 613 additional unadvertised delays due to Spanning Tree calculations. 614 This may cause re-indication (link up with A-flag) or retraction 615 (link up with B-flag) of indications previously sent to upper layer 616 protocols. 618 3. IANA Considerations 620 This document has no actions for IANA. 622 4. Security Considerations 624 A faked link-layer event notification can be used to launch a 625 denial-of service attack on the node and the associated network. 626 Secure generation and delivery of these notifications MUST be 627 ensured. This is a subject for link-layer and network stack designs 628 and therefore it is outside the scope of this document. 630 5. Contributors 632 Text for the specific link-layer technologies covered by this 633 document are contributed by Eric Njedjou (GPRS), Siva Veerepalli 634 (cdma2000), Nicolas Montavont (IEEE 802.11b), Thomas Noel (IEEE 635 802.11b), and Greg Daley (IEEE 802.3). 637 6. Acknowledgements 639 The authors would like to acknowledge Bernard Aboba, Sanjeev Athalye, 640 JinHyeock Choi, John Loughney, Pekka Nikander, Tom Petch, Dan 641 Romascanu, Pekka Savola, and Muhammad Mukarram bin Tariq for their 642 useful comments and suggestions. 644 7. References 646 7.1 Normative References 648 [CDMA2K] "IS-835 - cdma2000 Wireless IP Network Standard", . 650 [GPRS] "Digital cellular telecommunications system (Phase 2+); 651 General Packet Radio Service (GPRS) Service description; 652 Stage 2", 3GPP 3GPP TS 03.60 version 7.9.0 Release 98. 654 [GPRS-LINK] 655 "Digital cellular telecommunications system (Phase 2+); 656 Radio subsystem link control", 3GPP GSM 03.05 version 657 7.0.0 Release 98. 659 [I-D.ietf-dna-goals] 660 Choi, J., "Goals of Detecting Network Attachment in IPv6", 661 draft-ietf-dna-goals-04 (work in progress), December 2004. 663 [IEEE-802.11a] 664 Institute of Electrical and Electronics Engineers, "IEEE 665 Std 802.11a-1999, supplement to IEEE Std 802.11-1999, Part 666 11: Wireless MAN Medium Access Control (MAC) and Physical 667 Layer (PHY) specifications: High-speed Physical Layer in 668 the 5 GHZ band", IEEE Standard 802.11a, September 1999. 670 [IEEE-802.11b] 671 Institute of Electrical and Electronics Engineers, "IEEE 672 Std 802 Part 11, Information technology - 673 Telecomunications and information exchange between systems 674 - Local and metropolitan area networks - Specific 675 requirements - Part 11: Wireless Lan Medium Access Control 676 (MAC) And Physical Layer (PHY) Specifications", 677 IEEE Standard 802.11b, August 1999. 679 [IEEE-802.11g] 680 Institute of Electrical and Electronics Engineers, "IEEE 681 Std 802.11g-2003, Amendment to IEEE Std 802.11, 1999 682 edition, Part 11: Wireless MAN Medium Access Control (MAC) 683 and Physical Layer (PHY) specifications. Amendment 4: 684 Further Higher Data Rate Extension in the 2.4 GHz Band", 685 IEEE Standard 802.11g, June 2003. 687 [IEEE-802.11i] 688 Institute of Electrical and Electronics Engineers, 689 "Supplement to STANDARD FOR Telecommunications and 690 Information Exchange between Systems - LAN/MAN Specific 691 Requirements - Part 11: Wireless Medium Access Control 692 (MAC) and physical layer (PHY) specifications: 693 Specification for Enhanced Security", IEEE IEEE 802.11i, 694 December 2004. 696 [IEEE-802.1D] 697 Institute of Electrical and Electronics Engineers, "IEEE 698 standard for local and metropolitan area networks - common 699 specific ations - Media access control (MAC) Bridges", 700 ISO/IEC IEEE Std 802.1D, 2004. 702 [IEEE-802.1ab] 703 Institute of Electrical and Electronics Engineers, "Draft 704 Standard for Local and Metropolitan Networks: Station and 705 Media Access Control Connectivity Discovery (Draft 13)", 706 IEEE draft Std 802.1AB, 2004. 708 [IEEE-802.3] 709 Institute of Electrical and Electronics Engineers, "IEEE 710 standard for local and metropolitan area networks - 711 Specific Require ments, Part 3: Carrier Sense Multiple 712 Access with Collision Detection (CSMA/CD) Access Method 713 and Physical Layer Specifications", ISO/IEC IEEE 714 Std 802.3, 2002. 716 [RFC1332] McGregor, G., "The PPP Internet Protocol Control Protocol 717 (IPCP)", RFC 1332, May 1992. 719 [RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, 720 RFC 1661, July 1994. 722 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 723 Requirement Levels", BCP 14, RFC 2119, March 1997. 725 [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address 726 Autoconfiguration", RFC 2462, December 1998. 728 [RFC2472] Haskin, D. and E. Allen, "IP Version 6 over PPP", 729 RFC 2472, December 1998. 731 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 732 and M. Carney, "Dynamic Host Configuration Protocol for 733 IPv6 (DHCPv6)", RFC 3315, July 2003. 735 7.2 Informative References 737 [GPRS-CN] "Technical Specification Group Core Network; 738 Internetworking between the Public Land Mobile Network 739 (PLMN) supporting packet based services and Packet Data 740 Networks (PDN) (Release 6)", 3GPP 3GPP TS 29.061 version 741 6.1.0 2004-06. 743 [GPRS-GSSA] 744 "Technical Specification Group Services and System Aspect; 745 General Packet Radio Service (GPRS) Service description; 746 Stage 2 (Release 6)", 3GPP 3GPP TS 23.060 version 6.5.0 747 2004-06. 749 [I-D.ietf-mipshop-fast-mipv6] 750 Koodli, R., "Fast Handovers for Mobile IPv6", 751 draft-ietf-mipshop-fast-mipv6-03 (work in progress), 752 October 2004. 754 [I-D.ietf-mobileip-lowlatency-handoffs-v4] 755 Malki, K., "Low latency Handoffs in Mobile IPv4", 756 draft-ietf-mobileip-lowlatency-handoffs-v4-09 (work in 757 progress), June 2004. 759 [RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor 760 Discovery for IP Version 6 (IPv6)", RFC 2461, 761 December 1998. 763 Author's Address 765 Alper E. Yegin (editor) 766 Samsung Advanced Institute of Technology 767 75 West Plumeria Drive 768 San Jose, CA 95134 769 USA 771 Phone: +1 408 544 5656 772 Email: alper.yegin@samsung.com 774 Appendix A. Change History 776 The following changes were made on draft version 00: 778 - IEEE 802.11 ad-hoc mode discussion added. 780 - IPv6 address configuration over 3GPP networks clarified. 782 The following change were made on draft version 01: 784 - Text for IEEE 802.3 added. 786 - Multiple 3GPP PDP Contexts scenario clarified. 788 Intellectual Property Statement 790 The IETF takes no position regarding the validity or scope of any 791 Intellectual Property Rights or other rights that might be claimed to 792 pertain to the implementation or use of the technology described in 793 this document or the extent to which any license under such rights 794 might or might not be available; nor does it represent that it has 795 made any independent effort to identify any such rights. Information 796 on the procedures with respect to rights in RFC documents can be 797 found in BCP 78 and BCP 79. 799 Copies of IPR disclosures made to the IETF Secretariat and any 800 assurances of licenses to be made available, or the result of an 801 attempt made to obtain a general license or permission for the use of 802 such proprietary rights by implementers or users of this 803 specification can be obtained from the IETF on-line IPR repository at 804 http://www.ietf.org/ipr. 806 The IETF invites any interested party to bring to its attention any 807 copyrights, patents or patent applications, or other proprietary 808 rights that may cover technology that may be required to implement 809 this standard. Please address the information to the IETF at 810 ietf-ipr@ietf.org. 812 Disclaimer of Validity 814 This document and the information contained herein are provided on an 815 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 816 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 817 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 818 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 819 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 820 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 822 Copyright Statement 824 Copyright (C) The Internet Society (2005). This document is subject 825 to the rights, licenses and restrictions contained in BCP 78, and 826 except as set forth therein, the authors retain all their rights. 828 Acknowledgment 830 Funding for the RFC Editor function is currently provided by the 831 Internet Society.