NetExt Working Group P. Loureiro Internet-Draft M. Liebsch Intended status: Standards Track NEC Expires: January 14, 2010 July 13, 2009 Proxy Mobile IPv6 Localized Routing draft-loureiro-netext-pmipv6-ro-01.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on January 14, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Loureiro & Liebsch Expires January 14, 2010 [Page 1] Internet-Draft Proxy Mobile IPv6 Localized Routing July 2009 Abstract The IETF specified Proxy Mobile IPv6 as protocol for network-based mobility management. In Proxy Mobile IPv6, mobile nodes are attached to the network through Mobility Access Gateways and registered with a Local Mobility Anchor. Traffic from and to the mobile node traverses the mobile node's Local Mobility Anchor, irrespective of the location of the mobile node's corresponding communication endpoint. This document specifies a protocol extension to Proxy Mobile IPv6 which allows the set up and maintenance of an optimized routing path between two communicating mobile nodes' Mobility Access Gateways without traversing the mobile nodes' Local Mobility Anchor(s). The protocol component of a rendezvous control point ensures stable maintenance of routing states during handover in scenarios with multiple mobility anchors, where states for the two communication endpoints are distributed between these anchors. Loureiro & Liebsch Expires January 14, 2010 [Page 2] Internet-Draft Proxy Mobile IPv6 Localized Routing July 2009 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 5 3. General Procedure . . . . . . . . . . . . . . . . . . . . . . 6 4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 8 4.1. Setup of Localized Routing - Single LMA . . . . . . . . . 8 4.2. Setup of Localized Routing - Multiple LMAs . . . . . . . . 9 4.3. Maintenance during Handover - Single LMA . . . . . . . . . 10 4.4. Maintenance during Handover - Multiple LMAs . . . . . . . 11 4.5. Extension of the Localized Routing Lifetime . . . . . . . 12 5. Message Format . . . . . . . . . . . . . . . . . . . . . . . . 14 5.1. Protocol Messages . . . . . . . . . . . . . . . . . . . . 14 5.2. Message Options . . . . . . . . . . . . . . . . . . . . . 15 6. IPv4 Considerations . . . . . . . . . . . . . . . . . . . . . 17 6.1. Localized routing for IPv4 Home Addresses . . . . . . . . 17 6.2. IPv4 transport network . . . . . . . . . . . . . . . . . . 17 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 8. Security Considerations . . . . . . . . . . . . . . . . . . . 19 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 20 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 10.1. Normative References . . . . . . . . . . . . . . . . . . . 21 10.2. Informative References . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 Loureiro & Liebsch Expires January 14, 2010 [Page 3] Internet-Draft Proxy Mobile IPv6 Localized Routing July 2009 1. Introduction The IETF specified Proxy Mobile IPv6 (PMIPv6) [RFC5213] as solution for network-based mobility management. In PMIPv6, Mobile Nodes (MNs) are registered with a Local Mobility Anchor (LMA) maintaining a binding between the MN's Home Network Prefix (HNP) and its locator, which is represented by the currently used Mobility Access Gateway (MAG). The MAG's IP address serves as Proxy Care-of Address (Proxy CoA) and is bound to the MN's HNP. Downlink packets, which address the MN's HNP, are forwarded by the MN's LMA by means of an IP tunnel to the MN's current MAG, which terminates the tunnel and delivers the packet to the MN by means of link-layer or point-to-point mechanisms. Uplink packets are tunneled by the MN's MAG to the LMA and then forwarded to the Internet. The PMIPv6 architecture implies that all packets being sent or received by a MN traverse the associated LMA, irrespective of where an MN's correspondent communication endpoint is connected. In case two MNs attach to the same PMIPv6 domain, the routing path for the local communication between these nodes may be sub-optimal, as packets traverse the MNs' LMA(s) [I-D.liebsch-netext-pmip6-ro-ps]. This document specifies an extension to PMIPv6 as per [RFC5213] to set up a route optimized path and associated routing states for local communication between the two MNs' MAGs within a PMIPv6 domain and to maintain these routing states during the MNs' handover. The specified protocol for localized routing follows the network- based mobility management paradigm [RFC4831] and does not require any signaling from the MNs to establish an optimized routing path between the two MNs' MAGs. The present protocol is based on [I-D.abeille-netlmm-proxymip6ro] and supports reliable set up and maintenance of localized routes independent of whether both MNs attach to the same or different LMA and MAG. The protocol relies on a route optimization controller (ROC) function, which is associated with each LMA. In case both MNs are registered with different LMAs, only one selected LMA takes over the control to maintain states on PMIPv6 components during an MN's handover. Hence, the LMA which controls the set up and update of localized routing states represents the rendezvous control point for the route update procedure. Coordination of the route update procedure from a rendezvous point ensures stable maintenance of localized routing during one or both MNs' handover without running into a race condition situation. Loureiro & Liebsch Expires January 14, 2010 [Page 4] Internet-Draft Proxy Mobile IPv6 Localized Routing July 2009 2. Conventions and Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. This document uses the terminology of RFC 5213 [RFC5213]. The following terms are used in the context of this draft: o Mobile Node (MN): Mobile Node without IP mobility support, which is attached to a Mobility Access Gateway (MAG) and registered with a Local Mobility Anchor (LMA) according to the PMIPv6 specification RFC 5213 [RFC5213] o Correspondent Node (CN) - Correspondent Node with or without IP mobility support. The CN represents the communication peer of an MN, which is attached to a MAG and registered with an LMA according to the PMIPv6 specification. o Source MN - Mobile Node associated with the LMA that triggers the route optimization procedure. o Destination MN - Mobile Node associated with the LMA that receives the trigger to initiate the route optimization procedure. o Localized Routing - Result of signaling to set up routing states on relevant network entities to allow forwarding of data packets between an MN and a CN within a single PMIPv6 domain without traversing the MN's LMA and without traversing the CN's mobility anchor. o Localized Routing States - Information for localized routing on relevant forwarding entities on the optimized data path between an MN and a CN. Such information includes route entries and may include further information about the MN and the CN, such as IDs. o RO Trigger - This function is assigned to a network entity, which first detects that RO can be established between the MAGs of two MNs. o RO Control - This function is an integral part of an LMA which supports the set up and maintenance of localized routing. In case localized routing needs to be set up between two nodes, which are registered with different LMAs, only one LMA takes over the control to set up and maintain localized routing. The controlling LMA is selected during the initial establishment of a localized routing path and is responsible for coordinating subsequent updates of localized routing states due to movements of the MNs. Loureiro & Liebsch Expires January 14, 2010 [Page 5] Internet-Draft Proxy Mobile IPv6 Localized Routing July 2009 3. General Procedure According to the PMIPv6 protocol [RFC5213], all traffic generated by an MN attached to a MAG is routed through this MAG to the respective LMA. In the case of Figure 1 all traffic from MN1 to MN2 is routed through MAG1 to LMA1 and then through LMA2 and MAG3 towards MN2. The detection of the possibility to establish a localized path can then be assigned to the LMA of MN1 (LMA1) and it may be determined by analyzing the source/destination addresses of MN1 and MN2, for example. Referring to the reference architecture illustrated in Figure 1, LMA1 will detect the possibility to establish a localized forwarding path between the two MNs and functions as RO Trigger, whereas the role of the RO Controller is assigned to the peer LMA (LMA2). In the case of both MNs being associated to the same LMA and different MAGs, the role of RO Controller and RO Trigger is assigned to the same LMA. The RO Controller coordinates the setup of the localized path at the involved MAGs and is also responsible for updating the localized routing states in case of handover of one of the MNs. The specific case of setting up localized routing in the scenario of multiple LMAs possibly requires the resolution of a destination MN's IP address into the routable IP address of the destination MN's LMA. This is due to the fact that, upon traffic inspection and detection of the possibility of route localization, the LMA can only acquire the IP address of both MNs from the data packet but not the IP address of the peer LMA. An approach to solve this issue is out of scope of this document but discussed in [I-D.liebsch-dime-pmip6-lmaresolve]. After states for localized routing have been established, these states are assigned a Lifetime, which can be extended. Upon expiration of the Lifetime, MAGs and LMAs delete the associated localized routing states. Lifetime refreshing for localized routing states is done independently by each MAG at the respective LMA. A detailed policy when to update localized routing states is out of scope of this specification, but can be based on the result of probes for ongoing traffic. To avoid expiration of localized routing states, MAGs can refresh the associated lifetime and inform the respective LMA about the lifetime extension by means of a Refresh message. Loureiro & Liebsch Expires January 14, 2010 [Page 6] Internet-Draft Proxy Mobile IPv6 Localized Routing July 2009 Internet Backbone ........................ : : | | +----+ +----+ |LMA1|-----------------|LMA2| +----+ +----+ | | | | +-----+------+ +----+ | | | +----+ +----+ +----+ |MAG1| |MAG2| |MAG3| +----+ +----+ +----+ : : +---+ +---+ |MN1| |MN2| +---+ +---+ Figure 1: Reference Architecture Two different modes of operation can be supported for the currently specified protocol. The proxy mode, in which messages between MAGs are relayed through the LMAs, and the direct mode, in which the MAGs are allowed to exchange signaling messages directly at the cost of having to setup security associations between them but requiring a smaller number of message exchanging to setup the localized paths. The present draft focuses on the direct mode, although future versions of the document might consider the specification of the proxy mode. Considerations on the proxy mode can be checked in [I-D.abeille-netlmm-proxymip6ro]. Loureiro & Liebsch Expires January 14, 2010 [Page 7] Internet-Draft Proxy Mobile IPv6 Localized Routing July 2009 4. Protocol Overview In order to support the set up and maintenance of the localized routing procedure, this document introduces the following new signaling messages: o RO Trigger - This message is sent from an LMA to inform another LMA that it must initiate an RO procedure towards a MAG associated to it. It's only used on scenarios with more than one LMA. o RO Trigger Ack - This message is sent from an LMA to inform another LMA about the success of the RO path establishment. It's only used on scenarios with more than one LMA. o RO Init - This message is sent from an LMA to a MAG in order to inform it that it should setup RO according to the received information. It triggers the MAG to contact the peer MAG in order to setup the localized reverse path. o RO Init Ack - This message is sent from MAG to LMA in order to inform the status of the RO initiation setup. o RO Setup - This message is sent from MAG to MAG and informs the receiving MAG that it should setup an RO path according to the received information. o RO Setup Ack - This message is sent from MAG to MAG in order to inform the status of the RO setup. o RO Refresh - This message is sent from MAG to LMA in order to refresh the lifetime of an existing localized routing state. o RO Refresh Ack - This message is sent from LMA to MAG in order to inform the status of the lifetime refresh request. All the scenarios considered in the following chapters assume that traffic is initiated from MN1 towards MN2. 4.1. Setup of Localized Routing - Single LMA For the scenario of Figure 2, two mobile nodes are assumed to be registered with the same LMA and associated with different MAGs (MAG1 and MAG2). When traffic starts from the mobile node attached to MAG1 towards the mobile node attached to MAG2, it is detected by LMA1 and it triggers route localization. LMA1 sends a RO Init (1.) message immediately to MAG2 because it recognizes that the target mobile node is registered to itself so it knows the destination MAG (MAG2). At this point MAG2 starts activating the localized routing states for Loureiro & Liebsch Expires January 14, 2010 [Page 8] Internet-Draft Proxy Mobile IPv6 Localized Routing July 2009 the traffic towards MAG1 and instructs MAG1 to do the same on the inverse path by sending RO Setup (2.). If everything succeeds on the side of MAG1 it sends back RO Setup Ack (3.) to MAG2 with a successful code and MAG2 finally notifies LMA1 of the completion of the procedure by sending RO Init Ack (4.) back to LMA1. In case of failure to setup the forwarding state at MAG2 it should send immediately RO Init Ack with a failure code back to LMA1 instead of sending RO Setup to MAG1. +----+ +----+ +----+ |MAG1| |LMA1| |MAG2| +----+ +----+ +----+ | | | | [Trigger] | | | | | [RO Control] | | | | | |------1.RO Init-------->| | | | |<-----------------2. RO Setup--------------------| |------------------3. RO Setup Ack--------------->| | |<----4. RO Init Ack-----| | | | | | | Figure 2: Route Optimization Setup - Single LMA Note: For the case of single LMA scenarios, the role of Trigger and RO Control is always assigned to the same LMA. 4.2. Setup of Localized Routing - Multiple LMAs In Figure 3, two mobile nodes are registered with different LMAs (LMA1 and LMA2) and attached to two different MAGs (MAG1 and MAG2). LMA1 detects the possibility of localizing the route and since there are currently no associated states it triggers LMA2 by sending RO Trigger (1.) and assigns the role of RO Control to LMA2. The remaining of the signaling is similar to Figure 2 with the exception that LMA2 must inform LMA1 of the final result of the procedure with RO Trigger Ack (6.). Loureiro & Liebsch Expires January 14, 2010 [Page 9] Internet-Draft Proxy Mobile IPv6 Localized Routing July 2009 +----+ +----+ +----+ +----+ |MAG1| |LMA1| |LMA2| |MAG2| +----+ +----+ +----+ +----+ | | | | | [Trigger] | | | | | | | |---1.RO Trigger----->| | | | | | | | [RO Control] | | | | | | | |----2.RO Init------->| |<---------------------3. RO Setup-----------------------------| |----------------------4. RO Setup Ack------------------------>| | | |<---5. RO Init Ack---| | |<-6. RO Trigger Ack--| | | | | | | | | | Figure 3: Route Optimization Setup - Multiple LMAs 4.3. Maintenance during Handover - Single LMA In Figure 4, it is assumed that there is already a localized path established between the mobile node attached to pMAG1 and the mobile node attached to MAG2, it is also assumed that the MN performs an handover to nMAG1. When LMA1 receives the PBU (1.) from nMAG1 it recognizes that there are active route localized states for that mobile node that need to be installed at nMAG1 and updated at MAG2, so it proceeds to send RO Init (3.) to MAG2 following the same procedure as in Figure 2. The localized routing states at pMAG1 can be left to expire together with the BUL entry or can be explicitly deleted if there is a mechanism that allows for MN detachment detection. Loureiro & Liebsch Expires January 14, 2010 [Page 10] Internet-Draft Proxy Mobile IPv6 Localized Routing July 2009 +-----+ +-----+ +----+ +----+ |nMAG1| |pMAG1| |LMA1| |MAG2| +-----+ +-----+ +----+ +----+ | | | | | | [RO Control] | | | | | |--------------1.PBU------------------>| | |<-------------2.PBA-------------------| | | | | | | | [Trigger] | | | | | | | |-----3.RO Init------>| |<-------------------4. RO Setup-----------------------------| |--------------------5. RO Setup Ack------------------------>| | | |<--6.RO Init Ack-----| | | | | | | | | Figure 4: Route Optimization Maintenance during Handover - Single LMA 4.4. Maintenance during Handover - Multiple LMAs In Figure 5, it is assumed an already established localized path between two MNs that are registered under different LMAs. Like in Figure 4, the MN at pMAG1 will perform an handover to nMAG1. Upon receiving the PBU (1.), LMA1 will recognize the existence of active localized routing states and therefore informs LMA2 that it needs to start updating the localized routing states by sending RO Trigger (3.). The remaining of the signaling is similar to Figure 3 with the exception that LMA2 must inform LMA1 of the final result of the procedure with RO Trigger Ack (6.). Similarly to the previous case, the localized routing states at pMAG1 can be left to expire or deleted explicitly. Loureiro & Liebsch Expires January 14, 2010 [Page 11] Internet-Draft Proxy Mobile IPv6 Localized Routing July 2009 +-----+ +-----+ +----+ +----+ +----+ |nMAG1| |pMAG1| |LMA1| |LMA2| |MAG2| +-----+ +-----+ +----+ +----+ +----+ | | | | | | | | [RO Control] | | | | | | |-------1.PBU--------->| | | |<------2.PBA----------| | | | | | | | | | [Trigger] | | | | | | | | | |---3.RO Trigger---->| | | | | |----4.RO Init--->| |<---------------------5.RO Setup-----------------------------| |----------------------6.RO Setup Ack------------------------>| | | | |<-7.RO Init Ack--| | | |<--8.RO Trigger Ack-| | | | | | | | | | | | Figure 5: Route Optimization Maintenance during Handover - Multiple LMAs Note: In the case that the MN being attached to MAG2 performs the handover, there would be a direct RO Init message from LMA2 towards the new MAG (no RO trigger message is sent) due to the fact that the RO Control is assigned to LMA2. 4.5. Extension of the Localized Routing Lifetime Upon an expiring lifetime of localized routing states, it can be refreshed by any of the involved MAGs towards the respective LMA. This is accomplished by sending a RO Refresh message (1.) to the LMA, as depicted in Figure 6. The LMA replies with the status with a RO Refresh Ack message (2.). Expired localized routing states, which are not refreshed, are deleted and the traffic goes back to being forwarded through the LMA. In case of a multi-LMA scenario, MAGs can refresh the localized routing state lifetime by sending a RO Refresh message towards the respective LMA. The receiving LMA must reply back with the status in a RO Refresh Ack message. As in the single-LMA scenario above, expired localized routing states are deleted. Loureiro & Liebsch Expires January 14, 2010 [Page 12] Internet-Draft Proxy Mobile IPv6 Localized Routing July 2009 +----+ +----+ +----+ |MAG1| |LMA1| |MAG2| +----+ +----+ +----+ | | | | | [RO Timer] | | | | |<-----1.RO Refresh------| | | | | |----2.RO Refresh Ack--->| | | | | | | Figure 6: Lifetime Extension of Localized Routing States Loureiro & Liebsch Expires January 14, 2010 [Page 13] Internet-Draft Proxy Mobile IPv6 Localized Routing July 2009 5. Message Format 5.1. Protocol Messages This version of the protocol defines 4 new protocol commands plus associated Acknowledgements. The protocol messages extend the set of Mobility Header types, whereas some of these messages do not apply to the protocol interface between a MAG and an LMA, but to the interface between two MAGs or between two LMAs respectively. A list of currently specified messages is given below for the discussion of the protocol specification, whereas the detailed format of the options will be added in an updated version of the document. All formats of the new Mobility Header types carry a RO_Lifetime field to signal the lifetime of a localized routing state. All formats of the new Mobility Header types which represent an Acknowledgement of a control message carry a Status code in the header. RO Trigger - Route Optimization Trigger. Including the format is t.b.d. The following list are valid options, which must be included with this message: HNP Option - Home Network Prefix of Source MN. HNP Option - Home Network Prefix of Destination MN. MAG-ADDR Option - IPv6 address of the Source MN's MAG. RO Trigger Ack - Route Optimization Trigger Acknowledgment. Including the format is t.b.d. The following list are valid options, which must be included with this message: HNP Option - Home Network Prefix of Source MN. HNP Option - Home Network Prefix of Destination MN. RO Init - Route Optimization Initiation. Including the format is t.b.d. HNP Option - Home Network Prefix of Source MN. HNP Option - Home Network Prefix of Destination MN. Loureiro & Liebsch Expires January 14, 2010 [Page 14] Internet-Draft Proxy Mobile IPv6 Localized Routing July 2009 MAG-ADDR Option - IPv6 address of the Source MN's MAG. RO Init Ack - Route Optimization Initiation Acknowledgment. Including the format is t.b.d. HNP Option - Home Network Prefix of Source MN. HNP Option - Home Network Prefix of Destination MN. RO Setup - Route Optimization Setup. Including the format is t.b.d. HNP Option - Home Network Prefix of Source MN. HNP Option - Home Network Prefix of Destination MN. MAG-ADDR Option - IPv6 address of the Destination MN's MAG. RO Setup Ack - Route Optimization Setup Acknowledgment. Including the format is t.b.d. HNP Option - Home Network Prefix of Source MN. HNP Option - Home Network Prefix of Destination MN. RO Refresh - Route Optimization Refresh. Including the format is t.b.d. HNP Option - Home Network Prefix of Source MN. HNP Option - Home Network Prefix of Destination MN. RO Refresh Ack - Route Optimization Refresh Acknowledgment. Including the format is t.b.d. HNP Option - Home Network Prefix of Source MN. HNP Option - Home Network Prefix of Destination MN. 5.2. Message Options This version of the protocol defines 1 new Mobility Header option, which is applied with the signaling messages specified in this document. All options must meet the 32-bit boundary alignment. A list of currently used options is given below for the discussion of the protocol specification, whereas the detailed format of the options will be added in an updated version of the document. Loureiro & Liebsch Expires January 14, 2010 [Page 15] Internet-Draft Proxy Mobile IPv6 Localized Routing July 2009 MAG-ADDR - IPv6 address of the source/destination MN's MAG. Including the format is t.b.d. To signal the IPv6 address/prefix of the source and destination MN as communication endpoints, this specification uses the Home Network Prefix option of [RFC5213]. To signal the IPv4 HoA of the source and destination MN as communication endpoints, this specification uses the IPv4 Home Address option of [RFC5555]. Loureiro & Liebsch Expires January 14, 2010 [Page 16] Internet-Draft Proxy Mobile IPv6 Localized Routing July 2009 6. IPv4 Considerations 6.1. Localized routing for IPv4 Home Addresses IPv4 or dual stack enabled hosts may be served by a PMIPv6 network according to [I-D.ietf-netlmm-pmip6-ipv4-support]. To support the set up and maintenance of localized routes for IPv4 Home Addresses in PMIPv6, MAGs must add both MNs' IPv4 Home Addresses into their conceptual data structures where they store information about the MNs' routing states. Furthermore, MAGs must support encapsulation of IPv4 packets and dynamically enter and update the associated forwarding entry towards the correspondent MAG in their routing table. For uplink traffic, MAGs must take routing decisions on the IP address tuple represented by the source and the destination address of the packet. To signal the IPv4 Home Address of the two MNs, whose routing path needs to be optimized, the localized routing protocol messages include a IPv4 HoA option in their signaling messages. In case of localized routing for IPv4 HoAs, the IPv4 HoA option of the source and destination MN must be included in all signaling messages for the setup and maintenance of the localized routing states to identify the communication endpoints. According to the definition in this document, the MN which originates the communication and whose IP packet triggers the set up of an optimized routing path, is considered as the Source, whereas the recipient of this packet is considered as the Destination. 6.2. IPv4 transport network In case the transport network between PMIPv6 components supports IPv4 only, encapsulation of signaling messages for localized routing is performed according to [I-D.ietf-netlmm-pmip6-ipv4-support]. The same encapsulation modes apply to the protocol interface between MAGs. In such case, a MAG must enable the same or a different IPv4 address as used for the signaling with the LMA for the signaling with the correspondent MAG. The same applies to LMAs, which must enable an IPv4 address for the signaling with a potentially correspondent LMA. Selection of an appropriate encapsulation mode is out of scope of this version of the specification. In case of an IPv4 transport network which has a NAT between a MAG and an LMA or even between MAGs, using IPv4-UDP encapsulation is recommended. NATs between MAGs may be detected according to the NAT presence detection scheme as described in [I-D.ietf-netlmm-pmip6-ipv4-support], whereas instead of a PBU/PBA handshake the RO Setup/RO Setup Ack signaling handshake is being used to apply the detection mechanism. Loureiro & Liebsch Expires January 14, 2010 [Page 17] Internet-Draft Proxy Mobile IPv6 Localized Routing July 2009 7. IANA Considerations This document defines 8 new Mobility Header types for the MH Type field in the Mobility Header. These types are described in Section 5.1. According to the protocol specification, the Mobility Header type identifies also the protocol interface, on which a protocol message is being applied. This document defines 1 new Mobility Header option. This option is described in Section 5.2. Loureiro & Liebsch Expires January 14, 2010 [Page 18] Internet-Draft Proxy Mobile IPv6 Localized Routing July 2009 8. 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 [RFC5213]. Protection of signaling messages between an LMA and a MAG uses the mechanisms of Encapsulating Security Payload (ESP) [RFC4301] 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. Loureiro & Liebsch Expires January 14, 2010 [Page 19] Internet-Draft Proxy Mobile IPv6 Localized Routing July 2009 9. Contributors This document is based on an early contribution to the NetLMM Working Group [I-D.abeille-netlmm-proxymip6ro]. Many thanks to Julien Abeille, who contributed a lot to the original concept of this protocol extension to Proxy Mobile IPv6. Loureiro & Liebsch Expires January 14, 2010 [Page 20] Internet-Draft Proxy Mobile IPv6 Localized Routing July 2009 10. References 10.1. Normative References [I-D.ietf-netlmm-pmip6-ipv4-support] Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy Mobile IPv6", draft-ietf-netlmm-pmip6-ipv4-support-13 (work in progress), June 2009. [I-D.liebsch-dime-pmip6-lmaresolve] Liebsch, M., Loureiro, P., and J. Korhonen, "Local Mobility Anchor Resolution for PMIPv6", draft-liebsch-dime-pmip6-lmaresolve-00 (work in progress), March 2009. [I-D.liebsch-netext-pmip6-ro-ps] Liebsch, M., "PMIPv6 Localized Routing Problem Statement", draft-liebsch-netext-pmip6-ro-ps-00 (work in progress), February 2009. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005. [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. [RFC5555] Soliman, H., "Mobile IPv6 Support for Dual Stack Hosts and Routers", RFC 5555, June 2009. 10.2. Informative References [I-D.abeille-netlmm-proxymip6ro] Liebsch, M., Le, L., and J. Abeille, "Route Optimization for Proxy Mobile IPv6", draft-abeille-netlmm-proxymip6ro-01 (work in progress), November 2007. [RFC4831] Kempf, J., "Goals for Network-Based Localized Mobility Management (NETLMM)", RFC 4831, April 2007. Loureiro & Liebsch Expires January 14, 2010 [Page 21] Internet-Draft Proxy Mobile IPv6 Localized Routing July 2009 Authors' Addresses Paulo Loureiro NEC Laboratories Europe NEC Europe Ltd. Kurfuersten-Anlage 36 69115 Heidelberg, Germany Phone: +49 6221 4342177 Email: paulo.loureiro@nw.neclab.eu Marco Liebsch NEC Laboratories Europe NEC Europe Ltd. Kurfuersten-Anlage 36 69115 Heidelberg, Germany Phone: +49 6221 4342146 Email: marco.liebsch@nw.neclab.eu Loureiro & Liebsch Expires January 14, 2010 [Page 22]