Deprecating Any-Source Multicast (ASM) for Interdomain MulticastStockholmSwedenswmike@swm.pp.seJiscLumen House, Library AvenueHarwell OxfordDidcotOX11 0SGUnited Kingdomtim.chown@jisc.ac.ukJuniper Networks, Inc.2251 Corporate Park DriveHerndonVirginia20171United States of Americalenny@juniper.netFuturewei Technologies Inc.2330 Central ExpySanta ClaraCalifornia95050United States of Americatte@cs.fau.de
Operations
Mboned
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 organization or domain and are especially easy to
adopt in existing deployments of intradomain ASM using PIM Sparse Mode
(PIM-SM).
Status of This Memo
This memo documents an Internet Best Current Practice.
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). Further information
on BCPs is available in Section 2 of RFC 7841.
Information about the current status of this document, any
errata, and how to provide feedback on it may be obtained at
.
Copyright Notice
Copyright (c) 2020 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
() 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
. Introduction
. Background
. Multicast Service Models
. ASM Routing Protocols
. PIM Sparse Mode (PIM-SM)
. Embedded-RP
. BIDIR-RP
. SSM Routing Protocols
. Discussion
. Observations on ASM and SSM Deployments
. Advantages of SSM for Interdomain Multicast
. Reduced Network Operations Complexity
. No Network-Wide IP Multicast Group-Address Management
. Intrinsic Source-Control Security
. Recommendations
. Deprecating Use of ASM for Interdomain Multicast
. Including Network Support for IGMPv3/MLDv2
. Building Application Support for SSM
. Developing Application Guidance: SSM, ASM, Service Discovery
. Preferring SSM Applications Intradomain
. Documenting an ASM/SSM Protocol Mapping Mechanism
. Not Filtering ASM Addressing between Domains
. Not Precluding Intradomain ASM
. Evolving PIM Deployments for SSM
. Future Interdomain ASM Work
. Security Considerations
. IANA Considerations
. References
. Normative References
. Informative References
Acknowledgments
Authors' Addresses
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 Any-Source Multicast (ASM)
for interdomain
multicast, leaving Source-Specific Multicast (SSM)
as the recommended interdomain mode of
multicast.
Therefore, this document recommends that all hosts and routers that support
interdomain multicast applications fully support SSM.
This document does not make any statement on the use of ASM
within a single domain or organization 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 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 PIM-SSM is merely a subset of PIM-SM.
BackgroundMulticast 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 , 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 receivers. Since receivers specify only the group address,
the network -- and therefore the multicast routing protocols -- are
responsible for source discovery.
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), 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 , while
guidelines for IPv6 multicast address assignments
can be found in and
.
The IPv6 multicast address format is described
in .
ASM Routing ProtocolsPIM Sparse Mode (PIM-SM)
The most commonly deployed ASM routing protocol is Protocol Independent
Multicast - Sparse Mode (PIM-SM), as
detailed in .
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 a specific RP(s), either explicitly or through
dynamic RP-discovery protocols.
To enable PIM-SM to work between multiple
domains, an interdomain, inter-RP signaling protocol known
as Multicast Source Discovery Protocol (MSDP)
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 .
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.
At the time of writing, there is no IETF
interdomain solution at the level of
Proposed Standard 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., ).
Embedded-RPDue 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 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.
BIDIR-RPBIDIR-PIM 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.SSM Routing Protocols
SSM is detailed in . It mandates the use of
PIM-SSM for routing of SSM. PIM-SSM is merely a subset of PIM-SM
.
PIM-SSM expects the sender's source address(es)
to be known in advance by receivers through some out-of-band mechanism (typically
in the application layer); thus, the
receiver's designated router can send a PIM Join message 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.
For IPv6, the address prefix
ff3x::/32 is reserved for source-specific multicast use. See .
DiscussionObservations 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 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.
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 unauthorized 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 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 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 Internet Group Management Protocol, Version 3 (IGMPv3)
and
Multicast Listener Discovery, Version 2 (MLDv2)
. 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, Mac OS,
Linux/Android) and is no longer an impediment to SSM deployment.
Advantages of SSM for Interdomain MulticastThis 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 for
more details.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 (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.
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.
Therefore, BIDIR-PIM offers a trade-off of state complexity at the cost of
creating unnecessary traffic (potentially a large amount). 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 IP multicast traffic from
each other.
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.
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 IGMPv3/MLDv2 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 (FHR) of that source, minimizing source
attacks against shared network bandwidth and receivers.
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 (ACLs) on the sender's FHR are not feasible for
interdomain deployments.
This topic is expanded upon in .
Recommendations
This section provides recommendations for a variety of stakeholders in
SSM deployment, including vendors, operators, and application developers.
It also suggests further work that could be undertaken within the IETF.
Deprecating Use of ASM for Interdomain Multicast
This document recommends that the use of ASM be deprecated
for interdomain 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 .
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 focus of this document is deprecation of 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).
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 and MLDv2
necessary to support SSM (i.e., explicitly sending
source-specific reports).
"IPv6 Node Requirements"
states that MLDv2 must be supported in all implementations.
Such support is already widespread in common host and router platforms.
Further guidance on IGMPv3 and MLDv2 is given in
.
Multicast snooping is often used to limit the flooding of multicast traffic
in a Layer 2 network. With snooping, 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 .
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, that 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 and the implications of
using ASM versus 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.
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 .
Developing Application Guidance: SSM, ASM, Service Discovery
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-SSM.
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, 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, in general,
not recommended. Dedicated
service discovery via DNS-based Service
Discovery (DNS-SD) should be used
for this instead.
This document describes best practices 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. 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.
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.
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.
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
not filter ASM group ranges at domain boundaries, as some form of
ASM-SSM mappings may continue to be used for some time.
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 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, some BIDIR-PIM deployments have scaled
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 ).
This document also does not preclude continued use of ASM with multiple
PIM-SM domains inside organizations, such as with IPv4 MSDP or IPv6 Embedded-RP.
This includes organizations that are federations and have appropriate, nonstandardized
mechanisms to deal with the interdomain ASM issues explained in .
Evolving PIM Deployments for SSM
Existing PIM-SM deployments can usually be used to run SSM
applications with 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 coexist 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. 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 considerations on 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.
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
Track / 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 ). Accordingly, this
document recommends that future work for general-purpose interdomain IP
multicast focus on SSM items listed in .
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 unauthorized sources sending to ASM multicast groups.
RFC 4609 describes the additional security benefits of using
SSM instead of ASM.
IANA ConsiderationsThis document has no IANA actions.ReferencesNormative ReferencesHost extensions for IP multicastingThis memo specifies the extensions required of a host implementation of the Internet Protocol (IP) to support multicasting. Recommended procedure for IP multicasting in the Internet. This RFC obsoletes RFCs 998 and 1054. [STANDARDS-TRACK]Allocation Guidelines for IPv6 Multicast AddressesInternet Group Management Protocol, Version 3Multicast Listener Discovery Version 2 (MLDv2) for IPv6This document updates RFC 2710, and it specifies Version 2 of the ulticast Listener Discovery Protocol (MLDv2). MLD is used by an IPv6 router to discover the presence of multicast listeners on directly attached links, and to discover which multicast addresses are of interest to those neighboring nodes. MLDv2 is designed to be interoperable with MLDv1. MLDv2 adds the ability for a node to report interest in listening to packets with a particular multicast address only from specific source addresses or from all sources except for specific source addresses. [STANDARDS-TRACK]Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast AddressThis memo defines an address allocation policy in which the address of the Rendezvous Point (RP) is encoded in an IPv6 multicast group address. For Protocol Independent Multicast - Sparse Mode (PIM-SM), this can be seen as a specification of a group-to-RP mapping mechanism. This allows an easy deployment of scalable inter-domain multicast and simplifies the intra-domain multicast configuration as well. This memo updates the addressing format presented in RFC 3306. [STANDARDS-TRACK]IP Version 6 Addressing ArchitectureThis specification defines the addressing architecture of the IP Version 6 (IPv6) protocol. The document includes the IPv6 addressing model, text representations of IPv6 addresses, definition of IPv6 unicast addresses, anycast addresses, and multicast addresses, and an IPv6 node's required addresses.This document obsoletes RFC 3513, "IP Version 6 Addressing Architecture". [STANDARDS-TRACK]Source-Specific Multicast for IPIP version 4 (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. For IP version 6 (IPv6), the address prefix FF3x::/32 is reserved for source-specific multicast use. This document defines an extension to the Internet network service that applies to datagrams sent to SSM addresses and defines the host and router requirements to support this extension. [STANDARDS-TRACK]IANA Guidelines for IPv4 Multicast Address AssignmentsThis document provides guidance for the Internet Assigned Numbers Authority (IANA) in assigning IPv4 multicast addresses. It obsoletes RFC 3171 and RFC 3138 and updates RFC 2780. This memo documents an Internet Best Current Practice.Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)This document specifies Protocol Independent Multicast - Sparse Mode (PIM-SM). PIM-SM is a multicast routing protocol that can use the underlying unicast routing information base or a separate multicast-capable routing information base. It builds unidirectional shared trees rooted at a Rendezvous Point (RP) per group, and it optionally creates shortest-path trees per source.This document obsoletes RFC 4601 by replacing it, addresses the errata filed against it, removes the optional (*,*,RP), PIM Multicast Border Router features and authentication using IPsec that lack sufficient deployment experience (see Appendix A), and moves the PIM specification to Internet Standard.Use of Multicast across Inter-domain Peering PointsThis document examines the use of Source-Specific Multicast (SSM) across inter-domain peering points for a specified set of deployment scenarios. The objectives are to (1) describe the setup process for multicast-based delivery across administrative domains for these scenarios and (2) document supporting functionality to enable this process.Informative ReferencesIPv6 Multicast Address AssignmentsThis document defines the initial assignment of IPv6 multicast addresses. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.IP Multicast Applications: Challenges and SolutionsThis document describes the challenges involved with designing and implementing multicast applications. It is an introductory guide for application developers that highlights the unique considerations of multicast applications as compared to unicast applications. This memo provides information for the Internet community.Multicast Source Discovery Protocol (MSDP)The Multicast Source Discovery Protocol (MSDP) describes a mechanism to connect multiple IP Version 4 Protocol Independent Multicast Sparse-Mode (PIM-SM) domains together. Each PIM-SM domain uses its own independent Rendezvous Point (RP) and does not have to depend on RPs in other domains. This document reflects existing MSDP implementations.Border Gateway Multicast Protocol (BGMP): Protocol SpecificationThis document describes the Border Gateway Multicast Protocol (BGMP), a protocol for inter-domain multicast routing. BGMP builds shared trees for active multicast groups, and optionally allows receiver domains to build source-specific, inter-domain, distribution branches where needed. BGMP natively supports "source-specific multicast" (SSM). To also support "any-source multicast" (ASM), BGMP requires that each multicast group be associated with a single root (in BGMP it is referred to as the root domain). It requires that different ranges of the multicast address space are associated (e.g., with Unicast-Prefix-Based Multicast addressing) with different domains. Each of these domains then becomes the root of the shared domain-trees for all groups in its range. Multicast participants will generally receive better multicast service if the session initiator's address allocator selects addresses from its own domain's part of the space, thereby causing the root domain to be local to at least one of the session participants. This memo provides information for the Internet community.Considerations for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Snooping SwitchesThis memo describes the recommendations for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) snooping switches. These are based on best current practices for IGMPv2, with further considerations for IGMPv3- and MLDv2-snooping. Additional areas of relevance, such as link layer topology changes and Ethernet-specific encapsulation issues, are also considered. This memo provides information for the Internet community.Using Internet Group Management Protocol Version 3 (IGMPv3) and Multicast Listener Discovery Protocol Version 2 (MLDv2) for Source-Specific MulticastThe Internet Group Management Protocol Version 3 (IGMPv3) and the Multicast Listener Discovery Protocol Version 2 (MLDv2) are protocols that allow a host to inform its neighboring routers of its desire to receive IPv4 and IPv6 multicast transmissions, respectively. Source-specific multicast (SSM) is a form of multicast in which a receiver is required to specify both the network-layer address of the source and the multicast destination address in order to receive the multicast transmission. This document defines the notion of an "SSM-aware" router and host, and clarifies and (in some cases) modifies the behavior of IGMPv3 and MLDv2 on SSM-aware routers and hosts to accommodate source-specific multicast. This document updates the IGMPv3 and MLDv2 specifications. [STANDARDS-TRACK]Protocol Independent Multicast - Sparse Mode (PIM-SM) Multicast Routing Security Issues and EnhancementsThis memo describes security threats for the larger (intra-domain or inter-domain) multicast routing infrastructures. Only Protocol Independent Multicast - Sparse Mode (PIM-SM) is analyzed, in its three main operational modes: the traditional Any-Source Multicast (ASM) model, the source-specific multicast (SSM) model, and the ASM model enhanced by the Embedded Rendezvous Point (Embedded-RP) group-to-RP mapping mechanism. This memo also describes enhancements to the protocol operations that mitigate the identified threats. This memo provides information for the Internet community.Anycast-RP Using Protocol Independent Multicast (PIM)This specification allows Anycast-RP (Rendezvous Point) to be used inside a domain that runs Protocol Independent Multicast (PIM) only. Other multicast protocols (such as Multicast Source Discovery Protocol (MSDP), which has been used traditionally to solve this problem) are not required to support Anycast-RP. [STANDARDS-TRACK]Multicast Source Discovery Protocol (MSDP) Deployment ScenariosThis document describes best current practices for intra-domain and inter-domain deployment of the Multicast Source Discovery Protocol (MSDP) in conjunction with Protocol Independent Multicast Sparse Mode (PIM-SM). This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.Bidirectional Protocol Independent Multicast (BIDIR-PIM)This document discusses Bidirectional PIM (BIDIR-PIM), a variant of PIM Sparse-Mode that builds bidirectional shared trees connecting multicast sources and receivers. Bidirectional trees are built using a fail-safe Designated Forwarder (DF) election mechanism operating on each link of a multicast topology. With the assistance of the DF, multicast data is natively forwarded from sources to the Rendezvous-Point (RP) and hence along the shared tree to receivers without requiring source-specific state. The DF election takes place at RP discovery time and provides the route to the RP, thus eliminating the requirement for data-driven protocol events. [STANDARDS-TRACK]DNS-Based Service DiscoveryThis document specifies how DNS resource records are named and structured to facilitate service discovery. Given a type of service that a client is looking for, and a domain in which the client is looking for that service, this mechanism allows clients to discover a list of named instances of that desired service, using standard DNS queries. This mechanism is referred to as DNS-based Service Discovery, or DNS-SD.IPv6 Node RequirementsThis document defines requirements for IPv6 nodes. It is expected that IPv6 will be deployed in a wide range of devices and situations. Specifying the requirements for IPv6 nodes allows IPv6 to function well and interoperate in a large number of situations and deployments.This document obsoletes RFC 6434, and in turn RFC 4294.Acknowledgments
The authors would like to thank members of the IETF 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:
,
,
,
,
,
,
,
,
,
,
and
.
Authors' AddressesStockholmSwedenswmike@swm.pp.seJiscLumen House, Library AvenueHarwell OxfordDidcotOX11 0SGUnited Kingdomtim.chown@jisc.ac.ukJuniper Networks, Inc.2251 Corporate Park DriveHerndonVirginia20171United States of Americalenny@juniper.netFuturewei Technologies Inc.2330 Central ExpySanta ClaraCalifornia95050United States of Americatte@cs.fau.de