RFC 6463
Runtime Local Mobility Anchor (LMA) Assignment Support for Proxy Mobile IPv6
RFC 6463: Runtime Local Mobility Anchor (LMA) Assignment Support for Proxy Mobile IPv6 ✨
Heyy bestie, let's look at the title block first 🎀
- Authors: J. Korhonen, Ed. (Nokia Siemens Networks), S. Gundavelli (Cisco), H. Yokota (KDDI Lab), and X. Cui (Huawei Technologies) 👑
- Category: Standards Track 🦋
- ISSN: 2070-1721
- Date: February 2012 📅
- Obsoletes/Updates: this title block doesn't list any RFCs as obsoleted or updated 🌸
- Series: IETF, which is the Internet Engineering Task Force 🌈
Abstract 🧚
okay so this doc is all about a runtime local mobility anchor assignment feature and some matching mobility options for Proxy Mobile IPv6 💖 basically, the assignment happens during a Proxy Binding Update and Proxy Binding Acknowledgement message exchange between a mobile access gateway and a local mobility anchor. And it can be used, for example, for load-balancing purposes. literally so useful 😭
Status of This Memo 💅
ngl this section is just the boring formal stuff, but it matters 🙈
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.
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 . . . . . . . . . . . . . . . . . . 201. Introduction ✨
okay bestie, so this spec describes a runtime assignment of a local mobility anchor (LMA) for the Proxy Mobile IPv6 (PMIPv6) [RFC5213] protocol 🦋 The runtime LMA assignment happens during a Proxy Binding Update (PBU) and a Proxy Binding Acknowledgement (PBA) message exchange between a mobile access gateway (MAG) and an LMA. Again, it can be used, for example, for load-balancing purposes. MAGs and LMAs can also use other load-balancing mechanisms that are totally transparent at the PMIPv6 protocol level and don't depend on the functionality defined here 💅
The runtime LMA assignment functionality doesn't depend on the Domain Name System (DNS) or the Authentication, Authorization, and Accounting (AAA) infrastructure when it picks the LMA that the mobile node (MN) is anchored to 🌸 All MAGs and LMAs (either rfLMAs or r2LMAs; see Section 2.2) have to belong to the same PMIPv6 domain. no exceptions, periodt 💀
There are a bunch of reasons why runtime LMA assignment is such a useful addition to PMIPv6. A few of them:
- LMAs with multiple IP addresses: a cluster of LMAs, or a blade architecture LMA, may look to the routing system like multiple LMAs with separate unicast IP addresses. A MAG can start by picking any of the LMAs as the serving LMA, using things like DNS- and AAA-based solutions. But the MAG's initial pick might be suboptimal from the LMA's point of view, so an immediate runtime assignment to a "proper LMA" would be needed 😭 The LMA could use a [RFC5142]-based approach, but that would mean setting up a mobility session in a "wrong LMA" for no reason, with the associated back-end support system interactions, extra signaling between the MAG and the LMA, and then re-establishing a mobility session with the new LMA, with more signaling on top of that. ugh, so much waste 🙃
- Bypassing a load-balancer: a cluster of LMAs, or a blade architecture LMA, may have a load-balancer in front of them or built into one of the LMAs. The load-balancer would stand in for multiple LMAs during the LMA discovery phase, and only its IP address would be exposed to the MAG, which hides any individual LMA or LMA blade IP addresses from the MAG 🧚 But if all traffic has to go through the load-balancer, it quickly becomes a bottleneck. So 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 lets you build load-balancers that don't keep any MN-specific state information. big brain move 🧠
- Independence from DNS: DNS-based load-balancing is a super common practice. However, keeping MAGs up to date with LMA load status using DNS is hard, e.g., because of caching and unpredictable zone update delays [RFC6097]. Generally, LMAs constantly updating the [RFC2136] zone's master DNS server might not be feasible in a large PMIPv6 domain, due to increased load on the master DNS server and extra background signaling 🥲 Also, MAGs may make (LMA) destination address selection decisions that don't line up with what the DNS administrator actually wanted [RFC3484]. not it 🙅♀️
- Independence from AAA: AAA-based solutions have basically the same arguments as the DNS-based solutions above. It's also typical for AAA-based solutions to hand off the initial LMA selection to the DNS infrastructure [RFC5779]. The AAA infrastructure doesn't return an IP address or a Fully Qualified domain Name (FQDN) to a single LMA. Instead, it returns an FQDN representing a group of LMAs 🎀
- Support for IPv6 anycast addressing [RFC4291]: the current PMIPv6 specification doesn't say 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 one anycast address for all the blades. A MAG could then send a PBU to an anycast LMA address and receive a PBA from an anycast LMA address 🦋 Once the MAG gets the unicast address of the runtime-assigned LMA blade through the initial PBU/PBA exchange, the rest of the communication keeps using that unicast address. ✨
So, tl;dr: DNS/AAA-based approaches can't be used to select an "appropriate" LMA at runtime. That's why this spec defines a solution for LMA implementations where the IP address the MAG knows 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
Along with the terminology defined in [RFC5213], this doc also uses the following terms:
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). An 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. Honestly, very chill 😌
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. ✨ so yeah, the SAs should be pre-set up, and dynamic IKEv2 negotiation is a should, but it's not part of this spec 🙈
4. Mobility Options 💅
In the following sections, all presented values, bit fields, and addresses are in network byte order. That means the bytes are laid out in the order they're sent on the wire, so make sure you're reading them the right way round 🧚
Okay, the mobility options are coming up next in Part 2! 🌈✨
4.1. Redirect-Capability Mobility Option 🎀
okay so the Redirect-Capability option has an alignment requirement of 4n 💅. there can be zero or one of these in the PBU ✨. here's what it looks like 🦋
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 OptionOption Type: 8-bit identifier set to 46 🌸Option Length: 8-bit unsigned integer, representing the length of the Redirect-Capability mobility option in octets, excluding theOption TypeandLengthfields. TheOption LengthMUST be set to 2 💖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. that's the whole vibe, bestie 🫶
4.2. Redirect Mobility Option 🌈
so the Redirect mobility option in the PBA MUST contain a 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 ✨. it has an alignment requirement of 4n 💅. here's the format:
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 OptionOption Type: 8-bit identifier set to 47 🍓Option Length: 8-bit unsigned integer, representing the length of the Redirect mobility option in octets, excluding theOption TypeandLengthfields. 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 🙈Kflag: this bit is set (1) if theOptional IPv6 r2LMA Addressis included in the mobility option. Otherwise, the bit is unset (0) 🦋Nflag: this bit is set (1) if theOptional IPv4 r2LMA Addressis included in the mobility option. Otherwise, the bit is unset (0) 🦋Reserved: this field is reserved for future use. MUST be set to zero by the sender and ignored by the receiver 💜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 ✨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. iconic behaviour, no cap 👑
4.3. Load Information Mobility Option 💜
okay so the Load Information mobility option can be included in any PBA 🧚. it's used to report priority and key load information of a LMA to a MAG (or to a 'proxy-MAG') 🔥. it has an alignment requirement of 4n. here's the layout:
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 OptionOption Type: 8-bit identifier set to 48 🎀Option Length: 8-bit unsigned integer, representing the length of the Load Information mobility option in octets, excluding theOption TypeandLengthfields. The length is set to 18 ✨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 👑Sessions in Use: 32-bit unsigned integer, representing the number of parallel mobility sessions the LMA has in use 💅Maximum Sessions: 32-bit unsigned integer, representing the maximum number of parallel mobility sessions the LMA is willing to accept 💖Used Capacity: 32-bit unsigned integer, representing the used bandwidth/throughput capacity of the LMA in kilobytes per second 🌊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 info can easily be used to calculate different load factors of the LMA 🧮. and a MAG (or a 'proxy-MAG') MAY use the priority and load information to internally maintain priority ordering of LMAs. the way that's giving organisation 🫶
4.4. Alternate IPv4 Care-of Address Mobility Option 🦋
so the Alternate IPv4 Care-of Address (A4CoA) option has an alignment requirement of 4n+2 🌸. here's the format:
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 OptionOption Type: 8-bit identifier set to 49 🍓Option Length: 8-bit unsigned integer, representing the length of the Load Information mobility option in octets, excluding theOption TypeandLengthfields. The length is set to 4 💜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. no skipping the echo, bestie 😭
5. Runtime LMA Assignment 👑
5.1. General Operation 🌈
okay so 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 ✨:
[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 signalling 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 💅:
- 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 🧚
- 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 ✨
okay so in the base PMIPv6 protocol [RFC5213], a MAG sends a PBU to an LMA 🫶 That creates a Binding Cache Entry (BCE) at the LMA, and the LMA sends a PBA back to the MAG 💌 The MAG then makes its own Binding Update List Entry (BULE) to match. This spec extends the base protocol with runtime LMA assignment functionality 🔥
If the MAG supports runtime LMA assignment and the feature is turned on (see the EnableLMARedirectFunction configuration variable in Section 7), the MAG includes the Redirect-Capability mobility option in a PBU that starts a brand new mobility session (aka the Handoff Indicator Option in the PBU is set to 1) 🎀 That Redirect-Capability option is also a little signal to the LMA saying "hey, this MAG supports runtime LMA assignment and is ready to be handed off to a different LMA" 💅 Runtime LMA assignment always deals with one mobility session at a time 🦋
If the MAG gets a PBA that has the Redirect mobility option but the MAG never included the Redirect-Capability mobility option in the matching PBU, the MAG MUST ignore that option and process the PBA as described in RFC 5213. Nope, not today 🙈
If the MAG gets a PBA with the Redirect mobility option AND it did include the Redirect-Capability option in the matching PBU, then the MAG MUST do the following steps on top of the normal [RFC5213] PBA processing:
- The MAG updates its BULE so it holds the r2LMA address from the Redirect mobility option it just got 🍓
- If there's no SA between the MAG and the r2LMA, the MAG SHOULD start 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 SA creation. If those retries also fail, the newly created BULE (and also the BUL in the r2LMA) will eventually time out. If the failure keeps happening, it can be treated as a system-level configuration error 💀
The MAG is not required to send a fresh PBU to the r2LMA after a successful runtime assignment, because the mobility session is already set up in the r2LMA 🧚 The MAG MUST send all user traffic to the r2LMA address 💜 It MUST also send any later binding refresh PBUs (like lifetime extension, handoff, etc.) to the r2LMA address 🌸 If there's no existing tunnel between the MAG and the r2LMA unicast address, the MAG creates one as described in Section 6.9.1.2 of [RFC5213] ✨
5.3. Local Mobility Anchor Operation 👑
In the text that follows, "LMA" means the combination of the rfLMA and the r2LMA, aka the entity where runtime LMA assignment is possible. When the text is talking about one specific LMA role during the runtime assignment, it uses either 'rfLMA' or 'r2LMA' 🫶
If runtime assignment is enabled (see the EnableLMARedirectFunction configuration variable in Section 7) in the rfLMA, but the LMA assignment doesn't happen for some reason, AND the rfLMA isn't willing (or able) to serve 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 can assign an r2LMA, it returns a PBA with the Redirect mobility option 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 that it knows the MAG already has an SA with, or one the MAG can dynamically set up an SA with. The rfLMA MUST NOT assign the MAG to an r2LMA that the rfLMA and the r2LMA don't have a prior agreement with and an established trust relationship for runtime LMA assignment 🙅♀️ Those SA-related knowledge issues and trust relationships are deployment specific in a PMIPv6 domain and in a runtime assignment domain, and they're out of scope for this spec 🦋 Any possible context transfer and other coordination between the rfLMA and the r2LMA is also deployment specific for LMAs in a runtime assignment domain 💅 The rfLMA MUST NOT change the transport IP address family it uses during the runtime LMA assignment ✨
After a successful runtime LMA assignment, the PBA MUST contain the Redirect mobility option with a valid r2LMA unicast address, and the PBA Status Value indicates success 🎀
Next up, we look at two deployment and implementation models for runtime LMA assignment. In Section 5.3.1, the rfLMA and r2LMA are co-located. In Section 5.3.2, the rfLMA acts as a non-transparent 'proxy-MAG', and the rfLMA and the r2LMA are separate 🧚 There can be even more implementation options depending on how the rfLMA and the r2LMA are co-located and how the inter-LMA communication is arranged 🌈
5.3.1. Co-Located rfLMA and r2LMA Functions 🏠
In this approach, the rfLMA and the r2LMA are part of the same 'co-located LMA' and might even share the same physical network interface 🫶 The rfLMA is reachable through an anycast or loopback address of the LMA, and each r2LMA is reachable through its unicast address. Figure 2 shows example signaling flows for this solution 💜
The MAG-LMA SA is between the MAG and the rfLMA (aka the anycast or loopback address of the LMA). How this SA gets set up is out of scope for this spec, though a manual SA configuration is one option 🍓
The rfLMA becomes active when runtime LMA assignment is enabled (see the EnableLMARedirectFunction configuration variable in Section 7). When the rfLMA gets a PBU addressed to it, and that PBU has the Redirect-Capability mobility option, then the 'co-located LMA' MUST create a mobility session in an r2LMA role using the procedures in [RFC5213] 🔥 If there's no existing tunnel between the MAG and the r2LMA unicast address, the r2LMA creates one as described in Section 5.3 of [RFC5213]. The r2LMA that accepts and anchors the mobility session MUST also have runtime LMA assignment enabled (see the EnableLMARedirectAcceptFunction configuration variable in Section 7) 💅
If the mobility session creation succeeds, the 'co-located LMA' in the rfLMA role sends a PBA to the MAG. That PBA is sourced from 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, 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's no Redirect-Capability mobility option in it, then the 'co-located LMA' MAY choose to be an 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 an rfLMA role with Status Value set to 130 (Insufficient resources) error code, as mentioned in Section 5.3 💀
Here's the signaling flow from Figure 2, in all its glory 🧚
[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) 🦋
okay bestie, in this solution approach the rfLMA and the r2LMA are two isolated functions 💅 they may even be physically separate networking nodes, which is so main character 🌸 The r2LMA can be any [RFC5213]- or [RFC5844]-compliant LMA that doesn't have any knowledge of this specification when IPv6 transport is used. If you're using IPv4 transport, the [RFC5844]-compliant LMA MUST also implement the Alternate IPv4 Care-of Address option (see Section 4.4). Figure 3 shows example signaling flows for the whole thing ✨
The rfLMA is basically a non-transparent 'proxy-MAG' 🫶 It shows up as an LMA implementing this specification to the MAG, and as a base [RFC5213]-compliant MAG to the r2LMA. (See [RFC2616] for a generic definition of a non-transparent proxy. It's for HTTP, but the idea also applies here.) This type of operation is also called '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's 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:
- 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.
- Assigns a r2LMA to the MAG.
- 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.
- 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'.
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:
- 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
- there was no PBA' response from the r2LMA, or
- 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 either to the Status Value from the latest contacted PBA', or to 130 (Insufficient resources) in case of no responses from r2LMAs, 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.
[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') Example6. Handoff and Multi-Homing Considerations 🧚
okay so a MN can be multi-homed, which means it has network connectivity over multiple interfaces connected to one or more accesses 📱 If you want PMIPv6-based handovers between multiple interfaces or accesses, then a single LMA should have 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 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).
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 🔒
Okay bestie, this part is SERIOUS 😭 but we're gonna get through it together 🫶. The PMIPv6 signaling security stuff from RFC 5213 applies to this doc too, so go read that first. If an LMA is misconfigured, it can cause unwanted runtime LMA assignment attempts to LMAs that don't exist, or to LMAs that don't have and never will have an SA with the MAG 💀. Then the MAG gets failed binding updates or can't create mobility sessions. A misconfigured LMA can also mess up load distribution across the whole PMIPv6 domain. And this doc assumes the LMAs taking part in runtime LMA assignment already have adequate prior agreement and trust with each other 🤝.
If the SAs between MAGs and LMAs are manually keyed (which might be needed for the scenario in Section 5), then the anti-replay service for ESP-protected PMIPv6 traffic usually can't be provided 🙈. Whether that's a problem depends on the specific PMIPv6 domain, so it's deployment specific.
Now the spicy part 🌶️. If a PMIPv6 domain with runtime LMA assignment needs the rfLMA to change a PBU/PBA in any way (like swapping the source and destination IP address or any other field of the encapsulating IP packet), then the security mechanism protecting the PBU/PBA (such as possible authentication options) MUST NOT cover the outer IP packet on the parts that might get modified 😱. The other option is that the rfLMA does all the security processing on the PBU/PBA itself, and then the communication between the rfLMA and the r2LMA is unprotected at the PMIPv6 protocol level. In that case, the runtime assignment domain MUST implement an adequate level of security using other means, like layer-2 VPNs 🔐✨.
9. IANA Considerations 📋
New mobility options for use with PMIPv6 get 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 4910. Acknowledgements 🎀
Big thank you to Basavaraj Patil, Domagoj Premec, Ahmad Muhanna, Vijay Devarapalli, Rajeev Koodli, Yungui Wang, Pete McCann, and Qin Wu for talking through this document with the author 🥰. And a super special shoutout to Qian Li, who gave really 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.
[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.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📦 where this page comes from
- ietf: rfc6463 2012-02
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms