doc: Add RFC documents

1 files changed, 1683 insertions, 0 deletions

diff --git a/doc/rfc/rfc7411.txt b/doc/rfc/rfc7411.txt
new file mode 100644
index 0000000..fa9f5e2
--- /dev/null
+++ b/doc/rfc/rfc7411.txt
@@ -0,0 +1,1683 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                   T. Schmidt, Ed.
+Request for Comments: 7411                                   HAW Hamburg
+Updates: 5568                                               M. Waehlisch
+Category: Experimental                              link-lab & FU Berlin
+ISSN: 2070-1721                                                R. Koodli
+                                                                   Intel
+                                                            G. Fairhurst
+                                                  University of Aberdeen
+                                                                  D. Liu
+                                                            China Mobile
+                                                           November 2014
+
+
+       Multicast Listener Extensions for Mobile IPv6 (MIPv6) and
+               Proxy Mobile IPv6 (PMIPv6) Fast Handovers
+
+Abstract
+
+   Fast handover protocols for Mobile IPv6 (MIPv6) and Proxy Mobile IPv6
+   (PMIPv6) define mobility management procedures that support unicast
+   communication at reduced handover latency.  Fast handover base
+   operations do not affect multicast communication and, hence, do not
+   accelerate handover management for native multicast listeners.  Many
+   multicast applications like IPTV or conferencing, though, comprise
+   delay-sensitive, real-time traffic and will benefit from fast
+   handover completion.  This document specifies extension of the Mobile
+   IPv6 Fast Handovers (FMIPv6) and the Fast Handovers for Proxy Mobile
+   IPv6 (PFMIPv6) protocols to include multicast traffic management in
+   fast handover operations.  This multicast support is provided first
+   at the control plane by management of rapid context transfer between
+   access routers and second at the data plane by optional fast traffic
+   forwarding that may include buffering.  An FMIPv6 access router
+   indicates support for multicast using an updated Proxy Router
+   Advertisements message format.
+
+   This document updates RFC 5568, "Mobile IPv6 Fast Handovers".
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Schmidt, et al.               Experimental                      [Page 1]
+
+RFC 7411              Multicast for FMIPv6/PFMIPv6         November 2014
+
+
+Status of This Memo
+
+   This document is not an Internet Standards Track specification; it is
+   published for examination, experimental implementation, and
+   evaluation.
+
+   This document defines an Experimental Protocol for the Internet
+   community.  This document is a product of the Internet Engineering
+   Task Force (IETF).  It represents the consensus of the IETF
+   community.  It has received public review and has been approved for
+   publication by the Internet Engineering Steering Group (IESG).  Not
+   all documents approved by the IESG are a candidate for any level of
+   Internet Standard; see Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc7411.
+
+Copyright Notice
+
+   Copyright (c) 2014 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Schmidt, et al.               Experimental                      [Page 2]
+
+RFC 7411              Multicast for FMIPv6/PFMIPv6         November 2014
+
+
+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 ................................................30
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Schmidt, et al.               Experimental                      [Page 3]
+
+RFC 7411              Multicast for FMIPv6/PFMIPv6         November 2014
+
+
+1.  Introduction
+
+   Mobile IPv6 [RFC6275] defines a network-layer mobility protocol
+   involving participation by Mobile Nodes, while Proxy Mobile IPv6
+   [RFC5213] provides a mechanism without requiring mobility protocol
+   operations at a Mobile Node (MN).  Both protocols introduce traffic
+   disruptions on handovers that may be intolerable in many real-time
+   application scenarios such as gaming or conferencing.  Mobile IPv6
+   Fast Handovers (FMIPv6) [RFC5568] and Fast Handovers for Proxy Mobile
+   IPv6 (PFMIPv6) [RFC5949] improve the performance of handovers for
+   unicast communication.  Delays are reduced to the order of the
+   maximum of the link switching delay and the signaling delay between
+   Access Routers (ARs) or Mobile Access Gateways (MAGs)
+   [FMIPv6-Analysis].
+
+   No dedicated treatment of seamless IP multicast [RFC1112] data
+   service has been proposed by any of the above protocols.  MIPv6 only
+   roughly defines multicast for Mobile Nodes using a remote
+   subscription approach or a home subscription through bidirectional
+   tunneling via the Home Agent (HA).  Multicast forwarding services
+   have not been specified in [RFC5213] but are subject to separate
+   specifications: [RFC6224] and [RFC7287].  It is assumed throughout
+   this document that mechanisms and protocol operations are in place to
+   transport multicast traffic to ARs.  These operations are referred to
+   as 'JOIN/LEAVE' of an AR, while the explicit techniques to manage
+   multicast transmission are beyond the scope of this document.
+
+   Mobile multicast protocols need to support applications such as IPTV
+   with high-volume content streams and allow distribution to
+   potentially large numbers of receivers.  They should thus preserve
+   the multicast nature of packet distribution and approximate optimal
+   routing [RFC5757].  It is undesirable to rely on home tunneling for
+   optimizing multicast.  Unencapsulated, native multicast transmission
+   requires establishing forwarding state, which will not be transferred
+   between access routers by the unicast fast handover protocols.  Thus,
+   multicast traffic will not experience 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 in the
+   presence of any-source or source-specific multicast.  The protocol
+   extensions were designed under the requirements that
+
+   o  multicast context transfer shall be transparently included in
+      unicast fast handover operations;
+
+
+
+
+
+Schmidt, et al.               Experimental                      [Page 4]
+
+RFC 7411              Multicast for FMIPv6/PFMIPv6         November 2014
+
+
+   o  neither unicast mobility protocols nor multicast routing shall be
+      modified or otherwise affected; and
+
+   o  no active participation of MNs in PMIPv6 domains is defined.
+
+   The solution common to both underlying unicast protocols defines the
+   per-group or per-channel transfer of multicast contexts between ARs
+   or MAGs.  The protocol defines corresponding message extensions
+   necessary for carrying (*,G) or (S,G) context information independent
+   of the particular handover protocol.  ARs or MAGs are then enabled to
+   treat multicast traffic according to fast unicast handovers and with
+   similar performance.  No protocol changes are introduced that prevent
+   a multicast-unaware node from performing 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 prior to
+   undergoing a fast handover.  It does not introduce any requirements
+   on the multicast routing protocols in use, nor are the ARs or MAGs
+   assumed to be multicast routers.  It assumes network conditions,
+   though, that allow native multicast reception in both the previous
+   and new access network.  Methods 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] to
+   allow an FMIPv6 AR to indicate support for multicast.
+
+1.1.  Use Cases and Deployment Scenarios
+
+   Multicast extensions for fast handovers enable multicast services in
+   domains that operate either of the unicast fast handover protocols:
+   [RFC5568] or [RFC5949].  Typically, fast handover protocols are
+   activated within an operator network or within a dedicated service
+   installation.
+
+   Multicast group communication has a variety of dominant use cases.
+   One traditional application area is infotainment with voluminous
+   multimedia streams delivered to a large number of receivers (e.g.,
+   IPTV).  Other time-critical services, such as news items or stock-
+   exchange prices, are commonly transmitted via multicast to support
+   fair and fast updates.  Both of these use cases may be mobile, and
+   both largely benefit from fast handover operations.  Mobile operators
+   may therefore enhance their operational quality or offer premium
+   services by enabling fast handovers.
+
+
+
+
+
+
+Schmidt, et al.               Experimental                      [Page 5]
+
+RFC 7411              Multicast for FMIPv6/PFMIPv6         November 2014
+
+
+   Another traditional application area for multicast is conversational
+   group communication in scenarios like conferencing or gaming as well
+   as in dedicated collaborative environments or teams.  Machine-to-
+   machine communication in the emerging Internet of Things is expected
+   to generate various additional mobile use cases (e.g., among cars).
+   High demands on transmission quality and rapidly moving parties may
+   require fast handovers.
+
+   Most of the deployment scenarios above are bound to a fixed
+   infrastructure with consumer equipment at the edge.  Today, they are
+   thus likely to follow an operator-centric approach like PFMIPv6.
+   However, Internet technologies evolve for adoption in
+   infrastructureless scenarios, for example, disaster recovery, rescue,
+   crisis prevention, and civil safety.  Mobile end-to-end communication
+   in groups is needed in Public Protection and Disaster Relief (PPDR)
+   scenarios, where mobile multicast communication needs to be supported
+   between members of rescue teams, police officers, fire brigade teams,
+   paramedic teams, and command control offices in order to support the
+   protection and health of citizens.  These use cases require fast and
+   reliable mobile services that cannot rely on operator infrastructure.
+   They are thus 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 document 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 provides an informative overview of the protocol
+   mechanisms without normative specifications.
+
+   The reference scenario for multicast fast handover is illustrated in
+   Figure 1.  A Mobile Node is initially attached to the previous access
+   network (P-AN) via the Previous Access Router (PAR) or Previous
+   Mobile Access Gateway (PMAG) and moves to the new access network
+   (N-AN) connected via a New AR (NAR) or New MAG (NMAG).
+
+
+
+
+
+
+
+Schmidt, et al.               Experimental                      [Page 6]
+
+RFC 7411              Multicast for FMIPv6/PFMIPv6         November 2014
+
+
+                             ***  ***  ***  ***
+                            *   **   **   **   *
+                           *                    *
+                            *  Multicast Cloud *
+                           *                    *
+                            *   **   **   **   *
+                             ***  ***  ***  ***
+                                  /      \
+                                 /        \
+                                /          \
+                    +........../..+      +..\..........+
+                    . +-------+-+ .______. +-+-------+ .
+                    . |   PAR   |()_______)|   NAR   | .
+                    . |  (PMAG) | .      . |  (NMAG) | .
+                    . +----+----+ .      . +----+----+ .
+                    .      |      .      .      |      .
+                    .   ___|___   .      .   ___|___   .
+                    .  /       \  .      .  /       \  .
+                    . (  P-AN   ) .      . (  N-AN   ) .
+                    .  \_______/  .      .  \_______/  .
+                    .      |      .      .      |      .
+                    .   +----+    .      .   +----+    .
+                    .   | MN |  ---------->  | MN |    .
+                    .   +----+    .      .   +----+    .
+                    +.............+      +.............+
+
+               Figure 1: Reference Network for Fast Handover
+
+3.1.  Multicast Context Transfer between Access Routers
+
+   In a fast handover scenario (see Figure 1), ARs/MAGs establish a
+   mutual binding and provide the capability to exchange context
+   information concerning the MN.  This context transfer will be
+   triggered by detecting the forthcoming movement of an MN to a new AR
+   and assists the MN to immediately resume communication on the new
+   subnet using its previous IP address.  In contrast to unicast,
+   multicast flow reception does not primarily depend on address and
+   binding cache management but requires distribution trees to adapt so
+   that traffic follows the movement of the MN.  This process may be
+   significantly slower than fast handover management [RFC5757].  To
+   accelerate the handover, a multicast listener may offer a twofold
+   advantage of including the multicast groups under subscription in the
+   context transfer.  First, the NAR can proactively join the subscribed
+   groups as soon as it gains knowledge of them.  Second, multicast
+   flows can be included in traffic forwarding via the tunnel that is
+   established from the PAR to the NAR by the unicast fast handover
+   protocol.
+
+
+
+
+Schmidt, et al.               Experimental                      [Page 7]
+
+RFC 7411              Multicast for FMIPv6/PFMIPv6         November 2014
+
+
+   There are two modes of operation in FMIPv6 and in PFMIPv6.  The
+   predictive mode allows for AR-binding and context transfer prior to
+   an MN handover, while in the reactive mode, these steps are executed
+   after detection that the MN has reattached to a NAR (NMAG).  Details
+   of the signaling schemes 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
+   simultaneously about the multicast group context as specified in
+   Sections 3.2 and 3.3.  Thereafter, the PAR will initiate an AR-
+   binding and context transfer by transmitting a Handover Initiation
+   (HI) message to the NAR (NMAG).  The HI message is extended by
+   multicast group states carried in mobility header options, as defined
+   in Section 5.3.  On reception of the HI message, the NAR returns a
+   multicast acknowledgement in its Handover Acknowledgement (HAck)
+   answer that indicates its ability to support each requested group
+   (see Section 5.4).  The NAR (NMAG) expresses its willingness 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 why a node may decide not to forward a
+   specific group, e.g., the NAR could already have a native
+   subscription for the group(s) or capacity constraints can hinder
+   decapsulation of additional streams.  At the previous network, there
+   may be policy or capacity constraints that make it undesirable to
+   forward the multicast traffic.  The PAR can add the tunnel interface
+   obtained from the underlying unicast protocol to its multicast
+   forwarding database for those groups the MN wishes to receive, so
+   that multicast flows can be forwarded in parallel to the unicast
+   traffic.
+
+   The NAR implements an MLD proxy [RFC4605] providing host-side
+   behavior towards the upstream PAR.  The proxy will submit an MLD
+   report to the upstream tunnel interface to signal the set of groups
+   to be forwarded.  It will terminate multicast forwarding from the
+   tunnel when the group is natively received.  In parallel, the NAR
+   joins all groups that are not already under subscription using its
+   native multicast upstream interface.  While the MN has not arrived at
+   a downstream interface of the NAR, multicast subscriptions on behalf
+   of the MN are associated with a downstream loopback interface.
+   Reception of the Join at the NAR enables downstream native multicast
+   forwarding of the subscribed group(s).
+
+
+
+
+
+
+Schmidt, et al.               Experimental                      [Page 8]
+
+RFC 7411              Multicast for FMIPv6/PFMIPv6         November 2014
+
+
+   In a reactive fast handover, the PAR will learn about the movement of
+   the MN after the latter has re-associated with the new access
+   network.  Also, from the new link, it will be informed about the
+   multicast context of the MN.  As group membership information is
+   present at the new access network prior to context transfer, MLD join
+   signaling can proceed in parallel to HI/HAck exchange.  Following the
+   context transfer, multicast data can be forwarded to the new access
+   network using the PAR-NAR tunnel of the fast handover protocol.
+   Depending on the specific network topology, multicast traffic for
+   some groups may natively arrive before it is forwarded from the PAR.
+
+   In both modes of operation, it is the responsibility of the PAR
+   (PMAG) to properly apply multicast state management when an MN leaves
+   (i.e., to determine whether it can prune the traffic for any
+   unsubscribed group).  Depending on the link type and MLD parameter
+   settings, methods for observing the departure of an MN need to be
+   applied (see [RFC5757]).  While considering subscriptions of the
+   remaining nodes and from the tunnel interfaces, the PAR uses normal
+   multicast forwarding rules to determine whether multicast traffic can
+   be pruned.
+
+   This method allows an MN to participate in multicast group
+   communication with a handover performance that is comparable to
+   unicast handover.  It is worth noting that tunnel management between
+   access routers in all modes is inherited from the corresponding
+   unicast fast handover protocols.  Tunnels thus remain active until
+   unicast handover operations have been completed for the MN.
+
+3.2.  Protocol Operations Specific to FMIPv6
+
+   ARs that provide multicast support in FMIPv6 will advertise this
+   general service by setting an indicator bit ('M' bit) in its PrRtAdv
+   message, as defined in Section 5.1.  Additional details about the
+   multicast service support, e.g., flavors and groups, will be
+   exchanged within HI/HAck dialogs later at handover.
+
+   An MN operating FMIPv6 will actively initiate the handover management
+   by submitting a Fast Binding Update (FBU).  The MN, which is aware of
+   the multicast groups it wishes to maintain, will attach mobility
+   options containing its group states (see Section 5.3) to the FBU and
+   thereby inform ARs about its multicast context.  ARs will use these
+   multicast context options for inter-AR context transfer.
+
+   In predictive mode, the FBU is issued on the previous link and
+   received by the PAR as displayed in Figure 2.  The PAR will extract
+   the multicast context options and append them to its HI message.
+   From the HAck message, the PAR will redistribute the multicast
+   acknowledgement by adding the corresponding mobility options to its
+
+
+
+Schmidt, et al.               Experimental                      [Page 9]
+
+RFC 7411              Multicast for FMIPv6/PFMIPv6         November 2014
+
+
+   Fast Binding ACK (FBack) message.  From receiving the FBack message,
+   the MN will learn about the multicast support for each group in the
+   new access network.  If some groups or multicast service models are
+   not supported, it can decide to take actions to overcome a missing
+   service (e.g., by tunneling).  Note that the proactive multicast
+   context transfer may proceed successfully, even if the MN misses the
+   FBack message on the previous link.
+
+            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 FMIPv6
+
+   The flow diagram for reactive mode is depicted in Figure 3.  After
+   attaching to the new access link and performing an Unsolicited
+   Neighbor Advertisement (UNA), the MN issues an FBU that the NAR
+   forwards to the PAR without processing.  At this time, the MN is able
+   to rejoin all subscribed multicast groups without relying on AR
+   assistance.  Nevertheless, multicast context options are exchanged in
+   the HI/HAck dialog to facilitate intermediate forwarding of the
+   requested multicast flows.  The multicast traffic could arrive from
+   an MN subscription at the same time that the NAR receives the HI
+   message.  Such multicast flows may be transparently excluded from
+
+
+
+Schmidt, et al.               Experimental                     [Page 10]
+
+RFC 7411              Multicast for FMIPv6/PFMIPv6         November 2014
+
+
+   forwarding by setting an appropriate Multicast Acknowledgement
+   Option.  In either case, to avoid duplication, the NAR MUST ensure
+   that not more than one flow of the same group is forwarded to the MN.
+
+             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 FMIPv6
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Schmidt, et al.               Experimental                     [Page 11]
+
+RFC 7411              Multicast for FMIPv6/PFMIPv6         November 2014
+
+
+3.3.  Protocol Operations Specific to PFMIPv6
+
+   In a proxy mobile IPv6 environment, the MN remains agnostic of
+   network layer changes, and fast handover procedures are operated by
+   the access routers or MAGs to which MNs are connected via node-
+   specific point-to-point links.  The handover initiation, or the re-
+   association, is managed by the access networks.  Consequently, access
+   routers need to be aware of multicast membership state at the Mobile
+   Node.  There are two ways to obtain the multicast membership of an
+   MN.
+
+   o  MAGs may perform explicit tracking (see [RFC4605] and [RFC6224])
+      or extract membership status from forwarding states at node-
+      specific links.
+
+   o  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 will learn about the upcoming movement
+   of the Mobile Node, including its new Access Point Identifier (New AP
+   ID).  Without explicit tracking, it will immediately submit a general
+   MLD query and receive MLD reports indicating the multicast address
+   listening state of the subscribed group(s).  As displayed in
+   Figure 4, it will initiate binding and context transfer with the NMAG
+   by issuing a HI message that is augmented by multicast contexts in
+   the mobility options defined in Section 5.3.  NMAG will extract
+   multicast context information and act as described in Section 3.1.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Schmidt, et al.               Experimental                     [Page 12]
+
+RFC 7411              Multicast for FMIPv6/PFMIPv6         November 2014
+
+
+                                               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 PFMIPv6
+
+   In reactive mode, the NMAG will learn the attachment of the MN to the
+   N-AN and establish connectivity using the PMIPv6 protocol operations.
+   However, it will have no knowledge about multicast state at the MN.
+   Triggered by an MN attachment, the NMAG will send a general MLD query
+   and thereafter join 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 those group identifiers it requests to be
+
+
+
+Schmidt, et al.               Experimental                     [Page 13]
+
+RFC 7411              Multicast for FMIPv6/PFMIPv6         November 2014
+
+
+   forwarded from PMAG.  Using the identical syntax in its Multicast
+   Mobility Option headers, as defined in Section 5.4, the PMAG
+   acknowledges the set of requested groups in a HAck answer, indicating
+   the group(s) it is willing to forward.  The corresponding call flow
+   is displayed 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 PFMIPv6
+
+
+
+
+
+
+
+
+
+
+Schmidt, et al.               Experimental                     [Page 14]
+
+RFC 7411              Multicast for FMIPv6/PFMIPv6         November 2014
+
+
+4.  Protocol Details
+
+   This section provides a normative definition of the protocol
+   operations.
+
+4.1.  Protocol Operations Specific to FMIPv6
+
+4.1.1.  Operations of the Mobile Node
+
+   A Mobile Node willing to manage multicast traffic by fast handover
+   operations MUST transfer its MLD listener state records within fast
+   handover negotiations.
+
+   When sensing 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) prior to signaling with PAR.
+
+   The MN will receive the Multicast Acknowledgement Option(s) as a part
+   of the Fast Binding Acknowledge (FBack) (see Section 5.4) and learn
+   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.  Beyond standard FMIPv6
+   signaling, no multicast-specific operation is required by the MN when
+   reattaching in the new network.
+
+   In reactive mode, the MN MUST append the identical Multicast Mobility
+   Option to the FBU sent after its reconnect.  In response, it will
+   learn about the Multicast Acknowledgement Option(s) from the FBack
+   and expect corresponding multicast data.  Concurrently, 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 informs the MNs about the capability of the PAR to
+   process and exchange Multicast Mobility Options during fast handover
+   operations.
+
+   In predictive mode, a PAR will receive the multicast listener state
+   of an MN prior to handover from the Multicast Mobility Option
+   appended to the FBU.  It forwards these records to the NAR within HI
+   messages and will expect Multicast Acknowledgement Option(s) in a
+   HAck, which is itself returned to the MN as an appendix to the FBack.
+   In performing the multicast context exchange, the PAR is instructed
+
+
+
+Schmidt, et al.               Experimental                     [Page 15]
+
+RFC 7411              Multicast for FMIPv6/PFMIPv6         November 2014
+
+
+   to include the PAR-to-NAR tunnel obtained from unicast handover
+   management in its multicast downstream interfaces and awaits
+   reception of 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
+   (e.g., due to administrative configurations or load conditions).
+
+   In reactive mode, the PAR will receive the FBU augmented by the
+   Multicast Mobility Option from the new network but continues 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 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 (i.e., MLD querying, explicit tracking).
+
+4.1.3.  Operations of the New Access Router
+
+   A NAR that supports multicast advertises that support by setting the
+   'M' bit in PrRtAdv as specified in Section 5.1 of this document.
+   This indicator exclusively serves the purpose of informing MNs about
+   the capability of the NAR to process and exchange Multicast Mobility
+   Options during fast handover operations.
+
+   In predictive mode, a NAR will receive the multicast listener state
+   of an expected MN from the Multicast Mobility Option appended to the
+   HI message.  It will extract the multicast group membership records
+   from the message and match the request subscription with its
+   multicast service offer.  Further on, it will join the requested
+   groups using a downstream loopback interface.  This will lead to
+   suitable regular subscriptions to a native multicast upstream
+   interface without additional forwarding.  Concurrently, the NAR
+   builds a Multicast Acknowledgement Option(s) (see Section 5.4)
+   listing the set of groups that are unsupported on the new access link
+   and returns this list within a HAck.  As soon as there is an
+   operational bidirectional tunnel from the PAR to NAR, the NAR joins
+   the groups requested by the MN, which are then forwarded by the PAR
+   using the tunnel link.
+
+   In reactive mode, the NAR will learn about the multicast listener
+   state of a new MN from the Multicast Mobility Option appended to each
+   HI message after the MN has already performed local subscriptions of
+
+
+
+Schmidt, et al.               Experimental                     [Page 16]
+
+RFC 7411              Multicast for FMIPv6/PFMIPv6         November 2014
+
+
+   the multicast service.  Thus, the NAR solely determines the
+   intersection of requested and supported groups and issues a join
+   request for each group forwarding this on the PAR-NAR tunnel
+   interface.
+
+   In both modes, the NAR MUST send a LEAVE message to the tunnel when
+   it is no longer needed to forward a group, e.g., after arrival of
+   native multicast traffic or termination of a group membership from
+   the MN.  Although the message can be delayed, immediately sending the
+   LEAVE message eliminates the need for the PAR and NAR to process
+   traffic that is not to be forwarded.
+
+4.1.4.  Buffering Considerations
+
+   Multicast packets may be lost during handover.  For example, in
+   predictive mode, as illustrated by Figure 2, packets may be lost
+   while the MN is -- already or still -- detached from the networks,
+   even though they are forwarded to the NAR.  In reactive mode as
+   illustrated by Figure 3, the situation may be worse, since there will
+   be a delay before joining the multicast group after the MN reattaches
+   to the NAR.  Multicast packets cannot be delivered during this time.
+   Buffering the multicast packets at the PAR can reduce multicast
+   packet loss but may then increase resource consumption and delay in
+   packet transmission.  Implementors should balance the different
+   requirements in the context of predominant application demands (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 willing to participate in multicast traffic will join,
+   maintain, and leave groups as if located in the fixed Internet.  It
+   will cooperate in handover indication as specified in [RFC5949] and
+   required by its access link-layer technology.  No multicast-specific
+   mobility actions nor implementations are required at the MN in a
+   PMIPv6 domain.
+
+4.2.2.  Operations of the Previous MAG
+
+   A MAG receiving 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
+   performs explicit membership tracking on that link.  After knowledge
+   of the multicast subscriptions of the MN is acquired, the PMAG builds
+   a Multicast Mobility Option, as described in Section 5.3, that
+   contains the MLD and IGMP multicast listener state.  If not empty,
+   this Mobility Option is appended to the regular fast handover HI
+
+
+
+Schmidt, et al.               Experimental                     [Page 17]
+
+RFC 7411              Multicast for FMIPv6/PFMIPv6         November 2014
+
+
+   messages.  In the case when a unicast HI message is submitted prior
+   to 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) with a HAck message (see Section 5.4) and the bidirectional
+   tunnel with the NMAG is created.  After the HAck message is received,
+   the PMAG adds the tunnel to its downstream interfaces in the
+   multicast forwarding database.  For those groups reported in the
+   Multicast Acknowledgement Option(s), i.e., not supported in the new
+   access network, the PMAG normally takes appropriate actions (e.g.,
+   forwarding and termination) according to the network policy.  It
+   SHOULD start forwarding multicast traffic down the tunnel interface
+   for the groups indicated in the multicast listener reports received
+   from NMAG.  However, it MAY deny forwarding some or all groups
+   included in the multicast listener reports (e.g., due to
+   administrative configurations or load conditions).
+
+   After the departure of the MN and on the reception of a LEAVE
+   message, it is RECOMMENDED that the PMAG terminates forwarding of the
+   specified groups and updates 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 receiving a HI message with the Multicast Mobility Option for a
+   currently attached node follows the reactive fast handover mode as a
+   PMAG.  It will return a Multicast Acknowledgement Option(s) (see
+   Section 5.4) within a HAck message listing the groups for which it
+   does not provide forwarding support to the NMAG.  It will add the
+   bidirectional tunnel with NMAG to its downstream interfaces and will
+   start forwarding multicast traffic for the groups listed in the
+   multicast listener report messages from the NMAG.  On reception of a
+   LEAVE message for a group, the PMAG terminates forwarding for the
+   specific group and updates its multicast forwarding database.
+   According to 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 will interpret the departure of the MN as a
+   multicast LEAVE message of the MN and react according to the
+   signaling scheme deployed in the access network (i.e., MLD querying
+   and explicit tracking).
+
+
+
+
+
+
+
+
+Schmidt, et al.               Experimental                     [Page 18]
+
+RFC 7411              Multicast for FMIPv6/PFMIPv6         November 2014
+
+
+4.2.3.  Operations of the New MAG
+
+   A MAG receiving a HI message with a Multicast Mobility Option for a
+   currently unattached node follows the same predictive fast handover
+   mode as an NMAG.  It will decide the multicast groups to be forwarded
+   from the PMAG and build a Multicast Acknowledgement Option (see
+   Section 5.4) that enumerates only unwanted groups.  This Mobility
+   Option is appended to the regular fast handover HAck messages or, in
+   the case of a unicast HAck message being submitted prior to multicast
+   state acknowledgement, sent in an additional HAck message to the
+   PMAG.  Immediately thereafter, 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.  As soon as the bidirectional tunnel with PMAG is
+   established, the NMAG additionally joins those groups on the tunnel
+   interface requested to be forwarded from the PMAG.
+
+   A MAG experiencing a connection request for an MN without prior
+   reception of a 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 multicast subscriptions of the newly arrived MN.  Using
+   standard multicast operations, the NMAG joins groups not currently
+   forwarded using its regular multicast upstream interface.
+   Concurrently, it selects groups for forwarding from PMAG and builds a
+   Multicast Mobility Option, as described in Section 5.3, that contains
+   the multicast listener state.  If not empty, this Mobility Option is
+   appended to the regular fast handover HI messages with the F flag set
+   or, in the case of unicast HI message being submitted prior to
+   multicast state detection, sent in an additional HI message to the
+   PMAG.  Upon reception of the Multicast Acknowledgement Option and
+   establishment of the bidirectional tunnel, the NMAG additionally
+   joins the set of groups on the tunnel interface that it wishes to
+   receive by forwarding from the PMAG.  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 group membership of the MN terminates.
+   Although the message can be delayed, immediately sending the LEAVE
+   message eliminates the need for PAR and NAR to process traffic that
+   is not to be forwarded.
+
+
+
+
+
+
+Schmidt, et al.               Experimental                     [Page 19]
+
+RFC 7411              Multicast for FMIPv6/PFMIPv6         November 2014
+
+
+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 is worth mentioning the scenarios of a dual-stack IPv4/IPv6 access
+   network and the use of Generic Routing Encapsulation (GRE) tunneling
+   as specified in [RFC5845].  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)
+
+   This document updates the Proxy Router Advertisements (PrRtAdv)
+   message format defined in Section 6.1.2 of [RFC5568].  The update
+   assigns the first bit of the Reserved field to carry the 'M' bit, as
+   defined in Figure 6.  An FMIPv6 AR indicates support for multicast by
+   setting the 'M' bit to a value of 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) Message
+
+
+
+
+Schmidt, et al.               Experimental                     [Page 20]
+
+RFC 7411              Multicast for FMIPv6/PFMIPv6         November 2014
+
+
+   This document updates the Reserved field to include the 'M' bit.  It
+   is specified as follows.
+
+      M = 1 indicates that the specifications of this document apply.
+
+      M = 0 indicates that the behavior during fast handover proceeds
+      according to [RFC5568].
+
+   The default value (0) of this bit indicates 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, as defined in [RFC6275].  Mobility Headers can carry variable
+   Mobility Options.
+
+   The multicast listener context of an MN is transferred in fast
+   handover operations from PAR/PMAG to NAR/NMAG within a new Multicast
+   Mobility Option and MUST be acknowledged by a corresponding Multicast
+   Acknowledgement Option.  Depending on the specific handover scenario
+   and protocol in use, the corresponding option is included within the
+   mobility option list of HI/HAck only (PFMIPv6) or of FBU/FBack/HI/
+   HAck (FMIPv6).
+
+5.3.  New Multicast Mobility Option
+
+   This section defines the Multicast Mobility Option.  It contains the
+   current listener state record of the MN obtained from the MLD
+   Multicast Listener Report message and has the format displayed in
+   Figure 7.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Schmidt, et al.               Experimental                     [Page 21]
+
+RFC 7411              Multicast for FMIPv6/PFMIPv6         November 2014
+
+
+        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 Option
+
+   Type: 60
+
+   Length: 8-bit unsigned integer.  The length of this option in 32-bit
+   words, not including the Type, Length, Option-Code, and Reserved
+   fields.
+
+   Option-Code:
+
+      1: IGMPv3 Payload Type
+
+      2: MLDv2 Payload Type
+
+      3: IGMPv3 Payload Type from IGMPv2 Compatibility Mode
+
+      4: MLDv2 Payload Type from MLDv1 Compatibility Mode
+
+   Reserved: MUST be set to zero by the sender and MUST be ignored by
+   the receiver.
+
+   MLD or IGMP Report Payload: This field is composed of the Membership
+   Report message after stripping its ICMP header.  This Report Payload
+   always contains an integer number of multicast records.
+   Corresponding message formats are defined for MLDv2 in [RFC3810] and
+   for IGMPv3 in [RFC3376].  This field MUST always contain the first
+   header line (Reserved field and No of Mcast Address Records).
+
+
+
+
+
+
+
+
+Schmidt, et al.               Experimental                     [Page 22]
+
+RFC 7411              Multicast for FMIPv6/PFMIPv6         November 2014
+
+
+   Figure 8 shows the Report Payload for MLDv2 (see Section 5.2 of
+   [RFC3810] for the definition of Multicast Address Records).  When
+   IGMPv3 is used, the payload format is defined according to IGMPv3
+   Group Records (see Section 4.2 of [RFC3376] for the definition of
+   Group Records).
+
+        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 Payload
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Schmidt, et al.               Experimental                     [Page 23]
+
+RFC 7411              Multicast for FMIPv6/PFMIPv6         November 2014
+
+
+5.4.  New Multicast Acknowledgement Option
+
+   The Multicast Acknowledgement Option reports the status of the
+   context transfer and contains the list of state records that could
+   not be successfully transferred to the next access network.  It has
+   the format displayed in 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 Option
+
+   Type: 61
+
+   Length: 8-bit unsigned integer.  The length of this option in 32-bit
+   words, not including the Type, Length, Option-Code, and Status
+   fields.
+
+   Option-Code: 0
+
+   Status:
+
+      1: Report Payload type unsupported
+
+      2: Requested group service unsupported
+
+      3: Requested group service administratively prohibited
+
+   MLD or IGMP Unsupported Report Payload: This field is syntactically
+   identical to the MLD and IGMP Report Payload field described in
+   Section 5.3 but is only composed of those Multicast Address Records
+   that are not supported or prohibited in the new access network.  This
+   field MUST always contain the first header line (Reserved field and
+   No of Mcast Address Records) but MUST NOT contain any Mcast Address
+   Records if the status code equals 1.
+
+
+
+Schmidt, et al.               Experimental                     [Page 24]
+
+RFC 7411              Multicast for FMIPv6/PFMIPv6         November 2014
+
+
+   Note that group subscriptions to specific sources may be rejected at
+   the destination network; thus, the composition of multicast address
+   records may differ from initial requests within an MLD or IGMP Report
+   Payload option.
+
+5.5.  Length Considerations: Number of Records and Addresses
+
+   Mobility Header messages exchanged in HI/HAck and FBU/FBack dialogs
+   impose length restrictions on multicast context records due to the
+   8-bit Length field.  The maximal payload length available in FBU/
+   FBack messages is 4 octets (Mobility Option header line) + 1024
+   octets (MLD Report Payload).  For example, not more than 51 Multicast
+   Address Records of minimal length (without source states) may be
+   exchanged in one message pair.  In typical handover scenarios, this
+   number reduces further according to unicast context and Binding
+   Authorization data.  A larger number of MLD reports that exceeds the
+   available payload size MAY be sent within multiple HI/HAck or FBU/
+   FBack message pairs.  In PFMIPv6, context information can be
+   fragmented over several HI/HAck messages.  However, a single MLDv2
+   Report Payload MUST NOT be fragmented.  Hence, for a single Multicast
+   Address Record, the number of source addresses (S,.) is limited to
+   62.
+
+5.6.  MLD and IGMP Compatibility Requirements
+
+   Access routers (MAGs) MUST support MLDv2 and IGMPv3.  To enable
+   multicast service for MLDv1 and IGMPv2 listeners, the routers MUST
+   follow the interoperability rules defined in [RFC3810] and [RFC3376]
+   and appropriately set the Multicast Address Compatibility Mode.
+
+   When the Multicast Address Compatibility Mode is MLDv1 or IGMPv2, a
+   router internally translates the subsequent MLDv1 and IGMPv2 messages
+   for that multicast address to their MLDv2 and IGMPv3 equivalents and
+   uses these messages in the context transfer.  The current state of
+   Compatibility Mode is translated into the code of the Multicast
+   Mobility Option, as defined in Section 5.3.  A NAR (NMAG) receiving a
+   Multicast Mobility Option during handover will switch to the lowest
+   level of MLD and IGMP Compatibility Mode that it learned from its
+   previous and new option values.  This minimal compatibility agreement
+   is used to allow for continued operation.
+
+
+
+
+
+
+
+
+
+
+
+Schmidt, et al.               Experimental                     [Page 25]
+
+RFC 7411              Multicast for FMIPv6/PFMIPv6         November 2014
+
+
+6.  Security Considerations
+
+   Security vulnerabilities that exceed issues discussed in the base
+   protocols mentioned in this document ([RFC5568], [RFC5949],
+   [RFC3810], and [RFC3376]) are identified as follows.
+
+   Multicast context transfer at predictive handovers implements group
+   states at remote access routers and may lead to group subscriptions
+   without further validation of the multicast service requests.
+   Thereby, a NAR (NMAG) is requested to cooperate in potentially
+   complex multicast rerouting and may receive large volumes of traffic.
+   Malicious or inadvertent multicast context transfers may result in a
+   significant burden of route establishment and traffic management onto
+   the backbone infrastructure and the access router itself.  Rapid
+   rerouting or traffic overload can be mitigated by a rate control at
+   the AR that restricts the frequency of traffic redirects and the
+   total number of subscriptions.  In addition, the wireless access
+   network remains protected from multicast data injection until the
+   requesting MN attaches to the new location.
+
+7.  IANA Considerations
+
+   This document defines two new mobility options that have been
+   allocated from the "Mobility Options" registry at
+   <http://www.iana.org/assignments/mobility-parameters>:
+
+      60 Multicast Mobility Option, described in Section 5.3
+
+      61 Multicast Acknowledgement Option, described in Section 5.4
+
+8.  References
+
+8.1.  Normative References
+
+   [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>.
+
+
+
+Schmidt, et al.               Experimental                     [Page 26]
+
+RFC 7411              Multicast for FMIPv6/PFMIPv6         November 2014
+
+
+   [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
+
+   [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>.
+
+
+
+
+Schmidt, et al.               Experimental                     [Page 27]
+
+RFC 7411              Multicast for FMIPv6/PFMIPv6         November 2014
+
+
+   [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>.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Schmidt, et al.               Experimental                     [Page 28]
+
+RFC 7411              Multicast for FMIPv6/PFMIPv6         November 2014
+
+
+Appendix A.  Considerations for Mobile Multicast Sources
+
+   This document only specifies protocol operations for fast handovers
+   for mobile listeners.  In this appendix, we briefly discuss aspects
+   of supporting mobile multicast sources.
+
+   In a multicast-enabled Proxy Mobile IPv6 domain, multicast sender
+   support is likely to be enabled by any one of the mechanisms
+   described in [RFC7287].  In this case, multicast data packets from an
+   MN are transparently forwarded either to its associated LMA or to a
+   multicast-enabled access network.  In all cases, a mobile source can
+   continue to transmit multicast packets after a handover from PMAG to
+   NMAG without additional management operations.  Packets (with a
+   persistent source address) will continue to flow via the LMA or the
+   access network into the previously established distribution system.
+
+   In contrast, an MN will change its Care-of Address while performing
+   FMIPv6 handovers.  Even though MNs are enabled to send packets via
+   the reverse NAR-PAR tunnel using their previous Care-of Address for a
+   limited time, multicast sender support in such a Mobile IPv6 regime
+   will most likely follow one of the basic mechanisms described in
+   Section 5.1 of [RFC5757]: (1) bidirectional tunneling, (2) remote
+   subscription, or (3) agent-based solutions.  A solution for multicast
+   senders that is homogeneously deployed throughout the mobile access
+   network can support seamless services during fast handovers, the
+   details of which are beyond the scope of this document.
+
+Acknowledgments
+
+   Protocol extensions to support multicast in Fast Mobile IPv6 have
+   been loosely discussed for several years.  Repeated attempts have
+   been made to define 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 many fruitful discussions in the MobOpts
+   research group.  We would like to thank all active members for
+   constructive thoughts and contributions on the subject of multicast
+   mobility.  The MULTIMOB working group has provided continuous
+   feedback during the evolution of this work.  Comments, discussions,
+   and reviewing remarks have been contributed by (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 has been provided by the German Federal Ministry of Education
+   and Research within the projects Mindstone, SKIMS, and SAFEST.  This
+   is gratefully acknowledged.
+
+
+
+Schmidt, et al.               Experimental                     [Page 29]
+
+RFC 7411              Multicast for FMIPv6/PFMIPv6         November 2014
+
+
+Authors' Addresses
+
+   Thomas C. Schmidt (editor)
+   HAW Hamburg
+   Dept. Informatik
+   Berliner Tor 7
+   Hamburg  D-20099
+   Germany
+
+   EMail: t.schmidt@haw-hamburg.de
+
+
+   Matthias Waehlisch
+   link-lab & FU Berlin
+   Hoenower Str. 35
+   Berlin  D-10318
+   Germany
+
+   EMail: mw@link-lab.net
+
+
+   Rajeev Koodli
+   Intel
+   3600 Juliette Lane
+   Santa Clara,  CA 95054
+   United States
+
+   EMail: rajeev.koodli@intel.com
+
+
+   Godred Fairhurst
+   University of Aberdeen
+   School of Engineering
+   Aberdeen  AB24 3UE
+   United Kingdom
+
+   EMail: gorry@erg.abdn.ac.uk
+
+
+   Dapeng Liu
+   China Mobile
+
+   Phone: +86-123-456-7890
+   EMail: liudapeng@chinamobile.com
+
+
+
+
+
+
+
+Schmidt, et al.               Experimental                     [Page 30]
+