RFC 8885
Proxy Mobile IPv6 Extensions for Distributed Mobility Management
Bestie, this is RFC 8885 🎀 It's titled Proxy Mobile IPv6 Extensions for Distributed Mobility Management, and it's an Experimental doc (not Standards Track), so it's for trying stuff out and evaluating it. It's from October 2020 and carries ISSN 2070-1721. The authors are CJ. Bernardos, A. de la Oliva (UC3M), F. Giust (Athonet), JC. Zúñiga (SIGFOX), and A. Mourad (InterDigital) 💜. The header doesn't list anything it obsoletes or updates ✨
Abstract ✨
Okay so DMM setups let networks spread traffic out optimally, so you don't need centrally deployed anchors handling IP mobility support for everyone 🌸
There are lots of ways to tackle DMM, like extending network-based mobility protocols (think Proxy Mobile IPv6) or client-based ones (think Mobile IPv6), among others. This doc goes with the first option 💅 It proposes a PMIPv6-based solution where mobility sessions are anchored at the last IP hop router, which is called the mobility anchor and access router (MAAR). A MAAR is an enhanced access router that can also act as a local mobility anchor or mobility access gateway on a per-prefix basis. The main focus is on the required extensions needed to effectively support simultaneously anchoring several flows at different distributed gateways 🦋
Status of This Memo ✨
This document is not an Internet Standards Track specification. It's published for examination, experimental implementation, and evaluation 🧚
It defines an Experimental Protocol for the Internet community 💖 It's a product of the Internet Engineering Task Force (IETF) and represents the IETF community's consensus. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). Not every IESG-approved doc is eligible for any level of Internet Standard, so check Section 2 of RFC 7841 for the deets 🌈
Want the current status, any errata, or a way to send feedback? Head to https://www.rfc-editor.org/info/rfc8885 ✨
Copyright Notice 🌸
Copyright (c) 2020 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 (https://trustee.ietf.org/license-info) as they stand on the publication date. Please read these carefully, because they spell out your rights and restrictions for this document 🫶 Code Components pulled out of this document must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as described in the Simplified BSD License 💅
Table of Contents 🦋
1. Introduction
1.1. Requirements Language
2. Terminology
3. PMIPv6 DMM Extensions
3.1. Initial Registration
3.2. The CMD as PBU/PBA Relay
3.3. The CMD as MAAR Locator
3.4. The CMD as PBU/PBA Proxy
3.5. De-registration
3.6. Retransmissions and Rate Limiting
3.7. The Distributed Logical Interface (DLIF) Concept
4. Message Format
4.1. Proxy Binding Update
4.2. Proxy Binding Acknowledgement
4.3. Anchored Prefix Option
4.4. Local Prefix Option
4.5. Previous MAAR Option
4.6. Serving MAAR Option
4.7. DLIF Link-Local Address Option
4.8. DLIF Link-Layer Address Option
5. IANA Considerations
6. Security Considerations
7. References
7.1. Normative References
7.2. Informative References
Acknowledgements
Authors' Addresses1. Introduction 🎀
So the Distributed Mobility Management (DMM) paradigm is all about minimizing the impact of today's standardized mobility management solutions, which are centralized (at least to a pretty big extent) [RFC7333] 💅
The two biggest examples of current IP mobility solutions are Mobile IPv6 [RFC6275] and Proxy Mobile IPv6 (PMIPv6) [RFC5213] ✨ They give you mobility support, but the catch is that all the operations happen at one central point (the mobility anchor), which then has to handle data forwarding and control for a huge number of users 😭 The mobility anchor is the home agent for Mobile IPv6 and the local mobility anchor for PMIPv6. As [RFC7333] points out, centralized mobility solutions come with a whole list of problems: longer (sub-optimal) routing paths, scalability issues, signaling overhead (and most likely a longer associated handover latency), more complicated network deployment, higher vulnerability because there's a potential single point of failure, and a lack of granularity in the mobility management service. That last one means mobility is offered per node, because you can't define finer-grained policies, for example per application 🙈
DMM is supposed to fix all that by [RFC7333] [RFC7429] bringing the mobility anchor closer to the mobile node (MN) 🦋 The vibe is that the central anchor moves to the edge of the network and gets deployed in the MN's default gateway. So the first elements giving IP connectivity to a bunch of MNs are also the mobility managers for those MNs. This doc calls these entities Mobility Anchors and Access Routers (MAARs) 🌈
This document focuses on network-based DMM, so the starting point is making PMIPv6 work in a distributed way [RFC7429] 💜 Mobility is handled by the network, and the MN doesn't have to be involved. Here's the twist though: unlike PMIPv6, when the MN moves from one access network to another, the router anchoring the MN's address may change. That means the anchors need to signal each other to retrieve the MN's previous location(s) 👑 Another key thing in network-based DMM is that each MAAR owns its own prefix pool exclusively. Those prefixes get assigned by the MAAR to the MNs attached to it, and they're routable at that MAAR. Prefixes are handed out to MNs attached to a MAAR at that time, but they stay with those MNs as they move around, and they stay routable at that MAAR as well as towards the MN itself ✨
We look at partially distributed schemes, where only the data plane is distributed among access routers, kind of like mobile access gateways (MAGs). The control plane stays centralized toward a central node (used as an information store), which is freed up from any route management and MN data forwarding tasks 🧚
1.1. Requirements Language 💖
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here 🫶
2. Terminology 🌸
The following terms used in this document are defined in the PMIPv6 specification [RFC5213]:
- BCE: Binding Cache Entry
- LMA: Local Mobility Anchor
- MAG: Mobile Access Gateway
- MN: Mobile Node
- P-CoA: Proxy Care-of Address
- PBA: Proxy Binding Acknowledgement
- PBU: Proxy Binding Update
The following terms used in this document are defined in the Mobile IPv6 (MIPv6) specification [RFC6275]:
- CN: Correspondent Node
The following terms are used in this document too 💅
Home Control-Plane Anchor (Home-CPA or H-CPA): The Home-CPA hosts the MN's mobility session. An MN can have more than one mobility session, and those sessions can be anchored on the same Home-CPA or on different ones 👑 The Home-CPA works with the Home-DPA to manage the forwarding state.
Home Data Plane Anchor (Home-DPA or H-DPA): The Home-DPA is the topological anchor for the MN's IP addresses and/or prefixes 🦋 The Home-CPA picks the Home-DPA on a session basis, and the Home-DPA sits in the forwarding path for all of the MN's IP traffic 🌈
Access Control Plane Node (Access-CPN or A-CPN): The Access-CPN is in charge of interfacing with the MN's Home-CPA and the Access-DPN. It has a protocol interface to the Home-CPA 💜
Access Data Plane Node (Access-DPN or A-DPN): The Access-DPN function is hosted on the first-hop router where the MN is attached. It is not hosted on a Layer 2 (L2) bridging device such as an eNode(B) or Access Point 🙈
The following terms are defined and used in this document too 🧚
MAAR (Mobility Anchor and Access Router): The first-hop router where the MNs attach. It also acts as the mobility manager for the IPv6 prefixes it anchors, running the functions of PMIP's MAG and LMA. Depending on the prefix, it plays the role of Access-DPN, Home-DPA, and Access-CPN ✨
CMD (Central Mobility Database): The node that stores the BCEs allocated for the MNs in the mobility domain. It plays the role of Home-CPA 🌸
P-MAAR (Previous MAAR): When an MN moves to a new point of attachment, a new MAAR might be allocated as its anchor point for future IPv6 prefixes. The MAAR that served the MN before that new attachment becomes the P-MAAR. It's still the anchor point for the IPv6 prefixes it had allocated to the MN in the past, and it serves as the Home-DPA for flows using those prefixes 💖 There might be several P-MAARs serving one MN, for example when the MN keeps switching points of attachment while maintaining long-lasting flows 🔥
S-MAAR (Serving MAAR): The MAAR the MN is currently attached to. Depending on the prefix, it plays the role of Access-DPN, Home-DPA, and Access-CPN 🫶
Anchoring MAAR: A MAAR anchoring an IPv6 prefix used by an MN 👑
DLIF (Distributed Logical Interface): This is a logical interface at the IP stack of the MAAR. For each active prefix used by the MN, the S-MAAR has a DLIF configured (associated with each MAAR still anchoring flows). That's how an S-MAAR presents itself to each MN as multiple routers: one as itself, and one per P-MAAR 🌈
3. PMIPv6 DMM Extensions ✨
okay so the big idea 💖 is that we split the data plane and the control plane apart. the data plane becomes distributed and gets run by the MAARs out at the edge of the network, while the control plane is still on the MAARs but also leans on one central boss called the Central Mobility Database (CMD) 👑. the PMIPv6 hierarchy between LMA and MAG is still there, just with some major glow-ups 🦋:
- The LMA is discharged from the data forwarding role, so only the Binding Cache and its management operations stick around. Hence, the LMA gets renamed to "CMD", which is therefore a Home-CPA. Also, the CMD is able to send and parse both PBU and PBA messages 📨.
- The MAG gets enriched with LMA functionalities, which is why it's now called a Mobility Anchor and Access Router (MAAR) 🌸. It keeps a local Binding Cache for the MNs attached to it, and it is able to send and parse PBU and PBA messages.
- The Binding Cache gets extended to include info about the P-MAARs where the MN was anchored and still has active data sessions 🧚.
- Each MAAR has its own unique set of global prefixes (which are configurable) that it can hand out to MNs, but these must be exclusive to that MAAR, i.e., no other MAAR can allocate the same prefixes 🔥.
The MAARs lean on the CMD to access and update info about the MNs, which gets stored as mobility sessions. So basically, one centralized node keeps a global view of the network status 👀. The CMD gets queried whenever an MN is detected joining or leaving the mobility domain. It might be a fresh attachment, a detachment, or a handover, but MAARs aren't aware of past info about a mobility session, so they contact the CMD to retrieve the data they care about and then take the right action 💅. The query procedure and message exchange sequence can vary to optimize update latency and/or signaling overhead. Here, we get one method for initial registration and three different approaches for updating mobility sessions using PBUs and PBAs. Each approach gives the CMD a different role:
- The CMD is a PBU/PBA relay;
- The CMD is only a MAAR locator;
- The CMD is a PBU/PBA proxy.
The solution in this document allows per-prefix anchoring decisions 🎀. For example, some flows can be anchored at a central Home-DPA (like a traditional LMA), or an application can switch to the locally anchored prefix to gain route optimization, as indicated in [RFC8563]. ngl this kind of per-prefix treatment would potentially need extra extensions to the MAARs and signaling between the MAARs and the MNs to convey the per-flow anchor preference (central, distributed). Those aren't covered in this document, so no spoilers 🙈.
Note that an MN may move across different MAARs, which might result in several P-MAARs existing at a given moment, each one anchoring a different prefix used by the MN 🌈.
3.1. Initial Registration
Initial registration happens when an MN attaches to a network for the first time, rather than attaching to a new network after moving from a previous one 🍓.
In this description (shown in Figure 1), it is assumed that:
- The MN is attaching to MAAR1.
- The MN is authorized to attach to the network.
Upon MN attachment, the following operations take place:
- MAAR1 assigns a global IPv6 prefix from its own prefix pool to the MN (Pref1). It also stores this prefix (Pref1) in the locally allocated temporary BCE.
- MAAR1 sends a PBU [RFC5213] with Pref1 and the MN's MN-ID to the CMD.
- Since this is an initial registration, the CMD stores a BCE containing the MN-ID, Pref1, and MAAR1's address (as a Proxy-CoA) as the primary fields.
- The CMD replies with a PBA with the usual options defined in PMIPv6 [RFC5213], meaning the MN's registration is fresh and no past status is available 💖.
- MAAR1 stores the BCE described in (1) and unicasts a Router Advertisement (RA) to the MN with Pref1.
- The MN uses Pref1 to configure an IPv6 address (IP1) (e.g., with stateless address autoconfiguration (SLAAC)) ✨.
Note that:
- Alternative IPv6 autoconfiguration mechanisms can also be used, though this document describes the SLAAC-based one.
- IP1 is routable at MAAR1 in the sense that it is on the path of packets addressed to the MN.
- MAAR1 acts as a plain router for packets destined to the MN, as no encapsulation or special handling takes place 🦋.
In the diagram shown in Figure 1 (and subsequent diagrams), the flow of packets is presented using *.
+-----+ +---+ +--+
|MAAR1| |CMD| |CN|
+-----+ +---+ +*-+
| | *
MN | * +---+
attach. | ***** _|CMD|_
detection | flow1 * / +-+-+ \
| | * / | \
local BCE | * / | \
allocation | * / | \
|--- PBU -->| +---*-+-' +--+--+ `+-----+
| BCE | * | | | | |
| creation |MAAR1+------+MAAR2+-----+MAAR3|
|<-- PBA ---| | * | | | | |
local BCE | +---*-+ +-----+ +-----+
finalized | *
| | Pref1 *
| | +*-+
| | |MN|
| | +--+
Operations sequence Packet flow
Figure 1: First Attachment to the NetworkNote that the registration process does not change regardless of the CMD's modes (relay, locator, or proxy) described in the following sections. The procedure is depicted in Figure 1 👑.
3.2. The CMD as PBU/PBA Relay
Okay so, when the CMD is acting as a PBU/PBA relay and the MN moves, this is the whole sequence 💅✨
- When the MN leaves its current point of attachment and attaches to MAAR2 (now the S-MAAR) 🦋, MAAR2 reserves an IPv6 prefix (Pref2), stores a temporary BCE, and sends a PBU to the CMD for registration.
- Once the CMD gets the PBU and does its BC lookup 🔍, it finds an entry that already exists for the MN and binds the MN-ID to its former location. So the CMD forwards the PBU to the MAAR listed as Proxy-CoA (MAAR1) and adds a new mobility option to tell MAAR1 the S-MAAR's global address (this is the Serving MAAR option, defined in Section 4.6). The CMD then updates the P-CoA field in the BCE for the MN with the S-MAAR's address.
- When MAAR1 gets that PBU, it can set up a tunnel on its side toward MAAR2 and the related routes for Pref1 🌈. Then MAAR1 replies to the CMD with a PBA (carrying the option we just mentioned) to confirm that the new location has successfully changed. That PBA has the prefix anchored at MAAR1 in the Home Network Prefix option.
- After the CMD gets the PBA, it updates the BCE and fills in an instance of the P-MAAR list 📋. The P-MAAR list is an extra field on the BCE with one element for each P-MAAR involved in the MN's mobility session, and each element holds that P-MAAR's global address and the prefix it delegated. The CMD also sends a PBA to the new S-MAAR. That PBA contains the previous Proxy-CoA and the prefix anchored to it, packed into a new mobility option called the Previous MAAR option (defined in Section 4.5). Then, once that PBA arrives, a bidirectional tunnel can be set up between the two MAARs, and new routes get set so the IP flow(s) carrying Pref1 are recovered 🫶.
- Now packets for Pref1 hit MAAR1 first, get encapsulated into the tunnel, and get forwarded to MAAR2, which finally delivers them to their destination 🚀. On the uplink, when the MN sends packets using Pref1 as a source address, they go to MAAR2 (since it's the MN's new default gateway) and then get tunneled to MAAR1, which routes them toward the next hop to the destination. Packets carrying Pref2, on the other hand, are routed by MAAR2 with no special packet handling in either direction 🎀.
+-----+ +---+ +-----+ +--+ +--+
|MAAR1| |CMD| |MAAR2| |CN| |CN|
+-----+ +---+ +-----+ +*-+ +*-+
| | | * *
| | MN * +---+ *
| | attach. ***** _|CMD|_ *
| | det. flow1 * / +-+-+ \ *flow2
| |<-- PBU ---| * / | \ *
| BCE | * / | *******
| check+ | * / | * \
| update | +---*-+-' +--+-*+ `+-----+
|<-- PBU*---| | | * | | *| | |
route | | |MAAR1|______|MAAR2+-----+MAAR3|
update | | | **(______)** *| | |
|--- PBA*-->| | +-----+ +-*--*+ +-----+
| BCE | * *
| update | Pref1 * *Pref2
| |--- PBA*-->| +*--*+
| | route ---move-->|*MN*|
| | update +----+
Operations sequence Data Packet flow
PBU/PBA messages with * contain
a new mobility optionFigure 2: Scenario after a Handover, CMD as Relay
For the MN's next movements, the whole process repeats, but now there are more P-MAARs involved, since the count grows with the number of prefixes the MN wants to keep 📈. Once the CMD gets the first PBU from the new S-MAAR, it forwards copies of that PBU to every P-MAAR listed in the BCE. That covers the P-MAAR registered as the current P-CoA (i.e., the MAAR from before the handover) plus everyone in the P-MAAR list 🧚. Those P-MAARs reply to the CMD with a PBA, and the CMD bundles all of those PBAs into one PBA for the S-MAAR. Then the S-MAAR can finally set up the tunnels with the P-MAARs 🎉.
It's worth noting that this design splits mobility management at the prefix granularity 🍓. It can be tuned to erase old mobility sessions when they're no longer needed, while the MN stays reachable through the latest prefix it acquired. The catch is that the latency of the mobility update is tied to the PBA from whichever P-MAAR is furthest away, in terms of RTT, meaning the one that takes the longest to reach the CMD 🐢. You can soften that drawback with a timeout at the CMD. When the timeout expires, all the PBAs collected so far get sent out, and the rest go out later when they arrive. Heads up though: in that case, the S-MAAR might get multiple PBAs from the CMD in response to a single PBU 👀. The CMD SHOULD follow the retransmission and rate-limiting considerations in Section 3.6, especially when it's aggregating and relaying PBAs.
Bursts alert 🚨: with multiple P-MAARs, say k MAARs, one PBU arriving at the CMD triggers k outgoing packets. Those packets can come out in bursts from the CMD, even though each one is headed to a different target. Pacing mechanisms MUST be introduced to avoid bursts on the outgoing link.
3.3. The CMD as MAAR Locator
The handover latency from the approach we just covered can be cut down if the P-MAARs are allowed to signal their info directly to the new S-MAAR ⚡. This procedure follows what was described in Section 3.2 right up until the P-MAAR gets the PBU with the Serving MAAR option. At that point the P-MAAR knows where the MN is now (thanks to the S-MAAR's address in the Serving MAAR option). So, besides sending a PBA to the CMD, it also sends a PBA to the S-MAAR that includes the prefix it's anchoring. That second PBA doesn't need any new options, because the prefix is already in the Home Network Prefix (HNP) option and the P-MAAR's address comes from the message's source address 💁. This frees the CMD from having to forward the PBA to the S-MAAR, since the S-MAAR gets a copy straight from the P-MAAR with everything it needs to build the tunnels and set the right routes. Figure 3 shows the new message sequence. The data forwarding stays exactly the same 🌸.
+-----+ +---+ +-----+ +--+ +--+
|MAAR1| |CMD| |MAAR2| |CN| |CN|
+-----+ +---+ +-----+ +*-+ +*-+
| | | * *
| | MN * +---+ *
| | attach. ***** _|CMD|_ *
| | det. flow1 * / +-+-+ \ *flow2
| |<-- PBU ---| * / | \ *
| BCE | * / | *******
| check+ | * / | * \
| update | +---*-+-' +--+-*+ `+-----+
|<-- PBU*---| | | * | | *| | |
route | | |MAAR1|______|MAAR2+-----+MAAR3|
update | | | **(______)** *| | |
|--------- PBA -------->| +-----+ +-*--*+ +-----+
|--- PBA*-->| route * *
| BCE update Pref1 * *Pref2
| update | +*--*+
| | | ---move-->|*MN*|
| | | +----+
Operations sequence Data Packet flow
PBU/PBA messages with * contain
a new mobility optionFigure 3: Scenario after a Handover, CMD as Locator
3.4. The CMD as PBU/PBA Proxy
You can get an even better result with this one 🏆. The CMD sends the PBA to the new S-MAAR before it tells the P-MAARs about the location change. Here's why it works: by the time the CMD receives the PBU for the new registration, it already has all the info the new S-MAAR needs to set up the tunnels and routes. So the PBA goes to the S-MAAR right after the PBU arrives, and it includes the Previous MAAR option in this case 🙌. At the same time, the CMD sends a PBU to the P-MAARs with the Serving MAAR option, so they know about the MN's new location and get what they need to set up their own tunnels and routes. Once a P-MAAR finishes its update, it sends a PBA back to the CMD to say the operation is done and the info is updated on all the network nodes ✅. This procedure comes from the first one with the message order rearranged, but the parameters communicated are the same 💜. Figure 4 shows the scheme, and yep, the data forwarding stays untouched 🫶.
+-----+ +---+ +-----+ +--+ +--+
|MAAR1| |CMD| |MAAR2| |CN| |CN|
+-----+ +---+ +-----+ +*-+ +*-+
| | | * *
| | MN * +---+ *
| | attach. ***** _|CMD|_ *
| | det. flow1 * / +-+-+ \ *flow2
| |<-- PBU ---| * / | \ *
| BCE | * / | *******
| check+ | * / | * \
| update | +---*-+-' +--+-*+ `+-----+
|<-- PBU*---x--- PBA*-->| | * | | *| | |
route | route |MAAR1|______|MAAR2+-----+MAAR3|
update | update | **(______)** *| | |
|--- PBA*-->| | +-----+ +-*--*+ +-----+
| BCE | * *
| update | Pref1 * *Pref2
| | | +*--*+
| | | ---move-->|*MN*|
| | | +----+
Operations sequence Data Packet flow
PBU/PBA messages with * contain
a new mobility optionFigure 4: Scenario after a Handover, CMD as Proxy
3.5. De-registration 🦋
okay so the de-registration mechanism from PMIPv6 just can't be used as-is in this solution, bestie 💅 Here's why: each MAAR handles its own independent mobility session (a single prefix or a set of prefixes) for a given MN, but the aggregated session actually lives over at the CMD. So if a P-MAAR decides the MN is gone because it's no longer on its access link, it removes the routing state for the prefix(es). That's the exact same state the CMD would delete too, so it totally wrecks any prefix continuity attempt 😭 not me watching the whole plan fall apart lol.
The simplest fix is to stop a P-MAAR from de-registering a prefix at all, and only let an S-MAAR de-register the whole MN session 🎀 To make that work, first you remove any L2 detachment event as a trigger, so de-registration only happens when the binding lifetime expires. That gives the MN a guard interval to connect to a new MAAR, which is honestly so smart 🧚 After that, the MAAR operations need a change, and there are two possible solutions you can deploy:
- A P-MAAR stops the BCE timer when it receives a PBU from the CMD containing a "Serving MAAR" option. That way only the S-MAAR is allowed to de-register the mobility session, since the MN has definitely left the domain 🌸
- When the BCE expires, P-MAARs can send de-registration messages to the CMD. Instead of acknowledging with a 0 lifetime, the CMD sends back a PBA with a non-zero lifetime, which renews the session if the MN is still connected to the domain 💜 iconic, right?
3.6. Retransmissions and Rate Limiting ✨
okay this part is about being polite to the network 🫶 The node sending PBUs (that's the CMD or S-MAAR) SHOULD use the timeout to also deal with missing PBAs, meaning it retransmits PBUs when they go unanswered. For the retransmission timer, the INITIAL_BINDACK_TIMEOUT [RFC6275] SHOULD be used.
Now the retransmissions MUST use an exponential backoff process, so the timeout period doubles on each retransmission. It keeps going until either the node gets a response or the timeout hits MAX_BINDACK_TIMEOUT [RFC6275] 🍓 The node MAY keep sending these messages at that slower rate indefinitely, so that's totally allowed 🌈
And one hard rule: the node MUST NOT send PBU messages to a particular node more than MAX_UPDATE_RATE times within a second [RFC6275] 🚫 Rate limits are literally the main character of this section, periodt 👑
3.7. The Distributed Logical Interface (DLIF) Concept
okay so one of the biggest headaches with a network-based DMM setup is figuring out how an MN can send and receive traffic anchored at different MAARs at the same time 😭, and how to steer which source IPv6 address the MN picks for a new flow without needing any special help from the MN's IP stack 💅. enter the DLIF 🦋. it's a software construct living in the MAAR, and it basically hides the anchor switcheroo from the MN so it doesn't have to know.
+---------------------------------------------------+
( Operator's )
( core )
+---------------------------------------------------+
| |
+---------------+ tunnel +---------------+
| IP stack |===============| IP stack |
+---------------+ +-------+-------+
| mn1mar1 |--+ (DLIFs) +--|mn1mar1|mn1mar2|--+
+---------------+ | | +-------+-------+ |
| phy interface | | | | phy interface | |
+---------------+ | | +---------------+ |
MAAR1 (o) (o) MAAR2 (o)
x x
x x
prefA::/64 x x prefB::/64
(AdvPrefLft=0) x x
(o)
|
+-----+
prefA::MN1 | MN1 | prefB::MN1
(deprecated) +-----+
Figure 5: DLIF: Exposing Multiple Routers (One per P-MAAR)the core idea is this: each S-MAAR shows itself to a given MN as multiple routers, one per P-MAAR linked to that MN 🌸. check out Figure 5 for the vibe. MN1 starts out on MAAR1 and grabs an IPv6 address (prefA::MN1) from a prefix anchored locally at MAAR1 (prefA::/64). at this point MAAR1 is both the anchoring and serving MAAR, and it acts like a regular IPv6 access router too. MAAR1 makes a DLIF to talk to MN1 over a point-to-point link, presenting itself as a logical router with its own MAC and IPv6 addresses (for example prefA::MAAR1/64 and fe80::MAAR1/64) through the DLIF mn1mar1 ✨. these addresses are MAAR1's "logical" identity for MN1, and they follow the MN around as it roams inside the domain. (fyi where all this info gets stored and updated is out of scope for this doc. possible spots include the home subscriber server, aka the HSS, or the user's profile 🧚)
if MN1 moves over and attaches to a different MAAR in the domain (MAAR2 in the Figure 5 example), that MAAR makes a brand new logical interface (mn1mar2) to show itself to MN1, and gives it a locally anchored prefix (prefB::/64) 🎀. but here's the twist: MN1 still has another active IPv6 address anchored at MAAR1, so MAAR2 also has to create an extra logical interface that looks just like the one MAAR1 was using to talk to MN1 💜. in this example MAAR1 is the only P-MAAR (MAAR2 is the same as the S-MAAR), so only mn1mar1 gets created. but the same process would repeat for every extra P-MAAR involved 🔁. to keep the prefix anchored at MAAR1 reachable, a tunnel between MAAR1 and MAAR2 gets set up and the routing gets updated to match 🛤️. the PBU/PBA signaling is what builds that bidirectional tunnel between MAAR1 and MAAR2, and it can also carry info about the prefix(es) anchored at MAAR1 and the addresses of the associated DLIF (that's mn1mar1) over to MAAR2 💅.
+------------------------------------------+ +----------------------+
| MAAR1 | | MAAR2 |
|+----------------------------------------+| |+--------------------+|
||+------------------++------------------+|| ||+------------------+||
|||+-------++-------+||+-------++-------+||| |||+-------++-------+|||
||||mn3mar1||mn3mar2||||mn2mar1||mn2mar2|||| ||||mn1mar1||mn1mar2||||
|||| LMAC1 || LMAC2 |||| LMAC3 || LMAC4 |||| |||| LMAC5 || LMAC6 ||||
|||+-------++-------+||+-------++-------+||| |||+-------++-------+|||
||| LIFs of MN3 || LIFs of MN2 ||| ||| LIFs of MN1 |||
||+------------------++------------------+|| ||+------------------+||
|| MAC1 (phy if MAAR1) || || MAC2 (phy if MAAR2)||
|+----------------------------------------+| |+--------------------+|
+------------------------------------------+ +----------------------+
x x x
x x x
(o) (o) (o)
| | |
+--+--+ +--+--+ +--+--+
| MN3 | | MN2 | | MN1 |
+-----+ +-----+ +-----+
Figure 6: Distributed Logical Interface ConceptFigure 6 zooms in on the logical interface idea 🔍. there are two MAARs and three MNs in this one. MAAR1 is serving MN2 and MN3, and MAAR2 is serving MN1. quick reminder: an S-MAAR is always the anchoring MAAR for the MNs it serves 👑. each MAAR has just one physical wireless interface in this example.
as we covered before, each MN always sees multiple logical routers, one per anchoring MAAR, no matter which MAAR is its S-MAAR right now 🌈. from the MN's point of view these MAARs look like totally different routers, even though the MN is physically connected through a single interface. the trick is that the S-MAAR sets up different logical interfaces. MN1 is attached to MAAR2 (so MAAR2 is its S-MAAR), which means MN1 picked an IPv6 address from MAAR2's pool (like prefB::/64). MAAR2 built a logical interface (mn1mar2) on top of its wireless physical interface (phy if MAAR2), and that's what serves MN1 🫶. this interface uses a logical MAC address (LMAC6) that's different from the hardware MAC address of MAAR2's physical interface (MAC2). over mn1mar2, MAAR2 advertises its locally anchored prefix prefB::/64. before MN1 hopped over to MAAR2, it was attached to MAAR1 and set up a locally anchored address there, and MN1 is still using that address in active conversations 💖. so MN1 keeps "seeing" an interface connecting to MAAR1 as if it were directly connected to both MAARs. that works because the S-MAAR (MAAR2) configures an extra DLIF, mn1mar1, which acts exactly like the logical interface MAAR1 configured back when MN1 was attached there. this means the MAC and IPv6 addresses on that logical interface stay the same no matter which physical MAAR is serving the MN 🧠. the info an S-MAAR needs to set up these logical interfaces can come from a few places: the information carried in the PBA, an external database (like the HSS), or other means 📦. as the figure shows, each MAAR can have several logical interfaces per attached MN, and it always has at least one (since an S-MAAR is also an anchoring MAAR for the attached MN) 💜.
to enforce the use of the prefix anchored locally at the S-MAAR, the RAs sent over the logical interfaces that play the role of anchoring MAARs (the ones that are different from the serving one) include a zero preferred prefix lifetime, and a non-zero valid prefix lifetime so the prefix stays valid while it's being deprecated 🙈. the goal is to deprecate the prefixes delegated by those MAARs so they stop serving the MN. ngl the catch is that ongoing communications can keep using those addresses even after they're deprecated, so this only affects the setup of new sessions 🌸.
the DLIF concept also unlocks this use case: say a given MAAR (like MAAR1 in Figure 5) gives access to a local IP network, and the resources on that network can't be reached from outside the local network (so an MN attached to MAAR2 can't get to them) 🏠. this is kind of like the local IP access scenario 3GPP considered, where a local gateway node gets picked for sessions that need local services instead of going through a central gateway 🛰️. the goal is to let an MN roam while still being able to reach this local IP network. the solution for this case uses more specific routes, as discussed in RFC 4191 [RFC4191], when the MN moves to a MAAR that isn't the one providing access to the local IP network (MAAR1 in the example). these routes are advertised through the DLIF where the MAAR is providing access to the local network (MAAR1 in this example). so if MN1 moves from MAAR1 to MAAR2, any active session MN1 has with a node on the local network connected to MAAR1 survives via the tunnel between MAAR1 and MAAR2 🦋. and any future connection attempt to the local network still works even though MN1 isn't attached to MAAR1 anymore, as long as a source address configured from MAAR1 gets selected for new connections (see [RFC6724], rule 5.5) ✨.
4. Message Format
This section defines extensions to the PMIPv6 [RFC5213] protocol messages 🎀.
4.1. Proxy Binding Update
a new flag (D) gets added to the PBU to show that the PBU is coming from a MAAR or a CMD and not from a MAG 🙌. the rest of the PBU format stays exactly the same as what's defined in [RFC5213].
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|H|L|K|M|R|P|F|T|B|S|D| Rsrvd | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility Options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+DMM Flag (D) The D flag gets set to tell the receiver that the PBU is from a MAAR or a CMD 🫶. when an LMA that doesn't support the extensions in this document gets a message with the D flag set, the PBU MUST NOT be processed by the LMA, and an error MUST be returned 🙅♀️.
Mobility Options a variable-length field, sized so the complete Mobility Header is an integer multiple of 8 octets long 📏. it holds zero or more TLV-encoded mobility options. the encoding and format of the defined options are described in Section 6.2 of [RFC6275] 🧚. the receiving node MUST ignore and skip any options it doesn't understand 💅.
4.2. Proxy Binding Acknowledgement ✨
okay so the PBA gets a brand new flag, the D flag 🎀, which tells everyone that the sender can run as a MAAR or CMD. Everything else in the PBA format stays exactly the same as what [RFC5213] already defined, so no drama there 💅
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status |K|R|P|T|B|S|D| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility Options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+DMM Flag (D)
The D flag gets set when the sender of the message is able to operate as a MAAR or CMD 🦋 Now here's the tea: if a MAG that doesn't support the extensions in this document gets a message with the D flag set, it MUST ignore the message, and an error MUST be returned. No sneaky processing allowed 🙈
Mobility Options
This is a variable-length field, sized so the whole Mobility Header ends up being an integer multiple of 8 octets long 🍓 It holds zero or more TLV-encoded mobility options. The encoding and format of the defined options are described in Section 6.2 of [RFC6275]. The MAAR MUST ignore and skip any options it doesn't understand. Main character energy: skip what you don't know 💜
4.3. Anchored Prefix Option
okay this one is a brand new option for PBU and PBA messages that get swapped between MAARs and CMDs 🌸 Because of that, it can ONLY show up if the D bit is set in a PBU/PBA. Its whole job is carrying the MN's prefix that's anchored at the anchoring MAAR. You can have multiple Anchored Prefix options in one message, so go wild ✨
This option has an alignment requirement of 8n+4. 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved | Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Anchored Prefix +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Type: 65
Length: an 8-bit unsigned integer giving the length of the option in octets, not counting the type and length fields. This field MUST be set to 18. 🔥
Reserved: unused at the time of publication 💅 The sender MUST initialize it to 0, and the receiver MUST ignore it.
Prefix Length: an 8-bit unsigned integer giving the prefix length in bits of the IPv6 prefix in the option.
Anchored Prefix: a 16-octet field holding the MN's IPv6 Anchored Prefix. Only the first Prefix Length bits are valid, and the rest of the bits MUST be ignored. Bye bye, extra bits 👋
4.4. Local Prefix Option
this is another new option, this time for PBU and PBA messages that go between MAARs or between a MAAR and a CMD 🧚 Same deal as before: it can only appear if the D bit is set in a PBU/PBA. It's used to share a prefix of a local network that can ONLY be reached through the anchoring MAAR. Again, multiple Local Prefix options are allowed in one message ✨
The Local Prefix option also has an alignment requirement of 8n+4, and it looks like this:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved | Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Local Prefix +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Type: 66
Length: an 8-bit unsigned integer giving the length of the option in octets, not counting the type and length fields. This field MUST be set to 18. 🌈
Reserved: unused at the time of publication. The sender MUST initialize it to 0, and the receiver MUST ignore it.
Prefix Length: an 8-bit unsigned integer giving the prefix length in bits of the IPv6 prefix in the option.
Local Prefix: a 16-octet field holding the IPv6 Local Prefix. Only the first Prefix Length bits are valid for the IPv6 Local Prefix, and the rest of the bits MUST be ignored. 💖
4.5. Previous MAAR Option
this one is brand new too, and it's for PBA messages that a CMD sends to a MAAR 🎀 Its purpose is to tell the S-MAAR about the P-MAAR's global address, plus the prefix that's anchored to it. Multiple Previous MAAR options can show up in the same message.
The Previous MAAR option has an alignment requirement of 8n+4. 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved | Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Previous MAAR +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Home Network Prefix +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Type: 67
Length: an 8-bit unsigned integer giving the length of the option in octets, not counting the type and length fields. This field MUST be set to 34. 🦋
Reserved: unused at the time of publication. The sender MUST initialize it to 0, and the receiver MUST ignore it.
Prefix Length: an 8-bit unsigned integer giving the prefix length in bits of the IPv6 prefix in the option.
Previous MAAR: a 16-octet field holding the P-MAAR's IPv6 global address.
Home Network Prefix: a 16-octet field holding the MN's IPv6 Home Network Prefix. Only the first Prefix Length bits are valid for the MN's IPv6 Home Network Prefix, and the rest of the bits MUST be ignored. 🫶
4.6. Serving MAAR Option
this new option is for PBU messages that go between the CMD and a P-MAAR 🌸 It tells the P-MAAR about the current S-MAAR's global address. Its format is as follows:
The Serving MAAR option has an alignment requirement of 8n+6. Its format is as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ S-MAAR's Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Type: 68
Length: an 8-bit unsigned integer giving the length of the option in octets, not counting the type and length fields. This field MUST be set to 16. 👑
Serving MAAR: a 16-octet field holding the S-MAAR's IPv6 global address.
4.7. DLIF Link-Local Address Option
last but not least 🧚 this new DLIF Link-Local Address option is for PBA messages going between MAARs and between a MAAR and a CMD. It exchanges the link-local address of the DLIF that should be configured on the S-MAAR, so the S-MAAR looks like the DLIF configured on the P-MAAR. Iconic, honestly ✨
The DLIF Link-Local Address option has an alignment requirement of 8n+6. Its format is as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ DLIF Link-Local Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Type: 69
Length: an 8-bit unsigned integer giving the length of the option in octets, not counting the type and length fields. This field MUST be set to 16. 🔥
DLIF Link-Local Address: a 16-octet field holding the link-local address of the logical interface. 💅
4.8. DLIF Link-Layer Address Option ✨
okay so this one is the DLIF Link-Layer Address option 🦋 it's a brand new mobility option for the PBA message, and it gets passed between MAARs and between a MAAR and a CMD 💌 its whole job is sharing the link-layer address of the DLIF so the S-MAAR can set up a DLIF that matches the one on the P-MAAR. main character energy 💅
Depending on how big the address is, the option MUST be aligned properly, following the mobility option alignment rules in [RFC6275] 📐
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ DLIF Link-Layer Address +
. ... .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Here's the breakdown of each field 🧩
Type: the value is70🎀Length: an 8-bit unsigned integer that tells you the length of the option in octets, not counting the type and length fields 📏Reserved: unused at the time of publication 🫧 the sender MUST initialize it to 0, and the receiver MUST ignore it 🙈DLIF Link-Layer Address: a variable-length field holding the link-layer address of the logical interface that's going to be configured on the S-MAAR 💖
The content and format of this field, including octet and bit ordering, follows Section 4.6 of [RFC4861] for carrying link-layer addresses 🌸 but on some access links the link-layer address isn't used or can't be figured out, and in that case this option cannot be used 💀
5. IANA Considerations 📋
okay IANA time 🌈 this document defines six new mobility options: Anchored Prefix, Local Prefix, Previous MAAR, Serving MAAR, DLIF Link-Local Address, and DLIF Link-Layer Address ✨ IANA assigned Type values for all of them from the same numbering space as the other mobility options in the "Mobility Options" registry at http://www.iana.org/assignments/mobility-parameters 🦋
This document also reserves a brand new flag (D) with a value of 0x0010 in the "Binding Update Flags" registry, and another new flag (D) with a value of 0x02 in the "Binding Acknowledgment Flags" of the "Mobile IPv6 parameters" registry (http://www.iana.org/assignments/mobility-parameters) 🍓
6. Security Considerations 🔐💀
okay bestie, this part is serious 😭 the protocol extensions in this document share the same security concerns as PMIPv6 [RFC5213] 🫣 it is recommended that the signaling messages, PBU and PBA, exchanged between the MAARs get protected with IPsec, specifically by using the security association that's already set up between them. this basically kills the threats of someone impersonating a MAAR 🛡️✨
when the CMD acts as a PBU/PBA relay, it might relay one PBU to multiple P-MAARs 👀 in situations with lots of fast handovers (think vehicular networks), there could be multiple previous MAARs, say k of them. so the CMD ends up creating k outgoing packets from one incoming packet 😱 that comes with a real amplification risk 🚨 to keep the output traffic (basically the rate of PBUs sent) under control, the CMD MUST use a pacing approach in its outgoing queue 🫧
when the CMD acts as a MAAR locator, mobility signaling (PBAs) gets exchanged between the P-MAARs and the current S-MAAR 🧚 so security associations are REQUIRED between the involved MAARs, on top of the ones already needed with the CMD 🔑
de-registration happens by timeout, so measures SHOULD be implemented to cut down on the risks of continued resource consumption (DoS attacks) 🙅♀️ for example, you could put a limit on how many P-MAARs are associated with a given MN ⭐
the CMD and the participating MAARs MUST be trusted parties authorized to perform all operations relevant to their role 👑
there are some privacy considerations too 🙈 even though the involved parties trust each other, the signaling reveals info about the previous locations each MN has visited, plus the active prefixes they're using at any given time. so mechanisms MUST be in place to make sure MAARs and CMDs don't disclose this information to other parties, or use it for anything other than providing the distributed mobility support specified in this document 🫶
7. References 📚
7.1. Normative References
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. - [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191, November 2005,
<https://www.rfc-editor.org/info/rfc4191>. - [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, DOI 10.17487/RFC4861, September 2007,
<https://www.rfc-editor.org/info/rfc4861>. - [RFC5213] Gundavelli, S., Ed., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, DOI 10.17487/RFC5213, August 2008,
<https://www.rfc-editor.org/info/rfc5213>. - [RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July 2011,
<https://www.rfc-editor.org/info/rfc6275>. - [RFC7333] Chan, H., Ed., Liu, D., Seite, P., Yokota, H., and J. Korhonen, "Requirements for Distributed Mobility Management", RFC 7333, DOI 10.17487/RFC7333, August 2014,
<https://www.rfc-editor.org/info/rfc7333>. - [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017,
<https://www.rfc-editor.org/info/rfc8174>.
7.2. Informative References
- [DISTRIBUTED-ANCHORING] Bernardos, C. and J. Zuniga, "PMIPv6-based distributed anchoring", Work in Progress, Internet-Draft, draft-bernardos-dmm-distributed-anchoring-09, 29 May 2017,
<https://tools.ietf.org/html/draft-bernardos-dmm-distributed-anchoring-09>. - [DMM-PMIP] Bernardos, C., Oliva, A., and F. Giust, "A PMIPv6-based solution for Distributed Mobility Management", Work in Progress, Internet-Draft, draft-bernardos-dmm-pmip-09, 8 September 2017,
<https://tools.ietf.org/html/draft-bernardos-dmm-pmip-09>. - [RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, "Default Address Selection for Internet Protocol Version 6 (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012,
<https://www.rfc-editor.org/info/rfc6724>. - [RFC7429] Liu, D., Ed., Zuniga, JC., Ed., Seite, P., Chan, H., and CJ. Bernardos, "Distributed Mobility Management: Current Practices and Gap Analysis", RFC 7429, DOI 10.17487/RFC7429, January 2015,
<https://www.rfc-editor.org/info/rfc7429>. - [RFC8563] Katz, D., Ward, D., Pallagatti, S., Ed., and G. Mirsky, Ed., "Bidirectional Forwarding Detection (BFD) Multipoint Active Tails", RFC 8563, DOI 10.17487/RFC8563, April 2019,
<https://www.rfc-editor.org/info/rfc8563>.
Acknowledgements 🫶
the authors want to thank Dirk von Hugo, John Kaippallimalil, Ines Robles, Joerg Ott, Carlos Pignataro, Vincent Roca, Mirja Kühlewind, Éric Vyncke, Adam Roach, Benjamin Kaduk, and Roman Danyliw for their comments on this document 💜 they also want to thank Marco Liebsch, Dirk von Hugo, Alex Petrescu, Daniel Corujo, Akbar Rahman, Danny Moses, Xinpeng Wei, and Satoru Matsushima for their comments and discussion on the documents [DISTRIBUTED-ANCHORING] and [DMM-PMIP], which this document is based on 🌷
and the authors also want to thank Lyle Bertz and Danny Moses for their in-depth review and their super valuable comments and suggestions 🎀
Authors' Addresses 💌
Carlos J. Bernardos
Universidad Carlos III de Madrid
Av. Universidad, 30
28911 Leganes Madrid
Spain
Phone: +34 91624 6236
Email: cjbc@it.uc3m.es
URI: http://www.it.uc3m.es/cjbc/Antonio de la Oliva
Universidad Carlos III de Madrid
Av. Universidad, 30
28911 Leganes Madrid
Spain
Phone: +34 91624 8803
Email: aoliva@it.uc3m.es
URI: http://www.it.uc3m.es/aoliva/Fabio Giust
Athonet S.r.l.
via Ca' del Luogo 6/8
36050 Bolzano Vicentino (VI)
Italy
Email: fabio.giust.research@gmail.comJuan Carlos Zúñiga
SIGFOX
425 rue Jean Rostand
31670 Labege
France
Email: j.c.zuniga@ieee.org
URI: http://www.sigfox.com/Alain Mourad
InterDigital Europe
Email: Alain.Mourad@InterDigital.com
URI: http://www.InterDigital.com/the end, bestie! 🌈💖 you made it through the whole RFC 🦋👑
📦 where this page comes from
- ietf: rfc8885 2020-10
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms