RFC 5186

RFC 5186 🦋 Internet Group Management Protocol Version 3 (IGMPv3) / Multicast Listener Discovery Version 2 (MLDv2) and Multicast Routing Protocol Interaction

okay bestie, let's get into the header first 💅 This one's from the Network Working Group, written by Brian Haberman (Johns Hopkins University) and Jim Martin (Woven Systems). It's Informational 🌸 and it's dated May 2008. The header doesn't list any RFCs it obsoletes or updates, so it's standing on its own ✨

---

Status of This Memo 🎀

This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.

Abstract 🔮

IGMPv3 and MLDv2 need new behavior from the multicast routing protocols 🙈 The extra source info in their messages means the routing protocols have to manage it and actually use it. This doc explains how multicast routing protocols will work with these source-filtering group management protocols 💜

1. Introduction ✨

okay so IGMPv3 [IGMP3] and MLDv2 [MLDv2] both need new behavior from the multicast routing protocols 😭 Their extra source information means those routing protocols have to manage it and use it. This doc describes how multicast routing protocols will interpret what they learn from these source-filtering group management protocols 🧚

2. Multicast Forwarding State 🌈

Existing multicast routing protocols check the group management database to see if there are local members for a multicast group 👀 With the older group management protocols, that database had just one kind of record: the group someone cared about, plus the local interfaces.

With IGMPv3 and MLDv2, routing protocols can now build multicast forwarding state from the source filter info for every group that has local membership. ngl that's so main character 💅 It means the group management database needs four record types. And only one record may exist for a given interface and a given multicast group 🔥

1. EXCLUDE <> 🌸 The EXCLUDE <> record means interest in all sources sent to this group address, for a set of local interfaces. It's the same as the single record type from the older versions of the group management protocols.
2. INCLUDE <> 🫶 The INCLUDE <> record means there is no interest in any sources sent to this group address, for a set of local interfaces.
3. EXCLUDE <list> ⭐ The EXCLUDE <list> record means interest in all sources except the ones specifically listed, for a set of local interfaces.
4. INCLUDE <list> 💖 The INCLUDE <list> record means interest in only the specifically listed sources, for a set of local interfaces.

The records in the group management database should be used when generating forwarding state for a multicast group. If the source address in a multicast packet is in the database for that group and is in an INCLUDE list, or isn't in an EXCLUDE list, the multicast routing protocol should add the interface to the downstream interfaces list. Otherwise, it should not be added based on local group membership 🦋

3. DVMRP Interaction 🍓

The Distance Vector Multicast Routing Protocol (DVMRP) [DVMRP] doesn't know anything about who the senders for a multicast group are 🙈 So DVMRP will only act on the multicast group address that's in an IGMPv3 or MLDv2 report.

Future standardized versions of DVMRP might add pruning and grafting messages like PIM-DM (more on that in Section 5) 👀 If they do, the rules in Section 5 can be applied in that situation ✨

4. MOSPF Interaction 🌊

In Multicast Extensions to OSPF (MOSPF) [MOSPF], source filter info in the group management database only gets used for building forwarding state (we just covered that above). The reason is that group-membership-LSAs get flooded within MOSPF 💅

5. PIM-DM Interaction 🎀

The PIM-DM protocol [PIMDM] matters a lot when it comes to a source-filtering group management protocol, in two areas: pruning and grafting the multicast distribution tree 😭 The next sections describe the behavior PIM-DM needs in order to work with IGMPv3 and MLDv2 🫶

5.1. PIM-DM Prunes 💜

PIM-DM prune messages get sent when a PIM-DM router decides that nobody is interested in the data flowing on the (S,G) forwarding state. If the multicast router is running IGMPv3 or MLDv2, that's determined by source S being in EXCLUDE state in the source filter for destination G. It also happens when all interest in G ends for an existing (S,G) forwarding entry ✨

5.2. PIM-DM Grafts 🔥

PIM-DM graft messages get sent to override an existing PIM-DM prune 💖 With IGMPv3 or MLDv2, this happens when prune state exists for (S,G) and the source filter state for S changes to INCLUDE for the specified G 👑

6. PIM-SM Interaction 🧚

A PIM-SM interaction happens when a PM-SM [PIMSM] router gets an IGMP or MLD message about a group address in the Any Source Multicast (ASM) range. That range is the whole multicast address space, minus the global SSM range [SSM] and any locally defined Source Specific space 🌈

6.1. PIM-SM Joins (ASM Behavior) 🌸

PIM-SM join messages get sent when a PIM-SM router decides there are entities interested in a specific group, or in a specific source sending to the group ✨ If that's triggered by an IGMPv3 or MLDv2 report with a zero-length EXCLUDE list, the join is sent as a (*,G) join toward the RP 💅

If the join is triggered by an IGMPv3 or MLDv2 state change that affects source information, the PIM-SM join is sent as an (S,G) join toward that specific source. This optimizes the join process and helps the SSM model get adopted 🦋 Sending this (S,G) join can cause failures in architectures where leaf routers don't have global reachability, so local policy can override it 😬 If that's the case, all triggered joins get sent toward the RP as (,G) joins. The router sending the (,G) join is responsible for filtering the data according to the IGMPv3 database before forwarding 🫶

6.2. PIM-SM Prunes (ASM Behavior) 💀

PIM-SM prune messages get sent when a PIM-SM router decides there's nobody interested in a specific group, or in a specific source sending to the group 🙈 If that's triggered by receiving a report with an EXCLUDE, or by a specific Source/Group timing out, then an (S,G) prune gets sent toward the upstream router. If all of the IGMPv3 or MLDv2 derived requests for a group time out, then (S,G) and (*,G) prunes get sent upstream as needed to stop all traffic for that group 🛑

7. PIM-SSM Interaction 💜

A PIM-SSM interaction happens when a PIM-SM router gets an IGMPv3 or MLDv2 message about a group address in the Source Specific Multicast range. This behavior isn't defined in this document. It's defined in [PIMSM] instead 🧚

8. Security Considerations 🚨

💀 Security check, bestie! This document does not introduce any additional security issues above and beyond those already discussed in [PIMDM], [PIMSM], [IGMP3], and [MLDv2]. Go read those, they're the real deal 🔥

9. Acknowledgements 🫶

The authors would like to thank Murali Brahmadesam, Leonard Giuliano, and Hal Sandick for their feedback and suggestions 💖

10. Normative References 📚

• [IGMP3] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, October 2002.
• [MLDv2] Vida, R., Ed., and L. Costa, Ed., "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
• [DVMRP] Waitzman, D., Partridge, C., and S. Deering, "Distance Vector Multicast Routing Protocol", RFC 1075, November 1988.
• [MOSPF] Moy, J., "Multicast Extensions to OSPF", RFC 1584, March 1994.
• [PIMDM] Adams, A., Nicholas, J., and W. Siadak, "Protocol Independent Multicast - Dense Mode (PIM-DM): Protocol Specification (Revised)", RFC 3973, January 2005.
• [PIMSM] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", RFC 4601, August 2006.
• [SSM] Holbrook, H. and B. Cain, "Source-Specific Multicast for IP", RFC 4607, August 2006.

Authors' Addresses 🏡

Brian Haberman
The Johns Hopkins University Applied Physics Laboratory
11100 Johns Hopkins Road
Laurel, MD  20723-6099
US

Phone: +1 443 778 1319
EMail: brian@innovationslab.net

Jim Martin
Woven Systems
2455 Augustine Drive, Suite 211
Santa Clara, CA  95054
US

Phone: +1 408 654-8143
EMail: jim@wovensystems.com

Full Copyright Statement ©️

Copyright (C) The IETF Trust (2008).

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property 🔐

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document, or the extent to which any license under such rights might or might not be available. It also doesn't represent that it has made any independent effort to identify any such rights. Information on the procedures for rights in RFC documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat, and any assurances of licenses to be made available, or the result of an attempt to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification, can be obtained from the IETF online IPR repository at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org 💌