One document matched: draft-ietf-dmm-requirements-01.xml

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 PUBLIC '' 
  'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
]>

<?xml-stylesheet type='text/xsl' href='rfc2629.xslt'?>

<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no"?>
<?rfc strict="yes"?>
<?rfc compact="yes"?> 
<?rfc subcompact="no"?>

<rfc category="info" ipr="trust200902" 
docName="draft-ietf-dmm-requirements-01">

<front>
<title abbrev="DMM-Reqs">
Requirements of distributed mobility management
</title>

<author initials="H" surname="Chan (Ed.)" 
fullname="H Anthony Chan (editor)">
<organization>Huawei Technologies</organization>
<address>
<postal>

<street>5340 Legacy Dr. Building 3, Plano, TX 75024, USA</street>
<street>Email: h.a.chan@ieee.org</street>
<street>-</street>
<street>Dapeng Liu</street>
<street>China Mobile</street>
<street>Unit2, 28 Xuanwumenxi Ave, Xuanwu District, 
Beijing 100053, China</street>
<street>Email: liudapeng@chinamobile.com</street>
<street>-</street>
<street>Pierrick Seite</street>
<street>France Telecom - Orange</street>
<street>4, rue du Clos Courtel, BP 91226, 
Cesson-Sevigne 35512, France</street>
<street>Email: pierrick.seite@orange-ftgroup.com</street>
<street>-</street>
<street>Hidetoshi Yokota</street>
<street>KDDI Lab</street>
<street>2-1-15 Ohara, Fujimino, Saitama, 356-8502 Japan</street>
<street>Email: yokota@kddilabs.jp</street>
<street>-</street>
<street>Charles E. Perkins</street>
<street>Huawei Technologies</street>
<street>Email: charliep@computer.org</street>
<street>-</street>
<street>Jouni Korhonen</street>
<street>Nokia Siemens Networks</street>
<street>Email: jouni.korhonen@nsn.com</street>
<street>-</street>
<street>Melia Telemaco</street>
<street>Alcatel-Lucent Bell Labs</street>
<street>Email: telemaco.melia@alcatel-lucent.com</street>
<street>-</street>
<street>Elena Demaria</street>
<street>Telecom Italia</street>
<street>via G. Reiss Romoli, 274, TORINO, 10148, Italy</street>
<street>Email: elena.demaria@telecomitalia.it</street>
<street>-</street>
<street>Jong-Hyouk Lee</street>
<street>RSM Department, Telecom Bretagne</street>
<street>Cesson-Sevigne, 35512, France</street>
<street>Email: jh.lee@telecom-bretagne.eu</street>
<street>-</street>
<street>Tricci So</street>
<street>ZTE</street>
<street>Email: tso@zteusa.com</street>
<street>-</street>
<street>Carlos J. Bernardos</street>
<street>Universidad Carlos III de Madrid</street>
<street>Av. Universidad, 30, Leganes, Madrid 28911, Spain</street>
<street>Email: cjbc@it.uc3m.es</street>
<street>-</street>
<street>Peter McCann</street>
<street>Huawei Technologies</street>
<street>Email: PeterMcCann@huawei.com</street>
<street>-</street>
<street>Seok Joo Koh</street>
<street>Kyungpook National University, Korea</street>
<street>Email: sjkoh@knu.ac.kr</street>
<street>-</street>
<street>Wen Luo</street>
<street>ZTE</street>
<street>No.68, Zijinhua RD,Yuhuatai District, Nanjing, Jiangsu 210012, China</street>
<street>Email: luo.wen@zte.com.cn</street>
<street>-</street>
<street>Marco Liebsch</street>
<street>NEC Laboratories Europe</street>
<street>Email: liebsch@neclab.eu</street>
<street>-</street>
<street>Carl Williams</street>
<street>MCSR Labs</street>
<street>Email: carlw@mcsr-labs.org</street>
<street>-</street>

</postal>
</address>
</author>

<date month="July" year="2012"></date>
<area></area>
<workgroup></workgroup>
<abstract>

<t>
The traditional hierarchical structure of cellular networks 
has led to deployment models which are heavily centralized. 
Mobility management with centralized mobility anchoring 
in existing hierarchical mobile networks 
is quite prone to suboptimal routing
and issues related to scalability.
Centralized functions present a single point of 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
to match the mobility deployment 
with the current trend in network evolution,
to improve scalability,
to avoid single point of failure,
to enable transparency to upper layers 
only when needed,
etc.
The distributed mobility management also needs
to be compatible with 
existing network deployments and end hosts,
and be secured.
</t>
</abstract>
</front>

<middle>

<section anchor="intro" title="Introduction">

<t>
In the past decade a fair number of mobility protocols 
have been standardized. 
Although the protocols differ 
in terms of functions and associated message format, 
we can identify a few key common features:

<list>
<t>
presence of a centralized mobility anchor 
providing global reachability and an always-on experience;
</t>
<t>
extensions to optimize handover performance 
while users roam across wireless cells;
</t>
<t>
extensions to enable 
the use of heterogeneous wireless interfaces 
for multi-mode terminals 
(e.g. cellular phones).
</t>
</list>
</t>
<t>
The presence of the centralized mobility anchor 
allows a mobile device to be reachable 
when it is not connected to its home domain. 
The anchor point, among other tasks, 
ensures reachability 
of forwarding of packets 
destined to or sent from the mobile device. 
Most of the deployed architectures today 
have a small number of centralized anchors 
managing the traffic of millions of mobile subscribers.
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.
</t>

<t>
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 stringent requirements 
in terms of delay. 
Notions of localization and distribution of local agents 
have been introduced to reduce signaling overhead. 
Unfortunately today we witness difficulties 
in getting such protocols deployed,
often leading to sub-optimal choices. 
</t>

<t>
Moreover, the availability of multi-mode devices 
and the possibility of 
using several network interfaces simultaneously 
have motivated the development 
of more new protocol extensions.
Deployment is further complicated with so many extensions. 
</t>

<t>
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) 
through alternative access networks (e.g. WLAN). 
Moreover, the localization of content providers 
closer to 
the Mobile/Fixed Internet Service Providers network 
requires taking into account 
local Content Delivery Networks (CDNs) 
while providing mobility services.  
</t>

<t>
When demand exceeds capacity, 
both offloading and CDN techniques 
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 is reinforced 
by a shift in users traffic behavior,
aimed at increasing 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 the suboptimal routing issues 
of a centralized mobility scheme.

</t>

<t>
While deploying 
[Paper-Locating.User] 
today's mobile networks, 
service providers face new challenges. 
More often than not, 
mobile devices 
remain attached to the same point of attachment. 
Specific IP mobility management support 
is not required for applications 
that launch and complete 
while the mobile device is connected 
to the same point of attachment. 
However, 
the mobility support has been designed to be always on 
and to maintain the context for each mobile subscriber 
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 mobility and intelligence of many applications 
suggest that mobility can be provided dynamically, 
thus simplifying the context maintained 
in the different nodes of the mobile network.
</t>

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

<t>
This document describes 
the motivations of distributed mobility management
in Section 1.
Section 3 compares distributed mobility management
with centralized mobility management.
The requirements to address these problems
are given in Section 4.
</t>
<t>
The problem statement and the use cases
[I-D.yokota-dmm-scenario]
can be found in the following review paper: 
[Paper-Distributed.Mobility.Review].
</t>

</section>

<section title="Conventions used in this document">
<t>
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 <xref target="RFC2119" />.
</t>

<section title="Terminology">
<t>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 mobile node (MN), correspondent node (CN), home agent (HA), 
local mobility anchor (LMA), mobile access gateway (MAG), and context.
</t>

<t>
In addition, this draft introduces the following term. 
</t>

<t>
<list style='hanging'>

<t hangText='Mobility context'>
<vspace blankLines="1" />
is the collection of information 
required to provide mobility support for a given mobile node.
</t>

</list>
</t>

</section>

</section>


<section 
title="Centralized versus distributed mobility management">
<t>
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.
</t>

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

<t>
The next two subsections explain centralized and distributed
mobility management functions in the network.
</t>

<section title="Centralized mobility management">
<t>
With centralized mobility management, 
the mapping information between the stable node identifier 
and the changing IP address of a mobile node (MN) 
is kept at a centralized mobility anchor. 
Packets destined to an MN are routed via this anchor. 
In other words, 
such mobility management systems are centralized 
in both the control plane and the data plane.
</t>

<t>
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 <xref target="RFC6275"/> 
and Proxy Mobile IPv6 <xref target="RFC5213"/>, respectively. 
Current mobile 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 Gateway GPRS Support Node (GGSN) 
and Serving GPRS Support Node (SGSN) 
in the 3GPP UMTS hierarchical network 
and with Packet data network Gateway (P-GW) 
and Serving Gateway (S-GW) in the 3GPP EPS network.
</t>

      <figure>
        <preamble></preamble>
        <artwork><![CDATA[
       UMTS                3GPP SAE              MIP/PMIP
     +------+              +------+              +------+      
     | GGSN |              | P-GW |              |HA/LMA|      
     +------+              +------+              +------+      
        /\                    /\                    /\
       /  \                  /  \                  /  \
      /    \                /    \                /    \ 
     /      \              /      \              /      \
    /        \            /        \            /        \
+------+  +------+    +------+  +------+    +------+  +------+ 
| SGSN |  | SGSN |    | S-GW |  | S-GW |    |MN/MAG|  |MN/MAG| 
+------+  +------+    +------+  +------+    +------+  +------+  
      	]]></artwork>
        <postamble></postamble>
      </figure>

<t>Figure 1. Centralized mobility management.
</t>
</section>

<section title="Distributed mobility management">
<t>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). 
</t>

      <figure>
        <preamble></preamble>
        <artwork><![CDATA[
+------+  +------+  +------+  +------+    
|  MF  |  |  MF  |  |  MF  |  |  MF  |    
+------+  +------+  +------+  +------+    
                       |          
                     ----           
                    | MN |          
                     ----           
      	]]></artwork>
        <postamble></postamble>
      </figure>

<t>Figure 2. Distributed mobility management.
</t>
<t>
Mobility management may be partially distributed,
i.e., only the data plane is distributed,
or fully distributed
where both the data plane and control plane are distributed.
These different approaches are described in detail in 
[I-D.yokota-dmm-scenario].
</t>

<t>
[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. 
</t>

<t>
A distributed mobility management scheme is proposed in 
[Paper-Distributed.Dynamic.Mobility] 
for future flat IP architecture consisting of access nodes. 
The benefits of this design 
over centralized mobility management 
are also verified through simulations in 
[Paper-Distributed.Centralized.Mobility].
</t>
<t>
Before designing new mobility management protocols 
for a future flat IP architecture, 
one should first ask 
whether the existing mobility management protocols 
that have already been deployed 
for the hierarchical mobile networks 
can be extended to serve the 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. 
</t>

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

</section>

</section>


<section title="Requirements">
<t>
After comparing distributed mobility management
against centralized deployment in Section 3,
this section states 
the requirements as follows:
</t>

<!-- REQ1 -->
<section 
title="Distributed deployment">
<t>
<list style='format REQ%d:' counter="R_count">
<t>
Distributed deployment
<vspace blankLines="1" />
IP mobility, network access and routing solutions
provided by DMM 
MUST enable a distributed deployment 
of mobility management of IP sessions 
so that the traffic can be routed 
in an optimal manner 
without traversing 
centrally deployed mobility anchors. 
<vspace blankLines="1" />
Motivation: 
The motivations of this requirement are
to match mobility deployment 
with current trend in network evolution:
more cost and resource effective 
to cache and distribute contents 
when combining distributed anchors with caching systems 
(e.g., CDN); 
improve scalability; 
avoid single point of failure; 
mitigate threats 
being focused on a centrally deployed anchor, 
e.g., home agent and local mobility anchor. 
</t>
</list>
</t>

<t>
This requirement addresses the following problems 
PS1, PS2, PS3, and PS4.
</t>

<t>
<list style='format PS%d:' counter="PS_count">

<!-- PS1 -->
<t>
Non-optimal routes
<vspace blankLines="1" />
Routing via a centralized anchor 
often results in a longer route,
and the problem is especially manifested 
when accessing a local or cache server 
of a Content Delivery Network (CDN).
</t>

<!-- PS2 -->
<t>
Non-optimality in Evolved Network Architecture
<vspace blankLines="1" />
The centralized mobility management 
can become non-optimal 
as a network architecture evolves 
and becomes more flattened.
</t>

<!-- PS3 -->
<t>
Low scalability of centralized route 
and mobility context maintenance
<vspace blankLines="1" />
Setting up such special routes 
and maintaining the mobility context 
for each MN is more difficult to scale 
in a centralized design with a large number of MNs. 
Distributing the route maintenance function 
and the mobility context maintenance function 
among different networks can be more scalable.
</t>

<!-- PS4 -->
<t>
Single point of failure and attack
<vspace blankLines="1" />
Centralized anchoring 
may be more vulnerable 
to single point of failure and attack
than a distributed system. 
</t>

</list>
</t>


</section>

<!-- REQ2 -->
<section 
title="Transparency to Upper Layers when needed">
<t>
<list style='format REQ%d:' counter="R_count">
<t>
Transparency to Upper Layers when needed
<vspace blankLines="1" />
The DMM solutions MUST provide 
transparency above the IP layer when needed. 
Such transparency is needed, 
when the mobile hosts 
or entire mobile networks 
<xref target="RFC3963"/> 
change their point of attachment to the Internet, 
for the application flows 
that cannot cope with a change of IP address. 
Otherwise the support 
to maintain a stable home IP address or prefix 
during handover may be declined. 
<vspace blankLines="1" />
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 
when there is no such need.
</t>
</list>
</t>

<t>
This requirement addresses the problems 
PS5 as well as the other related problem O-PS1.
</t>

<!-- PS5 -->
<t>
<list style='format PS%d:' counter="PS_count">
<t>
Wasting resources to support mobile nodes 
not needing mobility support
<vspace blankLines="1" />
IP mobility support is not always required. 
For example, 
some applications do not need a stable IP address 
during handover, i.e., 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. 
</t>
</list>

<!-- O-PS1 -->
<list style='format O-PS%d:' counter="O-PS_count">
<t>
Mobility signaling overhead 
with peer-to-peer communication
<vspace blankLines="1" />
Wasting resources when mobility signaling 
(e.g., maintenance of the tunnel, keep alive, etc.) 
is not turned off for peer-to-peer communication. 
</t>
</list>

</t>


</section>

<!-- REQ3 -->
<section 
title="IPv6 deployment">
<t>
<list style='format REQ%d:' counter="R_count">
<t>
IPv6 deployment
<vspace blankLines="1" />
The DMM solutions SHOULD target IPv6 as primary deployment 
and SHOULD NOT be tailored specifically to support IPv4, 
in particular in situations 
where private IPv4 addresses and/or NATs are used.
<vspace blankLines="1" />
Motivation:
The motivation for this requirement is
to be inline with the general orientation of IETF. 
Moreover, 
DMM deployment is foreseen in mid-term/long-term,  
hopefully in an IPv6 world. 
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.
</t>
</list>
</t>
</section>

<!-- REQ4 -->
<section 
title="Compatibility">
<t>
<list style='format REQ%d:' counter="R_count">
<t>
Compatibility
<vspace blankLines="1" />
The DMM solution SHOULD be able to work 
between trusted administrative domains 
when allowed by the security measures 
deployed between these domains. 
Furthermore, 
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.
For example,
depending on the environment in which DMM is deployed,
the DMM solutions
may need to be compatible 
with other existing mobility protocols
that are deployed in that environment
or may need to be interoperable
with the network or the mobile hosts/routers
that do not support the DMM enabling protocol.
<vspace blankLines="1" />
Motivation: The motivation of this requirement is
to allow inter-domain operation
if desired and to preserve backwards compatibility 
so that the existing networks and hosts 
are not affected and do not break.
</t>
</list>
</t>


<t>
This requirement addresses 
the following other related problem O-PS2.
</t>

<t>
<!-- O-PS2 -->
<list style='format O-PS%d:' counter="O-PS_count">
<t>
Complicated deployment with 
too many variants and extensions of MIP
<vspace blankLines="1" />
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.
</t>
</list>
</t>

</section>

<!-- REQ5 -->
<section 
title="Existing mobility protocols">
<t>
<list style='format REQ%d:' counter="R_count">
<t>
Existing mobility protocols
<vspace blankLines="1" />
A DMM solution SHOULD 
first consider reusing 
and extending the existing mobility protocols 
before specifying new protocols.
<vspace blankLines="1" />
Motivation:
The purpose is to reuse the existing protocols first 
before considering new protocols.
</t>
</list>
</t>
</section>

<!-- REQ6 -->
<section 
title="Security considerations">
<t>
<list style='format REQ%d:' counter="R_count">
<t>
Security considerations
<vspace blankLines="1" />
The protocol solutions for DMM 
MUST consider security, 
for example 
authentication and authorization mechanisms 
that allow a legitimate mobile host/router 
to access to the DMM service, 
protection of signaling messages 
of the protocol solutions 
in terms of authentication, data integrity, 
and data confidentiality, 
opt-in or opt-out data confidentiality 
to signaling messages 
depending on network environments 
or user requirements.
<vspace blankLines="1" />
Motivation and problem statement:
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 attacks such as impersonation, 
denial of service, man-in-the-middle attacks, etc. 
are present to obtain illegitimate access 
or to collapse the DMM service. 
<vspace blankLines="1" />
Signaling messages are subject to various attacks 
since these messages carry context of a mobile host/router. 
For instance, 
a malicious node can forge 
and send a number of signaling messages 
to redirect traffic to a specific node. 
Consequently, the specific node is  
under a denial of service attack,
whereas other nodes are not receiving their traffic. 
As signaling messages travel over the Internet, 
the end-to-end security is required. 
</t>
</list>
</t>
</section>

</section>


<section anchor="security" title="Security Considerations">
<t>
Distributed mobility management (DMM) 
requires two kinds of security considerations:
1) access network security 
that only allows 
a legitimate mobile host/router 
to access the DMM service; 
2) 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 protocol.
</t>
<t>
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 authentication 
can be used for access network security, 
while IPsec can be used 
for end-to-end security.
</t>
</section>


<section title="IANA Considerations">
<t>None</t>
</section>


<section title="Co-authors and Contributors">
<t>This problem statement document is a joint effort 
among the following participants. 
Each individual has made significant contributions 
to this work. 
</t>

<t>Dapeng Liu: liudapeng@chinamobile.com</t>
<t>Pierrick Seite: pierrick.seite@orange-ftgroup.com</t>
<t>Hidetoshi Yokota: yokota@kddilabs.jp</t>
<t>Charles E. Perkins: charliep@computer.org</t>
<t>Melia Telemaco: telemaco.melia@alcatel-lucent.com</t>
<t>Elena Demaria: elena.demaria@telecomitalia.it</t>
<t>Peter McCann: Peter.McCann@huawei.com</t>
<t>Tricci So: tso@zteusa.com</t>
<t>Jong-Hyouk Lee: jh.lee@telecom-bretagne.eu</t>
<t>Jouni Korhonen: jouni.korhonen@nsn.com</t>
<t>Sri Gundavelli: sgundave@cisco.com</t>
<t>Carlos J. Bernardos: cjbc@it.uc3m.es</t>
<t>Marco Liebsch: Marco.Liebsch@neclab.eu</t>
<t>Wen Luo: luo.wen@zte.com.cn</t>
<t>Georgios Karagiannis: g.karagiannis@utwente.nl</t>
<t>Julien Laganier: jlaganier@juniper.net</t>
<t>Wassim Michel Haddad: Wassam.Haddad@ericsson.com</t>
<t>Seok Joo Koh: sjkoh@knu.ac.kr</t>
<t>Dirk von Hugo: Dirk.von-Hugo@telekom.de</t>
<t>Ahmad Muhanna: amuhanna@awardsolutions.com</t>


</section>

</middle>


<back>

<references title="Normative References">
  &rfc2119;
</references>

<references title="Informative References">
<?rfc include="reference.RFC.6275" ?>
<?rfc include="reference.RFC.5213" ?>
<?rfc include="reference.RFC.3963" ?>

<reference anchor="I-D.yokota-dmm-scenario">
<front>
<title>Use case scenarios 
for Distributed Mobility Management</title> 
<author initials="H" surname="Yokota" 
fullname="Hidetoshi Yokota">
  <organization /> 
</author>
<author initials="P" surname="Seite" 
fullname="Pierrick Seite">
  <organization /> 
</author>
<author initials="E" surname="Demaria" 
fullname="Elena Demaria">
  <organization /> 
</author>
<author initials="Z" surname="Cao" fullname="Zhen Cao">
  <organization /> 
</author>
<date day="18" month="October" year="2010" /> 
</front>
<seriesInfo name="Internet-Draft" 
 value="draft-yokota-dmm-scenario-00" /> 
<format type="TXT" target=
 "http://www.ietf.org/internet-drafts/draft-yokota-dmm-scenario-00.txt"/> 
</reference>

<reference anchor="I-D.ietf-netext-pd-pmip">
<front> 
<title>Prefix Delegation for Proxy Mobile IPv6</title> 
<author fullname="Xingyue Zhou" surname="Zhou" initials="X">
 <organization/>
</author> 
<author fullname="Jouni Korhonen" surname="Korhonen" initials="J"> 
 <organization/> 
</author> 
<author fullname="Carl Williams" surname="Williams" initials="C"> 
 <organization/> 
</author> 
<author fullname="Sri Gundavelli" surname="Gundavelli" initials="S"> 
 <organization/> 
</author> 
<author fullname="Carlos Bernardos" surname="Bernardos" initials="C"> 
 <organization/> 
</author> 
<date year="2012" day="12" month="March"/> 
<abstract>
<t>Proxy Mobile IPv6 enables IP mobility for a host without requiring its participation in any mobility signaling, being the network responsible for managing IP mobility on behalf of the host. However, Proxy Mobile IPv6 does not support assigning a prefix to a router and managing its IP mobility. This document specifies an extension to Proxy Mobile IPv6 protocol for supporting network mobility using DHCPv6-based Prefix Delegation.
</t>
</abstract> 
</front> 
<seriesInfo value="draft-ietf-netext-pd-pmip-02" 
 name="Internet-Draft"/> 
<format type="TXT" 
 target="http://www.ietf.org/internet-drafts/draft-ietf-netext-pd-pmip-02.txt"/> 
</reference>

<reference anchor="Paper-Locating.User">
<front>
<title>Locating the User</title>
<author initials="G" surname="Kirby">
  <organization />
</author>
<date year="1995" />
</front>
<seriesInfo name="" value="Communication International" />
</reference>

<reference anchor="Paper-Distributed.Dynamic.Mobility">
<front>
<title>A Distributed Dynamic Mobility Management Scheme 
Designed for Flat IP Architectures</title>
<author initials="P" surname="Bertin">
  <organization />
</author>
<author initials="S" surname="Bonjour">
  <organization />
</author>
<author initials="J-M" surname="Bonnin">
  <organization />
</author>
<date year="2008" />
</front>
<seriesInfo name="" 
value="Proceedings of 3rd International Conference 
on New Technologies, Mobility and Security (NTMS)" />
</reference>

<reference anchor="Paper-Distributed.Centralized.Mobility">
<front>
<title>A Distributed or Centralized Mobility</title>
<author initials="P" surname="Bertin">
  <organization />
</author>
<author initials="S" surname="Bonjour">
  <organization />
</author>
<author initials="J-M" surname="Bonnin">
  <organization />
</author>
<date month="December" year="2009" />
</front>
<seriesInfo name="" 
value="Proceedings of Global Communications Conference 
(GlobeCom)" />
</reference>

<reference anchor="Paper-Migrating.Home.Agents">
<front>
<title>Migrating Home Agents 
Towards Internet-scale Mobility Deployments</title>
<author initials="R" surname="Wakikawa">
  <organization />
</author>
<author initials="G" surname="Valadon">
  <organization />
</author>
<author initials="J" surname="Murai">
  <organization />
</author>
<date month="December" year="2006" />
</front>
<seriesInfo name="" 
value="Proceedings of the ACM 2nd CoNEXT Conference 
on Future Networking Technologies" />
</reference>

<reference anchor="Paper-Distributed.Mobility.SAE">
<front>
<title>A Distributed IP Mobility Approach for 3G SAE</title>
<author initials="M" surname="Fisher">
  <organization />
</author>
<author initials="F.U" surname="Anderson">
  <organization />
</author>
<author initials="A" surname="Kopsel">
  <organization />
</author>
<author initials="G" surname="Schafer">
  <organization />
</author>
<author initials="M" surname="Schlager">
  <organization />
</author>
<date year="2008" />
</front>
<seriesInfo name="" 
value="Proceedings of the 19th International Symposium 
on Personal, Indoor and Mobile Radio Communications (PIMRC)" 
/>
</reference>

<reference anchor="Paper-Distributed.Mobility.Review">
<front>
<title>Distributed and Dynamic Mobility Management 
in Mobile Internet: Current Approaches and Issues,
Journal of Communications, vol. 6, no. 1, pp. 4-15, Feb 2011.
</title>
<author initials="H" surname="Chan">
  <organization />
</author>
<author initials="H" surname="Yokota">
  <organization />
</author>
<author initials="J" surname="Xie">
  <organization />
</author>
<author initials="P" surname="Seite">
  <organization />
</author>
<author initials="D" surname="Liu">
  <organization />
</author>

<date month="February" year="2011" />
</front>
<seriesInfo name="" 
value="Proceedings of GlobeCom Workshop 
on Seamless Wireless Mobility" />
</reference>

<reference anchor="Paper-Distributed.Mobility.PMIP">
<front>
<title>Proxy Mobile IP 
with Distributed Mobility Anchors</title>
<author initials="H" surname="Chan">
  <organization />
</author>
<date month="December" year="2010" />
</front>
<seriesInfo name="" 
value="Proceedings of GlobeCom Workshop 
on Seamless Wireless Mobility" />
</reference>

<reference anchor="Paper-Distributed.Mobility.MIP">
<front>
<title>Distributed Mobility Management with Mobile IP</title>
<author initials="H" surname="Chan">
  <organization />
</author>
<date month="June" year="2012" />
</front>
<seriesInfo name="" 
value="Proceedings of 
IEEE International Communication Conference (ICC) 
Workshop on Telecommunications: 
from Research to Standards" />
</reference>

</references>

</back>
</rfc>