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]