<?xml version="1.0" encoding="UTF-8"?> encoding="utf-8"?>

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
  <!ENTITY RFC1112 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.1112.xml">
  <!ENTITY RFC2375 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2375.xml">
  <!ENTITY RFC3170 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3170.xml">
  <!ENTITY RFC3307 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3307.xml">
  <!ENTITY RFC3376 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3376.xml">
  <!ENTITY RFC3618 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3618.xml">
  <!ENTITY RFC3810 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3810.xml">
  <!ENTITY RFC3913 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3913.xml">
  <!ENTITY RFC3956 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3956.xml">
  <!ENTITY RFC4291 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4291.xml">
  <!ENTITY RFC4541 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4541.xml">
  <!ENTITY RFC4604 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4604.xml">
  <!ENTITY RFC4607 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4607.xml">
  <!ENTITY RFC4609 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4609.xml">
  <!ENTITY RFC4610 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4610.xml">
  <!ENTITY RFC4611 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4611.xml">
  <!ENTITY RFC5015 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5015.xml">
  <!ENTITY RFC5771 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5771.xml">
  <!ENTITY RFC6763 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6763.xml">
  <!ENTITY RFC7761 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7761.xml">
  <!ENTITY RFC8313 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8313.xml">
  <!ENTITY RFC8504 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8504.xml">
]>

<!-- Use with the following tips & tools:
      http://xml.resource.org/authoring/draft-mrose-writing-rfcs.html
      http://xml.resource.org/authoring/README.html OR
      http://xml.resource.org/authoring/README-dev.html
      http://xml.resource.org/ OR
      http://xml.resource.org/experimental.html
      http://fenron.net/~fenner/ietf/xml2rfc-valid/  link appears to be broken :(
      http://tools.ietf.org/tools/idnits/
      http://tools.ietf.org/rfcdiff
  -->

<!-- Then upload:
  https://datatracker.ietf.org/idst/upload.cgi
  -->

<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
     please see http://xml.resource.org/authoring/README.html -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
     (Here they are set differently than their defaults in xml2rfc v1.35) -->

<!-- give errors regarding ID-nits and DTD validation -->
<?rfc strict="yes"?>

<!-- control the table of contents (ToC) -->
<!-- generate a ToC -->
<?rfc toc="yes"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<?rfc tocdepth="3"?>

<!-- control references -->
<!-- use anchors instead of numbers for refs, i.e, [RFC2119] instead of [1] -->
<?rfc symrefs="yes"?>
<!-- sort the reference entries alphabetically -->
<?rfc sortrefs="no" ?>

<!-- control vertical white space
     (using these PIs as follows is recommended by the RFC Editor) -->
<!-- do not start each main section on a new page -->
<?rfc compact="yes" ?>
<!-- "no" to keep one blank line between list items (rfced) -->
<?rfc subcompact="no" ?>

<!-- encourage use of "xml2rfc" tool -->
<?rfc rfcprocack="yes" ?>
<!-- end of list of popular I-D processing instructions --> "rfc2629-xhtml.ent">

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="IETF"
     category="bcp" consensus="true" ipr="trust200902" docName="draft-ietf-mboned-deprecate-interdomain-asm-07">
     docName="draft-ietf-mboned-deprecate-interdomain-asm-07" number="8815"
     obsoletes="" updates="" xml:lang="en" tocInclude="true" tocDepth="3"
     symRefs="true" sortRefs="false" version="3">

  <!-- xml2rfc v2v3 conversion 2.41.0 -->

  <front>
    <title abbrev="Deprecating Interdomain ASM">Deprecating ASM Any-Source
    Multicast (ASM) for Interdomain Multicast</title>
    <seriesInfo name="RFC" value="8815"/>
    <seriesInfo name="BCP" value="229"/>
    <author fullname="Mikael Abrahamsson" initials="M." surname="Abrahamsson">
      <address>
        <postal>
          <street> </street>
          <city> Stockholm </city>
          <country> Sweden </country>
          <city>Stockholm</city>
          <country>Sweden</country>
        </postal>
        <email> swmike@swm.pp.se </email>
        <email>swmike@swm.pp.se</email>
      </address>
    </author>

    <author fullname="Tim Chown" initials="T." surname="Chown">
      <organization> Jisc </organization>
      <organization>Jisc</organization>
      <address>
        <postal>
          <street> Lumen
          <street>Lumen House, Library Avenue </street>
          <city> Harwell Oxford, Didcot</city>
          <code> OX11 0SG </code>
          <country> United Kingdom </country> Avenue</street>
          <extaddr>Harwell Oxford</extaddr>
	  <city>Didcot</city>
          <code>OX11 0SG</code>
          <country>United Kingdom</country>
        </postal>
        <email> tim.chown@jisc.ac.uk </email>
        <email>tim.chown@jisc.ac.uk</email>
      </address>
    </author>
    <author fullname="Lenny Giuliano" initials="L." surname="Giuliano">
      <organization> Juniper
      <organization>Juniper Networks, Inc. </organization> Inc.</organization>
      <address>
        <postal>
          <street> 2251
          <street>2251 Corporate Park Drive </street>
          <city> Herndon, Virginia</city>
          <code> 20171 </code>
          <country> United Drive</street>
          <city>Herndon</city> <region>Virginia</region>
          <code>20171</code>
          <country>United States </country> of America</country>
        </postal>
        <email> lenny@juniper.net </email>
        <email>lenny@juniper.net</email>
      </address>
    </author>
    <author fullname="Toerless Eckert" initials="T.T.E." initials="T." surname="Eckert">
      <organization>Futurewei Technologies Inc.</organization>
      <address>
        <postal>
          <street>2330 Central Expy</street>
          <city>Santa Clara</city> <region>California</region>
          <code>95050</code>
           <country>USA</country>
          <country>United States of America</country>
        </postal>
         <email>tte+ietf@cs.fau.de</email>
        <email>tte@cs.fau.de</email>
      </address>
    </author>
    <date month="March" month="August" year="2020"/>
    <area> Operations </area>
    <workgroup> Mboned </workgroup>
    <area>Operations</area>
    <workgroup>Mboned</workgroup>

    <abstract>
      <t>
	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 recommends 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 organization or domain and are especially easy to
adopt in existing deployments of intradomain ASM/PIM-SM deployments. ASM using PIM Sparse Mode
(PIM-SM).
      </t>
    </abstract>
  </front>
  <middle>
    <section title="Introduction"> numbered="true" toc="default">
      <name>Introduction</name>
      <t>
	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.
      </t>
      <t>
	This document addresses this gap by making a BCP-level
	recommendation to deprecate the use of Any-Source Multicast (ASM)
	for interdomain
	multicast, leaving Source-Specific Multicast (SSM)
	as the recommended interdomain mode of
        multicast.
	This
	Therefore, this document further recommends that all hosts and routers which that support
	interdomain multicast applications fully support SSM.
      </t>
      <t>
	This document does not make any statement on the use of ASM
	within a single domain or organisation, and therefore organization and, therefore, does not preclude its use. Indeed, there are application contexts for
	which ASM is currently still widely considered well-suited well suited within a
	single domain.
      </t>
      <t>
        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 that
        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 using PIM-SM, as SSM PIM-SSM is merely a subset of ASM. PIM-SM.
      </t>
    </section>
    <section title="Background">
        <section title="Multicast service models"> numbered="true" toc="default">
      <name>Background</name>
      <section numbered="true" toc="default">
        <name>Multicast Service Models</name>
        <t>
	  Any-Source Multicast (ASM) and Source-Specific Multicast (SSM)
	  are the two multicast service models in use today.  In ASM, as originally
	  described in <xref target="RFC1112"/>, target="RFC1112" format="default"/>, receivers express interest
	  in joining a multicast group address 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 receivers.  Since receivers specify only the group address,
	  the network, network -- and therefore the multicast routing protocols, protocols -- are
	  responsible for source discovery.
        </t>
        <t>
	  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 (typically in the application
	  layer,
	  layer), which drastically simplifies the network and how the multicast
	  routing protocols operate.
        </t>
        <t>
	  IANA has reserved specific ranges of IPv4 and IPv6 address
	  space for multicast addressing.
	  Guidelines for IPv4 multicast address assignments
	  can be found in <xref target="RFC5771"/>, target="RFC5771" format="default"/>, while
	  guidelines for IPv6 multicast address assignments
	  can be found in <xref target="RFC2375"/> target="RFC2375" format="default"/> and
	  <xref target="RFC3307"/>. target="RFC3307" format="default"/>.
	  The IPv6 multicast address format is described
	  in <xref target="RFC4291"/>. target="RFC4291" format="default"/>.
        </t>
      </section>
      <section title="ASM routing protocols"> numbered="true" toc="default">
        <name>ASM Routing Protocols</name>
        <section title="PIM numbered="true" toc="default">
          <name>PIM Sparse Mode (PIM-SM)"> (PIM-SM)</name>
          <t>
      	    The most commonly deployed ASM routing protocol is Protocol Independent
	    Multicast - Sparse Mode (PIM-SM), as
	    detailed in <xref target="RFC7761"/>. target="RFC7761" format="default"/>.
	    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’ "meeting point"
	    for sources and receivers, and all routers in a PIM-SM domain are
	    configured to use a specific RP(s), either explicitly or through
            dynamic RP discovery RP-discovery protocols.
          </t>
          <t>
	    To enable PIM-SM to work between multiple
	    domains, an interdomain, inter-RP signalling signaling protocol known
	    as Multicast Source Discovery Protocol (MSDP)
	    <xref target="RFC3618"/> target="RFC3618" format="default"/> is used to allow an RP in one
	    domain to learn of the existence of a source in another domain.
	    Deployment scenarios for MSDP are given in <xref target="RFC4611"/>. target="RFC4611" format="default"/>.
	    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.
          </t>
          <t>At the time of writing, there is no IETF Proposed Standard level
          interdomain solution at the level of
          Proposed Standard for IPv4 ASM multicast
          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: (e.g., <xref target="RFC3913"/>). target="RFC3913"
          format="default"/>).
          </t>
        </section>
        <section title="Embedded-RP"> numbered="true" toc="default">
          <name>Embedded-RP</name>
          <t>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
	    ASM, with PIM-SM leveraging those bits.
	    Embedded-RP <xref target="RFC3956"/> target="RFC3956" format="default"/> 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.
          </t>
        </section>
        <section title="Bidir-RP">

            <t>Bidir-PIM numbered="true" toc="default">
          <name>BIDIR-RP</name>
          <t>BIDIR-PIM <xref target="RFC5015"/> target="RFC5015" format="default"/> is
	  another protocol to support ASM.
            There is no standardized option to operate Bidir-PIM BIDIR-PIM interdomain. It is
            deployed intradomain for applications where many sources send traffic
            to the same IP multicast groups because because, unlike PIM-SM PIM-SM, it does not
            create per-source state. Bidir-PIM BIDIR-PIM is one of the important reasons for this
            document to not deprecate intradomain ASM.</t>
        </section>
      </section>
      <section title="SSM numbered="true" toc="default">
        <name>SSM Routing protocols"> Protocols</name>
        <t>
      	  SSM is detailed in <xref target="RFC4607"/>. target="RFC4607" format="default"/>. It mandates the use of
          PIM-SSM for routing of SSM.  PIM-SSM is merely a subset of PIM-SM (<xref target="RFC7761"/>).
	  <xref target="RFC7761" format="default"/>.
        </t>
        <t>
	  PIM-SSM expects the sender’s sender's source address(es)
	  to be known in advance by receivers through some out-of-band mechanism (typically
	  in the application layer), and thus layer); thus, the
	  receiver's designated router can send a PIM JOIN Join message directly towards the
	  source without needing to use an RP.
        </t>
        <t>
	  IPv4 addresses in the 232/8 (232.0.0.0 to
   	  232.255.255.255) range are designated as source-specific multicast Source-Specific Multicast
   	  (SSM) destination addresses and are reserved for use by
	  source-specific applications and protocols. See <xref target="RFC4607"/>.
	  For IPv6, the address prefix
	  ff3x::/32 is reserved for source-specific multicast use.  See <xref target="RFC4607" format="default"/>.
        </t>
      </section>
    </section>
    <section title="Discussion"> numbered="true" toc="default">
      <name>Discussion</name>
      <section title="Observations numbered="true" toc="default">
        <name>Observations on ASM and SSM deployments"> Deployments</name>
        <t>
	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 well-understood operational practice.  However, if interworking
	with external PIM domains is needed in IPv4 multicast deployments,
	interdomain MSDP is required to
	exchange 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
	Reverse Path Forwarding (RPF)
	rules, state attack protection, and filtering of undesired sources.
        </t>
        <t>
	PIM-SM is a general purpose 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.
        </t>
        <t>
	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 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 unauthorized sources sending traffic to ASM
        multicast groups; this security issue
	is one of biggest problems of interdomain multicast.
        </t>
        <t>
	As stated in RFC 4607, SSM is particularly well-suited well suited to either
	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., an electronic programming guide
	in IPTV applications).
        Therefore, SSM through PIM-SSM is therefore very well-suited well suited
	to applications such as classic linear broadcast linear-broadcast TV over IP.
        </t>
        <t>
	SSM requires applications, host operating systems systems, and the
	designated routers connected to receiving hosts
	to support Internet Group Management Protocol, Version 3 (IGMPv3)
	<xref target="RFC3376"/> target="RFC3376" format="default"/> and
	Multicast Listener Discovery, Version 2 (MLDv2)
	<xref target="RFC3810"/>. target="RFC3810" format="default"/>.  While support for
	IGMPv3 and MLDv2 has been commonplace in routing platforms for
	a long time, it has also now become widespread in common operating
	systems for several years (Windows, MacOS, Mac OS,
        Linux/Android) and is no longer an impediment to SSM deployment.
        </t>
      </section>
      <section title="Advantages anchor="advantages" numbered="true" toc="default">
        <name>Advantages of SSM for interdomain multicast" anchor="advantages" > Interdomain Multicast</name>
        <t>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 <xref target="RFC4607"/> target="RFC4607" format="default"/> for
        more details.</t>
        <section title="Reduced network operations complexity"> numbered="true" toc="default">
          <name>Reduced Network Operations Complexity</name>
          <t>
	  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 RP-discovery mechanisms (BSR/AutoRP) (Bootstrap Router
	  (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.
          </t>
          <t>
	  This reduced complexity makes SSM radically simpler to manage,
	  troubleshoot
	  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.
          </t>
          <t>Note that this discussion does not apply to Bidir-PIM, BIDIR-PIM, and there is
          (as mentioned above) no standardized interdomain solution for Bidir-PIM. BIDIR-PIM.
	  In Bidir-PIM, 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
	  Therefore, BIDIR-PIM offers a trade-off of state complexity with at the cost of
creating unnecessary traffic (potentially a large amount).  </t>
        </section>
        <section title="No network-wide numbered="true" toc="default">
          <name>No Network-Wide IP multicast group-address management"> Multicast Group-Address Management</name>
          <t>
          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 IP multicast traffic from
	  each other.
          </t>
          <t>
          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 network-operator involvement.
          </t>
        </section>
        <section anchor="source-security" title="Intrinsic source-control security"> numbered="true" toc="default">
          <name>Intrinsic Source-Control Security</name>
          <t>
	  SSM is implicitly secure against off-path unauthorized/undesired sources.
	  Receivers only receive packets from the sources they explicitly specify
          in their IGMPv3/MLDv2 membership messages, as opposed to ASM 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 First-Hop Router (FHR) of that source, minimizing source
          attacks against shared network bandwidth and receivers.
          </t>
          <t>
          This benefit is particularly 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) (ACLs) on the sender's FHR are not feasible for
  interdomain deployments.
          </t>
          <t>
	  This topic is expanded upon in <xref target="RFC4609"/>. target="RFC4609" format="default"/>.
          </t>
        </section>
      </section>
    </section>
    <section anchor="recommendations" title="Recommendations"> numbered="true" toc="default">
      <name>Recommendations</name>
      <t>
	This section provides recommendations for a variety of stakeholders in
	SSM deployment, including vendors, operators operators, and application developers,
	and developers.
	It also suggests further work that could be undertaken within the IETF.
      </t>
      <section title="Deprecating use numbered="true" toc="default">
        <name>Deprecating Use of ASM for interdomain multicast"> Interdomain Multicast</name>
        <t>
	This document recommends that the use of ASM be deprecated
	for interdomain multicast, and thus multicast; thus, implicitly, it recommends 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 <xref target="RFC8313"/>. target="RFC8313" format="default"/>.
        </t>
        <t>
	The recommendation applies to the use of ASM between domains where
	either MSDP (IPv4) or Embedded-RP (IPv6) is used.
        </t>
        <t>
	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.
        </t>
        <t>
	The focus of this document is deprecation of inter-domain interdomain ASM multicast,
	and while encouraging the use of SSM within domains,
	it leaves operators free to choose to use ASM within their own domains.
	A more inclusive interpretation of this recommendation is that it
	also extends to deprecating use of ASM in the case where PIM is
	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).
        </t>
      </section>
      <section title="Including network support numbered="true" toc="default">
        <name>Including Network Support for IGMPv3/MLDv2"> IGMPv3/MLDv2</name>
        <t>
	This document recommends that all hosts, router platforms platforms, and
	security appliances used for deploying multicast
	support the components of IGMPv3 <xref target="RFC3376"/> target="RFC3376" format="default"/> and MLDv2
	<xref target="RFC3810"/> target="RFC3810" format="default"/> necessary to support SSM (i.e., explicitly sending
	source-specific reports).
	The updated IPv6
	"IPv6 Node Requirements RFC Requirements" <xref target="RFC8504"/> target="RFC8504" format="default"/>
	states that MLDv2 must be supported in all implementations.
	Such support is already widespread in common host and router platforms.
        </t>
        <t>
	Further guidance on IGMPv3 and MLDv2 is given in
	<xref target="RFC4604"/>. target="RFC4604" format="default"/>.
        </t>
        <t>
        Multicast snooping is often used to limit the flooding of multicast traffic
        in a layer Layer 2 network.  With snooping, a an 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 <xref target="RFC4541"/>. target="RFC4541" format="default"/>.
        </t>
      </section>
      <section title="Building application support numbered="true" toc="default">
        <name>Building Application Support for SSM"> SSM</name>
        <t>
	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, that there is a wide range of applications today
	that only support ASM.  In many cases cases, this is due to application developers
	being unaware of the operational concerns of networks, networks and the implications of
	using ASM versus using SSM.  This document serves to
	provide clear direction for application developers who might currently only
	consider using ASM to instead support SSM, which only requires relatively minor
	changes for many applications, particularly those with single sources.
        </t>
        <t>
	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:
        </t>
	<t>
	<list style="empty">
	<t>"SSM

          <blockquote>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."
	</t>
	</list>
	</t> library.
	</blockquote>

        <t>
	Some useful considerations for multicast applications can be found
	in  <xref target="RFC3170"/>. target="RFC3170" format="default"/>.
        </t>
      </section>
      <section anchor="guidance" title="Developing application guidance: numbered="true" toc="default">
        <name>Developing Application Guidance: SSM, ASM, service discovery"> Service Discovery</name>
        <t>
        Applications with many-to-many communication patterns can create more
        (S,G) state than is feasible for networks to manage, whether the source discovery is
        done by ASM with PIM-SM or at the application level and SSM/PIM-SM. SSM/PIM-SSM.
        These applications are not best supported by either SSM/PIM-SSM or ASM/PIM-SM.
        </t>
        <t>
	  Instead, these applications are better served by routing protocols
	  that do not create (S,G), such as Bidir-PIM. BIDIR-PIM.
	  Unfortunately, today many applications today use ASM solely 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 is, in general general,
	  not recommended.   Dedicated
	  service discovery via DNS-SD DNS-based Service
   Discovery (DNS-SD) <xref target="RFC6763"/> target="RFC6763" format="default"/> should be used
   for this instead.
        </t>
        <t>
	This document describes best practices to explain when to use SSM in applications,
	e.g,
	applications -- e.g., when ASM without (S,G) state in the network is
	better, or when dedicated service-discovery
	mechanisms should be used, but used. However, specifying how applications
	can support these practices is
	outside the scope of this document.
	Further work on this subject may be expected within the IETF.
        </t>
      </section>
      <section title="Preferring numbered="true" toc="default">
        <name>Preferring SSM applications intradomain"> Applications Intradomain</name>
        <t>
        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.
        </t>
        <t>However, for some applications applications, it may be prohibitively difficult to
        add support for source discovery, so intradomain ASM may still be appropriate.
        </t>
      </section>
      <section title="Documenting numbered="true" toc="default">
        <name>Documenting an ASM/SSM protocol mapping mechanism"> Protocol Mapping Mechanism</name>
        <t>
	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, 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.
        </t>
        <t>
	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.
        </t>
      </section>
      <section title="Not filtering numbered="true" toc="default">
        <name>Not Filtering ASM addressing Addressing between domains"> Domains</name>
        <t>
	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.
        </t>
        <t>
	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.
        </t>
      </section>
      <section anchor="precluding" title="Not precluding numbered="true" toc="default">
        <name>Not Precluding Intradomain ASM"> ASM</name>
        <t>
	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 <xref target="RFC4610"/> target="RFC4610" format="default"/> or MSDP (with IPv4) for RP
	resilience, at the expense of the extra operational complexity.
	These existing practices are unaffected by this document.
        </t>
        <t>In the past decade, some Bidir-PIM BIDIR-PIM deployments have scaled
	interdomain ASM deployments beyond the capabilities of PIM-SM. This too This, too,
        is unaffected by this document, instead document; instead, it is encouraged where
        necessary due to application requirements (see <xref target="guidance"/>).</t> target="guidance" format="default"/>).</t>
        <t>
	This document also does not preclude continued use of ASM with multiple
        PIM-SM domains inside organisations, organizations, such as with IPv4 MSDP or IPv6 Embedded-RP.
	This includes organizations that are federations and have appropriate, non-standardized nonstandardized
        mechanisms to deal with the interdomain ASM issues explained in <xref target="advantages"/>. target="advantages" format="default"/>.
        </t>
      </section>
      <section title="Evolving numbered="true" toc="default">
        <name>Evolving PIM deployments Deployments for SSM"> SSM</name>
        <t>
	 Existing PIM-SM deployments can usually be used to run SSM
	applications with little to no few-to-no changes.  In some widely available
	router implementations 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 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 coexist without issues.
        </t>
        <t>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. 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 BIDIR-PIM is undefined and may not result in forwarding of any traffic.
        </t>
        <t>
        Note that these migration recommendations do not include considerations on when
        or how to evolve those intradomain applications best served by ASM/Bidir-PIM ASM/BIDIR-PIM from PIM-SM
        to Bidir-PIM. BIDIR-PIM. This may also be important but is outside the scope of this document.
        </t>
      </section>
    </section>
    <section title="Future interdomain numbered="true" toc="default">
      <name>Future Interdomain ASM work"> Work</name>
      <t>
      Future work may attempt to overcome current limitations of ASM solutions,
      such as interdomain deployment solutions for Bidir-PIM, BIDIR-PIM or source access control 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 Standards
      Track / BCP work).
      </t>
      <t>
	Nevertheless, it is very unlikely that any ASM solution, even with such
	future work, can ever provide the same intrinsic security and network network- and
	address management
	address-management simplicity as SSM (see <xref target="advantages"/>). target="advantages"
	format="default"/>).  Accordingly, this
	document recommends that future work for general-purpose interdomain IP
	multicast focus on SSM items listed in <xref target="recommendations"/>. target="recommendations" format="default"/>.
      </t>
    </section>
    <section title="Security Considerations"> numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>
	This document adds no new security considerations. It instead
        removes security issues incurred by interdomain ASM with PIM-SM/MSDP PIM-SM/MSDP, such as
        infrastructure control plane control-plane attacks and application and bandwidth/congestion
        attacks from unauthorised unauthorized sources sending to ASM multicast groups.
	RFC 4609 describes the additional security benefits of using
	SSM instead of ASM.
      </t>
    </section>
    <section title="IANA Considerations"> numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>This document makes has no request of IANA.</t>
      <t>Note to RFC Editor: this section may be removed upon publication as an RFC.</t> IANA actions.</t>
    </section>
  </middle>
  <back>
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.1112.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3307.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3376.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3810.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3956.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4291.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4607.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5771.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7761.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8313.xml"/>
      </references>
      <references>
        <name>Informative References</name>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2375.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3170.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3618.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3913.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4541.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4604.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4609.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4610.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4611.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5015.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6763.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8504.xml"/>
      </references>
    </references>
    <section title="Acknowledgments"> numbered="false" toc="default">
      <name>Acknowledgments</name>
      <t>
	The authors would like to thank members of the IETF mboned WG MBONE Deployment
	Working Group 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.
	<contact fullname="Hitoshi Asaeda"/>,
	<contact fullname="Dale Carder"/>,
	<contact fullname="Jake Holland"/>,
	<contact fullname="Albert Manfredi"/>,
	<contact fullname="Mike McBride"/>,
	<contact fullname="Per Nihlen"/>,
	<contact fullname="Greg Shepherd"/>,
	<contact fullname="James Stevens"/>,
	<contact fullname="Stig Venaas"/>,
	<contact fullname="Nils Warnke"/>,
	and
	<contact fullname="Sandy Zhang"/>.
      </t>
    </section>

    <section title="Changelog">

      <t>[RFC-Editor: Please remove this section.]</t>
      <t>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.</t>
      <t>   - NOTE: Text was not vetted by co-authors, so rev'ed just as discussion basis.</t>
      <t>   - 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).</t>
      <t>01 - Lenny: cleanup of text  version, removed redundancies.</t>
      <t>00 - initial IETF WG version.
         See draft-acg-mboned-deprecate-interdomain-asm for work leading to this document.</t>

    </section>

  </middle>
  <back>

    <references title="Normative References">
	&RFC1112;
	&RFC3307;
      	&RFC3376;
	&RFC3810;
	&RFC3956;
	&RFC4291;
	&RFC4607;
	&RFC5771;
      	&RFC7761;
	&RFC8313;
    </references>

    <references title="Informative References">
	&RFC2375;
	&RFC3170;
	&RFC3618;
	&RFC3913;
	&RFC4541;
	&RFC4604;
	&RFC4609;
	&RFC4610;
	&RFC4611;
	&RFC5015;
	&RFC6763;
	&RFC8504;

    </references>
  </back>
</rfc>