diff options
Diffstat (limited to 'doc/rfc/rfc6463.txt')
| -rw-r--r-- | doc/rfc/rfc6463.txt | 1235 |
1 files changed, 1235 insertions, 0 deletions
diff --git a/doc/rfc/rfc6463.txt b/doc/rfc/rfc6463.txt new file mode 100644 index 0000000..0911762 --- /dev/null +++ b/doc/rfc/rfc6463.txt @@ -0,0 +1,1235 @@ + + + + + + +Internet Engineering Task Force (IETF) J. Korhonen, Ed. +Request for Comments: 6463 Nokia Siemens Networks +Category: Standards Track S. Gundavelli +ISSN: 2070-1721 Cisco + H. Yokota + KDDI Lab + X. Cui + Huawei Technologies + February 2012 + + + Runtime Local Mobility Anchor (LMA) Assignment Support + for Proxy Mobile IPv6 + +Abstract + + This document describes a runtime local mobility anchor assignment + functionality and corresponding mobility options for Proxy Mobile + IPv6. The runtime local mobility anchor assignment takes place + during a Proxy Binding Update and a Proxy Binding Acknowledgement + message exchange between a mobile access gateway and a local mobility + anchor. The runtime local mobility anchor assignment functionality + defined in this specification can be used, for example, for load- + balancing purposes. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc6463. + + + + + + + + + + + + + +Korhonen, et al. Standards Track [Page 1] + +RFC 6463 Runtime LMA Assignment February 2012 + + +Copyright Notice + + Copyright (c) 2012 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 + 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 . . . . . . . . . . . . . . . . . 4 + 2.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 4 + 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 + 3. Proxy Mobile IPv6 Domain Assumptions . . . . . . . . . . . . . 5 + 4. Mobility Options . . . . . . . . . . . . . . . . . . . . . . . 5 + 4.1. Redirect-Capability Mobility Option . . . . . . . . . . . 5 + 4.2. Redirect Mobility Option . . . . . . . . . . . . . . . . . 6 + 4.3. Load Information Mobility Option . . . . . . . . . . . . . 7 + 4.4. Alternate IPv4 Care-of Address Mobility Option . . . . . . 9 + 5. Runtime LMA Assignment . . . . . . . . . . . . . . . . . . . . 9 + 5.1. General Operation . . . . . . . . . . . . . . . . . . . . 9 + 5.2. Mobile Access Gateway Operation . . . . . . . . . . . . . 10 + 5.3. Local Mobility Anchor Operation . . . . . . . . . . . . . 12 + 5.3.1. Co-Located rfLMA and r2LMA Functions . . . . . . . . . 13 + 5.3.2. Separate rfLMA and r2LMA Functions (Proxy-MAG) . . . . 14 + 6. Handoff and Multi-Homing Considerations . . . . . . . . . . . 18 + 7. Protocol Configuration Variables . . . . . . . . . . . . . . . 18 + 8. Security Considerations . . . . . . . . . . . . . . . . . . . 19 + 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 + 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20 + 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 + 11.1. Normative References . . . . . . . . . . . . . . . . . . . 20 + 11.2. Informative References . . . . . . . . . . . . . . . . . . 20 + + + + + + + + + + +Korhonen, et al. Standards Track [Page 2] + +RFC 6463 Runtime LMA Assignment February 2012 + + +1. Introduction + + This specification describes a runtime assignment of a local mobility + anchor (LMA) for the Proxy Mobile IPv6 (PMIPv6) [RFC5213] protocol. + The runtime LMA assignment takes place during a Proxy Binding Update + (PBU) and a Proxy Binding Acknowledgement (PBA) message 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. MAGs and LMAs can also + implement other load-balancing mechanisms that are completely + transparent at the PMIPv6 protocol level and do not depend on the + functionality defined in this specification. + + The runtime LMA assignment functionality does not depend on the + Domain Name System (DNS) or the Authentication, Authorization, and + Accounting (AAA) infrastructure for the assignment of the LMA to + which the mobile node (MN) is anchored. All MAGs and LMAs (either + rfLMAs or r2LMAs; see Section 2.2) have to belong to the same PMIPv6 + domain. + + There are a number of reasons why the runtime LMA assignment is a + useful addition to the PMIPv6 protocol. A few are identified below: + + 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 the LMAs as the serving LMA using, for example, 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 a + [RFC5142]-based approach, but that would imply unnecessary setting + up of a mobility session in a "wrong LMA" with associated back-end + support system interactions, additional signaling between the MAG + and the LMA, and re-establishing a 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 thus hiding possible + individual LMA or LMA blade IP addresses from the MAG. However, + if all traffic must always go through the load-balancer, it + quickly becomes 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. + + + +Korhonen, et al. Standards Track [Page 3] + +RFC 6463 Runtime LMA Assignment February 2012 + + + o Independence from DNS: DNS-based load-balancing is a common + practice. However, keeping MAGs up to date with LMA load status + using DNS is hard, e.g., due to caching and unpredictable zone + update delays [RFC6097]. Generally, LMAs constantly updating the + [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 perform + (LMA) destination address selection decisions that are not in line + with 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, it returns 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 have a unique unicast IP address for + each blade and a single anycast address for all blades. 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 runtime-assigned LMA blade through the + initial PBU/PBA exchange, the subsequent communication continues + using the unicast address. + + As a summary, the DNS/AAA-based approaches cannot be used to select + an "appropriate" LMA at runtime. Therefore, this specification + defines a solution that is applicable for LMA implementations where + the IP address known to the MAG is not the best LMA of choice at + runtime. + +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: + + + + + +Korhonen, et al. Standards Track [Page 4] + +RFC 6463 Runtime LMA Assignment February 2012 + + + rfLMA + + An LMA that 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 consists of at least one rfLMA and one or + more r2LMAs (all are part of the same PMIPv6 domain). 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. + +3. Proxy Mobile IPv6 Domain Assumptions + + The runtime LMA assignment functionality has few assumptions within + the PMIPv6 domain. + + Each LMA in a runtime assignment domain MUST be reachable at a + 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. + + Each LMA and MAG participating in the runtime LMA assignment is + assumed to have required Security Associations (SAs) pre-established. + Dynamic negotiation of the SAs using, e.g., IKEv2 [RFC5996], SHOULD + be supported but is out of scope of this specification. + +4. Mobility Options + + In the following sections, all presented values, bit fields, and + addresses are in network byte order. + +4.1. Redirect-Capability Mobility Option + + The Redirect-Capability mobility option has the alignment requirement + of 4n. There can be zero or one Redirect-Capability mobility option + in the PBU. The format of the Redirect-Capability mobility option is + shown below: + + + + +Korhonen, et al. Standards Track [Page 5] + +RFC 6463 Runtime LMA Assignment February 2012 + + + 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 | Reserved | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Redirect-Capability Mobility Option + + o Option Type: 8-bit identifier set to 46. + + 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 Reserved: This field is reserved for future use. This field MUST + be set to zero by the sender and ignored by the receiver. + + The Redirect-Capability option is used by the MAG to inform the LMA + that it implements and has enabled the runtime LMA assignment + functionality. + +4.2. Redirect Mobility Option + + The Redirect mobility option in the PBA MUST contain an unicast + address of the r2LMA and the address family MUST be the same as the + currently used transport between the MAG and the rfLMA. There can be + zero or one Redirect mobility option in the PBA. The Redirect + mobility option has the alignment requirement of 4n. 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 47. + + + + +Korhonen, et al. Standards Track [Page 6] + +RFC 6463 Runtime LMA Assignment February 2012 + + + 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 the 'K' flag is set and 'N' is unset, then + the length MUST be 18. If the 'K' flag is unset and 'N' is set, + then the length MUST be 6. Both the 'K' and 'N' flags cannot be + set or unset simultaneously. + + 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 by the sender and ignored by the receiver. + + o Optional IPv6 r2LMA Address: the unicast IPv6 address of the + r2LMA. This value is present when the corresponding PBU was + sourced from an IPv6 address. + + o Optional IPv4 r2LMA Address: the IPv4 address of the r2LMA. This + value is present when the corresponding PBU was sourced from an + IPv4 address (for IPv4 transport, see [RFC5844]). + + The Redirect option is used by the LMA to inform the MAG that the + runtime LMA assignment took place and the MAG has to update its + Binding Update List Entry (BULE) for the mobility session. + +4.3. Load Information Mobility Option + + The Load Information mobility option can be included in any PBA and + is used to report priority and key load information of a LMA to a MAG + (or to a 'proxy-MAG'). The Load Information mobility option has the + alignment requirement of 4n. The format of the mobility option is + shown below: + + + + + + + + + + + + + + +Korhonen, et al. Standards Track [Page 7] + +RFC 6463 Runtime LMA Assignment February 2012 + + + 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 | Priority | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Sessions in Use | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Maximum Sessions | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Used Capacity | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Maximum Capacity | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Load Information Mobility Option + + o Option Type: 8-bit identifier set to 48. + + o Option Length: 8-bit unsigned integer, representing the length of + the Load Information mobility option in octets, excluding the + Option Type and Length fields. The length is set to 18. + + o Priority: 16-bit unsigned integer, representing the priority of an + LMA. The lower value, the higher the priority. The priority only + has meaning among a group of LMAs under the same administration, + for example, determined by a common LMA FQDN, a domain name, or a + realm. + + o Sessions in Use: 32-bit unsigned integer, representing the number + of parallel mobility sessions the LMA has in use. + + o Maximum Sessions: 32-bit unsigned integer, representing the + maximum number of parallel mobility sessions the LMA is willing to + accept. + + o Used Capacity: 32-bit unsigned integer, representing the used + bandwidth/throughput capacity of the LMA in kilobytes per second. + + o Maximum Capacity: 32-bit unsigned integer, representing the + maximum bandwidth/throughput capacity in kilobytes per second the + LMA is willing to accept. + + The session and capacity information can easily be used to calculate + different load factors of the LMA. A MAG (or a 'proxy-MAG') MAY use + the priority and load information to internally maintain priority + ordering of LMAs. + + + + + +Korhonen, et al. Standards Track [Page 8] + +RFC 6463 Runtime LMA Assignment February 2012 + + +4.4. Alternate IPv4 Care-of Address Mobility Option + + The Alternate IPv4 Care-of Address (A4CoA) mobility option has the + alignment requirement of 4n+2. The format of the 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 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Alternate IPv4 Care-of Address | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Alternate IPv4 Care-of Address Mobility Option + + o Option Type: 8-bit identifier set to 49. + + o Option Length: 8-bit unsigned integer, representing the length of + the Load Information mobility option in octets, excluding the + Option Type and Length fields. The length is set to 4. + + o Alternate IPv4 Care-of Address: an IPv4 equivalent of the + [RFC6275] Alternate Care-of Address option for IPv6. In the + context of PMIPv6, its semantic is equivalent to the Alternate + Care-of Address option for IPv6. + + A MAG MAY include the Alternate IPv4 Care-of Address option in a PBU. + An LMA that receives and implements the Alternate IPv4 Care-of + Address option MUST echo the option as such back to the MAG in a + reply PBA. + +5. Runtime LMA Assignment + +5.1. General Operation + + During the runtime LMA assignment, the PBA is returned from the LMA + Address to which the PBU was sent, i.e., from the rfLMA address. + After the runtime LMA assignment, all PMIPv6 communication continues + directly between the MAG and the r2LMA bypassing the rfLMA. The + overall runtime LMA assignment flow sequence is shown in Figure 1. + + + + + + + + + + +Korhonen, et al. Standards Track [Page 9] + +RFC 6463 Runtime LMA Assignment February 2012 + + + [MAG] [rfLMA] [r2LMA] + | | | + 1) |--PBU-->| | LMA assignment takes place in rfLMA. + | | | + 2) | | ~ ~ ~ >|\ + | | | + BCE gets created in r2LMA. + 3) | |<~ ~ ~ ~|/ + | | | + 4) |<--PBA--| | PBA contains r2LMA information. + | | | + |<=====data======>| + | | | + 5) |-------PBU------>| Lifetime extension, + 6) |<------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. There are several + possible solutions for the rfLMA and the r2LMA interaction depending + on, e.g., the co-location properties of the rfLMA and the r2LMA. + This specification describes two: + + o Co-located rfLMA and r2LMA functions, where the 'rfLMA side of the + LMA' is reachable via an anycast address or the loopback address + of the LMA. See Section 5.3.1 for further details. + + o Separate rfLMA and r2LMA functions, where the rfLMA acts as a non- + transparent 'proxy-MAG' to a r2LMA. See Section 5.3.2 for further + details. + + There are other possible implementations of the rfLMA and the r2LMA. + At the end, as long as the protocol between the MAG and the rfLMA + follows this specification , the co-location or inter-communication + properties of the rfLMA and the r2LMA do not matter. + +5.2. Mobile Access Gateway Operation + + In the base PMIPv6 protocol [RFC5213], a MAG sends a PBU to an LMA; + this results in creation of a Binding Cache Entry (BCE) at the LMA + and the LMA sending a PBA sent back to the MAG. The MAG in turn + creates a corresponding Binding Update List Entry (BULE). This + specification extends the base protocol with the runtime LMA + assignment functionality. + + + + +Korhonen, et al. Standards Track [Page 10] + +RFC 6463 Runtime LMA Assignment February 2012 + + + If the MAG supports the runtime LMA assignment and the functionality + is also enabled (see the EnableLMARedirectFunction configuration + variable in Section 7), then the MAG includes the Redirect-Capability + mobility option in a PBU that establishes a new mobility session + (i.e., Handoff Indicator Option in the PBU has the value of 1). 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 a + 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 ignore the option and + process the PBA as described in RFC 5213. + + If the MAG receives a PBA that contains the Redirect mobility option + 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 [RFC5213] PBA processing: + + o The MAG updates its BULE to contain the r2LMA address included in + the received Redirect mobility option. + + o If there is no SA between the MAG and the r2LMA, the MAG SHOULD + initiate a dynamic creation of the SA between the MAG and the + r2LMA as described in Section 4 of RFC 5213. If the dynamic SA + creation fails, the MAG SHOULD log the event. The MAG MAY retry + the dynamic creation of the SA, and if those also fail, the newly + created BULE (and also the BUL in the r2LMA) will eventually + timeout. If the failure is persistent, it can be regarded as a + system-level configuration error. + + The MAG is not required to send a fresh PBU to the r2LMA after a + successful runtime assignment. The mobility session has already been + established in the r2LMA. The MAG MUST send all user traffic to the + r2LMA address. The MAG MUST send subsequent binding refresh PBUs + (e.g., lifetime extension, handoff, etc.) to the r2LMA address. If + there is no existing tunnel between the MAG and the r2LMA unicast + address, then the MAG creates one as described in Section 6.9.1.2 of + [RFC5213]. + + + + + + + + + + +Korhonen, et al. Standards Track [Page 11] + +RFC 6463 Runtime LMA Assignment February 2012 + + +5.3. Local Mobility Anchor Operation + + The text in the following sections refers to an '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 (see the + EnableLMARedirectFunction configuration variable in Section 7) in the + rfLMA but the LMA assignment is not going to take place for some + reason, and the rfLMA is not willing to serve (or not capable of + serving) as a normal [RFC5213] 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. If the rfLMA is able to make + the assignment to an r2LMA, it returns a PBA with the Redirect + mobility option as defined below. Otherwise, the rfLMA MUST act as a + normal [RFC5213]- or [RFC5844]-defined LMA for the MAG. + + The rfLMA MUST only assign the MAG to a new r2LMA with which it knows + the MAG has an SA or with which it knows the MAG can establish an SA + 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 + 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 + change the used transport IP address family during the runtime LMA + assignment. + + As a result of a successful runtime LMA assignment, the PBA MUST + contain the Redirect mobility option with a valid r2LMA unicast + address and the PBA Status Value indicating success. + + Next, we describe two deployment and implementation models for the + runtime LMA assignment. In Section 5.3.1, we describe a model where + the rfLMA and r2LMA are co-located. In Section 5.3.2 we describe a + model where the rfLMA acts as a non-transparent 'proxy-MAG', and + where the rfLMA and the r2LMA are separate. There can be even more + implementation options depending on the rfLMA and the r2LMA + co-location properties, and how the inter-LMA communication is + arranged. + + + + + + + +Korhonen, et al. Standards Track [Page 12] + +RFC 6463 Runtime LMA Assignment February 2012 + + +5.3.1. Co-Located rfLMA and r2LMA Functions + + In this solution approach, the rfLMA and the r2LMA are part of the + same 'co-located LMA', and may even be using the same physical + network interface. The rfLMA is reachable via an anycast or a + loopback address of the LMA. Each r2LMA is reachable via its unicast + address. Figure 2 illustrates example signaling flows for the + solution. + + The MAG-LMA SA is between the MAG and the rfLMA (i.e., the anycast or + the loopback address of the LMA). How this SA has been set up is out + of scope of this specification, but a manual SA configuration is one + possibility. + + The rfLMA becomes active when the runtime LMA assignment + functionality is enabled (see the EnableLMARedirectFunction + configuration variable in Section 7). When the rfLMA receives a PBU + destined to it, and the PBU contains the Redirect-Capability mobility + option, then the 'co-located LMA' MUST create a mobility session in a + r2LMA role using the procedures described in [RFC5213]. If there is + no existing tunnel between the MAG and the r2LMA unicast address, + then the r2LMA creates one as described in Section 5.3 of [RFC5213]. + The r2LMA used for accepting and anchoring the mobility session MUST + also have the runtime LMA assignment functionality enabled (see the + EnableLMARedirectAcceptFunction configuration variable in Section 7). + + If the mobility session creation succeeded, then the 'co-located LMA' + in the rfLMA role sends a PBA to the MAG. The PBA is sourced using + the rfLMA (anycast or loopback) address. The PBA MUST contain the + r2LMA unicast address (IPv6 or IPv4) in the Redirect mobility option. + + If the PBU is received on the r2LMA unicast address, then the PBU is + processed as described in RFC 5213 and the response PBA MUST NOT + contain the Redirect mobility option. + + If the PBU is received on the rfLMA address and there is no Redirect- + Capability mobility option in the PBU, then the 'co-located LMA' MAY + choose to be a LMA for the MAG (assuming the rfLMA address is not an + anycast address). Otherwise, the rfLMA MUST reject the PBU and send + back a PBA in a rfLMA role with Status Value set to 130 (Insufficient + resources) error code (as mentioned in Section 5.3). + + + + + + + + + + +Korhonen, et al. Standards Track [Page 13] + +RFC 6463 Runtime LMA Assignment February 2012 + + + [MAG] [rfLMA /r2LMA_1/r2LMA_2/r2LMA_3] + | | | | | + MAG discovers rfLMA | | | | + BULE for rfLMA | | | | + | | | | | + |-- PBU --------------------->| | | | + | src=MAG_Proxy-CoA, | | | | + | dst=rfLMA, | | | | + | Redirect-Capability, .. | r2LMA gets selected | + | BCE is created in r2LMA_2 + | |Tunnel setup in r2LMA_2| + | | | | | + |<- PBA ----------------------| | | | + | src=rfLMA, | | | | + | dst=MAG_Proxy-CoA, | | | | + | Redirect=r2LMA_2_address, | | | | + | Load Info, .. | | | | + | | | | | + BULE updated to r2LMA_2 | | | | + Tunnel setup | | | | + | | | | | + |<=========== MAG-r2LMA_2 tunnel ============>| | + | | | | | + Lifetime extension, etc. | | | | + | | | | | + |-- PBU ------------------------------------->| | + | src=MAG_Proxy-CoA, | | | | + | dst=r2LMA_2, .. | | | | + | | | | | + |<- PBA --------------------------------------| | + | src=r2LMA_2, | | | | + | dst=MAG_Proxy-CoA, | | | | + | Load Info, .. | | | | + | | | | | + + Figure 2: Co-Located rfLMA and r2LMA Example + +5.3.2. Separate rfLMA and r2LMA Functions (Proxy-MAG) + + In this solution approach, the rfLMA and the r2LMA are two isolated + functions, and may even be physically separate networking nodes. The + r2LMA can be any [RFC5213]- or [RFC5844]-compliant LMA that doesn't + have any knowledge of this specification when IPv6 transport is used. + In case of IPv4 transport, the [RFC5844]-compliant LMA MUST also + implement the Alternate IPv4 Care-of Address option (see + Section 4.4). Figure 3 illustrates example signaling flows for the + solution. + + + + +Korhonen, et al. Standards Track [Page 14] + +RFC 6463 Runtime LMA Assignment February 2012 + + + The rfLMA is actually a non-transparent 'proxy-MAG' that shows up as + an LMA implementing this specification towards the MAG, and as a base + [RFC5213]-compliant MAG to the r2LMA. (See [RFC2616] for a generic + definition of a non-transparent proxy; although it's for HTTP, the + idea also applies here.) This type of operation is also referred to + as 'chaining' in other contexts. The protocol between the 'proxy- + MAG' and the r2LMA is the base [RFC5213] PMIPv6 protocol. + + The MAG-LMA SA is between the MAG and the rfLMA, and [RFC5213] SA + considerations apply fully. The MAG has no knowledge of the 'proxy- + MAG'-r2LMA SA. [RFC5213] considerations regarding the SA between the + 'proxy-MAG' and the r2LMA apply fully. It is also possible that + 'proxy-MAG'-r2LMA security is arranged using other means than IPsec, + for example, using layer-2 VPNs. + + When the rfLMA receives a PBU, and the PBU contains the Redirect- + Capability mobility option, then the rfLMA in a 'proxy-MAG' role: + + o Processes the PBU using the procedures described in RFC 5213 + except that no mobility session gets created. Instead, the rfLMA + creates a proxy state based on the received PBU. + + o Assigns a r2LMA to the MAG. + + o Creates a new PBU', which includes all non-security related + mobility options from the original PBU and an Alternate Care-of + Address (ACoA) option containing the Proxy Care-of Address of the + original MAG. If the original PBU already included an ACoA + option, then the content of the ACoA option in the PBU' MUST be + the same as in the original PBU. + + Note, in case of IPv4 transport [RFC5844], the Alternate IPv4 + Care-of Address (A4CoA) option MUST be used and contain the IPv4 + Proxy Care-of Address of the original MAG. + + o Sends the new PBU' sourced from its 'proxy-MAG' IPv6 or IPv4 Proxy + Care-of Address and destined to the r2LMA address using the + procedures described in RFC 5213 (or RFC 5844 in case of IPv4 + transport). + + The r2LMA processes the received PBU' using the procedures described + in RFC 5213 or RFC 5844. In case of IPv4 transport, the r2LMA uses + the IPv4 Proxy Care-of Address from the Alternate IPv4 Care-of + Address option for the tunnel setup and the creation of the BCE. The + reply PBA' MUST be destined to the source address of the received + PBU', i.e., the Care-of Address the 'proxy-MAG'. + + + + + +Korhonen, et al. Standards Track [Page 15] + +RFC 6463 Runtime LMA Assignment February 2012 + + + Once the rfLMA in a 'proxy-MAG' role receives a reply PBA' from the + r2LMA and the mobility session creation succeeded in the r2LMA, the + rfLMA sends a PBA to the original MAG. The PBA is sourced from the + rfLMA address and destined to the MAG (IPv6 or IPv4) Proxy Care-of + Address. The PBA MUST contain the r2LMA (IPv6 or IPv4) unicast + address in the Redirect mobility option. Other non-security-related + mobility options (including the Load Information option) are copied + from the PBA' to the PBA as such. + + If one of these errors occurs: + + o the PBA' Status Value indicates that the mobility session creation + failed in the r2LMA. For example, the Status Value in the PBA' is + set to 130 (Insufficient resources), or + + o there was no PBA' response from the r2LMA, or + + o the PBA' did not include the Alternate IPv4 Care-of Address option + although it was included in the corresponding PBU' (when using + IPv4 transport), + + then the rfLMA SHOULD assign the MAG to a new r2LMA and rerun the + procedure for sending the PBU' described earlier for the new r2LMA. + The number and order of r2LMA reassignment attempts is controlled by + the local policy and the amount of known r2LMAs in the rfLMA. When + the rfLMA in a 'proxy-MAG' role concludes the mobility session + creation failed with r2LMA(s), the rfLMA MUST set the Status Value in + the PBA as received from the latest contacted PBA' Status Value or to + 130 (Insufficient resources) in case of no responses from rfLMAs, and + send the reply PBA to the MAG. The PBA is sourced from the rfLMA + address and destined to the MAG Proxy Care-of Address. Other + possible non-security-related mobility options (including the Load + Information option) are copied from the PBA' to the PBA as such. + + Once the rfLMA has sent the reply PBA to the MAG, it can remove the + proxy state. Subsequent traffic between the MAG and the r2LMA will + bypass the rfLMA (assuming the mobility session creation succeeded in + the r2LMA). + + If the rfLMA receives a PBU with no Redirect-Capability mobility + option in the PBU, then the PBU is processed as described in + Section 5.3, i.e., the rfLMA may or may not act as an [RFC5213] or + [RFC5844] LMA to the MAG. + + + + + + + + +Korhonen, et al. Standards Track [Page 16] + +RFC 6463 Runtime LMA Assignment February 2012 + + + [MAG] [rfLMA] [r2LMA] + | | | + MAG discovers rfLMA | | + BULE for rfLMA | | + | | | + |-- PBU --------------------->| rfLMA assigns a r2LMA and | + | src=MAG_Proxy-CoA, | creates a proxy state | + | dst=rfLMA, | | + | Redirect-Capability, .. | | + | |-- PBU' -------------------->| + | | src=proxy-MAG_Proxy-CoA, | + | | dst=r2LMA, | + | | ACoA/A4CoA=MAG_Proxy-CoA, | + | | .. | + | | BCE created in r2LMA + | | Tunnel setup + | | Proxy-CoA is MAG's address + | | | + | rfLMA removes the |<- PBA' ---------------------| + | proxy state | src=r2LMA, | + | | dst=proxy-MAG_Proxy-CoA, | + | | Load Info, .. | + |<- PBA ----------------------| | + | src=rfLMA, | | + | dst=MAG_Proxy-CoA, | | + | Redirect=r2LMA_address, | | + | Load Info, .. | | + | | | + BULE updated to r2LMA | | + Tunnel setup | | + | | | + |<===================== MAG-r2LMA tunnel ==================>| + | | | + Lifetime extension, etc. | | + | | | + |-- PBU --------------------------------------------------->| + | src=MAG_Proxy-CoA, dst=r2LMA, .. | + | | | + |<- PBA ----------------------------------------------------| + | src=r2LMA, dst=MAG_Proxy-CoA, Load Info, .. | + | | | + + Figure 3: Separate rfLMA and r2LMA ('proxy-MAG') Example + + + + + + + + +Korhonen, et al. Standards Track [Page 17] + +RFC 6463 Runtime LMA Assignment February 2012 + + +6. Handoff and Multi-Homing Considerations + + A MN can be multi-homed, i.e., have network connectivity over + multiple interfaces connected to one or more accesses. If PMIPv6- + based handovers between multiple interfaces or accesses are desired, + then a single LMA should have a control over all possible multi-homed + mobility sessions the MN has. Once the MN has established one + mobility session with one LMA, the subsequent mobility sessions of + the same MN would be anchored to the LMA that was initially assigned. + If each mobility session over a different interface (and possibly a + MAG) has no requirements for PMIPv6-based handovers between accesses + or interfaces, then the rest of the considerations in this section do + not apply. + + 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. Ensuring the discovery of the same + r2LMA each time relies on the MN having an identity that can always + point to the same policy profile, independent of the access that is + used. + + 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. + +7. Protocol Configuration Variables + + This specification defines two 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). + + + + + +Korhonen, et al. Standards Track [Page 18] + +RFC 6463 Runtime LMA Assignment February 2012 + + + 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). + + Note that the MAG and LMA configuration variables from Sections 9.1 + and 9.2 of [RFC5213] do not apply for an LMA when it is in an rfLMA + role. + +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 an 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 in runtime LMA assignment have adequate prior agreement + and trust relationships between each other. + + If the SAs between MAGs and LMAs are manually keyed (as may be needed + by the scenario described in Section 5), 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 an adequate level of + security using other means, such as layer-2 VPNs. + + + + + + + + + + + +Korhonen, et al. Standards Track [Page 19] + +RFC 6463 Runtime LMA Assignment February 2012 + + +9. IANA Considerations + + New mobility options for use with PMIPv6 are defined in the [RFC6275] + "Mobility Options" registry. The mobility options are defined in + Section 4: + + Redirect-Capability Mobility Option 46 + Redirect Mobility Option 47 + Load Information Mobility Option 48 + Alternate IPv4 Care-of Address 49 + +10. Acknowledgements + + The author would like to thank Basavaraj Patil, Domagoj Premec, Ahmad + Muhanna, Vijay Devarapalli, Rajeev Koodli, Yungui Wang, Pete McCann, + and Qin Wu for their discussion of this document. A special thanks + to Qian Li for her detailed feedback on the protocol details. + +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. + + [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., + and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. + + [RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support + in IPv6", RFC 6275, July 2011. + +11.2. Informative References + + [RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, + "Dynamic Updates in the Domain Name System (DNS UPDATE)", + RFC 2136, April 1997. + + [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., + Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext + Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. + + [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. + + + + + +Korhonen, et al. Standards Track [Page 20] + +RFC 6463 Runtime LMA Assignment February 2012 + + + [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. + + [RFC5844] Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy + Mobile IPv6", RFC 5844, May 2010. + + [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, + "Internet Key Exchange Protocol Version 2 (IKEv2)", + RFC 5996, September 2010. + + [RFC6097] Korhonen, J. and V. Devarapalli, "Local Mobility Anchor + (LMA) Discovery for Proxy Mobile IPv6", RFC 6097, + February 2011. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Korhonen, et al. Standards Track [Page 21] + +RFC 6463 Runtime LMA Assignment February 2012 + + +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: sgundave@cisco.com + + + Hidetoshi Yokota + KDDI Lab + 2-1-15 Ohara, Fujimino + Saitama 356-8502 + Japan + + EMail: yokota@kddilabs.jp + + + Xiangsong Cui + Huawei Technologies + Huawei Building, No. 156 Beiqing Rd. + Z-park, Shi-Chuang-Ke-Ji-Shi-Fan-Yuan + Hai-Dian District, Beijing 100095 + P.R. China + + EMail: Xiangsong.Cui@huawei.com + + + + + + + + + + + + + + +Korhonen, et al. Standards Track [Page 22] + |