Network Working Group N. Neumann
Internet-Draft X. Fu
Expires: July 12, 2009 J. Lei
University of Goettingen
G. Zhang
Huawei Technologies Co., Ltd.
January 8, 2009
Inter-Domain Handover and Data Forwarding between Proxy Mobile IPv6
Domains
draft-neumann-netlmm-inter-domain-01
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on July 12, 2009.
Copyright Notice
Copyright (c) 2009 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
(http://trustee.ietf.org/license-info) 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.
Neumann, et al. Expires July 12, 2009 [Page 1]
Internet-Draft Inter-Domain PMIP January 2009
Abstract
This document specifies mechanisms to setup and maintain handover and
data forwarding procedures that allow a mobile node to move between
different domains that provide (localized) network-based mobility
support based on Proxy Mobile IPv6 for that node.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions & Terminology . . . . . . . . . . . . . . . . . . 3
2.1. Conventions used in this document . . . . . . . . . . . . 3
2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Finding the Session Mobility Anchor . . . . . . . . . . . 5
3.1.1. Direct Location . . . . . . . . . . . . . . . . . . . 5
3.1.2. Indirect Location . . . . . . . . . . . . . . . . . . 5
3.2. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 6
4. Inter-Domain Mobility Support . . . . . . . . . . . . . . . . 6
4.1. Registration of a new Mobile Node . . . . . . . . . . . . 6
4.2. Local Routing . . . . . . . . . . . . . . . . . . . . . . 7
5. Local Mobility Anchor Considerations . . . . . . . . . . . . . 7
5.1. Support to find the Session Mobility Anchor . . . . . . . 7
5.1.1. Direct SMA Location . . . . . . . . . . . . . . . . . 8
5.1.1.1. Processing of an Initial Binding Registration . . 8
5.1.1.2. Querying the Common Database . . . . . . . . . . . 8
5.2. Processing Proxy Binding Updates . . . . . . . . . . . . . 8
5.2.1. LMA to SMA PBU . . . . . . . . . . . . . . . . . . . . 8
5.2.2. MAG to LMA PBU . . . . . . . . . . . . . . . . . . . . 8
5.2.3. MAG to SMA PBU . . . . . . . . . . . . . . . . . . . . 8
6. Inter-Domain Security . . . . . . . . . . . . . . . . . . . . 9
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
8. Security Considerations . . . . . . . . . . . . . . . . . . . 9
8.1. Intra-domain securtiy considerations . . . . . . . . . . . 9
8.2. Inter-domain security considerations . . . . . . . . . . . 9
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
9.1. Normative References . . . . . . . . . . . . . . . . . . . 10
9.2. Informative References . . . . . . . . . . . . . . . . . . 10
Appendix A. Open Issues . . . . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
Neumann, et al. Expires July 12, 2009 [Page 2]
Internet-Draft Inter-Domain PMIP January 2009
1. Introduction
A mobile node in the current Internet needs to maintain a fixed
endpoint when it moves to allow for seamless connectivity with its
corresponding nodes. When the mobile nodes moves between network-
based mobility domains that are under different administrative
control, this becomes challenging. One network is responsible for
the communication endpoint while the other network provides the
actual mobility services to the mobile node. This document proposes
an approach to solve this problem by using inter-domain signaling to
setup session handover and data forwarding between the different
domains.
A network-based localized mobility management solution like Proxy
Mobile IPv6 (PMIPv6) [RFC5213] provides a mobile node with mobility
within the PMIPv6-enabled domain it is deployed in. When the mobile
node leaves the network, however, the mobility support breaks since
the mobile node moves out of the administrative reach of the local
mobility solution.
2. Conventions & Terminology
2.1. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
2.2. Terminology
Mobility Session
The period of time in which the mobile node needs mobility support
from the network. If the mobile node reaches a state where it
currently does not need mobility support, the mobility session can
safely be reset. During a mobility session the network-based
mobility solution described in this document offers the mobile a
fixed end-point for its communications, namely the session
mobility anchor, which stays valid even when the mobile node moves
between Proxy Mobile IP domains.
Session Mobility Anchor
A fixed end-point which relays all the communication for the
mobile node. This is the local mobility anchor of the first Proxy
Mobile IP domain that a mobile node is connected to during a
mobility session.
Neumann, et al. Expires July 12, 2009 [Page 3]
Internet-Draft Inter-Domain PMIP January 2009
3. Overview
In order to provide continuous mobility support for a mobile nodes
that is moving between different mobility domains, a steady anchor
point has to be provided for corresponding nodes. In Mobile IP, for
example, this is the home agent while in Proxy Mobile IP this is the
local mobility anchor (LMA). This anchor point allows the mobile
node to change its point of attachment to a network without its
corresponding nodes noticing that. All the mobile node's traffic is
routed through the local mobility anchor which then forwards the
traffic to the mobile node. When a mobile node leaves a Proxy Mobile
IP domain, however, it moves beyond the control of the local mobility
anchor and therefore its mobility breaks.
When a mobile node initially attaches to a Proxy Mobile IP domain,
the local mobility anchor becomes the session mobility anchor (SMA)
for the mobile node. For the duration of the mobility session this
session mobility anchor will handle all incoming and outgoing
connections for the mobile node. As long as the mobile node stays
within the local Proxy Mobile IP domain, this only includes regular
Proxy Mobile IPv6 operations as described in [RFC5213]. When the
mobile node leaves the local Proxy Mobile IP domain, however, the new
Proxy Mobile IP domain's local mobility anchor will initialize a
tunnel to the session mobility anchor to allow the session mobility
anchor to continue serving as an anchor point for the mobile node.
Within the new Proxy Mobile IP domain all regular Proxy Mobile IP
operations still apply with the exception that all traffic for the
mobile node is tunneled from the new local mobility anchor to the
session mobility anchor which in turn communicates with the
correspondent node.
[CN]
||
||
[LMA_1 >===========================================> [LMA_3]
= SMA]] >=================> [LMA_2] Tunnel |
| Tunnel | |
| | |
| | |
| | |
[MAG] [MAG] [MAG]
| | |
MN ------------------------> MN ----------------------> MN
Movement Movement
Figure 1: Movement
Neumann, et al. Expires July 12, 2009 [Page 4]
Internet-Draft Inter-Domain PMIP January 2009
For all intends and purposes from the point of view of the session
mobility anchor, the current local mobility anchor of a mobile node
can be seen as a mobile access gateway which performs the
corresponding operations.
3.1. Finding the Session Mobility Anchor
When a mobile node attaches to a Proxy Mobile IP domain, the local
mobility anchor of this domain has to locate the session mobility
anchor for this mobile node and initiate a tunnel between itself and
the session mobility anchor. In case the Proxy Mobile IP domain is
the first domain the mobile node attaches to within its mobility
session, the current local mobility anchor becomes the session
mobility anchor and continues with its regular Proxy Mobile IP
operations. If the mobile node already has been attached to a
different Proxy Mobile IP domain, it's session mobility anchor
resides within this previous domain and the local mobility anchor
needs to establish a binding with the session mobility anchor in
order to send and receive the data for the mobile node through its
session mobility anchor. Depending on the scenario, the local
mobility anchor can directly or indirectly locate the session
mobility anchor for a mobile node.
3.1.1. Direct Location
Direct location of a session mobility anchor for a mobile node
requires some kind of look-up between associated Proxy Mobile IP
domains. For example, this can be achieved by maintaining a common
database where session mobility anchors deposit the information for
which mobile node they are responsible for. Such a database can be
established by service level agreements between the operators of
Proxy Mobile IP domains. For a local mobility anchor to locate the
session mobility anchor for a mobile node it will send a look-up
request to the database using the mobile node's identity (e.g. its
Network Access Identifier (NAI) [RFC4282]) as the look-up key. If
the database does not have an entry for the mobile node, the local
mobility anchor becomes the session mobility anchor for the mobility
session of the mobile node.
3.1.2. Indirect Location
If no common database exists between Proxy Mobile IP domains, the
local mobility anchor can use an indirect scheme to locate the
session mobility anchor of a mobile node. For this purpose, the
local mobility anchor infers the session mobility anchor assigned IP
address of the mobile node and uses this address to send its session
transfer request to. Since the session mobility anchor is
responsible for this IP address, the local mobility anchor will
Neumann, et al. Expires July 12, 2009 [Page 5]
Internet-Draft Inter-Domain PMIP January 2009
indirectly reach the session mobility anchor. If there is no reply
to the request, the local mobility anchor must assume that no
previous session mobility anchor exists and itself become the session
mobility anchor for the mobility session of the mobile node. The
session mobility anchor assigned IP address of a mobile node is the
IP address the mobile node got assigned when it initially attached to
a Proxy Mobile IP domain. The local mobility anchor can try to infer
this IP address, for example, by analyzing the mobile node's Router
Solicitation messages [RFC4861] or DHCP requests [RFC3315].
3.2. Assumptions
This document assumes that there are some operational agreements
between the operators of the different Proxy Mobile IP domains. Part
of this agreement are, for example, the conditions under which users
are allowed to move between domains and the location method that is
used to find the session mobility anchor.
4. Inter-Domain Mobility Support
4.1. Registration of a new Mobile Node
When a new mobile node attaches to a Proxy Mobile IP domain, the
corresponding local mobility anchor registers itself as the new local
mobility anchor for the mobile node with the session mobility anchor
of the mobile node.
[MN] [MAG] [LMA] [SMA]
| | | |
Attaches | | |
| | | |
|--Rtr Sol ->| | |
| | | |
| |--PBU----->| |
| | | |
| | |------PBU--->|
| | | |
| | |<-----PBA----|
| | |===Tunnel====|
| | | |
| |<---PBA----| |
| |==Tunnel===| |
| | | |
|<--Rtr Adv--| | |
| | | |
Neumann, et al. Expires July 12, 2009 [Page 6]
Internet-Draft Inter-Domain PMIP January 2009
Figure 2: Signal Flow
Figure Figure 2 shows the signaling flow when a mobile node attaches
to a Proxy Mobile IP domain. As in the normal Proxy Mobile IP case,
the mobile node sends a Router Solicitation message that is received
by the local mobile access gateway. The mobile access gateway then
sends its Proxy Binding Update (PBU) to the local mobility anchor.
To register itself with the session mobility anchor as the new local
mobility anchor for the mobile node, the local mobility anchor
forwards this Proxy Binding Update to the session mobility anchor.
The session mobility anchor then determines the corresponding
policies for the mobile node as it would for a local mobile node and
constructs the Proxy Binding Acknowledgment (PBA). The Proxy Binding
Acknowledgment is then sent to the local mobility anchor as if it
were a local mobile access gateway and a bi-directional tunnel is
established between the session mobility anchor and the local
mobility anchor. The local mobility anchor forwards the received
Proxy Binding Acknowledgment to its mobile access gateway which in
turn uses the Proxy Binding Acknowledgment to configure the mobile
node. Also, the local mobility anchor establishes the bi-direct
tunnel to this mobile access gateway. All traffic for the mobile
node is then routed from the session mobility anchor through the
local mobility anchor and the mobile access gateway. All future
movements of the mobile node within the new Proxy Mobile IPv6 domain
are covered by local mobility operations as described in [RFC5213].
4.2. Local Routing
Traffic might occur between nodes that are currently allocated in the
same mobility domain but are associated with session mobility anchors
outside this domain. The local mobility anchor of the domain MAY
optimize the delivery of this traffic by locally routing the packets
instead of sending them over the corresponding session mobility
anchor(s). The flag EnableMAGLocalRouting MAY be used for
controlling this behavior. For further local routing considerations,
see Section 6.10.3. of the Proxy Mobile IPv6 (PMIPv6) document
[RFC5213].
5. Local Mobility Anchor Considerations
5.1. Support to find the Session Mobility Anchor
The LMA is responsible to either act as a SMA for nodes that attach
to its domain originally or to locate the corresponding SMA for nodes
that move to its domain from another domain. In the first case, the
LMA needs to support operations that allow it to be found and queried
by other LMAs for mobility session related data. In the later case,
Neumann, et al. Expires July 12, 2009 [Page 7]
Internet-Draft Inter-Domain PMIP January 2009
the LMA needs to perform these locating and querying operations
itself. This document describes two operating schemes for this
purpose: the direct location of the SMA and the indirect location of
the SMA.
5.1.1. Direct SMA Location
As explained in Section 3.1.1 the direct location of the SMA is
performed using a common database between the participating PMIP
domains.
5.1.1.1. Processing of an Initial Binding Registration
Upon the reception of an Initial Binding Registration (cf. Section
5.3.2. [RFC5213]) the LMA MUST query the common database for a SMA
for the corresponding mobile node. If a SMA is returned the LMA will
act as a visited LMA and send a corresponding PBU to the SMA. If not
SMA is returned, the LMA will act as a SMA for the mobile node and
update the database accordingly. Afterwards the LMA processes the
Initial Binding Registration as specified in [RFC5213].
5.1.1.2. Querying the Common Database
...
5.2. Processing Proxy Binding Updates
5.2.1. LMA to SMA PBU
If a SMA receives a PBU from a LMA it MUST assume that the mobile
node moved to the PMIP domain the LMA is responsible for. The SMA
MUST process the PBU as it would process a PBU from any of the MAGs
in its own domain.
5.2.2. MAG to LMA PBU
If a LMA that is not the SMA for a mobile node receives a PBU which
is not part of an Initial Binding Registration it MUST process the
PBU as it would process any other PBU. If the PBU is successful it
MUST also send a Binding Lifetime Extension PBU to the SMA.
5.2.3. MAG to SMA PBU
If a SMA receives a PBU from a MAG within its own domain it MUST
process it like it would process the PBU as a LMA.
Neumann, et al. Expires July 12, 2009 [Page 8]
Internet-Draft Inter-Domain PMIP January 2009
6. Inter-Domain Security
This document introduces signaling and data forwarding between
different Proxy Mobile IP domains which needs to be protected. Proxy
Mobile IP itself recommends using IPsec with established security
associations to protect the signaling messages, Proxy Binding Update
and Proxy Binding Acknowledgment message exchanges between the mobile
access gateway and the local mobility anchor. This document extends
this recommendation for all message exchanges between the session
mobility anchor and the local mobility anchor including forwarded
data for the mobile node. How the IPsec associations are established
is beyond this document.
7. IANA Considerations
8. Security Considerations
This section deals with the considerations related to intra-domain
security within one Proxy Mobile IP domain and inter-domain security
between different Proxy Mobile IP domains that are involved in
managing a mobile nodes mobility.
8.1. Intra-domain securtiy considerations
This document does not change any intra-domain mobility procedures
and therefore does not introduce additional intra-domain security
risks. The security considerations in [RFC5213] cover security risks
inside a Proxy Mobile IPv6 domain.
8.2. Inter-domain security considerations
The signaling and data forwarding between different Proxy Mobile IP
domains where the session mobility anchor resides in one domain and
the current local mobility anchor for a mobile node resides in the
other domain is recommended to be protected by using IPsec with
established security associations. This means that the local
mobility anchor establishes and maintains an IPsec tunnel to the
session mobility anchor which is used for communications. How these
security associations are established is beyond this document. It is
recommended, however, to establish some kind of service agreements
between service providers to specify security constraints and to
arrange the valid endpoints (i.e. the local mobility anchor and
session mobility anchor addresses).
In opposite to plain Proxy Mobile IPv6, the signaling between the
session mobility anchor and the mobile node traverses not only the
Neumann, et al. Expires July 12, 2009 [Page 9]
Internet-Draft Inter-Domain PMIP January 2009
Internet but also the local network of the current Proxy Mobile IP
domain. The signaling between the session mobility anchor and the
mobile node is, therefore, at least exposed to the current local
mobility anchor, and the corresponding mobile access gateways in the
current Proxy Mobile IP domain. Especially for applicable
authentication procedures between the session mobility anchor and the
mobile node, the session mobility anchor is recommended to only use
procedures that cannot be exploited by overhearing parties.
9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K.,
and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.
9.2. Informative References
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
and M. Carney, "Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The
Network Access Identifier", RFC 4282, December 2005.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
September 2007.
Appendix A. Open Issues
o better definition of mobility session (when to start a new
session)
o extend inter domain security issues
o De-Registration of a MN
Neumann, et al. Expires July 12, 2009 [Page 10]
Internet-Draft Inter-Domain PMIP January 2009
Authors' Addresses
Niklas Neumann
University of Goettingen
Computer Networks Group
Goldschmidtstrasse 7
Goettingen 37077
Germany
Email: neumann@cs.uni-goettingen.de
Xiaoming Fu
University of Goettingen
Computer Networks Group
Goldschmidtstrasse 7
Goettingen 37077
Germany
Email: fu@cs.uni-goettingen.de
Jun Lei
University of Goettingen
Computer Networks Group
Goldschmidtstrasse 7
Goettingen 37077
Germany
Email: lei@cs.uni-goettingen.de
Gong Zhang
Huawei Technologies Co., Ltd.
Corporate Research Department
B-1 Building, Longgang
Shenzhen 518129
P.R.China
Email: Nicholas@huawei.com
Neumann, et al. Expires July 12, 2009 [Page 11]