draft-ietf-dna-link-information-04.txt   draft-ietf-dna-link-information-05.txt 
Network Working Group S. Krishnan, Ed. Network Working Group S. Krishnan, Ed.
Internet-Draft Ericsson Research Internet-Draft Ericsson Research
Expires: April 9, 2007 N. Montavont Expires: May 9, 2007 N. Montavont
LSIIT - University Louis Pasteur LSIIT - University Louis Pasteur
E. Njedjou E. Njedjou
France Telecom France Telecom
S. Veerepalli S. Veerepalli
Qualcomm Qualcomm
A. Yegin, Ed. A. Yegin, Ed.
Samsung AIT Samsung AIT
October 6, 2006 November 5, 2006
Link-layer Event Notifications for Detecting Network Attachments Link-layer Event Notifications for Detecting Network Attachments
draft-ietf-dna-link-information-04 draft-ietf-dna-link-information-05
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 41 skipping to change at page 1, line 41
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 9, 2007. This Internet-Draft will expire on May 9, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The Internet Society (2006).
Abstract Abstract
Certain network access technologies are capable of providing various Certain network access technologies are capable of providing various
link-layer status information to IP. Link-layer event notifications types of link-layer status information to IP. Link-layer event
can help IP expeditiously detect configuration changes. This notifications can help IP expeditiously detect configuration changes.
document provides a non-exhaustive catalogue of information available This document provides a non-exhaustive catalogue of information
from well-known access technologies. available from well-known access technologies.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements notation . . . . . . . . . . . . . . . . . . 4 1.1 Requirements notation . . . . . . . . . . . . . . . . . . 4
2. Link-Layer Event Notifications . . . . . . . . . . . . . . . . 5 2. Link-Layer Event Notifications . . . . . . . . . . . . . . . . 5
2.1. GPRS/3GPP . . . . . . . . . . . . . . . . . . . . . . . . 6 2.1 GPRS/3GPP . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2. cdma2000/3GPP2 . . . . . . . . . . . . . . . . . . . . . . 8 2.2 cdma2000/3GPP2 . . . . . . . . . . . . . . . . . . . . . . 7
2.3. IEEE 802.11/WiFi . . . . . . . . . . . . . . . . . . . . . 8 2.3 IEEE 802.11/WiFi . . . . . . . . . . . . . . . . . . . . . 8
2.4. IEEE 802.3 CSMA/CD . . . . . . . . . . . . . . . . . . . . 10 2.4 IEEE 802.3 CSMA/CD . . . . . . . . . . . . . . . . . . . . 9
2.4.1. Link Integrity Tests in 802.3 Networks . . . . . . . . 10 2.4.1 Link Integrity Tests in 802.3 Networks . . . . . . . . 10
2.4.2. IEEE 802.1D Bridging and Its Effects on Link-layer 2.4.2 IEEE 802.1D Bridging and Its Effects on Link-layer
Event Notifications . . . . . . . . . . . . . . . . . 11 Event Notifications . . . . . . . . . . . . . . . . . 10
2.4.3. 802.1AB Link-Layer Discovery Protocol . . . . . . . . 13 2.4.3 802.1AB Link-Layer Discovery Protocol . . . . . . . . 12
2.4.4. Summary . . . . . . . . . . . . . . . . . . . . . . . 13 2.4.4 Summary . . . . . . . . . . . . . . . . . . . . . . . 13
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
4. Security Considerations . . . . . . . . . . . . . . . . . . . 15 4. Security Considerations . . . . . . . . . . . . . . . . . . . 15
5. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 16 5. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 16
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
7.1. Normative References . . . . . . . . . . . . . . . . . . . 18 7.1 Normative References . . . . . . . . . . . . . . . . . . . 18
7.2. Informative References . . . . . . . . . . . . . . . . . . 19 7.2 Informative References . . . . . . . . . . . . . . . . . . 19
Appendix A. Change History . . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 A. Change History . . . . . . . . . . . . . . . . . . . . . . . . 22
Intellectual Property and Copyright Statements . . . . . . . . . . 24 Intellectual Property and Copyright Statements . . . . . . . . 23
1. Introduction 1. Introduction
It is not an uncommon occurrence for a node to change its point-of 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 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., a mobile phone moving among base stations) or nomadic usage
(e.g., road-warrior case). (e.g., road-warrior case).
A node changing its point-of attachment to the network may end up A node changing its point-of attachment to the network may end up
changing its IP subnet and therefore require re-configuration of IP- changing its IP subnet and therefore require re-configuration of IP-
layer parameters, such as IP address, default gateway information, layer parameters, such as IP address, default gateway information,
and DNS server address. Detecting the subnet change can usually use and DNS server address. Detecting the subnet change can usually use
network-layer indications such as a change in the advertised prefixes network-layer indications (such as a change in the advertised
(i.e., appearance and disappearance of prefixes). But generally prefixes for IPv6). But generally reliance on such indications does
reliance on such indications does not yield rapid detection, since not yield rapid detection, since these indications are not readily
these indications are not readily available upon node changing its available upon node changing its point of attachment.
point of attachment.
The changes to the underlying link-layer status can be relayed to IP Additional information can be conveyed along with the event, such as
in the form of link-layer event notifications. Establishment and the identifier of the network attachment point (e.g., IEEE 802.11
tear down of a link-layer connection are two basic events types. BSSID and SSID), or network-layer configuration parameters obtained
Additional information can be conveyed in addition to the event type, via the link-layer attachment process if available. It is envisaged
such as the identifier of the network attachment point (e.g., IEEE that such event notifications can in certain circumstances be used to
802.11 BSSID and SSID), or network-layer configuration parameters expedite the inter-subnet movement detection and reconfiguration
obtained via the link-layer attachment process if available. It is process. For example, the notification indicating that the node has
envisaged that such event notifications can in certain circumstances established a new link-layer connection MAY be used for immediately
be used to expedite the inter-subnet movement detection and probing the network for a possible configuration change. In the
reconfiguration process. For example, the notification indicating absence of such a notification from the link-layer, IP has to wait
that the node has established a new link-layer connection MAY be used for indications that are not immediately available, such as receipt
for immediately probing the network for a possible configuration of next scheduled router advertisement, unreachability of the default
change. In the absence of such a notification from the link-layer, gateway, etc.
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 It should be noted that a link-layer event notification does not
always translate into a subnet change. Even if the node has torn always translate into a subnet change. Even if the node has torn
down a link-layer connection with one attachment point and down a link-layer connection with one attachment point and
established a new connection with another, it may still be attached established a new connection with another, it may still be attached
to the same IP subnet. For example, several IEEE 802.11 access to the same IP subnet. For example, several IEEE 802.11 access
points can be attached to the same IP subnet. Moving among these points can be attached to the same IP subnet. Moving among these
access points does not warrant any IP-layer configuration change. access points does not warrant any IP-layer configuration change.
In order to enable an enhanced scheme for detecting change of subnet, In order to enable an enhanced scheme for detecting change of subnet,
skipping to change at page 4, line 24 skipping to change at page 4, line 21
[I-D.ietf-mipshop-fast-mipv6]. Separate documents that are backward- [I-D.ietf-mipshop-fast-mipv6]. Separate documents that are backward-
compatible with this one can be generated to discuss further compatible with this one can be generated to discuss further
enhancements. enhancements.
These event notifications are considered with hosts in mind, although These event notifications are considered with hosts in mind, although
they may also be available on the network side (e.g., on the access 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 points and routers). An API or protocol-based standard interface may
be defined between the link-layer and IP for conveying this be defined between the link-layer and IP for conveying this
information. That activity is beyond the scope of this document. information. That activity is beyond the scope of this document.
1.1. Requirements notation 1.1 Requirements notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
2. Link-Layer Event Notifications 2. Link-Layer Event Notifications
Link-layer event notifications are considered to be one of the inputs 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 to the DNA process. A DNA process is likely to take other inputs
(e.g., presence of advertised prefixes, reachability of default (e.g., presence of advertised prefixes, reachability of default
gateways) before determining whether IP-layer configuration must be gateways) before determining whether IP-layer configuration must be
updated. It is expected that the DNA process can take advantage of updated. It is expected that the DNA process can take advantage of
link-layer notifications when they are made available to IP. While link-layer notifications when they are made available to IP. While
by itself a link-layer notification may not constitute all the input 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 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 collect further information (i.e., other inputs to the process). For
example, the node may send a router solicitation as soon as it learns example, the node may send a router solicitation as soon as it learns
that a new link-layer connection is established. that a new link-layer connection is established.
The link-layer event that is considered most useful to DNA process is The link-layer event that is considered most useful to DNA process is
the link up event. The link up event is deterministic, and the link the link up event. The associated notifications can be provided to
up notification is provided to IP-layer after the event successfully the IP-layer after the event concludes successfully. The link up
concludes. The link up events and notifications are associated with events and notifications are associated with a network interface on
a network interface on the node. The IP module may receive the node. The IP module may receive simultaneous independent
simultaneous independent notifications from each one of the network notifications from each one of the network interfaces on the node.
interfaces on the node.
"Link" is a communication facility or medium over which network nodes "Link" is a communication facility or medium over which network nodes
can communicate. Each link is associated with a minimum of two can communicate. Each link is associated with a minimum of two
endpoints. An "attachment point" is the link endpoint on the link to endpoints. An "attachment point" is the link endpoint on the link to
which the node is currently connected, such as an access point, a which the node is currently connected, such as an access point, a
base station, or a wired switch. base station, or a wired switch.
"Link up" is an event provided by the link-layer that signifies a "Link up" is an event provided by the link-layer that signifies a
state change associated with the interface becoming capable of state change associated with the interface becoming capable of
communicating data packets. This event is associated with a link- communicating data packets. This event is associated with a link-
skipping to change at page 6, line 12 skipping to change at page 6, line 11
the event. Alternatively, the link-layer implementation MAY choose the event. Alternatively, the link-layer implementation MAY choose
to delay the link up notification until the risk conditions cease to to delay the link up notification until the risk conditions cease to
exist. exist.
If a link up with the R-flag set was generated, another link up MUST 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 follow up as soon as the link-layer is capable of generating a
deterministic notification. The event attributes MUST indicate deterministic notification. The event attributes MUST indicate
whether the packets transmitted since the previous notification were whether the packets transmitted since the previous notification were
presumed to be blocked (B-flag) or allowed (A-flag) by the network if 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- the link-layer could determine the exact conditions. If the link-
layer cannot make a determination about the faith of these packets, layer cannot make a determination about the fate of these packets, it
it MUST generate a link up without any additional indications (no MUST generate a link up without any additional indications (no flags
flags set). set).
A node may have to change its IP-layer configuration even when the A node may have to change its IP-layer configuration even when the
link-layer connection stays the same. An example scenario is the link-layer connection stays the same. An example scenario is the
IPv6 subnet renumbering [RFC2461]. Therefore, there exist cases IPv6 subnet renumbering [RFC2461]. Therefore, there exist cases
where IP-layer configuration may have to change even without the IP- where IP-layer configuration may have to change even without the IP-
layer receiving a link up notification. Therefore, a link-layer layer receiving a link up notification. Therefore, a link-layer
notification is not a mandatory indication of a subnet change. notification is not a mandatory indication of a subnet change.
A link up notification may optionally deliver information relating to A link up notification may optionally deliver information relating to
the attachment point. Such auxiliary information may include the attachment point. Such auxiliary information may include
skipping to change at page 6, line 47 skipping to change at page 6, line 46
link establishment). link establishment).
The link-layer process leading to a link up event depends on the link The link-layer process leading to a link up event depends on the link
technology. While a link-layer notification MUST always indicate technology. While a link-layer notification MUST always indicate
that the link up event occurred, the availability and types of that the link up event occurred, the availability and types of
auxiliary information on the attachment point depends on the link- auxiliary information on the attachment point depends on the link-
layer technology as well. The following subsections examine four layer technology as well. The following subsections examine four
link-layer technologies and describe when a link-layer notification link-layer technologies and describe when a link-layer notification
must be generated and what information must be included in it. must be generated and what information must be included in it.
2.1. GPRS/3GPP 2.1 GPRS/3GPP
GPRS is an enhancement to the GSM data transmission architecture and GSM Packet Radio System (GPRS) provides packet switched data
capabilities, designed to allow for packet switching in user data transmission over a cellular network[GPRS][GPRS-LINK].
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-
LINK].
The GPRS architecture consists of a Radio Access Network and a packet The GPRS architecture consists of a Radio Access Network and a packet
domain Core Network. domain Core Network.
- The GPRS Radio Access Network is composed of Mobile Terminals (MT), - The GPRS Radio Access Network is composed of Mobile Terminals (MT),
a Base Station Subsystem and Serving GPRS Support Nodes (SGSN). a Base Station Subsystem and Serving GPRS Support Nodes (SGSN).
- An IP Core Network that acts as the transport backbone of user - An IP Core Network that acts as the transport backbone of user
datagrams between SGSNs and Gateway GPRS Support Nodes (GGSN). The datagrams between SGSNs and Gateway GPRS Support Nodes (GGSN). The
GGSN ensures the GPRS IP core network connectivity with external GGSN ensures the GPRS IP core network connectivity with external
networks, such as Internet or Local Area Networks. GGSN acts as the networks, such as Internet or Local Area Networks. GGSN acts as the
default IP gateway for the MT. default IP gateway for the MT.
A GPRS MT that wants to establish IP-level connections MUST first A GPRS MT that wants to establish IP connectivity establishes first a
perform a GPRS attach to the SGSN. This MUST be followed by a connection to the GPRS network and one or more PDP Context
request to the GPRS network to settle the necessary soft state associations between the MT and the GGSN. It is only after the PDP
mechanism (GPRS tunneling protocol) between its serving SGSN and the Context has been established, address autoconfiguration and tunneling
GGSN. The soft state maintained between the MT, the SGSN and the mechanism have taken place that the MT's IP packets can be forwarded
GGSN is called a PDP Context. It is used for guaranteeing a to and from its remote IP peers. The aim of PDP Context
negotiated quality of service for the IP flows exchanged between the establishment is also to provide IP-level configuration on top of the
GPRS MT and an external Packet Data Network such as Internet. It is GPRS link-layer attachment.
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 Successful establishment of a PDP Context on a GPRS link signifies
the availability of IP service to the MT. Therefore, this link-layer the availability of IP service to the MT. Therefore, this link-layer
event MUST generate a link up event notification sent to IP-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 An MT has the possibility to establish a secondary PDP Context while
re-using the IP configuration acquired from a previously established re-using the IP configuration acquired from a previously established
and active PDP Context. Establishment of a secondary PDP Context and active PDP Context. Such a secondary PDP Context does not
does not provide additional information to IP-layer. Such a second provide additional information to IP-layer and only allows another
PDP Context would basically have a different QoS profile so that a QoS profile to be used. The activiation of a such secondary PDP
different type of application can be served. In that case, Context MUST NOT generate another link up event notification.
activation of the secondary PDP Context MUST NOT generate another However, other additional PDP Context activiations are to be treated
link up event notification. However, a secondary PDP Context as indicated earlier.
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 With IPv4, the auxiliary information carried along with this
notification MUST be the IPv4 address of the MT which is obtained as notification MUST be the IPv4 address of the MT which is obtained as
part of the PDP Context. With IPv6, the PDP Context activation part of the PDP Context. With IPv6, the PDP Context activation
response does not come along with a usable IPv6 address. response does not come along with a usable IPv6 address.
Effectively, the IPv6 address received from the GGSN in the PDP Effectively, the IPv6 address received from the GGSN in the PDP
address field of the message does not contain a valid prefix. The MN address field of the message does not contain a valid prefix. The MN
actually only uses the interface-identifier extracted from that field actually only uses the interface-identifier extracted from that field
to form a link-local address, that it uses afterwards to obtain a to form a link-local address, that it uses afterwards to obtain a
valid prefix (e.g., by stateless [RFC2462][GPRS-CN] or stateful valid prefix (e.g., by stateless [RFC2462][GPRS-CN] or stateful
[RFC3315] [GPRS-GSSA] address configuration). Therefore no IPv6- [RFC3315] [GPRS-GSSA] address configuration). Therefore no IPv6-
related auxiliary information is provided to IP-layer. related auxiliary information is provided to IP-layer.
2.2. cdma2000/3GPP2 2.2 cdma2000/3GPP2
cdma2000-based 3GPP2 packet data services provide mobile users wide cdma2000-based 3GPP2 packet data services provide mobile users wide
area high-speed access to packet switched networks [CDMA2K]. Some of area high-speed access to packet switched networks [CDMA2K]. Some of
the major components of the 3GPP2 packet network architecture consist the major components of the 3GPP2 packet network architecture consist
of: of:
- Mobile Station (MS), which allows mobile access to packet-switched - Mobile Station (MS), which allows mobile access to packet-switched
networks over a wireless connection. networks over a wireless connection.
- Radio Access Network, which consists of the Base Station - Radio Access Network, which consists of the Base Station
skipping to change at page 8, line 48 skipping to change at page 8, line 33
Service, IPCP enables configuration of IPv4 address on the MS. This Service, IPCP enables configuration of IPv4 address on the MS. This
IPv4 address MUST be provided as the auxiliary information along with IPv4 address MUST be provided as the auxiliary information along with
the link up notification. IPV6CP used for Simple IPv6 service does the link up notification. IPV6CP used for Simple IPv6 service does
not provide an IPv6 address, but the interface-identifiers for local not provide an IPv6 address, but the interface-identifiers for local
and remote end-points of the PPP link. Since there is no standards- and remote end-points of the PPP link. Since there is no standards-
mandated correlation between the interface-identifier and other IP- mandated correlation between the interface-identifier and other IP-
layer configuration parameters, this information is deemed not useful layer configuration parameters, this information is deemed not useful
for DNA (nevertheless it MAY be provided as auxiliary information for for DNA (nevertheless it MAY be provided as auxiliary information for
other uses). other uses).
2.3. IEEE 802.11/WiFi 2.3 IEEE 802.11/WiFi
IEEE 802.11-based WiFi networks are the wireless extension of the IEEE 802.11-based WiFi networks are the wireless extension of the
Local Area Networks. Currently available standards are IEEE 802.11b Local Area Networks. Currently available standards are IEEE 802.11b
[IEEE-802.11b], IEEE 802.11g [IEEE-802.11g], and IEEE 802.11a [IEEE- [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 802.11a]. The specifications define both the MAC-layer and the
physical-layer. The MAC layer is the same for all these physical-layer. The MAC layer is the same for all these
technologies. technologies.
Two operating modes are available in the IEEE 802.11 series, either Two operating modes are available in the IEEE 802.11 series, either
infrastructure mode or ad-hoc mode. In infrastructure mode, all infrastructure mode or ad-hoc mode. In infrastructure mode, all
link-layer frames are transmitted to an access point (AP) which then link-layer frames are transmitted to an access point (AP) which then
forwards them to the final receiver. A station (STA) MUST establish forwards them to the final receiver. A station (STA) establishes a
a IEEE 802.11 link with an AP in order to send and receive IP IEEE 802.11 association with an AP in order to send and receive IP
packets. In a WiFi network that supports Robust Secure Network (RSN packets. In a WiFi network that uses Robust Secure Network (RSN
[IEEE-802.11i]), successful completion of 4-way handshake between the [IEEE-802.11i]), successful completion of the 4-way handshake between
STA and AP commences the availability of IP service. The link up the STA and AP commences the availability of IP service. The link up
event notification MUST be generated upon this event. In non-RSN- event notification MUST be generated upon this event. In non-RSN-
based networks, successful association or re-association events on based networks, successful association or re-association events on
the link-layer MUST cause a link up notification sent to the IP- the link-layer MUST cause a link up notification sent to the IP-
layer. layer.
As part of the link establishment, Basic Service Set Identification As part of the link establishment, Basic Service Set Identification
(BSSID) and Service Set Identifier (SSID) associated with the AP is (BSSID) and Service Set Identifier (SSID) associated with the AP is
learned by the STA. BSSID is a unique identifier of the AP, usually 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 set to the MAC address of the wireless interface of the AP. SSID
carries the identifier of the Extended Service Set (ESS) - the set carries the identifier of the Extended Service Set (ESS) - the set
composed of APs and associated STAs that share a common distribution composed of APs and associated STAs that share a common distribution
system. BSSID and SSID MUST be provided as auxiliary information system. BSSID and SSID MAY be provided as auxiliary information
along with the link up notification. Unfortunately this information along with the link up notification. Unfortunately this information
does not provide a deterministic indication of whether the IP-layer does not provide a deterministic indication of whether the IP-layer
configuration MUST be changed upon movement. There is no standards- configuration MUST be changed upon movement. There is no standards-
mandated one-to-one relation between the BSSID/SSID pairs and IP 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 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. Similarly, an ESS with the given SSID may span
multiple IP subnets. And finally, the SSIDs are not globally unique. multiple IP subnets. And finally, the SSIDs are not globally unique.
The same SSID may be used by multiple independent ESSs. See Appendix The same SSID may be used by multiple independent ESSs. See Appendix
A of [DNA4] for a detailed discussion. Nevertheless, BSSID/SSID A of [DNA4] for a detailed discussion. Nevertheless, BSSID/SSID
information may be used in a probabilistic way by the DNA process, information may be used in a probabilistic way by the DNA process,
skipping to change at page 10, line 7 skipping to change at page 9, line 40
delivery. STAs do not associate with each other, and therefore may delivery. STAs do not associate with each other, and therefore may
exchange data frames in state 2 (authenticated and not associated) or exchange data frames in state 2 (authenticated and not associated) or
even in state 1 (unauthenticated and unassociated) if the even in state 1 (unauthenticated and unassociated) if the
Distribution System is not used (i.e., "To DS" and "From DS" bits are 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 clear). If authentication is performed, a link up indication can be
generated upon authentication. Concerning the link layer generated upon authentication. Concerning the link layer
identification, both the BSSID (which is a random MAC address chosen 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 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. not to make any assumptions on the IP network configuration.
2.4. IEEE 802.3 CSMA/CD 2.4 IEEE 802.3 CSMA/CD
IEEE 802.3 CSMA/CD (commonly referred to as Ethernet) is the most IEEE 802.3 CSMA/CD (commonly referred to as Ethernet) is the most
commonly deployed Local Area Network technology in use today. As commonly deployed Local Area Network technology in use today. As
deployed today, it is specified by a physical layer/medium access deployed today, it is specified by a physical layer/medium access
control (MAC) layer specification [IEEE-802.3]. In order to provide control (MAC) layer specification [IEEE-802.3]. In order to provide
connection of different LANs together into a larger network, 802.3 connection of different LANs together into a larger network, 802.3
LANs are often bridged together [IEEE-802.1D]. LANs are often bridged together [IEEE-802.1D].
In this section, the terms 802.3 and Ethernet are used In this section, the terms 802.3 and Ethernet are used
interchangeably. This section describes some issues in providing interchangeably. This section describes some issues in providing
skipping to change at page 10, line 36 skipping to change at page 10, line 21
In order to determine whether the physical medium is ready for frame In order to determine whether the physical medium is ready for frame
transfer, IEEE 802.3 Ethernet specifies its own link monitoring transfer, IEEE 802.3 Ethernet specifies its own link monitoring
mechanism, which is defined for some, but not all classes of media. mechanism, which is defined for some, but not all classes of media.
Where available, this Link Integrity Test operation is used to Where available, this Link Integrity Test operation is used to
identify when packets are able to be received on an Ethernet segment. identify when packets are able to be received on an Ethernet segment.
It is applicable to both wired and optical physical layers, although It is applicable to both wired and optical physical layers, although
details vary between technologies (link pulses in twisted pair details vary between technologies (link pulses in twisted pair
copper, light levels in fibre). copper, light levels in fibre).
2.4.1. Link Integrity Tests in 802.3 Networks 2.4.1 Link Integrity Tests in 802.3 Networks
Link Integrity Tests in 802.3 networks typically occur at initial Link Integrity Tests in 802.3 networks typically occur at initial
physical connection time (for example, at the auto-negotiation physical connection time (for example, at the auto-negotiation
stage), and periodically afterwards. It makes use of physical-layer stage), and periodically afterwards. It makes use of physical-layer
specific operations to determine if a medium is able to support link- specific operations to determine if a medium is able to support link-
layer frames [IEEE-802.3]. layer frames [IEEE-802.3].
The status of the link as determined by the Link Integrity Test is The status of the link as determined by the Link Integrity Test is
stored in the variable 'link_status'. Changes to the value of stored in the variable 'link_status'. Changes to the value of
link_status (for example due to Link Integrity Test failure) will link_status (for example due to Link Integrity Test failure) will
skipping to change at page 11, line 15 skipping to change at page 10, line 48
autonegotiation has not completed. OK state indicates that the autonegotiation has not completed. OK state indicates that the
medium is able to send and receive packets. medium is able to send and receive packets.
Upon transition to a particular state the Physical Medium Attachment Upon transition to a particular state the Physical Medium Attachment
subsystems generates a PMA_LINK.indicate(link_status). Indications subsystems generates a PMA_LINK.indicate(link_status). Indications
of OK state MAY be used to generate a link up event notification. of OK state MAY be used to generate a link up event notification.
This indication do not definitively ensure that packets will be able This indication do not definitively ensure that packets will be able
to be received through the bridge domain, though [see the next to be received through the bridge domain, though [see the next
section]. Such operations are governed by bridging. section]. Such operations are governed by bridging.
2.4.2. IEEE 802.1D Bridging and Its Effects on Link-layer Event 2.4.2 IEEE 802.1D Bridging and Its Effects on Link-layer Event
Notifications Notifications
Ethernet networks commonly consist of LANs joined together by Ethernet networks commonly consist of LANs joined together by
transparent bridges (usually implemented as switches). Transparent transparent bridges (usually implemented as switches). Transparent
bridges require the active topology to be loop free. The Spanning bridges require the active topology to be loop free. This is
Tree Protocol (STP) achieves this by the exchange of Bridge Protocol achieved through the Spanning Tree Protocol (STP) or the Rapid
Data Unit (BPDU), as defined in [IEEE-802.1D], which leads to, where Spanning Tree Protocol (RSTP). These protocols exchange Bridge
required, the blocking of ports (i.e., not forwarding). Protocol Data Units (BPDUs), 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 By default, the spanning tree protocol does not know whether a
particular newly connected piece of Ethernet will cause a loop. particular newly connected piece of Ethernet will cause a loop.
Therefore it will block all traffic from and to newly connected ports Therefore it will block all traffic from and to newly connected ports
with the exception of some unbridged management frames. The STP will 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 determine if the port can be connected to the network in a loop-free
manner. manner.
For these technologies, even though the link-layer appears available, For these technologies, even though the link-layer appears available,
skipping to change at page 11, line 48 skipping to change at page 11, line 34
even if the host itself does not implement bridging or STP, packet even if the host itself does not implement bridging or STP, packet
delivery across the network can be affected by the presence of delivery across the network can be affected by the presence of
bridges. bridges.
Where the host is not running STP itself, no explicit indication that Where the host is not running STP itself, no explicit indication that
forwarding has begun is sent from a bridge. Therefore, a host may 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 not know when STP operations have completed, and when it is safe to
inform upper layers to transmit packets. inform upper layers to transmit packets.
Where it is not known that forwarding operations are available, a Where it is not known that forwarding operations are available, a
host needs to assume that STP is being performed, and may indicate host SHOULD assume that RSTP or STP is being performed. Hosts MAY
full connectivity only based on timeouts or reception of BPDUs. listen to STP/RSTP and 802.1AB messages to gain further information
about the timing of full connectivity on the link, for example, to
Most hosts today do not listen to BPDU frames. For these hosts, override an existing indication.
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
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
circumstances.
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 Notably, though, it is not easy for a host to distinguish between
MUST send a link up notification upon expiry of calculated delays to Disabled bridge ports and non-bridge ports with no active
indicate that general packet transfer is available across the LAN. transmitters on them, as Disabled ports will have no traffic on them,
and incur 100% sender loss.
If no bridge configuration messages are received within the If no bridge configuration messages are received within the
Bridge_Max_Age interval (default 20s), then it is likely that there 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 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 [IEEE-802.1D]), since at least two BPDU hello messages would have
been lost. Upon this timeout, a link up notification MUST be been lost. Upon this timeout, a link up notification MUST be
generated. generated, if one has not been already.
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
loss.
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 If a BPDU is received, and the adjacent bridge is running the
original Spanning Tree Protocol, then a host cannot successfully send original Spanning Tree Protocol, then a host cannot successfully send
packets until at least twice the ForwardDelay value in the received packets until at least twice the ForwardDelay value in the received
BPDU has elapsed. After this time, a link up notification MUST be BPDU has elapsed. After this time, a link up notification MUST be
generated. If the previous link up notification had the R-flag set, 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 then the B-flag) MUST be set in this notification. The B-flag
signifies that the packets sent within the prior interval were lost. signifies that the packets sent within the prior interval were lost.
If the bridge is identified as performing Rapid Spanning Tree If the bridge is identified as performing Rapid Spanning Tree
Protocol (RSTP), it instead waits Bridge_Max_Age after packet Protocol (RSTP), it instead waits Bridge_Max_Age after packet
reception (advertised in the BPDU's Max Age field), before reception (advertised in the BPDU's Max Age field), before
forwarding. For ports which are known to be point-to-point through forwarding. For ports which are known to be point-to-point through
autonegotiation, this delay is abbreviated to 3 seconds after autonegotiation, this delay is abbreviated to 3 seconds after
autonegotiation completes [IEEE-802.1D]. autonegotiation completes [IEEE-802.1D].
2.4.3. 802.1AB Link-Layer Discovery Protocol 2.4.3 802.1AB Link-Layer Discovery Protocol
The recently defined 802.1AB Link-Layer Discovery Protocol (LLDP) The recently defined 802.1AB Link-Layer Discovery Protocol (LLDP)
provides information to devices which are directly adjacent to them provides information to devices which are directly adjacent to them
on the local LAN [IEEE-802.1ab]. on the local LAN [IEEE-802.1ab].
LLDP sends information periodically, and at link status change time LLDP sends information periodically, and at link status change time
to indicate the configuration parameters of the device. Devices may to indicate the configuration parameters of the device. Devices may
either send or receive these messages, or both. either send or receive these messages, or both.
The LLDP message may contain a System Capabilities TLV, which The LLDP message may contain a System Capabilities TLV, which
skipping to change at page 13, line 41 skipping to change at page 13, line 5
bridge not to run STP, and immediately allow forwarding. bridge not to run STP, and immediately allow forwarding.
Proprietary extensions may also indicate that data forwarding is Proprietary extensions may also indicate that data forwarding is
already available on such a port. Discussion of such optimizations already available on such a port. Discussion of such optimizations
is out-of-scope for this document. is out-of-scope for this document.
Due to the protocol's newness and lack of deployment, it is unclear Due to the protocol's newness and lack of deployment, it is unclear
how this protocol will eventually affect DNA in IPv4 or IPv6 how this protocol will eventually affect DNA in IPv4 or IPv6
networks. networks.
2.4.4. Summary 2.4.4 Summary
Link-Layer indications in Ethernet-like networks are complicated by Link-Layer indications in Ethernet-like networks are complicated by
additional unadvertised delays due to Spanning Tree calculations. additional unadvertised delays due to Spanning Tree calculations.
This may cause re-indication (link up with A-flag) or retraction This may cause re-indication (link up with A-flag) or retraction
(link up with B-flag) of indications previously sent to upper layer (link up with B-flag) of indications previously sent to upper layer
protocols. protocols.
3. IANA Considerations 3. IANA Considerations
This document has no actions for IANA. This document has no actions for IANA.
4. Security Considerations 4. Security Considerations
A faked link-layer event notification can be used to launch a Attackers may spoof various indications at the link-layer, or
denial-of service attack on the node and the associated network. manipulate the physical medium directly in an effort to confuse the
Secure generation and delivery of these notifications MUST be host about the state of the link-layer. For instance, attackers may
ensured. This is a subject for link-layer and network stack designs spoof error messages or disturb the wireless medium to cause the host
and therefore it is outside the scope of this document. to move its connection elsewhere or to even disconnect. Attackers
may also spoof information to make the host believe it has a
connection when, in reality, it does not.
These attacks may cause use of non-preferred networks or even denial-
of-service.
This specification does not provide any protection of its own for the
the indications from the lower layers. But the vulnerabilities can
be mitigated through the use of techniques in other parts of the
protocol stack. In particular, it is RECOMMENDED that
authentication, replay and integrity protection of link-layer
management messages is enabled when available. Additionally, the
protocol stack may also use some network layer mechanisms to achieve
partial protection. For instance, SEND [RFC 3971] could be used to
confirm secure reachability with a router. However, network layer
mechanisms are unable to deal with all problems, such as with
insecure lower layer notifications that lead to the link not
functioning properly
5. Contributors 5. Contributors
In addition to the people listed in the author list, text for the In addition to the people listed in the author list, text for the
specific link-layer technologies covered by this document was specific link-layer technologies covered by this document was
contributed by Thomas Noel (IEEE 802.11b), and Greg Daley (IEEE contributed by Thomas Noel (IEEE 802.11b), and Greg Daley (IEEE
802.3). The authors would like to thank them for their efforts in 802.3). The authors would like to thank them for their efforts in
bringing this document to fruition. bringing this document to fruition.
6. Acknowledgements 6. Acknowledgements
The authors would like to acknowledge Bernard Aboba, Sanjeev Athalye, The authors would like to acknowledge Bernard Aboba, Sanjeev Athalye,
JinHyeock Choi, John Loughney, Pekka Nikander, Brett Pentland, Tom JinHyeock Choi, John Loughney, Pekka Nikander, Brett Pentland, Tom
Petch, Dan Romascanu, Pekka Savola, and Muhammad Mukarram bin Tariq Petch, Dan Romascanu, Pekka Savola, and Muhammad Mukarram bin Tariq
for their useful comments and suggestions. for their useful comments and suggestions.
7. References 7. References
7.1. Normative References 7.1 Normative References
[CDMA2K] "IS-835 - cdma2000 Wireless IP Network Standard", . [CDMA2K] "IS-835 - cdma2000 Wireless IP Network Standard", .
[GPRS] "Digital cellular telecommunications system (Phase 2+); [GPRS] "Digital cellular telecommunications system (Phase 2+);
General Packet Radio Service (GPRS) Service description; General Packet Radio Service (GPRS) Service description;
Stage 2", 3GPP 3GPP TS 03.60 version 7.9.0 Release 98. Stage 2", 3GPP 3GPP TS 03.60 version 7.9.0 Release 98.
[GPRS-LINK] [GPRS-LINK]
"Digital cellular telecommunications system (Phase 2+); "Digital cellular telecommunications system (Phase 2+);
Radio subsystem link control", 3GPP GSM 03.05 version Radio subsystem link control", 3GPP GSM 03.05 version
skipping to change at page 19, line 47 skipping to change at page 19, line 47
[RFC2472] Haskin, D. and E. Allen, "IP Version 6 over PPP", [RFC2472] Haskin, D. and E. Allen, "IP Version 6 over PPP",
RFC 2472, December 1998. RFC 2472, December 1998.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
and M. Carney, "Dynamic Host Configuration Protocol for and M. Carney, "Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", RFC 3315, July 2003. IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC4135] Choi, JH. and G. Daley, "Goals of Detecting Network [RFC4135] Choi, JH. and G. Daley, "Goals of Detecting Network
Attachment in IPv6", RFC 4135, August 2005. Attachment in IPv6", RFC 4135, August 2005.
7.2. Informative References 7.2 Informative References
[GPRS-CN] "Technical Specification Group Core Network; [GPRS-CN] "Technical Specification Group Core Network;
Internetworking between the Public Land Mobile Network Internetworking between the Public Land Mobile Network
(PLMN) supporting packet based services and Packet Data (PLMN) supporting packet based services and Packet Data
Networks (PDN) (Release 6)", 3GPP 3GPP TS 29.061 version Networks (PDN) (Release 6)", 3GPP 3GPP TS 29.061 version
6.1.0 2004-06. 6.1.0 2004-06.
[GPRS-GSSA] [GPRS-GSSA]
"Technical Specification Group Services and System Aspect; "Technical Specification Group Services and System Aspect;
General Packet Radio Service (GPRS) Service description; General Packet Radio Service (GPRS) Service description;
skipping to change at page 21, line 5 skipping to change at page 20, line 26
[I-D.ietf-mobileip-lowlatency-handoffs-v4] [I-D.ietf-mobileip-lowlatency-handoffs-v4]
Malki, K., "Low Latency Handoffs in Mobile IPv4", Malki, K., "Low Latency Handoffs in Mobile IPv4",
draft-ietf-mobileip-lowlatency-handoffs-v4-11 (work in draft-ietf-mobileip-lowlatency-handoffs-v4-11 (work in
progress), October 2005. progress), October 2005.
[RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor [RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor
Discovery for IP Version 6 (IPv6)", RFC 2461, Discovery for IP Version 6 (IPv6)", RFC 2461,
December 1998. December 1998.
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.
The following change was made on draft version 03:
Link down events were removed since they are not relevant to DNA
References updated
Authors' Addresses Authors' Addresses
Suresh Krishnan (editor) Suresh Krishnan (editor)
Ericsson Research Ericsson Research
8400 Decarie Blvd. 8400 Decarie Blvd.
Town of Mount Royal, QC Town of Mount Royal, QC
Canada Canada
Email: suresh.krishnan@ericsson.com Email: suresh.krishnan@ericsson.com
skipping to change at page 23, line 4 skipping to change at page 21, line 21
Email: eric.njedjou@france-telecom.com Email: eric.njedjou@france-telecom.com
Siva Veerepalli Siva Veerepalli
Qualcomm Qualcomm
5775 Morehouse Drive 5775 Morehouse Drive
San Diego, CA 92131 San Diego, CA 92131
USA USA
Phone: +1 858 658 4628 Phone: +1 858 658 4628
Email: sivav@qualcomm.com Email: sivav@qualcomm.com
Alper E. Yegin (editor) Alper E. Yegin (editor)
Samsung Advanced Institute of Technology Samsung Advanced Institute of Technology
75 West Plumeria Drive 75 West Plumeria Drive
San Jose, CA 95134 San Jose, CA 95134
USA USA
Phone: +1 408 544 5656 Phone: +1 408 544 5656
Email: alper01.yegin@partner.samsung.com Email: alper01.yegin@partner.samsung.com
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.
The following change was made on draft version 03:
Link down events were removed since they are not relevant to DNA
References updated
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights 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 might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
 End of changes. 37 change blocks. 
165 lines changed or deleted 143 lines changed or added

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/