[Search] [txt|pdf|bibtex] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 rfc4886                                  
NEMO Working Group                                              T. Ernst
Internet-Draft                                   WIDE at Keio University
Expires: April 25, 2005                                 October 25, 2004



            Network Mobility Support Goals and Requirements
                    draft-ietf-nemo-requirements-03


Status of this Memo


   This document is an Internet-Draft and is subject to all provisions
   of section 3 of RFC 3667.  By submitting this Internet-Draft, each
   author represents that any applicable patent or other IPR claims of
   which he or she is aware have been or will be disclosed, and any of
   which he or she 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 April 25, 2005.


Copyright Notice


   Copyright (C) The Internet Society (2004).


Abstract


   Network mobility arises when a router connecting an entire network to
   the Internet dynamically changes its point of attachment to the
   Internet therefrom causing the reachability of the entire network to
   be changed in the topology.  Such kind of network is referred to as a
   mobile network.  Without appropriate mechanisms, sessions established
   between nodes in the mobile network and the global Internet cannot be
   maintained while the mobile router changes its point of attachment.
   The required support mechanisms will be provided in two phases.  The




Ernst                    Expires April 25, 2005                 [Page 1]


Internet-Draft                 NEMO Goals                   October 2004



   first phase, referred to as NEMO Basic Support is to provide session
   continuity while the necessary optimizations mechanims referred to as
   NEMO Extended Support might be provided later.  This document
   outlines the goals expected from network mobility support and defines
   the requirements that must be met by NEMO Basic Support solutions.


Table of Contents


   1.   Introduction . . . . . . . . . . . . . . . . . . . . . . . .   3


   2.   NEMO Working Group Objectives and Methodology  . . . . . . .   4


   3.   NEMO Support Design Goals  . . . . . . . . . . . . . . . . .   5
     3.1  Migration Transparency . . . . . . . . . . . . . . . . . .   5
     3.2  Performance Transparency and Seamless Mobility . . . . . .   5
     3.3  Network Mobility Support Transparency  . . . . . . . . . .   5
     3.4  Operational Transparency . . . . . . . . . . . . . . . . .   6
     3.5  Arbitrary Configurations . . . . . . . . . . . . . . . . .   6
     3.6  Local Mobility and Global Mobility . . . . . . . . . . . .   7
     3.7  Scalability  . . . . . . . . . . . . . . . . . . . . . . .   7
     3.8  Backward Compatibility . . . . . . . . . . . . . . . . . .   7
     3.9  Secure Signaling . . . . . . . . . . . . . . . . . . . . .   8
     3.10   Location Privacy . . . . . . . . . . . . . . . . . . . .   8
     3.11   IPv4 and NAT Traversal . . . . . . . . . . . . . . . . .   8


   4.   NEMO Basic Support One-Liner Requirements  . . . . . . . . .   8


   5.   Changes Between Versions . . . . . . . . . . . . . . . . . .  10
     5.1  Changes between version -02 and -03  . . . . . . . . . . .  10
     5.2  Changes Between Version -01 and -02  . . . . . . . . . . .  10
     5.3  Changes Between Version -00 and -01  . . . . . . . . . . .  11


   6.   Acknowledgments  . . . . . . . . . . . . . . . . . . . . . .  11


   7.   References . . . . . . . . . . . . . . . . . . . . . . . . .  12


        Author's Address . . . . . . . . . . . . . . . . . . . . . .  12


        Intellectual Property and Copyright Statements . . . . . . .  13













Ernst                    Expires April 25, 2005                 [Page 2]


Internet-Draft                 NEMO Goals                   October 2004



1.  Introduction


   Network mobility support is concerned with managing the mobility of
   an entire network, viewed as a single unit, which changes its point
   of attachment to the Internet and thus its reachability in the
   Internet topology.  Such kind of network is referred to as a mobile
   network and includes one or more mobile routers (MRs) which connect
   it to the global Internet.  Nodes behind the MR(s) (MNNs) are both
   fixed (LFNs) and mobile (VMNs or LMNs).  In most cases, the internal
   structure of the mobile network will in effect be relatively stable
   (no dynamic change of the topology), but this is not a general
   assumption.


   Cases of mobile networks include for instance:


   o  networks attached to people (Personal Area Networks or PANs): a
      cell-phone with one cellular interface and one Bluetooth interface
      together with a Bluetooth-enabled PDA constitute a very simple
      instance of a mobile network.  The cell-phone is the mobile router
      while the PDA is used for web browsing or runs a personal web
      server.


   o  networks of sensors and computers deployed in vehicles: vehicles
      are more and more embedded with a number of processing units for
      safety and ease of driving reasons, as advocated by ITS
      (Intelligent Transportation Systems) applications.


   o  access networks deployed in public transportation (buses, trains,
      taxis, aircrafts): they provide Internet access to IP devices
      carried by passengers (laptop, camera, mobile phone: host mobility
      within network mobility or PANs: network mobility within network
      mobility, i.e.  nested mobility).


   o  ad-hoc networks connected to the Internet via a MR: for instance
      students in a train that both need to set up an ad-hoc network
      among themselves and to get Internet connectivity through the MR
      connecting the train to the Internet.


   Mobility of networks does not cause MNNs to change their own physical
   point of attachment, however they happen to change their topological
   location with respect to the global Internet.  If network mobility is
   not explicitly supported by some mechanisms, the mobility of the MR
   results into MNNs losing Internet access and breaking ongoing
   sessions entertained between arbitrary correspondent node (CNs) in
   the global Internet and those MNNs located within the mobile network.
   In addition, the communication path between MNNs and arbitrary
   correspondent nodes (CN) becomes sub-optimal, whereas multiple levels
   of mobility will cause extremely sub-optimal routing.




Ernst                    Expires April 25, 2005                 [Page 3]


Internet-Draft                 NEMO Goals                   October 2004



   The mechanisms required for handling such mobility issues are
   currently lacking within the IETF standards.  Traditional work
   conducted on mobility support (particularly in the Mobile IP working
   group) is to provide continuous Internet connectivity and optimal
   routing to mobile hosts only (host mobility support) and are unable
   to support network mobility.  The NEMO working group has therefore
   been set up to deal with issues specific to network mobility.  The
   purpose of this document is thus to detail the methodology that will
   be followed by the NEMO working group, its goals, and to define
   requirements for network mobility support.


   Mobility-related terms used in this document are defined in [3]
   whereas terms pertaining to network mobility specifically are defined
   in [4].  This document is structured as follows: Section 2 defines
   the rough objectives and methodology of the NEMO working group and we
   emphasize the stepwise approach the working group has decided to
   follow.  A number of desirable design goals are listed in Section 3.
   Those design goals serve as guidelines to edict the requirements
   listed in Section 4 for basic network mobility support [2].


2.  NEMO Working Group Objectives and Methodology


   The primary objective of the NEMO work is to specify a solution which
   allows mobile network nodes (MNNs) to remain connected to the
   Internet and continuously reachable at all times while the mobile
   network they are attached to changes its point of attachment.
   Secondary goals of the work is to investigate the effects of network
   mobility on various aspects of internet communication such as routing
   protocol changes, implications of realtime traffic and fast
   handovers, optimizations.  These should all support the primary goal
   of reachability for mobile network nodes.  Security is an important
   consideration too, and efforts should be made to use existing
   solutions if they are appropriate.  Although a well-designed solution
   may include security inherent in other protocols, mobile networks
   also introduce new challenges.


   For doing so, the NEMO working group has decided to take a stepwise
   approach by standardizing a basic solution to preserve session
   continuity (NEMO Basic Support), and at the same time study the
   possible approaches and issues with providing more optimal routing
   with potentially nested mobile networks (NEMO Extended Support).
   However, the working group is not chartered to actually standardize a
   solution to such route optimization at this point in time.


   For NEMO Basic Support, the working group will assume that none of
   the nodes behind the MR will be aware of the network's mobility, thus
   the network's movement needs to be completely transparent to the
   nodes inside the mobile network.  This assumption will be made to




Ernst                    Expires April 25, 2005                 [Page 4]


Internet-Draft                 NEMO Goals                   October 2004



   accommodate nodes inside the network that are not generally aware of
   mobility.


   The efforts of the Mobile IP working group have resulted in the
   Mobile IPv4 and Mobile IPv6 protocols, which have already solved the
   issue of host mobility support.  Since challenges to enabling mobile
   networks are vastly reduced by this work, basic network mobility
   support will adopt the methods for host mobility support used in
   Mobile IP, and extend them in the simplest way possible to achieve
   its goals.  The basic support solution is for each MR to have a Home
   Agent, and use bidirectional tunneling between the MR and HA to
   preserve session continuity while the MR moves.  The MR will acquire
   a Care-of-address from its attachment point much like what is done
   for mobile nodes (MN) using Mobile IP.  This approach allows nested
   mobile networks, since each MR will appear to its attachment point as
   a single node.


3.  NEMO Support Design Goals


   This section details the fundamental design goals the solutions will
   tend to achieve.  Those design goals will serve to edict and
   understand the requirements defined for forthcoming solutions.
   Actual requirements for NEMO Basic Support are in the next section,
   whereas NEMO Extended Support has not yet been considered.


3.1  Migration Transparency


   A permanent connectivity to the Internet has to be provided to all
   MNNs while continuous sessions are expected to be maintained as the
   mobile router changes its point of attachment.  For doing so, MNNs
   are expected to be reachable via their permanent IP addresses.


3.2  Performance Transparency and Seamless Mobility


   NEMO support is expected to be provided with limited signaling
   overhead and to minimize the impact of handover over applications, in
   terms of packet loss or delay.  However, although variable delays of
   transmission and losses between MNNs and their respective CNs could
   be perceived as the network is displaced, it would not be considered
   a lack of performance transparency.


3.3  Network Mobility Support Transparency


   MNNs behind the MR(s) don't change their own physical point of
   attachment as a result of the mobile network's displacement in the
   Internet topology.  Consequently, NEMO support is expected to be
   performed by the sole MR(s) and specific support functions on any
   other node than the MR(s) would better be avoided.




Ernst                    Expires April 25, 2005                 [Page 5]


Internet-Draft                 NEMO Goals                   October 2004



3.4  Operational Transparency


   NEMO support is to be implemented at the IP layer level.  It is
   expected to be transparent to upper layers so that any upper layer
   protocol can run unchanged on top of an IP layer extended with NEMO
   support.


3.5  Arbitrary Configurations


   The formation of a mobile network can exist in various levels of
   complexity.  In the simplest case, a mobile network contains just a
   mobile router and a host.  In the most complicated case, a mobile
   network is multihomed and is itself a multi-level aggregation of
   mobile networks with collectively thousands of mobile routers and
   hosts.  While the list of potential configurations of mobile networks
   cannot be limited, at least the following configurations are
   desirable:


   o  mobile networks of any size, ranging from a sole subnet with a few
      IP devices to a collection of subnets with a large number of IP
      devices,


   o  nodes that change their point of attachment within the mobile
      network,


   o  foreign mobile nodes that attach to the mobile network,


   o  multihomed mobile network either when a single MR has multiple
      attachments to the internet, or when the mobile network is
      attached to the Internet by means of multiple MRs (see definition
      in [4] and the analys in [5]),


   o  nested mobile networks (mobile networks attaching to other mobile
      networks (see definition in [4]).  Although the complexity
      requirements of those nested networks is not clear, it is
      desirable to support arbitrary levels of recursive networks, and
      only in the case where this is impractical and protocol concerns
      preclude this support should the solution impose restrictions on
      nesting (e.g.  path MTU),


   o  distinct mobility frequencies (see mobility factor in [3])


   o  distinct access medium.


   In order to keep complexity minimal, transit networks are excluded
   from this list.  A transit network is one in which data would be
   forwarded between two endpoints outside of the network, so that the
   network itself simply serves as a transitional conduit for packet




Ernst                    Expires April 25, 2005                 [Page 6]


Internet-Draft                 NEMO Goals                   October 2004



   forwarding.  A stub network (leaf network), on the other hand, does
   not serve as a data forwarding path.  Data on a stub network is
   either sent by or addressed to a node located within that network.


3.6  Local Mobility and Global Mobility


   Mobile networks and mobile nodes owned by administratively different
   entities are expected to be displaced within a domain boundary or
   between domain boundaries.  Multihoming, vertical and horizontal
   handoffs, and access control mechanisms are desirable to achieve this
   goal.  Such mobility type is not expected to be limited for any
   consideration other than administrative and security policies.


3.7  Scalability


   NEMO support signaling and processing is expected to scale to a
   potentially large number of mobile networks irrespective of their
   configuration, mobility frequency, size and number of CNs.


3.8  Backward Compatibility


   NEMO support will have to co-exist with existing IPv6 standards
   without interfering with them.  Standards defined in other IETF
   working groups have to be reused as much as possible and extended
   only if deemed necessary.  For instance, the following mechanisms
   defined by other working groups are expected to function without
   modidications:


   o  Address allocation and configuration mechanisms


   o  Host mobility support: mobile nodes and correspondent nodes,
      either located within or outside the mobile network are expected
      to keep operating protocols defined by the Mobile IP working
      group.  This include mechanisms for host mobility support (Mobile
      IPv6) and seamless mobility (FMIPv6).


   o  Multicast support entertained by MNNs are expected to be
      maintained while the mobile router changes its point of
      attachment.


   o  Access control protocols and mechanisms used by visiting mobile
      hosts and routers to be authenticated and authorized to gain
      access to the Internet via the mobile network infrastructure
      (MRs).


   o  Security protocols and mechanisms


   o  Mechanisms performed by routers deployed both in the visited




Ernst                    Expires April 25, 2005                 [Page 7]


Internet-Draft                 NEMO Goals                   October 2004



      networks and in mobile networks (routing protocols, Neighbor
      Discovery, ICMP, Router Renumbering, ...).



3.9  Secure Signaling


   NEMO support will have to comply with usual IETF security policies
   and recommendations and is expected to have its specific security
   issues fully addressed.  In practice, all NEMO support control
   messages transmitted in the network will have to ensure an acceptable
   level of security to prevent intruders to usurp identities and forge
   data.  Specifically, the following issues have to be considered:


   o  Authentication of the sender to prevent identity usurpation.


   o  Authorization, to make sure the sender is granted permission to
      perform the operation as indicated in the control message.


   o  Confidentiality of the data contained in the control message.



3.10  Location Privacy


   Means to hide the actual location of MNNS to third parties other than
   the HA are desired.  In which extend this has to be enforced is not
   clear since it is always possible to determine the topological
   location by analysing IPv6 headers.  It would thus require some kind
   of encryption of the IPv6 header to prevent third parties to monitor
   IPv6 addresses between the MR and the HA.  On the other hand, it is
   at the very least desirable to provide means for MNNs to hide their
   real topological location to their CNs.


3.11  IPv4 and NAT Traversal


   IPv4 clouds and NAT are likely to co-exist with IPv6 for a long time,
   so it is desirable to ensure mechanisms developped for NEMO will be
   able to traverse such clouds.


4.  NEMO Basic Support One-Liner Requirements


   The NEMO WG is to specify a unified and unique "Network Mobility
   Basic Support" solution, hereafter referred to as "the solution".
   This solution is to allow all nodes in the mobile network to be
   reachable via permanent IP addresses, as well as maintain ongoing
   sessions as the MR changes its point of attachment to the Internet
   topology.  This is to be done by maintaining a bidirectional tunnel
   between a MR and its Home Agent.





Ernst                    Expires April 25, 2005                 [Page 8]


Internet-Draft                 NEMO Goals                   October 2004



   For doing so, the NEMO Working Group has decided to investigate
   reusing the existing Mobile IPv6 [1] mechanisms for the tunnel
   management, or extend it if deemed necessary.


   The list of requirements below have been placed on the NEMO Basic
   Support solution.  They have been mostly met by the resulting
   specification which can now be found in [2].


      R01: The solution MUST be implemented at the IP layer level.


      R02: The solution MUST set up a bi-directional tunnel between a
      Mobile Router and its Home Agent (MRHA tunnel)


      R03: All traffic exchanged between a MNN and a CN in the global
      Internet MUST transit through the bidirectional MRHA tunnel.


      R04: MNNs MUST be reachable at a permanent IP address and name.


      R05: The solution MUST maintain continuous sessions (both unicast
      and multicast) between MNNs and arbitrary CNs after IP handover of
      (one of) the MR.


      R06: The solution MUST not require modifications to any node other
      than MRs and HAs.


      R07: The solution MUST support fixed nodes, mobile hosts and
      mobile routers in the mobile network.


      R08: The solution MUST allow MIPv6-enabled MNNs to use a mobile
      network link as either a home link or a foreign link.


      R09: The solution MUST ensure backward compatibility with other
      standards defined by the IETF.  This include particularly:


         R09:1: The solution MUST not prevent the proper operation of
         Mobile IPv6 (i.e.  the solution MUST allow MIPv6-enabled MNNs
         to operate either the CN, HA, or MN operations defined in [1])


      R10: The solution MUST treat all the potential configurations the
      same way (whatever the number of subnets, MNNs, nested levels of
      MRs, egress interfaces, ...)


      R11: The solution MUST support at least 2 levels of nested mobile
      networks, while, in principle, arbitrary levels of recursive
      mobile networks SHOULD be supported.


      R12: The solution MUST function for multihomed MR and multihomed
      mobile networks as defined in [4].




Ernst                    Expires April 25, 2005                 [Page 9]


Internet-Draft                 NEMO Goals                   October 2004



      R13: NEMO Support signaling over the bidirectional MUST be
      minimized


      R14: Signaling messages between the HA and the MR MUST be secured:


         R14.1: The receiver MUST be able to authenticate the sender


         R14.2: The function performed by the sender MUST be authorized
         for the content carried


         R14.3: Anti-replay MUST be provided


         R14.4: The signaling messages MAY be encrypted


      R15: The solution MUST ensure transparent continuation of routing
      and management operations over the bi-directional tunnel (this
      includes e.g.  unicast and multicast routing protocols, router
      renumbering, DHCPv6, etc)


      R16: The solution MUST not impact on the routing fabric neither on
      the Internet addressing architecture.  [ACCORDING TO IETF56
      minutes, SHOULD BE REMOVED]


      R18: The solution MAY preserve sessions established through
      another egress interface when one fails



5.  Changes Between Versions


5.1  Changes between version -02 and -03


   - Mostly cosmetic changes


   - Merged section Terminology into Introduction


   - Cross-references with other NEMO WG docs


   - Changed the introducion of section Section 4 and added reference to
   NEMO Basic Support's resulting specification.


5.2  Changes Between Version -01 and -02


   - removed sub-items in R12 (sub-cases are contained into the
   definition of multihoming)


   - minor typos


   - R15: Added "multicast"




Ernst                    Expires April 25, 2005                [Page 10]


Internet-Draft                 NEMO Goals                   October 2004



   - R14.4: SHOULD softened to MAY according to discussion at IETF56th
   meeting.


   - R17 moved to R09 and contains former R09 as a sub-case.


   - R18: relaxed from "SHOULD" to may based on Vijay Devarapalli
   comment (030718)


5.3  Changes Between Version -00 and -01


   - title of documents: included the word "goals"


   - entire document: some rewording


   - section 4: changed title of section to "NEMO Design Goals".


   - section 4: removed "MUST" and "MAY"


   - section 4: more text about location privacy


   - section 4: changed "Administration" paragraph to "Local and Global
   Mobility".  Text enhanced.


   - section 5: R02: replace "between MR and MR's HA" with "a MR and its
   HA" R11: specified at least 2 levels R12: replaced "support" with
   "function" and add "multihomed MR" R13.x renumbered to R12.x since
   part of R12 (editing mistake) R13 and R18: new requirements proposed
   by editor and minor changes in the formulation of other Requirements


6.  Acknowledgments


   The material presented in this document takes most of its text from
   discussions and previous documents submitted to the NEMO working
   group.  This includes initial contributions from Motorola, INRIA,
   Ericsson and Nokia.  We are particularly grateful to Hesham Soliman
   (Ericsson) and the IETF ADs (Erik Nordmark and Thomas Narten) who
   highly helped to set up the NEMO working group.  We are also grateful
   to all the following people whose comments highly contributed to the
   present document: TJ Kniveton (Nokia), Alexandru Petrescu (Motorola),
   Christophe Janneteau (Motorola), Pascal Thubert (CISCO), Hong-Yon
   Lach (Motorola), Mattias Petterson (Ericsson) and all the others
   people who have expressed their opinions on the NEMO (formely MONET)
   mailing list.  Thierry Ernst wish to personally grant support to its
   previous employers, INRIA, and Motorola for their support and
   direction in bringing this topic up to the IETF, particularly Claude
   Castelluccia (INRIA) and Hong-Yon Lach (Motorola).






Ernst                    Expires April 25, 2005                [Page 11]


Internet-Draft                 NEMO Goals                   October 2004



7  References


   [1]  Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in
        IPv6", RFC 3775, June 2004.


   [2]  Devarapalli, V., "Network Mobility (NEMO) Basic Support
        Protocol", draft-ietf-nemo-basic-support-03 (work in progress),
        June 2004.


   [3]  Manner, J. and M. Kojo, "Mobility Related Terminology", RFC
        3753, June 2004.


   [4]  Ernst, T. and H. Lach, "Network Mobility Support Terminology",
        draft-ietf-nemo-terminology-02 (work in progress), October 2004.


   [5]  Ng, C-W., Paik, E-K. and T. Ernst, "Analysis of Multihoming in
        Network Mobility Support", draft-ietf-nemo-multihoming-issues-01
        (work in progress), October 2004.


   [6]  Thubert, P., Wakikawa, R. and V. Devarapalli, "NEMO Home Network
        Models", draft-ietf-nemo-home-network-models-01 (work in
        progress), October 2004.


   [7]  Deering, S. and R. Hinden, "Internet Protocol Version 6 (IPv6)",
        IETF RFC 2460, December 1998.



Author's Address


   Thierry Ernst
   WIDE at Keio University
   Jun Murai Lab., Keio University.
   K-square Town Campus, 1488-8 Ogura, Saiwa-Ku
   Kawasaki, Kanagawa  212-0054
   Japan


   Phone: +81-44-580-1600
   Fax:   +81-44-580-1437
   EMail: ernst@sfc.wide.ad.jp
   URI:   http://www.sfc.wide.ad.jp/~ernst/












Ernst                    Expires April 25, 2005                [Page 12]


Internet-Draft                 NEMO Goals                   October 2004



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 (2004).  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.




Ernst                    Expires April 25, 2005                [Page 13]