doc: Add RFC documents

1 files changed, 1067 insertions, 0 deletions

diff --git a/doc/rfc/rfc6224.txt b/doc/rfc/rfc6224.txt
new file mode 100644
index 0000000..4006851
--- /dev/null
+++ b/doc/rfc/rfc6224.txt
@@ -0,0 +1,1067 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                        T. Schmidt
+Request for Comments: 6224                                   HAW Hamburg
+Category: Informational                                     M. Waehlisch
+ISSN: 2070-1721                                     link-lab & FU Berlin
+                                                             S. Krishnan
+                                                                Ericsson
+                                                              April 2011
+
+
+             Base Deployment for Multicast Listener Support
+                 in Proxy Mobile IPv6 (PMIPv6) Domains
+
+Abstract
+
+   This document describes deployment options for activating multicast
+   listener functions in Proxy Mobile IPv6 domains without modifying
+   mobility and multicast protocol standards.  Similar to home agents in
+   Mobile IPv6, Local Mobility Anchors of Proxy Mobile IPv6 serve as
+   multicast subscription anchor points, while Mobile Access Gateways
+   provide Multicast Listener Discovery (MLD) proxy functions.  In this
+   scenario, mobile nodes remain agnostic of multicast mobility
+   operations.  Support for mobile multicast senders is outside the
+   scope of this document.
+
+Status of This Memo
+
+   This document is not an Internet Standards Track specification; it is
+   published for informational purposes.
+
+   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/rfc6224.
+
+
+
+
+
+
+
+
+
+
+
+
+Schmidt, et al.               Informational                     [Page 1]
+
+RFC 6224              Multicast Listeners in PMIPv6           April 2011
+
+
+Copyright Notice
+
+   Copyright (c) 2011 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
+   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
+   3.  Overview . . . . . . . . . . . . . . . . . . . . . . . . . . .  4
+   4.  Deployment Details . . . . . . . . . . . . . . . . . . . . . .  8
+     4.1.  Operations of the Mobile Node  . . . . . . . . . . . . . .  8
+     4.2.  Operations of the Mobile Access Gateway  . . . . . . . . .  8
+     4.3.  Operations of the Local Mobility Anchor  . . . . . . . . . 10
+     4.4.  IPv4 Support . . . . . . . . . . . . . . . . . . . . . . . 10
+     4.5.  Multihoming Support  . . . . . . . . . . . . . . . . . . . 11
+     4.6.  Multicast Availability throughout the Access Network . . . 12
+     4.7.  A Note on Explicit Tracking  . . . . . . . . . . . . . . . 12
+   5.  Message Source and Destination Address . . . . . . . . . . . . 13
+     5.1.  Query  . . . . . . . . . . . . . . . . . . . . . . . . . . 13
+     5.2.  Report/Done  . . . . . . . . . . . . . . . . . . . . . . . 13
+   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 13
+   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
+   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
+     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 14
+     8.2.  Informative References . . . . . . . . . . . . . . . . . . 15
+   Appendix A.  Initial MLD Queries on Upcoming Links . . . . . . . . 16
+   Appendix B.  State of IGMP/MLD Proxy Implementations . . . . . . . 16
+   Appendix C.  Comparative Evaluation of Different Approaches  . . . 17
+
+
+
+
+
+
+
+
+
+
+
+
+Schmidt, et al.               Informational                     [Page 2]
+
+RFC 6224              Multicast Listeners in PMIPv6           April 2011
+
+
+1.  Introduction
+
+   Proxy Mobile IPv6 (PMIPv6) [RFC5213] extends Mobile IPv6 (MIPv6)
+   [RFC3775] by network-based management functions that enable IP
+   mobility for a host without requiring its participation in any
+   mobility-related signaling.  Additional network entities, called the
+   Local Mobility Anchor (LMA) and Mobile Access Gateways (MAGs), are
+   responsible for managing IP mobility on behalf of the mobile node
+   (MN).
+
+   With these entities in place, the mobile node experiences an
+   exceptional access topology towards the static Internet in the sense
+   that the MAG introduces a routing hop in situations where the LMA
+   architecturally acts as the next hop (or designated) router for the
+   MN.  In the particular case of multicast communication, group
+   membership management, as signaled by the Multicast Listener
+   Discovery (MLD) protocol [RFC3810] [RFC2710], requires dedicated
+   treatment at the network side.
+
+   Multicast routing functions need to be placed carefully within the
+   PMIPv6 domain in order to augment unicast transmission with group
+   communication services.  [RFC5213] does not explicitly address
+   multicast communication.  Bidirectional home tunneling, the minimal
+   multicast support arranged by MIPv6, cannot be directly transferred
+   to network-based management scenarios, since a mobility-unaware node
+   will not initiate such a tunnel after movement.  Consequently, even
+   minimal multicast listener support in PMIPv6 domains requires an
+   explicit deployment of additional functions.
+
+   This document describes options for deploying multicast listener
+   functions in Proxy Mobile IPv6 domains without modifying mobility and
+   multicast protocol standards.  Similar to home agents in Mobile IPv6,
+   PMIPv6 Local Mobility Anchors serve as multicast subscription anchor
+   points, while Mobile Access Gateways provide MLD proxy functions.  In
+   this scenario, mobile nodes remain agnostic of multicast mobility
+   operations.  This document does not address specific optimizations
+   and efficiency improvements of multicast routing for network-based
+   mobility discussed in [RFC5757], as such solutions would require
+   changes to the base PMIPv6 protocol [RFC5213].  Support for mobile
+   multicast senders is also outside the scope of this document.
+
+2.  Terminology
+
+   This document uses the terminology as defined for the mobility
+   protocols [RFC3775], [RFC5213], and [RFC5844], as well as the
+   multicast edge related protocols [RFC3376], [RFC3810], and [RFC4605].
+
+
+
+
+
+Schmidt, et al.               Informational                     [Page 3]
+
+RFC 6224              Multicast Listeners in PMIPv6           April 2011
+
+
+3.  Overview
+
+   The reference scenario for multicast deployment in Proxy Mobile IPv6
+   domains is illustrated in Figure 1.  Below, LMAA and MN-HNP are the
+   LMA Address and Mobile Node's Home Network Prefix as defined in
+   [RFC5213].
+
+                       +-------------+
+                       | Content     |
+                       | Source      |
+                       +-------------+
+                              |
+                     ***  ***  ***  ***
+                    *   **   **   **   *
+                   *                    *
+                    *  Fixed Internet  *
+                   *                    *
+                    *   **   **   **   *
+                     ***  ***  ***  ***
+                      /            \
+                  +----+         +----+
+                  |LMA1|         |LMA2|                 Multicast Anchor
+                  +----+         +----+
+             LMAA1  |              |  LMAA2
+                    |              |
+                    \\           //\\
+                     \\         //  \\
+                      \\       //    \\                 Unicast Tunnel
+                       \\     //      \\
+                        \\   //        \\
+                         \\ //          \\
+               Proxy-CoA1 ||            ||  Proxy-CoA2
+                       +----+          +----+
+                       |MAG1|          |MAG2|           MLD Proxy
+                       +----+          +----+
+                        |  |             |
+                MN-HNP1 |  | MN-HNP2     | MN-HNP3
+                       MN1 MN2          MN3
+
+      Figure 1: Reference Network for Multicast Deployment in PMIPv6
+
+   An MN in a PMIPv6 domain will decide on multicast group membership
+   management completely independent of its current mobility conditions.
+   It will submit MLD Report and Done messages, based on application
+   triggers, using its link-local source address and multicast
+   destination addresses according to [RFC3810] or [RFC2710].  These
+
+
+
+
+
+Schmidt, et al.               Informational                     [Page 4]
+
+RFC 6224              Multicast Listeners in PMIPv6           April 2011
+
+
+   link-local signaling messages will arrive at the currently active MAG
+   via one of its downstream local (wireless) links.  A multicast-
+   unaware MAG would simply discard these MLD messages.
+
+   To facilitate multicast in a PMIPv6 domain, an MLD proxy function
+   [RFC4605] needs to be deployed on the MAG that selects the tunnel
+   interface corresponding to the MN's LMA for its upstream interface
+   (cf., Section 6 of [RFC5213]).  Thereby, each MAG-to-LMA tunnel
+   interface defines an MLD proxy domain at the MAG, and it contains all
+   downstream links to MNs that share this specific LMA.  According to
+   standard proxy operations, MLD Report messages will be aggregated and
+   then forwarded up the tunnel interface to the MN's corresponding LMA.
+
+   Serving as the designated multicast router or an additional MLD
+   proxy, the LMA will transpose any MLD message from a MAG into the
+   multicast routing infrastructure.  Correspondingly, the LMA will
+   create appropriate multicast forwarding states at its tunnel
+   interface.  Traffic of the subscribed groups will arrive at the LMA,
+   and the LMA will forward this traffic according to its group/source
+   states.  In addition, the LMA will act as an MLD querier, seeing its
+   downstream tunnel interfaces as multicast-enabled links.
+
+   At the MAG, MLD queries and multicast data will arrive on the
+   (tunnel) interface that is assigned to a group of access links as
+   identified by its Binding Update List (cf., Section 6.1 of
+   [RFC5213]).  As specified for MLD proxies, the MAG will forward
+   multicast traffic and initiate related signaling down the appropriate
+   access links to the MNs.  Hence, all multicast-related signaling and
+   the data traffic will transparently flow from the LMA to the MN on an
+   LMA-specific tree, which is shared among the multicast sources.
+
+   In case of a handover, the MN (unaware of IP mobility) will not send
+   unsolicited MLD reports.  Instead, the MAG is required to maintain
+   group memberships in the following way.  On observing a new MN on a
+   downstream access link, the MAG sends a MLD General Query.  Based on
+   its outcome and the multicast group states previously maintained at
+   the MAG, a corresponding Report will be sent to the LMA aggregating
+   group membership states according to the proxy function.  Additional
+   Reports can be omitted when the previously established multicast
+   forwarding states at the new MAG already cover the subscriptions of
+   the MN.
+
+   In summary, the following steps are executed on handover:
+
+   1.  The MAG-MN link comes up and the MAG discovers the new MN.
+
+   2.  Unicast address configuration and PMIPv6 binding are performed
+       after the MAG determines the corresponding LMA.
+
+
+
+Schmidt, et al.               Informational                     [Page 5]
+
+RFC 6224              Multicast Listeners in PMIPv6           April 2011
+
+
+   3.  Following IPv6 address configuration, the MAG should send an
+       (early) MLD General Query to the new downstream link as part of
+       its standard multicast-enabled router operations.
+
+   4.  The MAG should determine whether the MN is admissible to
+       multicast services; if it's not, then stop here.
+
+   5.  The MAG adds the new downstream link to the MLD proxy instance
+       with up-link to the corresponding LMA.
+
+   6.  The corresponding proxy instance triggers an MLD General Query on
+       the new downstream link.
+
+   7.  The MN Membership Reports arrive at the MAG, in response either
+       to the early query or to the query sent by the proxy instance.
+
+   8.  The Proxy processes the MLD Report, updates states, and reports
+       upstream if necessary.
+
+   After Re-Binding, the LMA is not required to issue a MLD General
+   Query on the tunnel link to refresh forwarding states.  Multicast
+   state updates should be triggered by the MAG, which aggregates
+   subscriptions of all its MNs (see the call flow in Figure 2).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Schmidt, et al.               Informational                     [Page 6]
+
+RFC 6224              Multicast Listeners in PMIPv6           April 2011
+
+
+   MN1             MAG1             MN2             MAG2             LMA
+   |                |                |               |                |
+   |    Join(G)     |                |               |                |
+   +--------------->|                |               |                |
+   |                |     Join(G)    |               |                |
+   |                |<---------------+               |                |
+   |                |                |               |                |
+   |                |     Aggregated Join(G)         |                |
+   |                +================================================>|
+   |                |                |               |                |
+   |                |   Mcast Data   |               |                |
+   |                |<================================================+
+   |                |                |               |                |
+   |  Mcast Data    | Mcast Data     |               |                |
+   |<---------------+--------------->|               |                |
+   |                |                |               |                |
+   |           <  Movement of MN 2 to MAG2  &  PMIP Binding Update  > |
+   |                |                |               |                |
+   |                |                |--- Rtr Sol -->|                |
+   |                |                |<-- Rtr Adv ---|                |
+   |                |                |               |                |
+   |                |                |   MLD Query   |                |
+   |                |                |<--------------+                |
+   |                |                |               |                |
+   |                |                |   Join(G)     |                |
+   |                |                +-------------->|                |
+   |                |                |               Aggregated Join(G)
+   |                |                |               +===============>|
+   |                |                |               |                |
+   |                |   Mcast Data   |               |                |
+   |                |<================================================+
+   |                |                |               |   Mcast Data   |
+   |                |                |               |<===============+
+   |  Mcast Data    |                |               |                |
+   |<---------------+                |  Mcast Data   |                |
+   |                |                |<--------------+                |
+   |                |                |               |                |
+
+               Figure 2: Call Flow of Multicast-Enabled PMIP
+            with "MLD Membership Report" Abbreviated by "Join"
+
+   These multicast deployment considerations likewise apply for mobile
+   nodes that operate with their IPv4 stack enabled in a PMIPv6 domain.
+   PMIPv6 can provide IPv4 home address mobility support [RFC5844].
+   Such mobile nodes will use IGMP [RFC2236] [RFC3376] signaling for
+   multicast, which is handled by an IGMP proxy function at the MAG in
+   an analogous way.
+
+
+
+
+Schmidt, et al.               Informational                     [Page 7]
+
+RFC 6224              Multicast Listeners in PMIPv6           April 2011
+
+
+   Following these deployment steps, multicast management transparently
+   interoperates with PMIPv6.  It is worth noting that MNs -- while
+   being attached to the same MAG, but associated with different LMAs --
+   can subscribe to the same multicast group.  Thereby, data could be
+   distributed redundantly in the network and duplicate traffic could
+   arrive at a MAG.  Additionally, in a point-to-point wireless link
+   model, a MAG might be forced to transmit the same data over one
+   wireless domain to different MNs.  However, multicast traffic
+   arriving at one interface of the MN will always remain unique, i.e.,
+   the mobile multicast distribution system will never cause duplicate
+   packets arriving at an MN (see Appendix C for further
+   considerations).
+
+4.  Deployment Details
+
+   Multicast activation in a PMIPv6 domain requires to deploy general
+   multicast functions at PMIPv6 routers and to define their interaction
+   with the PMIPv6 protocol in the following way.
+
+4.1.  Operations of the Mobile Node
+
+   A mobile node willing to manage multicast traffic will join,
+   maintain, and leave groups as if located in the fixed Internet.  No
+   specific mobility actions nor implementations are required at the MN.
+
+4.2.  Operations of the Mobile Access Gateway
+
+   A Mobile Access Gateway is required to assist in MLD signaling and
+   data forwarding between the MNs that it serves and the corresponding
+   LMAs associated to each MN.  It therefore needs to implement an
+   instance of the MLD proxy function [RFC4605] for each upstream tunnel
+   interface that has been established with an LMA.  The MAG decides on
+   the mapping of downstream links to a proxy instance (and hence an
+   upstream link to an LMA) based on the regular Binding Update List as
+   maintained by PMIPv6 standard operations (cf., Section 6.1 of
+   [RFC5213]).  As links connecting MNs and MAGs change under mobility,
+   MLD proxies at MAGs must be able to dynamically add and remove
+   downstream interfaces in their configurations.
+
+   On the reception of MLD reports from an MN, the MAG must identify the
+   corresponding proxy instance from the incoming interface and perform
+   regular MLD proxy operations: it will insert/update/remove multicast
+   forwarding state on the incoming interface and will merge state
+   updates into the MLD proxy membership database.  It will then send an
+   aggregated Report via the upstream tunnel to the LMA when the
+   membership database (cf., Section 4.1 of [RFC4605]) changes.
+   Conversely, on the reception of MLD queries, the MAG proxy instance
+   will answer the Queries on behalf of all active downstream receivers
+
+
+
+Schmidt, et al.               Informational                     [Page 8]
+
+RFC 6224              Multicast Listeners in PMIPv6           April 2011
+
+
+   maintained in its membership database.  Queries sent by the LMA do
+   not force the MAG to trigger corresponding messages immediately
+   towards MNs.  Multicast traffic arriving at the MAG on an upstream
+   interface will be forwarded according to the group-specific or
+   source-specific forwarding states as acquired for each downstream
+   interface within the MLD proxy instance.  At this stage, it is
+   important to note that IGMP/MLD proxy implementations capable of
+   multiple instances are expected to closely follow the specifications
+   of Section 4.2 in [RFC4605], i.e., treat proxy instances in isolation
+   of each other while forwarding.  In providing isolated proxy
+   instances, the MAG will uniquely serve its downstream links with
+   exactly the data that belong to whatever group is subscribed on the
+   particular interface.
+
+   After a handover, the MAG will continue to manage upstream tunnels
+   and downstream interfaces as specified in the PMIPv6 specification.
+   It must dynamically associate new access links to proxy instances
+   that include the upstream connection to the corresponding LMA.  The
+   MAG detects the arrival of a new MN by receiving a router
+   solicitation message and by an upcoming link.  To learn about
+   multicast groups subscribed by a newly attaching MN, the MAG should
+   send a General Query to the MN's link.  Querying an upcoming
+   interface is a standard operation of MLD queriers (see Appendix A)
+   and is performed immediately after address configuration.  In
+   addition, an MLD query should be initiated by the proxy instance, as
+   soon as a new interface has been configured for downstream.  In case
+   the access link between MN and MAG goes down, interface-specific
+   multicast states change.  Both cases may alter the composition of the
+   membership database and this will trigger corresponding Reports
+   towards the LMA.  Note that the actual observable state depends on
+   the access link model in use.
+
+   An MN may be unable to answer MAG multicast membership queries due to
+   handover procedures, or its report may arrive before the MAG has
+   configured its link as the proxy downstream interface.  Such
+   occurrences are equivalent to a General Query loss.  To prevent
+   erroneous query timeouts at the MAG, MLD parameters should be
+   carefully adjusted to the mobility regime.  In particular, MLD timers
+   and the Robustness Variable (see Section 9 of [RFC3810]) should be
+   chosen to be compliant with the time scale of handover operations and
+   proxy configurations in the PMIPv6 domain.
+
+   In proceeding this way, the MAG is able to aggregate multicast
+   subscriptions for each of its MLD proxy instances.  However, this
+   deployment approach does not prevent multiple identical streams
+   arriving from different LMA upstream interfaces.  Furthermore, a
+   multipoint channel forwarding into the wireless domain is prevented
+   by the point-to-point link model in use.
+
+
+
+Schmidt, et al.               Informational                     [Page 9]
+
+RFC 6224              Multicast Listeners in PMIPv6           April 2011
+
+
+4.3.  Operations of the Local Mobility Anchor
+
+   For any MN, the Local Mobility Anchor acts as the persistent home
+   agent and at the same time as the default multicast querier for the
+   corresponding MAG.  It implements the function of the designated
+   multicast router or a further MLD proxy.  According to MLD reports
+   received from a MAG (on behalf of the MNs), the LMA establishes/
+   maintains/removes group-/source-specific multicast forwarding states
+   at its corresponding downstream tunnel interfaces.  At the same time,
+   it procures for aggregated multicast membership maintenance at its
+   upstream interface.  Based on the multicast-transparent operations of
+   the MAGs, the LMA treats its tunnel interfaces as multicast-enabled
+   downstream links, serving zero to many listening nodes.  Multicast
+   traffic arriving at the LMA is transparently forwarded according to
+   its multicast forwarding information base.
+
+   After a handover, the LMA will receive Binding De-Registrations and
+   Binding Lifetime Extensions that will cause a re-mapping of home
+   network prefix(es) to a new Proxy-CoA in its Binding Cache (see
+   Section 5.3 of [RFC5213]).  The multicast forwarding states require
+   updating, as well, if the MN within an MLD proxy domain is the only
+   receiver of a multicast group.  Two different cases need to be
+   considered:
+
+   1.  The mobile node is the only receiver of a group behind the
+       interface at which a De-Registration was received: the membership
+       database of the MAG changes, which will trigger a Report/Done
+       sent via the MAG-to-LMA interface to remove this group.  The LMA
+       thus terminates multicast forwarding.
+
+   2.  The mobile node is the only receiver of a group behind the
+       interface at which a Lifetime Extension was received: the
+       membership database of the MAG changes, which will trigger a
+       Report sent via the MAG-to-LMA interface to add this group.  The
+       LMA thus starts multicast distribution.
+
+   In proceeding this way, each LMA will provide transparent multicast
+   support for the group of MNs it serves.  It will perform traffic
+   aggregation at the MN-group level and will assure that multicast data
+   streams are uniquely forwarded per individual LMA-to-MAG tunnel.
+
+4.4.  IPv4 Support
+
+   An MN in a PMIPv6 domain may use an IPv4 address transparently for
+   communication as specified in [RFC5844].  For this purpose, 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
+
+
+
+Schmidt, et al.               Informational                    [Page 10]
+
+RFC 6224              Multicast Listeners in PMIPv6           April 2011
+
+
+   multicast support on the network side, an IGMP proxy function needs
+   to be deployed at MAGs in exactly the same way as for IPv6.
+   [RFC4605] defines IGMP proxy behavior in full agreement with IPv6/
+   MLD.  Thus, IPv4 support can be transparently provided following the
+   obvious deployment analogy.
+
+   For a dual-stack IPv4/IPv6 access network, the MAG proxy instances
+   should choose multicast signaling according to address configurations
+   on the link, but may submit IGMP and MLD queries in parallel, if
+   needed.  It should further be noted that the infrastructure cannot
+   identify two data streams as identical when distributed via an IPv4
+   and IPv6 multicast group.  Thus, duplicate data may be forwarded on a
+   heterogeneous network layer.
+
+   A particular note is worth giving the scenario of [RFC5845] in which
+   overlapping private address spaces of different operators can be
+   hosted in a PMIP domain by using Generic Routing Encapsulation (GRE)
+   with key identification.  This scenario implies that unicast
+   communication in the MAG-LMA tunnel can be individually identified
+   per MN by the GRE keys.  This scenario still does not impose any
+   special treatment of multicast communication for the following
+   reasons.
+
+   MLD/IGMP signaling between MNs and the MAG is on point-to-point links
+   (identical to unicast).  Aggregated MLD/IGMP signaling between the
+   MAG proxy instance and the LMA remains link-local between the routers
+   and independent of any individual MN.  So the MAG-proxy and the LMA
+   should not use GRE key identifiers, but plain GRE to exchange MLD
+   queries and reports.  Similarly, multicast traffic sent from an LMA
+   to MAGs proceeds as router-to-router forwarding according to the
+   multicast forwarding information base (MFIB) of the LMA and
+   independent of MN's unicast addresses, while the MAG proxy instance
+   distributes multicast data down the point-to-point links (interfaces)
+   according to its own MFIB, independent of MN's IP addresses.
+
+   It remains an open issue how communication proceeds in a multi-
+   operator scenario, i.e., from which network the LMA pulls multicast
+   traffic.  This could be any mobility Operator itself, or a third
+   party.  However, this backbone routing in general is out of scope of
+   the document, and most likely a matter of contracts.
+
+4.5.  Multihoming Support
+
+   An MN can connect to a PMIPv6 domain through multiple interfaces and
+   experience transparent unicast handovers at all interfaces (cf.,
+   Section 5.4 of [RFC5213]).  In such simultaneous access scenarios, it
+   can autonomously assign multicast channel subscriptions to individual
+   interfaces (see [RFC5757] for additional details).  While doing so,
+
+
+
+Schmidt, et al.               Informational                    [Page 11]
+
+RFC 6224              Multicast Listeners in PMIPv6           April 2011
+
+
+   multicast mobility operations described in this document will
+   transparently preserve the association of channels to interfaces in
+   the following way.
+
+   Multicast listener states are kept per interface in the MLD state
+   table.  An MN will answer to an MLD General Query received on a
+   specific (re-attaching) interface according to the specific
+   interface's state table.  Thereafter, multicast forwarding is resumed
+   for channels identical to those under subscription prior to handover.
+   Consequently, an MN in a PMIPv6 domain may use multiple interfaces to
+   facilitate load balancing or redundancy, but cannot follow a 'make-
+   before-break' approach to service continuation on handovers.
+
+4.6.  Multicast Availability throughout the Access Network
+
+   There may be deployment scenarios where multicast services are
+   available throughout the access network, independent of the PMIPv6
+   infrastructure.  Direct multicast access at MAGs may be supported
+   through native multicast routing within a flat access network that
+   includes a multicast router, via dedicated (tunnel or VPN) links
+   between MAGs and designated multicast routers, or by deploying
+   Automatic Multicast Tunneling (AMT) [AUTO-MULTICAST].
+
+   Multicast deployment can be simplified in these scenarios.  A single
+   proxy instance at MAGs with up-link to the multicast cloud, for
+   instance, could serve group communication purposes.  MAGs could
+   operate as general multicast routers or AMT gateways as well.
+
+   Common to these solutions is that mobility management is covered by
+   the dynamics of multicast routing, as initially foreseen in the
+   Remote Subscription approach, i.e., join via a local multicast router
+   as sketched in [RFC3775].  Care must be taken to avoid avalanche
+   problems or service disruptions due to tardy multicast routing
+   operations and to adapt to different link-layer technologies
+   [RFC5757].  The different possible approaches should be carefully
+   investigated beyond the initial sketch in Appendix C.  Such work is
+   beyond the scope of this document.
+
+4.7.  A Note on Explicit Tracking
+
+   An IGMPv3/MLDv2 Querier may operate in combination with explicit
+   tracking as described in Appendix A.2 of [RFC3376], or Appendix A.2
+   of [RFC3810].  This mechanism allows routers to monitor each
+   multicast receiver individually.  Even though this procedure is not
+   standardized yet, it is widely implemented by vendors as it supports
+   faster leave latencies and reduced signaling.
+
+
+
+
+
+Schmidt, et al.               Informational                    [Page 12]
+
+RFC 6224              Multicast Listeners in PMIPv6           April 2011
+
+
+   Enabling explicit tracking on downstream interfaces of the LMA and
+   MAG would track a single MAG and MN respectively per interface.  It
+   may be used to preserve bandwidth on the MAG-MN link.
+
+5.  Message Source and Destination Address
+
+   This section describes source and destination addresses of MLD
+   messages and encapsulating outer headers when deployed in the PMIPv6
+   domain.  This overview is for clarification purposes only and does
+   not define a behavior different from referenced standards in any way.
+
+   The interface identifier A-B denotes an interface on node A, which is
+   connected to node B.  This includes tunnel interfaces.  Destination
+   addresses for MLD/IGMP messages shall be as specified in Section 8 of
+   [RFC2710] for MLDv1, and Sections 5.1.15 and 5.2.14 of [RFC3810] for
+   MLDv2.
+
+5.1.  Query
+
+   +===========+================+======================+==========+
+   | Interface | Source Address | Destination Address  | Header   |
+   +===========+================+======================+==========+
+   |           | LMAA           | Proxy-CoA            | outer    |
+   + LMA-MAG   +----------------+----------------------+----------+
+   |           | LMA-link-local | [RFC2710], [RFC3810] | inner    |
+   +-----------+----------------+----------------------+----------+
+   | MAG-MN    | MAG-link-local | [RFC2710], [RFC3810] |   --     |
+   +-----------+----------------+----------------------+----------+
+
+5.2.  Report/Done
+
+   +===========+================+======================+==========+
+   | Interface | Source Address | Destination Address  | Header   |
+   +===========+================+======================+==========+
+   | MN-MAG    | MN-link-local  | [RFC2710], [RFC3810] |   --     |
+   +-----------+----------------+----------------------+----------+
+   |           | Proxy-CoA      | LMAA                 | outer    |
+   + MAG-LMA   +----------------+----------------------+----------+
+   |           | MAG-link-local | [RFC2710], [RFC3810] | inner    |
+   +-----------+----------------+----------------------+----------+
+
+6.  Security Considerations
+
+   This document does not introduce additional messages or novel
+   protocol operations.  Consequently, no additional threats are
+   introduced by this document beyond those identified as security
+   concerns of [RFC3810], [RFC4605], [RFC5213], and [RFC5844].
+
+
+
+
+Schmidt, et al.               Informational                    [Page 13]
+
+RFC 6224              Multicast Listeners in PMIPv6           April 2011
+
+
+   However, particular attention should be paid to implications of
+   combining multicast and mobility management at network entities.  As
+   this specification allows mobile nodes to initiate the creation of
+   multicast forwarding states at MAGs and LMAs while changing
+   attachments, threats of resource exhaustion at PMIP routers and
+   access networks arrive from rapid state changes, as well as from
+   high-volume data streams routed into access networks of limited
+   capacities.  In addition to proper authorization checks of MNs, rate
+   controls at replicators may be required to protect the agents and the
+   downstream networks.  In particular, MLD proxy implementations at
+   MAGs should carefully procure automatic multicast state extinction on
+   the departure of MNs, as mobile multicast listeners in the PMIPv6
+   domain will not actively terminate group membership prior to
+   departure.
+
+7.  Acknowledgements
+
+   This memo follows initial requirements work presented in "Multicast
+   Support Requirements for Proxy Mobile IPv6" (July 2009), and is the
+   outcome of extensive previous discussions and a follow-up of several
+   initial documents on the subject.  The authors would like to thank
+   (in alphabetical order) Jari Arkko, Luis M. Contreras, Greg Daley,
+   Gorry Fairhurst, Dirk von Hugo, Liu Hui, Seil Jeon, Jouni Korhonen,
+   Guang Lu, Sebastian Meiling, Akbar Rahman, Imed Romdhani, Behcet
+   Sarikaya, Pierrick Seite, Stig Venaas, and Juan Carlos Zuniga for
+   advice, help, and reviews of the document.  Funding by the German
+   Federal Ministry of Education and Research within the G-LAB
+   Initiative is gratefully acknowledged.
+
+8.  References
+
+8.1.  Normative References
+
+   [RFC2710]  Deering, S., Fenner, W., and B. Haberman, "Multicast
+              Listener Discovery (MLD) for IPv6", RFC 2710,
+              October 1999.
+
+   [RFC3376]  Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
+              Thyagarajan, "Internet Group Management Protocol, Version
+              3", RFC 3376, October 2002.
+
+   [RFC3775]  Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
+              in IPv6", RFC 3775, June 2004.
+
+   [RFC3810]  Vida, R. and L. Costa, "Multicast Listener Discovery
+              Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
+
+
+
+
+
+Schmidt, et al.               Informational                    [Page 14]
+
+RFC 6224              Multicast Listeners in PMIPv6           April 2011
+
+
+   [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.
+
+   [RFC5213]  Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K.,
+              and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.
+
+   [RFC5844]  Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy
+              Mobile IPv6", RFC 5844, May 2010.
+
+8.2.  Informative References
+
+   [AUTO-MULTICAST]
+              Thaler, D., Talwar, M., Aggarwal, A., Vicisano, L., and T.
+              Pusateri, "Automatic IP Multicast Without Explicit Tunnels
+              (AMT)", Work in Progress, March 2010.
+
+   [RFC2236]  Fenner, W., "Internet Group Management Protocol, Version
+              2", RFC 2236, November 1997.
+
+   [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.
+
+   [RFC5845]  Muhanna, A., Khalil, M., Gundavelli, S., and K. Leung,
+              "Generic Routing Encapsulation (GRE) Key Option for Proxy
+              Mobile IPv6", RFC 5845, June 2010.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Schmidt, et al.               Informational                    [Page 15]
+
+RFC 6224              Multicast Listeners in PMIPv6           April 2011
+
+
+Appendix A.  Initial MLD Queries on Upcoming Links
+
+   According to [RFC3810] and [RFC2710], when an IGMP-/MLD-enabled
+   multicast router starts operating on a subnet, by default it
+   considers itself as querier and sends several General Queries.  Such
+   initial query should be sent by the router immediately, but could be
+   delayed by a (tunable) Startup Query Interval (see Sections 7.6.2 and
+   9.6 of [RFC3810]).
+
+   Experimental tests on Linux and Cisco systems have revealed immediate
+   IGMP Queries followed a link trigger event (within a fraction of 1
+   ms), while MLD queries immediately followed the autoconfiguration of
+   IPv6 link-local addresses at the corresponding interface.
+
+Appendix B.  State of IGMP/MLD Proxy Implementations
+
+   The deployment scenario defined in this document requires certain
+   proxy functionalities at the MAGs that implementations of [RFC4605]
+   need to contribute.  In particular, a simultaneous support of IGMP
+   and MLD is needed, as well as a configurable list of downstream
+   interfaces that may be altered during runtime, and the deployment of
+   multiple proxy instances at a single router that can operate
+   independently on separated interfaces.
+
+   A brief experimental trial undertaken in February 2010 revealed the
+   following divergent statuses of selected IGMP/MLD proxy
+   implementations.
+
+   Cisco Edge Router:  Software-based commodity edge routers (test
+      device from the 26xx-Series) implement IGMPv2/v3 proxy functions
+      only in combination with Protocol Independent Multicast - Sparse
+      Mode (PIM-SM).  There is no support of MLD proxy.  Interfaces are
+      dynamically configurable at runtime via the command line
+      interface, but multiple proxy instances are not supported.
+
+   Linux igmpproxy:  IGMPv2 Proxy implementation that permits a static
+      configuration of downstream interfaces (simple bug fix required).
+      Multiple instances are prevented by a lock (corresponding code
+      reused from a previous Distance Vector Multicast Routing Protocol
+      (DVMRP) implementation).  IPv6/MLD is unsupported.  Project page:
+      http://sourceforge.net/projects/igmpproxy/.
+
+   Linux gproxy:  IGMPv3 Proxy implementation that permits configuration
+      of the upstream interface, only.  Downstream interfaces are
+      collected at startup without dynamic extension of this list.  No
+      support of multiple instances or MLD.
+
+
+
+
+
+Schmidt, et al.               Informational                    [Page 16]
+
+RFC 6224              Multicast Listeners in PMIPv6           April 2011
+
+
+   Linux ecmh:  MLDv1/2 Proxy implementation without IGMP support that
+      inspects IPv4 tunnels and detects encapsulated MLD messages.
+      Allows for dynamic addition of interfaces at runtime and multiple
+      instances.  However, downstream interfaces cannot be configured.
+      Project page: http://sourceforge.net/projects/ecmh/
+
+Appendix C.  Comparative Evaluation of Different Approaches
+
+   In this section, we briefly evaluate two orthogonal PMIP concepts for
+   multicast traffic organization at LMAs.  In scenario A, multicast is
+   provided by combined unicast/multicast LMAs as described in this
+   document.  Scenario B directs traffic via a dedicated, central
+   multicast router ("LMA-M") that tunnels packets to MAGs independent
+   of unicast handoffs.
+
+   Neither approach establishes native multicast distribution between
+   the LMA and MAG; instead, they use tunneling mechanisms.  In scenario
+   A, a MAG is connected to different multicast-enabled LMAs and can
+   receive the same multicast stream via multiple paths depending on the
+   group subscriptions of MNs and their associated LMAs.  This problem,
+   a.k.a. the tunnel convergence problem, may lead to redundant traffic
+   at the MAGs.  In contrast, scenario B configures MAGs to establish a
+   tunnel to a single, dedicated multicast LMA for all attached MNs and
+   relocates overhead costs to the multicast anchor.  This eliminates
+   redundant traffic but may result in an avalanche problem at the LMA.
+
+   We quantify the costs of both approaches based on two metrics: the
+   amount of redundant traffic at MAGs and the number of simultaneous
+   streams at LMAs.  Realistic values depend on the topology and the
+   group subscription model.  To explore scalability in a large PMIP
+   domain of 1,000,000 MNs, we consider the following two extreme
+   multicast settings.
+
+   1.  All MNs participate in distinct multicast groups.
+
+   2.  All MNs join the same multicast group.
+
+   A typical PMIP deployment approximately allows for 5,000 MNs attached
+   to one MAG, while 50 MAGs can be served by one LMA.  Hence 1,000,000
+   MNs require approximately 200 MAGs backed by 4 LMAs for unicast
+   transmission.  In scenario A, these LMAs also forward multicast
+   streams, while in scenario B one additional dedicated LMA (LMA-M)
+   serves multicast.  In the following, we calculate the metrics
+   described above.  In addition, we display the number of packet
+   streams that cross the interconnecting (wired) network within a
+   PMIPv6 domain.
+
+
+
+
+
+Schmidt, et al.               Informational                    [Page 17]
+
+RFC 6224              Multicast Listeners in PMIPv6           April 2011
+
+
+   Setting 1:
+   +===================+==============+================+===============+
+   | PMIP multicast    | # of redund. |   # of simul.  |  # of total   |
+   | scheme            |   streams    |    streams     |   streams in  |
+   |                   |   at MAG     |  at LMA/LMA-M  |   the network |
+   +===================+==============+================+===============+
+   | Combined Unicast/ |        0     |     250,000    |  1,000,000    |
+   | Multicast LMA     |              |                |               |
+   +-------------------+--------------+----------------+---------------+
+   | Dedicated         |        0     |   1,000,000    |  1,000,000    |
+   | Multicast LMA     |              |                |               |
+   +-------------------+--------------+----------------+---------------+
+
+        1,000,000 MNs are subscribed to distinct multicast groups.
+
+   Setting 2:
+   +===================+==============+================+===============+
+   | PMIP multicast    | # of redund. |   # of simul.  |  # of total   |
+   | scheme            |   streams    |    streams     |   streams in  |
+   |                   |   at MAG     |  at LMA/LMA-M  |   the network |
+   +===================+==============+================+===============+
+   | Combined Unicast/ |        3     |       200      |     800       |
+   | Multicast LMA     |              |                |               |
+   +-------------------+--------------+----------------+---------------+
+   | Dedicated         |        0     |       200      |     200       |
+   | Multicast LMA     |              |                |               |
+   +-------------------+--------------+----------------+---------------+
+
+         1,000,000 MNs are subscribed to the same multicast group.
+
+   These considerations of extreme settings show that packet duplication
+   and replication effects apply in changing intensities for different
+   use cases of multicast data services.  However, tunnel convergence,
+   i.e., duplicate data arriving at a MAG, does cause much smaller
+   problems in scalability than the stream replication at LMAs
+   (avalanche problem).  For scenario A, it should also be noted that
+   the high stream replication requirements at LMAs in setting 1 can be
+   attenuated by deploying additional LMAs in a PMIP domain, while
+   scenario B does not allow for distributing the LMA-M, as no handover
+   management is available at LMA-M.
+
+
+
+
+
+
+
+
+
+
+
+Schmidt, et al.               Informational                    [Page 18]
+
+RFC 6224              Multicast Listeners in PMIPv6           April 2011
+
+
+Authors' Addresses
+
+   Thomas C. Schmidt
+   HAW Hamburg
+   Berliner Tor 7
+   Hamburg  20099
+   Germany
+
+   EMail: schmidt@informatik.haw-hamburg.de
+   URI:   http://inet.cpt.haw-hamburg.de/members/schmidt
+
+
+   Matthias Waehlisch
+   link-lab & FU Berlin
+   Hoenower Str. 35
+   Berlin  10318
+   Germany
+
+   EMail: mw@link-lab.net
+
+
+   Suresh Krishnan
+   Ericsson
+   8400 Decarie Blvd.
+   Town of Mount Royal, QC
+   Canada
+
+   EMail: suresh.krishnan@ericsson.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Schmidt, et al.               Informational                    [Page 19]
+