draft-ietf-dna-link-information-01.txt   draft-ietf-dna-link-information-02.txt 
Network Working Group A. Yegin, Ed. Network Working Group A. Yegin, Ed.
Internet-Draft Samsung AIT Internet-Draft Samsung AIT
Expires: August 11, 2005 E. Njedjou Expires: January 9, 2006 July 8, 2005
France Telecom
S. Veerepalli
Qualcomm
N. Montavont
T. Noel
LSIIT - University Louis Pasteur
February 10, 2005
Link-layer Event Notifications for Detecting Network Attachments Link-layer Event Notifications for Detecting Network Attachments
draft-ietf-dna-link-information-01.txt draft-ietf-dna-link-information-02.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, I certify that any applicable By submitting this Internet-Draft, each author represents that any
patent or other IPR claims of which I am aware have been disclosed, applicable patent or other IPR claims of which he or she is aware
and any of which I become aware will be disclosed, in accordance with have been or will be disclosed, and any of which he or she becomes
RFC 3668. 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
other groups may also distribute working documents as other groups may also distribute working documents as Internet-
Internet-Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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 August 11, 2005. This Internet-Draft will expire on January 19, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). All Rights Reserved. Copyright (C) The Internet Society (2005).
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 draft can help IP expeditiously detect configuration changes. This
provides a non-exhaustive catalogue of information available from document provides a non-exhaustive catalogue of information available
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 . . . . . . . . . . . . . . . . . . . . . . . . 6 2.1 GPRS/3GPP . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2 cdma2000/3GPP2 . . . . . . . . . . . . . . . . . . . . . . 7 2.2 cdma2000/3GPP2 . . . . . . . . . . . . . . . . . . . . . . 8
2.3 IEEE 802.11/WiFi . . . . . . . . . . . . . . . . . . . . . 8 2.3 IEEE 802.11/WiFi . . . . . . . . . . . . . . . . . . . . . 9
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 2.4 IEEE 802.3 CSMA/CD . . . . . . . . . . . . . . . . . . . . 10
4. Security Considerations . . . . . . . . . . . . . . . . . . . 11 2.4.1 Link Integrity Tests in 802.3 Networks . . . . . . . . 11
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 2.4.2 IEEE 802.1D Bridging and Its Effects on Link-layer
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 Event Notifications . . . . . . . . . . . . . . . . . 12
6.1 Normative References . . . . . . . . . . . . . . . . . . . . 13 2.4.3 802.1AB Link-Layer Discovery Protocol . . . . . . . . 14
6.2 Informative References . . . . . . . . . . . . . . . . . . . 14 2.4.4 Summary . . . . . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 15 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
A. Change History . . . . . . . . . . . . . . . . . . . . . . . . 17 4. Security Considerations . . . . . . . . . . . . . . . . . . . 16
Intellectual Property and Copyright Statements . . . . . . . . 18 5. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 17
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
7.1 Normative References . . . . . . . . . . . . . . . . . . . 19
7.2 Informative References . . . . . . . . . . . . . . . . . . 20
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 21
A. Change History . . . . . . . . . . . . . . . . . . . . . . . . 22
Intellectual Property and Copyright Statements . . . . . . . . 23
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 changing its IP subnet and therefore require re-configuration of IP-
IP-layer parameters, such as IP address, default gateway information, layer parameters, such as IP address, default gateway information,
and DNS server address. Detecting the subnet change can usually use and DNS server address. Detecting the subnet change can usually use
network-layer indications such as a change in the advertised prefixes network-layer indications such as a change in the advertised prefixes
(i.e., appearance and disappearance of prefixes). But generally (i.e., appearance and disappearance of prefixes). But generally
reliance on such indications does not yield rapid detection, since reliance on such indications does not yield rapid detection, since
these indications are not readily available upon node changing its these indications are not readily available upon node changing its
point of attachment. point of attachment.
The changes on the underlying link-layer status can be relayed to IP The changes on the underlying link-layer status can be relayed to IP
in the form of link-layer event notifications. Establishment and in the form of link-layer event notifications. Establishment and
tear down of a link-layer connection are two basic events types. tear down of a link-layer connection are two basic events types.
Additional information can be conveyed in addition to the event type, Additional information can be conveyed in addition to the event type,
such as the identifier of the network attachment point, or such as the identifier of the network attachment point (e.g., IEEE
network-layer configuration parameters obtained via the link-layer 802.11 BSSID and SSID), or network-layer configuration parameters
attachment process. It is envisaged that such event notifications obtained via the link-layer attachment process if available. It is
can in certain circumstances be used to expedite the inter-subnet envisaged that such event notifications can in certain circumstances
movement detection and reconfiguration process. For example, the be used to expedite the inter-subnet movement detection and
notification indicating that the node has established a new reconfiguration process. For example, the notification indicating
link-layer connection can be used for immediately probing the network that the node has established a new link-layer connection MAY be used
for a possible configuration change. In the absence of such a for immediately probing the network for a possible configuration
notification from the link-layer, IP has to wait for indications that change. In the absence of such a notification from the link-layer,
are not immediately available, such as receipt of next scheduled IP has to wait for indications that are not immediately available,
router advertisement, unreachability of the default gateway, etc. such as receipt of next scheduled router advertisement,
unreachability of the default gateway, etc.
It should be noted that a link-layer event notification does not It be noted that a link-layer event notification does not always
always translate into a subnet change. Even if the node has torn translate into a subnet change. Even if the node has torn down a
down a link-layer connection with one attachment point and link-layer connection with one attachment point and established a new
established a new connection with another, it may still be attached connection with another, it may still be attached to the same IP
to the same IP subnet. For example, several IEEE 802.11 access subnet. For example, several IEEE 802.11 access points can be
points can be attached to the same IP subnet. Moving among these attached to the same IP subnet. Moving among these access points
access points does not warrant any IP-layer configuration change. 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 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 [I-D.ietf-dna-goals]. A
broader set of information may be used for other problem spaces broader set of information (e.g., signal strenght, packet loss, etc.)
(e.g., anticipation-based Mobile IP fast handovers may be used for other problem spaces, such as anticipation-based
[I-D.ietf-mobileip-lowlatency-handoffs-v4] Mobile IP fast handovers [I-D.ietf-mobileip-lowlatency-handoffs-v4]
[I-D.ietf-mipshop-fast-mipv6]). Separate documents that are [I-D.ietf-mipshop-fast-mipv6]. Separate documents that are backward-
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
skipping to change at page 5, line 27 skipping to change at page 5, line 27
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 Two basic link-layer events are considered potentially useful to DNA
process: link up and link down. Both of these events are process: link up and link down. Both of these events are
deterministic, and their notifications are provided to IP-layer after deterministic, and their notifications are provided to IP-layer after
the events successfully conclude. These events and notifications are the events successfully conclude. These events and notifications are
associated with a network interface on the node. The IP module may associated with a network interface on the node. The IP module may
receive simultaneous independent notifications from each one of the receive simultaneous independent notifications from each one of the
network interfaces on the node. network interfaces on the node.
Node's establishment of a link-layer connection with an attachment "Link" is a communication facility or medium over which network nodes
point that signifies the availability of IP service (i.e., being able can communicate. Each link is associated with a minimum of two
to send and receive IP packets) between the two is considered a link endpoints. An "attachment point" is the link endpoint on the link to
up event. The attachment point is typically an access network which the node is currently connected, such as an access point, a
element, such as an access point, a base station, or a wired switch base station, or a wired switch.
[TO-DO: How about ad-hoc networks? Attached neighbors may be
considered attachment points]. "Link up" is an event provided by the link-layer that signifies a
state change associated with the interface becoming capable of
communicating data packets. This event is associated with a link-
layer connection between the node and an attachment point.
The actual event is managed by the link-layer of the node through 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.
Link down event signifies the discontinuation of the IP service There is a non-deterministic usage of link up notification to
between the node and the attachment point. When the link-layer accomodate implementations that desire to indicate the link is up but
connection is physically or logically torn down and it can no longer the data transmission may be blocked in the network (see IEEE 802.3
carry IP packets, this is considered to be a link down event. discussion). A link up notification MAY be generated with an
appropriate attribute (e.g., "risk" indicated by R-flag) to convey
the event. Alternatively, the link-layer implementation MAY choose
to delay the link up notification until the risk conditions cease to
exist.
If a link up with the R-flag set was generated, another link up MUST
follow up as soon as the link-layer is capable of generating a
deterministic notification. The event attributes MUST indicate
whether the packets transmitted since the previous notification were
presumed to be blocked (B-flag) or allowed (A-flag) by the network if
the link-layer could determine the exact conditions. If the link-
layer cannot make a determination about the faith of these packets,
it MUST generate a link up without any additional indications (no
flags set).
"Link down" is an event provided by the link-layer that signifies a
state change associated with the interface no longer being capable of
communicating data packets. A link down event is only generated once
the link-layer considers the link unusable; transient periods of high
frame loss are not sufficient. When the link-layer connection is
physically or logically torn down and it can no longer carry data
packets, this is considered to be a link down event.
Among these two events the first one to take place after an interface 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 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 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 events. Each time the interface changes its point of attachment, a
link down event with the previous attachment point must be followed link down event with the previous attachment point MUST be followed
by a link up event with the new one. Finally, when the network by a link up event with the new one. Finally, when the network
interface is disabled, this must generate a link down event. Each interface is disabled, this MUST generate a link down event. Each
one of these events must generate a notification in order they occur. 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 exists cases IPv6 subnet renumbering [RFC2461]. Therefore, there exist cases
where IP-layer configuration may have to change even without the where IP-layer configuration may have to change even without the IP-
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 In addition to the type of the event (link up, link down), a link-
link-layer notification may also optionally deliver information layer notification may also optionally deliver information relating
relating to the attachment point. Such auxiliary information may to the attachment point. Such auxiliary information may include
include identity of the attachment point (e.g., base station identity of the attachment point (e.g., base station identifier), or
identifier), or the IP-layer configuration parameters associated with the IP-layer configuration parameters associated with the attached
the attached subnet (e.g., subnet prefix, default gateway address, subnet (e.g., subnet prefix, default gateway address, etc.). While
etc.). While merely knowing that a new link-layer connection is merely knowing that a new link-layer connection is established may
established may prompt DNA process to immediately seek other clues prompt DNA process to immediately seek other clues for detecting
for detecting network configuration change, auxiliary information may network configuration change, auxiliary information may constitute
constitute further clues (and even the final answers sometimes). In further clues (and even the final answers sometimes). In cases where
cases where there is a one-to-one mapping between the attachment there is a one-to-one mapping between the attachment point
point identifiers and the IP-layer configurations, learning the identifiers and the IP-layer configurations, learning the former can
former can reveal the latter. Furthermore, IP-layer configuration reveal the latter. Furthermore, IP-layer configuration parameters
parameters obtained during link-layer connection may be exactly what obtained during link-layer connection may be exactly what the DNA
the DNA process is trying to discover (e.g., IP address configured process is trying to discover (e.g., IP address configured during PPP
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 or link down event
depends on the link technology. While a link-layer notification must depends on the link technology. While a link-layer notification MUST
always indicate the event type, the availability and types of always indicate the event type, the availability and types of
auxiliary information on the attachment point depends on the auxiliary information on the attachment point depends on the link-
link-layer technology as well. The following subsections examine layer technology as well. The following subsections examine four
three link-layer technologies and describe when a link-layer link-layer technologies and describe when a link-layer notification
notification must be generated and what information must be included must be generated and what information must be included in it.
in it. The coverage on the link types may be expanded in the future
[TO-DO: Add IEEE 802.3].
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 Data Networks such as the Internet or corporate LANs [GPRS][GPRS-
[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.
- The GPRS Radio Access Network is composed of Mobile Terminals (MT), - The GPRS Radio Access Network is composed of Mobile Terminals (MT),
a Base Station Subsystem and Serving GPRS Support Nodes (SGSN). a Base Station Subsystem and Serving GPRS Support Nodes (SGSN).
- An IP Core Network that acts as the transport backbone of user - An IP Core Network that acts as the transport backbone of user
datagrams between SGSNs and Gateway GPRS Support Nodes (GGSN). The datagrams between SGSNs and Gateway GPRS Support Nodes (GGSN). The
GGSN ensures the GPRS IP core network connectivity with external GGSN ensures the GPRS IP core network connectivity with external
networks, such as Internet or Local Area Networks. GGSN acts as the networks, such as Internet or Local Area Networks. GGSN acts as the
default IP gateway for the MT. default IP gateway for the MT.
A GPRS MT that wants to establish IP-level connections should first A GPRS MT that wants to establish IP-level connections MUST first
perform a GPRS attach to the SGSN. This should be followed by a perform a GPRS attach to the SGSN. This MUST be followed by a
request the GPRS network to settle the necessary soft state mechanism request to the GPRS network to settle the necessary soft state
(GPRS tunneling protocol) between its serving SGSN and the GGSN. The mechanism (GPRS tunneling protocol) between its serving SGSN and the
soft state maintained between the MT, the SGSN and the GGSN is called GGSN. The soft state maintained between the MT, the SGSN and the
a PDP Context. It is used for guaranteeing a negotiated quality of GGSN is called a PDP Context. It is used for guaranteeing a
service for the IP flows exchanged between the GPRS MT and an negotiated quality of service for the IP flows exchanged between the
external Packet Data Network such as Internet . It is only after the GPRS MT and an external Packet Data Network such as Internet. It is
PDP Context has been established, address autoconfiguration and only after the PDP Context has been established, address
tunneling mechanism have taken place that the MT's IP packets can be autoconfiguration and tunneling mechanism have taken place that the
forwarded to and from its remote IP peers. The aim of PDP Context MT's IP packets can be forwarded to and from its remote IP peers.
establishment is also to provide IP-level configuration on top of the The aim of PDP Context establishment is also to provide IP-level
GPRS link-layer attachment. configuration on top of the GPRS link-layer attachment.
Successful establishment of a PDP Context on a GPRS link signifies
the availability of IP service to the MT. Therefore, this link-layer
event MUST generate a link up event notification sent to IP-layer.
An MT has the possibility to establish a secondary PDP Context while
re-using the IP configuration acquired from a previously established
and active PDP Context. Establishment of a secondary PDP Context
does not provide additional information to IP-layer. Such a second
PDP Context would basically have a different QoS profile so that a
different type of application can be served. In that case,
activation of the secondary PDP Context MUST NOT generate another
link up event notification. However, a secondary PDP Context
establishment that triggers a new IP configuration is to be treated
from the IP layer as indicated above.
Successful establishment of a PDP Context on a GPRS signifies the
availability of IP service to the MT. Therefore, this link-layer
event must generate a link up event notification sent to IP-layer.
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 [RFC3315] [GPRS-GSSA] address configuration). Therefore no IPv6-
IPv6-related auxiliary information is provided to IP-layer. related auxiliary information is provided to IP-layer.
Similarly, PDP Context deactivation must generate a link down event PDP Context deactivation is used to generate link down event
notifications. Considering there may be multiple PDP Contexts with
the same IP configuration parameters (e.g., primary and secondary
contexts), the deactivation of the PDP Context that has the only
instance of a given IP configuration MUST generate a link down event
notification. For example, both the primary and the secondary PDP
Contexts may be using the same configuration parameters. In that
case, deactivation of the primary context would not generate a link
down notification while the secondary context is active. If the
primary context is deactivated first, and than the secondary is
deactivated, only the latter action would generate the link down
notification. notification.
2.2 cdma2000/3GPP2 2.2 cdma2000/3GPP2
cdma2000-based 3GPP2 packet data services provide mobile users wide cdma2000-based 3GPP2 packet data services provide mobile users wide
area high-speed access to packet switched networks [CDMA2K]. Some of area high-speed access to packet switched networks [CDMA2K]. Some of
the major components of the 3GPP2 packet network architecture consist the major components of the 3GPP2 packet network architecture consist
of: of:
- Mobile Station (MS), which allows mobile access to packet-switched - Mobile Station (MS), which allows mobile access to packet-switched
skipping to change at page 8, line 17 skipping to change at page 9, line 14
- Radio Access Network, which consists of the Base Station - Radio Access Network, which consists of the Base Station
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]) reach the Opened state. When these states are reached in
PPP, a link up event notification must be delivered to the IP-layer. PPP, a link up event notification MUST be delivered to the IP-layer.
When the PPP is used for 3GPP2 Simple (i.e., non-Mobile) IPv4 When the PPP is used for 3GPP2 Simple (i.e., non-Mobile) IPv4
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 and remote end-points 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 (hence it is not provided as auxiliary for DNA (nevertheless it MAY be provided as auxiliary information for
information). other uses).
IPCP/IPV6CP termination, or the underlying LCP or NCP reaching Closed IPCP/IPV6CP termination, or the underlying LCP or NCP reaching Closed
State signify the end of corresponding IP service on the PPP link. State signify the end of corresponding IP service on the PPP link.
This event must generate a link down notification delivered to the This event MUST generate a link down notification delivered to the
IP-layer. IP-layer.
2.3 IEEE 802.11/WiFi 2.3 IEEE 802.11/WiFi
IEEE 802.11-based WiFi networks are the wireless extension of the IEEE 802.11-based WiFi networks are the wireless extension of the
Local Area Networks. Currently available standards are IEEE 802.11b Local Area Networks. Currently available standards are IEEE 802.11b
[IEEE-802.11b], IEEE 802.11g [IEEE-802.11g], and IEEE 802.11a [IEEE-802.11b], IEEE 802.11g [IEEE-802.11g], and IEEE 802.11a [IEEE-
[IEEE-802.11a]. The specifications define both the MAC-layer and the 802.11a]. The specifications define both the MAC-layer and the
physical-layer. The MAC layer is the same for all these physical-layer. The MAC layer is the same for all these
technologies. technologies.
Two operating modes are available in the IEEE 802.11 series, either Two operating modes are available in the IEEE 802.11 series, either
infrastructure mode or ad-hoc mode. In infrastructure mode, all infrastructure mode or ad-hoc mode. In infrastructure mode, all
link-layer frames are transmitted to an access point (AP) which then link-layer frames are transmitted to an access point (AP) which then
forwards them to the final receiver. A STA must establish a IEEE forwards them to the final receiver. A station (STA) MUST establish
802.11 link with an AP in order to send and receive IP packets. In a a IEEE 802.11 link with an AP in order to send and receive IP
WiFi network that supports Robust Secure Network (RSN packets. In a WiFi network that supports Robust Secure Network (RSN
[IEEE-802.11i]), successful completion of 4-way handshake between the [IEEE-802.11i]), successful completion of 4-way handshake between the
STA and AP commences the availability of IP service. The link up STA and AP commences the availability of IP service. The link up
event notification must be generated upon this event. In event notification MUST be generated upon this event. In non-RSN-
non-RSN-based networks, successful association or re-association based networks, successful association or re-association events on
events on the link-layer must cause a link up notification sent to the link-layer MUST cause a link up notification sent to the IP-
the IP-layer. layer.
As part of the link establishment, Basic Service Set Identification As part of the link establishment, Basic Service Set Identification
(BSSID) and Service Set Identifier (SSID) associated with the AP is (BSSID) and Service Set Identifier (SSID) associated with the AP is
learned by the STA. BSSID is a unique identifier of the AP. Its learned by the STA. BSSID is a unique identifier of the AP, usually
value is set to the MAC address of the AP. SSID carries the set to the MAC address of the wireless interface of the AP. SSID
identifier of the Extended Service Set (ESS) - the set composed of carries the identifier of the Extended Service Set (ESS) - the set
APs and associated STAs that share a common distribution system. composed of APs and associated STAs that share a common distribution
BSSID and SSID should be provided as auxiliary information along with system. BSSID and SSID MUST be provided as auxiliary information
the link up notification. Unfortunately this information does not along with the link up notification. Unfortunately this information
provide a deterministic indication of whether the IP-layer does not provide a deterministic indication of whether the IP-layer
configuration must be changed upon movement. There is no configuration MUST be changed upon movement. There is no standards-
standards-mandated one-to-one relation between the BSSID/SSID pairs mandated one-to-one relation between the BSSID/SSID pairs and IP
and IP subnets. An AP with a given BSSID can connect a STA to any subnets. An AP with a given BSSID can connect a STA to any one of
one of more than one IP subnets. Similarly, an ESS with the given multiple IP subnets. Similarly, an ESS with the given SSID may span
SSID may span multiple IP subnets. And finally, the SSIDs are not multiple IP subnets. And finally, the SSIDs are not globally unique.
globally unique. The same SSID may be used by multiple independent The same SSID may be used by multiple independent ESSs. See Appendix
ESSs. See Appendix A of [DNA4] for a detailed discussion. A of [DNA4] for a detailed discussion. Nevertheless, BSSID/SSID
Nevertheless, BSSID/SSID information may be used in a probabilistic information may be used in a probabilistic way by the DNA process,
way by the DNA process, hence it is provided with the link up event hence it is provided with the link up event notification.
notification.
Disassociation event in RSN-based, and de-authentication and Disassociation event in RSN-based, and de-authentication and
disassociation events in non-RSN-based WiFi networks must translate disassociation events in non-RSN-based WiFi networks MUST translate
to link down events, and generate the corresponding link-layer to link down events, and generate the corresponding link-layer
notifications. notifications.
In ad-hoc mode, mobile station (STA) in range may directly In ad-hoc mode, mobile station (STA) in range may directly
communicate with others, i.e., without any infrastructure or communicate with others, 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
Indepedant Basic Service Set. In an IBSS, only station 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 authentication even in state 1 (unauthenticated and unassociated) if the
is not used. Although a link up indication can be generated upon Distribution System is not used (i.e., "To DS" and "From DS" bits are
authentication, one may not be present per latter usage. If clear). If authentication is performed, a link up indication can be
authentication is performed, a deauthentication event is used for generated upon authentication, and a link down indication can be
generating the link down indication. 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
IEEE 802.3 CSMA/CD (commonly referred to as Ethernet) is the most
commonly deployed Local Area Network technology in use today. As
deployed today, it is specified by both a physical layer/medium
access control (MAC) layer specification [IEEE-802.3]. In order to
provide connection of different LANs together into a larger network,
802.3 LANs are often bridged together [IEEE-802.1D].
In this section, the terms 802.3 and Ethernet are used
interchangeably. This section describes some issues in providing
link-layer indications on Ethernet networks, and shows how bridging
affects these indications.
In Ethernet networks, hosts are connected by wires or by optic fibre
to a switch (bridge), a bus (e.g., co-axial cable), a repeater (hub),
or directly to another Ethernet device. Interfaces are symmetric, in
that while many different physical layers may be present, medium
access control is uniform for all devices.
In order to determine whether the physical medium is ready for frame
transfer, IEEE 802.3 Ethernet specifies its own link monitoring
mechanism, which is defined for some, but not all classes of media.
Where available, this Link Integrity Test operation is used to
identify when packets are able to be received on an Ethernet segment.
It is applicable to both wired and optical physical layers, although
details vary between technologies (link pulses in twisted pair
copper, light levels in fibre).
2.4.1 Link Integrity Tests in 802.3 Networks
Link Integrity Tests in 802.3 networks typically occur at initial
physical connection time (for example, at the auto-negotiation
stage), and periodically afterwards. It makes use of physical-layer
specific operations to determine if a medium is able to support link-
layer frames [IEEE-802.3].
The status of the link as determined by the Link Integrity Test is
stored in the variable 'link_status'. Changes to the value of
link_status (for example due to Link Integrity Test failure) will
generate link indications if the technology dependent interface is
implemented on an Ethernet device [IEEE-802.3].
The link_status has possible values of FAIL, READY and OK. When an
interface is in FAIL state, Link Integrity Tests have failed. Where
status is READY, the link segment has passed integrity tests, but
autonegotiation has not completed. OK state indicates that the
medium is able to send and receive packets.
Upon transition to a particular state the Physical Medium Attachment
subsystems generates a PMA_LINK.indicate(link_status). Indications
of OK state MAY be used to generate a link up event notification.
This indication do not definitively ensure that packets will be able
to be received through the bridge domain, though [see the next
section]. Such operations are governed by bridging.
PMA_LINK.indicate(FAIL) MUST be used to generate a link down
notification.
2.4.2 IEEE 802.1D Bridging and Its Effects on Link-layer Event
Notifications
Ethernet networks commonly consist of LANs joined together by
transparent bridges (usually implemented as switches). Tranparent
bridges require the active topology to be loop free. The Spanning
Tree Protocol (STP) achieves this by the exchange of Bridge Protocol
Data Unit (BPDU), as defined in [IEEE-802.1D], which leads to, where
required, the blocking of ports (i.e., not forwarding).
By default, the spanning tree protocol does not know whether a
particular newly connected piece of Ethernet will cause a loop.
Therefore it will block all traffic from and to newly connected ports
with the exception of some unbridged management frames. The STP will
determine if the port can be connected to the network in a loop-free
manner.
For these technologies, even though the link-layer appears available,
no data packet forwarding will occur until it is determined that the
port can be connected to the network in a loop-free environment.
For hosts which are providing indications to upper layer protocols,
even if the host itself does not implement bridging or STP, packet
delivery across the network can be affected by the presence of
bridges.
Where the host is not running STP itself, no explicit indication that
forwarding has begun is sent from a bridge. Therefore, a host may
not know when STP operations have completed, and when it is safe to
inform upper layers to transmit packets.
Where it is not known that forwarding operations are available, a
host needs to assume that STP is being performed, and may indicate
full connectivity only based on timeouts or reception of BPDUs.
Most hosts today do not listen to BPDU frames. For these hosts,
connectivity to the a port which is potentially bridged (any Ethernet
port) carries the potential of frame loss if transmissions occur
before any bridges' ForwardDelay timers have expired twice. This
timeout defaults to 30 seconds (2 * 15 seconds), but may be as high
as 60s [IEEE-802.1D]. When sending indications to upper layers, the
period where frame forwarding is potentially unavailable should be
indicated to upper-layer protocols.
Alternatively, a host can listen for BPDUs and use them to determine
the length of port blockage which will occur in their particular
circumstances.
In either case, as soon as link_status becomes OK a link up
notification with the attribute (R-flag) that indicates the risk of
packet loss MAY be sent.
Upon learning that an adjacent port is running STP or RSTP, the host
MUST send a link up notification upon expiry of calculated delays to
indicate that general packet transfer is available across the LAN.
If no bridge configuration messages are received within the
Bridge_Max_Age interval (default 20s), then it is likely that there
is no visible bridge whose port is enabled for bridging (S8.4.5 of
[IEEE-802.1D]), since at least two BPDU hello messages would have
been lost. Upon this timeout, a link up notification MUST be
generated.
It is not easy for a non-STP host to distinguish between Disabled
bridge ports and non-bridge ports with no IP nodes on them, as
Disabled ports will have no traffic on them, and incur 100% sender
loss.
Upon this Bridge_Max_Age timeout, a link up notification must be
generated. If an earlier link up was generated with the R-flag set,
this new one MUST set the A-flag showing that packets sent within the
prior interval were likely to have traversed the forwarding path
(unless the port is disabled).
If a BPDU is received, and the adjacent bridge is running the
original Spanning Tree Protocol, then a host cannot successfully send
packets until at least twice the ForwardDelay value in the received
BPDU has elapsed. After this time, a link up notification MUST be
generated. If the previous link up notification had the R-flag set,
then the B-flag) MUST be set in this notification. The B-flag
signifies that the packets sent within the prior interval were lost.
If the bridge is identified as performing Rapid Spanning Tree
Protocol (RSTP), it instead waits Bridge_Max_Age after packet
reception (advertised in the BPDU's Max Age field), before
forwarding. For ports which are known to be point-to-point through
autonegotiation, this delay is abbreviated to 3 seconds after
autonegotiation completes [IEEE-802.1D].
2.4.3 802.1AB Link-Layer Discovery Protocol
The recently defined 802.1AB Link-Layer Discovery Protocol (LLDP)
provides information to devices which are directly adjacent to them
on the local LAN [IEEE-802.1ab].
LLDP sends information periodically, and at link status change time
to indicate the configuration parameters of the device. Devices may
either send or receive these messages, or both.
The LLDP message may contain a System Capabilities TLV, which
describes the MAC and IP layer functions which a device is currently
using. Where a host receives the Systems Capabilities TLV which
indicate that no Bridging or Repeating is occurring on the LLDP
transmitter, then no delays for STP calculation will be applied to
packets sent through this transmitter, if the host does not perform
STP itself. This would allow the generation of a link up
notification.
Additionally, if a host receives a Systems Capabilities TLV which
indicates that the LLDP transmitter is a bridge, the host's
advertisement that it is an (end-host) Station-Only, may tell the
bridge not to run STP, and immediately allow forwarding.
Proprietary extensions may also indicate that data forwarding is
already available on such a port. Discussion of such optimizations
is out-of-scope for this document.
Due to the protocol's newness and lack of deployment, it is unclear
how this protocol will eventually affect DNA in IPv4 or IPv6
networks.
2.4.4 Summary
Link-Layer indications in Ethernet-like networks are complicated by
additional unadvertised delays due to Spanning Tree calculations.
This may cause re-indication (link up with A-flag) or retraction
(link up with B-flag) of indications previously sent to upper layer
protocols.
3. IANA Considerations 3. IANA Considerations
This document has no actions for IANA. This document has no actions for IANA.
4. Security Considerations 4. Security Considerations
A faked link-layer event notification can be used to launch a 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. Acknowledgements 5. Contributors
Text for the specific link-layer technologies covered by this
document are contributed by Eric Njedjou (GPRS), Siva Veerepalli
(cdma2000), Nicolas Montavont (IEEE 802.11b), Thomas Noel (IEEE
802.11b), and Greg Daley (IEEE 802.3).
6. Acknowledgements
The authors would like to acknowledge Bernard Aboba, Sanjeev Athalye, The authors would like to acknowledge Bernard Aboba, Sanjeev Athalye,
JinHyeock Choi, Greg Daley, Pekka Nikander, and Muhammad Mukarram bin JinHyeock Choi, John Loughney, Pekka Nikander, Tom Petch, Dan
Tariq for their useful comments and suggestions. Romascanu, Pekka Savola, and Muhammad Mukarram bin Tariq for their
useful comments and suggestions.
6. References 7. References
6.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] [I-D.ietf-dna-goals]
Choi, J., "Detecting Network Attachment in IPv6 Goals", Choi, J., "Goals of Detecting Network Attachment in IPv6",
draft-ietf-dna-goals-04 (work in progress), December 2004. 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 -
Telecomunications and information exchange between systems Telecomunications and information exchange between systems
- Local and metropolitan area networks - Specific - Local and metropolitan area networks - Specific
requirements - Part 11: Wireless Lan Medium Access Control requirements - Part 11: Wireless Lan Medium Access Control
(MAC) And Physical Layer (PHY) Specifications", IEEE (MAC) And Physical Layer (PHY) Specifications",
Standard 802.11b, August 1999. IEEE Standard 802.11b, August 1999.
[IEEE-802.11g] [IEEE-802.11g]
Institute of Electrical and Electronics Engineers, "IEEE Institute of Electrical and Electronics Engineers, "IEEE
Std 802.11g-2003, Amendment to IEEE Std 802.11, 1999 Std 802.11g-2003, Amendment to IEEE Std 802.11, 1999
edition, Part 11: Wireless MAN Medium Access Control (MAC) edition, Part 11: Wireless MAN Medium Access Control (MAC)
and Physical Layer (PHY) specifications. Amendment 4: and Physical Layer (PHY) specifications. Amendment 4:
Further Higher Data Rate Extension in the 2.4 GHz Band", Further Higher Data Rate Extension in the 2.4 GHz Band",
IEEE Standard 802.11g, June 2003. IEEE Standard 802.11g, June 2003.
[IEEE-802.11i] [IEEE-802.11i]
Institute of Electrical and Electronics Engineers, "Draft 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 Specific
Requirements - Part 11: Wireless Medium Access Control Requirements - Part 11: Wireless Medium Access Control
(MAC) and physical layer (PHY) specifications: (MAC) and physical layer (PHY) specifications:
Specification for Enhanced Security", IEEE Draft 802.11I/ Specification for Enhanced Security", IEEE IEEE 802.11i,
D8, February 2004. December 2004.
[IEEE-802.1D]
Institute of Electrical and Electronics Engineers, "IEEE
standard for local and metropolitan area networks - common
specific ations - Media access control (MAC) Bridges",
ISO/IEC IEEE Std 802.1D, 2004.
[IEEE-802.1ab]
Institute of Electrical and Electronics Engineers, "Draft
Standard for Local and Metropolitan Networks: Station and
Media Access Control Connectivity Discovery (Draft 13)",
IEEE draft Std 802.1AB, 2004.
[IEEE-802.3]
Institute of Electrical and Electronics Engineers, "IEEE
standard for local and metropolitan area networks -
Specific Require ments, Part 3: Carrier Sense Multiple
Access with Collision Detection (CSMA/CD) Access Method
and Physical Layer Specifications", ISO/IEC IEEE
Std 802.3, 2002.
[RFC1332] McGregor, G., "The PPP Internet Protocol Control Protocol [RFC1332] McGregor, G., "The PPP Internet Protocol Control Protocol
(IPCP)", RFC 1332, May 1992. (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)", STD 51,
RFC 1661, July 1994. RFC 1661, July 1994.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[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", RFC [RFC2472] Haskin, D. and E. Allen, "IP Version 6 over PPP",
2472, December 1998. RFC 2472, December 1998.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
M. Carney, "Dynamic Host Configuration Protocol for IPv6 and M. Carney, "Dynamic Host Configuration Protocol for
(DHCPv6)", RFC 3315, July 2003. IPv6 (DHCPv6)", RFC 3315, July 2003.
6.2 Informative References 7.2 Informative References
[GPRS-CN] "Technical Specification Group Core Network; [GPRS-CN] "Technical Specification Group Core Network;
Internetworking between the Public Land Mobile Network Internetworking between the Public Land Mobile Network
(PLMN) supporting packet based services and Packet Data (PLMN) supporting packet based services and Packet Data
Networks (PDN) (Release 6)", 3GPP 3GPP TS 29.061 version Networks (PDN) (Release 6)", 3GPP 3GPP TS 29.061 version
6.1.0 2004-06. 6.1.0 2004-06.
[GPRS-GSSA] [GPRS-GSSA]
"Technical Specification Group Services and System Aspect; "Technical Specification Group Services and System Aspect;
General Packet Radio Service (GPRS) Service description; General Packet Radio Service (GPRS) Service description;
skipping to change at page 14, line 51 skipping to change at page 21, line 23
[I-D.ietf-mipshop-fast-mipv6] [I-D.ietf-mipshop-fast-mipv6]
Koodli, R., "Fast Handovers for Mobile IPv6", Koodli, R., "Fast Handovers for Mobile IPv6",
draft-ietf-mipshop-fast-mipv6-03 (work in progress), draft-ietf-mipshop-fast-mipv6-03 (work in progress),
October 2004. October 2004.
[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-09 (work in draft-ietf-mobileip-lowlatency-handoffs-v4-09 (work in
progress), June 2004. progress), June 2004.
[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, December Discovery for IP Version 6 (IPv6)", RFC 2461,
1998. December 1998.
Authors' Addresses Author's Address
Alper E. Yegin (editor) Alper E. Yegin (editor)
Samsung Advanced Institute of Technology Samsung Advanced Institute of Technology
75 West Plumeria Drive 75 West Plumeria Drive
San Jose, CA 95134 San Jose, CA 95134
USA USA
Phone: +1 408 544 5656 Phone: +1 408 544 5656
EMail: alper.yegin@samsung.com Email: alper.yegin@samsung.com
Eric Njedjou
France Telecom
4, Rue du Clos Courtel BP 91226
Cesson-SȨvignȨ, 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
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
Thomas Noel
LSIIT - University Louis Pasteur
Pole API, bureau C428
Boulevard Sebastien Brant
Illkirch, 67400
France
Phone: +33 390 244 592
EMail: noel@dpt-info.u-strasbg.fr
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 change were made on draft version 01:
- Text for IEEE 802.3 added.
- Multiple 3GPP PDP Contexts scenario clarified.
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
 End of changes. 

This html diff was produced by rfcdiff 1.25, available from http://www.levkowetz.com/ietf/tools/rfcdiff/