NEMO Working Group                                 Thierry Ernst, Editor
Internet-Draft                                            INRIA and                                            WIDE
                                                          February, and INRIA
                                                               May, 2003

           "Network Mobility Support Goals and Requirements"
                 <draft-ietf-nemo-requirements-00.txt>
                 <draft-ietf-nemo-requirements-01.txt>

Status of This Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   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.

Abstract

   Network mobility arises when a router connecting an entire network to
   the Internet dynamically changes its point of attachment to the
   Internet and thus its therefrom causing the reachability of the entire network to
   be changed in the topology.
   The mobile Such kind of network is viewed referred to as a unit
   mobile network. Without appropriate mechanisms, sessions established
   between nodes in the mobile network and is connected to the global Internet by one or more cannot be
   maintained while the mobile routers. In contrast with host
   mobility router changes its point of attachment.
   The required support which aims at providing continuous Internet
   connectivity mechanisms will be provided in two phases. The
   first phase, referred to mobile hosts only, network mobility support as NEMO Basic Support is to provide continuous Internet sessions not only to the mobile router
   connecting the mobile network to session
   continuity while the global Internet, but also necessary optimizations mechanims referred to
   nodes behind the mobile router. The purpose of this as
   NEMO Extended Support might be provided later. This document is to
   list outlines
   the goals expected from network mobility support and defines the
   requirements that must be met by network mobility support
   solutions in IPv6. NEMO Basic Support solutions.

Table of Contents

   1.   Introduction . . . . . . . . . . . . . . . . . . . . . . . . 03

   2.   Terminology. . . . . . . . . . . . . . . . . . . . . . . . . 04

   3.   Network Mobility   NEMO Working Group Goals and Methodology . . . . . . . . . . . 04

   4.   General Purpose Guidelines for the Solutions   NEMO Support Design Goals . . . . . . . . .  . . . . . . . . 05

   5.   NEMO Basic Support One-liner Requirements for Basic NEMO Support.  . . . . . . . . . 09

   6.   Changes From  Previous Version . . . . . . . . . . . . . . . 11

   A.   Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . 11

   B.   References . . . . . . . . . . . . . . . . . . . . . . . . . 11 12

   C.   Editors' Addresses . . . . . . . . . . . . . . . . . . . . . 12

   D.   Full Copyright Statement . . . . . . . . . . . . . . . . . . 12 13

Conventions used in this document

   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].

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 (keeping the same address on the mobile network at all times),
   and mobile (entering (LFNs) and leaving the mobile network as they roam with
   respect to it). (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:

      - 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.

      - 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.

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

      - 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.

   Traditional work conducted so far on mobility support was

   Mobility of networks does not cause MNNs to provide
   continuous Internet connectivity change their own physical
   point of attachment, however they happen to mobile hosts only (host mobility
   support). In contrast change their topological
   location with host mobility support, respect to the global Internet.  If network mobility
   support is to provide continuous Internet sessions
   not only to the
   mobile router connecting the mobile network to the global Internet,
   but also to nodes behind explicitly supported by some mechanisms, the mobile router.

   Mobility of networks does not cause MNNs to change their own physical
   point mobility of attachment, however they happen to change their topological
   location with respect to the global Internet which MR
   results in lack of into MNNs losing Internet access and broken breaking ongoing
   sessions if no supporting mechanisms are
   deployed. entertained between arbitrary correspondent node (CNs) in
   the global Internet and those MNNs located within the mobile network.
   In addition, the communication path between a MNN MNNs and an arbitrary
   Correspondent Node
   correspondent nodes (CN) may result in becomes sub-optimal, whereas multiple levels
   of mobility will cause extremely suboptimal paths,
   particularly when mobile networks are nested or when the CN is itself
   mobile. sub-optimal routing.

   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 those. 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 group, its goals, and to list define
   requirements for network mobility support.

   This document is structured as follows: first, section 2 introduces
   the terminology for network mobility. In in section 3, we define the
   goals and methodology of the NEMO working group and we emphasize the
   stepwise approach the working group has decided to follow. A number
   of guidelines desirable design goals are listed in section 4 and are used in section 5 4. Those design goals
   serve as guidelines to edict the requirements for basic network
   mobility support.

2. Terminology

   Terms

   Mobility-related terms used in this document are taken from [MIPv6] and [MOBILITY-
   TERMS]. Additional defined in
   [MOBILITY-TERMS] whereas terms pertaining to network mobility
   specifically are defined in [NEMO-TERMS].

   [NOTE FROM THE EDITOR: parts from draft [NEMO-TERMS] will probably be
   moved to [MOBILITY-TERMS] whereas the remaining terms would then be
   pasted in this present document. THIS IS TO BE DISCUSSED]

3. Network Mobility NEMO Working Group Goals and Methodology

   The primary goal 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 (basic network mobility support), (NEMO Basic Support), and at the same time study the
   possible approaches and issues with providing more optimal routing
   with potentially nested mobile networks (extended network
   mobility support). (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 basic NEMO support, 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
   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 [7] and Mobile IPv6 [6] 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.

4. General Purpose Guidelines for the Solutions NEMO Suppport Design Goals

   This section lists a number of guidelines which are used details the fundamental design goals the solutions will
   tend to achieve. Those design goals will serve to edict and
   understand the requirements that MUST or SHOULD be met by defined for forthcoming network
   mobility support solutions, solutions. Actual
   requirements for both basic NEMO support and extended Basic Support are in the next section, whereas
   NEMO support. Extended Support has not yet been considered.

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

      - Performance Transparency (Seamless Mobility): and Seamless Mobility: NEMO support
      SHOULD provide is
      expected to be provided with limited signaling overhead and ideally SHOULD to
      minimize the impact of handover on over applications, in terms of
      packet loss or delay.  Variable However, although variable delays of
      transmission and losses between MNNs and their respective CNs
      could be perceived as the network is moving are displaced, it would not be
      considered a lack of performance transparency.

      - 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 better expected to be performed by the sole
      MR(s) and specific support functions on any other nodes node than the
      MR(s)
      SHOULD would better be avoided.

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

      - 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 multi-homed 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 multi-homed nodes that change their point of attachment within the mobile network (see definition in [NEMO-TERMS].
           network,

         o foreign mobile nodes that attach to the mobile network. network,

         o nodes that change their point of attachment within multi-homed mobile network either when a single MR has
           multiple attachments to the internet, or when the mobile
           network.
           network is attached to the Internet by means of multiple
           MRs (see definition in [NEMO-TERMS]),

         o nested mobile networks (see (mobile networks attaching to other
           mobile networks, see definition in [NEMO-TERMS].

         o mobile Although the
           complexity requirements of those nested networks displaced within a domain boundary (local
           mobility) or between domain boundaries (global mobility). 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. frequencies,

         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 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.

      - Administration: the solution MUST not prevent Local Mobility and Global Mobility: mobile networks and mobile
      nodes owned by administratively different entities are expected to
      attach
      be displaced within a domain boundary or between domain
      boundaries. Multihoming, vertical and horizontal handoffs, and
      access control mechanisms are desirable to any part of the Internet topology achieve this goal. Such
      mobility type is not expected to be limited for any consideration
      other
      considerations than administrative and security policies (both
      global mobility and local-mobility are desirable). policies.

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

      - Backward Compatibility: NEMO support MUST be able will have to co-exist
      and not interfere with
      existing IPv6 standards. The solution MUST
      reuse standards without interfering with them. Standards
      defined in other IETF working groups have to be reused as much as
      possible and MAY extended only
      extend them if deemed necessary. For instance, the
      following mechanisms defined by other working groups MUST still function: are expected
      to function without modidications:

         o Address allocation and configuration mechanism. mechanisms

         o Host mobility support: the solution MUST not prevent mobile nodes and correspondent nodes,
           either located within or outside the mobile network, 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: the solution MUST maintain ongoing
           multicast sessions of support entertained by MNNs as are expected to be
           maintained while the mobile router changes its point of
           attachment. Group membership is currently gathered
           by MLD.

         o Access control protocols and mechanisms: NEMO support MUST
           not disallow 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 Routing protocols and mechanisms: Mechanisms performed by routers deployed both in mobile
           networks may be routers like the others visited
           networks and therefrom are
           expected to run in some situations a number of protocols such
           as a routing protocol, mobile networks (routing protocols, Neighbor
           Discovery, ICMP, Router
           Renumbering and others. NEMO support MUST thus not prevent
           usual routing protocols and mechanisms to keep working within
           the mobile network and to interact with the global Internet
           (home network only in the case of basic NEMO support) when
           necessary.

         o Seamless Mobility: the solutions MUST be compatible with
           FMIPv6 Renumbering, ...).

      - Security: Secure Signaling: NEMO support MUST will have to comply with usual
      IETF security policies and recommendations and MUST is expected to have
      its specific security issues fully addressed. In practice, all
      NEMO support control messages transmitted in the network MUST will have
      to ensure an acceptable level of security to prevent intruders to
      usurp identities. identities and forge data. Specifically, the following
      issues have to be addressed: 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.

         o

      - Location Privacy: means to hide the actual location of MNNS to third parties other than the HA if desired.

5. One-liner Requirements
      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.

      - 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 Basic NEMO will be able to traverse such
      clouds.

5. NEMO Basic Support One-liner Requirements

   The NEMO WG will specify a unified and unique solution for "Basic
   Network Mobility Support". The solution will 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 will be done by maintaining a
   bidirectional tunnel between the a MR and its Home Agent. The Working
   Group will investigate reusing the existing Mobile IPv6 mechanisms
   for the tunnel management, or extend it if deemed necessary.

   The following requirements are placed on the Basic NEMO support Basic Support
   solution, hereafter referred to as "the solution":

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

   R02: The solution MUST set up a bi-directional tunnel between a
        MR and MR's its Home Agent.

   R03: All traffic exchanged between a MNN and a CN in the global
        Internet MUST transit through the bidirectional 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 not prevent the proper operation of Mobile
        IPv6 (i.e. the solution MUST support MIPv6-enabled MNNs and
        MUST also allow MIPv6-enabled MNNs to receive and process Binding Updates
        from arbitrary Mobile Nodes.) operate
        either the CN, HA, or MN operations defined in [MIPv6])
        [SHOULD BE MOVED UNDER R17]

   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 mobile networks attaching to other
        mobile networks (nested mobile networks). Although it is not
        fully clear how many layers of topology MUST be supported, or
        the complexity requirements at least 2 levels of those nested mobile
        networks, the goal
        is to support while, in principle, 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).
        mobile networks SHOULD be supported.

   R12: The solution MUST function for multi-homed multihomed MR and multihomed
        mobile networks.
        More precisely:

        R13.1: networks as defined in [NEMO-TERMS]). Particularly:

        R12.1: The solution MUST support function for multi-MR mobile networks with
               multiple MRs,

        R13.2:

        R12.2: The solution MUST support MR with multiple interfaces,

        R13.3: function for multi-egress
               interfaces

        R12.3: The solution must support MUST function for MR with multiple global
               addresses on an egress interface.

        [I PROPOSE TO REMOVE R12.1, 2 and 3 BECAUSE THIS IS
        CONTAINED IN THE DEFINITION IN [NEMO-TERMS]].

   R13: NEMO Support signaling over the bidirectional MUST be minimized
        [NEW REQUIREMENT PROPOSED BY EDITOR]

   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 SHOULD be encrypted [ACCORDING TO
               DISCUSSION AT IETF56, SHALL BE REMOVED or SOFTENED TO
               "MAY" (?)]

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

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

   R17: The solution MUST ensure backward compatibility with other
        standards defined by the IETF. IETF [SPECIFIC PROTOCOLS SHOULD BE
        EXPLICITLY LISTED: MLD, ... etc. PLEASE CONTRIBUTE THE NAMES OF
        PROTOCOLS TO BE INCLUDED ON THE MAILING LIST. MAYBE MIPV6 COULD
        BE INCLUDED HERE INSTEAD OF R09.] Particularly:

   R18: The solution SHOULD preserve sessions established through
        another egress interface when one fails [PROPOSED BY EDITOR OF
        THIS DOCUMENT AT THE IETF56 MEETING. TO BE DISCUSSED ON THE
        MAILING LIST]

6. Changes since last version

   - 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

A. 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).

B. References

   [IPv6-NODE]      John Loughney
                    "IPv6 Node Requirements"
                    draft-ietf-ipv6-node-requirements-01.txt
                    July 2002,
                    draft-ietf-ipv6-node-requirements.txt
                    Work in progress.

   [MIPv6]

   [MobileIPv4]     Charles Perkins
                    "IP Mobility Support"
                    RFC 2002, IETF, October 1996.

   [MobileIPv6]     David B. Johnson and C. Perkins.
                    "Mobility Support in IPv6"
                    draft-ietf-mobileip-ipv6-20.txt,
                    January 2002.
                    draft-ietf-mobileip-ipv6.txt,
                    Work in progress.

   [MOBILITY-TERMS] J. Manner
                    "Mobility Related Terminology
                    <draft-ietf-seamoby-mobility-terminology-00.txt>
                    August 2002.
                    <draft-ietf-seamoby-mobility-terminology.txt>
                    Work in progress progress.

   [NEMO-TERMS]     Thierry Ernst and Hong-Yon Lach
                    "Terminology for Network Mobility Support",
                    draft-ernst-nemo-terminology.txt.
                    draft-ietf-nemo-terminology.txt
                    Work in progress.

   [RFC1122]        R. Braden (editor).
                    "Requirements for Internet Hosts - Communication
                    Layers".  IETF RFC 1122, October 1989.

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

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

C. Editors's Addresses

   Questions about this document can be directed to the NEMO working
   group chairs:

      Thierry Ernst,
      Keio University.
      5322 Endo, Fujisawa-shi,
      Kanagawa 252-8520, Japan.
      Phone : +81-466-49-1100
      Fax   : +81-466-49-1395
      Email : ernst@sfc.wide.ad.jp

      T. J. Kniveton
      Communications Systems Lab
      Nokia Research Center
      313 Fairchild Drive
      Mountain View, California 94043, USA
      Phone : +1 650 625-2025
      Fax   : +1 650 625-2502
      EMail : Timothy.Kniveton@Nokia.com

D. Full Copyright Statement

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

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published and
   distributed, in whole or in part, without restriction of any kind,
   provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of developing
   Internet standards in which case the procedures for copyrights defined
   in the Internet Standards process must be followed, or as required to
   translate it into languages other than English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS 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.

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