Network Working Group                                      H. Chan (Ed.)
Internet-Draft                                       Huawei Technologies
Intended status: Informational                             July 12,                         September 7, 2012
Expires: January 13, March 11, 2013

            Requirements of distributed mobility management
                     draft-ietf-dmm-requirements-01 for Distributed Mobility Management


   This document defines the requirements for Distributed Mobility
   Management (DMM) in IPv6 deployments.  The traditional traditionally hierarchical
   structure of cellular networks has led to deployment models which are heavily
   in practice centralized.  Mobility management with logically
   centralized mobility anchoring in existing
   hierarchical current mobile networks is quite prone to
   suboptimal routing and
   issues related to scalability.  Centralized raises scalability issues.  Such centralized
   functions present a can lead to single point points of failure, failure and inevitably
   introduce longer delays and higher signaling loads for network
   operations related to mobility management.  This document defines the requirements for distributed
   mobility management for IPv6 deployment.  The objectives are objective is to match
   enhance mobility deployment with management in order to meet the current trend primary goals in
   network evolution,
   to i.e., improve scalability, to avoid single point points of
   failure, to enable
   transparency transparent mobility support to upper layers only
   when needed, etc.  The distributed and so on.  Distributed mobility management also needs to must be
   secure and compatible with existing network deployments and end hosts, and be secured.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at

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

   This Internet-Draft will expire on January 13, March 11, 2013.

Copyright Notice

   Copyright (c) 2012 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   ( in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Conventions used in this document  . . . . . . . . . . . . . .  5
     2.1.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  5
   3.  Centralized versus distributed mobility management . . . . . .  5
     3.1.  Centralized mobility management  . . . . . . . . . . . . .  6
     3.2.  Distributed mobility management  . . . . . . . . . . . . .  6  7
   4.  Requirements . . . . . . . . . . . . . . . . . . . . . . . . .  8  7
     4.1.  Distributed deployment . . . . . . . . . . . . . . . . . .  8
     4.2.  Transparency to Upper Layers when needed . . . . . . . . .  9
     4.3.  IPv6 deployment  . . . . . . . . . . . . . . . . . . . . . 10
     4.4.  Compatibility  Existing mobility protocols  . . . . . . . . . . . . . . . 10
     4.5.  Compatibility  . . . . . . . 10
     4.5.  Existing mobility protocols . . . . . . . . . . . . . . . 11 10
     4.6.  Security considerations  . . . . . . . . . . . . . . . . . 11
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 12 11
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 12
   7.  Co-authors and Contributors  . . . . . . . . . . . . . . . . . 12
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 13
     8.2.  Informative References . . . . . . . . . . . . . . . . . . 13
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15

1.  Introduction

   In the past decade a fair number of mobility protocols have been
   standardized [RFC6275] [RFC5944] [RFC5380] [RFC6301] [RFC5213].
   Although the protocols differ in terms of functions and associated
   message format, formats, we can identify a few key common features:

      presence of

      a centralized mobility anchor providing global reachability and an
      always-on experience; experience to the user;

      extensions to the base protocols to optimize handover performance
      while users roam across wireless cells; and

      extensions to enable the use of heterogeneous wireless interfaces
      for multi-mode terminals (e.g. cellular phones). smartphones).

   The presence of the centralized mobility anchor allows a mobile
   device node
   to be remain reachable when it is not connected to its home domain.  The
   anchor point, among other tasks, ensures reachability of connectivity by forwarding of
   packets destined to to, or sent from from, the mobile device.
   Most node.  In practice,
   most of the deployed architectures today have a small number of
   centralized anchors managing the traffic of millions of mobile
   subscribers. nodes.
   Compared with a distributed approach, a centralized approach is
   likely to have several issues or limitations affecting performance
   and scalability, which require costly network dimensioning and
   engineering to resolve.

   To optimize handovers from the perspective of mobile nodes, the base
   protocols have been extended to efficiently handle packet forwarding
   between the previous and new points of attachment.  These extensions
   are necessary when applications impose have stringent requirements in terms
   of delay.  Notions of localization and distribution of local agents
   have been introduced to reduce signaling overhead.
   Unfortunately overhead [Paper-
   Distributed.Centralized.Mobility].  Unfortunately, today we witness
   difficulties in getting such protocols deployed, often leading to sub-optimal choices. resulting in sub-
   optimal choices for the network operators.

   Moreover, the availability of multi-mode devices and the possibility
   of using several network interfaces simultaneously have motivated the
   development of even more new protocol extensions.  Deployment extensions to add more capabilities
   to the base protocol.  In the end, deployment is further complicated
   with so many the multitude of extensions.

   Mobile users are, more than ever, consuming Internet content; such
   traffic imposes new requirements on mobile core networks for data
   traffic delivery.  When the traffic demand exceeds available
   capacity, service providers need to implement new strategies such as
   selective traffic offload (e.g. 3GPP work items LIPA/SIPTO) LIPA/SIPTO

   [TS.23829]) through alternative access networks (e.g.  WLAN).  WLAN) [Paper-
   Mobile.Data.Offloading].  Moreover, the localization presence of content providers
   closer to the Mobile/Fixed mobile/fixed Internet Service Providers network
   requires taking into account local Content Delivery Networks (CDNs)
   while providing mobility services.

   When demand exceeds capacity, both traffic offloading and CDN techniques
   mechanisms could benefit from the development of mobile architectures
   with fewer levels of routing hierarchy introduced into the data path
   by the mobility management system.  This trend in network flattening towards so-called
   "flat networks" is reinforced by a shift in users user traffic behavior, aimed at increasing behavior.
   In particular, there is an increase in direct communications among
   peers in the same geographical area.  Distributed mobility management
   in a truly flat mobile architecture would anchor the traffic closer
   to the point of attachment of the
   user and overcome user, overcoming the suboptimal routing issues
   route stretch of a centralized mobility scheme.

   While deploying [Paper-Locating.User] today's mobile networks, service providers face new
   challenges.  More  Mobility patterns indicate that, more often than not,
   devices nodes remain attached to the same point of attachment.  Specific attachment for
   considerable periods of time [Paper-Locating.User] .  Therefore it is
   not uncommon to observe that specific IP mobility management support
   is not required for applications that launch and complete their
   sessions while the mobile device node is connected to the same point of
   attachment.  However, the currently, IP mobility support has been is designed
   to be always on and to maintain for
   always-on operation, maintaining all parameters of the context for
   each mobile subscriber for as long as they are connected to the
   network.  This can result in a waste of resources and ever-increasing
   costs for the service provider.  Infrequent node mobility and coupled
   with application intelligence of many
   applications suggest that mobility can be provided dynamically,
   selectively, thus simplifying the context maintained in the different
   nodes of the mobile network.

   The DMM charter addresses two complementary aspects of mobility
   management procedures: the distribution of mobility anchors to
   achieve towards a
   more flat design network and the dynamic activation/deactivation of mobility
   protocol support as an enabler to distributed mobility management.
   The former has the goal of aims at positioning mobility anchors (HA, LMA) closer to
   the user; ideally, these mobility agents could be collocated with the first hop
   first-hop router.  The latter, facilitated by the distribution of
   mobility anchors, aims at identifying when mobility support must be
   activated and identifying sessions that do not impose require mobility
   management support -- thus reducing the amount of state information
   that must be maintained in the various mobility agents of the mobile
   network.  The key idea is that dynamic mobility management relaxes
   some of the constraints so that of previously-standardized mobility
   management solutions and, by doing so, it may can avoid the establishment
   of non-
   optimal non-optimal tunnels between two topologically distant anchors.

   This document describes the motivations of distributed mobility

   Given this motivational background in Section 1.  Section 3 this section, this document
   compares distributed mobility management with centralized mobility management.
   management in Section 3.  The requirements to address these problems
   are given in Section 4.  Finally, security considerations are
   discussed in Section 5.

   The problem statement and the use cases [I-D.yokota-dmm-scenario] can
   be found in the following review paper: [Paper-
   Distributed.Mobility.Review]. [Paper-Distributed.Mobility.Review].

2.  Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL","SHALL NOT",
   document are to be interpreted as described in [RFC2119].

2.1.  Terminology

   All the general mobility-related terms and their acronyms used in
   this document are to be interpreted as defined in the Mobile IPv6
   base specification [RFC6275], in the Proxy mobile IPv6 specification
   [RFC5213], and in Mobility Related Terminology [RFC3753].  These
   terms include the following: mobile node (MN), correspondent node
   (CN), and home agent
   (HA), (HA) as per [RFC6275]; local mobility anchor (LMA),
   (LMA) and mobile access gateway (MAG), (MAG) as per [RFC5213], and
   context. context
   as per [RFC3753].

   In addition, this draft introduces the following term.

   Mobility context

      is the collection of information required to provide mobility
      management support for a given mobile node.

3.  Centralized versus distributed mobility management

   Mobility management functions may be implemented at different layers
   of the network protocol stack.  At the IP (network) layer, they may reside in
   the network or in the mobile node.  In particular, a network-based
   solution resides in the network only.  It therefore enables mobility
   for existing hosts and network applications which are already in
   deployment but lack mobility support.

   At the IP layer, a mobility management protocol to achieve supporting session
   continuity is typically based on the principle of distinguishing
   between identifier and routing address and maintaining a mapping
   between them.  With the two.  In Mobile IP, the home address serves as an
   identifier of the device whereas the care-of-address (CoA) takes the
   role of routing address, and the routing address.  The binding between them these two is
   maintained at the
   mobility anchor, i.e., the home agent. agent (mobility anchor).  If packets can be
   continuously delivered to a mobile device node at its home address, then all
   sessions using that home address can be preserved are unaffected even though the
   routing or care-of address (CoA) changes.

   The next two subsections explain centralized and distributed mobility
   management functions in the network.

3.1.  Centralized mobility management


   In centralized mobility management, the mapping information between
   the stable persistent node identifier and the changing IP address of a
   mobile node (MN) is kept at a centralized single mobility anchor.  Packets  At the same
   time, packets destined to an the MN are routed via this anchor.  In
   other words, such mobility management systems are centralized in both
   the control plane and the data plane.

   Many existing mobility management deployments make use of centralized
   mobility anchoring in a hierarchical network architecture, as shown
   in Figure 1.  Examples of such centralized mobility anchors are the
   home agent (HA) and local mobility anchor (LMA) in Mobile IPv6
   [RFC6275] and Proxy Mobile IPv6 [RFC5213], respectively.  Current
   cellular networks such as the Third Generation Partnership Project
   (3GPP) UMTS networks, CDMA networks, and 3GPP Evolved Packet System
   (EPS) networks also employ centralized mobility management, with management too.  In
   particular, Gateway GPRS Support Node (GGSN) and Serving GPRS Support
   Node (SGSN) in the 3GPP UMTS hierarchical network network, and with the Packet
   data network Gateway (P-GW) and Serving Gateway (S-GW) in the 3GPP
   EPS network. network, respectively, act as anchors in a hierarchy.

          UMTS                3GPP SAE              MIP/PMIP
        +------+              +------+              +------+
        | GGSN |              | P-GW |              |HA/LMA|
        +------+              +------+              +------+
           /\                    /\                    /\
          /  \                  /  \                  /  \
         /    \                /    \                /    \
        /      \              /      \              /      \
       /        \            /        \            /        \
   +------+  +------+    +------+  +------+    +------+  +------+
   | SGSN |  | SGSN |    | S-GW |  | S-GW |    |MN/MAG|  |MN/MAG|
   +------+  +------+    +------+  +------+    +------+  +------+

   Figure 1.  Centralized mobility management.

3.2.  Distributed mobility management

   Mobility management functions may also be distributed to multiple
   locations in different
   networks as shown in Figure 2, so that a mobile node in any of these
   networks may be served by a closeby mobility function (MF).

   +------+  +------+  +------+  +------+
   |  MF  |  |  MF  |  |  MF  |  |  MF  |
   +------+  +------+  +------+  +------+
                       | MN |

   Figure 2.  Distributed mobility management.

   Mobility management may be partially distributed, i.e., or fully distributed.  In the
   former case only the data plane is distributed, or fully distributed.  Fully distributed where
   mobility management implies that both the data plane and the control
   plane are distributed.  These different approaches are described in
   detail in [I-D.yokota-dmm-scenario].

   [Paper-New.Perspective] discusses some initial steps towards a clear
   definition of what mobility management may be, to assist in better
   developing distributed architecture.  [Paper-
   Characterization.Mobility.Management] analyses current mobility
   solutions and proposes an initial decoupling of mobility management
   into well-defined functional blocks, identifying their interactions,
   as well as a potential grouping, which later can assist in deriving
   more flexible mobility management architectures.  According to the
   split functional blocks, this paper proposes three ways into which
   mobility management functional blocks can be grouped, as an initial
   way to consider a better distribution: location and handover
   management, control and data plane, user and access perspective.

   A distributed mobility management scheme is proposed in [Paper-
   Distributed.Dynamic.Mobility] for future flat IP IP-based
   mobile network architecture consisting of access nodes.  The nodes is proposed in
   [Paper-Distributed.Dynamic.Mobility].  Its benefits of this design over centralized
   mobility management are also verified shown through simulations in [Paper-Distributed.Centralized.Mobility].

   Before [Paper-
   Distributed.Centralized.Mobility].  Moreover, the (re)use and
   extension of existing protocols in the design of both fully
   distributed mobility management [Paper-Migrating.Home.Agents] [Paper-
   Distributed.Mobility.SAE] and partially distributed mobility
   management [Paper-Distributed.Mobility.PMIP] [Paper-
   Distributed.Mobility.MIP] have been reported in the literature.
   Therefore, before designing new mobility management protocols for a
   future flat IP architecture, one should it is recommended to first ask consider
   whether the existing mobility management protocols that have already been deployed for the
   hierarchical mobile networks can be extended to
   serve the a flat IP architecture.  MIPv4 has already been deployed in 3GPP2 networks, and
   PMIPv6 has already been adopted in WiMAX Forum and in 3GPP standards.
   Using MIP or PMIP for both centralized and distributed architectures
   would ease the migration of the current mobile networks towards a
   flat architecture.  It has therefore been proposed to adapt MIP or
   PMIPv6 to achieve distributed mobility management by using a
   distributed mobility anchor architecture.

   In [Paper-Migrating.Home.Agents], the HA functionality is copied to
   many locations.  The HoA of all MNs are anycast addresses, so that a
   packet destined to the HoA from any corresponding node (CN) from any
   network can be routed via the nearest copy of the HA.  In addition,
   [Paper-Distributed.Mobility.SAE] proposes to distribute the function
   of HA into many mobility agents (MAs) each serving a portion of MNs
   using a distributed hash table structure.  A lookup to the hash table
   will point to the MA serving an MN.  In [Paper-
   Distributed.Mobility.PMIP] and [Paper-Distributed.Mobility.MIP], only
   the mobility routing (MR) function is duplicated and distributed in
   many locations.  The location information for any MN that has moved
   to a visited network is still centralized and kept at a location
   management (LM) function in the home network of the MN.  The LM
   function at different networks constitutes a distributed database
   system of all the MNs that belong to any of these networks and have
   moved to a visited network.

4.  Requirements

   After comparing distributed mobility management against centralized

4.  Requirements

   After comparing distributed mobility management against centralized
   deployment in Section 3, this section states the requirements as

4.1.  Distributed deployment

   REQ1:  Distributed deployment

          IP mobility, network access and routing solutions provided by
          DMM MUST enable a distributed deployment of for mobility management
          of IP sessions so that the traffic does not need to traverse
          centrally deployed mobility anchors and thus can be routed in
          an optimal manner without traversing centrally deployed
          mobility anchors. manner.

          Motivation: The motivations of this This requirement are to match
          mobility deployment with is motivated by current trend trends in
          network evolution:
          more cost (a) it is cost- and resource effective resource-effective to
          cache and distribute
          contents when content by combining distributed mobility
          anchors with caching systems (e.g., CDN); improve (b) the
          significantly larger number of mobile nodes and flows call for
          improved scalability; avoid (c) single point points of failure; mitigate threats being focused on failure are avoided
          in a distributed system; (d) threats against centrally
          deployed anchor, anchors, e.g., home agent and local mobility anchor. anchor,
          are mitigated in a distributed system.

   This requirement addresses the following problems PS1, PS2, PS3, and
   PS4. PS4 in the

   PS1:  Non-optimal routes

         Routing via a centralized anchor often results in a longer
         route, and the
         route.  The problem is especially manifested when accessing a
         local or cache server or servers of a Content Delivery Network (CDN).

   PS2:  Non-optimality  Divergence from other evolutionary trends in Evolved Network Architecture

         The centralized network

         Centralized mobility management can become non-optimal as with a
         flat network architecture evolves and becomes more flattened. architecture.

   PS3:  Low scalability of centralized route and mobility context

         Setting up such special routes through a central anchor and maintaining the
         mobility context for each MN therein requires more resources is
         more difficult to scale in a centralized
         design with a large number of MNs. design, thus reducing
         scalability.  Distributing the route maintenance function and
         the mobility context maintenance function among different networks
         network entities can be more scalable. increase scalability.

   PS4:  Single point of failure and attack

         Centralized anchoring may be more vulnerable to single point points
         failure failures and attack attacks than a distributed system.  The impact
         of a successful attack on a system with centralized mobility
         management can be far greater as well.

4.2.  Transparency to Upper Layers when needed

   REQ2:  Transparency to Upper Layers when needed


          DMM solutions MUST provide transparency transparent mobility support above
          the IP layer when needed.  Such transparency is needed, when the mobile
          hosts or entire mobile networks [RFC3963] for
          example, when, upon change their of point of attachment to the
          Internet, for the an application flows that flow cannot cope with a change of in the
          IP address.  Otherwise the  Otherwise, support to maintain for maintaining a stable home
          IP address or prefix during
          handover handovers may be declined.

          Motivation: The motivation of this requirement is to enable
          more efficient use of network resources and more efficient
          routing by not maintaining a stable home IP address context at the mobility anchor when
          there is no such need.

   This requirement addresses the problems PS5 as well as the other
   related problem O-PS1.

   PS5:  Wasting resources to provide mobility support mobile to nodes that do
         not needing mobility need such support

         IP mobility support is not always required. required, and not every
         parameter of mobility context is always used.  For example,
         some applications do not need a stable IP address during handover,
         i.e., a
         handover to maintain IP session continuity.  Sometimes, the
         entire application session runs while the terminal does not
         change the point of attachment.  In these situations that do not require IP
         mobility support, network resources are wasted when mobility
         context is set up.

   O-PS1:  Mobility signaling overhead with peer-to-peer communication

           Wasting resources when mobility signaling (e.g., maintenance
           of the tunnel, keep alive, etc.) is not turned off for peer-
           to-peer communication.  Peer-to-peer communications have
           particular traffic patterns that often do not benefit from
           mobility support from the network.  Thus, the assoicated
           mobility support signaling (e.g., maintenance of the tunnel,
           keep alives, etc.) wastes network resources for no
           application gain.  In such a case, it is better to enable
           mobility support selectively.

4.3.  IPv6 deployment

   REQ3:  IPv6 deployment


          DMM solutions SHOULD target IPv6 as the primary deployment
          environment and SHOULD NOT be tailored specifically to support
          IPv4, in particular in situations where private IPv4 addresses
          and/or NATs are used.

          Motivation: The motivation for this This requirement is to be inline with the general
          orientation of IETF.  Moreover, IETF work.  DMM deployment is foreseen in mid-term/long-term, hopefully in an mid-
          to long-term horizon, when IPv6 world. is expected to be far more
          common than today.  It is also unnecessarily complex to solve
          this problem for IPv4, as we will not be able to use some of
          the IPv6-specific features/tools.

4.4.  Compatibility  Existing mobility protocols

   REQ4:  Compatibility

          The  Existing mobility protocols

          A DMM solution SHOULD be able first consider reusing and extending
          IETF-standardized protocols before specifying new protocols.

          Motivation: Using IETF protocols is easier to work between trusted
          administrative domains when allowed by the security measures
          deployed between these domains.  Furthermore, the deploy and to

4.5.  Compatibility

   REQ5:  Compatibility

          The DMM solution MUST be able to co-exist with existing network deployment and
          end hosts so that the existing deployment can continue to be
          supported. co-exist with existing
          network deployments and end hosts.  For example, depending on
          the environment in which DMM is deployed, the DMM solutions may
          need to be compatible with other existing deployed mobility protocols that are deployed in
          that environment
          or may need to be interoperable interoperate with the a network or the mobile hosts/routers hosts/
          routers that do not support the DMM enabling protocol. protocols.  Furthermore, a DMM
          solution SHOULD work across different networks, possibly
          operated as separate administrative domains, when allowed by
          the trust relationship between them.

          Motivation: The motivation motivations of this requirement is to allow
          inter-domain operation if desired and are (1) to
          preserve backwards compatibility so that the existing networks and
          hosts are not affected and do not break. continue to function as usual, and
          (2) enable inter-domain operation if desired.

   This requirement addresses the following other related problem O-PS2.

   O-PS2:  Complicated deployment with too many MIP variants and
           of MIP

           Deployment is complicated with many variants and extensions
           of MIP.  When introducing new functions which may add to the
           complexity, existing solutions are more vulnerable to break.

4.5.  Existing mobility protocols

   REQ5:  Existing mobility protocols

          A DMM solution SHOULD first consider reusing and extending the
          existing mobility protocols before specifying new protocols.

          Motivation: The purpose is to reuse the existing protocols
          first before considering new protocols.

4.6.  Security considerations

   REQ6:  Security considerations


          DMM protocol solutions for DMM MUST consider security, for
          example security aspects,
          including confidentiality and integrity.  Examples of aspects
          to be considered are authentication and authorization
          mechanisms that allow a legitimate mobile host/router to access to use
          the mobility support provided by the DMM service,
          protection of solution; signaling messages of the protocol solutions
          message protection in terms of authentication, encryption,
          etc.; data integrity, integrity and data
          confidentiality, confidentiality; opt-in or opt-out
          data confidentiality to signaling messages depending on
          network environments or user requirements.

          Motivation and problem statement:

          Motivation: Mutual authentication and authorization between a
          mobile host/router and an access router providing the DMM
          service to the mobile host/router are required to prevent
          potential attacks in the access network of the DMM service.  Otherwise, various
          Various attacks such as impersonation, denial of service, man-in-the-middle man-
          in-the-middle attacks,
          etc. are present to obtain illegitimate access or to collapse
          the and so on, can be mounted against a DMM service.
          service and need to be protected against.

          Signaling messages are can be subject to various attacks since these
          they carry critical context of information about a mobile host/router. node/
          router.  For instance, a malicious node can forge and send a number of
          signaling messages to redirect thus redirecting traffic to a specific node. from its
          legitimate path.  Consequently, the specific node is under a
          denial of service attack, whereas other nodes are do not receiving receive
          their traffic.  As signaling messages may travel over the
          Internet, the end-to-end security is could be required.

5.  Security Considerations

   Distributed mobility management (DMM) requires two kinds of security
   considerations: 1) First, access network security that only allows a
   legitimate mobile host/router to access the DMM service; 2) end-to-
   end Second, end-
   to-end security that protects signaling messages for the DMM service.
   Access network security is required between the mobile host/router
   and the access network providing the DMM service.  End-to-end
   security is required between nodes that participate in the DMM

   It is necessary to provide sufficient defense against possible
   security attacks, or to adopt existing security mechanisms and
   protocols to provide sufficient security protections.  For instance,
   EAP based
   EAP-based authentication can be used for access network security,
   while IPsec can be used for end-to-end security.

6.  IANA Considerations


7.  Co-authors and Contributors

   This problem statement document is a joint effort among the following
   participants.  Each individual has made significant contributions to
   this work.

   Dapeng Liu:

   Pierrick Seite:

   Hidetoshi Yokota:

   Charles E. Perkins:

   Melia Telemaco:

   Elena Demaria:

   Peter McCann:

   Kostas Pentikousis:

   Tricci So:

   Jong-Hyouk Lee:

   Jouni Korhonen:

   Sri Gundavelli:

   Carlos J. Bernardos:

   Marco Liebsch:
   Wen Luo:

   Georgios Karagiannis:

   Julien Laganier:

   Wassim Michel Haddad:

   Alexandru Petrescu:

   Seok Joo Koh:

   Dirk von Hugo:

   Ahmad Muhanna:

8.  References

8.1.  Normative References

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

8.2.  Informative References

              Zhou, X., Korhonen, J., Williams, C., Gundavelli, S., and
              C. Bernardos, "Prefix Delegation for Proxy Mobile IPv6",
              draft-ietf-netext-pd-pmip-02 (work in progress),
              March 2012.

              Yokota, H., Seite, P., Demaria, E., and Z. Cao, "Use case
              scenarios  for Distributed Mobility Management",
              draft-yokota-dmm-scenario-00 (work in progress),
              October 2010.

              Bertin, P., Bonjour, S., and J-M. Bonnin, "A Distributed
              or Centralized Mobility",  Proceedings of Global
              Communications Conference  (GlobeCom), December 2009.

              Bertin, P., Bonjour, S., and J-M. Bonnin, "A Distributed
              Dynamic Mobility Management Scheme  Designed for Flat IP
              Architectures",  Proceedings of 3rd International
              Conference  on New Technologies, Mobility and Security
              (NTMS), 2008.

              Chan, H., "Distributed Mobility Management with Mobile
              IP",  Proceedings of  IEEE International Communication
              Conference (ICC)  Workshop on Telecommunications:  from
              Research to Standards, June 2012.

              Chan, H., "Proxy Mobile IP  with Distributed Mobility
              Anchors",  Proceedings of GlobeCom Workshop  on Seamless
              Wireless Mobility, December 2010.

              Chan, H., Yokota, H., Xie, J., Seite, P., and D. Liu,
              "Distributed and Dynamic Mobility Management  in Mobile
              Internet: Current Approaches and Issues, Journal of
              Communications, vol. 6, no. 1, pp. 4-15, Feb 2011.",
               Proceedings of GlobeCom Workshop  on Seamless Wireless
              Mobility, February 2011.

              Fisher, M., Anderson, F., Kopsel, A., Schafer, G., and M.
              Schlager, "A Distributed IP Mobility Approach for 3G SAE",
               Proceedings of the 19th International Symposium  on
              Personal, Indoor and Mobile Radio Communications (PIMRC),

              Kirby, G., "Locating the User",  Communication
              International, 1995.

              Wakikawa, R., Valadon, G., and J. Murai, "Migrating Home
              Agents  Towards Internet-scale Mobility Deployments",
               Proceedings of the ACM 2nd CoNEXT Conference  on Future
              Networking Technologies, December 2006.

              Lee, K., Lee, J., Yi, Y., Rhee, I., and S. Chong, "Mobile
              Data Offloading: How Much Can WiFi Deliver?",  SIGCOMM
              2010, 2010.

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

   [RFC3963]  Devarapalli, V., Wakikawa, R., Petrescu, A., and P.
              Thubert, "Network Mobility (NEMO) Basic Support Protocol",
              RFC 3963, January 2005.

   [RFC5213]  Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K.,
              and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.

   [RFC5380]  Soliman, H., Castelluccia, C., ElMalki, K., and L.
              Bellier, "Hierarchical Mobile IPv6 (HMIPv6) Mobility
              Management", RFC 5380, October 2008.

   [RFC5944]  Perkins, C., "IP Mobility Support for IPv4, Revised",
              RFC 5944, November 2010.

   [RFC6275]  Perkins, C., Johnson, D., and J. Arkko, "Mobility Support
              in IPv6", RFC 6275, July 2011.

   [RFC6301]  Zhu, Z., Wakikawa, R., and L. Zhang, "A Survey of Mobility
              Support in the Internet", RFC 6301, July 2011.

              3GPP, "Local IP Access and Selected IP Traffic Offload
              (LIPA-SIPTO)", 3GPP TR 23.829 10.0.1, October 2011.

Author's Address

   H Anthony Chan (editor)
   Huawei Technologies
   5340 Legacy Dr. Building 3, Plano, TX 75024, USA
   Dapeng Liu
   China Mobile
   Unit2, 28 Xuanwumenxi Ave, Xuanwu District,  Beijing 100053, China
   Pierrick Seite
   France Telecom - Orange
   4, rue du Clos Courtel, BP 91226,  Cesson-Sevigne 35512, France
   Hidetoshi Yokota
   KDDI Lab
   2-1-15 Ohara, Fujimino, Saitama, 356-8502 Japan
   Charles E. Perkins
   Huawei Technologies
   Jouni Korhonen
   Nokia Siemens Networks
   Charles E. Perkins
   Huawei Technologies
   Melia Telemaco
   Alcatel-Lucent Bell Labs
   Elena Demaria
   Telecom Italia
   via G. Reiss Romoli, 274, TORINO, 10148, Italy
   Jong-Hyouk Lee
   RSM Department, Telecom Bretagne
   Cesson-Sevigne, 35512, France
   Kostas Pentikousis
   Huawei Technologies
   Carnotstr. 4 10587 Berlin, Germany
   Tricci So
   Carlos J. Bernardos
   Universidad Carlos III de Madrid
   Av. Universidad, 30, Leganes, Madrid 28911, Spain
   Peter McCann
   Huawei Technologies
   Seok Joo Koh
   Kyungpook National University, Korea
   Wen Luo
   No.68, Zijinhua RD,Yuhuatai District, Nanjing, Jiangsu 210012, China
   Marco Liebsch
   NEC Laboratories Europe
   Carl Williams
   MCSR Labs