RFC 2365

RFC 2365: Administratively Scoped IP Multicast 🦋

Okay bestie, this is RFC 2365, called Administratively Scoped IP Multicast. It came out of the Network Working Group in July 1998, written by D. Meyer from the University of Oregon. It's a Best Current Practice (that's BCP 23, if you're keeping track 💅). The header doesn't list any RFCs it obsoletes or updates, so it's standing on its own, no cap 🫶

Status of this Memo ✨

This doc specifies an Internet Best Current Practices for the Internet Community, and it's asking for discussion and suggestions for improvements 🎀 Distribution of this memo is unlimited, so share it with everyone 💖

Copyright Notice 🌸

Copyright (C) The Internet Society (1998). All Rights Reserved.

1. Abstract ✨

This doc defines the "administratively scoped IPv4 multicast space" as the range 239.0.0.0 to 239.255.255.255 🌈 It also describes a simple set of semantics for implementing Administratively Scoped IP Multicast, and it gives a mapping between the IPv6 multicast address classes [RFC1884] and the IPv4 multicast address classes. Iconic work 👑

This memo is a product of the MBONE Deployment Working Group (MBONED) in the Operations and Management Area of the Internet Engineering Task Force. Send comments to <mboned@ns.uoregon.edu> or to the author 💌

2. Acknowledgments 🫶

A lot of this memo comes from "Administratively Scoped IP Multicast", by Van Jacobson and Steve Deering, presented at the 30th IETF in Toronto, Canada, on 25 July 1994. Steve Casner, Mark Handley and Dave Thaler also gave insightful comments on earlier versions of this document, so shoutout to them 🧚

3. Introduction 🌸

Okay so, most current IP multicast implementations get some level of scoping by using the TTL field in the IP header 💅 Typical MBONE (Multicast Backbone) usage has been to set up TTL thresholds that keep traffic inside some administratively defined topological region. The basic forwarding rule for interfaces with configured TTL thresholds is that a packet doesn't get forwarded across the interface unless its remaining TTL is greater than the threshold. It's giving rules, but also a little bit of chaos 🙈

TTL scoping has been used to control how multicast traffic gets distributed, either to ease the stress on scarce resources (like bandwidth), or to get some kind of improved privacy or scaling properties ✨ On top of that, the TTL is also used in its traditional role of limiting datagram lifetime. So you've got these roles that often clash with each other, and TTL scoping has proven hard to implement reliably. The schemes that came out of it have often been complex and hard to understand 😭

Now here's the bigger architectural problem 💀 It's about how TTL scoping interacts with broadcast and prune protocols (for example DVMRP [DVMRP]). In lots of common cases, TTL scoping can stop pruning from working. Picture this: a packet either has its TTL expire, or it fails a TTL threshold. The router that throws that packet away can't prune any upstream sources, so it ends up sinking all multicast traffic, even if there are no downstream receivers who care. You might think, "just send prunes upstream from the point where the packet got discarded," but that can throw away legit traffic, because later packets could take a different path and reach the same point with a larger TTL 😤

On the other hand, administratively scoped IP multicast can give clear and simple semantics for scoped IP multicast ✨ Its key properties are that (i). packets addressed to administratively scoped multicast addresses do not cross configured administrative boundaries, and (ii). administratively scoped multicast addresses are locally assigned, so they aren't required to be unique across administrative boundaries. Main character energy, honestly 👑

4. Definition of the Administratively Scoped IPv4 Multicast Space 🎀

The administratively scoped IPv4 multicast address space is defined as the range 239.0.0.0 to 239.255.255.255 🦋

5. Discussion 💜

To support administratively scoped IP multicast, a router should support configuring per-interface scoped IP multicast boundaries 🌈 A router like this is called a boundary router, and it doesn't forward packets that match an interface's boundary definition in either direction. (That bi-directional check is what prevents problems on multi-access networks, so it's doing real work 🫶) A boundary router also always prunes the boundary for dense-mode groups [PIMDM], and it doesn't accept joins for sparse-mode groups [PIMSM] in the administratively scoped range 🔥

6. The Structure of the Administratively Scoped Multicast Space 💅

The structure of the IP version 4 administratively scoped multicast space is loosely based on the IP Version 6 Addressing Architecture from RFC 1884 [RFC1884] 🧚 This doc defines two important scopes: the IPv4 Local Scope and the IPv4 Organization Local Scope. We'll go through both of them below 🌸

6.1. The IPv4 Local Scope -- 239.255.0.0/16 💖

239.255.0.0/16 is defined as the IPv4 Local Scope. The Local Scope is the minimal enclosing scope, so it can't be divided any further 🦋 The exact extent of a Local Scope depends on the site, but locally scoped regions have to obey certain topological constraints. Specifically, a Local Scope must not span any other scope boundary. It also has to be completely contained within, or equal to, any larger scope. If scope regions overlap in area, the overlapping area must be in its own local scope. This means any scope boundary is also a boundary for the Local Scope ✨ The more general topological requirements for administratively scoped regions get covered further down.

6.1.1. Expansion of the IPv4 Local Scope 🌈

The IPv4 Local Scope space grows "downward" 📉 So the IPv4 Local Scope may grow downward from 239.255.0.0/16 into the reserved ranges 239.254.0.0/16 and 239.253.0.0/16. But these ranges should not be utilized until the 239.255.0.0/16 space isn't enough anymore 🙈

6.2. The IPv4 Organization Local Scope -- 239.192.0.0/14 🌸

239.192.0.0/14 is defined as the IPv4 Organization Local Scope 🎀 This is the space an organization should allocate sub-ranges from when it defines scopes for private use 💼

6.2.1. Expansion of the IPv4 Organization Local Scope 🍓

The ranges 239.0.0.0/10, 239.64.0.0/10 and 239.128.0.0/10 are unassigned and available for expanding this space ✨ These ranges should be left unassigned until the 239.192.0.0/14 space isn't enough anymore. The reason is that future revisions of this document might define additional scopes on a scale larger than organizations, so the room is kept open for that 🦋

6.3. Other IPv4 Scopes of Interest 💜

The other two scope classes of interest, statically assigned link-local scope and global scope, already exist in IPv4 multicast space 🌈 The statically assigned link-local scope is 224.0.0.0/24. The existing static global scope allocations are a bit more granular, and they include:

        224.1.0.0-224.1.255.255         ST Multicast Groups
        224.2.0.0-224.2.127.253         Multimedia Conference Calls
        224.2.127.254                   SAPv1 Announcements
        224.2.127.255                   SAPv0 Announcements (deprecated)
        224.2.128.0-224.2.255.255       SAP Dynamic Assignments
        224.252.0.0-224.255.255.255     DIS transient groups
        232.0.0.0-232.255.255.255       VMTP transient groups

For current multicast address assignments, see [RFC1700]. That list can also be found, possibly in a more up-to-date form, at ftp://ftp.isi.edu/in-notes/iana/assignments/multicast-addresses 🧚

9.1. Relative Assignment Guidelines 🎀

okay so, requests for relative assignments should go straight to the IANA 💅 The IANA gets advice from an area expert when it makes relative address assignments, and that area expert gets appointed by the relevant Area Director.

ngl, relative addresses are mostly for bootstrapping into dynamic address assignments from inside the scope 🧚 So relative assignments should only go to services that can't use a dynamic address assignment protocol to find their address within the desired scope. The dynamic address assignment service itself is a classic example. It's giving chicken-and-egg energy, and it's iconic 🫶

10. Security Considerations 🚨

bestie, this part is serious, so listen up 😭 Organizations using the administratively scoped IP Multicast addresses should not rely on them to keep sensitive data from leaving the organization. If a multicast router on an administrative boundary gets mis-configured, has a bug in its administrative scoping code, or runs into other problems that make it forward an administratively scoped IP multicast packet outside the proper scope, the organization's data would leave its intended transmission region. Not me having my data escape like that 💀

Organizations that send sensitive data over administratively scoped IP Multicasting should use a confidentiality mechanism, such as encryption, to protect it 🔐 For lots of existing video-conferencing applications (vat is one example), encryption is already built in as an application feature. It just needs to be turned on, and the appropriate cryptographic keys need to be distributed securely. For many other applications, the IP Encapsulating Security Payload (ESP) [RFC-1825, RFC-1827] can give IP-layer confidentiality through encryption ✨

Inside an administratively scoped IP multicast group, manual key distribution might well be feasible 🌸 Dynamic key management for IP Security was still a research area when this note was written. The IETF was expected to extend the ISAKMP key management protocol to support scalable multicast key distribution in the future, so keep an eye out for that 👀

It is important to note that the "boundary router" described in this note is not necessarily providing any kind of firewall capability. Don't mix those two up, periodt 🙅‍♀️

11. References 📚

• [ASMA] V. Jacobson, S. Deering, "Administratively Scoped IP Multicast", presented at the 30th IETF, Toronto, Canada, 25 July 1994.
• [DVMRP] Pusateri, T., "Distance Vector Multicast Routing Protocol", Work in Progress.
• [MZAP] Handley, M., "Multicast-Scope Zone Announcement Protocol (MZAP)", Work in Progress.
• [PIMDM] Deering, S, et. al., "Protocol Independent Multicast Version 2, Dense Mode Specification", Work in Progress.
• [PIMSM] Estrin, D., Farinacci, D., Helmy, A., Thaler, D., Deering, S., Handley, M., Jacobson, V., Liu, C., Sharma, P., and L. Wei, "Protocol Independent Multicast Sparse Mode (PIM-SM): Protocol Specification", RFC 2362, June 1998.
• [RFC1700] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1700, October 1994.
• [RFC1884] Hinden. R., and S. Deering, "IP Version 6 Addressing Architecture", RFC1884, December 1995.
• [SAP] Handley, M., "SAP: Session Announcement Protocol", Work in Progress.

12. Author's Address 🖊️

David Meyer Cisco Systems San Jose, CA

EMail: dmm@cisco.com

13. Full Copyright Statement 💜

Copyright (C) The Internet Society (1998). All Rights Reserved.

Here's the vibe: this document and translations of it can be copied and shared with others. Derivative works that comment on or explain it, or help with implementing it, can be made, copied, published, and distributed, in whole or in part, with no restrictions of any kind. The catch is that the above copyright notice and this paragraph must be included on every copy and derivative work. The document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations. The one exception is for developing Internet standards, and in that case the copyright procedures defined in the Internet Standards process must be followed. Translating it into languages other than English is also allowed 🌈

These permissions are perpetual and will not be revoked by the Internet Society or its successors or assigns ♾️

This document and the information in it are provided on an "AS IS" basis, and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.