Network Working Group J. Korhonen, Ed. Internet-Draft Nokia Siemens Networks Intended status: Standards Track S. Gundavelli Expires: April 2, 2011 Cisco H. Yokota KDDI Lab X. Cui Huawei Technologies September 29, 2010 Runtime LMA Assignment Support for Proxy Mobile IPv6 draft-ietf-netext-redirect-04.txt Abstract This document describes a runtime Local Mobility Anchor assignment functionality and corresponding mobility options for Proxy Mobile IPv6. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on April 2, 2011. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must Korhonen, et al. Expires April 2, 2011 [Page 1] Internet-Draft Runtime LMA Assignment September 2010 include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Requirements and Terminology . . . . . . . . . . . . . . . . . 5 2.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 5 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 3. Proxy Mobile IPv6 Domain Assumptions . . . . . . . . . . . . . 6 4. Mobility Options . . . . . . . . . . . . . . . . . . . . . . . 7 4.1. Redirect-Capability Mobility Option . . . . . . . . . . . 7 4.2. Redirect Mobility Option . . . . . . . . . . . . . . . . . 7 5. Runtime LMA Assignment . . . . . . . . . . . . . . . . . . . . 10 5.1. Common Mobile Access Gateway Operation . . . . . . . . . . 10 5.2. Common Local Mobility Anchor Operation . . . . . . . . . . 10 5.3. Mobility Session Created During the Runtime Assignment . . 11 5.3.1. General Operation . . . . . . . . . . . . . . . . . . 11 5.3.2. Mobile Access Gateway Operation . . . . . . . . . . . 12 5.3.3. Local Mobility Anchor Operation . . . . . . . . . . . 13 5.4. Mobility Session Created After the Runtime Assignment . . 13 5.4.1. General Operation . . . . . . . . . . . . . . . . . . 14 5.4.2. Mobile Access Gateway Operation . . . . . . . . . . . 14 5.4.3. Local Mobility Anchor Operation . . . . . . . . . . . 15 6. Multi-Homing Considerations . . . . . . . . . . . . . . . . . 16 7. Configuration Variables . . . . . . . . . . . . . . . . . . . 17 8. Security Considerations . . . . . . . . . . . . . . . . . . . 18 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 11.1. Normative References . . . . . . . . . . . . . . . . . . . 21 11.2. Informative References . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 Korhonen, et al. Expires April 2, 2011 [Page 2] Internet-Draft Runtime LMA Assignment September 2010 1. Introduction This document describes the Redirect-Capability and the Redirect mobility options, and the corresponding functionality for a runtime assignment of the Local Mobility Anchor (LMA) for Proxy Mobile IPv6 (PMIPv6). The runtime LMA assignment takes place during a Proxy Binding Update (PBU) and a Proxy Binding Acknowledgement (PBA) messages exchange between a Mobile Access Gateway (MAG) and a LMA. The runtime LMA assignment functionality defined in this specification can be used, for example, for load balancing purposes during the initial PBU/PBA messages exchange. However, other use cases are also possible. In case of load balancing, the runtime LMA assignment approach is just one implementation option. MAGs and LMAs can implement other solutions that are, for example, completely transparent at PMIPv6 protocol level and do not depend on the functionality defined in this specification. The runtime LMA assignment functionality described in this specification does not depend on information provisioned to external entities, such as the Domain Name System (DNS) or the Authentication, Authorization and Accounting (AAA) infrastructure. The trust relationship and coordination management between LMAs within a PMIPv6 domain is deployment specific and not described in this specification. There are number of reasons, why the runtime LMA assignment is an useful addition to the PMIPv6 protocol. The following list describes some identified ones: o LMAs with multiple IP addresses: a cluster of LMAs or a blade architecture LMA may appear to the routing system as multiple LMAs with separate unicast IP addresses. A MAG can initially select any of those LMA IP addresses as the LMA Address using e.g., DNS- and AAA-based solutions. However, MAG's initial selection may be suboptimal from the LMA point of view and immediate runtime assignment to a "proper LMA" would be needed. The LMA could use [RFC5142] based approach but that would imply unnecessary setting up of a mobility session in a "wrong LMA" with associated backend support system interactions, involve additional signaling between the MAG and the LMA, and re-establishing mobility session to the new LMA again with associated signaling. o Bypassing a load balancer: a cluster of LMAs or a blade architecture LMA may have a load balancer in front of them or integrated in one of the LMAs. The load balancer would represent multiple LMAs during the LMA discovery phase and only its IP address would be exposed to the MAG hiding possible individual LMA or LMA blade IP addresses from the MAG. However, if all traffic Korhonen, et al. Expires April 2, 2011 [Page 3] Internet-Draft Runtime LMA Assignment September 2010 must always go through the load balancer it becomes quickly a bottleneck. Therefore, a PMIPv6 protocol level support for bypassing the load balancer after the initial PBU/PBA exchange would greatly help scalability. Also bypassing the load balancer as soon as possible allows implementing load balancers that do not maintain any MN specific state information. o Independence from DNS: DNS-based load balancing is a common practise. However, keeping MAGs up-to-date with LMA load status using DNS is hard e.g., due caching and unpredictable zone update delays [I-D.ietf-netlmm-lma-discovery]. Generally, LMAs constantly updating [RFC2136] zone's master DNS server might not feasible in a large PMIPv6 domain due to increased load on the master DNS server and additional background signaling. Furthermore, MAGs may do (LMA) destination address selection decisions that are not in-line what the DNS administrator actually wanted [RFC3484]. o Independence from AAA: AAA-based solutions have basically the same arguments as DNS-based solutions above. It is also typical that AAA-based solutions offload the initial LMA selection to the DNS infrastructure [RFC5779]. The AAA infrastructure does not return an IP address or a Fully Qualified domain Name (FQDN) to a single LMA, rather a FQDN representing a group of LMAs. o Support for IPv6 anycast addressing [RFC4291]: the current PMIPv6 specification does not specify how the PMIPv6 protocol should treat anycast addresses assigned to mobility agents. For example, a blade architecture LMA may appear to the routing system as multiple LMAs with separate unicast IP addresses and with one or more "grouping" anycast addresses. A MAG could then initially send a PBU to an anycast LMA address and receive a PBA from an anycast LMA address. Once the MAG receives the unicast address of the selected r2LMA through the initial PBU/PBA exchange, the MAG MUST immediately start using that unicast address for the mobility session. Korhonen, et al. Expires April 2, 2011 [Page 4] Internet-Draft Runtime LMA Assignment September 2010 2. Requirements and Terminology 2.1. Requirements 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]. 2.2. Terminology In addition to the terminology defined in [RFC5213], the following terminology is also used: rfLMA An LMA which receives a PBU from a MAG and decides to assign an IP mobility session with a new target LMA (r2LMA). r2LMA The LMA assigned to a MAG as a result of the runtime LMA assignment. Runtime Assignment Domain A group of LMAs that consist of at least one rfLMA and one or more r2LMAs. A rfLMA is allowed to assign MAGs only with r2LMAs that belong to the same runtime assignment domain. The rfLMA and one or more r2LMAs may consist of multiple blades in a single network element, multiple physical network elements, or multiple LMAs distributed geographically. Korhonen, et al. Expires April 2, 2011 [Page 5] Internet-Draft Runtime LMA Assignment September 2010 3. Proxy Mobile IPv6 Domain Assumptions The runtime LMA assignment functionality has several assumptions on the PMIPv6 domain. They are discussed here as they have an impact on PMIPv6 deployment. Each LMA in a runtime assignment domain MUST be reachable at an unicast IP address. The rfLMA and the r2LMA MUST have a prior agreement, adequate means to secure their inter-LMA communication and an established trust relationship to perform the runtime LMA assignment. The rfLMA MUST NOT assign a MAG with a r2LMA, if the rfLMA knows the r2LMA cannot accept a mobility session from the MAG. That is, the runtime assignment functionality is not enabled in the r2LMA, or the r2LMA does not belong to the same runtime assignment domain as the rfLMA, or the r2LMA is down or otherwise unreachable. How the rfLMA learns and knows the capabilities of other r2LMAs in the runtime assignment domain, is not covered by this specification. Each LMA and MAG participating to the runtime LMA assignment is assumed to have required Security Associations (SA) already set up in advance. Dynamic negotiation of the SAs using e.g., IKEv2 [RFC5996] SHOULD be supported but is out of scope of this specification. The LMA MUST NOT include the Redirect mobility option in the PBA and perform the runtime LMA assignment, unless the MAG indicated the runtime LMA assignment functionality support in the corresponding PBU using the Redirection-Capability mobility option. The LMA MUST NOT include the Redirect mobility option unsolicited even if the MAG had earlier indicated support for the runtime LMA assignment functionality. MAGs and LMAs implementing the runtime LMA assignment functionality MUST support the runtime LMA assignment during the initial PBU/PBA exchange which creates a new mobility session. A mid-session LMA assignment may make use of [RFC5142] Korhonen, et al. Expires April 2, 2011 [Page 6] Internet-Draft Runtime LMA Assignment September 2010 4. Mobility Options 4.1. Redirect-Capability Mobility Option A PBU message SHOULD contain the Redirect-Capability mobility option as an indication to a LMA that a MAG supports the runtime LMA assignment functionality. When this option is included, the MAG may be assigned with another LMA, and the assigned LMA may simultaneously create a Binding Cache Entry (BCE). Hence, the MAG including this option MUST be able to support runtime LMA assignment with and without a creation of a BCE in the runtime assigned LMA. The Redirect-Capability mobility option has the alignment requirement of 4n. There can zero or one Redirect-Capability mobility option in the PBU. The format of the Redirect-Capability mobility option is shown below: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option Type | Option Length |F| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Redirect-Capability Mobility Option o Option Type: 8-bit identifier set to TBD1. o Option Length: 8-bit unsigned integer, representing the length of the Redirect-Capability mobility option in octets, excluding the Option Type and Length fields. The Option Length MUST be set to 2. o 'F' flag: This bit is set (1) if the MAG supports IPv4 transport. Otherwise, the bit is unset (0). o Reserved: This field is reserved for future use. MUST be set to zero. 4.2. Redirect Mobility Option The LMA MUST include the Redirect mobility option in a PBA only if the MAG indicated support for the runtime LMA assignment functionality and runtime LMA assignment took place. The Redirect mobility option in the PBA MUST contain at least one unicast address of the r2LMA. There can at most one Redirect mobility option in the PBA. The Redirect mobility option has the alignment requirement of 4n. Korhonen, et al. Expires April 2, 2011 [Page 7] Internet-Draft Runtime LMA Assignment September 2010 The format of the Redirect mobility option is shown below: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option Type | Option Length |K|N| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Optional IPv6 r2LMA Address | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Optional IPv4 r2LMA Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Redirect Mobility Option o Option Type: 8-bit identifier set to TBD2. o Option Length: 8-bit unsigned integer, representing the length of the Redirect mobility option in octets, excluding the Option Type and Length fields. If 'K' flag is set and 'N' is unset, then the length MUST be 18. If 'K' flag is unset and 'N' is set, then the length MUST be 6. If both 'K' and 'N' flags are set, then the length MUST be 22. o 'K' flag: This bit is set (1) if the 'Optional IPv6 r2LMA Address' is included in the mobility option. Otherwise, the bit is unset (0). o 'N' flag: This bit is set (1) if the 'Optional IPv4 r2LMA Address' is included in the mobility option. Otherwise, the bit is unset (0). o Reserved: This field is reserved for future use. MUST be set to zero. o Optional IPv6 r2LMA Address: the unicast IPv6 address of the r2LMA. This value is present if the r2LMA IPv6 address is available. o Optional IPv4 r2LMA Address: the IPv4 address of the r2LMA. This value is present if the r2LMA IPv4 address is available and the 'F' flag was set in the corresponding Redirect-Capability mobility option. Korhonen, et al. Expires April 2, 2011 [Page 8] Internet-Draft Runtime LMA Assignment September 2010 Both 'K' and 'N' flags MUST NOT be unset at the same time. Korhonen, et al. Expires April 2, 2011 [Page 9] Internet-Draft Runtime LMA Assignment September 2010 5. Runtime LMA Assignment 5.1. Common Mobile Access Gateway Operation In the base PMIPv6 protocol [RFC5213] a MAG sends a PBU to an LMA, which results in a BCE creation at the LMA and the LMA sending a PBA sent back to the MAG. The MAG in turn creates an entry in its Binding Update List (BUL). This specification extends the base protocol with the runtime LMA assignment functionality. Backwards compatibility is maintained in a deployment wherein some MAGs may have the ability to support runtime LMA assignment while others do not. This is accomplished by the use of the Redirect- Capability mobility option that a MAG includes in the PBU. If the runtime LMA assignment functionality is supported and also enabled, then the MAG SHOULD include the Redirect-Capability mobility option in a PBU that establishes a new mobility session. The Redirect- Capability mobility option in the PBU is also an indication to an LMA that the MAG supports the runtime LMA assignment functionality and is prepared to be assigned with a different LMA. The runtime LMA assignment concerns always one mobility session at time. If the MAG receives a PBA that contains the Redirect mobility option without first including the Redirect-Capability mobility option in the corresponding PBU, then the MAG MUST treat the PBA as if the binding update failed and SHOULD log the event. 5.2. Common Local Mobility Anchor Operation The text in the following sections refers to a 'LMA' when it means the combination of the rfLMA and the r2LMA i.e., the entity where runtime LMA assignment is possible. When the text points to a specific LMA role during the runtime assignment, it uses either the 'rfLMA' or the 'r2LMA'. If the runtime assignment functionality is enabled in the LMA but the LMA assignment is not going to take place for a reason or other, and the rfLMA is not willing to serve (or capable of) as a normal RFC 5213 LMA for the MAG, then the rfLMA MUST reject the PBU and send back a PBA with Status Value set to 130 (Insufficient resources) error code. Otherwise, the rfLMA MUST act as a normal RFC 5213 defined LMA for the MAG. The rfLMA MUST only assign the MAG with a new r2LMA that it knows the MAG has a SA with or the MAG and the r2LMA are able to create it dynamically. The rfLMA MUST NOT assign the MAG with a r2LMA that the rfLMA and the r2LMA do not have a prior agreement and an established trust relationship for the runtime LMA assignment. These SA related Korhonen, et al. Expires April 2, 2011 [Page 10] Internet-Draft Runtime LMA Assignment September 2010 knowledge issues and trust relationships are deployment specific in a PMIPv6 domain and in a runtime assignment domain, and out of scope of this specification. Possible context transfer and other coordination management between the rfLMA and the r2LMA, are again deployment specific for LMAs in a runtime assignment domain. The rfLMA MUST NOT assign a MAG using IPv6 transport with a new r2LMA using IPv4 transport, if the MAG does not indicate support for IPv4 in the Redirect-Capability mobility option, as there is no guarantee that the MAG supports switching from IPv6 transport to IPv4 transport. The same also applies for assigning a MAG using IPv4 transport with a r2LMA supporting only IPv6 transport. If the r2LMA has IPv4 support enabled and the 'F' flag was set in the corresponding Redirect-Capability mobility option, then the PBA returned to the MAG SHOULD include the IPv4 address of the r2LMA in the Redirect mobility option even if IPv6 transport is used. As a result of a successful runtime LMA assignment, the PBA MUST contain the Redirect mobility option with a valid r2LMA Address and the PBA Status Value indicating success. In general the r2LMA may be a normal RFC 5213 LMA without any runtime LMA assignment functionality. The r2LMA MAY also include rfLMA functionality in which case the consideration described in the following sections for the rfLMA apply. If the runtime LMA assignment functionality is implemented but not enabled in a LMA, then the LMA MUST ignore the Redirect-Capability mobility option received in PBUs and act as a LMA defined in RFC 5213. 5.3. Mobility Session Created During the Runtime Assignment 5.3.1. General Operation During the runtime LMA assignment, the PBA is returned from the LMA Address where the PBU was sent to i.e., from the rfLMA. After the runtime LMA assignment all PMIPv6 communication continues directly between the MAG and the r2LMA. The overall runtime LMA assignment flow sequence is shown in Figure 1. Korhonen, et al. Expires April 2, 2011 [Page 11] Internet-Draft Runtime LMA Assignment September 2010 MAG rfLMA r2LMA | | | 1) |--PBU-->| ~ ~ ~ | (LMA assignment takes place, BCE gets created 2) |<--PBA--| ~ ~ ~ | in r2LMA, PBA contains r2LMA information and | | | Status Value set to | | | Accepted_and_Redirected_with_Binding) 3) |<=====data======>| | | | 4) |-------PBU------>| (lifetime extension, 5) |<------PBA-------| de-registration, etc.) | | | Figure 1: Runtime LMA assignment from rfLMA to r2LMA and setting up a mobility session in the r2LMA within a runtime assignment domain The assumption in the signaling flow step 1) shown in Figure 1 is that the mobility session gets created in the r2LMA, although the rfLMA is responsible for interfacing with the MAG. The interaction between the rfLMA and the r2LMA in the runtime assignment domain is not defined in this specification. There are several possible solutions for the rfLMA and the r2LMA interaction depending on e.g. the collocation properties of the rfLMA and the r2LMA, and whether the rfLMA and the r2LMA just use base PMIPv6 protocol between each other. 5.3.2. Mobile Access Gateway Operation In addition to MAG operations described in Section 5.1, the following considerations has to taken into account during the runtime LMA assignment. If the MAG receives a PBA that contains the Redirect mobility option and the Status Value set to TBD3 (Accepted_and_Redirected_with_Binding), and the MAG had included the Redirect-Capability mobility option in the corresponding PBU, then the MAG MUST perform the following steps in addition to the normal RFC 5213 PBA processing: o If there is no SA between the MAG and the r2LMA, the MAG MAY treat the PBA as if the binding update failed and log the event. The MAG SHOULD initiate a dynamic creation of the SA between the MAG and the r2LMA (note that the dynamic creation of the SA is outside of the scope of this specification). If the runtime LMA assignment was successful, the MAG updates the BUL to correspond the r2LMA Address included in the received Redirect mobility option. There is no need to resend any PBUs to the r2LMA after a successful runtime assignment. The mobility session has Korhonen, et al. Expires April 2, 2011 [Page 12] Internet-Draft Runtime LMA Assignment September 2010 already been established in the r2LMA as indicated by the Status Value TBD3 (Accepted_and_Redirected_with_Binding). The MAG MUST send subsequent binding refreshing PBUs and user traffic to the new r2LMA Address. 5.3.3. Local Mobility Anchor Operation If the runtime LMA assignment functionality is enabled in the LMA and the received PBU contains the Redirect-Capability mobility option, then the rfLMA MAY assign the MAG with a new r2LMA. In the case of runtime LMA assignment, the PBA returned to the MAG MUST always include the unicast IP address (IPv6, IPv4 or both) of the r2LMA in the Redirect mobility option and the Status Value set to TBD3 (Accepted_and_Redirected_with_Binding). If the rfLMA did not assign the MAG with a new r2LMA or the runtime LMA assignment failed, then the PBA MUST NOT contain the Redirect mobility option. If the runtime LMA assignment was successful, the mobility session MUST be established in the r2LMA. The actual PBU processing that creates the mobility session and the corresponding BCE takes place in the r2LMA. However, depending on the LMA's implementation of the PMIPv6 security framework, the security processing (such as IPsec) of the PBU may take place in the rfLMA before the PBU is transferred from the rfLMA to the r2LMA. Whenever the runtime assignment processing has involved the r2LMA, the PBA sent by the rfLMA to the MAG MUST reflect the information the r2LMA would include in its PBA (such as mobility options, Status Value and so on). The only exceptions are possible security related options that the rfLMA MAY need to modify or remove. The rfLMA is always allowed to add more mobility options to the PBA. During the runtime LMA assignment process, the rfLMA MAY need to maintain a temporary MAG-rfLMA-r2LMA state and may even act as a "proxy MAG" to the r2LMA. This, however, depends on the collocation properties of the rfLMA and the r2LMA, and how the rfLMA interact with the r2LMA. The interaction may happen as a PBU/PBA packet forwarding/proxying in a conventional sense or as an inter-blade communication using some LMA architecture specific communication method. Once the runtime LMA assignment has completed successfully from the rfLMA point of view and it has sent the PBA to the MAG, the rfLMA can remove all state information regarding the recent runtime LMA assignment. 5.4. Mobility Session Created After the Runtime Assignment Korhonen, et al. Expires April 2, 2011 [Page 13] Internet-Draft Runtime LMA Assignment September 2010 5.4.1. General Operation During the runtime LMA assignment the PBA is returned from the LMA Address where the PBU was sent to i.e., from the rfLMA. After the runtime LMA assignment, the MAG has to initiate another PBU/PBA exchange with the r2LMA and after that all PMIPv6 communication continues between the MAG and the r2LMA. The overall runtime LMA assignment flow sequence is shown in Figure 2. MAG rfLMA r2LMA | | | 1) |--PBU-->| | (assignment takes place, PBA contain 2) |<--PBA--| | r2LMA information, Status Value set | | | to Rejected_but_Redirected) | | | 3) |-------PBU------>| (BCE gets created in r2LMA) 4) |<------PBA-------| | | | 5) |<=====data======>| | | | 6) |-------PBU------>| (lifetime extension, 7) |<------PBA-------| de-registration, etc.) | | | Figure 2: Runtime LMA assignment from rfLMA to r2LMA within a runtime assignment domain The assumption in the signaling flow steps 1) and 2) shown in Figure 2 is that the MAG is only assigned with the r2LMA. The mobility session creation with the r2LMA requires a new PBU/PBA exchange with the r2LMA using the normal RFC 5213 procedures. 5.4.2. Mobile Access Gateway Operation The MAG operation is exactly the same as described in Section 5.1 and Section 5.3.2 except for two aspects: o The Status Value in the received PBA is set to TBD4 (Rejected_but_Redirected). This indicates to the MAG that there is no mobility session (i.e. BCE) created in the r2LMA and not in the rfLMA either. The MAG was only assigned with a new r2LMA Address information. o The MAG MUST initiate a new PBU/PBA exchange with the r2LMA in order to establish a mobility session. Only after a successful PBU/PBA exchange with the r2LMA, the runtime assignment has completed. The initial PBU sent to the r2LMA SHOULD NOT contain Korhonen, et al. Expires April 2, 2011 [Page 14] Internet-Draft Runtime LMA Assignment September 2010 the Redirect-Capability mobility option in order to avoid possible immediate new runtime LMA assignment. 5.4.3. Local Mobility Anchor Operation If the runtime LMA assignment functionality is enabled in the LMA and the received PBU contains the Redirect-Capability mobility option, then the rfLMA MAY assign the MAG with a new r2LMA. In the case of runtime LMA assignment, the PBA returned to the MAG MUST always include the unicast IP address (IPv6, IPv4 or both) of the r2LMA in the Redirect mobility option and the Status Value set to TBD4 (Rejected_but_Redirected). If the rfLMA did not assign the MAG with a new r2LMA or the runtime assignment failed, then the PBA MUST NOT contain the Redirect mobility option and the PBA is processed according to RFC 5213. Korhonen, et al. Expires April 2, 2011 [Page 15] Internet-Draft Runtime LMA Assignment September 2010 6. Multi-Homing Considerations A MN can be multi-homed. A single LMA entity should have the control over all possible multi-homed mobility sessions the MN has. All mobility sessions a multi-homed MN may have SHOULD be anchored in the single LMA entity. Therefore, once the MN has established one mobility session with one LMA, the subsequent mobility sessions of the same MN SHOULD be anchored to the LMA that was initially assigned. One possible solution already supported by this specification is applying the runtime LMA assignment only for the very first initial attach a multi-homed MN does towards a PMIPv6 domain. After the initial attach, the assigned r2LMA Address has been stored in the policy profile. For the subsequent mobility sessions of the multi- homed MN, the same assigned r2LMA Address would be used and there is no need to contact the rfLMA. MAGs have a control over selectively enabling and disabling the runtime assignment of the LMA. If the multi-homed MN is attached to a PMIPv6 domain via multiple MAGs, the assigned r2LMA Address should be stored in the remote policy store and downloaded as a part of the policy profile download to a MAG. Alternatively, MAGs can share policy profile information using other means. In both cases, the actual implementation of the policy profile information sharing is specific to a PMIPv6 deployment and out of scope of this specification. Korhonen, et al. Expires April 2, 2011 [Page 16] Internet-Draft Runtime LMA Assignment September 2010 7. Configuration Variables This specification defines three configuration variables that control the runtime LMA assignment functionality within a PMIPv6 domain. EnableLMARedirectFunction This configuration variable is available in both a MAG and in a rfLMA. When set to TRUE (i.e., enabled), the PMIPv6 node enables the runtime LMA assignment functionality. The default value is FALSE (i.e., disabled). EnableLMARedirectAcceptFunction This configuration variable is available in a r2LMA. When set to TRUE (i.e., enabled), the r2LMA is able to accept runtime LMA assignment mobility sessions from a rfLMA. The default value is FALSE (i.e., disabled). Korhonen, et al. Expires April 2, 2011 [Page 17] Internet-Draft Runtime LMA Assignment September 2010 8. Security Considerations The security considerations of PMIPv6 signaling described in RFC 5213 apply to this document. An incorrectly configured LMA may cause unwanted runtime LMA assignment attempts to non-existing LMAs or to other LMAs that do not have and will not have a SA with the MAG. Consequently, the MAG will experience failed binding updates or unsuccessful creation of mobility sessions. An incorrectly configured LMA may also cause biased load distribution within a PMIPv6 domain. This document also assumes that the LMAs that participate to runtime LMA assignment have adequate prior agreement and trust relationship between each other. If the SAs between MAGs and LMAs are manually keyed (as it may be needed by the scenario described in Section 5.3), then the anti- replay service of ESP protected PMIPv6 traffic cannot typically be provided. This is, however, deployment specific to a PMIPv6 domain. If a PMIPv6 domain deployment with a runtime LMA assignment requires that a rfLMA has to modify a PBU/PBA in any way e.g., by changing the source and destination IP address or any other field of the encapsulating IP packet, then the security mechanism (such as possible authentication options) used to protect the PBU/PBA MUST NOT cover the outer IP packet on those parts that might get modified. Alternatively, the rfLMA can do all required security processing on the PBU/PBA, and the communication between the rfLMA and the r2LMA would be unprotected at the PMIPv6 protocol level. In this case the runtime assignment domain MUST implement adequate level of security using other means, such as layer-2 VPNs. Korhonen, et al. Expires April 2, 2011 [Page 18] Internet-Draft Runtime LMA Assignment September 2010 9. IANA Considerations Two new mobility options for the use with PMIPv6 are defined in the [RFC3775] "Mobility Options" registry. The mobility options are defined in Section 4: Redirect-Capability Mobility Option is set to TBD1 Redirect Mobility Option is set to TBD2 This document defines the following new Status values for use in PBA messages. The values are to be allocated from the same number space, as defined in Section 6.1.8 of [RFC3775]. The value below MUST be less than 128 indicating that the PBU was accepted by the LMA: Accepted_and_Redirected_with_Binding is set to TBD3 The value below MUST be greater than 128 indicating that the PBU was rejected by the LMA: Rejected_but_Redirected is set to TBD4 Korhonen, et al. Expires April 2, 2011 [Page 19] Internet-Draft Runtime LMA Assignment September 2010 10. Acknowledgements The author would like to thank Basavaraj Patil, Domagoj Premec, Ahmad Muhanna, Vijay Devarapalli and Qin Wu for their reviews and comments on this document. The authors also thank Yungui Wang for his comments and discussion on this document. Korhonen, et al. Expires April 2, 2011 [Page 20] Internet-Draft Runtime LMA Assignment September 2010 11. References 11.1. Normative References [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. [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 11.2. Informative References [I-D.ietf-netlmm-lma-discovery] Korhonen, J. and V. Devarapalli, "LMA Discovery for Proxy Mobile IPv6", draft-ietf-netlmm-lma-discovery-06 (work in progress), September 2010. [RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136, April 1997. [RFC3484] Draves, R., "Default Address Selection for Internet Protocol version 6 (IPv6)", RFC 3484, February 2003. [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006. [RFC5142] Haley, B., Devarapalli, V., Deng, H., and J. Kempf, "Mobility Header Home Agent Switch Message", RFC 5142, January 2008. [RFC5779] Korhonen, J., Bournelle, J., Chowdhury, K., Muhanna, A., and U. Meyer, "Diameter Proxy Mobile IPv6: Mobile Access Gateway and Local Mobility Anchor Interaction with Diameter Server", RFC 5779, February 2010. [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 5996, September 2010. Korhonen, et al. Expires April 2, 2011 [Page 21] Internet-Draft Runtime LMA Assignment September 2010 Authors' Addresses Jouni Korhonen (editor) Nokia Siemens Networks Linnoitustie 6 FI-02600 Espoo FINLAND Email: jouni.nospam@gmail.com Sri Gundavelli Cisco 170 West Tasman Drive San Jose, CA 95134 USA Email: sri.gundavelli@cisco.com Hidetoshi Yokota KDDI Lab 2-1-15 Ohara, Fujimino Saitama, 356-8502 Japan Email: yokota@kddilabs.jp Xiangsong Cui Huawei Technologies KuiKe Bld., No.9 Xinxi Rd. Shang-Di Information Industry Base Hai-Dian District, Beijing, P.R. China, 100085 Email: Xiangsong.Cui@huawei.com Korhonen, et al. Expires April 2, 2011 [Page 22]