draft-ietf-dna-link-information-03.txt   draft-ietf-dna-link-information-04.txt 
Network Working Group A. Yegin, Ed. Network Working Group S. Krishnan, Ed.
Internet-Draft Samsung AIT Internet-Draft Ericsson Research
Expires: April 27, 2006 October 24, 2005 Expires: April 9, 2007 N. Montavont
LSIIT - University Louis Pasteur
E. Njedjou
France Telecom
S. Veerepalli
Qualcomm
A. Yegin, Ed.
Samsung AIT
October 6, 2006
Link-layer Event Notifications for Detecting Network Attachments Link-layer Event Notifications for Detecting Network Attachments
draft-ietf-dna-link-information-03.txt draft-ietf-dna-link-information-04
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 33 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 27, 2006. This Internet-Draft will expire on April 9, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). 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 link-layer status information to IP. Link-layer event notifications
can help IP expeditiously detect configuration changes. This can help IP expeditiously detect configuration changes. This
document provides a non-exhaustive catalogue of information available document provides a non-exhaustive catalogue of information available
from well-known access technologies. 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 . . . . . . . . . . . . . . . . . . . . . . . . 7 2.1. GPRS/3GPP . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2 cdma2000/3GPP2 . . . . . . . . . . . . . . . . . . . . . . 8 2.2. cdma2000/3GPP2 . . . . . . . . . . . . . . . . . . . . . . 8
2.3 IEEE 802.11/WiFi . . . . . . . . . . . . . . . . . . . . . 9 2.3. IEEE 802.11/WiFi . . . . . . . . . . . . . . . . . . . . . 8
2.4 IEEE 802.3 CSMA/CD . . . . . . . . . . . . . . . . . . . . 10 2.4. IEEE 802.3 CSMA/CD . . . . . . . . . . . . . . . . . . . . 10
2.4.1 Link Integrity Tests in 802.3 Networks . . . . . . . . 11 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 . . . . . . . . . . . . . . . . . 12 Event Notifications . . . . . . . . . . . . . . . . . 11
2.4.3 802.1AB Link-Layer Discovery Protocol . . . . . . . . 14 2.4.3. 802.1AB Link-Layer Discovery Protocol . . . . . . . . 13
2.4.4 Summary . . . . . . . . . . . . . . . . . . . . . . . 14 2.4.4. Summary . . . . . . . . . . . . . . . . . . . . . . . 13
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
4. Security Considerations . . . . . . . . . . . . . . . . . . . 16 4. Security Considerations . . . . . . . . . . . . . . . . . . . 15
5. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 17 5. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 16
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
7.1 Normative References . . . . . . . . . . . . . . . . . . . 19 7.1. Normative References . . . . . . . . . . . . . . . . . . . 18
7.2 Informative References . . . . . . . . . . . . . . . . . . 20 7.2. Informative References . . . . . . . . . . . . . . . . . . 19
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 21 Appendix A. Change History . . . . . . . . . . . . . . . . . . . 21
A. Change History . . . . . . . . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22
Intellectual Property and Copyright Statements . . . . . . . . 23 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 re-configuration of IP-
skipping to change at page 4, line 9 skipping to change at page 4, line 9
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 draft 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 [I-D.ietf-dna-goals]. A necessary for solving the DNA problem [RFC4135]. A broader set of
broader set of information (e.g., signal strength, packet loss, etc.) information (e.g., signal strength, packet loss, etc.) and events
may be used for other problem spaces, such as anticipation-based (e.g. link down) may be used for other problem spaces, such as
Mobile IP fast handovers [I-D.ietf-mobileip-lowlatency-handoffs-v4] anticipation-based Mobile IP fast handovers [I-D.ietf-mobileip-
lowlatency-handoffs-v4]
[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.
Two basic link-layer events are considered potentially useful to DNA The link-layer event that is considered most useful to DNA process is
process: link up and link down. Both of these events are the link up event. The link up event is deterministic, and the link
deterministic, and their notifications are provided to IP-layer after up notification is provided to IP-layer after the event successfully
the events successfully conclude. These events and notifications are concludes. The link up events and notifications are associated with
associated with a network interface on the node. The IP module may a network interface on the node. The IP module may receive
receive simultaneous independent notifications from each one of the simultaneous independent notifications from each one of the network
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-
layer connection between the node and an attachment point. layer connection between the node and an attachment point.
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 MUST
be delivered to the IP-layer. By the time the notification is be delivered to the IP-layer. By the time the notification is
delivered, the link-layer of the node MUST be ready to accept IP delivered, the link-layer of the node MUST be ready to accept IP
packets from the IP and the physical-layers. packets from the IP and the physical-layers. Each time an interface
changes its point of attachment, a link up event SHOULD be generated.
There is a non-deterministic usage of link up notification to There is a non-deterministic usage of link up notification to
accomodate implementations that desire to indicate the link is up but accomodate implementations that desire to indicate the link is up but
the data transmission may be blocked in the network (see IEEE 802.3 the data transmission may be blocked in the network (see IEEE 802.3
discussion). A link up notification MAY be generated with an discussion). A link up notification MAY be generated with an
appropriate attribute (e.g., "risk" indicated by R-flag) to convey appropriate attribute (e.g., "risk" indicated by R-flag) to convey
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 faith of these packets,
it MUST generate a link up without any additional indications (no it MUST generate a link up without any additional indications (no
flags set). flags set).
"Link down" is an event provided by the link-layer that signifies a
state change associated with the interface no longer being capable of
communicating data packets. A link down event is only generated once
the link-layer considers the link unusable; transient periods of high
frame loss are not sufficient. When the link-layer connection is
physically or logically torn down and it can no longer carry data
packets, this is considered to be a link down event.
Among these two events the first one to take place after an interface
becomes enabled MUST be a link up event. During the time a network
interface is enabled, it may go through a series of link up and down
events. Each time the interface changes its point of attachment, a
link down event with the previous attachment point MUST be followed
by a link up event with the new one. Finally, when the network
interface is disabled, this MUST generate a link down event. Each
one of these events MUST generate a notification in the order they
occur.
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.
In addition to the type of the event (link up, link down), a link- A link up notification may optionally deliver information relating to
layer notification may also optionally deliver information relating the attachment point. Such auxiliary information may include
to the attachment point. Such auxiliary information may include
identity of the attachment point (e.g., base station identifier), or identity of the attachment point (e.g., base station identifier), or
the IP-layer configuration parameters associated with the attached the IP-layer configuration parameters associated with the attached
subnet (e.g., subnet prefix, default gateway address, etc.). While subnet (e.g., subnet prefix, default gateway address, etc.). While
merely knowing that a new link-layer connection is established may merely knowing that a new link-layer connection is established may
prompt DNA process to immediately seek other clues for detecting prompt DNA process to immediately seek other clues for detecting
network configuration change, auxiliary information may constitute 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 link-layer connection may be exactly what the DNA obtained during link-layer connection may be exactly what the DNA
process is trying to discover (e.g., IP address configured during PPP process is trying to discover (e.g., IP address configured during PPP
link establishment). link establishment).
The link-layer process leading to a link up or link down event The link-layer process leading to a link up event depends on the link
depends on the link technology. While a link-layer notification MUST technology. While a link-layer notification MUST always indicate
always indicate the event type, 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 GPRS is an enhancement to the GSM data transmission architecture and
capabilities, designed to allow for packet switching in user data capabilities, designed to allow for packet switching in user data
transmission within the GPRS network as well as for higher quality of transmission within the GPRS network as well as for higher quality of
service for the IP traffic of Mobile Terminals with external Packets service for the IP traffic of Mobile Terminals with external Packets
Data Networks such as the Internet or corporate LANs [GPRS][GPRS- Data Networks such as the Internet or corporate LANs [GPRS][GPRS-
LINK]. 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.
skipping to change at page 8, line 21 skipping to change at page 8, line 4
different type of application can be served. In that case, different type of application can be served. In that case,
activation of the secondary PDP Context MUST NOT generate another activation of the secondary PDP Context MUST NOT generate another
link up event notification. However, a secondary PDP Context link up event notification. However, a secondary PDP Context
establishment that triggers a new IP configuration is to be treated establishment that triggers a new IP configuration is to be treated
from the IP layer as indicated above. 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.
PDP Context deactivation is used to generate link down event 2.2. cdma2000/3GPP2
notifications. Considering there may be multiple PDP Contexts with
the same IP configuration parameters (e.g., primary and secondary
contexts), the deactivation of the PDP Context that has the only
instance of a given IP configuration MUST generate a link down event
notification. For example, both the primary and the secondary PDP
Contexts may be using the same configuration parameters. In that
case, deactivation of the primary context would not generate a link
down notification while the secondary context is active. If the
primary context is deactivated first, and than the secondary is
deactivated, only the latter action would generate the link down
notification.
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 9, line 30 skipping to change at page 8, line 48
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).
IPCP/IPV6CP termination, or the underlying LCP or NCP reaching Closed 2.3. IEEE 802.11/WiFi
State signify the end of corresponding IP service on the PPP link.
This event MUST generate a link down notification delivered to the
IP-layer.
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
skipping to change at page 10, line 27 skipping to change at page 9, line 40
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,
hence it is provided with the link up event notification. hence it is provided with the link up event notification.
Disassociation event in non-RSN-based, and de-authentication and
disassociation events in RSN-based WiFi networks MUST translate to
link down events, and generate the corresponding link-layer
notifications.
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 MSDU
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, and a link down indication can be generated upon authentication. Concerning the link layer
generated upon deauthentication. 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 11, line 29 skipping to change at page 10, line 36
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 12, line 4 skipping to change at page 11, line 11
The link_status has possible values of FAIL, READY and OK. When an The link_status has possible values of FAIL, READY and OK. When an
interface is in FAIL state, Link Integrity Tests have failed. Where interface is in FAIL state, Link Integrity Tests have failed. Where
status is READY, the link segment has passed integrity tests, but status is READY, the link segment has passed integrity tests, but
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.
PMA_LINK.indicate(FAIL) MUST be used to generate a link down
notification.
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. The Spanning
Tree Protocol (STP) achieves this by the exchange of Bridge Protocol Tree Protocol (STP) achieves this by the exchange of Bridge Protocol
Data Unit (BPDU), as defined in [IEEE-802.1D], which leads to, where Data Unit (BPDU), as defined in [IEEE-802.1D], which leads to, where
required, the blocking of ports (i.e., not forwarding). 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
skipping to change at page 14, line 5 skipping to change at page 13, line 9
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 14, line 37 skipping to change at page 13, line 41
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.
skipping to change at page 17, line 7 skipping to change at page 16, line 7
4. Security Considerations 4. Security Considerations
A faked link-layer event notification can be used to launch a A faked link-layer event notification can be used to launch a
denial-of service attack on the node and the associated network. denial-of service attack on the node and the associated network.
Secure generation and delivery of these notifications MUST be Secure generation and delivery of these notifications MUST be
ensured. This is a subject for link-layer and network stack designs ensured. This is a subject for link-layer and network stack designs
and therefore it is outside the scope of this document. and therefore it is outside the scope of this document.
5. Contributors 5. Contributors
Text for the specific link-layer technologies covered by this In addition to the people listed in the author list, text for the
document are contributed by Eric Njedjou (GPRS), Siva Veerepalli specific link-layer technologies covered by this document was
(cdma2000), Nicolas Montavont (IEEE 802.11b), Thomas Noel (IEEE contributed by Thomas Noel (IEEE 802.11b), and Greg Daley (IEEE
802.11b), and Greg Daley (IEEE 802.3). 802.3). The authors would like to thank them for their efforts in
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
7.0.0 Release 98. 7.0.0 Release 98.
[I-D.ietf-dna-goals]
Choi, J., "Goals of Detecting Network Attachment in IPv6",
draft-ietf-dna-goals-04 (work in progress), December 2004.
[IEEE-802.11a] [IEEE-802.11a]
Institute of Electrical and Electronics Engineers, "IEEE Institute of Electrical and Electronics Engineers, "IEEE
Std 802.11a-1999, supplement to IEEE Std 802.11-1999, Part Std 802.11a-1999, supplement to IEEE Std 802.11-1999, Part
11: Wireless MAN Medium Access Control (MAC) and Physical 11: Wireless MAN Medium Access Control (MAC) and Physical
Layer (PHY) specifications: High-speed Physical Layer in Layer (PHY) specifications: High-speed Physical Layer in
the 5 GHZ band", IEEE Standard 802.11a, September 1999. the 5 GHZ band", IEEE Standard 802.11a, September 1999.
[IEEE-802.11b] [IEEE-802.11b]
Institute of Electrical and Electronics Engineers, "IEEE Institute of Electrical and Electronics Engineers, "IEEE
Std 802 Part 11, Information technology - Std 802 Part 11, Information technology -
skipping to change at page 20, line 47 skipping to change at page 19, line 44
[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, 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.
7.2 Informative References [RFC4135] Choi, JH. and G. Daley, "Goals of Detecting Network
Attachment in IPv6", RFC 4135, August 2005.
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 27 skipping to change at page 21, line 5
[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.
Author's Address
Alper E. Yegin (editor)
Samsung Advanced Institute of Technology
75 West Plumeria Drive
San Jose, CA 95134
USA
Phone: +1 408 544 5656
Email: alper.yegin@samsung.com
Appendix A. Change History Appendix A. Change History
The following changes were made on draft version 00: The following changes were made on draft version 00:
- IEEE 802.11 ad-hoc mode discussion added. - IEEE 802.11 ad-hoc mode discussion added.
- IPv6 address configuration over 3GPP networks clarified. - IPv6 address configuration over 3GPP networks clarified.
The following changes were made on draft version 01: The following changes were made on draft version 01:
- Text for IEEE 802.3 added. - Text for IEEE 802.3 added.
- Multiple 3GPP PDP Contexts scenario clarified. - Multiple 3GPP PDP Contexts scenario clarified.
The following change was made on draft version 02: The following change was made on draft version 02:
- Editorial fixes as suggested by WG last call feedback. - 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
Suresh Krishnan (editor)
Ericsson Research
8400 Decarie Blvd.
Town of Mount Royal, QC
Canada
Email: suresh.krishnan@ericsson.com
Nicolas Montavont
LSIIT - University Louis Pasteur
Pole API, bureau C428
Boulevard Sebastien Brant
Illkirch 67400
France
Phone: +33 390 244 587
Email: montavont@dpt-info.u-strasbg.fr
Eric Njedjou
France Telecom
4, Rue du Clos Courtel BP 91226
Cesson Sevigne 35512
France
Phone: +33 299124202
Email: eric.njedjou@france-telecom.com
Siva Veerepalli
Qualcomm
5775 Morehouse Drive
San Diego, CA 92131
USA
Phone: +1 858 658 4628
Email: sivav@qualcomm.com
Alper E. Yegin (editor)
Samsung Advanced Institute of Technology
75 West Plumeria Drive
San Jose, CA 95134
USA
Phone: +1 408 544 5656
Email: alper01.yegin@partner.samsung.com
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.
skipping to change at page 23, line 41 skipping to change at page 24, line 41
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 33 change blocks. 
121 lines changed or deleted 127 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/