[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 RFC 4957

Network Working Group                                      A. Yegin, Ed.
Internet-Draft                                               Samsung AIT
Expires: August 11, 2005                                      E. Njedjou
                                                          France Telecom
                                                           S. Veerepalli
                                                                Qualcomm
                                                            N. Montavont
                                                                 T. Noel
                                        LSIIT - University Louis Pasteur
                                                       February 10, 2005


    Link-layer Event Notifications for Detecting Network Attachments
                 draft-ietf-dna-link-information-01.txt

Status of this Memo

   By submitting this Internet-Draft, I certify that any applicable
   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
   RFC 3668.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as
   Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on August 11, 2005.

Copyright Notice

   Copyright (C) The Internet Society (2005).  All Rights Reserved.

Abstract

   Certain network access technologies are capable of providing various
   link-layer status information to IP.  Link-layer event notifications
   can help IP expeditiously detect configuration changes.  This draft



Yegin, et al.           Expires August 11, 2005                 [Page 1]


Internet-Draft          L2 Notifications for DNA           February 2005


   provides a non-exhaustive catalogue of information available from
   well-known access technologies.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1   Requirements notation  . . . . . . . . . . . . . . . . . .  4
   2.  Link-Layer Event Notifications . . . . . . . . . . . . . . . .  5
     2.1   GPRS/3GPP  . . . . . . . . . . . . . . . . . . . . . . . .  6
     2.2   cdma2000/3GPP2 . . . . . . . . . . . . . . . . . . . . . .  7
     2.3   IEEE 802.11/WiFi . . . . . . . . . . . . . . . . . . . . .  8
   3.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 10
   4.  Security Considerations  . . . . . . . . . . . . . . . . . . . 11
   5.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
   6.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
   6.1   Normative References . . . . . . . . . . . . . . . . . . . . 13
   6.2   Informative References . . . . . . . . . . . . . . . . . . . 14
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 15
   A.  Change History . . . . . . . . . . . . . . . . . . . . . . . . 17
       Intellectual Property and Copyright Statements . . . . . . . . 18































Yegin, et al.           Expires August 11, 2005                 [Page 2]


Internet-Draft          L2 Notifications for DNA           February 2005


1.  Introduction

   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
   (e.g., a mobile phone moving among base stations) or nomadic usage
   (e.g., road-warrior case).

   A node changing its point-of attachment to the network may end up
   changing its IP subnet and therefore require re-configuration of
   IP-layer parameters, such as IP address, default gateway information,
   and DNS server address.  Detecting the subnet change can usually use
   network-layer indications such as a change in the advertised prefixes
   (i.e., appearance and disappearance of prefixes).  But generally
   reliance on such indications does not yield rapid detection, since
   these indications are not readily available upon node changing its
   point of attachment.

   The changes on the underlying link-layer status can be relayed to IP
   in the form of link-layer event notifications.  Establishment and
   tear down of a link-layer connection are two basic events types.
   Additional information can be conveyed in addition to the event type,
   such as the identifier of the network attachment point, or
   network-layer configuration parameters obtained via the link-layer
   attachment process.  It is envisaged that such event notifications
   can in certain circumstances be used to expedite the inter-subnet
   movement detection and reconfiguration process.  For example, the
   notification indicating that the node has established a new
   link-layer connection can be used for immediately probing the network
   for a possible configuration change.  In the absence of such a
   notification from the link-layer, IP has to wait for indications that
   are not immediately available, such as receipt of next scheduled
   router advertisement, unreachability of the default gateway, etc.

   It should be noted that a link-layer event notification does not
   always translate into a subnet change.  Even if the node has torn
   down a link-layer connection with one attachment point and
   established a new connection with another, it may still be attached
   to the same IP subnet.  For example, several IEEE 802.11 access
   points can be attached to the same IP subnet.  Moving among these
   access points does not warrant any IP-layer configuration change.

   In order to enable an enhanced scheme for detecting change of subnet,
   we need to define link-layer event notifications that can be
   realistically expected from various access technologies.  The
   objective of this draft is to provide a catalogue of link-layer
   events and notifications in various architectures.  While this
   document mentions the utility of this information for detecting
   change of subnet (or, detecting network attachment - DNA), the



Yegin, et al.           Expires August 11, 2005                 [Page 3]


Internet-Draft          L2 Notifications for DNA           February 2005


   detailed usage is left to other documents, namely DNA solution
   specifications.

   The document limits itself to the minimum set of information that is
   necessary for solving the DNA problem [I-D.ietf-dna-goals].  A
   broader set of information may be used for other problem spaces
   (e.g., anticipation-based Mobile IP fast handovers
   [I-D.ietf-mobileip-lowlatency-handoffs-v4]
   [I-D.ietf-mipshop-fast-mipv6]).  Separate documents that are
   backward-compatible with this one can be generated to discuss further
   enhancements.

   These event notifications are considered with hosts in mind, although
   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
   be defined between the link-layer and IP for conveying this
   information.  That activity is beyond the scope of this document.

1.1  Requirements notation

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].




























Yegin, et al.           Expires August 11, 2005                 [Page 4]


Internet-Draft          L2 Notifications for DNA           February 2005


2.  Link-Layer Event Notifications

   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
   (e.g., presence of advertised prefixes, reachability of default
   gateways) before determining whether IP-layer configuration must be
   updated.  It is expected that the DNA process can take advantage of
   link-layer notifications when they are made available to IP.  While
   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
   collect further information (i.e., other inputs to the process).  For
   example, the node may send a router solicitation as soon as it learns
   that a new link-layer connection is established.

   Two basic link-layer events are considered potentially useful to DNA
   process: link up and link down.  Both of these events are
   deterministic, and their notifications are provided to IP-layer after
   the events successfully conclude.  These events and notifications are
   associated with a network interface on the node.  The IP module may
   receive simultaneous independent notifications from each one of the
   network interfaces on the node.

   Node's establishment of a link-layer connection with an attachment
   point that signifies the availability of IP service (i.e., being able
   to send and receive IP packets) between the two is considered a link
   up event.  The attachment point is typically an access network
   element, such as an access point, a base station, or a wired switch
   [TO-DO: How about ad-hoc networks? Attached neighbors may be
   considered attachment points].

   The actual event is managed by the link-layer of the node through
   execution of link-layer protocols and mechanisms.  Once the event
   successfully completes within the link-layer, its notification must
   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
   packets from the IP and the physical-layers.

   Link down event signifies the discontinuation of the IP service
   between the node and the attachment point.  When the link-layer
   connection is physically or logically torn down and it can no longer
   carry IP 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



Yegin, et al.           Expires August 11, 2005                 [Page 5]


Internet-Draft          L2 Notifications for DNA           February 2005


   interface is disabled, this must generate a link down event.  Each
   one of these events must generate a notification in order they occur.

   A node may have to change its IP-layer configuration even when the
   link-layer connection stays the same.  An example scenario is the
   IPv6 subnet renumbering [RFC2461].  Therefore, there exists cases
   where IP-layer configuration may have to change even without the
   IP-layer receiving a link up notification.  Therefore, a link-layer
   notification is not a mandatory indication of a subnet change.

   In addition to the type of the event (link up, link down), a
   link-layer notification may also optionally deliver information
   relating to the attachment point.  Such auxiliary information may
   include identity of the attachment point (e.g., base station
   identifier), or the IP-layer configuration parameters associated with
   the attached subnet (e.g., subnet prefix, default gateway address,
   etc.).  While merely knowing that a new link-layer connection is
   established may prompt DNA process to immediately seek other clues
   for detecting network configuration change, auxiliary information may
   constitute further clues (and even the final answers sometimes).  In
   cases where there is a one-to-one mapping between the attachment
   point identifiers and the IP-layer configurations, learning the
   former can reveal the latter.  Furthermore, IP-layer configuration
   parameters obtained during link-layer connection may be exactly what
   the DNA process is trying to discover (e.g., IP address configured
   during PPP link establishment).

   The link-layer process leading to a link up or link down event
   depends on the link technology.  While a link-layer notification must
   always indicate the event type, the availability and types of
   auxiliary information on the attachment point depends on the
   link-layer technology as well.  The following subsections examine
   three link-layer technologies and describe when a link-layer
   notification must be generated and what information must be included
   in it.  The coverage on the link types may be expanded in the future
   [TO-DO: Add IEEE 802.3].

2.1  GPRS/3GPP

   GPRS is an enhancement to the GSM data transmission architecture and
   capabilities, designed to allow for packet switching in user data
   transmission within the GPRS network as well as for higher quality of
   service for the IP traffic of Mobile Terminals with external Packets
   Data Networks such as the Internet or corporate LANs
   [GPRS][GPRS-LINK].

   The GPRS architecture consists of a Radio Access Network and a packet
   domain Core Network.



Yegin, et al.           Expires August 11, 2005                 [Page 6]


Internet-Draft          L2 Notifications for DNA           February 2005


   - The GPRS Radio Access Network is composed of Mobile Terminals (MT),
   a Base Station Subsystem and Serving GPRS Support Nodes (SGSN).

   - An IP Core Network that acts as the transport backbone of user
   datagrams between SGSNs and Gateway GPRS Support Nodes (GGSN).  The
   GGSN ensures the GPRS IP core network connectivity with external
   networks, such as Internet or Local Area Networks.  GGSN acts as the
   default IP gateway for the MT.

   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
   request the GPRS network to settle the necessary soft state mechanism
   (GPRS tunneling protocol) between its serving SGSN and the GGSN.  The
   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
   service for the IP flows exchanged between the GPRS MT and an
   external Packet Data Network such as Internet .  It is only after the
   PDP Context has been established, address autoconfiguration and
   tunneling mechanism have taken place that the MT's IP packets can be
   forwarded to and from its remote IP peers.  The aim of PDP Context
   establishment is also to provide IP-level configuration on top of the
   GPRS link-layer attachment.

   Successful establishment of a PDP Context on a GPRS 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
   notification MUST be the IPv4 address of the MT which is obtained as
   part of the PDP Context.  With IPv6, the PDP Context activation
   response does not come along with a usable IPv6 address.
   Effectively, the IPv6 address received from the GGSN in the PDP
   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
   notification.

2.2  cdma2000/3GPP2

   cdma2000-based 3GPP2 packet data services provide mobile users wide
   area high-speed access to packet switched networks [CDMA2K].  Some of
   the major components of the 3GPP2 packet network architecture consist
   of:




Yegin, et al.           Expires August 11, 2005                 [Page 7]


Internet-Draft          L2 Notifications for DNA           February 2005


   - Mobile Station (MS), which allows mobile access to packet-switched
   networks over a wireless connection.

   - Radio Access Network, which consists of the Base Station
   Transceivers, Base Station Controllers, and the Packet Control
   Function.

   - Network Access Server known as the Packet Data Switching Node
   (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
   link-layer protocol between the MS and the PDSN.  Before any IP
   packets may be sent or received, PPP must reach the Network-Layer
   Protocol phase, and the IP Control Protocol (IPCP [RFC1332], IPV6CP
   [RFC2472]) reach the Opened state.  When these states are reached in
   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
   Service, IPCP enables configuration of IPv4 address on the MS.  This
   IPv4 address must be provided as the auxiliary information along with
   the link up notification.  IPV6CP used for Simple IPv6 service does
   not provide an IPv6 address, but  the interface-identifiers for local
   and remote end-points of the PPP link.  Since there is no
   standards-mandated correlation between the interface-identifier and
   other IP-layer configuration parameters, this information is deemed
   not useful for DNA (hence it is not provided as auxiliary
   information).

   IPCP/IPV6CP termination, or the underlying LCP or NCP reaching Closed
   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
   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.11a].  The specifications define both the MAC-layer and the
   physical-layer.  The MAC layer is the same for all these
   technologies.

   Two operating modes are available in the IEEE 802.11 series, either
   infrastructure mode or ad-hoc mode.  In infrastructure mode, all
   link-layer frames are transmitted to an access point (AP) which then
   forwards them to the final receiver.  A STA must establish a IEEE
   802.11 link with an AP in order to send and receive IP packets.  In a
   WiFi network that supports Robust Secure Network (RSN



Yegin, et al.           Expires August 11, 2005                 [Page 8]


Internet-Draft          L2 Notifications for DNA           February 2005


   [IEEE-802.11i]), successful completion of 4-way handshake between the
   STA and AP commences the availability of IP 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
   (BSSID) and Service Set Identifier (SSID) associated with the AP is
   learned by the STA.  BSSID is a unique identifier of the AP.  Its
   value is set to the MAC address of the AP.  SSID carries the
   identifier of the Extended Service Set (ESS) - the set composed of
   APs and associated STAs that share a common distribution system.
   BSSID and SSID should be provided as auxiliary information along with
   the link up notification.  Unfortunately this information does not
   provide a deterministic indication of whether the IP-layer
   configuration must be changed upon movement.  There is no
   standards-mandated one-to-one relation between the BSSID/SSID pairs
   and IP subnets.  An AP with a given BSSID can connect a STA to any
   one of more than one IP subnets.  Similarly, an ESS with the given
   SSID may span multiple IP subnets.  And finally, the SSIDs are not
   globally unique.  The same SSID may be used by multiple independent
   ESSs.  See Appendix A of [DNA4] for a detailed discussion.
   Nevertheless, BSSID/SSID information may be used in a probabilistic
   way by the DNA process, hence it is provided with the link up event
   notification.

   Disassociation event in RSN-based, and de-authentication and
   disassociation events in non-RSN-based WiFi networks must translate
   to link down events, and generate the corresponding link-layer
   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.




Yegin, et al.           Expires August 11, 2005                 [Page 9]


Internet-Draft          L2 Notifications for DNA           February 2005


3.  IANA Considerations

   This document has no actions for IANA.
















































Yegin, et al.           Expires August 11, 2005                [Page 10]


Internet-Draft          L2 Notifications for DNA           February 2005


4.  Security Considerations

   A faked link-layer event notification can be used to launch a
   denial-of service attack on the node and the associated network.
   Secure generation and delivery of these notifications must be
   ensured.  This is a subject for link-layer and network stack designs
   and therefore it is outside the scope of this document.












































Yegin, et al.           Expires August 11, 2005                [Page 11]


Internet-Draft          L2 Notifications for DNA           February 2005


5.  Acknowledgements

   The authors would like to acknowledge Bernard Aboba, Sanjeev Athalye,
   JinHyeock Choi, Greg Daley, Pekka Nikander, and Muhammad Mukarram bin
   Tariq for their useful comments and suggestions.














































Yegin, et al.           Expires August 11, 2005                [Page 12]


Internet-Draft          L2 Notifications for DNA           February 2005


6.  References

6.1  Normative References

   [CDMA2K]   "IS-835 - cdma2000 Wireless IP Network Standard",  .

   [GPRS]     "Digital cellular telecommunications system (Phase 2+);
              General Packet Radio Service (GPRS) Service description;
              Stage 2", 3GPP 3GPP TS 03.60 version 7.9.0 Release 98.

   [GPRS-LINK]
              "Digital cellular telecommunications system (Phase 2+);
              Radio subsystem link control", 3GPP GSM 03.05 version
              7.0.0 Release 98.

   [I-D.ietf-dna-goals]
              Choi, J., "Detecting Network Attachment in IPv6 Goals",
              draft-ietf-dna-goals-04 (work in progress), December 2004.

   [IEEE-802.11a]
              Institute of Electrical and Electronics Engineers, "IEEE
              Std 802.11a-1999, supplement to IEEE Std 802.11-1999, Part
              11: Wireless MAN Medium Access Control (MAC) and Physical
              Layer (PHY) specifications: High-speed Physical Layer in
              the 5 GHZ band", IEEE Standard 802.11a, September 1999.

   [IEEE-802.11b]
              Institute of Electrical and Electronics Engineers, "IEEE
              Std 802 Part 11, Information technology -
              Telecomunications and information exchange between systems
              - Local and metropolitan area networks - Specific
              requirements - Part 11: Wireless Lan Medium Access Control
              (MAC) And Physical Layer (PHY) Specifications", IEEE
              Standard 802.11b, August 1999.

   [IEEE-802.11g]
              Institute of Electrical and Electronics Engineers, "IEEE
              Std 802.11g-2003, Amendment to IEEE Std 802.11, 1999
              edition, Part 11: Wireless MAN Medium Access Control (MAC)
              and Physical Layer (PHY) specifications. Amendment 4:
              Further Higher Data Rate Extension in the 2.4 GHz Band",
              IEEE Standard 802.11g, June 2003.

   [IEEE-802.11i]
              Institute of Electrical and Electronics Engineers, "Draft
              Supplement to STANDARD FOR Telecommunications and
              Information Exchange between Systems - LAN/MAN Specific
              Requirements - Part 11: Wireless Medium Access Control



Yegin, et al.           Expires August 11, 2005                [Page 13]


Internet-Draft          L2 Notifications for DNA           February 2005


              (MAC) and physical layer (PHY) specifications:
              Specification for Enhanced Security", IEEE Draft 802.11I/
              D8, February 2004.

   [RFC1332]  McGregor, G., "The PPP Internet Protocol Control Protocol
              (IPCP)", RFC 1332, May 1992.

   [RFC1661]  Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51,
              RFC 1661, July 1994.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2462]  Thomson, S. and T. Narten, "IPv6 Stateless Address
              Autoconfiguration", RFC 2462, December 1998.

   [RFC2472]  Haskin, D. and E. Allen, "IP Version 6 over PPP", RFC
              2472, December 1998.

   [RFC3315]  Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and
              M. Carney, "Dynamic Host Configuration Protocol for IPv6
              (DHCPv6)", RFC 3315, July 2003.

6.2  Informative References

   [GPRS-CN]  "Technical Specification Group Core Network;
              Internetworking between the Public Land Mobile Network
              (PLMN) supporting packet based services and Packet Data
              Networks (PDN) (Release 6)", 3GPP 3GPP TS 29.061 version
              6.1.0 2004-06.

   [GPRS-GSSA]
              "Technical Specification Group Services and System Aspect;
              General Packet Radio Service (GPRS) Service description;
              Stage 2 (Release 6)", 3GPP 3GPP TS 23.060 version 6.5.0
              2004-06.

   [I-D.ietf-mipshop-fast-mipv6]
              Koodli, R., "Fast Handovers for Mobile IPv6",
              draft-ietf-mipshop-fast-mipv6-03 (work in progress),
              October 2004.

   [I-D.ietf-mobileip-lowlatency-handoffs-v4]
              Malki, K., "Low latency Handoffs in Mobile IPv4",
              draft-ietf-mobileip-lowlatency-handoffs-v4-09 (work in
              progress), June 2004.

   [RFC2461]  Narten, T., Nordmark, E. and W. Simpson, "Neighbor



Yegin, et al.           Expires August 11, 2005                [Page 14]


Internet-Draft          L2 Notifications for DNA           February 2005


              Discovery for IP Version 6 (IPv6)", RFC 2461, December
              1998.


Authors' Addresses

   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


   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






Yegin, et al.           Expires August 11, 2005                [Page 15]


Internet-Draft          L2 Notifications for DNA           February 2005


   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










































Yegin, et al.           Expires August 11, 2005                [Page 16]


Internet-Draft          L2 Notifications for DNA           February 2005


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.












































Yegin, et al.           Expires August 11, 2005                [Page 17]


Internet-Draft          L2 Notifications for DNA           February 2005


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   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
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Copyright Statement

   Copyright (C) The Internet Society (2005).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.




Yegin, et al.           Expires August 11, 2005                [Page 18]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/