draft-ietf-dna-link-information-06.txt   rfc4957.txt 
Network Working Group S. Krishnan, Ed. Network Working Group S. Krishnan, Ed.
Internet-Draft Ericsson Research Request for Comments: 4957 Ericsson Research
Intended status: Informational N. Montavont Category: Informational N. Montavont
Expires: August 19, 2007 LSIIT - University Louis Pasteur GET ENST Bretagne
E. Njedjou E. Njedjou
France Telecom France Telecom
S. Veerepalli S. Veerepalli
Qualcomm Qualcomm
A. Yegin, Ed. A. Yegin, Ed.
Samsung AIT Samsung
February 15, 2007 August 2007
Link-layer Event Notifications for Detecting Network Attachments
draft-ietf-dna-link-information-06
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-
Drafts.
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 Link-Layer Event Notifications for Detecting Network Attachments
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at Status of This Memo
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 19, 2007. This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
Abstract Abstract
Certain network access technologies are capable of providing various Certain network access technologies are capable of providing various
types of link-layer status information to IP. Link-layer event types of link-layer status information to IP. Link-layer event
notifications can help IP expeditiously detect configuration changes. notifications can help IP expeditiously detect configuration changes.
This document provides a non-exhaustive catalogue of information This document provides a non-exhaustive catalogue of information
available from well-known access technologies. available from well-known access technologies.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Link-Layer Event Notifications . . . . . . . . . . . . . . . . 6 3. Link-Layer Event Notifications . . . . . . . . . . . . . . . . 5
3.1. GPRS/3GPP . . . . . . . . . . . . . . . . . . . . . . . . 7 3.1. GPRS/3GPP . . . . . . . . . . . . . . . . . . . . . . . . 6
3.2. cdma2000/3GPP2 . . . . . . . . . . . . . . . . . . . . . . 8 3.2. cdma2000/3GPP2 . . . . . . . . . . . . . . . . . . . . . . 7
3.3. IEEE 802.11/WiFi . . . . . . . . . . . . . . . . . . . . . 9 3.3. IEEE 802.11/WiFi . . . . . . . . . . . . . . . . . . . . . 8
3.4. IEEE 802.3 CSMA/CD . . . . . . . . . . . . . . . . . . . . 10 3.4. IEEE 802.3 CSMA/CD . . . . . . . . . . . . . . . . . . . . 9
3.4.1. Link Integrity Tests in 802.3 Networks . . . . . . . . 11 3.4.1. Link Integrity Tests in 802.3 Networks . . . . . . . . 10
3.4.2. IEEE 802.1D Bridging and Its Effects on Link-layer 3.4.2. IEEE 802.1D Bridging and Its Effects on Link-layer
Event Notifications . . . . . . . . . . . . . . . . . 11 Event Notifications . . . . . . . . . . . . . . . . . 11
3.4.3. 802.1AB Link-Layer Discovery Protocol . . . . . . . . 13 3.4.3. 802.1AB Link-Layer Discovery Protocol . . . . . . . . 12
3.4.4. Other heuristics . . . . . . . . . . . . . . . . . . . 13 3.4.4. Other Heuristics . . . . . . . . . . . . . . . . . . . 13
3.4.5. Summary . . . . . . . . . . . . . . . . . . . . . . . 13 3.4.5. Summary . . . . . . . . . . . . . . . . . . . . . . . 13
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 4. Security Considerations . . . . . . . . . . . . . . . . . . . 13
5. Security Considerations . . . . . . . . . . . . . . . . . . . 16 5. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 14
6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 17 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 7.1. Normative References . . . . . . . . . . . . . . . . . . . 14
8.1. Normative References . . . . . . . . . . . . . . . . . . . 19 7.2. Informative References . . . . . . . . . . . . . . . . . . 16
8.2. Informative References . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22
Intellectual Property and Copyright Statements . . . . . . . . . . 24
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 reconfiguration 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 network-layer indications (such as a change in the advertised
prefixes for IPv6). But such indications may not be always available prefixes for IPv6). But such indications may not be always available
(e.g. DNAv6) to the node upon changing its point of attachment. (e.g., Detecting Network Attachment in IPv6 (DNAv6)) to the node upon
changing its point of attachment.
Link-layer event notifications can help IP expeditiously detect
configuration changes. This document provides a non-exhaustive
catalog of information available from some access technologies, and
discusses the interpretation of this information at the IP layer.
This document is not intended to specify or change the behavior of
these access technologies in any manner.
Additional information can be conveyed along with the event, such as Additional information can be conveyed along with the event, such as
the identifier of the network attachment point (e.g., IEEE 802.11 the identifier of the network attachment point (e.g., IEEE 802.11
BSSID and SSID), or network-layer configuration parameters obtained Basic Service Set Identification (BSSID) and Service Set Identifier
via the link-layer attachment process if available. It is envisaged (SSID)), or network-layer configuration parameters obtained via the
that such event notifications can in certain circumstances be used to 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 expedite the inter-subnet movement detection and reconfiguration
process. For example, the notification indicating that the node has process. For example, the notification indicating that the node has
established a new link-layer connection may be used for immediately established a new link-layer connection may be used for immediately
probing the network for a possible configuration change. In the probing the network for a possible configuration change. In the
absence of such a notification from the link layer, IP has to wait absence of such a notification from the link layer, IP has to wait
for indications that are not immediately available, such as receipt for indications that are not immediately available, such as receipt
of next scheduled router advertisement, unreachability of the default of the next scheduled router advertisement, unreachability of the
gateway, etc. 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,
we need to define link-layer event notifications that can be we need to define link-layer event notifications that can be
realistically expected from various access technologies. The realistically expected from various access technologies. The
objective of this draft is to provide a catalogue of link-layer objective of this document is to provide a catalogue of link-layer
events and notifications in various architectures. While this events and notifications in various architectures. While this
document mentions the utility of this information for detecting document mentions the utility of this information for detecting
change of subnet (or, detecting network attachment - DNA), the change of subnet (or, detecting network attachment - DNA), the
detailed usage is left to other documents, namely DNA solution detailed usage is left to other documents, namely, DNA solution
specifications. specifications.
The document limits itself to the minimum set of information that is The document limits itself to the minimum set of information that is
necessary for solving the DNA problem [RFC4135]. A broader set of necessary for solving the DNA problem [RFC4135]. A broader set of
information (e.g., signal strength, packet loss, etc.) and events information (e.g., signal strength, packet loss, etc.) and events
(e.g. link down) may be used for other problem spaces, such as (e.g. link down) may be used for other problem spaces, such as
anticipation-based Mobile IP fast handovers anticipation-based Mobile IP fast handovers [RFC4881], [RFC4068],
[I-D.ietf-mobileip-lowlatency-handoffs-v4], etc.
[I-D.ietf-mipshop-fast-mipv6] etc.
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.
2. Terminology 2. Terminology
Link: is a communication facility or medium over which network nodes Link: is a communication facility or medium over which network nodes
skipping to change at page 5, line 22 skipping to change at page 4, line 45
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-
layer connection between the node and an attachment point. layer connection between the node and an attachment point.
BSSID: Basic Service Set Identification BSSID: Basic Service Set Identification
DNA: Detecting Network Attachment DNA: Detecting Network Attachment
GPRS: GSM Packet Radio System GPRS: General Packet Radio Service
PDP: Packet Data Protocol PDP: Packet Data Protocol
SSID: Service Set Identifier SSID: Service Set Identifier
3. Link-Layer Event Notifications 3. 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
skipping to change at page 6, line 28 skipping to change at page 5, line 28
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 associated notifications can be provided to the link up event. The associated notifications can be provided to
the IP-layer after the event concludes successfully. The link up the IP-layer after the event concludes successfully. The link up
events and notifications are associated with a network interface on events and notifications are associated with a network interface on
the node. The IP module may receive simultaneous independent the node. The IP module may receive simultaneous independent
notifications from each one of the network interfaces on the node. notifications from each one of the network interfaces on the node.
The actual event is managed by the link layer of the node through The actual event is managed by the link layer of the node through
execution of link-layer protocols and mechanisms. Once the event execution of link-layer protocols and mechanisms. Once the event
successfully completes within the link layer, its notification must successfully completes within the link layer, its notification is
be delivered to the IP-layer. By the time the notification is delivered to the IP-layer. By the time the notification is
delivered, the link layer of the node must be ready to accept IP delivered, the link layer of the node must be ready to accept IP
packets from the IP and the physical-layers. Each time an interface packets from the IP and the physical layers. Each time an interface
changes its point of attachment, a link up event should be generated. changes its point of attachment, a link up event should be generated.
There is a non-deterministic usage of the link up notification to There is a non-deterministic usage of the link up notification to
accomodate implementations that desire to indicate the link is up but accommodate implementations that desire to indicate the link is up,
the data transmission may be blocked in the network (see IEEE 802.3 but the data transmission may be blocked in the network (see IEEE
discussion). A link up notification may be generated with an 802.3 discussion). A link up notification may be generated with an
appropriate attribute, conveying its non-deterministic nature, to appropriate attribute, conveying its non-deterministic nature, to
convey the event. Alternatively, the link-layer implementation may convey the event. Alternatively, the link-layer implementation may
choose to delay the link up notification until the risk conditions choose to delay the link up notification until the risk conditions
cease to exist. cease to exist.
If a non-deterministic link up was generated, another link up must If a non-deterministic link up was generated, another link up must
follow as soon as the link layer is capable of generating a follow as soon as the link layer is capable of generating a
deterministic notification. The event attributes may indicate deterministic notification. The event attributes may indicate
whether the packets transmitted since the previous notification were whether the packets transmitted since the previous notification were
presumed to be blocked or allowed by the network, if the link layer presumed to be blocked or allowed by the network, if the link layer
could determine the exact conditions. could determine the exact conditions.
The deterministic link up event following a non-deterministic link up The deterministic link up event following a non-deterministic link up
event can be treated differently by consumers of the link up event. event can be treated differently by consumers of the link up event.
e.g. The second link up event need not trigger a confirmation For example, the second link up event need not trigger a confirmation
process, if the first one already did. process, if the first one already did.
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
skipping to change at page 7, line 28 skipping to change at page 6, line 32
merely knowing that a new link-layer connection is established may merely knowing that a new link-layer connection is established may
prompt the DNA process to immediately seek other clues for detecting prompt the DNA process to immediately seek other clues for detecting
a network configuration change, auxiliary information may constitute a network configuration change, auxiliary information may constitute
further clues (and even the final answers sometimes). In cases where further clues (and even the final answers sometimes). In cases where
there is a one-to-one mapping between the attachment point there is a one-to-one mapping between the attachment point
identifiers and the IP-layer configurations, learning the former can identifiers and the IP-layer configurations, learning the former can
reveal the latter. Furthermore, IP-layer configuration parameters reveal the latter. Furthermore, IP-layer configuration parameters
obtained during the link-layer connection may be exactly what the DNA obtained during the link-layer connection may be exactly what the DNA
process is trying to discover. process is trying to discover.
The link-layer process leading to a link up event depends on the link The link-layer process leading to a link up event depend 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. is generated and what information is included in it.
3.1. GPRS/3GPP 3.1. GPRS/3GPP
GSM Packet Radio System (GPRS) provides packet switched data GSM Packet Radio System (GPRS) provides packet-switched data
transmission over a cellular network[GPRS][GPRS-LINK]. transmission over a cellular network[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
a Base Station Subsystem and Serving GPRS Support Nodes (SGSN). (MTs), a Base Station Subsystem and Serving GPRS Support Nodes
(SGSNs).
- 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 (GGSNs).
GGSN ensures the GPRS IP core network connectivity with external The GGSN ensures the GPRS IP core network connectivity with
networks, such as the Internet or Local Area Networks. The GGSN acts external networks, such as the Internet or Local Area Networks.
as the default IP gateway for the MT. The GGSN acts as the default IP gateway for the MT.
A GPRS MT that wants to establish IP connectivity establishes first a A GPRS MT that wants to establish IP connectivity establishes first a
connection to the GPRS network and one or more PDP Context connection to the GPRS network and one or more PDP Context
associations between the MT and the GGSN. It is only after the PDP associations between the MT and the GGSN. It is only after the PDP
Context has been established, address autoconfiguration and tunneling Context has been established and after address autoconfiguration and
mechanism have taken place that the MT's IP packets can be forwarded tunneling mechanism have taken place that the MT's IP packets can be
to and from its remote IP peers. The aim of PDP Context 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 establishment is also to provide IP-level configuration on top of the
GPRS link-layer attachment. 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 the IP event generates a link up event notification sent to the IP layer.
layer.
An MT has the possibility to establish a secondary PDP Context while An MT may establish a secondary PDP Context while reusing the IP
re-using the IP configuration acquired from a previously established configuration acquired from a previously established and active PDP
and active PDP Context. Such a secondary PDP Context does not Context. Such a secondary PDP Context does not provide additional
provide additional information to the IP layer and only allows information to the IP layer and only allows another quality-of-
another QoS profile to be used. The activation of such a secondary service (QoS) profile to be used. The activation of such a secondary
PDP context does not usually generate a link up event since it does PDP context does not usually generate a link up event since it does
not require new IP parameters. However, other additional PDP Context not require new IP parameters. However, other additional PDP Context
activiations are to be treated as indicated earlier. activations are to be treated as indicated earlier.
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 is the IPv4 address of the MT that is obtained as part
part of the PDP Context. With IPv6, the PDP Context activation of the PDP Context. With IPv6, the PDP Context activation response
response does not come along with a usable IPv6 address. does not come along with a usable IPv6 address. Effectively, the
Effectively, the IPv6 address received from the GGSN in the PDP IPv6 address received from the GGSN in the PDP address field of the
address field of the message does not contain a valid prefix. The MN message does not contain a valid prefix. The MN actually only uses
actually only uses the interface-identifier extracted from that field the interface identifier extracted from that field to form a link-
to form a link-local address, that it uses afterwards to obtain a local address that it uses afterwards to obtain a valid prefix (e.g.,
valid prefix (e.g., by stateless [RFC2462][GPRS-CN] or stateful by stateless [RFC2462][GPRS-CN] or stateful [RFC3315] [GPRS-GSSA]
[RFC3315] [GPRS-GSSA] address configuration). Therefore no IPv6- address configuration). Therefore, no IPv6-related auxiliary
related auxiliary information is provided to the IP layer. information is provided to the IP layer.
3.2. cdma2000/3GPP2 3.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.
skipping to change at page 9, line 12 skipping to change at page 8, line 19
Transceivers, Base Station Controllers, and the Packet Control Transceivers, Base Station Controllers, and the Packet Control
Function. Function.
- Network Access Server known as the Packet Data Switching Node - Network Access Server known as the Packet Data Switching Node
(PDSN). The PDSN also serves as default IP gateway for the IP MS. (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 3GPP2 networks use the Point-to-Point Protocol (PPP [RFC1661]) as the
link-layer protocol between the MS and the PDSN. Before any IP link-layer protocol between the MS and the PDSN. Before any IP
packets may be sent or received, PPP must reach the Network-Layer packets may be sent or received, PPP must reach the Network-Layer
Protocol phase, and the IP Control Protocol (IPCP [RFC1332], IPV6CP Protocol phase, and the IP Control Protocol (IPCP [RFC1332], IPV6CP
[RFC2472]) reach the Opened state. When these states are reached in [RFC2472]) must reach the Opened state. When these states are
PPP, a link up event notification must be delivered to the IP layer. reached in PPP, a link up event notification is delivered to the IP
layer.
When the PPP is used for 3GPP2 Simple (i.e., non-Mobile) IPv4 When the PPP is used for 3GPP2 Simple (i.e., non-Mobile) IPv4
Service, IPCP enables configuration of an IPv4 address on the MS. Service, IPCP enables configuration of an IPv4 address on the MS.
This IPv4 address must be provided as the auxiliary information along This IPv4 address is provided as the auxiliary information along with
with the link up notification. IPV6CP used for Simple IPv6 service the link up notification. IPV6CP used for Simple IPv6 service does
does not provide an IPv6 address, but the interface identifiers for not provide an IPv6 address, but the interface identifiers for local
local and remote endpoints of the PPP link. Since there is no and remote endpoints of the PPP link. Since there is no standards-
standards-mandated correlation between the interface identifier and mandated correlation between the interface identifier and other IP-
other IP-layer configuration parameters, this information is deemed layer configuration parameters, this information is deemed not useful
not useful for DNA (nevertheless it may be provided as auxiliary for DNA (nevertheless, it may be provided as auxiliary information
information for other uses). for other uses).
3.3. IEEE 802.11/WiFi 3.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-802.11b], IEEE 802.11g [IEEE-802.11g], and IEEE 802.11a
[IEEE-802.11a]. The specifications define both the MAC-layer and the [IEEE-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) that then
forwards them to the final receiver. A station (STA) establishes an forwards them to the final receiver. A station (STA) establishes an
IEEE 802.11 association 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 uses Robust Secure Network (RSN packets. In a WiFi network that uses Robust Secure Network (RSN
[IEEE-802.11i]), successful completion of the 4-way handshake between [IEEE-802.11i]), successful completion of the 4-way handshake between
the 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 is generated upon this event. In non-RSN-based
based networks, successful association or re-association events on networks, successful association or re-association events on the link
the link layer must cause a link up notification sent to the IP- layer causes a link up notification sent to the IP layer.
layer.
As part of the link establishment, the STA learns the Basic Service As part of the link establishment, the STA learns the BSSID and SSID
Set Identification (BSSID) and Service Set Identifier (SSID)
associated with the AP. The BSSID is a unique identifier of the AP, associated with the AP. The BSSID is a unique identifier of the AP,
usually set to the MAC address of the wireless interface of the AP. usually set to the MAC address of the wireless interface of the AP.
The SSID carries the identifier of the Extended Service Set (ESS) - The SSID carries the identifier of the Extended Service Set (ESS) --
the set composed of APs and associated STAs that share a common the set composed of APs and associated STAs that share a common
distribution system. BSSID and SSID may be provided as auxiliary distribution system. The 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 information does not provide a deterministic indication of whether
the IP-layer configuration must be changed upon movement. There is the IP-layer configuration must be changed upon movement. There is
no standards-mandated one-to-one relation between the BSSID/SSID 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 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 any one of multiple IP subnets. Similarly, an ESS with the given
SSID may span multiple IP subnets. And finally, the SSIDs are not SSID may span multiple IP subnets. And finally, the SSIDs are not
globally unique. The same SSID may be used by multiple independent globally unique. The same SSID may be used by multiple independent
ESSs. Nevertheless, BSSID/SSID information may be used in a ESSs. Nevertheless, BSSID/SSID information may be used in a
probabilistic way by the DNA process, hence it is provided with the probabilistic way by the DNA process; hence, it is provided with the
link up event notification. link up event notification.
In ad-hoc mode, mobile stations (STA) in range may directly In ad-hoc mode, mobile stations (STA) in range may directly
communicate with each other, i.e., without any infrastructure or communicate with each other, i.e., without any infrastructure or
intermediate hop. The set of communicating STAs is called IBSS for intermediate hop. The set of communicating STAs is called IBSS for
Independent Basic Service Set. In an IBSS, only STA services are Independent Basic Service Set. In an IBSS, only STA services are
available, i.e. authentication, deauthentication, privacy and MSDU available, i.e., authentication, deauthentication, privacy, and MAC
delivery. STAs do not associate with each other, and therefore may Service Data Unit (MSDU) delivery. STAs do not associate with each
exchange data frames in state 2 (authenticated and not associated) or other, and therefore may exchange data frames in state 2
even in state 1 (unauthenticated and unassociated) if the (authenticated and not associated) or even in state 1
Distribution System is not used (i.e., "To DS" and "From DS" bits are (unauthenticated and unassociated) if the Distribution System is not
clear). If authentication is performed, a link up indication can be used (i.e., "To DS" and "From DS" bits are clear). If authentication
generated upon authentication. Concerning the link layer is performed, a link up indication can be generated upon
identification, both the BSSID (which is a random MAC address chosen authentication. Concerning the link layer identification, both the
by a STA of the IBSS) and SSID may be used to identify a link, but BSSID (which is a random MAC address chosen by a STA of the IBSS) and
not to make any assumptions on the IP network configuration. SSID may be used to identify a link, but not to make any assumptions
on the IP network configuration.
3.4. IEEE 802.3 CSMA/CD 3.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
link-layer indications on Ethernet networks, and shows how bridging link-layer indications on Ethernet networks, and shows how bridging
affects these indications. affects these indications.
In Ethernet networks, hosts are connected by wires or by optic fibre 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), to a switch (bridge), a bus (e.g., coaxial cable), a repeater (hub),
or directly to another Ethernet device. Interfaces are symmetric, in or directly to another Ethernet device. Interfaces are symmetric, in
that while many different physical layers may be present, medium that while many different physical layers may be present, medium
access control is uniform for all devices. access control is uniform for all devices.
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).
3.4.1. Link Integrity Tests in 802.3 Networks 3.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)
stage), and periodically afterwards. It makes use of physical-layer and periodically afterwards. They make 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
generate link indications if the technology dependent interface is generate link indications if the technology-dependent interface is
implemented on an Ethernet device [IEEE-802.3]. implemented on an Ethernet device [IEEE-802.3].
The link_status has possible values of FAIL, READY and OK. When an The link_status has possible values of FAIL, READY, and OK. In FAIL
interface is in FAIL state, Link Integrity Tests have failed. Where state, Link Integrity Tests have failed. In READY state, the link
status is READY, the link segment has passed integrity tests, but segment has passed integrity tests, but auto-negotiation has not
autonegotiation has not completed. OK state indicates that the completed. In OK state, the medium is able to send and receive
medium is able to send and receive packets. 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.
These indications do not definitively ensure that packets will be These indications do not definitively ensure that packets will be
able to be received through the bridge domain, though [see the next able 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.
3.4.2. IEEE 802.1D Bridging and Its Effects on Link-layer Event 3.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. This is bridges require the active topology to be loop free. This is
achieved through the Spanning Tree Protocol (STP) or the Rapid achieved through the Spanning Tree Protocol (STP) or the Rapid
Spanning Tree Protocol (RSTP). These protocols exchange Bridge Spanning Tree Protocol (RSTP). These protocols exchange Bridge
Protocol Data Units (BPDUs), as defined in [IEEE-802.1D], which leads Protocol Data Units (BPDUs), as defined in [IEEE-802.1D]; this leads
to, where required, the blocking of ports (i.e., not forwarding). to the blocking of ports (i.e., not forwarding), where required.
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
with the exception of some unbridged management frames. The STP will ports with the exception of some unbridged management frames. The
determine if the port can be connected to the network in a loop-free STP will determine if the port can be connected to the network in a
manner. loop-free manner.
For these technologies, even though the link layer appears available, For these technologies, even though the link layer appears available,
no data packet forwarding will occur until it is determined that the no data packet forwarding will occur until it is determined that the
port can be connected to the network in a loop-free environment. port can be connected to the network in a loop-free environment.
For hosts which are providing indications to upper layer protocols, For hosts that are providing indications to upper-layer protocols,
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.
A host connected to a bridge port does not receive any explicit A host connected to a bridge port does not receive any explicit
indication that the bridge has started forwarding packets. indication that the bridge has started forwarding packets.
Therefore, a host may not know when STP operations have completed, Therefore, a host may not know when STP operations have completed, or
and when it is safe to inform upper layers to transmit packets. when it is safe to 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 should assume that RSTP or STP is being performed. Hosts may host should assume that RSTP or STP is being performed. Hosts may
listen to STP/RSTP and 802.1AB messages to gain further information listen to STP/RSTP and 802.1AB messages to gain further information
about the timing of full connectivity on the link, for example, to about the timing of full connectivity on the link, for example, to
override an existing indication. override an existing indication.
Notably, though, it is not easy for a host to distinguish between Notably, though, it is not easy for a host to distinguish between
Disabled bridge ports and non-bridge ports with no active disabled bridge ports and non-bridge ports with no active
transmitters on them, as Disabled ports will have no traffic on them, transmitters on them, as Disabled ports will have no traffic on them,
and incur 100% sender loss. 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
is no visible bridge whose port is enabled for bridging (S8.4.5 of 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 is generated,
generated, if one has not been already. if one has not been already.
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 is
generated. If the previous link up notification was non- generated. If the previous link up notification was non-
deterministic, then this notification includes an attribute deterministic, then this notification includes an attribute
signifying that the packets sent within the prior interval were lost. signifying 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 auto-negotiation, this delay is abbreviated to 3 seconds after auto-
autonegotiation completes [IEEE-802.1D]. negotiation completes [IEEE-802.1D].
3.4.3. 802.1AB Link-Layer Discovery Protocol 3.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 that are directly adjacent to them on
on the local LAN [IEEE-802.1ab]. 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
to indicate the configuration parameters of the device. Devices may indicate the configuration parameters of the device. Devices may
either send or receive these messages, or both. send or receive these messages, or do both.
The LLDP message may contain a System Capabilities TLV, which The LLDP message may contain a System Capabilities TLV, which
describes the MAC and IP layer functions which a device is currently describes the MAC- and IP-layer functions that a device is currently
using. Where a host receives the Systems Capabilities TLV which using. Where a host receives the System Capabilities TLV indicating
indicate that no Bridging is occurring on the LLDP transmitter, no that no Bridging is occurring on the LLDP transmitter, no delays for
delays for STP calculation will be applied to packets sent through STP calculation will be applied to packets sent through this
this transmitter. This would allow the generation of a link up transmitter. This would allow the generation of a link up
notification. notification.
Additionally, if a host receives a Systems Capabilities TLV which Additionally, if a host receives a System Capabilities TLV indicating
indicates that the LLDP transmitter is a bridge, the host's that the LLDP transmitter is a bridge, the host's advertisement that
advertisement that it is an (end-host) Station-Only, may tell the it is an (end-host) Station-Only may tell the bridge not to run STP
bridge not to run STP, and immediately allow forwarding. and may 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.
Because the protocol is new and not widely deployed, it is unclear Because the protocol is new and not widely deployed, 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.
3.4.4. Other heuristics 3.4.4. Other Heuristics
In 802.3 networks, NICs are often capable of returning a speed and In 802.3 networks, Network Interface Cards (NICs) are often capable
duplex indication to the host, and that changes in these of returning a speed and duplex indication to the host. Changes in
characteristics may indicate a connection to a new layer 2 network. these characteristics may indicate a connection to a new layer 2
network.
3.4.5. Summary 3.4.5. 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 or retraction of indications previously This may cause re-indication or retraction of indications previously
sent to upper layer protocols. sent to upper layer protocols.
4. IANA Considerations 4. Security Considerations
This document has no actions for IANA.
5. Security Considerations
Attackers may spoof various indications at the link layer, or Attackers may spoof various indications at the link layer, or
manipulate the physical medium directly in an effort to confuse the manipulate the physical medium directly in an effort to confuse the
host about the state of the link layer. For instance, attackers may host about the state of the link layer. For instance, attackers may
spoof error messages or disturb the wireless medium to cause the host spoof error messages or disturb the wireless medium to cause the host
to move its connection elsewhere or to even disconnect. Attackers to move its connection elsewhere or even to disconnect. Attackers
may also spoof information to make the host believe it has a may also spoof information to make the host believe it has a
connection when, in reality, it does not. In addition, wireless connection when, in reality, it does not. In addition, wireless
networks such as 802.11 are susceptible to an attack called the "Evil networks such as 802.11 are susceptible to an attack called the "Evil
Twin" attack where an attacker sets up an Access Point with the same Twin" attack where an attacker sets up an Access Point with the same
SSID as a legitimate one and gets the use to connect to the fake SSID as a legitimate one and gets the use to connect to the fake
access point instead of the real one. These attacks may cause use of access point instead of the real one. These attacks may cause use of
non-preferred networks or even denial of service. non-preferred networks or even denial of service.
This specification does not provide any protection of its own for the This specification does not provide any protection of its own for the
indications from the lower layers. But the vulnerabilities can be indications from the lower layers. But the vulnerabilities can be
mitigated through the use of techniques in other parts of the mitigated through the use of techniques in other parts of the
protocol stack. In particular, it is recommended that protocol stack. In particular, it is recommended that
authentication, replay and integrity protection of link-layer authentication, replay, and integrity protection of link-layer
management messages is enabled when available. e.g. The IEEE 802.1ae management messages are enabled when available. For example, the
standard [IEEE-802.1ae] defines such mechanisms for IEEE 802 IEEE 802.1ae standard [IEEE-802.1ae] defines such mechanisms for IEEE
compliant MAC layers. Additionally, the protocol stack may also use 802-compliant MAC layers. Additionally, the protocol stack may also
some network layer mechanisms to achieve partial protection. For use some network-layer mechanisms to achieve partial protection. For
instance, SEND [RFC3971] could be used to confirm secure reachability instance, SEND [RFC3971] could be used to confirm secure reachability
with a router. However, network layer mechanisms are unable to deal with a router. However, network layer mechanisms are unable to deal
with all problems, such as with insecure lower layer notifications with all problems, such as insecure lower-layer notifications that
that lead to the link not functioning properly. lead to the link not functioning properly.
6. 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.
7. 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, Steve Bellovin, Thomas Narten, Petch, Dan Romascanu, Pekka Savola, Steve Bellovin, Thomas Narten,
Matt Mathis, Alfred Hoenes and Muhammad Mukarram bin Tariq for their Matt Mathis, Alfred Hoenes, and Muhammad Mukarram bin Tariq for their
useful comments and suggestions. useful comments and suggestions.
8. References 7. References
8.1. Normative References 7.1. Normative References
[CDMA2K] "IS-835 - cdma2000 Wireless IP Network Standard", . [CDMA2K] "cdma2000 Wireless IP Network Standard", ,
December 2000.
[GPRS] "Digital cellular telecommunications system (Phase 2+); [GPRS] "Digital cellular telecommunications system (Phase
General Packet Radio Service (GPRS) Service description; 2+); General Packet Radio Service (GPRS) Service
Stage 2", 3GPP TS 03.60 version 7.9.0 Release 98. description; Stage 2", 3GPP TS 03.60 version 7.9.0
Release 98.
[GPRS-LINK] [GPRS-LINK] "Digital cellular telecommunications system (Phase
"Digital cellular telecommunications system (Phase 2+); 2+); Radio subsystem link control", 3GPP GSM 03.05
Radio subsystem link control", 3GPP GSM 03.05 version version 7.0.0 Release 98.
7.0.0 Release 98.
[IEEE-802.11a] [IEEE-802.11a] Institute of Electrical and Electronics Engineers,
Institute of Electrical and Electronics Engineers, "IEEE "IEEE Std 802.11a-1999, supplement to IEEE Std
Std 802.11a-1999, supplement to IEEE Std 802.11-1999, Part 802.11-1999, Part 11: Wireless MAN Medium Access
11: Wireless MAN Medium Access Control (MAC) and Physical Control (MAC) and Physical Layer (PHY)
Layer (PHY) specifications: High-speed Physical Layer in specifications: High-speed Physical Layer in the 5
the 5 GHZ band", IEEE Standard 802.11a, September 1999. GHZ band", IEEE Standard 802.11a, September 1999.
[IEEE-802.11b] [IEEE-802.11b] Institute of Electrical and Electronics Engineers,
Institute of Electrical and Electronics Engineers, "IEEE "IEEE Std 802 Part 11, Information technology -
Std 802 Part 11, Information technology - Telecomunications and information exchange between
Telecomunications and information exchange between systems systems - Local and metropolitan area networks -
- Local and metropolitan area networks - Specific Specific requirements - Part 11: Wireless Lan Medium
requirements - Part 11: Wireless Lan Medium Access Control Access Control (MAC) And Physical Layer (PHY)
(MAC) And Physical Layer (PHY) Specifications", Specifications", IEEE Standard 802.11b, August 1999.
IEEE Standard 802.11b, August 1999.
[IEEE-802.11g] [IEEE-802.11g] Institute of Electrical and Electronics Engineers,
Institute of Electrical and Electronics Engineers, "IEEE "IEEE Std 802.11g-2003, Amendment to IEEE Std 802.11,
Std 802.11g-2003, Amendment to IEEE Std 802.11, 1999 1999 edition, Part 11: Wireless MAN Medium Access
edition, Part 11: Wireless MAN Medium Access Control (MAC) Control (MAC) and Physical Layer (PHY)
and Physical Layer (PHY) specifications. Amendment 4: specifications. Amendment 4: Further Higher Data
Further Higher Data Rate Extension in the 2.4 GHz Band", Rate Extension in the 2.4 GHz Band", IEEE Standard
IEEE Standard 802.11g, June 2003. 802.11g, June 2003.
[IEEE-802.11i] [IEEE-802.11i] Institute of Electrical and Electronics Engineers,
Institute of Electrical and Electronics Engineers,
"Supplement to STANDARD FOR Telecommunications and "Supplement to STANDARD FOR Telecommunications and
Information Exchange between Systems - LAN/MAN Specific Information Exchange between Systems - LAN/MAN
Requirements - Part 11: Wireless Medium Access Control Specific Requirements - Part 11: Wireless Medium
(MAC) and physical layer (PHY) specifications: Access Control (MAC) and physical layer (PHY)
Specification for Enhanced Security", IEEE IEEE 802.11i, specifications: Specification for Enhanced Security",
December 2004. IEEE 802.11i, December 2004.
[IEEE-802.1D] [IEEE-802.1D] Institute of Electrical and Electronics Engineers,
Institute of Electrical and Electronics Engineers, "IEEE "IEEE standard for local and metropolitan area
standard for local and metropolitan area networks - common networks - common specifications - Media access
specifications - Media access control (MAC) Bridges", ISO/ control (MAC) Bridges", ISO/IEC IEEE Std 802.1D,
IEC IEEE Std 802.1D, 2004. 2004.
[IEEE-802.1ab] [IEEE-802.1ab] Institute of Electrical and Electronics Engineers,
Institute of Electrical and Electronics Engineers, "Draft "Draft Standard for Local and Metropolitan Networks:
Standard for Local and Metropolitan Networks: Station and Station and Media Access Control Connectivity
Media Access Control Connectivity Discovery (Draft 13)", Discovery (Draft 13)", IEEE draft Std 802.1AB, 2004.
IEEE draft Std 802.1AB, 2004.
[IEEE-802.1ae] [IEEE-802.1ae] Institute of Electrical and Electronics Engineers,
Institute of Electrical and Electronics Engineers, "IEEE "IEEE Std 802.1AE, Local and Metropolitan Area
Std 802.1AE, Local and Metropolitan Area Networks - Media Networks - Media Access Control (MAC) Security",
Access Control (MAC) Security", IEEE Standard 802.1ae, IEEE Standard 802.1ae, June 2006.
June 2006.
[IEEE-802.3] [IEEE-802.3] Institute of Electrical and Electronics Engineers,
Institute of Electrical and Electronics Engineers, "IEEE "IEEE standard for local and metropolitan area
standard for local and metropolitan area networks - networks - Specific Requirements, Part 3: Carrier
Specific Requirements, Part 3: Carrier Sense Multiple Sense Multiple Access with Collision Detection
Access with Collision Detection (CSMA/CD) Access Method (CSMA/CD) Access Method and Physical Layer
and Physical Layer Specifications", ISO/IEC IEEE Specifications", ISO/IEC IEEE Std 802.3, 2002.
Std 802.3, 2002.
[RFC1332] McGregor, G., "The PPP Internet Protocol Control Protocol [RFC1332] McGregor, G., "The PPP Internet Protocol Control
(IPCP)", RFC 1332, May 1992. Protocol (IPCP)", RFC 1332, May 1992.
[RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, [RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)",
RFC 1661, July 1994. STD 51, RFC 1661, July 1994.
[RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 2462, December 1998. Autoconfiguration", RFC 2462, December 1998.
[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,
and M. Carney, "Dynamic Host Configuration Protocol for C., and M. Carney, "Dynamic Host Configuration
IPv6 (DHCPv6)", RFC 3315, July 2003. Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander,
Neighbor Discovery (SEND)", RFC 3971, March 2005. "SEcure Neighbor Discovery (SEND)", RFC 3971,
March 2005.
[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.
8.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
(PLMN) supporting packet based services and Packet Data Network (PLMN) supporting packet based services and
Networks (PDN) (Release 6)", 3GPP TS 29.061 version 6.1.0 Packet Data Networks (PDN) (Release 6)", 3GPP TS
2004-06. 29.061 version 6.1.0 2004-06.
[GPRS-GSSA]
"Technical Specification Group Services and System Aspect;
General Packet Radio Service (GPRS) Service description;
Stage 2 (Release 6)", 3GPP TS 23.060 version 6.5.0
2004-06.
[I-D.ietf-mipshop-fast-mipv6]
Koodli, R., "Fast Handovers for Mobile IPv6",
draft-ietf-mipshop-fast-mipv6-03 (work in progress),
October 2004.
[I-D.ietf-mobileip-lowlatency-handoffs-v4] [GPRS-GSSA] "Technical Specification Group Services and System
Malki, K., "Low Latency Handoffs in Mobile IPv4", Aspect; General Packet Radio Service (GPRS) Service
draft-ietf-mobileip-lowlatency-handoffs-v4-11 (work in description; Stage 2 (Release 6)", 3GPP TS 23.060
progress), October 2005. version 6.5.0 2004-06.
[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.
[RFC4068] Koodli, R., "Fast Handovers for Mobile IPv6",
RFC 4068, July 2005.
[RFC4881] El Malki, K., "Low-Latency Handoffs in Mobile IPv4",
RFC 4881, June 2007.
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
Nicolas Montavont Nicolas Montavont
LSIIT - University Louis Pasteur GET ENST Bretagne
Pole API, bureau C428 2, rue de la chataigneraie
Boulevard Sebastien Brant Cesson-Sevigne 35576
Illkirch 67400
France France
Phone: +33 390 244 587 Phone: (33) 2 99 12 70 23
Email: montavont@dpt-info.u-strasbg.fr EMail: nicolas.montavont@enst-bretagne.fr
Eric Njedjou Eric Njedjou
France Telecom France Telecom
4, Rue du Clos Courtel BP 91226 4, Rue du Clos Courtel BP 91226
Cesson Sevigne 35512 Cesson Sevigne 35512
France France
Phone: +33 299124202 Phone: +33 299124878
Email: eric.njedjou@orange-ftgroup.com EMail: eric.njedjou@orange-ftgroup.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
75 West Plumeria Drive Istanbul
San Jose, CA 95134 Turkey
USA
Phone: +1 408 544 5656 Phone: +90 533 348 2402
Email: alper01.yegin@partner.samsung.com EMail: a.yegin@partner.samsung.com
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
skipping to change at page 24, line 45 skipping to change at page 18, line 45
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Acknowledgment Acknowledgement
Funding for the RFC Editor function is provided by the IETF Funding for the RFC Editor function is currently provided by the
Administrative Support Activity (IASA). Internet Society.
 End of changes. 102 change blocks. 
304 lines changed or deleted 277 lines changed or added

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