RFC 7411
Multicast Listener Extensions for Mobile IPv6 (MIPv6) and Proxy Mobile IPv6 (PMIPv6) Fast Handovers
Multicast Listener Extensions for Mobile IPv6 (MIPv6) and Proxy Mobile IPv6 (PMIPv6) Fast Handovers 🦋✨
okay bestie, let's start with the ID card 🪪. This is RFC 7411, published in November 2014 by the IETF, and it's an Experimental doc, so it's not a Standards Track spec 🧪. It's written by T. Schmidt, Ed. (HAW Hamburg), M. Waehlisch (link-lab & FU Berlin), R. Koodli (Intel), G. Fairhurst (University of Aberdeen), and D. Liu (China Mobile) 🫶. It updates RFC 5568, and its ISSN is 2070-1721. It doesn't list anything it obsoletes 💅.
Abstract ✨
okay so fast handover protocols for Mobile IPv6 (MIPv6) and Proxy Mobile IPv6 (PMIPv6) are all about mobility management for unicast traffic, and they cut down handover latency 🏃♀️. BUT the base fast handover operations don't touch multicast at all, which means native multicast listeners get zero acceleration 😭. And that's a problem, because so many multicast apps like IPTV or conferencing are delay-sensitive and real-time, so they'd totally benefit from faster handover completion 📺🔥.
This doc extends Mobile IPv6 Fast Handovers (FMIPv6) and Fast Handovers for Proxy Mobile IPv6 (PFMIPv6) so they include multicast traffic management in fast handover operations 💖. The multicast support lives first in the control plane, through rapid context transfer between access routers, and second in the data plane, through optional fast traffic forwarding that may include buffering 🧚. An FMIPv6 access router shows that it supports multicast with an updated Proxy Router Advertisements message format 🎀.
This document updates RFC 5568, "Mobile IPv6 Fast Handovers".
Status of This Memo
this doc 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 consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). Not every IESG-approved doc is a candidate for any level of Internet Standard, so check Section 2 of RFC 5741 if you're curious 🤓.
For info on the current status, any errata, and how to send feedback, go to http://www.rfc-editor.org/info/rfc7411 🔗.
Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved. 🌈
This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stand on the date of publication. Please read these carefully, because they describe your rights and restrictions for 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 they're provided without warranty as described in the Simplified BSD License 💜.
Table of Contents
1. Introduction ....................................................4
1.1. Use Cases and Deployment Scenarios .........................5
2. Terminology .....................................................6
3. Protocol Overview ...............................................6
3.1. Multicast Context Transfer between Access Routers ..........7
3.2. Protocol Operations Specific to FMIPv6 .....................9
3.3. Protocol Operations Specific to PFMIPv6 ...................12
4. Protocol Details ...............................................15
4.1. Protocol Operations Specific to FMIPv6 ....................15
4.1.1. Operations of the Mobile Node ......................15
4.1.2. Operations of the Previous Access Router ...........15
4.1.3. Operations of the New Access Router ................16
4.1.4. Buffering Considerations ...........................17
4.2. Protocol Operations Specific to PFMIPv6 ...................17
4.2.1. Operations of the Mobile Node ......................17
4.2.2. Operations of the Previous MAG .....................17
4.2.3. Operations of the New MAG ..........................19
4.2.4. IPv4 Support Considerations ........................20
5. Message Formats ................................................20
5.1. Multicast Indicator for Proxy Router Advertisement
(PrRtAdv) .................................................20
5.2. Extensions to Existing Mobility Header Messages ...........21
5.3. New Multicast Mobility Option .............................21
5.4. New Multicast Acknowledgement Option ......................24
5.5. Length Considerations: Number of Records and Addresses ....25
5.6. MLD and IGMP Compatibility Requirements ...................25
6. Security Considerations ........................................26
7. IANA Considerations ............................................26
8. References .....................................................26
8.1. Normative References ......................................26
8.2. Informative References ....................................27
Appendix A. Considerations for Mobile Multicast Sources ..........29
Acknowledgments ...................................................29
Authors' Addresses ................................................301. Introduction ✨
okay so Mobile IPv6 [RFC6275] is a network-layer mobility protocol that needs Mobile Nodes to take part 🙋♀️, while Proxy Mobile IPv6 [RFC5213] gives you mobility without needing any mobility protocol operations on the Mobile Node (MN) 🪄. Both of them cause traffic disruptions during handovers, and those can be totally intolerable in real-time stuff like gaming or conferencing 😩. Mobile IPv6 Fast Handovers (FMIPv6) [RFC5568] and Fast Handovers for Proxy Mobile IPv6 (PFMIPv6) [RFC5949] make handovers way better, but only for unicast communication 💅. The delays get reduced to roughly the bigger of the link switching delay and the signaling delay between Access Routers (ARs) or Mobile Access Gateways (MAGs) [FMIPv6-Analysis] ⚡.
Here's the tea ☕: none of the protocols above come with dedicated treatment for seamless IP multicast [RFC1112] data service 🙈. MIPv6 only roughly defines multicast for Mobile Nodes, using either a remote subscription approach or a home subscription through bidirectional tunneling via the Home Agent (HA) 🏠. Multicast forwarding services aren't specified in [RFC5213] and are handled by separate specs instead: [RFC6224] and [RFC7287] 📚. For the rest of this doc, it's assumed that mechanisms and protocol operations are already in place to transport multicast traffic to ARs. Those operations are called 'JOIN/LEAVE' of an AR, and the explicit techniques for managing multicast transmission are out of scope here 🚫.
Mobile multicast protocols need to support apps like IPTV, which have high-volume content streams and need to reach potentially large numbers of receivers 📺🌊. So they should preserve the multicast nature of packet distribution and approximate optimal routing [RFC5757] 🦋. Relying on home tunneling to optimize multicast is undesirable 🙅♀️. Unencapsulated, native multicast transmission requires establishing forwarding state, and the unicast fast handover protocols won't transfer that state between access routers 💔. So multicast traffic won't get the expedited handover performance, BUT an MN (or its corresponding MAG in PMIPv6) can perform remote subscriptions in each visited network 🧚.
This document specifies extensions to FMIPv6 and PFMIPv6 that include multicast traffic management for fast handover operations, whether the multicast is any-source or source-specific 🎀. The protocol extensions were designed under these requirements:
- multicast context transfer shall be transparently included in unicast fast handover operations;
- neither unicast mobility protocols nor multicast routing shall be modified or otherwise affected; and
- no active participation of MNs in PMIPv6 domains is defined.
The solution that both underlying unicast protocols share defines the per-group or per-channel transfer of multicast contexts between ARs or MAGs 🌸. The protocol defines the message extensions needed to carry (*,G) or (S,G) context information, independent of the particular handover protocol 💜. That way, ARs or MAGs can treat multicast traffic according to fast unicast handovers and get similar performance 🚀. No protocol changes are introduced that stop a multicast-unaware node from doing fast handovers with multicast-aware ARs or MAGs 🫶.
The specified mechanisms apply when a Mobile Node has joined and maintains one or several multicast group subscriptions before it goes through a fast handover ✨. This doc doesn't add any requirements on the multicast routing protocols in use, and the ARs or MAGs aren't assumed to be multicast routers 🙌. It does assume network conditions that allow native multicast reception in both the previous and new access network, though 🌈. Ways to bridge regions without native multicast connectivity are beyond the scope of this document 🚧.
Section 5.1 of this memo updates the Proxy Router Advertisements (PrRtAdv) message format defined in Section 6.1.2 of [RFC5568] so an FMIPv6 AR can indicate support for multicast 📣💖.
1.1. Use Cases and Deployment Scenarios
okay so multicast extensions for fast handovers are how you get multicast services working in networks that already run one of the unicast fast handover protocols, [RFC5568] or [RFC5949] 🦋 and usually those fast handover protocols get switched on inside an operator network or some dedicated service setup ✨
multicast group communication has a bunch of major use cases, bestie 🍓 the classic one is infotainment, where huge multimedia streams go out to tons of receivers at once (think IPTV 📺). then there's time-critical stuff like news updates or stock-exchange prices, which get sent via multicast so everyone gets fair and fast updates 💅 both of these can be mobile, and both seriously benefit from fast handovers, so mobile operators can level up their service quality or sell premium features by turning fast handovers on 👑
another classic area is conversational group stuff, like conferencing or gaming, plus dedicated collab environments or teams 🫶 machine-to-machine communication in the Internet of Things is expected to create more mobile use cases too (like cars talking to each other 🚗). when the transmission quality has to be really high and the parties are moving fast, fast handovers may be needed 🔥
most of these deployment scenarios are tied to fixed infrastructure with consumer equipment at the edge, so they'll likely follow an operator-centric approach like PFMIPv6 💖 but Internet tech is evolving for infrastructureless scenarios too, like disaster recovery, rescue, crisis prevention, and civil safety 🌈 mobile end-to-end group communication is needed in Public Protection and Disaster Relief (PPDR) scenarios, where mobile multicast has to work between rescue teams, police officers, fire brigade teams, paramedic teams, and command control offices so citizens stay protected and healthy 🧚 these use cases need fast and reliable mobile services that can't rely on operator infrastructure, so they're expected to benefit from running multicast with FMIPv6 ✨
2. Terminology ✨
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
this doc uses the terminology for mobility entities in [RFC5568], [RFC5949], [RFC6275], and [RFC5213] 💜
a multicast group is any group (*,G) or (S,G) multicast channel listed in a Multicast Listener Report Message 🎀
3. Protocol Overview 🦋
this section gives an informative overview of the protocol mechanisms, without normative specifications 🌸
the reference scenario for multicast fast handover is shown in Figure 1 👑 a Mobile Node starts out attached to the previous access network (P-AN) through the Previous Access Router (PAR) or Previous Mobile Access Gateway (PMAG), then moves to the new access network (N-AN) connected through a New AR (NAR) or New MAG (NMAG) 🚀
*** *** *** ***
* ** ** ** *
* *
* Multicast Cloud *
* *
* ** ** ** *
*** *** *** ***
/ \
/ \
/ \
+........../..+ +..\..........+
. +-------+-+ .______. +-+-------+ .
. | PAR |()_______)| NAR | .
. | (PMAG) | . . | (NMAG) | .
. +----+----+ . . +----+----+ .
. | . . | .
. ___|___ . . ___|___ .
. / \ . . / \ .
. ( P-AN ) . . ( N-AN ) .
. \_______/ . . \_______/ .
. | . . | .
. +----+ . . +----+ .
. | MN | ----------> | MN | .
. +----+ . . +----+ .
+.............+ +.............+
Figure 1: Reference Network for Fast Handover3.1. Multicast Context Transfer between Access Routers ✨
in a fast handover scenario (see Figure 1), ARs/MAGs set up a mutual binding and can swap context info about the MN 💖 this context transfer gets triggered when the forthcoming movement of an MN to a new AR is detected, and it helps the MN immediately resume communication on the new subnet using its previous IP address 🌈 here's the twist: unlike unicast, multicast flow reception doesn't mainly depend on address and binding cache management, it needs distribution trees to adapt so traffic follows the MN as it moves 😭 that process may be a lot slower than fast handover management [RFC5757] 💀 so to speed things up, a multicast listener can get a twofold advantage by including the multicast groups it's subscribed to in the context transfer 🫶 first, the NAR can proactively join the subscribed groups as soon as it learns about them 🔥 second, multicast flows can be included in traffic forwarding through the tunnel set up from the PAR to the NAR by the unicast fast handover protocol 🧚
there are two modes of operation in FMIPv6 and in PFMIPv6 🎀 the predictive mode lets AR-binding and context transfer happen before an MN handover, while in the reactive mode these steps run after the MN is detected as having reattached to a NAR (NMAG) 🦋 the signaling details differ between FMIPv6 and PFMIPv6 and are outlined in Sections 3.2 and 3.3 🌸
in a predictive fast handover, the access router (i.e., PAR (PMAG) in Figure 1) learns about the impending movement of the MN and, at the same time, about the multicast group context as specified in Sections 3.2 and 3.3 👑 after that, the PAR starts an AR-binding and context transfer by sending a Handover Initiation (HI) message to the NAR (NMAG) 🚀 the HI message is extended with multicast group states carried in mobility header options, as defined in Section 5.3 💅 when the HI message arrives, the NAR sends back a multicast acknowledgement in its Handover Acknowledgement (HAck) answer that shows whether it can support each requested group (see Section 5.4) ✨ the NAR (NMAG) says it wants to receive multicast traffic forwarded by the PAR using standard Multicast Listener Discovery (MLD) signaling for IPv6, or the Internet Group Management Protocol (IGMP) for an IPv4 compatibility case 💖
nodes normally create forwarding state for each group requested 🌈 there are several reasons a node might decide not to forward a specific group, e.g., the NAR could already have a native subscription for the group(s), or capacity constraints could stop it decapsulating extra streams 😬 on the previous network there may be policy or capacity constraints that make forwarding the multicast traffic undesirable 🙈 the PAR can add the tunnel interface it got from the underlying unicast protocol to its multicast forwarding database for the groups the MN wants to receive, so multicast flows can be forwarded in parallel with the unicast traffic 🧚
the NAR implements an MLD proxy [RFC4605] that gives host-side behavior toward the upstream PAR 🦋 the proxy submits an MLD report to the upstream tunnel interface to signal the set of groups to be forwarded 💜 it stops multicast forwarding from the tunnel once the group is natively received 🔥 at the same time, the NAR joins all groups that aren't already subscribed, using its native multicast upstream interface 🫶 while the MN hasn't arrived at a downstream interface of the NAR, multicast subscriptions on the MN's behalf are tied to a downstream loopback interface 🌸 once the Join reaches the NAR, native multicast forwarding of the subscribed group(s) is enabled downstream 👑
in a reactive fast handover, the PAR finds out about the movement of the MN after it has re-associated with the new access network 💅 from the new link, it also gets told about the MN's multicast context ✨ since group membership info is already at the new access network before the context transfer, MLD join signaling can run in parallel with the HI/HAck exchange 💖 after the context transfer, multicast data can be forwarded to the new access network through the PAR-NAR tunnel of the fast handover protocol 🌈 depending on the network topology, multicast traffic for some groups may natively arrive before it's forwarded from the PAR 🧚
in both modes of operation, it's the PAR's (PMAG's) job to properly manage multicast state when an MN leaves, meaning figuring out whether it can prune the traffic for any unsubscribed group 😭 depending on the link type and MLD parameter settings, methods for spotting the MN's departure need to be applied (see [RFC5757]) 🎀 while looking at subscriptions from the remaining nodes and from the tunnel interfaces, the PAR uses normal multicast forwarding rules to decide whether multicast traffic can be pruned 🦋
this method lets an MN take part in multicast group communication with handover performance that's comparable to unicast handover ✨ worth noting: tunnel management between access routers in all modes is inherited from the corresponding unicast fast handover protocols 🫶 so tunnels stay active until unicast handover operations have been completed for the MN 💜
3.2. Protocol Operations Specific to FMIPv6 💅
okay so ARs that support multicast in FMIPv6 announce it by flipping an indicator bit (the M bit) in their PrRtAdv message, as defined in Section 5.1 🎀. The juicy details, like which flavors and groups are supported, get swapped during the HI/HAck dialogs at handover time 🫶
the MN is the one who kicks things off ✨ it sends a Fast Binding Update (FBU) to start handover management. Since the MN knows which multicast groups it wants to keep, it attaches mobility options with its group states (see Section 5.3) to the FBU, so the ARs know its multicast context. The ARs then use those multicast context options for inter-AR context transfer 🦋
in predictive mode, the FBU goes out on the previous link and the PAR catches it, as shown in Figure 2 💖 the PAR pulls out the multicast context options and tucks them into its HI message. When the HAck comes back, the PAR passes the multicast acknowledgement along by adding the matching mobility options to its Fast Binding ACK (FBack) 🌸 once the MN gets that FBack, it knows which groups have multicast support on the new access network. if some groups or multicast service models aren't supported, the MN can decide what to do about it, like tunneling to cover the gap 🧚 also, the proactive multicast context transfer can still succeed even if the MN misses the FBack on the previous link. no cap, that's resilient 👑
MN PAR NAR
| | |
|------RtSolPr------->| |
|<-----PrRtAdv--------| |
| | |
| | |
|---------FBU-------->|----------HI--------->|
| (Multicast MobOpt) | (Multicast MobOpt) |
| | |
| |<--------HAck---------|
| | (Multicast AckOpt) |
| | Join to
| | Multicast
| | Groups
| | |
| <-----FBack---|--FBack------> |
| (Multicast AckOpt) | (Multicast AckOpt) |
| | |
disconnect optional |
| packet ================>|
| forwarding |
| | |
connect | |
| | |
|------------UNA --------------------------->|
|<=================================== deliver packets
| |
Figure 2: Predictive Multicast Handover for FMIPv6now reactive mode, which is Figure 3 🦋 here the MN attaches to the new access link and sends an Unsolicited Neighbor Advertisement (UNA), then issues an FBU. The NAR forwards that FBU to the PAR without processing it 💅 at this point the MN can rejoin all its subscribed multicast groups without needing AR help. Even so, multicast context options still get exchanged in the HI/HAck dialog, so intermediate forwarding of the requested multicast flows can happen 🌈 multicast traffic might come in from an MN subscription at the same moment the NAR gets the HI message, and that's fine because those flows can be quietly left out of forwarding by setting an appropriate Multicast Acknowledgement Option. either way, the NAR MUST make sure that no more than one flow of the same group gets forwarded to the MN, so nothing gets duplicated. no duplicate drama allowed 🙈
MN PAR NAR
| | |
|------RtSolPr------->| |
|<-----PrRtAdv--------| |
| | |
disconnect | |
| | |
| | |
connect | |
|-------UNA-----------|--------------------->|
|-------FBU-----------|---------------------)|
| (Multicast MobOpt) |<-------FBU----------)|
| | |
Join to | |
Multicast | |
Groups | |
| |----------HI--------->|
| | (Multicast MobOpt) |
| |<-------HAck----------|
| | (Multicast AckOpt) |
| | |
| |(HI/HAck if necessary)|
| | |
| FBack, optional |
| packet forwarding ==========>|
| | |
|<=================================== deliver packets
| |
Figure 3: Reactive Multicast Handover for FMIPv63.3. Protocol Operations Specific to PFMIPv6 💖
okay so in a proxy mobile IPv6 environment, the MN stays totally clueless about network layer changes 🙈 and the fast handover stuff gets run by the access routers or MAGs that MNs are plugged into via node-specific point-to-point links. The handover initiation (or the re-association) is managed by the access networks, which means access routers need to be aware of the multicast membership state at the Mobile Node 🦋 there are two ways to get that membership info:
- MAGs may perform explicit tracking (see [RFC4605] and [RFC6224]) or extract membership status from forwarding states at node-specific links.
- routers can issue a general MLD query at handovers. Both methods are equally applicable. However, a router that does not provide explicit membership tracking needs to query its downstream links after a handover. The MLD membership information then allows the PMAG to learn the multicast group subscriptions of the MN.
In predictive mode, the PMAG finds out about the MN's upcoming move, including its new Access Point Identifier (New AP ID) ✨. Without explicit tracking, it immediately submits a general MLD query and receives MLD reports showing the multicast address listening state of the subscribed group(s). Then (see Figure 4) it starts binding and context transfer with the NMAG by issuing a HI message augmented with multicast contexts in the mobility options defined in Section 5.3. The NMAG extracts the multicast context information and acts as described in Section 3.1 🎀
PMAG NMAG
MN P-AN N-AN (PAR) (NAR)
| | | | |
| Report | | | |
|---(MN ID,-->| | | |
| New AP ID) | | | |
| | HO Indication | |
| |--(MN ID, New AP ID)-->| |
| | | | |
| | | Optional: |
| | | MLD Query |
| | | | |
| | | |------HI---->|
| | | |(Multicast MobOpt)
| | | | |
| | | |<---HAck-----|
| | | |(Multicast AckOpt)
| | | | |
| | | | Join to
| | | | Multicast
| | | | Groups
| | | | |
| | | |HI/HAck(optional)
| | | |<- - - - - ->|
| | | | |
| | | optional packet |
| | | forwarding =======>|
disconnect | | | |
| | | | |
connect | | | |
| MN-AN connection | AN-MAG connection |
|<----establishment----->|<----establishment------->|
| | | (substitute for UNA) |
| | | | |
|<========================================== deliver packets
| | | | |
Figure 4: Predictive Multicast Handover for PFMIPv6In reactive mode, the NMAG learns that the MN has attached to the N-AN and sets up connectivity using the PMIPv6 protocol operations. However, it has no knowledge of the multicast state at the MN 🙈 So, triggered by an MN attachment, the NMAG sends a general MLD query and then joins the groups for which it receives multicast listener report messages. In the case of a reactive handover, the binding is initiated by the NMAG, and the HI/HAck message semantic is inverted (see [RFC5949]) 🔄 For multicast context transfer, the NMAG attaches to its HI message the group identifiers it wants forwarded from the PMAG. Using the identical syntax in its Multicast Mobility Option headers, as defined in Section 5.4, the PMAG acknowledges the requested groups in a HAck answer, indicating which group(s) it is willing to forward. The corresponding call flow is shown in Figure 5 💜
PMAG NMAG
MN P-AN N-AN (PAR) (NAR)
| | | | |
disconnect | | | |
| | | | |
connect | | | |
| | | | |
| MN-AN connection | AN-MAG connection |
|<---establishment---->|<----establishment------->|
| | |(substitute for UNA & FBU)|
| | | | |
| | | | MLD Query
| | | | |
| | | | Join to
| | | | Multicast
| | | | Groups
| | | |
| | | |<------HI----|
| | | |(Multicast MobOpt)
| | | | |
| | | |---HAck----->|
| | | |(Multicast AckOpt)
| | | | |
| | | | |
| | | |HI/HAck(optional)
| | | |<- - - - - ->|
| | | | |
| | | optional packet |
| | | forwarding =======>|
| | | | |
|<======================================== deliver packets
| | | | |
Figure 5: Reactive Multicast Handover for PFMIPv64. Protocol Details ✨
This section gives the normative definition of the protocol operations 📜
4.1. Protocol Operations Specific to FMIPv6 🌸
4.1.1. Operations of the Mobile Node
A Mobile Node that wants to manage multicast traffic through fast handover operations MUST transfer its MLD listener state records within the fast handover negotiations 🎀
When it senses a handover in predictive mode, an MN MUST build a Multicast Mobility Option, as described in Section 5.3, that contains the MLD or IGMP multicast listener state, and append it to the Fast Binding Update (FBU) before signaling with the PAR 💅
The MN will receive the Multicast Acknowledgement Option(s) as part of the Fast Binding Acknowledge (FBack) (see Section 5.4) and find out about unsupported or prohibited groups at the NAR 👀 The MN MAY take appropriate actions, such as home tunneling, to enable reception of groups that are not available via the NAR. Apart from standard FMIPv6 signaling, the MN doesn't need any multicast-specific operation when it reattaches in the new network ✨
In reactive mode, the MN MUST append the identical Multicast Mobility Option to the FBU it sends after its reconnect 🔁 In response, it learns about the Multicast Acknowledgement Option(s) from the FBack and expects the corresponding multicast data. At the same time, it joins all subscribed multicast groups directly on its newly established access link 🫶
4.1.2. Operations of the Previous Access Router
A PAR that supports multicast advertises that support by setting the 'M' bit in the Proxy Router Advertisement (PrRtAdv) message, as specified in Section 5.1 of this document. This indicator exclusively tells the MNs that the PAR can process and exchange Multicast Mobility Options during fast handover operations 🌈
In predictive mode, a PAR receives the multicast listener state of an MN before the handover, from the Multicast Mobility Option appended to the FBU. It forwards these records to the NAR within HI messages and expects Multicast Acknowledgement Option(s) in a HAck, which is itself returned to the MN as an appendix to the FBack. When doing the multicast context exchange, the PAR is instructed to include the PAR-to-NAR tunnel, obtained from unicast handover management, in its multicast downstream interfaces, and it waits to receive multicast listener report messages from the NAR. In response to receiving multicast subscriptions, the PAR SHOULD forward group data, acting as a regular multicast router or proxy. However, the PAR MAY refuse to forward some or all of the multicast flows (for example, because of administrative configurations or load conditions) ⚠️
In reactive mode, the PAR receives the FBU augmented by the Multicast Mobility Option from the new network, but it carries on with an identical multicast record exchange in the HI/HAck dialog. As in the predictive case, it configures the PAR-to-NAR tunnel for the multicast downstream. It then (if capable) forwards data according to the group membership indicated in the multicast listener report messages received from the NAR 🦋
In both modes, the PAR MUST interpret the first of the two events (the departure of the MN or the reception of the Multicast Acknowledgement Option(s)) as if the MN had sent a multicast LEAVE message, and react according to the signaling scheme deployed in the access network (that is, MLD querying or explicit tracking) 🧚
4.1.3. Operations of the New Access Router 🦋
okay so a NAR that does multicast tells everyone by setting the 'M' bit in PrRtAdv, as laid out in Section 5.1 of this document 💅. That bit has one job: it just lets MNs know the NAR can process and exchange Multicast Mobility Options during fast handover. Nothing more, nothing less ✨.
In predictive mode, the NAR gets the multicast listener state for an expected MN from the Multicast Mobility Option tucked into the HI message 🧚. It pulls out the multicast group membership records, matches the requested subscriptions against what it offers, and then joins those groups using a downstream loopback interface. That leads to proper regular subscriptions on a native multicast upstream interface, with no extra forwarding needed 🔥. At the same time, the NAR builds Multicast Acknowledgement Option(s) (see Section 5.4) listing the groups that aren't supported on the new access link, and sends that list back inside a HAck. Once there's an operational bidirectional tunnel from the PAR to the NAR, the NAR joins the groups the MN asked for, and the PAR forwards them down the tunnel link 🌸.
In reactive mode, the NAR only learns about a new MN's multicast listener state from the Multicast Mobility Option on each HI message. That shows up after the MN has already done its own local subscriptions to the multicast service 🙈. So the NAR works out the overlap between what was requested and what it supports, then issues a join for each group, forwarding it over the PAR-NAR tunnel interface 💖.
In both modes, the NAR MUST send a LEAVE message to the tunnel when it's no longer needed to forward a group, e.g., after native multicast traffic arrives or the MN ends a group membership 🫶. The LEAVE can be delayed, but sending it right away means the PAR and NAR don't have to keep processing traffic that isn't going to be forwarded anyway ✨.
4.1.4. Buffering Considerations 🍓
Multicast packets can get lost during handover 😭. In predictive mode (as shown in Figure 2), packets can be lost while the MN is -- already or still -- detached from the networks, even though they're forwarded to the NAR. In reactive mode (Figure 3), it can be even worse. There's a delay before the join for the multicast group happens after the MN reattaches to the NAR, and multicast packets can't be delivered during that gap 💀.
Buffering the packets at the PAR can cut down on loss, but it can also use up more resources and add delay to packet transmission 🌈. Implementors should balance these requirements based on what the applications care about most (e.g., real-time requirements or loss sensitivity) 👑.
4.2. Protocol Operations Specific to PFMIPv6 💜
4.2.1. Operations of the Mobile Node 🌸
A Mobile Node that wants in on multicast traffic joins, maintains, and leaves groups just like it's sitting on the fixed Internet 💅. It cooperates in handover indication as specified in [RFC5949], as its access link-layer technology requires. Honestly, no multicast-specific mobility actions or implementations are required at the MN in a PMIPv6 domain, so there's nothing extra to build here 🙌.
4.2.2. Operations of the Previous MAG 🦋
A MAG that receives a handover indication for one of its MNs follows the same predictive fast handover mode as a PMAG 🧚. It MUST issue an MLD General Query immediately on its corresponding link, unless it does explicit membership tracking on that link. Once it knows the MN's multicast subscriptions, the PMAG builds a Multicast Mobility Option (as described in Section 5.3) containing the MLD and IGMP multicast listener state. If that isn't empty, the Mobility Option gets appended to the regular fast handover HI messages. If a unicast HI message goes out before multicast state detection, the multicast listener state is sent in an additional HI message to the NMAG 💖.
The PMAG then waits until it receives the Multicast Acknowledgement Option(s) in a HAck message (see Section 5.4) and the bidirectional tunnel with the NMAG is created. After the HAck arrives, the PMAG adds the tunnel to its downstream interfaces in the multicast forwarding database. For the groups reported in the Multicast Acknowledgement Option(s), meaning the ones not supported in the new access network, the PMAG normally takes appropriate actions (e.g., forwarding and termination) according to network policy. It SHOULD start forwarding multicast traffic down the tunnel interface for the groups in the multicast listener reports received from the NMAG. However, it MAY deny forwarding some or all of those groups (e.g., because of administrative configurations or load conditions) 👑.
After the MN departs and a LEAVE message comes in, it is RECOMMENDED that the PMAG stop forwarding the specified groups and update its multicast forwarding database. It correspondingly sends a LEAVE message to its upstream link for any group where there are no longer any active listeners on any downstream link 🫶.
A MAG that receives a HI message with the Multicast Mobility Option for a currently attached node follows the reactive fast handover mode as a PMAG. It returns a Multicast Acknowledgement Option(s) (see Section 5.4) within a HAck message, listing the groups it doesn't provide forwarding support for to the NMAG. It adds the bidirectional tunnel with the NMAG to its downstream interfaces and starts forwarding multicast traffic for the groups listed in the multicast listener report messages from the NMAG. On receiving a LEAVE message for a group, the PMAG stops forwarding that specific group and updates its multicast forwarding database. Based on its multicast forwarding state, it sends a LEAVE message to its upstream link for any group where there are no longer any active listeners on any downstream link 🔥.
In both modes, the PMAG treats the MN's departure as a multicast LEAVE message from the MN, and reacts according to the signaling scheme deployed in the access network (i.e., MLD querying and explicit tracking) 🌈.
4.2.3. Operations of the New MAG 💅
A MAG that receives a HI message with a Multicast Mobility Option for a currently unattached node follows the same predictive fast handover mode as an NMAG 🧚. It decides which multicast groups will be forwarded from the PMAG, and builds a Multicast Acknowledgement Option (see Section 5.4) that enumerates only the unwanted groups. This Mobility Option gets appended to the regular fast handover HAck messages or, if a unicast HAck message goes out before multicast state acknowledgement, it's sent in an additional HAck message to the PMAG.
Right after that, the NMAG SHOULD update its MLD membership state based on the membership reported in the Multicast Mobility Option. Until the MN reattaches, the NMAG uses its Loopback interface for downstream and MUST NOT forward traffic to the potential link of the MN 🙈. The NMAG SHOULD issue JOIN messages for those newly selected groups to its regular multicast upstream interface. Once the bidirectional tunnel with the PMAG is established, the NMAG additionally joins those groups on the tunnel interface that were requested to be forwarded from the PMAG 🦋.
A MAG that experiences a connection request for an MN without a prior corresponding Multicast Mobility Option is operating in the reactive fast handover mode as an NMAG. Following the reattachment, it SHOULD immediately issue an MLD General Query to learn about the multicast subscriptions of the newly arrived MN 🍓. Using standard multicast operations, the NMAG joins groups not currently forwarded using its regular multicast upstream interface. At the same time, it selects groups for forwarding from the PMAG and builds a Multicast Mobility Option (as described in Section 5.3) that contains the multicast listener state. If that isn't empty, this Mobility Option is appended to the regular fast handover HI messages with the F flag set. Or, if a unicast HI message goes out before multicast state detection, it's sent in an additional HI message to the PMAG 💖.
Once the Multicast Acknowledgement Option is received and the bidirectional tunnel is established, the NMAG additionally joins the set of groups it wants to receive by forwarding from the PMAG, on the tunnel interface. When multicast flows arrive, the NMAG forwards data to the appropriate downlink(s) ✨.
In both modes, the NMAG MUST send a LEAVE message to the tunnel when forwarding of a group is no longer needed, e.g., after native multicast traffic arrives or the group membership of the MN ends. Although the message can be delayed, sending the LEAVE immediately means the PAR and NAR don't have to process traffic that isn't going to be forwarded 💜.
4.2.4. IPv4 Support Considerations 🌈
An MN in a PMIPv6 domain MAY use an IPv4 address transparently for communication, as specified in [RFC5844] 🦋. For this purpose, Local Mobility Anchors (LMAs) can register IPv4-Proxy-CoAs in its binding caches, and MAGs can provide IPv4 support in access networks. Correspondingly, multicast membership management will be performed by the MN using IGMP. For multiprotocol multicast support on the network side, IGMPv3 router functions are required at both MAGs (see Section 5.6 for compatibility considerations with previous IGMP versions). Context transfer between MAGs can transparently proceed in the HI/HAck message exchanges by encapsulating IGMP multicast state records within Multicast Mobility Options (see Sections 5.3 and 5.4 for details on message formats) 🧚.
The deployment of IPv4 multicast support SHOULD be homogeneous across a PMIP domain. This avoids multicast service breaks during handovers 🫶.
It's worth mentioning the dual-stack IPv4/IPv6 access network scenario, and the use of Generic Routing Encapsulation (GRE) tunneling as specified in [RFC5845] 🌸. The corresponding implications and operations are discussed in the PMIP Multicast Base Deployment document (see [RFC6224]) 👑.
5. Message Formats ✨
5.1. Multicast Indicator for Proxy Router Advertisement (PrRtAdv) 🦋
okay so this bit updates the PrRtAdv message format from Section 6.1.2 of [RFC5568] ✨ The update takes the first bit of the Reserved field and uses it to carry the 'M' bit, as shown in Figure 6. An FMIPv6 AR says it supports multicast by setting the 'M' bit to 1 💖
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 | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Subtype |M| Reserved | Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ...
+-+-+-+-+-+-+-+-+-+-+-+-
Figure 6: Multicast Indicator Bit for Proxy Router Advertisement
(PrRtAdv) MessageHere's the breakdown of the 'M' bit 🌸
M = 1means the specifications in this document apply ✨M = 0means fast handover carries on according to [RFC5568] 🍓
The default value of this bit is 0, which means a non-multicast-capable service 🙈
5.2. Extensions to Existing Mobility Header Messages 🧚
the fast handover protocols use an IPv6 header type called Mobility Header, defined in [RFC6275] 💅 Mobility Headers can carry variable Mobility Options, which is the whole reason this works 🎀
so the multicast listener context of an MN gets moved during fast handover from the PAR/PMAG over to the NAR/NMAG inside a new Multicast Mobility Option. That context MUST be acknowledged by a matching Multicast Acknowledgement Option 🫶 Depending on the handover scenario and protocol, the option lives in the mobility option list of HI/HAck only (PFMIPv6), or in FBU/FBack/HI/HAck (FMIPv6) 👑
5.3. New Multicast Mobility Option 🌈
this section defines the Multicast Mobility Option. It holds the current listener state record of the MN, pulled from the MLD Multicast Listener Report message, and it looks like Figure 7 🦋
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 | Option-Code | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ MLD or IGMP Report Payload +
~ ~
~ ~
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: Mobility Header Multicast OptionHere's the scoop on each field 🍓
Type: 60💖Lengthis an 8-bit unsigned integer 🎀 It's the length of this option in 32-bit words, and it doesn't count the Type, Length, Option-Code, and Reserved fields.Option-Codetells you which payload type you're dealing with 🧚1: IGMPv3 Payload Type ✨2: MLDv2 Payload Type 💜3: IGMPv3 Payload Type from IGMPv2 Compatibility Mode 🌸4: MLDv2 Payload Type from MLDv1 Compatibility Mode 🦋
ReservedMUST be set to zero by the sender and MUST be ignored by the receiver 🙈
The MLD or IGMP Report Payload is the Membership Report message with its ICMP header stripped off 😭 It always holds an integer number of multicast records. The formats are defined for MLDv2 in [RFC3810] and for IGMPv3 in [RFC3376]. This field MUST always contain the first header line (the Reserved field and the No of Mcast Address Records) 💅
Figure 8 shows the Report Payload for MLDv2. Check Section 5.2 of [RFC3810] for the definition of Multicast Address Records. If IGMPv3 is in use, the payload follows the IGMPv3 Group Records instead, so check Section 4.2 of [RFC3376] for those 🌈
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |No of Mcast Address Records (M)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. Multicast Address Record (1) .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Multicast Address Record (2) .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . |
. . .
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Multicast Address Record (M) .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: MLDv2 Report Payload5.4. New Multicast Acknowledgement Option 💜
the Multicast Acknowledgement Option reports how the context transfer went 🫶 It also lists the state records that couldn't be transferred to the next access network. It looks like Figure 9 🌸
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 | Option-Code | Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ MLD or IGMP Unsupported Report Payload +
~ ~
~ ~
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: Mobility Header Multicast Acknowledgement OptionHere's the field rundown 🎀
Type: 61🧚Lengthis an 8-bit unsigned integer. It's the length of this option in 32-bit words, not counting the Type, Length, Option-Code, and Status fields 💖Option-Code: 0✨Statustells you what happened 🔥1: Report Payload type unsupported 💀2: Requested group service unsupported 😭3: Requested group service administratively prohibited 🙈
The MLD or IGMP Unsupported Report Payload has the exact same shape as the MLD and IGMP Report Payload field from Section 5.3. The difference is that it only holds the Multicast Address Records that aren't supported or are prohibited in the new access network 🌈 This field MUST always contain the first header line (the Reserved field and the No of Mcast Address Records). It MUST NOT contain any Mcast Address Records if the status code equals 1 🦋
Heads up that group subscriptions to specific sources might get rejected at the destination network. So the multicast address records can look different from what was originally requested in an MLD or IGMP Report Payload option 👀
5.5. Length Considerations: Number of Records and Addresses ✨
the HI/HAck and FBU/FBack dialogs have length limits on multicast context records, because the Length field is only 8 bits 🙈 The most payload you get in FBU/FBack messages is 4 octets (the Mobility Option header line) plus 1024 octets (the MLD Report Payload). For example, you can fit about 51 Multicast Address Records of minimal length (without source states) in one message pair 🌸 In normal handover scenarios that number goes down even more, because unicast context and Binding Authorization data take up room too 😭
If you've got more MLD reports than fit in the payload, they MAY be sent across multiple HI/HAck or FBU/FBack message pairs 🫶 In PFMIPv6, context info can be fragmented over several HI/HAck messages. But a single MLDv2 Report Payload MUST NOT be fragmented 💅 So for one Multicast Address Record, the number of source addresses (S,.) is capped at 62 👑
5.6. MLD and IGMP Compatibility Requirements 🌈
Access routers (MAGs) MUST support MLDv2 and IGMPv3 💖 For MLDv1 and IGMPv2 listeners to get multicast service, the routers MUST follow the interoperability rules in [RFC3810] and [RFC3376] and set the Multicast Address Compatibility Mode properly 🎀
when the Multicast Address Compatibility Mode is MLDv1 or IGMPv2, the router quietly translates the later MLDv1 and IGMPv2 messages for that multicast address into their MLDv2 and IGMPv3 versions 🧚 It uses those in the context transfer. The current Compatibility Mode state gets translated into the code of the Multicast Mobility Option from Section 5.3 ✨ A NAR (NMAG) that gets a Multicast Mobility Option during handover will switch to the lowest level of MLD and IGMP Compatibility Mode it learned from its previous and new option values 🦋 That minimal compatibility agreement keeps things running smoothly 💜
6. Security Considerations ✨
okay bestie, security time 🔒💀 these are the vulnerabilities that go beyond what the base protocols already cover ([RFC5568], [RFC5949], [RFC3810], and [RFC3376]), so pay attention!!
Multicast context transfer during predictive handovers sets up group state at remote access routers, and it can lead to group subscriptions without any further validation of the multicast service requests 😬. So a NAR (NMAG) gets asked to help with potentially complex multicast rerouting, and it may end up receiving large volumes of traffic 🌊. Malicious or accidental multicast context transfers can put a serious strain on route setup and traffic management, both on the backbone infrastructure and on the access router itself 💅.
Rapid rerouting or traffic overload can be mitigated by rate control at the AR, which limits how often traffic redirects happen and how many subscriptions there are in total 🦋. Also, the wireless access network stays protected from multicast data injection until the requesting MN attaches to the new location 🛡️✨.
7. IANA Considerations 🌸
this document defines two new mobility options, both allocated from the "Mobility Options" registry at <http://www.iana.org/assignments/mobility-parameters> 🎀
60Multicast Mobility Option, described in Section 5.361Multicast Acknowledgement Option, described in Section 5.4
8. References 📚
8.1. Normative References
these are the must-read ones, the foundations everything else sits on 🧱
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. - [RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support in IPv6", RFC 6275, July 2011,
<http://www.rfc-editor.org/info/rfc6275>. - [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008,
<http://www.rfc-editor.org/info/rfc5213>. - [RFC5568] Koodli, R., "Mobile IPv6 Fast Handovers", RFC 5568, July 2009,
<http://www.rfc-editor.org/info/rfc5568>. - [RFC5949] Yokota, H., Chowdhury, K., Koodli, R., Patil, B., and F. Xia, "Fast Handovers for Proxy Mobile IPv6", RFC 5949, September 2010,
<http://www.rfc-editor.org/info/rfc5949>. - [RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, August 1989,
<http://www.rfc-editor.org/info/rfc1112>. - [RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick, "Internet Group Management Protocol (IGMP) / Multicast Listener Discovery (MLD)-Based Multicast Forwarding ("IGMP/MLD Proxying")", RFC 4605, August 2006,
<http://www.rfc-editor.org/info/rfc4605>. - [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June 2004,
<http://www.rfc-editor.org/info/rfc3810>. - [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, October 2002,
<http://www.rfc-editor.org/info/rfc3376>.
8.2. Informative References
these ones are good background reading, the extra context that makes everything click 🦋
- [RFC5757] Schmidt, T., Waehlisch, M., and G. Fairhurst, "Multicast Mobility in Mobile IP Version 6 (MIPv6): Problem Statement and Brief Survey", RFC 5757, February 2010,
<http://www.rfc-editor.org/info/rfc5757>. - [FMCAST-MIP6] Suh, K., Kwon, D., Suh, Y., and Y. Park, "Fast Multicast Protocol for Mobile IPv6 in the fast handovers environments", Work in Progress, draft-suh-mipshop-fmcast-mip6-00, February 2004.
- [FMIPv6-Analysis] Schmidt, T. and M. Waehlisch, "Predictive versus Reactive -- Analysis of Handover Performance and Its Implications on IPv6 and Multicast Mobility", Telecommunication Systems, Vol. 30, No. 1-3, pp. 123-142, November 2005,
<http://dx.doi.org/10.1007/s11235-005-4321-4>. - [RFC6224] Schmidt, T., Waehlisch, M., and S. Krishnan, "Base Deployment for Multicast Listener Support in Proxy Mobile IPv6 (PMIPv6) Domains", RFC 6224, April 2011,
<http://www.rfc-editor.org/info/rfc6224>. - [RFC7287] Schmidt, T., Gao, S., Zhang, H., and M. Waehlisch, "Mobile Multicast Sender Support in Proxy Mobile IPv6 (PMIPv6) Domains", RFC 7287, June 2014,
<http://www.rfc-editor.org/info/rfc7287>. - [RFC5844] Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy Mobile IPv6", RFC 5844, May 2010,
<http://www.rfc-editor.org/info/rfc5844>. - [RFC5845] Muhanna, A., Khalil, M., Gundavelli, S., and K. Leung, "Generic Routing Encapsulation (GRE) Key Option for Proxy Mobile IPv6", RFC 5845, June 2010,
<http://www.rfc-editor.org/info/rfc5845>.
Appendix A. Considerations for Mobile Multicast Sources 🎬
okay so this whole document only spells out fast handover operations for mobile listeners 👂 this appendix is a quick peek at mobile multicast sources, which is a whole other vibe 🫶
in a multicast-enabled Proxy Mobile IPv6 domain, multicast sender support will probably come from any one of the mechanisms in [RFC7287] ✨ in that case, multicast data packets from an MN get forwarded transparently, either to its associated LMA or to a multicast-enabled access network. In every case, a mobile source can keep transmitting multicast packets after a handover from PMAG to NMAG with no extra management operations needed 🙌 packets with a persistent source address keep flowing through the LMA or the access network into the distribution system that was already set up 🌈
BUT, plot twist 🙈 an MN changes its Care-of Address while doing FMIPv6 handovers. Even though MNs can still send packets through the reverse NAR-PAR tunnel using their previous Care-of Address for a limited time, multicast sender support in this Mobile IPv6 setup will most likely use one of the basic mechanisms from Section 5.1 of [RFC5757]: (1) bidirectional tunneling, (2) remote subscription, or (3) agent-based solutions 💜 a solution for multicast senders that's deployed the same way across the whole mobile access network can support seamless services during fast handovers. The details of that are beyond the scope of this document, so that's a story for another day 💅
Acknowledgments 🫶
okay the shoutouts 📣 protocol extensions for multicast in Fast Mobile IPv6 were talked about loosely for several years 🍓 Repeated attempts were made to define the corresponding protocol extensions. The first version [FMCAST-MIP6] was presented by Kyungjoo Suh, Dong-Hee Kwon, Young-Joo Suh, and Youngjun Park in 2004 👑
this work was stimulated by lots of fruitful discussions in the MobOpts research group 🧚 we'd like to thank all the active members for their constructive thoughts and contributions on multicast mobility 💖 The MULTIMOB working group gave continuous feedback during the evolution of this work ⭐ Comments, discussions, and reviewing remarks came from (in alphabetical order) Carlos J. Bernardos, Luis M. Contreras, Hui Deng, Shuai Gao, Brian Haberman, Dirk von Hugo, Min Hui, Georgios Karagian, Marco Liebsch, Behcet Sarikaya, Stig Venaas, and Juan Carlos Zuniga 🌸✨
funding was provided by the German Federal Ministry of Education and Research within the projects Mindstone, SKIMS, and SAFEST. This is gratefully acknowledged 🇩🇪💜
Authors' Addresses 🦋
the people behind this, with their contact details 💌
Thomas C. Schmidt (editor)
HAW Hamburg
Dept. Informatik
Berliner Tor 7
Hamburg D-20099
Germany
EMail: t.schmidt@haw-hamburg.deMatthias Waehlisch
link-lab & FU Berlin
Hoenower Str. 35
Berlin D-10318
Germany
EMail: mw@link-lab.netRajeev Koodli
Intel
3600 Juliette Lane
Santa Clara, CA 95054
United States
EMail: rajeev.koodli@intel.comGodred Fairhurst
University of Aberdeen
School of Engineering
Aberdeen AB24 3UE
United Kingdom
EMail: gorry@erg.abdn.ac.ukDapeng Liu
China Mobile
Phone: +86-123-456-7890
EMail: liudapeng@chinamobile.com📦 where this page comes from
- ietf: rfc7411 2014-11
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms