NETLMM Working Group K. Taniuchi
Internet-Draft V. Fajardo
Expires: September 1, 2007 Y. Ohba
TARI
A. Dutta (Ed.)
Telcordia
H. Schulzrinne
Columbia Univ.
February 28, 2007
Media Independent Pre-authentication supporting fast-handoff in PMIPv6
draft-taniuchi-netlmm-mpa-proxymipv6-00
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of 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 September 1, 2007.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Taniuchi, et al. Expires September 1, 2007 [Page 1]
Internet-Draft MPA-asissted PMIP February 2007
Abstract
This document describes a proactive mechanism to provide fast-
handover involving PMIPv6. In particular, it describes how one can
achieve fast handoff for PMIPv6 using Media-independent Pre-
Authentication (MPA) technique. It discusses the need for a fast-
handoff for PMIPv6 environment. It then describes how MPA techniques
could be used during different steps involving both intra-domain and
inter-domain handoff for PMIPv6. MPA-based fast-handover takes
advantage of the pre-authentication mechanism so that the mobile can
perform the access authentication while in the previous local
mobility (PMA) domain and thus would be able to complete many of the
handoff related operations while still in the previous network.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Media Independent Preauthentication-assisted fast-handoff
for PMIPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Intra-domain Handoff . . . . . . . . . . . . . . . . . . . 5
2.1.1. Bootstrapping State . . . . . . . . . . . . . . . . . 5
2.1.2. Mobile is impending to move . . . . . . . . . . . . . 7
2.1.3. Preauthentication phase . . . . . . . . . . . . . . . 8
2.1.4. Proactive Tunnel Creation . . . . . . . . . . . . . . 11
2.1.5. Proactive proxy binding update . . . . . . . . . . . . 12
2.1.6. Tunnel creation between nPMA and HA . . . . . . . . . 13
2.1.7. Proactive tunnel deletion . . . . . . . . . . . . . . 14
2.1.8. Movement to the new network . . . . . . . . . . . . . 15
2.2. Inter-domain Handoff . . . . . . . . . . . . . . . . . . . 16
2.2.1. Bootstrapping State . . . . . . . . . . . . . . . . . 17
2.2.2. Mobile is impending to move . . . . . . . . . . . . . 18
2.2.3. Preauthentication Phase . . . . . . . . . . . . . . . 19
2.2.4. Proactive Tunnel Creation . . . . . . . . . . . . . . 19
2.2.5. Proactive Proxy Binding Update . . . . . . . . . . . . 19
2.2.6. Tunnel between nPMA and nHA . . . . . . . . . . . . . 21
2.2.7. Data Flow when mobile in pPoA . . . . . . . . . . . . 21
2.2.8. Tunnel Deletion . . . . . . . . . . . . . . . . . . . 23
2.2.9. Movement to the new network . . . . . . . . . . . . . 24
3. Security Considerations . . . . . . . . . . . . . . . . . . . 26
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29
6.1. Normative References . . . . . . . . . . . . . . . . . . . 29
6.2. Informative References . . . . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30
Intellectual Property and Copyright Statements . . . . . . . . . . 32
Taniuchi, et al. Expires September 1, 2007 [Page 2]
Internet-Draft MPA-asissted PMIP February 2007
1. Introduction
The goals and advantages for local mobility management have duly been
documented in the problem statement [I-D.kempf-netlmm-nohost-ps] and
no-host-requirement [I-D.kempf-netlmm-nohost-req] drafts. Advantage
of local mobility management is to optimize many of the functions
related to mobility and reduce the number of signaling messages over
the air. In network localized mobility management paradigm, when the
mobile moves from one MAG to another MAG, and its movement is limited
within one LMA, the following operations must be performed. It can
broadly be classified into few steps such as layer 2 movement,
detection of new link (DNA), router solicitation, access
authentication, profile verification, proxy binding update and
address re-configuration. This paradigm can also be extended so that
the mobile can move between two LMAs for inter-domain case. LMA
nomenclature can be interchanged with HA and MAG can be interchanged
with PMA in this document.
We describe some of the steps involved during network localized
movement in details in the following paragraps as described in the no
host requirement draft.
1) Link layer signaling required for handover, reassociation, and re-
authentication. For example, in 802.11, this is the ReAssociate
message together with 802.1x re-authentication using EAP.
2) Active IP level movement detection, including router reachability:
The DNA protocol uses Router Solicitation/Router Advertisement for
this purpose. In addition, if Secured Neighbor Discovery (SEND) is
used and the mobile node does not have a certificate cached for the
router, the mobile node must use Certification Path Solicitation/
Certification Path Advertisement to obtain a certification path.
3) Once the movement detection is complete, the mobile will need to
configure its IP address based on the prefix advertisement from the
MAG. But if the prefix is the same as the old prefix it gets
configured with the same IP address.
4) But the mobile still goes through the process of re-authentication
in the new point-of-attachment. After the re-authentication is
complete, it will trigger the establishment of the tunnel between the
MAG (PMA) and the LMA (HA). Thus, any traffic destined to the mobile
node will be sent over the tunnel and will be delivered to the
mobile.
If this movement is extended to inter-domain movement, then the PMAs
(MAGs) may belong to two different LMA. The respective MAGs can also
be called as pPMA and nPMA.
Taniuchi, et al. Expires September 1, 2007 [Page 3]
Internet-Draft MPA-asissted PMIP February 2007
It appears at least from the current version of PMIP draft
[I-D.sgundave-mipv6-proxymipv6] that the mobile during its movement
within a PMIP domain (when it moves from one PMA link to another PMA
link), it still goes through an IP address configuration process,
even though it does not change its IP address in the new link. Thus,
let us say for stateless auto-configuration mode, things like,
sending a RS upon DNA (in case of link change), obtaining a home
prefix from the router (PMA) and configuring an address (by appending
its link-layer address with the prefix) are mandatory even if the new
address generated is same as the address the mobile had in the old
PMA link. Thus it is almost similar to re-initiating the address
configuration process. In addition, LMA (HA) takes some time to be
able to complete the proxy binding update and set up the tunnel
between PMA (MAG) and LMA (HA). Thus, even if the handoff delay is
reduced compared to the global mobility protocol, and there is less
signaling exchange over the air, there is still an appreciable amount
of delay due to other components involved in the handoff process.
These components include access authentication, profile verification,
home address reconfiguration and binding update. Things appear to be
more complicated and handoff takes more time for inter-domain case,
as it involves two home agents in each domain and the home prefix
advertisement is different in each domain.
This draft attempts to reduce the delay due to access authentication,
tunnel setup, binding update and media forwarding by applying the
media independent pre-authentication techniques for both intra-domain
and inter-domain cases. Media Independent pre-authentication
techniques [I-D.ohba-mobopts-mpa-framework] can also provide a
proactive fast-handoff technique for PMIPv6. Some of the results
using MPA framework can be found in
[I-D.ohba-mobopts-mpa-implementation].
Taniuchi, et al. Expires September 1, 2007 [Page 4]
Internet-Draft MPA-asissted PMIP February 2007
2. Media Independent Preauthentication-assisted fast-handoff for PMIPv6
This proposal provides the mechanism based on media independent pre-
authentication by which both intra-domain and inter-domain handoff
delays are reduced, thereby reducing the packet loss as well when
ProxyMIPv6 is used as the protocol for handoff. We cover the
mechanisms associated with both the handoff cases. In intra-domain
case, the mobile moves between the PMAs that are under the same LMA.
Thus both the PMAs send the same home prefix as part of their router
advertisement. During Inter-domain case, the LMAs (PMAs) are
different. Thus, each of the PMAs belonging to each LMA advertises a
different prefix as part of the router advertisement. We describe
how MPA can help speed up the handoff for both the cases in details.
2.1. Intra-domain Handoff
In this section, we describe the MPA procedures that are needed to
support fast-handoff for the mobile thereby reducing the packet loss
when the movement is limited to intra-domain case.
2.1.1. Bootstrapping State
Figure 1 shows an initial bootstrapping scenario, where the mobile
(MN) boots up in a cell that is under pPMA. In this case, both pPMA
and nPMA are under the same LMA which is HA (Home Agent) in this
case. When the mobile is connected to the pPoA, it completes the
access authentication procedure by sending its NAI and other profile
related to mobile to the pPMA. pPMA forwards it to AAA server to
obtain the prefix related to the mobile. pPMA actually does co-exist
with the access router PAR in this case. We also assume that the
first hop access router is equipped with other layer 3 authentication
agent such as PAA (PANA Authentication Agent) [I-D.ietf-pana-pana].
As part of the initial access authentication, the mobile can perform
an EAP by communicating with the local authenticator PAA and the AAA
server. After the initial authentication is over, the PMA gets the
home prefix for the mobile and sends it as part of the router
advertisement. After the mobile gets the home prefix, it configures
itself with the home address HoA and then configures its default
router to be PMA. At this point the PMA sends the proxy binding
update to the HA on behalf of the mobile. The tunnel gets created
between the pPMA and the HA after the binding update procedure is
complete. Data from any host destined to the mobile will be
intercepted by the HA, and the HA will send this data to pPMA. This
data will have the current IP addressing scheme. Outer tunnel will
have a source address HA and destination address pPMA. The inner
data will have the source address ANY and the inner address HoA.
Once pPMA gets this data, it will strip off the outer header and
deliver the inner data to the mobile. Data delivery path can be
Taniuchi, et al. Expires September 1, 2007 [Page 5]
Internet-Draft MPA-asissted PMIP February 2007
shown as follows. Data Packet: CN -> HoA, PMIP Tunnel: Outer HA ->
pPMA, Inner ANY -> HoA
Taniuchi, et al. Expires September 1, 2007 [Page 6]
Internet-Draft MPA-asissted PMIP February 2007
+------+
| |
| CN \ +-------+
+------+\ | |
\ | AAA |
\+------+ +-------+
\ |
/ HA |
/| |
/ *------+
/ /
/ /
/ /
/ /
+-/-/-+ +-----+
|pPMA | |nPMA |
|pPAA | |nPAA |
|pAR | |nPAR |
+--+--+ +-----+
|
|
|
|
--+------- -----------
/// \|/ \\\/// \\\
|| +-*--+ |||| ||
| | | | | |
| | MN | | | |
|| +----+ |||| ||
\\\ ///\\\ ///
---------- -----------
Figure 1: Mobile bootstrapping in pPoA
2.1.2. Mobile is impending to move
Figure 2 shows the scenario as the mobile starts to move away from
the current point of attachment (pPoA). When the mobile tries to
move away from the nPoA, it prepares the pre-authentication process.
Mobile can use any technique to determine that it is moving away from
the current point of attachment. For example, a mobile can always
use IEEE 802.21-based event service commands [802.21] to determine
that it is impending to move away and notify the access routers and
PMA accordingly.
Taniuchi, et al. Expires September 1, 2007 [Page 7]
Internet-Draft MPA-asissted PMIP February 2007
+----+
| | +-----+
|CN \ |AAA |
+----+\\ | |
\ +-----+
\*------+
|\HA |
/| |
/ *------+
/ /
/ /
/ /
/ /
+--/-/--+ +-------+
| pPMA | | nPMA |
| pPAA | | nPAA |
| pAR | | nAR |
+---+---+ +-------+
|
|
|
|
--+-- +
///- | -\\\ -----------
/ | \//// \\\\
| +-----*/| \\
| | MN | | |
| | || + |
| +-----+ | |
\ \X //
\\\- -/// \\\\ ////
----- -----------
Figure 2: Mobile is impending to move to nPoA
Figure 2: Mobile impending to move
2.1.3. Preauthentication phase
During the pre-authentication phase, the mobile can complete the
layer 3 and layer 2-based access authentication while still in the
previous network, thereby reducing the time due to pre-
authentication. There are basically two types of authentication,
such as direct authentication and indirect authentication. In case
of direct authentication the mobile can communicate with nPMA
directly, but in case of indirect authentication, pPMA acts like a
proxy. We describe both the cases: direct pre-authentication and
Taniuchi, et al. Expires September 1, 2007 [Page 8]
Internet-Draft MPA-asissted PMIP February 2007
indirect pre-authentication.
2.1.3.1. Direct Preauthentication
Figure 3 shows the direct pre-authentication phase. This pre-
authentication is layer 3 pre-authentication. Although a layer 3
pre-authentication can also jump start the layer 2 pre-
authentication. Through some discovery process such as IEEE 802.21-
based information service [802.21], the mobile discovers the details
of the network elements in the next access network. In particular it
obtains the relevant information such as MAC address, IP address of
the next access router (nAR), nPMA and nPAA. Since nPMA and nPAA do
co-exist with the NAR, the mobile also obtains the address of PMA and
PAA as well. As the mobile starts the pre-authentication process
with nPAA, nPAA can communicate with nPMA and will finish checking
the mobile's profile and obtains mobiles home prefix ahead of time
from the HA. nPMA obtains MNs profile and understands pre-auth state.
nPMA can optionally communicate with the AAA server as a backend
server. During the process of pre-authentication the tunnel is also
created between the pPMA and nPMA. Both pPMA and nPMA need to know
each others end-points so that they can create the desired tunnel.The
pre-authentication control packet has the pPMA address that can be
used to create the transient tunnel between PMAs.
Taniuchi, et al. Expires September 1, 2007 [Page 9]
Internet-Draft MPA-asissted PMIP February 2007
+-----+ +-----+
| \ | AAA |
|CN |\\ | |
+-----+ \ *-+---+
\*-----+ /|\|
/\ | | |
/|HA | | |
/ *-----+ | |
/ / | |
/ / | |
/ / | |
+---|-*/ ++-+---+
|pPM| X------------+|nPMA |
|pPA| |\ ||nPAA |
|pA-+-+------------++nNAR |
+--\*-* +------+
\\ \
\\ \
\\ \
\\ \
\\ \ -----------
-------\\-\ /// \\\
/// \\\XX \\
|| +-\\+\+| |
| | | | | |
| | MN| | | |
|| +-----+| //
\\\ ///\\\ ///
---------- -----------
Figure 3: Direct Pre-authentication with nPAA
Figure 3: Direct Pre-auhentication
2.1.3.2. Indirect Preauthentication
In case of indirect pre-authentication, pPMA is involved as a pass-
through and acts like a pre-authentication proxy. In this case also,
nPAA is co-located with nPMA. During the pre-authentication phase,
nPMA also obtains the mobile's profile and then receives prefix from
the HA, that it can use to advertise. Similarly, Pre-auth signaling
can be used to create tunnel. Data delivery path: Data Packet CN ->
HoA PMIP Tunnel: Outer HA -> pPMA, Inner ANY -> HoA
Taniuchi, et al. Expires September 1, 2007 [Page 10]
Internet-Draft MPA-asissted PMIP February 2007
2.1.4. Proactive Tunnel Creation
Figure 4 shows the detailed procedure of how the proactive transient
tunnel between pPMA and nPMA is created. During the pre-
authentication phase, the pPMA and nPMA come to know each others IP
address and thus can set up the transient tunnel. Details of the
proactive handover tunnel: Proactive HO Tunnel: Outer nPMA -> pPMA,
Inner ANY -> HoA
Taniuchi, et al. Expires September 1, 2007 [Page 11]
Internet-Draft MPA-asissted PMIP February 2007
+-----+
| | +-----+
| CN | |AAA |
+-----* | |
\ +-----+
\
\ +------+
\ | HA |
\ | |
\*-/----+
/ /
/ /
/ /
+-------+/ / +-------+
| pPMA / / |nPMA |
| pPAA |/ |nPAA |
| pAR +---------------+nAR |
| +---------------+ |
+----\--+ +-------+
\ +
\
-------\--- ------------
//// \ \\\\//// \\\\
|| *---+++| ||
| | | | | |
| |MN| | | |
|| +---+++| ||
\\\\ ////\\\\ ////
----------- ------------
Figure 4: Tunnel creation between pPMA and nPMA
Figure 4: Tunnel Creation between pPMA and nPMA
2.1.5. Proactive proxy binding update
After the tunnel is created between the pPMA and nPMA during the
authentication phase, nPMA sends a proxy binding update on behalf of
the mobile. Figure 5 shows the mechanism associated with the proxy
binding update, where the nPMA updates the HA with the source address
of nPMA and gets the home prefix that it can send in the router
advertisement. During the proxy binding update the the data still
flows through the pPMA. Data delivery path during this phase is
shown below. Data Packet : ANY -> HoA Proactive HO Tunnel: Outer
nPMA -> pPMA, Inner ANY -> HoA
Taniuchi, et al. Expires September 1, 2007 [Page 12]
Internet-Draft MPA-asissted PMIP February 2007
2.1.6. Tunnel creation between nPMA and HA
After the proxy-binding update is sent to the HA from nPMA on behalf
of the mobile, another tunnel is created between HA and pPMA. Figure
5 shows this procedure. However, while this tunnel is being created,
the data still flows through pPMA. Thus data loss is avoided during
this tunnel creation. However, after the tunnel is created the new
data gets forwarded to oPoA via two tunnels that were created between
HA and nPMA and nPMA and pPMA. Data Packet : ANY -> HoA PMIP Tunnel:
Outer HA -> nPMA, Inner ANY -> HoA Proactive HO Tunnel: Outer nPMA ->
pPMA, Inner ANY -> HoA
Taniuchi, et al. Expires September 1, 2007 [Page 13]
Internet-Draft MPA-asissted PMIP February 2007
+-----+
| | +-----+
| CN | |AAA |
+-----* | |
\ +-----+
\
\ +------+
\ | HA |
\ | \
\*-/---\+\
/ / \ \
/ / \ \
/ / \ \
+-------+/ / \+-------+
| pPMA / / |nPMA |
| pPAA |/ |nPAA |
| pAR +---------------+nAR |
| +---------------+ |
+----\--+ +-------+
\
\
-------\--- ------------
//// \ \\\\//// \\\\
|| *---+++| ||
| | | | | |
| |MN| | | |
|| +---+++| ||
\\\\ ////\\\\ ////
----------- ------------
Figure 5: Tunnel Creation between pPMA and HA
2.1.7. Proactive tunnel deletion
Since the tunnel between pPMA and nPMA should not be there when the
mobile is nPoA, this tunnel should be deleted by the mobile just
before it moves to the nPoA. Figure 6 shows how the tunnel is
deleted just before the mobile moves to the new PoA. In some cases,
it is advisable to keep the tunnel on to avoid the ping-pong effect.
The trajectory of data looks as follows. Data delivery path is shown
below. Data Packet - ANY -> HoA PMIP Tunnel - Outer (HA -> nPMA),
Inner (ANY -> HoA) Proactive HO Tunnel - Outer (nPMA -> pPMA), Inner
(ANY -> HoA)
Taniuchi, et al. Expires September 1, 2007 [Page 14]
Internet-Draft MPA-asissted PMIP February 2007
2.1.8. Movement to the new network
At a certain threshold the mobile finally ends up moving to the nPoA.
Based on the RA from the NAR, the mobile realizes that it is in a new
network, and changes its default router. But, since pre-
authentication and binding update have already been taken care of
ahead of time, the mobile does not need to go through the process of
access authentication (both layer 2 and layer 3 if applicable) again.
This will reduce the effective handoff time and eventually the packet
loss as well. Once the HA detects that the mobile is already within
nPMA, it can always delete the tunnel between pPMA and HA. The data
path will look as follows. Following is the data delivery path at
this point: Data Packet, (ANY -> HoA) PMIP Tunnel, Outer (HA ->
nPMA), Inner (ANY -> HoA)
Taniuchi, et al. Expires September 1, 2007 [Page 15]
Internet-Draft MPA-asissted PMIP February 2007
+-------+ +------+
| CN | | |
| \ | AAA |
+-------+\ +------+
\
\
+\-----+
| HA |
| |
*--\-\-*
\ \
\ \
\ \
\ \
+-----+ *-\-\-+
|pPMA +--------------+nPMA |
|pPAA +--------------+nPAA |
|pAR + +nAR |
+-----+ +-----*
/
/ Tunnel Delete
/
------------ ---/-------
//// XXX\ / \\\
// // X\ \\
| | +--/-+| |
| | |MN | | |
| | | | | |
| \\+----+| //
\\ \\\ // ///
\\\\ ///-----------
------------
Figure 6: Tunnel Deletion Procedure
Figure 6: Tunnel deletion pPMA and nPMA
2.2. Inter-domain Handoff
In this section we define inter-domain movement for the mobile, where
pPMA and nPMA are in two different domains. Thus, there is a
different LMA (HA) designed for each of the PMA (MAG). As a result,
pPMA and nPMA send different home prefix as part of their router
advertisement. In this situation when the mobile moves between two
PMAs, it will try to configure itself with a new HoA. There can be
two cases how this can be handled. In one situation, the MN maybe
Taniuchi, et al. Expires September 1, 2007 [Page 16]
Internet-Draft MPA-asissted PMIP February 2007
equipped with CMIP and in another case MN may not be equipped with
CMIP. When the MN is not equipped with CMIP, the nPMA sends the
binding update to the pHA on behalf of the MN, but there is no tunnel
between nPMA and pHA in this case. Many of the initial condtitions
are still same as intra-domain case. But there is an additional
tunnel between pHA and nHA, and nPMA might be able to send a proxy
binding update to pHA on behalf of the mobile. Alternatively, cMIP
can also send the binding update to pHA.
2.2.1. Bootstrapping State
The initial state for inter-domain case would be same as the initial
state for intra-domain case. The tunnel between pHA and nHA could be
made ahead of time. As shown in the diagram, pPMA is under pHA and
nPMA is under nHA. Tunnel between pHA and nHA could be done ahead of
time or on-demand basis. In order to be able to create the tunnel it
is assumed that there is a service agreement between two network
providers. Figure 7 shows the state of initial boot-strapping.
Data delivery path: Data Packet : ANY -> pHoA PMIP Tunnel: Outer HA
-> nPMA, Inner ANY -> pHoA
Taniuchi, et al. Expires September 1, 2007 [Page 17]
Internet-Draft MPA-asissted PMIP February 2007
+-------+
| |
+-----+ | AAA |
| | +-------+
|CN \
+-----+\
\
*-----+ +-----+
| +--------+ |
|pHA +--------+nHA |
*-/---+ +-----+
/ /
/ /
/ /
/ /
/ /
/ /
+/-/---+ +------+
|pPMA | |nPMA |
|pPAA | |nPAA |
|pAR | |nAR |
| | | |
+------+ +------+
------------
//// \\\\ -----------
// +-----+ /XX/ \\\\
| | | || | ||
| | MN | | | |
| +-----+ | | |
\\ || // ||
\\\\ ///X\\\ ////
------------ -----------
Figure 7: Initial bootstrapping in Inter-domain case
2.2.2. Mobile is impending to move
When the mobile is about to leave the network based on certain
threshold, it begins the pre-authentication phase. But the data
still flows through pHA at this point.
Data Packet : ANY -> pHoA PMIP Tunnel: Outer HA -> nPMA, Inner ANY ->
pHoA
Taniuchi, et al. Expires September 1, 2007 [Page 18]
Internet-Draft MPA-asissted PMIP February 2007
2.2.3. Preauthentication Phase
In this state, MN starts the pre-authentication process. Just like
in intra-domain case, there are two types of authentication possible,
direct authentication and indirect authentication. This
authentication is layer 3 authentication, although a layer 3
authentication can bootstrap the layer 2 authentication also. PAA is
collocated with PMA in each domain. Path of data flow in this state
is as follows.
Data Packet , ANY -> pHoA PMIP Tunnel, Outer (HA -> nPMA), Inner (ANY
-> pHoA) Data path in the Tunnel between Has: Outer (pHA -> nHA),
Inner (ANY -> pHoA) As part of the pre-authentication, nPMA obtains
MN's profile and understands that the mobile is in pre-auth state,
and obtains the prefix for meant for the new network.
2.2.3.1. Direct Preauthentication
This section describes the direct pre-authentication for Inter-domain
case. Direct pre-authentication for Inter-domain case is very
similar to intra-domain case, where the pPMA acts like a pass
through.
2.2.3.2. Indirect Preauthentication
This section describes indirect authentication for inter-domain case.
Indirect authentication for inter-domain case is very similar to
indirect pre-authentication for intra-domain case. In this case pPMA
is involved in the authentication process.
2.2.4. Proactive Tunnel Creation
This section describes the tunnel creation between pPMA and nPMA. In
this scenario, nPMA creates a tunnel with pPMA as part of the pre-
authentication. Data flow from CN->MN still remains same. Tunnel
creation between pPMA and nPMA is done during the pre-authentication
phase.
Data delivery path: Data Packet ANY -> pHoA PMIP Tunnel: Outer pHA ->
pPMA, Inner ANY -> pHoA
2.2.5. Proactive Proxy Binding Update
Proxy-binding update takes place when the mobile is still in the
previous network. nPMA sends the Proxy Binding Update to nHA and nHA
sends Proxy Binding Ack. nPMA sends its address to the nHA as part of
the proxy binding update (nHoA:nPMA). nPMA also sends a binding
update to pHA with an address of nHA binding to pHoA (pHoA:nHoA). As
Taniuchi, et al. Expires September 1, 2007 [Page 19]
Internet-Draft MPA-asissted PMIP February 2007
part of this phase a tunnel is created between nHA and nPMA. Any
traffic destined to pHoA will be first intercepted by the pHA, will
be forwarded to nHA and will eventually reach the nPMA using the nHA-
nPMA tunnel. In case of PMA, this traffic will be tunneled back to
the mobile using pPMA-nPMA tunnel.
Figure 8 shows the proxy binding update to nHA and the proxy binding
update to pHA. These could take place at the same time or in
sequence. As soon as the proxy binding update to nHA is complete, a
tunnel is setup between nPMA and nHA. Proxy-binding update to pHA
sets up the forwarding table at pHA to nHA. We assume that there is
some sort of security association between nPMA and pHA so that nPMA
can update pHA.
Alternatively, the mobile can send the update signal to the pHA
directly about nHoA, as it already has the prefix of the new HA. But
in this case the mobile needs to be equipped with client MIPv6. It
is assumed that the client maybe equipped with cMIPv6 in order to
help the inter-domain roaming. In case of CMIP, the mobile can send
the binding update either via pPMA or nPMA.
Taniuchi, et al. Expires September 1, 2007 [Page 20]
Internet-Draft MPA-asissted PMIP February 2007
+----+
| | +----+
|CN | | |
+--+-+ |AAA |
| +/---+
| /
| /
+--+--+ +---/+
| pHA +----------+nHA |
| +----------+ |
+-+-+-+- +--+-+
| | -- |
| | -- |
| | -- |
| | -- |
+-+-+--+ -+--+--+
|pPMA | |nPMA |
|pPAA +---------+nPAA |
|pAR +---------+nAR |
| | | |
+---\--+ +-----+
\
\
-------\--
//// \ \\\\ ----------
|| \ //// \\\\
| +----\++ | ||
| | MN | | | |
|| | | | || |
\\\\ +-----++/ ||
---------- \\\\ ////
----------
Figure 8: Proxy Binding update to pHA and nHA
2.2.6. Tunnel between nPMA and nHA
As part of the proxy binding update, the pHA and nHA are properly
updated. The tunnels are setup between nHA, nMPA and between pPMA
and nPMA and the data starts flowing from CN to MN using the new
network entities. Data from CN, instead of being sent over pPMA is
sent via, nHA and nPMA, thus takes a round about way.
2.2.7. Data Flow when mobile in pPoA
Date from CN is picked up by the pHA, and pHA forwards the packet
from CN to nHA using a tunnel and nHA now forwards the packet
destinated to pHoA to nPMA. At this point, the data traffic is
Taniuchi, et al. Expires September 1, 2007 [Page 21]
Internet-Draft MPA-asissted PMIP February 2007
forwarded to pPMA using Proactive handover tunnel. Figure 9 shows
the scenario when the mobile is still in the previous network and the
proxy binding updates are complete.
Data Packet : ANY -> pHoA Tunnel between HAs: Outer pHA -> nHA, Inner
ANY -> pHoA nPMIP Tunnel:Outer nHA -> nPMA, Inner ANY -> pHoA, nHoA
Proactive HO Tunnel: Outer nPMA -> pPMA, Inner ANY -> pHoA, nHoA
Taniuchi, et al. Expires September 1, 2007 [Page 22]
Internet-Draft MPA-asissted PMIP February 2007
+-------+
+----+ | AAA |
|CN | | \
+--+-+ +-------+\\
| \
| \
+--+--+ \\+----+
|pHA +---------------------*nHA |
| +---------------------+ |
+-+-+-+- +-+-++
| | -- | |
| | -- | |
| | -- | |
| | -- | |
| | -- | |
| | -- | |
+-+-+---+ -- +----+-++
|pPMA | -- |nPMA |
|pPAA +----------------+nPAA |
|pAR +----------------+nAR |
| \ | |
+-------+\ +-------+
\
\\
----------\- ------------
//// \\\\X/// \\\\
// \// \\ \\
| |*----+ |
| | | MN || |
| | | || |
| |+----+ |
\\ \\ // //
\\\\ ///X\\\ ////
------------ ------------
Figure 9: Data flow before the mobile moves
2.2.8. Tunnel Deletion
At certain threshold, the mobile decides to change its layer 2 point
of attachment and moves to the new network. Just before it moves, it
deletes the tunnel between nPMA and pPMA just like the intra-domain
case and lands up in the new network. Any transient traffic during
tunnel deletion can still be taken care of by deploying buffering
agents at the access routers. Tunnel deletion takes place between
Taniuchi, et al. Expires September 1, 2007 [Page 23]
Internet-Draft MPA-asissted PMIP February 2007
the pPMA and nPMA just before the mobile moves to the new PoA.
Data delivery path: Data Packet : ANY -> pHoA Tunnel between HAs:
Outer pHA -> nHA, Inner ANY -> pHoA nPMIP Tunnel: Outer nHA -> nPMA,
Inner ANY -> pHoA, nHoA Proactive HO Tunnel: Outer nPMA -> pPMA,
Inner ANY -> pHoA, nHoA
2.2.9. Movement to the new network
As the mobile moves to the new network, it may not have to go through
the DNA process of sending the (Router Solicitation) to learn the MAC
address and the default router NAR. Since it already has the MAC
address and the IP address of NAR, the mobile can easily start
receiving the traffic from nPMA. Since the tunnel is deleted, this
traffic will not be forwarded to pPMA. Any transient traffic during
tunnel deletion can be buffered at the edge router. Figure 10 shows
the data path after the mobile has moved to the new network.
Data Packet ANY -> pHoA Tunnel between HAs: Outer pHA -> nHA Inner
ANY -> pHoA nPMIP Tunnel:Outer (nHA -> nPMA), (Inner ANY -> pHoA,
nHoA)
Taniuchi, et al. Expires September 1, 2007 [Page 24]
Internet-Draft MPA-asissted PMIP February 2007
+-----+ +------+
| | | AAA |
| CN | | |
+---+-+ +------+
|
|
|
+---+--+ +------+
|pHA +------------+nHA |
| +------------+ |
+------+ +--+-+-+
| |
| |
| |tunnel
| |
| |
+--------+ +--+-+--+
| pPMA | |nPMA |
| pPAA | |nPAA |
| pAR | |nAR |
| | | |
+--------+ +----+--+
|
|
------------ -----+-----
//// \\XX// | \\\\
// // \\ +-+---+ \\
| | | | | |
| | | |MN | |
| | | +-----+ |
\\ \\ // //
\\\\ //XX\\ ////
------------ -----------
Figure 10: Data flow when the mobile is in new doamin
Taniuchi, et al. Expires September 1, 2007 [Page 25]
Internet-Draft MPA-asissted PMIP February 2007
3. Security Considerations
This document describes how Media Independent Preauthentication
technique can be used to provide fast-handover for PMIPv6 for both
intra-domain and inter-domain mobility. It will need to adhere to
the security consideration for ProxyMIPv6 and Media Independent
Preauthentication. In addition, this mechanism needs to make sure
that proxy binding from nPMA to pHA is secured enough during inter-
domain case. Many of the signaling associated with the tunnel
creation between pPMA and nPMA can be secured using the security
procedure defined as part of the pre-authentication procedure as
described in the MPA draft.
Taniuchi, et al. Expires September 1, 2007 [Page 26]
Internet-Draft MPA-asissted PMIP February 2007
4. IANA Considerations
This document has no actions for IANA.
Taniuchi, et al. Expires September 1, 2007 [Page 27]
Internet-Draft MPA-asissted PMIP February 2007
5. Acknowledgments
We would like to thank Subir Das for many useful discussion related
to IEEE 802.21 and Media Independent Preauthentication.
Taniuchi, et al. Expires September 1, 2007 [Page 28]
Internet-Draft MPA-asissted PMIP February 2007
6. References
6.1. Normative References
[I-D.sgundave-mipv6-proxymipv6]
Gundavelli, S., "Proxy Mobile IPv6",
draft-sgundave-mipv6-proxymipv6-00 (work in progress),
October 2006.
[I-D.ohba-mobopts-mpa-framework]
Ohba, Y., "A Framework of Media-Independent Pre-
Authentication (MPA)", draft-ohba-mobopts-mpa-framework-03
(work in progress), October 2006.
[I-D.ohba-mobopts-mpa-implementation]
Ohba, Y., "Media-Independent Pre-Authentication (MPA)
Implementation Results",
draft-ohba-mobopts-mpa-implementation-03 (work in
progress), October 2006.
[I-D.kempf-netlmm-nohost-ps]
Kempf, J., "Problem Statement for IP Local Mobility",
draft-kempf-netlmm-nohost-ps-01 (work in progress),
January 2006.
[I-D.kempf-netlmm-nohost-req]
Kempf, J., "Requirements and Gap Analysis for IP Local
Mobility", draft-kempf-netlmm-nohost-req-00 (work in
progress), July 2005.
[I-D.ietf-pana-pana]
Forsberg, D., "Protocol for Carrying Authentication for
Network Access (PANA)", draft-ietf-pana-pana-13 (work in
progress), December 2006.
6.2. Informative References
[802.21] "Draft IEEE Standard for Local and Metropolitan Area
Networks: Media Independent Handover Services, IEEE
P802.21/D000.04,", Feb 2007.
Taniuchi, et al. Expires September 1, 2007 [Page 29]
Internet-Draft MPA-asissted PMIP February 2007
Authors' Addresses
Kenichi Taniuchi
Toshiba America Research, Inc.
1 Telcordia Drive
Piscataway, NJ 08854
USA
Phone: +1 732 699 5308
Email: ktaniuchi@tari.toshiba.com
Victor Fajardo
Toshiba America Research, Inc.
1 Telcordia Drive
Piscataway, NJ 08854
USA
Phone: +1 732 699 5368
Email: vfajardo@tari.toshiba.com
Yoshihiro Ohba
Toshiba America Research, Inc.
1 Telcordia Drive
Piscataway, NJ 08854
USA
Phone: +1 732 699 5305
Email: yohba@tari.toshiba.com
Ashutosh Dutta
Telcordia Technologies
1 Telcordia Drive
Piscataway, NJ 08854
USA
Phone: +1 732 699 3130
Email: adutta@research.telcordia.com
Taniuchi, et al. Expires September 1, 2007 [Page 30]
Internet-Draft MPA-asissted PMIP February 2007
Henning Schulzrinne
Columbia University
Department of Computer Science
450 Computer Science Building
New York, NY 10027
USA
Phone: +1 212 939 7004
Email: hgs@cs.columbia.edu
Taniuchi, et al. Expires September 1, 2007 [Page 31]
Internet-Draft MPA-asissted PMIP February 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Taniuchi, et al. Expires September 1, 2007 [Page 32]