RFC 8815
Deprecating Any-Source Multicast (ASM) for Interdomain Multicast
RFC 8815: Deprecating Any-Source Multicast (ASM) for Interdomain Multicast 🎀
okay bestie, this one is a Best Current Practice (that's BCP 229 🧚), published in August 2020 by the IETF. The authors are M. Abrahamsson, T. Chown (Jisc), L. Giuliano (Juniper Networks, Inc.), and T. Eckert (Futurewei Technologies Inc.). It's ISSN 2070-1721, and the title block doesn't list anything it obsoletes or updates. So it's a fresh recommendation, no drama 💅
Abstract ✨
so the big idea is that this doc recommends deprecating Any-Source Multicast (ASM) for interdomain multicast. instead, it recommends Source-Specific Multicast (SSM) for interdomain apps, and says hosts and routers in these deployments should fully support SSM 🫶 the vibe is that none of this stops you from still using ASM inside one organization or domain. it's also super easy to adopt if you already run intradomain ASM with PIM Sparse Mode (PIM-SM) 🌸
Status of This Memo 📜
this memo documents an Internet Best Current Practice 🎀
this is an IETF product, so it represents the consensus of the IETF community. it got public review and was approved for publication by the Internet Engineering Steering Group (IESG). if you want more info on BCPs, check Section 2 of RFC 7841 🧚
for the current status, any errata, or to send feedback, go to https://www.rfc-editor.org/info/rfc8815 💖
Copyright Notice 🦋
Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved. 🌈
this doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info), as they were in effect on the date it was published. please read these carefully because they spell out your rights and restrictions for this doc 📜 also, any code components pulled from this doc must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions. they come without warranty, as described in the Simplified BSD License 💅
Table of Contents 🗂️
1. Introduction
2. Background
2.1. Multicast Service Models
2.2. ASM Routing Protocols
2.2.1. PIM Sparse Mode (PIM-SM)
2.2.2. Embedded-RP
2.2.3. BIDIR-RP
2.3. SSM Routing Protocols
3. Discussion
3.1. Observations on ASM and SSM Deployments
3.2. Advantages of SSM for Interdomain Multicast
3.2.1. Reduced Network Operations Complexity
3.2.2. No Network-Wide IP Multicast Group-Address Management
3.2.3. Intrinsic Source-Control Security
4. Recommendations
4.1. Deprecating Use of ASM for Interdomain Multicast
4.2. Including Network Support for IGMPv3/MLDv2
4.3. Building Application Support for SSM
4.4. Developing Application Guidance: SSM, ASM, Service
Discovery
4.5. Preferring SSM Applications Intradomain
4.6. Documenting an ASM/SSM Protocol Mapping Mechanism
4.7. Not Filtering ASM Addressing between Domains
4.8. Not Precluding Intradomain ASM
4.9. Evolving PIM Deployments for SSM
5. Future Interdomain ASM Work
6. Security Considerations
7. IANA Considerations
8. References
8.1. Normative References
8.2. Informative References
Acknowledgments
Authors' Addresses1. Introduction 🌸
IP Multicast has shown up in all sorts of places: private networks, the wider Internet, and federated networks like national or regional research networks. a bunch of service models have been published (and revised over time), but the IETF never gave a strong recommendation on which models fit which scenarios. vendors and federations have totally stepped in with their own recommendations though 🙈
so this doc fills that gap with a BCP-level recommendation to deprecate ASM for interdomain multicast, leaving SSM as the recommended interdomain mode. that means all hosts and routers that support interdomain multicast apps should fully support SSM 🔥
this doc says nothing about ASM within a single domain or organization, so it doesn't stop you from using it there. honestly, there are plenty of app contexts where ASM is still widely considered a great fit inside one domain 💖
the main blocker for moving to SSM is application support. lots of apps start out for intradomain use and only go interdomain later 🧚 so this doc recommends that apps support SSM even when they're first meant for intradomain use. the best part is that SSM apps play nicely with existing intradomain ASM deployments that use PIM-SM, because PIM-SSM is just a subset of PIM-SM 🦋
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, the way it was 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 a group has multiple senders, traffic from all of them gets delivered to the receivers. since receivers only specify the group address, the network (and therefore the multicast routing protocols) is responsible for source discovery 🫠
SSM is the opposite energy 💅 receivers specify both the group and the source when they express interest in joining a multicast stream. source discovery in SSM is handled by some out-of-band mechanism, which is typically in the application layer. that 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 are in [RFC5771], and guidelines for IPv6 multicast address assignments are 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), detailed in [RFC7761] 💜 as the name suggests, PIM-SM was designed for scenarios where the subnets with receivers are sparsely distributed throughout the network. receivers don't indicate sender addresses in ASM (only group addresses), so PIM-SM uses a Rendezvous Point (RP) as a "meeting point" for sources and receivers. all routers in a PIM-SM domain are configured to use a specific RP (or RPs), either explicitly or through dynamic RP-discovery protocols 🫶
to get PIM-SM working across multiple domains, there's an interdomain, inter-RP signaling protocol called Multicast Source Discovery Protocol (MSDP) [RFC3618]. it lets an RP in one domain learn about a source in another domain. deployment scenarios for MSDP are in [RFC4611] 🌸 here's the tea though: MSDP floods info about all active sources for all multicast streams to all RPs in all the domains, even when nobody in a domain wants the stream 😭 that's a key scalability and security issue, and along with other deployment challenges, MSDP was never extended to support IPv6. it also remains an Experimental protocol 💀
so at the time of writing, there's no IETF interdomain solution at the Proposed Standard level for IPv4 ASM multicast. MSDP was the de facto mechanism for interdomain source discovery, and it's still Experimental. other protocol options were looked into around the same time, but they were never implemented or deployed, and they're now historic (e.g., [RFC3913]) 🕰️
2.2.2. Embedded-RP 🧚
IPv6 has more bits in its addresses than IPv4 does, so an IPv6-specific mechanism was designed to support interdomain ASM, with PIM-SM leveraging those bits 🦋 Embedded-RP [RFC3956] lets routers that support it figure out the RP for a group without any prior configuration or discovery protocols. they just look at the unicast RP address that's embedded (included) in the IPv6 multicast group address 🎀 Embedded-RP lets PIM-SM operate across any IPv6 network with an end-to-end path of routers that support this mechanism, including interdomain deployments ✨
2.2.3. BIDIR-RP 💜
BIDIR-PIM [RFC5015] is another protocol that supports ASM 🌈 there's no standardized option to run BIDIR-PIM interdomain. it's deployed intradomain for apps where many sources send traffic to the same IP multicast groups, because unlike PIM-SM, it doesn't create per-source state 🫶 BIDIR-PIM is one of the big reasons this doc doesn't deprecate intradomain ASM 👑
2.3. SSM Routing Protocols 🔥
SSM is detailed in [RFC4607] 💅 it mandates the use of PIM-SSM for routing SSM traffic, and PIM-SSM is merely a subset of PIM-SM [RFC7761] 🧚
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). so the receiver's designated router can send a PIM Join message directly toward the source without needing to use an RP 🌸 no RP drama, just straight to the source ✨
IPv4 addresses in the 232/8 range (232.0.0.0 to 232.255.255.255) are designated as Source-Specific Multicast (SSM) destination addresses, and they're reserved for source-specific apps and protocols 🎀 for IPv6, the address prefix ff3x::/32 is reserved for source-specific multicast use. see [RFC4607] for more 💖
3. Discussion 🫧
3.1. Observations on ASM and SSM Deployments 🔍
Okay so, in enterprise and campus networks, ASM in the form of PIM-SM is probably the most commonly deployed multicast protocol 🏢. Configuring and managing an RP (including RP redundancy) inside a single domain is a well-understood operational practice, so it's pretty chill. 😌 BUT, if you need to talk to external PIM domains in IPv4 multicast deployments, interdomain MSDP is required to swap info about sources between domain RPs. Deployment experience has shown MSDP to be a complex and fragile protocol to manage and troubleshoot 😭. Some of the issues are complex Reverse Path Forwarding (RPF) rules, state attack protection, and filtering out undesired sources. Literally a headache.
PIM-SM is a general-purpose protocol that can handle all the use cases 💖. It was designed for stuff like videoconferencing, where multiple sources might come and go during a multicast session. But for cases where there's a single, persistent source for a group, and receivers can be configured to know about that source, PIM-SM has unnecessary complexity 🙄. So SSM removes the need for many of the most complex parts of PIM-SM. Main character move. ✨
As explained above, MSDP was not extended to support IPv6. Instead, the proposed interdomain ASM solution for PIM-SM with IPv6 is Embedded-RP 🧚. It lets the RP address for a multicast group be embedded in the group address, so RP discovery is automatic for all routers on the path between a receiver and a sender. Embedded-RP can support lightweight ad hoc deployments, which is iconic. However, it relies on a single RP for an entire group, and that could only be made resilient within one domain. So while it 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 the biggest problems of interdomain multicast 🚨. Not me being dramatic, it's just true.
As stated in RFC 4607, SSM is particularly well suited to two kinds of stuff. First, dissemination-style applications with one or more senders whose identities are known (through some out-of-band mechanism) before the application starts running. Second, applications that use some signaling to indicate the source address of the multicast stream, like an electronic programming guide in IPTV applications 📺. So SSM through PIM-SSM is very well suited to things like classic linear-broadcast TV over IP. Perfect for TV energy. 🎀
SSM requires applications, host operating systems, and the designated routers connected to receiving hosts to support Internet Group Management Protocol, Version 3 (IGMPv3) [RFC3376] and Multicast Listener Discovery, Version 2 (MLDv2) [RFC3810]. Support for IGMPv3 and MLDv2 has been commonplace in routing platforms for a long time, and it's also now widespread in common operating systems (Windows, Mac OS, Linux/Android) for several years. So it is no longer an impediment to SSM deployment 🙌.
3.2. Advantages of SSM for Interdomain Multicast 💅
This section covers the three key benefits that SSM with PIM-SSM has over ASM 👑. These benefits also apply to intradomain deployments, but they matter even more in interdomain deployments. See [RFC4607] for more details.
3.2.1. Reduced Network Operations Complexity 🧠
The big win with SSM is less complexity, because it gets rid of the network-based source discovery that ASM with PIM-SM needs 🙃. 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 just uses a small subset of PIM-SM, plus the integration with IGMPv3/MLDv2, where the source address signaled from the receiver is immediately used to create (S,G) state. Getting rid of network-based source discovery for interdomain multicast means the vast majority of multicast's complexity just goes away 🫶.
This reduced complexity makes SSM radically simpler to manage, troubleshoot, and operate, especially for backbone network operators 💀. This is the main operator motivation behind the recommendation to deprecate ASM in interdomain scenarios.
Note that this discussion does not apply to BIDIR-PIM, and (as mentioned above) there is no standardized interdomain solution for BIDIR-PIM. With BIDIR-PIM, traffic is forwarded to the RP instead of building state like PIM-SM does. This happens even in the absence of receivers. So BIDIR-PIM is a trade-off: less state complexity, but at the cost of creating unnecessary traffic, which can be a large amount 🌈.
3.2.2. No Network-Wide IP Multicast Group-Address Management 🌸
With ASM, IP multicast group addresses need to be assigned to applications and their instances, so that two simultaneously active application instances won't share the same group address and end up receiving IP multicast traffic from each other 😵💫.
With SSM, no such IP multicast group management is necessary 🎉. Instead, the IP multicast group address just needs to be assigned locally on a source, kind of like a unicast transport protocol port number. The only coordination required is making sure different applications running on the same host don't send to the same group address. This does not require any network-operator involvement. Zero drama. 💜
3.2.3. Intrinsic Source-Control Security 🔐
SSM is implicitly secure against off-path unauthorized or undesired sources 🛡️. Receivers only get packets from the sources they explicitly specify in their IGMPv3/MLDv2 membership messages. Compare that with ASM, where any host can send traffic to a group address and have it transmitted to all receivers. With PIM-SSM, traffic from sources that no receiver requested will be discarded by the First-Hop Router (FHR) of that source, which minimizes source attacks against shared network bandwidth and receivers. Chef's kiss 🤌.
This benefit is especially important for interdomain deployments, because there are no standardized solutions for ASM control of sources. The most common intradomain operational practices, like Access Control Lists (ACLs) on the sender's FHR, are not feasible for interdomain deployments 🙅♀️.
This topic is expanded upon in [RFC4609].
4. Recommendations ✨
This section gives recommendations for a bunch of stakeholders in SSM deployment, including vendors, operators, and application developers 🧑💻. It also suggests further work that could be undertaken within the IETF.
4.1. Deprecating Use of ASM for Interdomain Multicast 🚫
This document recommends that the use of ASM be deprecated for interdomain multicast. So, implicitly, it recommends that hosts and routers that support these 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.
In the context of this document, an interdomain use of ASM multicast 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 deprecating interdomain ASM multicast. While it encourages the use of SSM within domains, it leaves operators free to choose ASM within their own domains 🦋. A more inclusive reading of this recommendation also extends to deprecating ASM when PIM is operated in a single operator domain, but user hosts or non-PIM network edge devices are under different operator control. A typical example is a service provider offering IPTV (single operator domain for PIM) to subscribers who run an IGMP proxy home gateway and IGMPv3/MLDv2 hosts (computers, 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] that are needed for SSM (that is, explicitly sending source-specific reports) 📨. "IPv6 Node Requirements" [RFC8504] states that MLDv2 must be supported in all implementations. This support is already widespread in common host and router platforms, so it's not a big ask 😤.
Further guidance on IGMPv3 and MLDv2 is given in [RFC4604].
Multicast snooping is often used to limit the flooding of multicast traffic in a Layer 2 network 🌊. With snooping, an L2 switch monitors IGMP/MLD messages and only forwards multicast traffic out of host ports that have interested receivers connected. So that snooping capability should support IGMPv3 and MLDv2 too. There's more discussion in [RFC4541].
4.3. Building Application Support for SSM 🛠️
The recommendation to use SSM for interdomain multicast means applications should properly trigger the sending of IGMPv3/MLDv2 source-specific report messages. Ngl, though, there's a wide range of applications today that only support ASM. In many cases this happens because application developers don't know about the operational concerns of networks, or what the implications of ASM versus SSM are 😬. This document gives clear direction for application developers who might currently only consider ASM, so they can support SSM instead. For many applications, especially ones with single sources, it only takes relatively minor changes. Glow-up time ✨.
It's often thought that ASM is required for multicast applications with multiple sources. But 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 networks can feasibly manage. That's true whether source discovery is done by ASM with PIM-SM or at the application level with SSM/PIM-SSM 🥵. These applications aren't best supported by either SSM/PIM-SSM or ASM/PIM-SM.
Instead, these applications are better served by routing protocols that don't create (S,G) state, such as BIDIR-PIM 💫. Unfortunately, lots of applications today use ASM solely for service discovery. One example is where clients send IP multicast packets to get unicast replies from server(s). Deploying any form of IP multicast solely to support that kind of service discovery is, in general, not recommended 🙅. Dedicated service discovery via DNS-based Service Discovery (DNS-SD) [RFC6763] should be used for this instead.
This document describes best practices that explain when to use SSM in applications -- for example, 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 🌷.
4.5. Preferring SSM Applications Intradomain ✨
okay so, if it's feasible, it's recommended that apps use SSM even if they're only meant to run inside a domain that supports ASM 💅. PIM-SSM is basically a subset of PIM-SM, so existing intradomain PIM-SM networks are automatically compatible with SSM apps 🫶. That means SSM apps and existing ASM apps can totally coexist 🌸. SSM's perks, simplified address management and way less operational complexity, apply just as much inside a domain as between them 🔥.
BUT, for some apps it might be prohibitively difficult to add source discovery support, so intradomain ASM may still be appropriate 😭.
4.6. Documenting an ASM/SSM Protocol Mapping Mechanism 🦋
so for existing ASM apps that can't easily be ported to SSM, it may be possible to use some form of protocol mapping 🧚. That means having a mechanism that translates a (*,G) join or leave into an (S,G) join or leave for a specific source S. The big challenge is figuring out where the configured source address, S, actually comes from 🤔.
There are vendor-specific mechanisms already deployed that do this, but none of them are documented in IETF documents 💀. This could be a useful area for the IETF to work on as an interim transition mechanism ✨. Still, these mechanisms bring extra administrative burdens, plus the need for some form of address management, and SSM doesn't require either of those 🙈. So 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 👑. So the group address doesn't need to be globally unique, which means there's no need for multicast address allocation as long as the reserved SSM range is used 💜.
Even though interdomain ASM is deprecated, it is recommended that operators not filter ASM group ranges at domain boundaries 🍓. Some form of ASM-SSM mappings may keep being used for a while, so don't slam that door shut yet 🫶.
4.8. Not Precluding Intradomain ASM 🎀
ASM inside a single multicast domain, like a campus or enterprise, is still pretty common today 💖. There are even global enterprise networks that have been running PIM-SM successfully for many years 🔥. The operators of those networks most often use Anycast-RP [RFC4610] or MSDP (with IPv4) for RP resilience, at the cost of extra operational complexity 😅. These existing practices are unaffected by this document ✨.
In the past decade, some BIDIR-PIM deployments have scaled interdomain ASM beyond the capabilities of PIM-SM 🚀. This is also unaffected by this document. Instead, BIDIR-PIM is encouraged where necessary due to application requirements (see Section 4.4) 🦋.
This document also doesn't preclude continued use of ASM with multiple PIM-SM domains inside organizations, like with IPv4 MSDP or IPv6 Embedded-RP 🌸. That includes organizations that are federations and have appropriate, nonstandardized 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 run SSM apps 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 turn it on 🌈. This means ASM apps can migrate to SSM/PIM-SSM through application-side development alone, handling source signaling via IGMPv3/MLDv2 and using SSM addresses 💖. No network actions are required for this transition, and unchanged ASM apps can keep coexisting 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 isn't standardized, it depends on implementation, and it 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 it may not result in forwarding of any traffic 💀.
Note that these migration recommendations don't cover when or how to move intradomain apps best served by ASM/BIDIR-PIM from PIM-SM to BIDIR-PIM 📝. That may also be important, but it's outside the scope of this document 🍓.
5. Future Interdomain ASM Work 🔮
future work may try to overcome current ASM limitations, like interdomain deployment solutions for BIDIR-PIM or source-access-control mechanisms for IPv6 PIM-SM with embedded-RP 🛠️. Such work could modify or amend this document's recommendations, 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 Section 3.2) 😤. So this document recommends that future work for general-purpose interdomain IP multicast focus on the SSM items listed in Section 4 💯.
6. Security Considerations 🔐
This document adds no new security considerations ✨. Instead, it removes security issues that come with interdomain ASM over PIM-SM/MSDP, like infrastructure control-plane attacks and application and bandwidth/congestion attacks from unauthorized sources sending to ASM multicast groups 😱.
Serious bestie moment: those attacks are no joke. Unauthorized sources can flood ASM groups and mess with the control plane, and SSM is how you shut that down. RFC 4609 describes the additional security benefits of using SSM instead of ASM 🔒.
7. IANA Considerations 📋
This document has no IANA actions 🌸.
8. References 📚
8.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>.
[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>.
[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>.
[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>.
[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>.8.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>.
[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>.
[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>.
[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>.
[RFC8504] Chown, T., Loughney, J., and T. Winters, "IPv6 Node
Requirements", BCP 220, RFC 8504, DOI 10.17487/RFC8504,
January 2019, <https://www.rfc-editor.org/info/rfc8504>.Acknowledgments 🫶
the authors want to thank members of the IETF MBONE Deployment Working Group for discussions on the content of this document 💜. Special 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 👑✨.
Authors' Addresses 🎀
okay so this is the last bit, and it's literally just who wrote this and how to reach them 💅 these four are the squad behind it 🫶
Mikael Abrahamsson 🦋 is first, based in Stockholm 🌸
Mikael Abrahamsson
Stockholm
Sweden
Email: swmike@swm.pp.seTim Chown 🌈 is next, at Jisc, out in Didcot, UK 🧚
Tim Chown
Jisc
Harwell Oxford
Lumen House, Library Avenue
Didcot
OX11 0SG
United Kingdom
Email: tim.chown@jisc.ac.ukLenny Giuliano 🍓 is at Juniper Networks, Inc. in Herndon, Virginia, USA ✨
Lenny Giuliano
Juniper Networks, Inc.
2251 Corporate Park Drive
Herndon, Virginia 20171
United States of America
Email: lenny@juniper.netAnd last but definitely not least, Toerless Eckert 👑 is at Futurewei Technologies Inc. in Santa Clara, California 💜
Toerless Eckert
Futurewei Technologies Inc.
2330 Central Expy
Santa Clara, California 95050
United States of America
Email: tte@cs.fau.de📦 where this page comes from
- ietf: rfc8815 2020-08
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms