Skip to main content

Deprecating ASM for Interdomain Multicast
draft-ietf-mboned-deprecate-interdomain-asm-05

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft that was ultimately published as RFC 8815.
Authors Mikael Abrahamsson , Tim Chown , Lenny Giuliano , Toerless Eckert
Last updated 2019-12-23 (Latest revision 2019-09-04)
RFC stream Internet Engineering Task Force (IETF)
Formats
Reviews
Additional resources Mailing list discussion
Stream WG state Submitted to IESG for Publication
Doc Shepherd Follow-up Underway
Document shepherd Colin Doyle
Shepherd write-up Show Last changed 2019-11-01
IESG IESG state Became RFC 8815 (Best Current Practice)
Consensus boilerplate Yes
Telechat date (None)
Responsible AD Warren "Ace" Kumari
Send notices to Colin Doyle <cdoyle@juniper.net>
IANA IANA review state IANA OK - No Actions Needed
draft-ietf-mboned-deprecate-interdomain-asm-05
Mboned                                                    M. Abrahamsson
Internet-Draft                                                 T-Systems
Intended status: Best Current Practice                          T. Chown
Expires: March 7, 2020                                              Jisc
                                                             L. Giuliano
                                                  Juniper Networks, Inc.
                                                               T. Eckert
                                                                  Huawei
                                                       September 4, 2019

               Deprecating ASM for Interdomain Multicast
             draft-ietf-mboned-deprecate-interdomain-asm-05

Abstract

   This document recommends deprecation of the use of Any-Source
   Multicast (ASM) for interdomain multicast.  It recommends the use of
   Source-Specific Multicast (SSM) for interdomain multicast
   applications and that hosts and routers in these deployments fully
   support SSM.  The recommendations in this document do not preclude
   the continued use of ASM within a single organisation or domain and
   are especially easy to adopt in existing intradomain ASM/PIM-SM
   deployments.

Requirements Language and 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 "Key words for use in
   RFCs to Indicate Requirement Levels" [RFC2119].

   The term IP and IP multicast are used to refer to both IPv4 and IPv6.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

Abrahamsson, et al.       Expires March 7, 2020                 [Page 1]
Internet-Draft         Deprecating Interdomain ASM        September 2019

   This Internet-Draft will expire on March 7, 2020.

Copyright Notice

   Copyright (c) 2019 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (https://trustee.ietf.org/license-info) 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.  Background  . . . . . . . . . . . . . . . . . . . . . . . . .   3
     2.1.  Multicast service models  . . . . . . . . . . . . . . . .   3
     2.2.  ASM routing protocols . . . . . . . . . . . . . . . . . .   4
       2.2.1.  PIM Sparse Mode (PIM-SM)  . . . . . . . . . . . . . .   4
       2.2.2.  Embedded-RP . . . . . . . . . . . . . . . . . . . . .   5
       2.2.3.  Bidir-RP  . . . . . . . . . . . . . . . . . . . . . .   5
     2.3.  SSM Routing protocols . . . . . . . . . . . . . . . . . .   5
   3.  Discussion  . . . . . . . . . . . . . . . . . . . . . . . . .   5
     3.1.  Observations on ASM and SSM deployments . . . . . . . . .   5
     3.2.  Advantages of SSM for interdomain multicast . . . . . . .   6
       3.2.1.  Reduced network operations complexity . . . . . . . .   7
       3.2.2.  No network wide IP multicast group-address management   7
       3.2.3.  Intrinsic source-control security . . . . . . . . . .   7
   4.  Recommendations . . . . . . . . . . . . . . . . . . . . . . .   8
     4.1.  Deprecating use of ASM for interdomain multicast  . . . .   8
     4.2.  Including network support for IGMPv3 / MLDv2  . . . . . .   8
     4.3.  Building application support for SSM  . . . . . . . . . .   9
     4.4.  Developing application guidance: SSM, ASM, service
           discovery . . . . . . . . . . . . . . . . . . . . . . . .   9
     4.5.  Preferring SSM applications intradomain . . . . . . . . .  10
     4.6.  Documenting an ASM/SSM protocol mapping mechanism . . . .  10
     4.7.  Not filtering ASM addressing between domains  . . . . . .  10
     4.8.  Not precluding Intradomain ASM  . . . . . . . . . . . . .  11
     4.9.  Evolving PIM deployments for SSM  . . . . . . . . . . . .  11
   5.  Future interdomain ASM work . . . . . . . . . . . . . . . . .  12
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  12
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  12
   8.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  12

Abrahamsson, et al.       Expires March 7, 2020                 [Page 2]
Internet-Draft         Deprecating Interdomain ASM        September 2019

   9.  Changelog . . . . . . . . . . . . . . . . . . . . . . . . . .  12
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  13
     10.1.  Normative References . . . . . . . . . . . . . . . . . .  13
     10.2.  Informative References . . . . . . . . . . . . . . . . .  14
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  15

1.  Introduction

   IP Multicast has been deployed in various forms, within private
   networks, the wider Internet, and federated networks such as national
   or regional research networks.  While a number of service models have
   been published, and in many cases revised over time, there has been
   no strong recommendation made by the IETF on the appropriateness of
   those models to certain scenarios, even though vendors and
   federations have often made such recommendations.

   This document addresses this gap by making a BCP-level recommendation
   to deprecate the use of ASM for interdomain multicast, leaving SSM as
   the recommended interdomain mode of multicast.  This document further
   recommends that all hosts and routers which support interdomain
   multicast applications fully support SSM.

   This document does not make any statement on the use of ASM within a
   single domain or organisation, and therefore does not preclude its
   use.  Indeed, there are application contexts for which ASM is
   currently still widely considered well-suited within a single domain.

   The main issue in most cases with moving to SSM is application
   support.  Many applications are initially deployed for intradomain
   use and are later deployed interdomain.  Therefore, this document
   recommends applications support SSM, even when they are initially
   intended for intradomain use.  As explained below, SSM applications
   are readily compatible with existing intradomain ASM deployments as
   SSM is merely a subset of ASM.

2.  Background

2.1.  Multicast service models

   Any-Source Multicast (ASM) and Source-Specific Multicast (SSM) are
   the two multicast service models in use today.  In ASM, as originally
   described in [RFC1112], receivers express interest in joining a
   multicast group address and routers use multicast routing protocols
   to deliver traffic from the sender(s) to the receivers.  If there are
   multiple senders for a given group, traffic from all senders will be
   delivered to the receiver.  Since receivers specify only the group
   address, the network, and therefore the multicast routing protocols,
   are responsible for source discovery.

Abrahamsson, et al.       Expires March 7, 2020                 [Page 3]
Internet-Draft         Deprecating Interdomain ASM        September 2019

   In SSM, by contrast, receivers specify both group and source when
   expressing interest in joining a multicast stream.  Source discovery
   in SSM is handled by some out-of-band mechanism (ie, the application
   layer), which drastically simplifies the network and how the
   multicast routing protocols operate.

   IANA has reserved specific ranges of IPv4 and IPv6 address space for
   multicast addressing.  Guidelines for IPv4 multicast address
   assignments can be found in [RFC5771], while guidelines for IPv6
   multicast address assignments can be found in [RFC2375] and
   [RFC3307].  The IPv6 multicast address format is described in
   [RFC4291].

2.2.  ASM routing protocols

2.2.1.  PIM Sparse Mode (PIM-SM)

   The most commonly deployed ASM routing protocol is Protocol
   Independent Multicast - Sparse Mode (PIM-SM), as detailed in
   [RFC7761].  PIM-SM, as the name suggests, was designed to be used in
   scenarios where the subnets with receivers are sparsely distributed
   throughout the network.  Because receivers do not indicate sender
   addresses in ASM (but only group addresses), PIM-SM uses the concept
   of a Rendezvous Point (RP) as a 'meeting point' for sources and
   receivers, and all routers in a PIM-SM domain are configured to use
   specific RP(s), either explicitly or through dynamic RP discovery
   protocols.

   To enable PIM-SM to work between multiple domains, an interdomain,
   inter-RP signalling protocol known as Multicast Source Discovery
   Protocol (MSDP) [RFC3618] is used to allow an RP in one domain to
   learn the existence of a source in another domain.  Deployment
   scenarios for MSDP are given in [RFC4611].  MSDP floods information
   about all active sources for all multicast streams to all RPs in all
   the domains - even if there is no receiver for a given application in
   a domain.  As a result of this key scalability and security issue,
   along with other deployment challenges with the protocol, MSDP was
   never extended to support IPv6 and remains an Experimental protocol.

   To this day, there is no IETF Proposed Standard level interdomain
   solution for IPv4 ASM multicast because MSDP was the de facto
   mechanism for the interdomain source discovery problem, and it is
   Experimental.  Other protocol options were investigated at the same
   time but were never implemented or deployed and are now historic
   (e.g: [RFC3913]).

Abrahamsson, et al.       Expires March 7, 2020                 [Page 4]
Internet-Draft         Deprecating Interdomain ASM        September 2019

2.2.2.  Embedded-RP

   Due to the availability of more bits in an IPv6 address than in IPv4,
   an IPv6-specific mechanism was designed in support of interdomain ASM
   with PIM-SM leveraging those bits.  Embedded-RP [RFC3956] allows
   routers supporting the protocol to determine the RP for the group
   without any prior configuration or discovery protocols, simply by
   observing the unicast RP address that is embedded (included) in the
   IPv6 multicast group address.  Embedded-RP allows PIM-SM operation
   across any IPv6 network in which there is an end-to-end path of
   routers supporting this mechanism, including interdomain deployment.

2.2.3.  Bidir-RP

   Bidir-PIM [RFC5015] is another protocol to support ASM.  There is no
   standardized option to operate Bidir-PIM interdomain.  It is deployed
   intradomain for applications where many sources send traffic to the
   same IP multicast groups because unlike PIM-SM it does not create
   per-source state.  Bidir-PIM is one of the important reasons for this
   document to not deprecate intradomain ASM.

2.3.  SSM Routing protocols

   SSM is detailed in [RFC4607].  It mandates the use of PIM-SSM for
   routing of SSM.  PIM-SSM is merely a subset of PIM-SM ([RFC7761]).

   PIM-SSM expects that the sender's source address(es) is known in
   advance by receivers through some out-of-band mechanism (typically in
   the application layer), and thus the receiver's designated router can
   send a PIM JOIN directly towards the source without needing to use an
   RP.

   IPv4 addresses in the 232/8 (232.0.0.0 to 232.255.255.255) range are
   designated as source-specific multicast (SSM) destination addresses
   and are reserved for use by source-specific applications and
   protocols.  See [RFC4607].  For IPv6, the address prefix FF3x::/32 is
   reserved for source-specific multicast use.

3.  Discussion

3.1.  Observations on ASM and SSM deployments

   In enterprise and campus scenarios, ASM in the form of PIM-SM is
   likely the most commonly deployed multicast protocol.  The
   configuration and management of an RP (including RP redundancy)
   within a single domain is a well understood operational practice.
   However, if interworking with external PIM domains is needed in IPv4
   multicast deployments, interdomain MSDP is required to exchange

Abrahamsson, et al.       Expires March 7, 2020                 [Page 5]
Internet-Draft         Deprecating Interdomain ASM        September 2019

   information about sources between domain RPs.  Deployment experience
   has shown MSDP to be a complex and fragile protocol to manage and
   troubleshoot.  Some of these issues include complex flooding RPF
   rules, state attack protection, and filtering of undesired sources.

   PIM-SM is a general purpose protocol that can handle all use cases.
   In particular, it was designed for cases such as videoconferencing
   where multiple sources may come and go during a multicast session.
   But for cases where a single, persistent source for a group is used,
   and receivers can be configured to know of that source, PIM-SM has
   unnecessary complexity.  Therefore, SSM removes the need for many of
   the most complex components of PIM-SM.

   As explained above, MSDP was not extended to support IPv6.  Instead,
   the proposed interdomain ASM solution for PIM-SM with IPv6 is
   Embedded-RP, which allows the RP address for a multicast group to be
   embedded in the group address, making RP discovery automatic for all
   routers on the path between a receiver and a sender.  Embedded-RP can
   support lightweight ad-hoc deployments.  However, it relies on a
   single RP for an entire group that could only be made resilient
   within one domain.  While this approach solves the MSDP issues, it
   does not solve the problem of unauthorised sources sending traffic to
   ASM multicast groups; this security issue is one of biggest problems
   of interdomain multicast.

   As stated in RFC 4607, SSM is particularly well-suited to
   dissemination-style applications with one or more senders whose
   identities are known (by some out-of-band mechanism) before the
   application starts running or applications that utilize some
   signaling to indicate the source address of the multicast stream
   (e.g., electronic programming guide in IPTV applications).  PIM-SSM
   is therefore very well-suited to applications such as classic linear
   broadcast TV over IP.

   SSM requires applications, host operating systems and the designated
   routers connected to receiving hosts to support IGMPv3 [RFC3376] and
   MLDv2 [RFC3810].  Support for IGMPv3 and MLDv2 has become widespread
   in common OSes for several years (Windows, MacOS, Linux/Android) and
   is no longer an impediment to SSM deployment.

3.2.  Advantages of SSM for interdomain multicast

   This section describes the three key benefits that SSM with PIM-SSM
   has over ASM.  These benefits also apply to intradomain deployment
   but are even more important in interdomain deployments.  See
   [RFC4607] for more details.

Abrahamsson, et al.       Expires March 7, 2020                 [Page 6]
Internet-Draft         Deprecating Interdomain ASM        September 2019

3.2.1.  Reduced network operations complexity

   A significant benefit of SSM is the reduced complexity that comes
   through eliminating the network-based source discovery required in
   ASM with PIM-SM.  Specifically, SSM eliminates the need for RPs,
   shared trees, Shortest Path Tree (SPT) switchovers, PIM registers,
   MSDP, dynamic RP discovery mechanisms (BSR/AutoRP) and data-driven
   state creation.  SSM simply utilizes a small subset of PIM-SM,
   alongside the integration with IGMPv3 / MLDv2, where the source
   address signaled from the receiver is immediately used to create
   (S,G) state.  Eliminating network-based source discovery for
   interdomain multicast means the vast majority of the complexity of
   multicast goes away.

   This reduced complexity makes SSM radically simpler to manage,
   troubleshoot and operate, particularly for backbone network
   operators.  This is the main operator motivation for the
   recommendation to deprecate the use of ASM in interdomain scenarios.

   Note that this discussion does not apply to Bidir-PIM, and there is
   (as mentioned above) no standardized interdomain solution for Bidir-
   PIM.  In Bidir-PIM, traffic is forwarded to the RP instead of
   building state as in PIM-SM.  This occurs even in the absence of
   receivers.  Bidir-PIM therefore trades state complexity with
   unnecessary traffic (potentially a large amount).

3.2.2.  No network wide IP multicast group-address management

   In ASM, IP multicast group addresses need to be assigned to
   applications and instances thereof, so that two simultaneously active
   application instances will not share the same group address and
   receive each others IP multicast traffic.

   In SSM, no such IP multicast group management is necessary.  Instead,
   the IP multicast group address simply needs to be assigned locally on
   a source like a unicast transport protocol port number: the only
   coordination required is to ensure that different applications
   running on the same host don't send to the same group address.  This
   does not require any network operator involvement.

3.2.3.  Intrinsic source-control security

   SSM is implicitly secure against off-path unauthorized/undesired
   sources.  Receivers only receive packets from the sources they
   explicitly specify in their IGMP/MLD membership messages, as opposed
   to ASM where any host can send traffic to a group address and have it
   transmitted to all receivers.  With PIM-SSM, traffic from sources not
   requested by any receiver will be discarded by the first-hop router

Abrahamsson, et al.       Expires March 7, 2020                 [Page 7]
Internet-Draft         Deprecating Interdomain ASM        September 2019

   (FHR) of that source, minimizing source attacks against shared
   network bandwidth and receivers.

   This benefit is particularily important in interdomain deployments
   because there are no standardized solutions for ASM control of
   sources and the most common intradomain operational practices such as
   Access Control Lists (ACL) on the sender's FHR are not feasible for
   interdomain deployments.

   This topic is expanded upon in [RFC4609].

4.  Recommendations

4.1.  Deprecating use of ASM for interdomain multicast

   This document recommends that the use of ASM is deprecated for
   interdomain multicast, and thus implicitly, that hosts and routers
   that support such interdomain applications fully support SSM and its
   associated protocols.  Best current practices for deploying
   interdomain multicast using SSM are documented in [RFC8313].

   The recommendation applies to the use of ASM between domains where
   either MSDP (IPv4) or Embedded-RP (IPv6) is used.

   An interdomain use of ASM multicast in the context of this document
   is one where PIM-SM with RPs/MSDP/Embedded-RP is run on routers
   operated by two or more separate administrative entities.

   The more inclusive interpretation of this recommendation is that it
   also extends to the case where PIM may only be operated in a single
   operator domain, but where user hosts or non-PIM network edge devices
   are under different operator control.  A typical example of this case
   is a service provider offering IPTV (single operator domain for PIM)
   to subscribers operating an IGMP proxy home gateway and IGMPv3/MLDv2
   hosts (computer, tablets, set-top boxes).

4.2.  Including network support for IGMPv3 / MLDv2

   This document recommends that all hosts, router platforms and
   security appliances used for deploying multicast support the
   components of IGMPv3 [RFC3376] and MLDv2 [RFC3810] necessary to
   support SSM (i.e., explicitly sending source-specific reports).  The
   updated IPv6 Node Requirements RFC [I-D.ietf-6man-rfc6434-bis] states
   that MLDv2 support is a MUST in all implementations.  Such support is
   already widespread in common host and router platforms.

   Further guidance on IGMPv3 and MLDv2 is given in [RFC4604].

Abrahamsson, et al.       Expires March 7, 2020                 [Page 8]
Internet-Draft         Deprecating Interdomain ASM        September 2019

   Multicast snooping is often used to limit the flooding of multicast
   traffic in a layer 2 network.  With snooping, a L2 switch will
   monitor IGMP/MLD messages and only forward multicast traffic out on
   host ports that have interested receivers connected.  Such snooping
   capability should therefore support IGMPv3 and MLDv2.  There is
   further discussion in [RFC4541].

4.3.  Building application support for SSM

   The recommendation to use SSM for interdomain multicast means that
   applications should properly trigger the sending of IGMPv3/MLDv2
   source-specific report messages.  It should be noted, however, there
   is a wide range of applications today that only support ASM.  In many
   cases this is due to application developers being unaware of the
   operational concerns of networks.  This document serves to provide
   clear direction for application developers to support SSM.

   It is often thought that ASM is required for multicast applications
   where there are multiple sources.  However, RFC 4607 also describes
   how SSM can be used instead of PIM-SM for multi-party applications:

      "SSM can be used to build multi-source applications where all
      participants' identities are not known in advance, but the multi-
      source "rendezvous" functionality does not occur in the network
      layer in this case.  Just like in an application that uses unicast
      as the underlying transport, this functionality can be implemented
      by the application or by an application-layer library."

   Some useful considerations for multicast applications can be found in
   [RFC3170].

4.4.  Developing application guidance: SSM, ASM, service discovery

   Applications with many-to-many communication patterns can create more
   (S,G) state than feasible for networks, whether the source discovery
   is done by ASM with PIM-SM or at the application level and SSM/PIM-
   SM.  These applications are not best supported by either SSM/PIM-SSM
   or ASM/PIM-SM.

   Instead, these applications are better served by routing protocols
   that do not create (S,G), such as Bidir-PIM.  Unfortunately, today
   many applications simply use ASM for service discovery.  One example
   is where clients send IP multicast packets to elicit unicast replies
   from server(s).  Deploying any form of IP multicast solely in support
   of such service discovery is in general not recommended.  Dedicated
   service discovery via DNS-SD [RFC6763] should be used for this
   instead.

Abrahamsson, et al.       Expires March 7, 2020                 [Page 9]
Internet-Draft         Deprecating Interdomain ASM        September 2019

   While the WG discussions had consensus that best practices should be
   developed to explain when to use SSM in applications, e.g, when ASM
   without (S,G) state in the network is better, or when dedicated
   service-discovery mechanisms should be used, it was agreed that
   documenting such practices are outside the scope of this document.

4.5.  Preferring SSM applications intradomain

   If feasible, it is recommended for applications to use SSM even if
   they are initially only meant to be used in intradomain environments
   supporting ASM.  Because PIM-SSM is a subset of PIM-SM, existing
   intradomain PIM-SM networks are automatically compatible with SSM
   applications.  Thus, SSM applications can operate alongside existing
   ASM applications.  SSM's benefits of simplified address management
   and significantly reduced operational complexity apply equally to
   intradomain use.

   However, for some applications it may be prohibitively difficult to
   add support for source discovery, so intradomain ASM may still be
   appropriate.

4.6.  Documenting an ASM/SSM protocol mapping mechanism

   In the case of existing ASM applications that cannot readily be
   ported to SSM, it may be possible to use some form of protocol
   mapping, i.e., to have a mechanism to translate a (*,G) join or leave
   to a (S,G) join or leave, for a specific source, S.  The general
   challenge in performing such mapping is determining where the
   configured source address, S, comes from.

   There are existing vendor-specific mechanisms deployed that achieve
   this function, but none are documented in IETF documents.  This may
   be a useful area for the IETF to work on as an interim transition
   mechanism.  However, these mechanisms would introduce additional
   administrative burdens, along with the need for some form of address
   management, neither of which are required in SSM.  Hence, this should
   not be considered a long-term solution.

4.7.  Not filtering ASM addressing between domains

   A key benefit of SSM is that the receiver specifies the source-group
   tuple when signaling interest in a multicast stream.  Hence, the
   group address need not be globally unique, so there is no need for
   multicast address allocation as long the reserved SSM range is used.

   Despite the deprecation of interdomain ASM, it is recommended that
   operators should not filter ASM group ranges at domain boundaries, as
   some form of ASM-SSM mappings may continue to be used for some time.

Abrahamsson, et al.       Expires March 7, 2020                [Page 10]
Internet-Draft         Deprecating Interdomain ASM        September 2019

4.8.  Not precluding Intradomain ASM

   The use of ASM within a single multicast domain such as a campus or
   enterprise is still relatively common today.  There are even global
   enterprise networks that have successfully been using PIM-SM for many
   years.  The operators of such networks most often use Anycast-RP
   [RFC4610] or MSDP (with IPv4) for RP resilience, at the expense of
   the extra operational complexity.  These existing practices are
   unaffected by this document.

   In the past decade, Bidir-PIM too has seen deployments to scale
   interdomain ASM deployments beyond the capabilities of PIM-SM.  This
   too is unaffected by this document, instead it is encouraged where
   necessary due to application requirements (see Section 4.4).

   This document also does not preclude continued use of ASM with
   multiple PIM-SM domains inside organisations, such as with IPv4 MSDP
   or IPv6 Embedded-RP.  This includes organizations that are
   federations and have appropriate, non-standardized mechanisms to deal
   with the interdomain ASM issues explained in Section 3.2.

4.9.  Evolving PIM deployments for SSM

   Existing PIM-SM deployments can usually be used to run SSM
   applications with little to no changes.  In some widely available
   router implentations of PIM-SM, PIM-SSM is simply enabled by default
   in the designated SSM address spaces whenever PIM-SM is enabled.  In
   other implementations, simple configuration options exist to enable
   it.  This allows easy migration of ASM applications to SSM/PIM-SSM
   solely through application side development to handle source-
   signaling via IGMPv3/MLDv2 and using SSM addresses.  No network
   actions are required for this transition; unchanged ASM applications
   can continue to co-exist without issues.

   When running PIM-SM, IGMPv3/MLDv2 (S,G) membership reports may also
   result in the desired PIM-SSM (S,G) operations and bypass any RP
   procedures, but this is not standardized but depends on
   implementation and may require additional configuration in available
   products.  In general, it is recommended to always use SSM address
   space for SSM applications.  For example, the interaction of IGMPv3/
   MLDv2 (S,G) membership reports and Bidir-PIM is undefined and may not
   result in forwarding of any traffic.

   Note that these migration recommendations do not include the
   considerations when or how to evolve those intradomain applications
   best served by ASM/Bidir-PIM from PIM-SM to Bidir-PIM.  This may also
   be important but is outside the scope of this document.

Abrahamsson, et al.       Expires March 7, 2020                [Page 11]
Internet-Draft         Deprecating Interdomain ASM        September 2019

5.  Future interdomain ASM work

   Future work may attempt to overcome current limitations of ASM
   solutions, such as interdomain deployment solutions for Bidir-PIM, or
   source access control mechanisms for IPv6 PIM-SM with embedded-RP.
   Such work could modify or amend the recommendations of this document
   (like any future IETF standards/BCP work).

   Nevertheless, it is very unlikely that any ASM solution, even with
   such future work, can ever provide the same intrinsic security and
   network and address management simplicity as SSM (see Section 3.2).
   Accordingly, this document recommends that future work for general
   purpose interdomain IP multicast focus on SSM items listed in
   Section 4.

6.  Security Considerations

   This document adds no new security considerations.  It instead
   removes security issues incurred by interdomain ASM with PIM-SM/MSDP
   such as infrastructure control plane attacks and application and
   bandwidth/congestion attacks from unauthorised sources sending to ASM
   multicast groups.  RFC 4609 describes the additional security
   benefits of using SSM instead of ASM.

7.  IANA Considerations

   This document makes no request of IANA.

   Note to RFC Editor: this section may be removed upon publication as
   an RFC.

8.  Acknowledgments

   The authors would like to thank members of the IETF mboned WG for
   discussions on the content of this document, with specific thanks to
   the following people for their contributions to the document: Hitoshi
   Asaeda, Dale Carder, Jake Holland, Albert Manfredi, Mike McBride, Per
   Nihlen, Greg Shepherd, James Stevens, Stig Venaas, Nils Warnke, and
   Sandy Zhang.

9.  Changelog

   [RFC-Editor: Please remove this section.]

   02 - Toerless: Attempt to document the issues brought up on the list
   and discussion by James Stevens re. use of Bidir-PIM intradomain and
   IGMP/MLD interop issues.

Abrahamsson, et al.       Expires March 7, 2020                [Page 12]
Internet-Draft         Deprecating Interdomain ASM        September 2019

   - NOTE: Text was not vetted by co-authors, so rev'ed just as
   discussion basis.

   - more subsection to highlight content.  Added more detailled
   discussion about downsides of ASM wrt. address management and
   intrinsic source-control in SSM.  Added recommendation to work on
   guidance when apps are best suited for SSM vs. ASM/Bidir vs. service
   discovery.  Added recommendation how to evolve from PIM-SM to SSM in
   existing deployments.  Added section on possible future interdomain
   ASM work (and why not to focus on it).

   01 - Lenny: cleanup of text version, removed redundancies.

   00 - initial IETF WG version.  See draft-acg-mboned-deprecate-
   interdomain-asm for work leading to this document.

10.  References

10.1.  Normative References

   [RFC1112]  Deering, S., "Host extensions for IP multicasting", STD 5,
              RFC 1112, DOI 10.17487/RFC1112, August 1989,
              <https://www.rfc-editor.org/info/rfc1112>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC3307]  Haberman, B., "Allocation Guidelines for IPv6 Multicast
              Addresses", RFC 3307, DOI 10.17487/RFC3307, August 2002,
              <https://www.rfc-editor.org/info/rfc3307>.

   [RFC3376]  Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
              Thyagarajan, "Internet Group Management Protocol, Version
              3", RFC 3376, DOI 10.17487/RFC3376, October 2002,
              <https://www.rfc-editor.org/info/rfc3376>.

   [RFC3810]  Vida, R., Ed. and L. Costa, Ed., "Multicast Listener
              Discovery Version 2 (MLDv2) for IPv6", RFC 3810,
              DOI 10.17487/RFC3810, June 2004,
              <https://www.rfc-editor.org/info/rfc3810>.

   [RFC3956]  Savola, P. and B. Haberman, "Embedding the Rendezvous
              Point (RP) Address in an IPv6 Multicast Address",
              RFC 3956, DOI 10.17487/RFC3956, November 2004,
              <https://www.rfc-editor.org/info/rfc3956>.

Abrahamsson, et al.       Expires March 7, 2020                [Page 13]
Internet-Draft         Deprecating Interdomain ASM        September 2019

   [RFC4291]  Hinden, R. and S. Deering, "IP Version 6 Addressing
              Architecture", RFC 4291, DOI 10.17487/RFC4291, February
              2006, <https://www.rfc-editor.org/info/rfc4291>.

   [RFC4607]  Holbrook, H. and B. Cain, "Source-Specific Multicast for
              IP", RFC 4607, DOI 10.17487/RFC4607, August 2006,
              <https://www.rfc-editor.org/info/rfc4607>.

   [RFC4610]  Farinacci, D. and Y. Cai, "Anycast-RP Using Protocol
              Independent Multicast (PIM)", RFC 4610,
              DOI 10.17487/RFC4610, August 2006,
              <https://www.rfc-editor.org/info/rfc4610>.

   [RFC5771]  Cotton, M., Vegoda, L., and D. Meyer, "IANA Guidelines for
              IPv4 Multicast Address Assignments", BCP 51, RFC 5771,
              DOI 10.17487/RFC5771, March 2010,
              <https://www.rfc-editor.org/info/rfc5771>.

   [RFC7761]  Fenner, B., Handley, M., Holbrook, H., Kouvelas, I.,
              Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent
              Multicast - Sparse Mode (PIM-SM): Protocol Specification
              (Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March
              2016, <https://www.rfc-editor.org/info/rfc7761>.

10.2.  Informative References

   [RFC2375]  Hinden, R. and S. Deering, "IPv6 Multicast Address
              Assignments", RFC 2375, DOI 10.17487/RFC2375, July 1998,
              <https://www.rfc-editor.org/info/rfc2375>.

   [RFC3170]  Quinn, B. and K. Almeroth, "IP Multicast Applications:
              Challenges and Solutions", RFC 3170, DOI 10.17487/RFC3170,
              September 2001, <https://www.rfc-editor.org/info/rfc3170>.

   [RFC3618]  Fenner, B., Ed. and D. Meyer, Ed., "Multicast Source
              Discovery Protocol (MSDP)", RFC 3618,
              DOI 10.17487/RFC3618, October 2003,
              <https://www.rfc-editor.org/info/rfc3618>.

   [RFC3913]  Thaler, D., "Border Gateway Multicast Protocol (BGMP):
              Protocol Specification", RFC 3913, DOI 10.17487/RFC3913,
              September 2004, <https://www.rfc-editor.org/info/rfc3913>.

   [RFC4541]  Christensen, M., Kimball, K., and F. Solensky,
              "Considerations for Internet Group Management Protocol
              (IGMP) and Multicast Listener Discovery (MLD) Snooping
              Switches", RFC 4541, DOI 10.17487/RFC4541, May 2006,
              <https://www.rfc-editor.org/info/rfc4541>.

Abrahamsson, et al.       Expires March 7, 2020                [Page 14]
Internet-Draft         Deprecating Interdomain ASM        September 2019

   [RFC4604]  Holbrook, H., Cain, B., and B. Haberman, "Using Internet
              Group Management Protocol Version 3 (IGMPv3) and Multicast
              Listener Discovery Protocol Version 2 (MLDv2) for Source-
              Specific Multicast", RFC 4604, DOI 10.17487/RFC4604,
              August 2006, <https://www.rfc-editor.org/info/rfc4604>.

   [RFC4609]  Savola, P., Lehtonen, R., and D. Meyer, "Protocol
              Independent Multicast - Sparse Mode (PIM-SM) Multicast
              Routing Security Issues and Enhancements", RFC 4609,
              DOI 10.17487/RFC4609, October 2006,
              <https://www.rfc-editor.org/info/rfc4609>.

   [RFC4611]  McBride, M., Meylor, J., and D. Meyer, "Multicast Source
              Discovery Protocol (MSDP) Deployment Scenarios", BCP 121,
              RFC 4611, DOI 10.17487/RFC4611, August 2006,
              <https://www.rfc-editor.org/info/rfc4611>.

   [RFC5015]  Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano,
              "Bidirectional Protocol Independent Multicast (BIDIR-
              PIM)", RFC 5015, DOI 10.17487/RFC5015, October 2007,
              <https://www.rfc-editor.org/info/rfc5015>.

   [RFC6763]  Cheshire, S. and M. Krochmal, "DNS-Based Service
              Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013,
              <https://www.rfc-editor.org/info/rfc6763>.

   [RFC8313]  Tarapore, P., Ed., Sayko, R., Shepherd, G., Eckert, T.,
              Ed., and R. Krishnan, "Use of Multicast across Inter-
              domain Peering Points", BCP 213, RFC 8313,
              DOI 10.17487/RFC8313, January 2018,
              <https://www.rfc-editor.org/info/rfc8313>.

   [I-D.ietf-6man-rfc6434-bis]
              Chown, T., Loughney, J., and T. Winters, "IPv6 Node
              Requirements", draft-ietf-6man-rfc6434-bis-09 (work in
              progress), July 2018.

Authors' Addresses

   Mikael Abrahamsson
   T-Systems
   Stockholm
   Sweden

   Email: mikael.abrahamsson@t-systems.se

Abrahamsson, et al.       Expires March 7, 2020                [Page 15]
Internet-Draft         Deprecating Interdomain ASM        September 2019

   Tim Chown
   Jisc
   Lumen House, Library Avenue
   Harwell Oxford, Didcot  OX11 0SG
   United Kingdom

   Email: tim.chown@jisc.ac.uk

   Lenny Giuliano
   Juniper Networks, Inc.
   2251 Corporate Park Drive
   Herndon, Virginia  20171
   United States

   Email: lenny@juniper.net

   Toerless Eckert
   Futurewei Technologies Inc.
   2330 Central Expy
   Santa Clara  95050
   USA

   Email: tte+ietf@cs.fau.de

Abrahamsson, et al.       Expires March 7, 2020                [Page 16]