[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

IETF INTERNET-DRAFT                                        Thierry Ernst
                                                    WIDE Project / INRIA
                                                           Hong-Yon Lach
                                                           Motorola Labs
                                                           February 2002

                "Network Mobility Support Requirements"

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

   The list of Internet-Draft Shadow Directories can be accessed at


   The purpose of traditional mobility support is to provide continuous
   Internet connectivity to mobile hosts (host mobility support). In
   contrast, network mobility support is concerned with situations where
   an entire network changes its point of attachment to the Internet and
   thus its reachability in the topology. We shall refer to such a
   network as a mobile network (MONET). This document tries to identify
   what constraints limit the implementation and the deployment of a
   potentially and ideally good solution, and what requirements
   solutions must comply to. Our main aim is to raise the discussion on
   the mailing list.

Ernst and Lach             Expires August 2002                  [Page 1]

INTERNET-DRAFT    Network Mobility Support Requirements    February 2002


Status of This Memo


   1. Introduction
   2. Important Disclaimer
   3. Design Requirements
      3.1. Migration Transparency (Permanent Connectivity)
      3.2. Operational Transparency
      3.3. Performance Transparency (Seamless Mobility)
      3.4. Layers Independence
      3.5. Mobility Management Transparency for MNNs
      3.6. Scalability
      3.7. Minimum Signaling Overload
      3.8. Routing Optimization in 6 3.9. Nested Mobility
      3.10. Backward Compatibility
      3.11. Minimum Impact on Existing Protocols and Infrastructure
      3.12. No impact on CNs or Internet routing
      3.13. Security
         3.13.1. Confidentiality
         3.13.2. Authentication
         3.13.3. Authorization
         3.13.4. Location Privacy
      3.14. Access Control
         3.14.1. Access Control for VMNs
         3.14.2. Access Control Architecture
         3.14.3. Access Control in the Fixed Network
      3.15. Wide-Area Mobility
      3.16. Unified Solution
      3.17. Mobile CNs
      3.18. Addressing Constraints



Author's Addresses

Ernst and Lach             Expires August 2002                  [Page 2]

INTERNET-DRAFT    Network Mobility Support Requirements    February 2002

 1. Introduction

   This document assumes that the reader is familiar with the
   terminology defined in [TERMINOLOGY] while reading [SCOPE] for a
   description of the problems is recommended.

   The purpose of traditional mobility support is to provide continuous
   Internet connectivity to mobile hosts (host mobility support). In
   contrast, network mobility support is concerned with situations where
   an entire network changes its point of attachment to the Internet and
   thus its reachability in the topology. We shall refer to such a
   network as a mobile network (MONET). Cases of mobile networks include
   networks attached to people (Personal Area Networks or PAN), and
   networks of sensors deployed in aircrafts, boats, busses, cars,
   train, etc that need a permanent Internet connection. Those mobile
   networks may also provide Internet access to devices carried by
   people (laptop, camera, mobile phone, etc, and PAN).

   As exhibited by the scenarios depicted in [TERMINOLOGY] and [SCOPE],
   there is a desire to achieve two levels of mobility: node mobility
   and network mobility. A passenger is a mobile node which visits a
   mobile network (VMN in a MONET), and passengers may themselves be
   mobile IP-subnets (MONET in a MONET), for example when carrying a
   PAN. Since people move from a MONET to another, and since instances
   of MONETs like trains, car, aircrafts cross country boundaries, both
   VMNs and MONETs are also most likely to cross ISP boundaries and
   therefore to move between topologically distant parts of the
   Internet. This means we must allow VMNs belonging to potentially
   different administrative domains to visit the MONET.  The instances
   highlighted above also justify the need to consider potentially large
   MONETs containing hundreds of hosts and several routers. The train
   example highlights that the number of correspondent nodes could also
   be very large, and that these may be sparsely distributed in the
   Internet. It also justifies the need for true worldwide mobility in
   the Internet. A MONET may attach to very distant parts of the
   Internet topology, provided it is granted access to it, therefore
   requiring both Local-Area Mobility support and Wide-Area Mobility

   The problems that need to be addressed are illustrated in [SCOPE]
   while the purpose of this document is to raise discussion in order to
   identify what constraints limit the implementation and the deployment
   of a potentially and ideally good solution, and what requirements
   solutions must comply to. Most constraints and requirements that we
   have listed are equally applicable to host mobility support and
   network mobility support. Some of them have been debated in the
   literature as far as host mobility support was concerned; we have
   extended this list to include those related to network mobility

Ernst and Lach             Expires August 2002                  [Page 3]

INTERNET-DRAFT    Network Mobility Support Requirements    February 2002


   The material presented in this document is based on [Ernst01] and on
   our former internet-draft that was submitted in July 2001 [OLD-draft]
   for the consideration of the Mobile IP Working Group. This former
   draft was defining the terminology that is now found in [TERMINOLOGY]
   and a list of requirements and issues as an attempt to clarify the
   problem caused by networks in motion and now found in this present
   document. It was also mentioning a number of issues (impact on
   addressing, routing, and existing network protocols). We have decided
   to split this former document in two because requirements are more
   subject to discussion and disagreements that the terminology on which
   we must agree on to base our discussions. More information may be
   found on the MONET web page [WEB-MONET]. Note that this list of
   requirements is primarily targeted to IPv6 [RFC2460], but is not
   limited to it, and that the already existing network mobility support
   proposals [MONET-PSBU], [HMIPv6], and [MOBRTR] don't necessarily meet
   these requirements.

 2. Important Disclaimer

   The stated opinions in this draft come from various sources and are
   not necessarily the opinions of the authors. The purpose of this
   draft is for open discussions.

 3. Design Requirements

   This section details what requirements MUST or SHOULD be fulfilled by
   solutions, and what constraints may limit the deployment of a
   potentially good solution. Most requirements discussed for host
   mobility support, like for instance [Bhagwat96], [Myles93],
   [Castelluccia97] or [Caceres96], are equally applicable to network
   mobility support. However, they must be extended and refined to
   comply with the specific characteristics. All requirements we have
   listed may not be satisfied by a single solution. For the sake of
   modularity, we may decide to use separate solutions for different
   aspects of the problem space. Moreover, some of them are
   controversial and are subject to discussions on the mailing list
   [WEB-MONET]. It is assumed that the reader has read [TERMINOLOGY].

  3.1. Migration Transparency (Permanent Connectivity)

      Network mobility support MUST provide permanent and continuous
      Internet connectivity to all MNNs without disruption of service
      for MNNs. This means that all MNNs MUST always be reachable
      regardless of the point of attachment of the MONET.

Ernst and Lach             Expires August 2002                  [Page 4]

INTERNET-DRAFT    Network Mobility Support Requirements    February 2002

  3.2. Operational Transparency

      The network layer MUST be able of supporting connectivity of the
      MONET in an absolute transparent manner to the application or the

  3.3. Performance Transparency (Seamless Mobility)

      Network mobility support SHOULD exhibit low latency, incur little
      or no data loss, minimum delays, minimum signaling load, and
      minimum bandwidth consumption for packet delivery. In other words,
      network mobility support SHOULD be as seamless as host mobility is
      supported (no abrupt degradation of service).

  3.4. Layers Independence

      Handover of IP sessions is performed at the network layer.  With
      respect to the layer separation of the Internet protocol suite,
      handover MUST be managed at the network layer only and
      transparently to upper layers, despite the migration of the MONET
      in the network topology. Therefore, a change of topological
      location MUST not have an impact on layers above the network layer
      other than a transient loss of performance, as depicted in the
      above paragraph. If this is respected, compatibility with existing
      transport and application layers is maintained. In practice, the
      identifiers used at the transport layer should be independent from
      the physical IP addresses used at the network layer for routing.
      If upper layer protocols require a location independent and
      invariant identifier, the network layer MUST provide it with an
      identifier irrespective of the actual topological location.

  3.5. Mobility Management Transparency for MNNs

      We have seen in [TERMINOLOGY] that MNNs don't change their own
      point of attachment as a result of the MONET's displacement in the
      Internet topology. Mobility management of a MONET SHOULD therefore
      be performed transparently to MNNs, at least to LFNs. LFNs SHOULD
      (MUST ?) better have no responsibility in network mobility
      management, whereas LMNs and VMNs SHOULD only be concerned about
      managing their own mobility if they themselves appear to change
      their point of attachment. However, MNNs may encounter variable
      delays of transmission and loss with their respective CNs as the

  3.6. Scalability

      Scalability has always been an important concern in the design of

Ernst and Lach             Expires August 2002                  [Page 5]

INTERNET-DRAFT    Network Mobility Support Requirements    February 2002

      new protocols. As far as host mobility is concerned, mobility
      support has to take into consideration a growing number of mobile
      hosts and should even assume that a major part of the nodes
      composing the Internet are mobile in the near future. This means
      that signaling load and memory consumption should scale to an
      important number of mobile nodes. However, network mobility
      support is concerned by scalability differently, and in three

         o large number of MONETs (e.g. PAN comprising a few devices and
         carried by every human being).

         o large MONETs comprising several subnetworks and a large
         number of MNNs on each subnetwork (e.g. a train)

         o the number of CNs is somewhat a function of the size of the
         MONET; the more MNNs a MONET has, the more CNs the MONET is
         most likely to have. (e.g. each MNN in a train communicating
         with a few CNs)

      Network mobility support MUST thus be able to support large
      MONETs, a very large number of small MONETs, and a large number of
      CNs. Scaling to a large number of CNs may indeed deserves more
      consideration than scaling to a large number of MONETs. This has
      never been considered in host mobility support, to the contrary of
      the ability to support a large number of mobile nodes.

  3.7. Minimum Signaling Overload

      Mobility management is usually performed at the cost of control
      traffic. Network mobility support MUST minimize this control
      traffic, all the more for the reasons outlined in section

  3.8. Routing Optimization

      Network mobility support SHOULD optimize routing. Non-optimal
      routing increases bandwidth consumption and transmission delays.
      The amount of traffic intended for the MONET is understandably
      more significant than in the case of a single mobile node (see
      section "scalability"), then non-optimal routing SHOULD be
      considered with more care than for host mobility support. However,
      efficient routing is usually performed at the expense of increased
      signaling.  Thus, the gain of optimal routing MUST be balanced
      against the incurred signaling cost.

  3.9. Nested Mobility

Ernst and Lach             Expires August 2002                  [Page 6]

INTERNET-DRAFT    Network Mobility Support Requirements    February 2002

      Network mobility support MUST support nested mobility. It MUST at
      least allow single VMNs to enter the MONET, single LMNs to leave
      the MONET, and single mobile IP-subnet attach the MONET (instance
      of a PAN in a train). Network mobility support must therefore
      consider both MONETs and mobile nodes, otherwise it may hardly
      interact with host mobility support. In practice, it should handle
      VMNs as optimally as if networks were fixed. The working group
      needs to agree if it MUST support any number of levels or be
      limited to only two levels.

  3.10. Backward Compatibility

      Network mobility support is constrained by backward compatibility
      with existing and forthcoming IPv6 standards. As such, it MUST not
      prevent MNNs to operate any standardized protocol. This
      particularly includes but is not limited to Mobile IPv6 (host
      mobility) and IGMP (multicast group membership):

         o Host Mobility Support Constraints: host mobility support in
         IPv6 is achieved by Mobile IPv6 which is a compulsory component
         of any IPv6 implementation. This means that network mobility
         support MUST not prevent LMNs and VMNs from operating Mobile
         IPv6 once located in a MONET.

         o Multicast Constraints: any IPv6 router is supposed to allow
         hosts on its attached subnetworks to participate in multicast
         sessions. Group membership is gathered by the IGMP protocol.
         Network mobility support MUST not prevent this.

      In both cases, the network mobility support MUST provide the
      necessary extensions to maintain backward compatibility with
      existing protocols.

  3.11. Minimum Impact on Existing Protocols and Infrastructure

      Minimum impact on the already deployed infrastructure was an
      important issue as far as IPv4 was concerned since it was not
      possible to require all hosts to implement new features. On the
      other hand, the emergence of IPv6 is an opportunity for making
      changes, if necessary. An important number of specifications has
      already been defined, but there is still scope for adding new
      capabilities if needed since IPv6 deployment is only dawning.
      However, in order to provide a quickly deployable solution,
      network mobility support SHOULD better make use of the existing
      protocols whenever possible and impose minimum changes or
      extensions on the existing ones. It is also desirable to minimize
      infrastructure installation costs and complexity.

Ernst and Lach             Expires August 2002                  [Page 7]

INTERNET-DRAFT    Network Mobility Support Requirements    February 2002

  3.12. No impact on CN or Internet routing

      To be able successfully deploy the final solution, session
      continuity between a MNN and a CN anywhere in the Internet SHOULD
      NOT assume any changes to existing CNs or the Internet routing
      architecture. On the other hand, optimizations for performance
      enhancement MAY involve some changes to CNs, provided that such
      optimizations would not cause any disruption to ongoing sessions,
      if not supported by CNs (i.e. backward compatible).  [THIS
      REQUIREMENT IS TO BE DISCUSSED (in light of the observation made
      in section "Minimum Impact on the Existing Protocols and
      Infrastructure" here above) BECAUSE IT WOULD PREVENT POTENTIALLY

  3.13. Security

      Network mobility support must comply with usual IPv6 security
      policies and standardized protocols. In addition, and unlike fixed
      nodes, MNNs are more exposed to security threats, particularly
      identity usurpation. Network mobility support must provide MNNs
      and their CNs with at least as good security as for fixed nodes
      and mobile hosts. It particularly shouldn't leave more room for
      intruders to usurp an identify nor to perpetrate any kind of
      attack against the MNNs nor the CNs. In practice, all control
      messages required by network mobility support must be exchanged in
      a secure manner and must ensure the following:

   3.13.1. Confidentiality

         All control messages transmitted in the network MUST  ensure
         MNNs' confidentiality. Only the recipient of the control
         message may be able to decrypt the content of the datagram.

   3.13.2. Authentication

         All control messages MUST be authenticated by recipients in
         order to prevent intruders to usurp the identity of a MNN.

   3.13.3. Authorization

         The recipient of a control message MUST ensure that the sender
         is effectively authorized to perform the mobility support
         operation indicated in the control message.

   3.13.4. Location Privacy

         Network mobility support may provide means for MNNs to hide
         their location to any third party. It shouldn't be possible to

Ernst and Lach             Expires August 2002                  [Page 8]

INTERNET-DRAFT    Network Mobility Support Requirements    February 2002

         determine the succession of topological location of a MONET or
         a particular MNN by monitoring the exchange of control
         messages. In practice, MNNs may wish to hide their location to
         some or all of their CNs, or anyone else but the CNs. It may
         also be desirable to hide the location of the entire MONET to
         all CNs without discrimination between MNNs.

  3.14. Access Control

   3.14.1. Access Control for VMNs

      Mobile Networks MUST be able to authenticate and authorize VMNs to
      gain access to the Internet via the mobile network infrastructure

   3.14.2. Access Control Architecture

      To be able to comply with the current access control mechanisms
      and achieve a scalable solution, the final solution MUST NOT
      assume that the fixed network would authenticate VMNs. VMN
      authentication and authorization MUST be the responsibility of the
      mobile network.

   3.14.3. Access Control in the Fixed Network

      AAA solutions MUST allow for authenticating an entire network.
      This MAY simply be done by ensuring that the Authentication and
      Authorization is not necessarily performed for a single IP
      address. This is particularly important for IPv6 as each node may
      configure multiple addresses. [THIS MAY BE SUGGESTING A SOLUTION

  3.15. Wide-Area Mobility

      Network mobility support MUST provide means for a MONET to move
      between heterogeneous networks, i.e. Wide-Area Mobility. This is
      required in order to ensure permanent and uninterrupted world-wide
      mobility. Nothing but administrative and security policies should
      prevent a MONET to attach anywhere in the Internet topology. In
      practice, a given MONET MUST be able to roam between
      administratively distinct access networks (between Internet
      Service Providers and corporate networks) and via any available
      access technology (802.11b WLAN, Bluetooth, satellite link, GSM,
      ...). In addition, network mobility support must also accommodate
      to CNs deployed in distinct administrative domains.

  3.16. Unified Solution

Ernst and Lach             Expires August 2002                  [Page 9]

INTERNET-DRAFT    Network Mobility Support Requirements    February 2002

      Should different schemes be proposed, a unified mobility support
      scheme is required. We must avoid a situation where distinct
      network mobility support schemes are deployed and unable to inter-
      operate with each other.

  3.17. Mobile CNs

      Network mobility support MUST be optimized to handle the case
      where the CN is itself a MN (as defined by [MIPv6]) or located in
      a MONET (particularly if it is a VMN). It must perform efficiently
      in both cases.

  3.18. Addressing Constraints

      The IP address is used for routing and to identify the subnetwork
      where an interface is attached to. Each interface on a subnetwork
      must therefore be configured with the network prefix of that

Ernst and Lach             Expires August 2002                 [Page 10]

INTERNET-DRAFT    Network Mobility Support Requirements    February 2002


   The first author would like to thank both Motorola Labs Paris and
   INRIA Rhône-Alpes, for the opportunity to bring this topic to the
   IETF and more particularly Claude Castelluccia (INRIA) for its
   advices, suggestions, and direction. In addition, we acknowledge
   Alexandru Petrescu (Motorola), Mattias Petterson (Ericsson), Hesham
   Soliman (Ericsson) and the NACM people from WIDE (Keio University)
   for their comments and suggestions on this draft.


   [Bhagwat96] Pravin Bhagwat, Satish Tripathi, and Charles Perkins.
   Network Layer Mobility: an Architecture and Survey. IEEE Personal
   Communications, 3(3):54, June 1996.

   [Caceres96] Ramon Caceres and Venkata N. Padmanabhan. "fast and
   scalable handoffs for wireles internetworks".  In Proc. of the Second
   ACM/IEEE International Conference on Mobile Computing and Networking
   (MobiCom), Rye, New York, USA, November 1996. Bell Laboratories and
   University of California at Berkeley.

   [Castelluccia98] Claude Castelluccia.  A Hierarchical Mobility
   Management Scheme for IPv6. Third Symposium on Computers and
   Communications (ISCC'98), Athens, Greece, June 1998.

   [Ernst01] Thierry Ernst "Network Mobility Support in IPv6", PhD
   Thesis, University Joseph Fourier Grenoble, France. October 2001.

   [HMIPv6] H. Soliman, C. Castelluccia, K. ElMalki, L. Bellier,
   "Hierarchical MIPv6 mobility management", draft-ietf-mobileip-
   hmipv6-05.txt. Work in progress

   [MIPv6] David B. Johnson and C. Perkins. Mobility Support in IPv6.
   draft-ietf-mobileip-ipv6-14.txt, July 2001. Work in progress.

   [MOBRTR] T.J. Kniveton, J. J. Malinen, V. Devarapalli and C. E.
   Perkins, "Mobile router support in Mobile IP", draft-kniveton-
   mobrtr-00.txt. Work in progress.

   [Myles93] Andrew Myles and David Skellern. Comparing Four IP Based
   Mobile Host Protocols. In Joint- European Networking Conference.
   Macquarie University, Sydney, Australia, May 1993.

   [OLD-draft] Thierry Ernst, Hong-Yon Lach, Claude Castelluccia
   "Network Mobility Support in IPv6: Problem Statement and
   Requirements", draft-ernst-mobileip-monetv6-00.txt, July 2001.

Ernst and Lach             Expires August 2002                 [Page 11]

INTERNET-DRAFT    Network Mobility Support Requirements    February 2002

   Expiration pending.

   [MONET-PSBU] T. Ernst, L. Bellier, A. Olivereau, C. Castelluccia,
   H.-Y. Lach, "Mobile Networks Support in Mobile IPv6 (Prefix Scope
   Binding Updates)" draft-ernst-mobileip-v6-network-02.txt, June 2001.
   Work in progress

   [RFC1122] R. Braden (editor). Requirements for Internet Hosts -
   Communication Layers.  Request For Comments 1122, Internet
   Engineering Task Force (IETF), October 1989.

   [RFC2460] S. Deering and R. Hinden. Internet Protocol Version 6
   (IPv6) Specification.  Request For Comments 2460, Internet
   Engineering Task Force (IETF), December 1998.

   [SCOPE] Hesham Soliman "Problem Scope" IETF internet-draft draft-
   soliman-monet-scope-00.txt, Work in progress.

   [TERMINOLOGY] Thierry Ernst "Terminology for Network Mobility
   Support", draft-ernst-monet-terminology-00.txt, February 2002. Work
   in progress.

   [WEB-MONET] MONET web page http://www.nal.motlabs.com/monet

Ernst and Lach             Expires August 2002                 [Page 12]

INTERNET-DRAFT    Network Mobility Support Requirements    February 2002

Author's Addresses

    Questions about this document can be directed to the authors:

      Thierry Ernst,
      WIDE Project
      Jun Murai lab. Faculty of Environmental Information,
      Keio University.
      5322 Endo, Fujisawa-shi, Kanagawa 252-8520, Japan.
      Phone : +81-466-49-1100
      Fax   : +81-466-49-1395
      E-mail: ernst@sfc.wide.ad.jp
      Web: http://www.sfc.wide.ad.jp/~ernst/

      Hong-Yon Lach
      Motorola Labs Paris, Lab Manager,
      Networking and Applications Lab (NAL)
      Espace Technologique - Saint Aubin
      91193 Gif-sur-Yvette Cedex, France
      Phone: +33-169-35-25-36
      Email: Hong-Yon.Lach@crm.mot.com

Ernst and Lach             Expires August 2002                 [Page 13]

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