RFC 4608

Source-Specific Protocol Independent Multicast in 232/8 ✨

Okay bestie, this is RFC 4608 🎀. It's a Best Current Practice (BCP 120), so it's the community's recommended way of doing things rather than a brand new protocol. It came out in August 2006 from the Network Working Group, and the authors are David Meyer, Robert Rockell, and Greg Shepherd 💖. The title block doesn't list anything it obsoletes or updates.

---

Status of This Memo 📜

This document is an Internet Best Current Practices doc for the Internet Community, and it's asking for discussion and suggestions to make it better 🌸. Distribution of this memo is unlimited.

Copyright Notice ⚖️

Copyright (C) The Internet Society (2006).

Abstract 🦋

okay so the IP Multicast group range 232/8 (that's 232.0.0.0 to 232.255.255.255) is designated for source-specific multicast and reserved for SSM apps and protocols 💅. This doc lays out operational recommendations so that behaviour stays source-specific inside that range 🫶.

Table of Contents 🗂️

1. Introduction ....................................................2
   1.1. BCP, Experimental Protocols, and Normative References ......2
2. Operational practices in 232/8 ..................................4
   2.1. Preventing Local Sources from Sending to Shared Tree .......4
   2.2. Preventing Remote Sources from Being Learned/Joined
        via MSDP ...................................................4
   2.3. Preventing Receivers from Joining the Shared Tree ..........4
   2.4. Preventing RPs as Candidates for 232/8 .....................5
3. Acknowledgements ................................................5
4. Security Considerations .........................................5
5. References ......................................................6
   5.1. Normative References .......................................6
   5.2. Informative References .....................................6

---

1. Introduction 💫

okay so PIM-SM [RFC4601] leans on the shared Rendezvous Point (RP) tree to find out about active sources for a group, and it's what supports the group-generic (Any Source Multicast or ASM) data distribution 🧚. The 232/8 range has been set aside for Source-Specific Multicast [RFC3569] apps and protocols [IANA], and the range SHOULD support source-only trees only ✨. That means no RP and no shared tree are needed, and active sources in 232/8 get discovered out of band 🍓. PIM Sparse Mode Designated Routers (DR) with local membership can join the shortest path tree for the source directly, using the SSM functionality of PIM-SM 👑.

We need operational best common practices for the 232/8 range so that shortest path source-only trees work across multiple domains in the Internet [RFC3569]. They also stop data from sources sending to groups in 232/8 from arriving via shared trees 🙈. Basically this avoids unwanted data arrival and lets several sources use the same group address without conflicts at the receivers 💜.

The operational practices SHOULD:

• Prevent local sources from sending to shared tree 🌈
• Prevent receivers from joining the shared tree 🌈
• Prevent RPs as candidates for 232/8 🌈
• Prevent remote sources from being learned/joined via Multicast Source Discovery Protocol (MSDP) [RFC3618] 🌈

1.1. BCP, Experimental Protocols, and Normative References 📚

This doc describes the best current practice for a widely deployed Experimental protocol, which is MSDP 🦋. There is no plan to advance MSDP's status (for example, to Proposed Standard), and the reasons are:

• MSDP was originally meant to be a temporary protocol, to be replaced by whatever the Inter-Domain Multicast Routing (IDMR) working group produced as an inter-domain protocol. But the IDMR WG (or later, the Border Gateway Multicast Protocol (BGMP) WG) never made a protocol that could be deployed to replace MSDP 😭.
• One of the main reasons MSDP got classified as Experimental is that the MSDP Working Group came up with changes that they thought made it better, but implementors didn't see a reason to deploy them. Without those changes (e.g., UDP or GRE encapsulation), MSDP can have negative consequences for the initial packets in datagram streams 💀.
• Scalability: Although we don't know what the hard limits might be, readvertising everything you know every 60 seconds clearly limits the amount of state you can advertise 🫠.
• MSDP reached nearly ubiquitous deployment as the de facto standard inter-domain multicast protocol in the IPv4 Internet 👑.
• No consensus could be reached on reworking MSDP to address the many concerns of various constituencies within the IETF. So a decision was made to document what is (ubiquitously) deployed and move that document to Experimental. Advancing MSDP to Proposed Standard was considered, but for the reasons above it was immediately discarded 🙅‍♀️.
• Protocols like source-specific multicast and bi-directional PIM, plus embedded RP techniques for IPv6, have further reduced consensus that a replacement protocol for MSDP is needed for the IPv4 Internet 🌸.

The RFC Editor's policy on references is that they get split into two categories, called "normative" and "informative". Normative references specify the documents that must be read to understand or implement the technology in an RFC (or whose technology must be present for the technology in the new RFC to work) [RFCED]. To understand this document you also have to understand both the PIM [RFC4601] and MSDP [RFC3618] documents, so references to those are normative 🧠.

The IETF has adopted the policy that BCPs must not have normative references to Experimental protocols. But this document is a special case, because the underlying Experimental document (MSDP) isn't planned to be advanced to Proposed Standard 🎀.

The MBONED Working Group requested approval under the Variance Procedure, as documented in RFC 2026 [RFC2026]. The IESG followed the Variance Procedure and, after an additional 4-week IETF Last Call, evaluated the comments and status and approved the document 🥳.

The key words "MUST"", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119] 🫶.

---

2. Operational practices in 232/8 🛠️

2.1. Preventing Local Sources from Sending to Shared Tree 🚫

To get rid of shared trees for groups in 232/8, while still coexisting with ASM in PIM-SM, the behaviour of the RP and/or the DR needs to change 💅. This can be done by:

• preventing data for 232/8 groups from being sent encapsulated to the RP by the DR, 🎀
• preventing the RP from accepting registers for 232/8 groups from the DR, and 🎀
• preventing the RP from forwarding accepted data down (*,G) tree for 232/8 groups. 🎀

2.2. Preventing Remote Sources from Being Learned/Joined via MSDP 🙅‍♀️

SSM doesn't need active source announcements via MSDP 🦋. All source announcements get received out of band, and the last hop router is responsible for sending (S,G) joins straight to the source. To stop SAs in the 232/8 range from propagating, an RP SHOULD:

• never originate an SA for any 232/8 groups, and
• never accept or forward an SA for any 232/8 groups.

2.3. Preventing Receivers from Joining the Shared Tree 🙈

Local PIM domain practices need to be enforced so local receivers can't join the shared tree for 232/8 groups 🔒. This can be done by:

• preventing DR from sending (*,G) joins for 232/8 groups, and 🍃
• preventing RP from accepting (*,G) join for 232/8 groups. 🍃

But inside a local PIM domain, any last-hop router NOT preventing (,G) joins may trigger unwanted (,G) state toward the RP that intersects an existing (S,G) tree 😱. That lets the receiver on the shared tree get the data, which breaks the source-specific [RFC3569] service model. So it's recommended that ALL routers in the domain MUST reject AND never originate (*,G) joins for 232/8 groups 🚨.

In cases where an ISP is offering its customers (or others) the use of the ISP's RP, the ISP SHOULD NOT allow (*,G) joins in the 232/8 range 🙅‍♀️.

2.4. Preventing RPs as Candidates for 232/8 🙅

Because SSM doesn't need an RP, all RPs SHOULD NOT offer themselves as candidates in the 232/8 range 💅. This can be done by:

• preventing RP/BSR from announcing in the 232/8 range, 🍑
• preventing ALL routers from accepting RP delegations in the 232/8 range, and 🍑
• precluding RP functionality on RP for the 232/8 range. 🍑

Note that in typical practice, RPs announce themselves as candidates for the 224/4 range (which obviously includes 232/8) 🤓. It's still acceptable to allow the advertisement of 224/4 (or any other superset of 232/8). But this approach relies on the second point above, namely that routers silently ignore the RP delegation in the 232/8 range and prevent sending or receiving using the shared tree, as described earlier 🫠. Finally, an RP SHOULD NOT be configured as a candidate RP for 232/8 (or for a more specific range) ✨.

Part 2 picks up with Acknowledgements, Security Considerations, and References 🌈💖

Full Copyright Statement 💖

Copyright (C) The Internet Society (2006). 🎀

Okay so this document is subject to the rights, licenses and restrictions in BCP 78, and except as set forth there, the authors keep all their rights. 🦋

⚠️ This document and the information in it are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY 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 on whether any Intellectual Property Rights or other rights that someone might claim over the technology in this document are valid or in scope, or on whether licenses for those rights are available, and it hasn't made any independent effort to find such rights. 🔍 If you want the details on how rights work for RFC documents, check out BCP 78 and BCP 79. 📚

Copies of IPR disclosures sent to the IETF Secretariat, plus any assurances of licenses that will be made available, are in the IETF's online IPR repository at http://www.ietf.org/ipr. The same goes for the results of any attempt to get a general license or permission for implementers or users of this specification to use the proprietary rights. ✨

The IETF also invites anyone interested to tell it about any copyrights, patents, patent applications, or other proprietary rights that might cover technology needed to implement this standard. 💌 Send that info to the IETF at ietf-ipr@ietf.org. 🫶

---

Acknowledgement 🧚

Funding for the RFC Editor function comes from the IETF Administrative Support Activity (IASA). 💅