Network Working Group                                      A. Yegin, Ed.
Internet-Draft                                               Samsung AIT
Expires: April 27, 2006                                 October 24, 2005

    Link-layer Event Notifications for Detecting Network Attachments

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on April 27, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2005).


   Certain network access technologies are capable of providing various
   link-layer status information to IP.  Link-layer event notifications
   can help IP expeditiously detect configuration changes.  This
   document provides a non-exhaustive catalogue of information available
   from well-known access technologies.

Yegin                    Expires April 27, 2006                 [Page 1]

Internet-Draft          L2 Notifications for DNA            October 2005

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1   Requirements notation  . . . . . . . . . . . . . . . . . .  4
   2.  Link-Layer Event Notifications . . . . . . . . . . . . . . . .  5
     2.1   GPRS/3GPP  . . . . . . . . . . . . . . . . . . . . . . . .  7
     2.2   cdma2000/3GPP2 . . . . . . . . . . . . . . . . . . . . . .  8
     2.3   IEEE 802.11/WiFi . . . . . . . . . . . . . . . . . . . . .  9
     2.4   IEEE 802.3 CSMA/CD . . . . . . . . . . . . . . . . . . . . 10
       2.4.1   Link Integrity Tests in 802.3 Networks . . . . . . . . 11
       2.4.2   IEEE 802.1D Bridging and Its Effects on Link-layer
               Event Notifications  . . . . . . . . . . . . . . . . . 12
       2.4.3   802.1AB Link-Layer Discovery Protocol  . . . . . . . . 14
       2.4.4   Summary  . . . . . . . . . . . . . . . . . . . . . . . 14
   3.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 15
   4.  Security Considerations  . . . . . . . . . . . . . . . . . . . 16
   5.  Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 17
   6.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18
   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
     7.1   Normative References . . . . . . . . . . . . . . . . . . . 19
     7.2   Informative References . . . . . . . . . . . . . . . . . . 20
       Author's Address . . . . . . . . . . . . . . . . . . . . . . . 21
   A.  Change History . . . . . . . . . . . . . . . . . . . . . . . . 22
       Intellectual Property and Copyright Statements . . . . . . . . 23

Yegin                    Expires April 27, 2006                 [Page 2]

Internet-Draft          L2 Notifications for DNA            October 2005

1.  Introduction

   It is not an uncommon occurrence for a node to change its point-of
   attachment to the network.  This can happen due to mobile usage
   (e.g., a mobile phone moving among base stations) or nomadic usage
   (e.g., road-warrior case).

   A node changing its point-of attachment to the network may end up
   changing its IP subnet and therefore require re-configuration of IP-
   layer parameters, such as IP address, default gateway information,
   and DNS server address.  Detecting the subnet change can usually use
   network-layer indications such as a change in the advertised prefixes
   (i.e., appearance and disappearance of prefixes).  But generally
   reliance on such indications does not yield rapid detection, since
   these indications are not readily available upon node changing its
   point of attachment.

   The changes to the underlying link-layer status can be relayed to IP
   in the form of link-layer event notifications.  Establishment and
   tear down of a link-layer connection are two basic events types.
   Additional information can be conveyed in addition to the event type,
   such as the identifier of the network attachment point (e.g., IEEE
   802.11 BSSID and SSID), or network-layer configuration parameters
   obtained via the link-layer attachment process if available.  It is
   envisaged that such event notifications can in certain circumstances
   be used to expedite the inter-subnet movement detection and
   reconfiguration process.  For example, the notification indicating
   that the node has established a new link-layer connection MAY be used
   for immediately probing the network for a possible configuration
   change.  In the absence of such a notification from the link-layer,
   IP has to wait for indications that are not immediately available,
   such as receipt of next scheduled router advertisement,
   unreachability of the default gateway, etc.

   It should be noted that a link-layer event notification does not
   always translate into a subnet change.  Even if the node has torn
   down a link-layer connection with one attachment point and
   established a new connection with another, it may still be attached
   to the same IP subnet.  For example, several IEEE 802.11 access
   points can be attached to the same IP subnet.  Moving among these
   access points does not warrant any IP-layer configuration change.

   In order to enable an enhanced scheme for detecting change of subnet,
   we need to define link-layer event notifications that can be
   realistically expected from various access technologies.  The
   objective of this draft is to provide a catalogue of link-layer
   events and notifications in various architectures.  While this
   document mentions the utility of this information for detecting

Yegin                    Expires April 27, 2006                 [Page 3]

Internet-Draft          L2 Notifications for DNA            October 2005

   change of subnet (or, detecting network attachment - DNA), the
   detailed usage is left to other documents, namely DNA solution

   The document limits itself to the minimum set of information that is
   necessary for solving the DNA problem [I-D.ietf-dna-goals].  A
   broader set of information (e.g., signal strength, packet loss, etc.)
   may be used for other problem spaces, such as anticipation-based
   Mobile IP fast handovers [I-D.ietf-mobileip-lowlatency-handoffs-v4]
   [I-D.ietf-mipshop-fast-mipv6].  Separate documents that are backward-
   compatible with this one can be generated to discuss further

   These event notifications are considered with hosts in mind, although
   they may also be available on the network side (e.g., on the access
   points and routers).  An API or protocol-based standard interface may
   be defined between the link-layer and IP for conveying this
   information.  That activity is beyond the scope of this document.

1.1  Requirements notation

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in [RFC2119].

Yegin                    Expires April 27, 2006                 [Page 4]

Internet-Draft          L2 Notifications for DNA            October 2005

2.  Link-Layer Event Notifications

   Link-layer event notifications are considered to be one of the inputs
   to the DNA process.  A DNA process is likely to take other inputs
   (e.g., presence of advertised prefixes, reachability of default
   gateways) before determining whether IP-layer configuration must be
   updated.  It is expected that the DNA process can take advantage of
   link-layer notifications when they are made available to IP.  While
   by itself a link-layer notification may not constitute all the input
   DNA needs, it can at least be useful for prompting the DNA process to
   collect further information (i.e., other inputs to the process).  For
   example, the node may send a router solicitation as soon as it learns
   that a new link-layer connection is established.

   Two basic link-layer events are considered potentially useful to DNA
   process: link up and link down.  Both of these events are
   deterministic, and their notifications are provided to IP-layer after
   the events successfully conclude.  These events and notifications are
   associated with a network interface on the node.  The IP module may
   receive simultaneous independent notifications from each one of the
   network interfaces on the node.

   "Link" is a communication facility or medium over which network nodes
   can communicate.  Each link is associated with a minimum of two
   endpoints.  An "attachment point" is the link endpoint on the link to
   which the node is currently connected, such as an access point, a
   base station, or a wired switch.

   "Link up" is an event provided by the link-layer that signifies a
   state change associated with the interface becoming capable of
   communicating data packets.  This event is associated with a link-
   layer connection between the node and an attachment point.

   The actual event is managed by the link-layer of the node through
   execution of link-layer protocols and mechanisms.  Once the event
   successfully completes within the link-layer, its notification MUST
   be delivered to the IP-layer.  By the time the notification is
   delivered, the link-layer of the node MUST be ready to accept IP
   packets from the IP and the physical-layers.

   There is a non-deterministic usage of link up notification to
   accomodate implementations that desire to indicate the link is up but
   the data transmission may be blocked in the network (see IEEE 802.3
   discussion).  A link up notification MAY be generated with an
   appropriate attribute (e.g., "risk" indicated by R-flag) to convey
   the event.  Alternatively, the link-layer implementation MAY choose
   to delay the link up notification until the risk conditions cease to

Yegin                    Expires April 27, 2006                 [Page 5]

Internet-Draft          L2 Notifications for DNA            October 2005

   If a link up with the R-flag set was generated, another link up MUST
   follow up as soon as the link-layer is capable of generating a
   deterministic notification.  The event attributes MUST indicate
   whether the packets transmitted since the previous notification were
   presumed to be blocked (B-flag) or allowed (A-flag) by the network if
   the link-layer could determine the exact conditions.  If the link-
   layer cannot make a determination about the faith of these packets,
   it MUST generate a link up without any additional indications (no
   flags set).

   "Link down" is an event provided by the link-layer that signifies a
   state change associated with the interface no longer being capable of
   communicating data packets.  A link down event is only generated once
   the link-layer considers the link unusable; transient periods of high
   frame loss are not sufficient.  When the link-layer connection is
   physically or logically torn down and it can no longer carry data
   packets, this is considered to be a link down event.

   Among these two events the first one to take place after an interface
   becomes enabled MUST be a link up event.  During the time a network
   interface is enabled, it may go through a series of link up and down
   events.  Each time the interface changes its point of attachment, a
   link down event with the previous attachment point MUST be followed
   by a link up event with the new one.  Finally, when the network
   interface is disabled, this MUST generate a link down event.  Each
   one of these events MUST generate a notification in the order they

   A node may have to change its IP-layer configuration even when the
   link-layer connection stays the same.  An example scenario is the
   IPv6 subnet renumbering [RFC2461].  Therefore, there exist cases
   where IP-layer configuration may have to change even without the IP-
   layer receiving a link up notification.  Therefore, a link-layer
   notification is not a mandatory indication of a subnet change.

   In addition to the type of the event (link up, link down), a link-
   layer notification may also optionally deliver information relating
   to the attachment point.  Such auxiliary information may include
   identity of the attachment point (e.g., base station identifier), or
   the IP-layer configuration parameters associated with the attached
   subnet (e.g., subnet prefix, default gateway address, etc.).  While
   merely knowing that a new link-layer connection is established may
   prompt DNA process to immediately seek other clues for detecting
   network configuration change, auxiliary information may constitute
   further clues (and even the final answers sometimes).  In cases where
   there is a one-to-one mapping between the attachment point
   identifiers and the IP-layer configurations, learning the former can
   reveal the latter.  Furthermore, IP-layer configuration parameters

Yegin                    Expires April 27, 2006                 [Page 6]

Internet-Draft          L2 Notifications for DNA            October 2005

   obtained during link-layer connection may be exactly what the DNA
   process is trying to discover (e.g., IP address configured during PPP
   link establishment).

   The link-layer process leading to a link up or link down event
   depends on the link technology.  While a link-layer notification MUST
   always indicate the event type, the availability and types of
   auxiliary information on the attachment point depends on the link-
   layer technology as well.  The following subsections examine four
   link-layer technologies and describe when a link-layer notification
   must be generated and what information must be included in it.

2.1  GPRS/3GPP

   GPRS is an enhancement to the GSM data transmission architecture and
   capabilities, designed to allow for packet switching in user data
   transmission within the GPRS network as well as for higher quality of
   service for the IP traffic of Mobile Terminals with external Packets
   Data Networks such as the Internet or corporate LANs [GPRS][GPRS-

   The GPRS architecture consists of a Radio Access Network and a packet
   domain Core Network.

   - The GPRS Radio Access Network is composed of Mobile Terminals (MT),
   a Base Station Subsystem and Serving GPRS Support Nodes (SGSN).

   - An IP Core Network that acts as the transport backbone of user
   datagrams between SGSNs and Gateway GPRS Support Nodes (GGSN).  The
   GGSN ensures the GPRS IP core network connectivity with external
   networks, such as Internet or Local Area Networks.  GGSN acts as the
   default IP gateway for the MT.

   A GPRS MT that wants to establish IP-level connections MUST first
   perform a GPRS attach to the SGSN.  This MUST be followed by a
   request to the GPRS network to settle the necessary soft state
   mechanism (GPRS tunneling protocol) between its serving SGSN and the
   GGSN.  The soft state maintained between the MT, the SGSN and the
   GGSN is called a PDP Context.  It is used for guaranteeing a
   negotiated quality of service for the IP flows exchanged between the
   GPRS MT and an external Packet Data Network such as Internet.  It is
   only after the PDP Context has been established, address
   autoconfiguration and tunneling mechanism have taken place that the
   MT's IP packets can be forwarded to and from its remote IP peers.
   The aim of PDP Context establishment is also to provide IP-level
   configuration on top of the GPRS link-layer attachment.

   Successful establishment of a PDP Context on a GPRS link signifies

Yegin                    Expires April 27, 2006                 [Page 7]

Internet-Draft          L2 Notifications for DNA            October 2005

   the availability of IP service to the MT.  Therefore, this link-layer
   event MUST generate a link up event notification sent to IP-layer.
   An MT has the possibility to establish a secondary PDP Context while
   re-using the IP configuration acquired from a previously established
   and active PDP Context.  Establishment of a secondary PDP Context
   does not provide additional information to IP-layer.  Such a second
   PDP Context would basically have a different QoS profile so that a
   different type of application can be served.  In that case,
   activation of the secondary PDP Context MUST NOT generate another
   link up event notification.  However, a secondary PDP Context
   establishment that triggers a new IP configuration is to be treated
   from the IP layer as indicated above.

   With IPv4, the auxiliary information carried along with this
   notification MUST be the IPv4 address of the MT which is obtained as
   part of the PDP Context.  With IPv6, the PDP Context activation
   response does not come along with a usable IPv6 address.
   Effectively, the IPv6 address received from the GGSN in the PDP
   address field of the message does not contain a valid prefix.  The MN
   actually only uses the interface-identifier extracted from that field
   to form a link-local address, that it uses afterwards to obtain a
   valid prefix (e.g., by stateless [RFC2462][GPRS-CN] or stateful
   [RFC3315] [GPRS-GSSA] address configuration).  Therefore no IPv6-
   related auxiliary information is provided to IP-layer.

   PDP Context deactivation is used to generate link down event
   notifications.  Considering there may be multiple PDP Contexts with
   the same IP configuration parameters (e.g., primary and secondary
   contexts), the deactivation of the PDP Context that has the only
   instance of a given IP configuration MUST generate a link down event
   notification.  For example, both the primary and the secondary PDP
   Contexts may be using the same configuration parameters.  In that
   case, deactivation of the primary context would not generate a link
   down notification while the secondary context is active.  If the
   primary context is deactivated first, and than the secondary is
   deactivated, only the latter action would generate the link down

2.2  cdma2000/3GPP2

   cdma2000-based 3GPP2 packet data services provide mobile users wide
   area high-speed access to packet switched networks [CDMA2K].  Some of
   the major components of the 3GPP2 packet network architecture consist

   - Mobile Station (MS), which allows mobile access to packet-switched
   networks over a wireless connection.

Yegin                    Expires April 27, 2006                 [Page 8]

Internet-Draft          L2 Notifications for DNA            October 2005

   - Radio Access Network, which consists of the Base Station
   Transceivers, Base Station Controllers, and the Packet Control

   - Network Access Server known as the Packet Data Switching Node
   (PDSN).  The PDSN also serves as default IP gateway for the IP MS.

   3GPP2 networks use the Point-to-Point Protocol (PPP [RFC1661]) as the
   link-layer protocol between the MS and the PDSN.  Before any IP
   packets may be sent or received, PPP MUST reach the Network-Layer
   Protocol phase, and the IP Control Protocol (IPCP [RFC1332], IPV6CP
   [RFC2472]) reach the Opened state.  When these states are reached in
   PPP, a link up event notification MUST be delivered to the IP-layer.

   When the PPP is used for 3GPP2 Simple (i.e., non-Mobile) IPv4
   Service, IPCP enables configuration of IPv4 address on the MS.  This
   IPv4 address MUST be provided as the auxiliary information along with
   the link up notification.  IPV6CP used for Simple IPv6 service does
   not provide an IPv6 address, but  the interface-identifiers for local
   and remote end-points of the PPP link.  Since there is no standards-
   mandated correlation between the interface-identifier and other IP-
   layer configuration parameters, this information is deemed not useful
   for DNA (nevertheless it MAY be provided as auxiliary information for
   other uses).

   IPCP/IPV6CP termination, or the underlying LCP or NCP reaching Closed
   State signify the end of corresponding IP service on the PPP link.
   This event MUST generate a link down notification delivered to the

2.3  IEEE 802.11/WiFi

   IEEE 802.11-based WiFi networks are the wireless extension of the
   Local Area Networks.  Currently available standards are IEEE 802.11b
   [IEEE-802.11b], IEEE 802.11g [IEEE-802.11g], and IEEE 802.11a [IEEE-
   802.11a].  The specifications define both the MAC-layer and the
   physical-layer.  The MAC layer is the same for all these

   Two operating modes are available in the IEEE 802.11 series, either
   infrastructure mode or ad-hoc mode.  In infrastructure mode, all
   link-layer frames are transmitted to an access point (AP) which then
   forwards them to the final receiver.  A station (STA) MUST establish
   a IEEE 802.11 link with an AP in order to send and receive IP
   packets.  In a WiFi network that supports Robust Secure Network (RSN
   [IEEE-802.11i]), successful completion of 4-way handshake between the
   STA and AP commences the availability of IP service.  The link up
   event notification MUST be generated upon this event.  In non-RSN-

Yegin                    Expires April 27, 2006                 [Page 9]

Internet-Draft          L2 Notifications for DNA            October 2005

   based networks, successful association or re-association events on
   the link-layer MUST cause a link up notification sent to the IP-

   As part of the link establishment, Basic Service Set Identification
   (BSSID) and Service Set Identifier (SSID) associated with the AP is
   learned by the STA.  BSSID is a unique identifier of the AP, usually
   set to the MAC address of the wireless interface of the AP.  SSID
   carries the identifier of the Extended Service Set (ESS) - the set
   composed of APs and associated STAs that share a common distribution
   system.  BSSID and SSID MUST be provided as auxiliary information
   along with the link up notification.  Unfortunately this information
   does not provide a deterministic indication of whether the IP-layer
   configuration MUST be changed upon movement.  There is no standards-
   mandated one-to-one relation between the BSSID/SSID pairs and IP
   subnets.  An AP with a given BSSID can connect a STA to any one of
   multiple IP subnets.  Similarly, an ESS with the given SSID may span
   multiple IP subnets.  And finally, the SSIDs are not globally unique.
   The same SSID may be used by multiple independent ESSs.  See Appendix
   A of [DNA4] for a detailed discussion.  Nevertheless, BSSID/SSID
   information may be used in a probabilistic way by the DNA process,
   hence it is provided with the link up event notification.

   Disassociation event in non-RSN-based, and de-authentication and
   disassociation events in RSN-based WiFi networks MUST translate to
   link down events, and generate the corresponding link-layer

   In ad-hoc mode, mobile stations (STA) in range may directly
   communicate with each other, i.e., without any infrastructure or
   intermediate hop.  The set of communicating STAs is called IBSS for
   Independent Basic Service Set. In an IBSS, only STA services are
   available, i.e. authentication, deauthentication, privacy and MSDU
   delivery.  STAs do not associate with each other, and therefore may
   exchange data frames in state 2 (authenticated and not associated) or
   even in state 1 (unauthenticated and unassociated) if the
   Distribution System is not used (i.e., "To DS" and "From DS" bits are
   clear).  If authentication is performed, a link up indication can be
   generated upon authentication, and a link down indication can be
   generated upon deauthentication.  Concerning the link layer
   identification, both the BSSID (which is a random MAC address chosen
   by a STA of the IBSS) and SSID may be used to identify a link, but
   not to make any assumptions on the IP network configuration.

2.4  IEEE 802.3 CSMA/CD

   IEEE 802.3 CSMA/CD (commonly referred to as Ethernet) is the most
   commonly deployed Local Area Network technology in use today.  As

Yegin                    Expires April 27, 2006                [Page 10]

Internet-Draft          L2 Notifications for DNA            October 2005

   deployed today, it is specified by a physical layer/medium access
   control (MAC) layer specification [IEEE-802.3].  In order to provide
   connection of different LANs together into a larger network, 802.3
   LANs are often bridged together [IEEE-802.1D].

   In this section, the terms 802.3 and Ethernet are used
   interchangeably.  This section describes some issues in providing
   link-layer indications on Ethernet networks, and shows how bridging
   affects these indications.

   In Ethernet networks, hosts are connected by wires or by optic fibre
   to a switch (bridge), a bus (e.g., co-axial cable), a repeater (hub),
   or directly to another Ethernet device.  Interfaces are symmetric, in
   that while many different physical layers may be present, medium
   access control is uniform for all devices.

   In order to determine whether the physical medium is ready for frame
   transfer, IEEE 802.3 Ethernet specifies its own link monitoring
   mechanism, which is defined for some, but not all classes of media.
   Where available, this Link Integrity Test operation is used to
   identify when packets are able to be received on an Ethernet segment.
   It is applicable to both wired and optical physical layers, although
   details vary between technologies (link pulses in twisted pair
   copper, light levels in fibre).

2.4.1  Link Integrity Tests in 802.3 Networks

   Link Integrity Tests in 802.3 networks typically occur at initial
   physical connection time (for example, at the auto-negotiation
   stage), and periodically afterwards.  It makes use of physical-layer
   specific operations to determine if a medium is able to support link-
   layer frames [IEEE-802.3].

   The status of the link as determined by the Link Integrity Test is
   stored in the variable 'link_status'.  Changes to the value of
   link_status (for example due to Link Integrity Test failure) will
   generate link indications if the technology dependent interface is
   implemented on an Ethernet device [IEEE-802.3].

   The link_status has possible values of FAIL, READY and OK.  When an
   interface is in FAIL state, Link Integrity Tests have failed.  Where
   status is READY, the link segment has passed integrity tests, but
   autonegotiation has not completed.  OK state indicates that the
   medium is able to send and receive packets.

   Upon transition to a particular state the Physical Medium Attachment
   subsystems generates a PMA_LINK.indicate(link_status).  Indications
   of OK state MAY be used to generate a link up event notification.

Yegin                    Expires April 27, 2006                [Page 11]

Internet-Draft          L2 Notifications for DNA            October 2005

   This indication do not definitively ensure that packets will be able
   to be received through the bridge domain, though [see the next
   section].  Such operations are governed by bridging.
   PMA_LINK.indicate(FAIL) MUST be used to generate a link down

2.4.2  IEEE 802.1D Bridging and Its Effects on Link-layer Event

   Ethernet networks commonly consist of LANs joined together by
   transparent bridges (usually implemented as switches).  Transparent
   bridges require the active topology to be loop free.  The Spanning
   Tree Protocol (STP) achieves this by the exchange of Bridge Protocol
   Data Unit (BPDU), as defined in [IEEE-802.1D], which leads to, where
   required, the blocking of ports (i.e., not forwarding).

   By default, the spanning tree protocol does not know whether a
   particular newly connected piece of Ethernet will cause a loop.

   Therefore it will block all traffic from and to newly connected ports
   with the exception of some unbridged management frames.  The STP will
   determine if the port can be connected to the network in a loop-free

   For these technologies, even though the link-layer appears available,
   no data packet forwarding will occur until it is determined that the
   port can be connected to the network in a loop-free environment.

   For hosts which are providing indications to upper layer protocols,
   even if the host itself does not implement bridging or STP, packet
   delivery across the network can be affected by the presence of

   Where the host is not running STP itself, no explicit indication that
   forwarding has begun is sent from a bridge.  Therefore, a host may
   not know when STP operations have completed, and when it is safe to
   inform upper layers to transmit packets.

   Where it is not known that forwarding operations are available, a
   host needs to assume that STP is being performed, and may indicate
   full connectivity only based on timeouts or reception of BPDUs.

   Most hosts today do not listen to BPDU frames.  For these hosts,
   connectivity to the a port which is potentially bridged (any Ethernet
   port) carries the potential of frame loss if transmissions occur
   before any bridges' ForwardDelay timers have expired twice.  This
   timeout defaults to 30 seconds (2 * 15 seconds), but may be as high
   as 60s [IEEE-802.1D].  When sending indications to upper layers, the

Yegin                    Expires April 27, 2006                [Page 12]

Internet-Draft          L2 Notifications for DNA            October 2005

   period where frame forwarding is potentially unavailable should be
   indicated to upper-layer protocols.

   Alternatively, a host can listen for BPDUs and use them to determine
   the length of port blockage which will occur in their particular

   In either case,  as soon as link_status becomes OK a link up
   notification with the attribute (R-flag) that indicates the risk of
   packet loss MAY be sent.

   Upon learning that an adjacent port is running STP or RSTP, the host
   MUST send a link up notification upon expiry of calculated delays to
   indicate that general packet transfer is available across the LAN.

   If no bridge configuration messages are received within the
   Bridge_Max_Age interval (default 20s), then it is likely that there
   is no visible bridge whose port is enabled for bridging (S8.4.5 of
   [IEEE-802.1D]), since at least two BPDU hello messages would have
   been lost.  Upon this timeout, a link up notification MUST be

   It is not easy for a non-STP host to distinguish between Disabled
   bridge ports and non-bridge ports with no IP nodes on them, as
   Disabled ports will have no traffic on them, and incur 100% sender

   Upon this Bridge_Max_Age timeout, a link up notification must be
   generated.  If an earlier link up was generated with the R-flag set,
   this new one MUST set the A-flag showing that packets sent within the
   prior interval were likely to have traversed the forwarding path
   (unless the port is disabled).

   If a BPDU is received, and the adjacent bridge is running the
   original Spanning Tree Protocol, then a host cannot successfully send
   packets until at least twice the ForwardDelay value in the received
   BPDU has elapsed.  After this time, a link up notification MUST be
   generated.  If the previous link up notification had the R-flag set,
   then the B-flag) MUST be set in this notification.  The B-flag
   signifies that the packets sent within the prior interval were lost.

   If the bridge is identified as performing Rapid Spanning Tree
   Protocol (RSTP), it instead waits Bridge_Max_Age after packet
   reception (advertised in the BPDU's Max Age field), before
   forwarding.  For ports which are known to be point-to-point through
   autonegotiation, this delay is abbreviated to 3 seconds after
   autonegotiation completes [IEEE-802.1D].

Yegin                    Expires April 27, 2006                [Page 13]

Internet-Draft          L2 Notifications for DNA            October 2005

2.4.3  802.1AB Link-Layer Discovery Protocol

   The recently defined 802.1AB Link-Layer Discovery Protocol (LLDP)
   provides information to devices which are directly adjacent to them
   on the local LAN [IEEE-802.1ab].

   LLDP sends information periodically, and at link status change time
   to indicate the configuration parameters of the device.  Devices may
   either send or receive these messages, or both.

   The LLDP message may contain a System Capabilities TLV, which
   describes the MAC and IP layer functions which a device is currently
   using.  Where a host receives the Systems Capabilities TLV which
   indicate that no Bridging or Repeating is occurring on the LLDP
   transmitter, then no delays for STP calculation will be applied to
   packets sent through this transmitter, if the host does not perform
   STP itself.  This would allow the generation of a link up

   Additionally, if a host receives a Systems Capabilities TLV which
   indicates that the LLDP transmitter is a bridge, the host's
   advertisement that it is an (end-host) Station-Only, may tell the
   bridge not to run STP, and immediately allow forwarding.

   Proprietary extensions may also indicate that data forwarding is
   already available on such a port.  Discussion of such optimizations
   is out-of-scope for this document.

   Due to the protocol's newness and lack of deployment, it is unclear
   how this protocol will eventually affect DNA in IPv4 or IPv6

2.4.4  Summary

   Link-Layer indications in Ethernet-like networks are complicated by
   additional unadvertised delays due to Spanning Tree calculations.
   This may cause re-indication (link up with A-flag) or retraction
   (link up with B-flag) of indications previously sent to upper layer

Yegin                    Expires April 27, 2006                [Page 14]

Internet-Draft          L2 Notifications for DNA            October 2005

3.  IANA Considerations

   This document has no actions for IANA.

Yegin                    Expires April 27, 2006                [Page 15]

Internet-Draft          L2 Notifications for DNA            October 2005

4.  Security Considerations

   A faked link-layer event notification can be used to launch a
   denial-of service attack on the node and the associated network.
   Secure generation and delivery of these notifications MUST be
   ensured.  This is a subject for link-layer and network stack designs
   and therefore it is outside the scope of this document.

Yegin                    Expires April 27, 2006                [Page 16]

Internet-Draft          L2 Notifications for DNA            October 2005

5.  Contributors

   Text for the specific link-layer technologies covered by this
   document are contributed by Eric Njedjou (GPRS), Siva Veerepalli
   (cdma2000), Nicolas Montavont (IEEE 802.11b), Thomas Noel (IEEE
   802.11b), and Greg Daley (IEEE 802.3).

Yegin                    Expires April 27, 2006                [Page 17]

Internet-Draft          L2 Notifications for DNA            October 2005

6.  Acknowledgements

   The authors would like to acknowledge Bernard Aboba, Sanjeev Athalye,
   JinHyeock Choi, John Loughney, Pekka Nikander, Brett Pentland, Tom
   Petch, Dan Romascanu, Pekka Savola, and Muhammad Mukarram bin Tariq
   for their useful comments and suggestions.

Yegin                    Expires April 27, 2006                [Page 18]

Internet-Draft          L2 Notifications for DNA            October 2005

7.  References

7.1  Normative References

   [CDMA2K]   "IS-835 - cdma2000 Wireless IP Network Standard",  .

   [GPRS]     "Digital cellular telecommunications system (Phase 2+);
              General Packet Radio Service (GPRS) Service description;
              Stage 2", 3GPP 3GPP TS 03.60 version 7.9.0 Release 98.

              "Digital cellular telecommunications system (Phase 2+);
              Radio subsystem link control", 3GPP GSM 03.05 version
              7.0.0 Release 98.

              Choi, J., "Goals of Detecting Network Attachment in IPv6",
              draft-ietf-dna-goals-04 (work in progress), December 2004.

              Institute of Electrical and Electronics Engineers, "IEEE
              Std 802.11a-1999, supplement to IEEE Std 802.11-1999, Part
              11: Wireless MAN Medium Access Control (MAC) and Physical
              Layer (PHY) specifications: High-speed Physical Layer in
              the 5 GHZ band", IEEE Standard 802.11a, September 1999.

              Institute of Electrical and Electronics Engineers, "IEEE
              Std 802 Part 11, Information technology -
              Telecomunications and information exchange between systems
              - Local and metropolitan area networks - Specific
              requirements - Part 11: Wireless Lan Medium Access Control
              (MAC) And Physical Layer (PHY) Specifications",
              IEEE Standard 802.11b, August 1999.

              Institute of Electrical and Electronics Engineers, "IEEE
              Std 802.11g-2003, Amendment to IEEE Std 802.11, 1999
              edition, Part 11: Wireless MAN Medium Access Control (MAC)
              and Physical Layer (PHY) specifications. Amendment 4:
              Further Higher Data Rate Extension in the 2.4 GHz Band",
              IEEE Standard 802.11g, June 2003.

              Institute of Electrical and Electronics Engineers,
              "Supplement to STANDARD FOR Telecommunications and
              Information Exchange between Systems - LAN/MAN Specific
              Requirements - Part 11: Wireless Medium Access Control

Yegin                    Expires April 27, 2006                [Page 19]

Internet-Draft          L2 Notifications for DNA            October 2005

              (MAC) and physical layer (PHY) specifications:
              Specification for Enhanced Security", IEEE IEEE 802.11i,
              December 2004.

              Institute of Electrical and Electronics Engineers, "IEEE
              standard for local and metropolitan area networks - common
              specific ations - Media access control (MAC) Bridges",
              ISO/IEC IEEE Std 802.1D, 2004.

              Institute of Electrical and Electronics Engineers, "Draft
              Standard for Local and Metropolitan Networks: Station and
              Media Access Control Connectivity Discovery (Draft 13)",
              IEEE draft Std 802.1AB, 2004.

              Institute of Electrical and Electronics Engineers, "IEEE
              standard for local and metropolitan area networks -
              Specific Require ments, Part 3: Carrier Sense Multiple
              Access with Collision Detection  (CSMA/CD) Access Method
              and Physical Layer Specifications", ISO/IEC IEEE
              Std 802.3, 2002.

   [RFC1332]  McGregor, G., "The PPP Internet Protocol Control Protocol
              (IPCP)", RFC 1332, May 1992.

   [RFC1661]  Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51,
              RFC 1661, July 1994.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2462]  Thomson, S. and T. Narten, "IPv6 Stateless Address
              Autoconfiguration", RFC 2462, December 1998.

   [RFC2472]  Haskin, D. and E. Allen, "IP Version 6 over PPP",
              RFC 2472, December 1998.

   [RFC3315]  Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
              and M. Carney, "Dynamic Host Configuration Protocol for
              IPv6 (DHCPv6)", RFC 3315, July 2003.

7.2  Informative References

   [GPRS-CN]  "Technical Specification Group Core Network;
              Internetworking between the Public Land Mobile Network
              (PLMN) supporting packet based services and Packet Data

Yegin                    Expires April 27, 2006                [Page 20]

Internet-Draft          L2 Notifications for DNA            October 2005

              Networks (PDN) (Release 6)", 3GPP 3GPP TS 29.061 version
              6.1.0 2004-06.

              "Technical Specification Group Services and System Aspect;
              General Packet Radio Service (GPRS) Service description;
              Stage 2 (Release 6)", 3GPP 3GPP TS 23.060 version 6.5.0

              Koodli, R., "Fast Handovers for Mobile IPv6",
              draft-ietf-mipshop-fast-mipv6-03 (work in progress),
              October 2004.

              Malki, K., "Low Latency Handoffs in Mobile IPv4",
              draft-ietf-mobileip-lowlatency-handoffs-v4-11 (work in
              progress), October 2005.

   [RFC2461]  Narten, T., Nordmark, E., and W. Simpson, "Neighbor
              Discovery for IP Version 6 (IPv6)", RFC 2461,
              December 1998.

Author's Address

   Alper E. Yegin (editor)
   Samsung Advanced Institute of Technology
   75 West Plumeria Drive
   San Jose, CA  95134

   Phone: +1 408 544 5656

Yegin                    Expires April 27, 2006                [Page 21]

Internet-Draft          L2 Notifications for DNA            October 2005

Appendix A.  Change History

   The following changes were made on draft version 00:

   - IEEE 802.11 ad-hoc mode discussion added.

   - IPv6 address configuration over 3GPP networks clarified.

   The following changes were made on draft version 01:

   - Text for IEEE 802.3 added.

   - Multiple 3GPP PDP Contexts scenario clarified.

   The following change was made on draft version 02:

   - Editorial fixes as suggested by WG last call feedback.

Yegin                    Expires April 27, 2006                [Page 22]

Internet-Draft          L2 Notifications for DNA            October 2005

Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at

Disclaimer of Validity

   This document and the information contained herein are provided on an

Copyright Statement

   Copyright (C) The Internet Society (2005).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.


   Funding for the RFC Editor function is currently provided by the
   Internet Society.

Yegin                    Expires April 27, 2006                [Page 23]