NetLMM Working Group M. Liebsch Internet-Draft L. Le Expires: May 16, 2008 NEC Laboratories J. Abeille Cisco Technology Center November 13, 2007 Route Optimization for Proxy Mobile IPv6 draft-abeille-netlmm-proxymip6ro-01.txt 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 May 16, 2008. Copyright Notice Copyright (C) The IETF Trust (2007). Liebsch, et al. Expires May 16, 2008 [Page 1] Internet-Draft Proxy Mobile IPv6 RO November 2007 Abstract The IETF is specifying a protocol for network-based localized mobility management, which takes basic operation for registration, tunnel management and de-registration into account. This document specifies a protocol for route optimization in networks, which support network-based mobility management. The specified protocol focuses on efficient set up and maintenance of a route optimized path between two mobile nodes and suits complex mobility scenarios as well as networks with multiple mobility anchors. Table of Contents 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Terminology and Functional Components . . . . . . . . . . . . 6 4. Protocol Operation . . . . . . . . . . . . . . . . . . . . . . 7 4.1. General procedure . . . . . . . . . . . . . . . . . . . . 7 4.2. Route Optimization - Direct Mode . . . . . . . . . . . . . 8 4.2.1. RO Setup Procedure . . . . . . . . . . . . . . . . . . 8 4.2.2. RO Handover Procedure . . . . . . . . . . . . . . . . 10 4.3. Route Optimization - Proxy Mode . . . . . . . . . . . . . 12 4.3.1. RO Setup Procedure . . . . . . . . . . . . . . . . . . 12 4.3.2. RO Handover Procedure . . . . . . . . . . . . . . . . 14 5. Message Format . . . . . . . . . . . . . . . . . . . . . . . . 17 6. Security Considerations . . . . . . . . . . . . . . . . . . . 18 7. Normative References . . . . . . . . . . . . . . . . . . . . . 19 Appendix A. MAG-local Route Optimization . . . . . . . . . . . . 20 Appendix B. Early State Activation (ESA) Policy . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 Intellectual Property and Copyright Statements . . . . . . . . . . 23 Liebsch, et al. Expires May 16, 2008 [Page 2] Internet-Draft Proxy Mobile IPv6 RO November 2007 1. Requirements notation 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 [RFC2119]. Liebsch, et al. Expires May 16, 2008 [Page 3] Internet-Draft Proxy Mobile IPv6 RO November 2007 2. Introduction The NetLMM WG is specifying a protocol for network-based localized mobility management (NetLMM), taking basic support for registration, de-registration and handover into account in a first protocol release. The specification of extensions and optimization is for further study and subject for either being incorporated into future versions of the protocol or specified in separate documents. In scope of the base protocol specification is the set up and maintenance of a forwarding tunnel between an MN's Mobility Access Gateway (MAG) and its selected Local Mobility Anchor (LMA). Data packets will always traverse the MN's MAG and its LMA, irrespective of the location of the MN's remote communication endpoint. Even though two communicating MNs might be located close to each other or within the same local mobility domain, packets will traverse the MNs' LMA(s). This document specifies a protocol for route optimization in networks which enable mobility and reachability to nodes by means of network- based mobility management. Even though the concept behind the proposed protocol is agnostic to the details of the NetLMM protocol, this document focuses on the operation of the protocol with Proxy MIPv6 [I-D.ietf-netlmm-proxymip6] as base protocol for network-based mobility. Control for route optimization in Mobile IPv6 is assigned to MNs and Correspondent Nodes (CNs). MNs can send Binding Update (BU) signaling to a CN to create a binding between the MN's home address (HoA) and its care-of address (CoA) at the CN. [RFC3775] specifies the Return Routability Test procedure between the CN and the MN to help validate an MN's binding, as a CN might not have a security association (SA) with the MN. Key concept of PMIPv6 is to relocate the responsibility for maintaining a node's binding on the LMA from the client (MN) to the functional entity MAG, which is co-located with the infrastructure's access routers. To create and update a binding at the MN's LMA, the MAG sends a Proxy BU (PBU) to the MN's LMA and receives the LMA's Proxy BACK (PBACK) on behalf of the MN. The binding establishes a valid tunnel for routing the MN's data packets from the MAG to the LMA (uplink) and from the LMA to the MAG (downlink). Relocating full control for route optimization from the client to the MAG function according to the PMIPv6 architecture is possible, but might not be the optimal approach. The set up and maintenance of a route optimized path in network-based mobility scenario is considered different from client-based mobility. This document focuses on the establishment of a route optimized path between two nodes, which are attached to the network by means of PMIPv6. The set up of an optimized route between an MN's MAG and a CN is not considered, as it reveals the address of the MN's MAG, Liebsch, et al. Expires May 16, 2008 [Page 4] Internet-Draft Proxy Mobile IPv6 RO November 2007 which can be mapped to the MN's location. Furthermore, it might be against an operator's policy to reveal address information of its infrastructure's network nodes. The MIPv6 Return Routability Test procedure is not considered either, as the two MN's MAGs might share an SA to protect signaling between MAGs. An alternative approach is proposed to avoid relying on an SA between MAGs. This protocol aims at efficient set up and maintenance of a route optimized path between two MNs' MAGs, while taking difficult mobility scenarios into account. Such scenarios comprise the set up of route optimization between two MNs which are registered with different LMAs, and the maintenance of the route optimized path in case one or both terminals hand over. To coordinate the set up and maintenance of the route optimized path efficiently, this protocol introduces the function Route Optimization Controller (RO controller), which is assigned to LMAs. During the set up of the route optimized path, one LMA is dynamically selected as active RO controller. In case the two MNs are registered with different LMAs, only one LMA, which has the active RO controller function assigned for the associated route optimized path, will coordinate the maintenance of the RO path and the establishment of the RO states on the MAG(s) upon handover. Liebsch, et al. Expires May 16, 2008 [Page 5] Internet-Draft Proxy Mobile IPv6 RO November 2007 3. Terminology and Functional Components o RO - Route Optimization o RO Communication - RO focus is on data exchange between two mobile nodes, MN1 and MN2, which are each registered in a NetLMM domain (This includes the case where MN1 and MN2 are registered in two different domains). Route optimized traffic goes from MN1 to MAG1, then from MAG1 to MAG2 and from MAG2 to MN2 as well as vice versa without traversing any LMA. o RO Association - An association between MAG1 and MAG2, between which RO is set up and maintained. To set up an association, signaling will be used to create RO states at each MAG. The association and state information can include MN profile data. o RO Setup Trigger - This function is assigned to a network entity, which first detects that RO can be established between the MAGs of two communicating MNs. o RO Update Trigger - When RO has been set up between MN1 and MN2 and one of them or even both initiate a handover, RO states need to be updated or established. The relevant RO update trigger function is assigned to an entity, which detects that RO states need to be updated. o RO Controller - The relevant RO controller functional entity for a RO communication is selected the first time RO is set up between a pair of MNs. In this protocol, the relevant active RO control function is assigned to either MN1's or MN2's mobility anchor. The entity which has been selected as active RO controller remains anchored as controlling entity for the duration of the route optimized communication and the lifetime of associated RO states. Liebsch, et al. Expires May 16, 2008 [Page 6] Internet-Draft Proxy Mobile IPv6 RO November 2007 4. Protocol Operation 4.1. General procedure When MN1 initiates traffic towards MN2, the traffic is routed via MN1's MAG and LMA (Figure 1). Either MN1's MAG or the LMA can detect that a route optimized path can be set up between the two MNs. As an example, detection can be based on the two MNs' IP address or the associated MAGs' IP address. Accordingly, either the MAG or the LMA takes over the role of the RO setup trigger. In the following description, the LMA will serve as RO setup trigger. During the set up phase of the route optimized path, either MN1's LMA (LMA1) or MN2's LMA (LMA2) will be selected as active RO controller for this particular RO association. In case both MNs are registered with the same LMA, this single LMA will serve as RO controller. The LMA, which has the active RO controller function assigned, coordinates the set up of the route optimized path and associated signaling with the relevant MAG(s). After the route optimized path has been set up between the two MNs' MAGs, one or both MNs might hand over to a different MAG. In that case, the LMA, which serves as active RO controller for this particular RO association, coordinates the re- establishment of the RO states on the relevant MAGs. Internet Backbone : : : : | | +----+ +----+ |LMA1|--------------|LMA2| +----+ +----+ | | | | +----+ +---------+----+ | | | +----+ +----+ +----+ |MAG1| |MAG2| |MAG3| +----+ +----+ +----+ : : +---+ +---+ |MN1| |MN2| +---+ +---+ Figure 1: Reference architecture for route optimization in NetLMM The protocol supports two modes of operation, the Direct Mode and the Proxy Mode. In Direct Mode, the two relevant MAGs can exchange Liebsch, et al. Expires May 16, 2008 [Page 7] Internet-Draft Proxy Mobile IPv6 RO November 2007 signaling to set up and maintain RO states for a particular pair of MNs. This might require these MAGs to share an SA to protect signaling messages. Setting up SAs between MAGs for route optimization is different from an SA between neighbor access routers to allow protection of handover related signaling. For route optimization, all relevant MAGs must share an SA, independent of whether or not they are geographically adjacent. This might impact the amount of SA-related states on each MAG. If this is not an issue, the protocol's Direct Mode allows MAGs to exchange signaling directly. Alternatively, the Proxy Mode can be operated, where only LMAs exchange signaling with MAGs to set up and maintain RO states. Inter-MAG signaling is not required in a system which operates the Proxy Mode for route optimization. This section describes the two modes separately, taking initial set up as well as maintenance of a route optimized path in case of a handover into account. Furthermore, description of both modes distinguish setting up a route optimized path between two MNs which are registered with the same LMA from a scenario where both MNs are registered with different LMAs. This document specifies the following new conceptual messages for route optimization. All messages need to be acknowledged by means of an associated Ack message. Ack messages carry a status code field. o RO Initiate - This message is sent from an LMA to inform another entity (either an LMA or a MAG, depending on the scenario) that it has to initiate or continue a RO procedure. By default, the receiving entity should create but not activate any forwarding states for the route optimized path. o RO Setup - This message is sent from an LMA (in the proxy mode) or a MAG (in the direct mode) to a MAG to activate or update RO forwarding states for a particular RO association. o RO Report - This message is used to inform about the result of setting up RO states on a MAG. An optional extension to this route optimization protocol solves possible issues with out of order packets when the communication path of an associated pair of MNs switches from non-route optimized to route optimized. The associated extension is described in [I-D.jaehwoon-netlmm-flush]. 4.2. Route Optimization - Direct Mode 4.2.1. RO Setup Procedure In all scenarios, MN1 initiates traffic to MN2. Liebsch, et al. Expires May 16, 2008 [Page 8] Internet-Draft Proxy Mobile IPv6 RO November 2007 In Figure 2, both MNs are registered with the same LMA (LMA1). The LMA detects, that route optimization can be set up, hence, serves as RO setup trigger [T]. As both MNs are registered with the same LMA, LMA1 serves as active RO controller (ROC). The LMA sends the RO Initiate message to MAG2. This message carries the ID and Home Network Prefix of MN1, the IP address of MAG1 as well as the ID of MN2. After MAG2 has acknowledged the RO Initiate message, it sends the RO Setup message to MAG1, carrying the ID of MN1 and MN2, as well as the Home Network Prefix of MN2. MAG1 acknowledges the RO Setup message. RO states are now established on MAG1 and MAG2. The result of the set up is reported to the RO controller by means of a RO Report message. +----+ +----+ +----+ |MAG1| |LMA1| |MAG2| +----+ +----+ +----+ | | | | [T] | | (ROC) | | | | | |-----RO Init----->| | |<--RO Init Ack----| | | | |<---------------RO Setup--------------| |--------------RO Setup Ack----------->| | | | | |<---RO Report-----| | |--RO Report Ack-->| | | | Figure 2: RO Direct Mode - One relevant LMA in the topology Figure 3 illustrates the set up of a route optimized path between two MNs which are registered with different LMAs. MN1 is registered with LMA1, MN2 is registered with LMA2. As MN1 initiates traffic, LMA1 detects the possibility to set up a route optimized path for this communication [T], but does not know the IP address of MAG2. It sends a RO Initiate message to LMA2, which carries information about MAG1's IP address, MN1's ID and Home Network Prefix as well as the Home Network Prefix of MN2. During this message handshake between LMA1 and LMA2, one LMA can be selected as active RO controller for this particular RO association. In this example, LMA2 is selected as RO controller. Further set up of RO states is similar to Figure 2. The only difference is that LMA2 should inform LMA1, who triggered route optimization, of the procedure's result, which is done by means of the RO Report message. Liebsch, et al. Expires May 16, 2008 [Page 9] Internet-Draft Proxy Mobile IPv6 RO November 2007 +----+ +----+ +----+ +----+ |MAG1| |LMA1| |LMA2| |MAG2| +----+ +----+ +----+ +----+ | | | | | [T] | | | | (ROC) | | | | | | |------RO Init---->| | | |<---RO Init Ack---| | | | |----RO Init---->| | | |<--RO Init Ack--| |<-----------------------RO Set-----------------------| |----------------------RO Setup Ack------------------>| | | |<--RO Report----| | | |-RO Report Ack->| | |<----RO Report----| | | |--RO Report Ack-->| | | | | | Figure 3: RO Direct Mode - Two relevant LMAs in the topology 4.2.2. RO Handover Procedure This section specifies the signaling to maintain RO states in a handover case. Figure 4 refers to the case where both MNs are registered with the same LMA (LMA1). When LMA1 receives the Proxy BU (PBU) from MN1's new MAG1 (nMAG1), it knows that RO states at MAGs need to be updated (at MAG2) and established (at nMAG1). As LMA1 represents the RO trigger function as well as the active RO controller for this RO association, LMA1 can send the RO Initiate to nMAG1 to initiate the establishment of RO states. RO states on pMAG1 might expire or be explicitly deleted with MN1's Binding Update List (BUL) entry. Whereas nMAG1 established the RO states, existing states in MAG2 are updated through this procedure. The remaining procedure is according to Figure 2. Liebsch, et al. Expires May 16, 2008 [Page 10] Internet-Draft Proxy Mobile IPv6 RO November 2007 +-----+ +-----+ +----+ +----+ |nMAG1| |pMAG1| |LMA1| |MAG2| +-----+ +-----+ +----+ +----+ | | | | | | (ROC) | | | [T] | |----------------- PBU- ------------->| | |<----------------PBAck --------------| | | | | | | | | | |<----------------RO Init-------------| | |---------------RO Init Ack---------->| | | | | | | | | | |-------------------------RO Setup -------------------->| |<----------------------RO Setup Ack--------------------| | | | | | | | | |----------------RO Report----------->| | |<-------------RO Report Ack----------| | | | | | | | | | Figure 4: RO Direct Mode - One relevant LMA in the topology, MN1 handover Figure 5 illustrates the case where MN1 and MN2 are registered with different LMAs. Again, MN1 initiates a handover from pMAG1 to nMAG1, which results in nMAG1 sending a PBU to LMA1. In this scenario, we assume that LMA2 serves as active RO controller, therefore LMA1 has to initiate the update procedure by means of sending a RO Initiate message to LMA2. Even though LMA2 is under control of the RO setup and maintenance, it is preferable to send the RO Initiate from LMA1 to nMAG1, as there might be no SA established between LMA2 and nMAG1 and such cross-signaling should be avoided in any case. Hence, LMA2 controls LMA1 to send the RO Initiate to nMAG1 by means of the first RO Initiate/Ack message handshake. LMA1 sends a RO Initiate message to nMAG1 to initiate the RO Setup handshake between nMAG1 and MAG2. The remaining procedure is similar to Figure 3, including the notification of the procedure's result to the RO controller by means of sending a RO Report message from LMA1 to LMA2. Note: in the case where the RO update trigger and active RO controller function are on the same LMA, this one does not send a RO Initiate message to the other LMA, but directly sends a RO Initiate message to its MAG. Liebsch, et al. Expires May 16, 2008 [Page 11] Internet-Draft Proxy Mobile IPv6 RO November 2007 +-----+ +-----+ +----+ +----+ +----+ |nMAG1| |pMAG1| |LMA1| |LMA2| |MAG2| +-----+ +-----+ +----+ +----+ +----+ | | | | | |------------PBU------------>| (ROC) | |<----------PBAck -----------| | | | | [T] | | | | |----RO Init---->| | | | |<--RO Init Ack--| | | | | | | |<----------RO Init----------| | | |---------RO Init Ack------->| | | | | | | | | | | | | |------------------------RO Setup--------------------------->| |<---------------------RO Setup Ack--------------------------| | | | | | | | | | | |----------RO Report-------->| | | |<-------RO Report Ack-------| | | | | | | | | | |---RO Report--->| | | | |<-RO Report Ack-| | | | | | | | | | | | Figure 5: RO Direct Mode - Two relevant LMAs in the topology, MN1 handover 4.3. Route Optimization - Proxy Mode In this mode, MAGs do not exchange signaling directly. A MAG exchanges signaling only with the LMA, which is associated with the attached MN. As a consequence, LMAs will proxy signaling messages between MAGs to set up and update RO states. 4.3.1. RO Setup Procedure The description in this section still assumes that MN1 initiates traffic with MN2. The LMA serves as RO setup trigger and controller, as in Direct Mode. According to Figure 6, the LMA sends a RO Initiate message to MAG2 to create RO states. The RO Initiate message indicates to MAG2 that the message sender (LMA1) serves as proxy to set up the RO communication between MAG1 and MAG2. The message contains MN2's ID, MN1's ID and Home Network Prefix, as well as MAG1's IP address. MAG2 acknowledges the RO Initiate with the associated Ack message. Subsequently, the LMA sends a RO Setup Liebsch, et al. Expires May 16, 2008 [Page 12] Internet-Draft Proxy Mobile IPv6 RO November 2007 message to MAG1 to proxy the signaling between MAG2 and MAG1. The message contains MN1's ID, MN2's ID and Home Network Prefix, as well as MAG2's IP address. At the reception of the RO Setup message, MAG1 creates and activates RO states for bi-directional route optimized path for this particular RO association between between MAG1 and MAG2. At reception of the associated Ack message, the LMA sends a RO Setup message to MAG2 to indicate that MAG1's RO states have been established and activated, as well as to activate MAG2's RO states for a bi-directional route optimized path. Note: RO states are established on MAG2 after the reception of the RO Initiate message. For secure and stable operation, RO states on MAG2 should be activated only after the reception of the RO Setup message, which indicates the status of MAG1's RO states. +----+ +----+ +----+ |MAG1| |LMA1| |MAG2| +----+ +----+ +----+ | | | | [T] | | (ROC) | | | | | |-------RO Init------>| | |<----RO Init Ack-----| | | | |<-----RO Setup------| | |----RO Setup Ack--->| | | | | | |------RO Setup------>| | |<----RO Setup Ack----| | | | Figure 6: RO Proxy Mode - One relevant LMA in the topology In the scenario with two LMAs (Figure 7), LMA1 serves as RO trigger, whereas LMA2 is selected as active RO controller for this particular RO association. As LMA1 has no information about MN2's MAG2, it sends the RO Initiate message to LMA2 to request setting up RO between MAG1 and MAG2. LMA2 establishes RO states at MAG2 by means of the RO Initiate message. As in the previous topology with a common LMA, MAG2 acknowledges the RO Initiate message. LMA2 notifies LMA1 about the created RO states at MAG2 by means of a RO Report handshake. The result causes LMA1 to proxy the RO Setup message, which is sent to MAG1. MAG1 has now all RO states set up and activated, whereas MAG2 waits for the RO Setup from LMA2 to activate its states according to MAG1's status. Liebsch, et al. Expires May 16, 2008 [Page 13] Internet-Draft Proxy Mobile IPv6 RO November 2007 +----+ +----+ +----+ +----+ |MAG1| |LMA1| |LMA2| |MAG2| +----+ +----+ +----+ +----+ | | | | | [T] (ROC) | | | | | | |-----RO Init---->| | | |<---RO Init Ack | | | | | | | | |----RO Init---->| | | |<--RO Init Ack--| | | | | | |<---RO Report----| | | |--RO Report Ack->| | | | | | |<----RO Setup-----| | | |---RO Setup Ack-->| | | | | | | | | | | | |----RO Report--->| | | |<-RO Report Ack--| | | | | | | | |----RO Setup--->| | | |<-RO Setup Ack--| | | | | Figure 7: RO Proxy Mode - Two relevant LMAs in the topology 4.3.2. RO Handover Procedure After MN's handover, nMAG1 notifies the LMA (LMA1) about MN1's arrival by means of the PBU message. LMA1 recognizes that RO states for this particular RO association need to be established at nMAG1 and updated on MAG2. As LMA1 is assigned the function of the RO update trigger as well as the active RO controller, it coordinates maintenance of the route optimized path according to Figure 8. Signaling sequence between nMAG1, LMA1 and MAG2 is the same as for the set up of RO states (Figure 6) Liebsch, et al. Expires May 16, 2008 [Page 14] Internet-Draft Proxy Mobile IPv6 RO November 2007 +-----+ +-----+ +----+ +----+ |nMAG1| |pMAG1| |LMA1| |MAG2| +-----+ +-----+ +----+ +----+ | | | | | | (ROC) | | | | | |-----------------PBU--------------->| | |<---------------PBAck---------------| | | | [T] | |<--------------RO Init--------------| | |-------------RO Init Ack----------->| | | | | | | | |----RO Setup---->| | | |<--RO Setup Ack--| | | | | |<-------------RO Setup--------------| | |------------RO Setup Ack----------->| | | | | | | | | | Figure 8: RO Proxy Mode - One relevant LMA in the topology, MN1 handover In the scenario, where MN1 and MN2 are tracked by different LMAs (Figure 9), LMA1 recognizes the need to update the RO association and serves as RO update trigger. In this scenario, we assume that LMA2 has been selected as active RO controller for this particular RO association, hence LMA1 sends a RO Initiate message to LMA2, which coordinates the update procedure. After having received the RO Initiate Ack from LMA2, LMA1 can start the RO update procedure by means of sending a RO Initiate message to MAG1. The remaining message sequence is according to Figure 9 and the same as for the RO setup procedure with two LMAs (Figure 7). Note: in the case where the RO update trigger and active RO controller function are on the same LMA, this one does not send a RO Initiate message to the other LMA, but directly sends a RO Initiate message to its MAG. Liebsch, et al. Expires May 16, 2008 [Page 15] Internet-Draft Proxy Mobile IPv6 RO November 2007 +-----+ +-----+ +----+ +----+ +----+ |nMAG1| |pMAG1| |LMA1| |LMA2| |MAG2| +-----+ +-----+ +----+ +----+ +----+ | | | | | |------------PBU------------>| (ROC) | |<----------PBAck------------| | | | | [T] | | | | |-----RO Init--->| | | | |<--RO Init Ack--| | | | | | | |<---------RO Init-----------| | | |--------RO Init Ack-------->| | | | | | | | | | |----RO Report-->| | | | |<-RO Report Ack-| | | | | | | | | | |---RO Setup--->| | | | |<-RO Setup Ack-| | | | | | | | |<----RO Report--| | | | |-RO Report Ack->| | | | | | | |<---------RO Setup----------| | | |--------RO Setup Ack------->| | | | | | | | | | | | | Figure 9: RO Proxy Mode - Two relevant LMAs in the topology, MN1 handover Liebsch, et al. Expires May 16, 2008 [Page 16] Internet-Draft Proxy Mobile IPv6 RO November 2007 5. Message Format To suit the format of the Proxy MIPv6 messages, the three differential messages RO Initiate, RO Setup and RO Report as well as the associated Ack messages are encoded according to the message data encoding rules for the Mobility Header (MH) as specified in [RFC3775]. Messages for RO are extensions to [I-D.ietf-netlmm-proxymip6] and identified by the MH Type. Parameters being carried by any of these messages are encoded as message options according to the type-length-value format specified in [RFC3775]. The following message option is specified for this protocol: MAG IP Address Option. Details about the message and message option format are t.b.d. Note: As an option to the RO protocol's direct mode, a Proxy BU message handshake can be used to substitute the RO Setup message handshake between MAGs. In this case, the RO Initiate message from an LMA serves as trigger to release the PBU to establish RO states on MAGs according to the protocol operation described in Section 4.2. Liebsch, et al. Expires May 16, 2008 [Page 17] Internet-Draft Proxy Mobile IPv6 RO November 2007 6. Security Considerations Security threats for route optimization in network-based mobility management comprise the danger of unauthorized set up or redirect of an established forwarding path by a malicious node. Signaling messages of this protocol between a MAG and an LMA as well as between LMAs must be authenticated by means of IPsec [RFC4301]. The use of IPsec between an LMA and a MAG follows [I-D.ietf-netlmm-proxymip6]. Protection of signaling messages between an LMA and a MAG uses the mechanisms of Encapsulating Security Payload (ESP) [RFC4303] in transport mode with mandatory data origin authentication by means of a non-null payload authentication algorithm. The use of encryption is optional. The same requirements apply to signaling between LMAs as well as between MAGs. In particular, if the network which interconnects two LMAs and/or two MAGs is not trusted, the use of encryption is recommended to support confidentiality protection between LMAs and between MAGs respectively. In case setting up a security association between MAGs appears difficult, the protocol's proxy mode allows secure operation without mandating such security association. In case RO is established between two MNs which are registered with different LMAs, the proposed RO protocol avoids direct signaling between one MN's LMA and the other MN's MAG. Instead, MAGs exchange signaling only with LMAs which maintain a registration for attached MNs. This avoids dependency on an existing security association between all possible MAG-LMA-pairs. Liebsch, et al. Expires May 16, 2008 [Page 18] Internet-Draft Proxy Mobile IPv6 RO November 2007 7. Normative References [I-D.ietf-netlmm-proxymip6] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", draft-ietf-netlmm-proxymip6-07 (work in progress), November 2007. [I-D.jaehwoon-netlmm-flush] Lee, J., "Flushing Mechanism for Routing Optimization in PMIPv6", draft-jaehwoon-netlmm-flush-00 (work in progress), June 2007. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005. [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005. Liebsch, et al. Expires May 16, 2008 [Page 19] Internet-Draft Proxy Mobile IPv6 RO November 2007 Appendix A. MAG-local Route Optimization In some scenarios, both MNs could be attached to the same MAG. The MNs can be registered to the same LMA or two different LMAs. In this case, the most efficient path is to route the traffic from MN1 to MN2 directly via the MAG, without going through the LMA(s). Establishing this direct path could be done as part of the PMIP base operation as it has been discussed in the NetLMM Working Group. However, if it is so, and if one MN hands off, RO states would have to be installed after the handover. We believe that it is more efficient and consistent to install the optimized path as part of a RO service and treat the handover case with the RO handover procedures described in Section 4. Liebsch, et al. Expires May 16, 2008 [Page 20] Internet-Draft Proxy Mobile IPv6 RO November 2007 Appendix B. Early State Activation (ESA) Policy In the procedures described in Section 4, the MAGs are provided with the relevant information needed to setup RO one after the other. Additionally, the MAG being contacted first only activates the states when it receives the notification of the success of the RO setup on the second MAG. As an example, in Figure 2, the first MAG contacted, MAG2, activates the RO states after having received and processed the RO setup Ack from MAG1. In a similar fashion, in Figure 6, MAG2 activates the RO states after having received and processed the RO Setup from LMA1. This approach avoids to start using the RO path in the case where the RO setup failed on either MAG. However, the setup of the RO path can be slightly optimized at the cost of suppressing this mechanism: the first MAG could create and activate the RO states without waiting for the notification concerning the second MAG. We call this enhancement Early State Activation. As an example in Figure 2, MAG2 could activate the RO states after having received and processed the RO Initiate message from LMA1. In a similar fashion in Figure 6, MAG2 could activate the RO states after having received and processed the RO Initiate message from LMA1. In case ESA is used, additional mechanisms need to be defined to handle RO setup failure. Indeed, the second MAG contacted could be unable to create the states for some reason, while the RO states and forwarding would already be active on the other MAG. Liebsch, et al. Expires May 16, 2008 [Page 21] Internet-Draft Proxy Mobile IPv6 RO November 2007 Authors' Addresses Marco Liebsch NEC Laboratories Kurfuersten-Anlage 36 69115 Heidelberg, Germany Phone: +49 6221 4342146 Email: liebsch@nw.neclab.eu Long Le NEC Laboratories Kurfuersten-Anlage 36 69115 Heidelberg, Germany Phone: +49 6221 4342224 Email: le@nw.neclab.eu Julien Abeille Cisco Technology Center Av. des Uttins 5 1180 Rolle, Switzerland (FR) Phone: +41 21 822 1696 Email: jabeille@cisco.com Liebsch, et al. Expires May 16, 2008 [Page 22] Internet-Draft Proxy Mobile IPv6 RO November 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). Liebsch, et al. Expires May 16, 2008 [Page 23]