draft-ietf-dna-link-information-00.txt   draft-ietf-dna-link-information-01.txt 
Network Working Group A. Yegin, Ed. Network Working Group A. Yegin, Ed.
Internet-Draft Samsung AIT Internet-Draft Samsung AIT
Expires: March 24, 2005 E. Njedjou Expires: August 11, 2005 E. Njedjou
France Telecom France Telecom
S. Veerepalli S. Veerepalli
Qualcomm Qualcomm
N. Montavont N. Montavont
T. Noel T. Noel
LSIIT - University Louis Pasteur LSIIT - University Louis Pasteur
September 23, 2004 February 10, 2005
Link-layer Event Notifications for Detecting Network Attachments Link-layer Event Notifications for Detecting Network Attachments
draft-ietf-dna-link-information-00.txt draft-ietf-dna-link-information-01.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, I certify that any applicable By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed, patent or other IPR claims of which I am aware have been disclosed,
and any of which I become aware will be disclosed, in accordance with and any of which I become aware will be disclosed, in accordance with
RFC 3668. RFC 3668.
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 39 skipping to change at page 1, line 40
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 March 24, 2005. This Internet-Draft will expire on August 11, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved. Copyright (C) The Internet Society (2005). All Rights Reserved.
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 draft
provides a non-exhaustive catalogue of information available from provides a non-exhaustive catalogue of information available from
well-known access technologies. well-known access technologies.
Table of Contents Table of Contents
skipping to change at page 2, line 22 skipping to change at page 2, line 22
2.1 GPRS/3GPP . . . . . . . . . . . . . . . . . . . . . . . . 6 2.1 GPRS/3GPP . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2 cdma2000/3GPP2 . . . . . . . . . . . . . . . . . . . . . . 7 2.2 cdma2000/3GPP2 . . . . . . . . . . . . . . . . . . . . . . 7
2.3 IEEE 802.11/WiFi . . . . . . . . . . . . . . . . . . . . . 8 2.3 IEEE 802.11/WiFi . . . . . . . . . . . . . . . . . . . . . 8
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
4. Security Considerations . . . . . . . . . . . . . . . . . . . 11 4. Security Considerations . . . . . . . . . . . . . . . . . . . 11
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
6.1 Normative References . . . . . . . . . . . . . . . . . . . . 13 6.1 Normative References . . . . . . . . . . . . . . . . . . . . 13
6.2 Informative References . . . . . . . . . . . . . . . . . . . 14 6.2 Informative References . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 15
Intellectual Property and Copyright Statements . . . . . . . . 17 A. Change History . . . . . . . . . . . . . . . . . . . . . . . . 17
Intellectual Property and Copyright Statements . . . . . . . . 18
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
skipping to change at page 4, line 11 skipping to change at page 4, line 11
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 may be used for other problem spaces
(e.g., anticipation-based Mobile IP fast handovers (e.g., anticipation-based Mobile IP fast handovers
[I-D.ietf-mobileip-lowlatency-handoff][I-D.ietf-mipshop-fast-mipv6]). [I-D.ietf-mobileip-lowlatency-handoffs-v4]
Separate documents that are backward-compatible with this one can be [I-D.ietf-mipshop-fast-mipv6]). Separate documents that are
generated to discuss further enhancements. backward-compatible with this one can be generated to discuss further
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",
skipping to change at page 7, line 14 skipping to change at page 7, line 14
- 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 MT that wants to establish IP-level connections should first A GPRS MT that wants to establish IP-level connections should first
perform a GPRS attach to the SGSN. This should be followed by a perform a GPRS attach to the SGSN. This should be followed by a
request the GPRS network to settle the necessary soft state mechanism request the GPRS network to settle the necessary soft state mechanism
(GPRS tunneling protocol) between its serving SGSN and the GGSN. The (GPRS tunneling protocol) between its serving SGSN and the GGSN. The
soft state maintained between the MT, the SGSN and the GGSN is called soft state maintained between the MT, the SGSN and the GGSN is called
a PDP Context. It is used for guaranteeing a negotiated quality of a PDP Context. It is used for guaranteeing a negotiated quality of
service for the IP flows exchanged between the GPRS MT and an service for the IP flows exchanged between the GPRS MT and an
external Packet Data Network such as Internet . Only after the PDP external Packet Data Network such as Internet . It is only after the
Context is established and tunneling mechanism takes place can the PDP Context has been established, address autoconfiguration and
MT's IP packets be forwarded to and from its remote IP peers. The tunneling mechanism have taken place that the MT's IP packets can be
aim of PDP Context establishment is also to provide IP-level forwarded to and from its remote IP peers. The aim of PDP Context
configuration on top of the GPRS link-layer attachment. establishment is also to provide IP-level configuration on top of the
GPRS link-layer attachment.
Successful establishment of a PDP Context on a GPRS signifies the Successful establishment of a PDP Context on a GPRS signifies the
availability of IP service to the MT. Therefore, this link-layer availability of IP service to the MT. Therefore, this link-layer
event must generate a link up event notification sent to IP-layer. event must generate a link up event notification sent to IP-layer.
The auxiliary information carried along with this notification must With IPv4, the auxiliary information carried along with this
be the IP address of the MT which is obtained as part of the PDP notification MUST be the IPv4 address of the MT which is obtained as
Context. In case of IPv6, IPv6 address of the MT may be obtained by part of the PDP Context. With IPv6, the PDP Context activation
alternative methods, such as DHCPv6 [RFC3315][GPRS-GSSA] or stateless response does not come along with a usable IPv6 address.
address autoconfiguration [RFC2462][GPRS-CN]. In that case, the IP Effectively, the IPv6 address received from the GGSN in the PDP
address auxiliary information must be set to null. address field of the message does not contain a valid prefix. The MN
actually only uses the interface-identifier extracted from that field
to form a link-local address, that it uses afterwards to obtain a
valid prefix (e.g., by stateless [RFC2462][GPRS-CN] or stateful
[RFC3315][GPRS-GSSA] address configuration). Therefore no
IPv6-related auxiliary information is provided to IP-layer.
Similarly, PDP Context deactivation must generate a link down event Similarly, PDP Context deactivation must generate a link down event
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:
skipping to change at page 8, line 40 skipping to change at page 8, line 47
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-802.11a]. The specifications define both the MAC-layer and the [IEEE-802.11a]. The specifications define both the MAC-layer and the
physical-layer. The MAC layer is the same for all these physical-layer. The MAC layer is the same for all these
technologies. technologies.
Two operating modes are available in the IEEE 802.11 series. In Two operating modes are available in the IEEE 802.11 series, either
ad-hoc mode, mobile station (STA) in range may directly communicate infrastructure mode or ad-hoc mode. In infrastructure mode, all
with other, i.e., without any infrastructure or intermediate hop. In link-layer frames are transmitted to an access point (AP) which then
infrastructure mode, all link-layer frames are transmitted to an forwards them to the final receiver. A STA must establish a IEEE
access point (AP) which then forwards them to the final receiver. 802.11 link with an AP in order to send and receive IP packets. In a
This document only considers infrastructure mode [for now... TO-DO: WiFi network that supports Robust Secure Network (RSN
consider ad-hoc too]. [IEEE-802.11i]), successful completion of 4-way handshake between the
STA and AP commences the availability of IP service. The link up
A STA must establish a IEEE 802.11 link with an AP in order to send event notification must be generated upon this event. In
and receive IP packets. In a WiFi network that supports Robust non-RSN-based networks, successful association or re-association
Secure Network (RSN [IEEE-802.11i]), successful completion of 4-way events on the link-layer must cause a link up notification sent to
handshake between the STA and AP commences the availability of IP the IP-layer.
service. The link up event notification must be generated upon this
event. In non-RSN-based networks, successful association or
re-association events on the link-layer must cause a link up
notification sent to the IP-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. Its
value is set to the MAC address of the AP in infrastructure mode. value is set to the MAC address of the AP. SSID carries the
SSID carries the identifier of the Extended Service Set (ESS) - the identifier of the Extended Service Set (ESS) - the set composed of
set composed of APs and associated STAs that share a common APs and associated STAs that share a common distribution system.
distribution system. BSSID and SSID should be provided as auxiliary BSSID and SSID should be provided as auxiliary information along with
information along with the link up notification. Unfortunately this the link up notification. Unfortunately this information does not
information does not provide a deterministic indication of whether provide a deterministic indication of whether the IP-layer
the IP-layer configuration must be changed upon movement. There is configuration must be changed upon movement. There is no
no standards-mandated one-to-one relation between the BSSID/SSID standards-mandated one-to-one relation between the BSSID/SSID pairs
pairs and IP subnets. An AP with a given BSSID can connect a STA to and IP subnets. An AP with a given BSSID can connect a STA to any
any one of more than one IP subnets. Similarly, an ESS with the one of more than one IP subnets. Similarly, an ESS with the given
given SSID may span multiple IP subnets. And finally, the SSIDs are SSID may span multiple IP subnets. And finally, the SSIDs are not
not globally unique. The same SSID may be used by multiple globally unique. The same SSID may be used by multiple independent
independent ESSs. See Appendix A of [DNA4] for a detailed ESSs. See Appendix A of [DNA4] for a detailed discussion.
discussion. Nevertheless, BSSID/SSID information may be used in a Nevertheless, BSSID/SSID information may be used in a probabilistic
probabilistic way by the DNA process, hence it is provided with the way by the DNA process, hence it is provided with the link up event
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
communicate with others, i.e., without any infrastructure or
intermediate hop. The set of communicating STAs is called IBSS for
Indepedant Basic Service Set. In an IBSS, only station services are
available, i.e. authentication, deauthentication, privacy and MSDU
delivery. STAs do not associate with each other, and therefore may
exchange data frames in state 2 (authenticated and not associated) or
even in state 1 (unauthenticated and unassociated) if authentication
is not used. Although a link up indication can be generated upon
authentication, one may not be present per latter usage. If
authentication is performed, a deauthentication event is used for
generating the link down indication. Concerning the link layer
identification, both the BSSID (which is a random MAC address chosen
by a STA of the IBSS) and SSID may be used to identify a link, but
not to make any assumptions on the IP network configuration.
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
skipping to change at page 13, line 22 skipping to change at page 13, line 22
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., "Detecting Network Attachment in IPv6 Goals",
draft-ietf-dna-goals-01 (work in progress), September draft-ietf-dna-goals-04 (work in progress), December 2004.
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
skipping to change at page 14, line 44 skipping to change at page 14, line 43
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;
Stage 2 (Release 6)", 3GPP 3GPP TS 23.060 version 6.5.0 Stage 2 (Release 6)", 3GPP 3GPP TS 23.060 version 6.5.0
2004-06. 2004-06.
[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-02 (work in progress), July draft-ietf-mipshop-fast-mipv6-03 (work in progress),
2004. October 2004.
[I-D.ietf-mobileip-lowlatency-handoff] [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, December
1998. 1998.
Authors' Addresses Authors' Addresses
skipping to change at page 17, line 5 skipping to change at page 17, line 5
Thomas Noel Thomas Noel
LSIIT - University Louis Pasteur LSIIT - University Louis Pasteur
Pole API, bureau C428 Pole API, bureau C428
Boulevard Sebastien Brant Boulevard Sebastien Brant
Illkirch, 67400 Illkirch, 67400
France France
Phone: +33 390 244 592 Phone: +33 390 244 592
EMail: noel@dpt-info.u-strasbg.fr EMail: noel@dpt-info.u-strasbg.fr
Appendix A. Change History
The following changes were made on draft version 00:
- IEEE 802.11 ad-hoc mode discussion added.
- IPv6 address configuration over 3GPP networks clarified.
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 17, line 41 skipping to change at page 18, 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 (2004). This document is subject Copyright (C) The Internet Society (2005). 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. 

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