RFC 3171

IANA Guidelines for IPv4 Multicast Address Assignments

📅 published August 2001, from ietf

RFC 3171: IANA Guidelines for IPv4 Multicast Address Assignments 🎀

Okay bestie, so this is RFC 3171 💅 It's from the Network Working Group, and it's a Best Current Practice (BCP 51), dated August 2001. The authors are Z. Albanna (Juniper Networks), K. Almeroth (UCSB), D. Meyer (Sprint), and M. Schipper (IANA). The title block doesn't list any RFCs it obsoletes or updates, so it's standing on its own ✨

Status of this Memo 📜

This doc is a BCP for the Internet Community, and it's basically asking everyone to talk about it and send over ideas to make it better 🫶 Distribution is totally unlimited, so share away!

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

Abstract 🌸

Here's the tea: this memo gives guidance to the Internet Assigned Numbers Authority (IANA) on how to assign IPv4 multicast addresses 🦋

1. Introduction ✨

So IANA (www.iana.org) is in charge of handing out parameter values for fields in protocols that were designed, created, or are maintained by the Internet Engineering Task Force (IETF) 🧚 RFC 2780 [RFC2780] is the one that gives IANA its guidance for assigning parameters in brand-new protocols. This memo is kind of a deeper dive into section 4.4.2 of RFC 2780, and it's trying to write down the way IANA has already been handling IPv4 multicast address assignments 📝

Quick vocab check: "Specification Required", "Expert Review", "IESG Approval", "IETF Consensus", and "Standards Action" all refer to the processes described in [RFC2434] 💜 And the keywords MUST, MUST NOT, MAY, OPTIONAL, REQUIRED, RECOMMENDED, SHALL, SHALL NOT, SHOULD, SHOULD NOT are read the way RFC 2119 [RFC2119] defines them 🙈

Now, the IPv4 multicast space is pretty small, so giving out more of it is only recommended in limited situations 🥺 Basically, IANA should only assign addresses when the dynamic selection (SDP/SAP), GLOP, SSM, or Administratively Scoped address spaces can't do the job. The guidelines in here are reflected at http://www.iana.org/numbers.html 🔥

2. Definition of Current Assignment Practice 🦋

Okay this is a big difference from unicast 👀 IPv4 unicast blocks get delegated to regional registries, but IPv4 multicast addresses are assigned directly by IANA 💅 Here's how the current assignments look [IANA]:

224.0.0.0   - 224.0.0.255     (224.0.0/24)  Local Network Control Block
224.0.1.0   - 224.0.1.255     (224.0.1/24)  Internetwork Control Block
224.0.2.0   - 224.0.255.0                   AD-HOC Block
224.1.0.0   - 224.1.255.255   (224.1/16)    ST Multicast Groups
224.2.0.0   - 224.2.255.255   (224.2/16)    SDP/SAP Block
224.252.0.0 - 224.255.255.255               DIS Transient Block
225.0.0.0   - 231.255.255.255               RESERVED
232.0.0.0   - 232.255.255.255 (232/8)       Source Specific Multicast
                                            Block
233.0.0.0   - 233.255.255.255 (233/8)       GLOP Block
234.0.0.0   - 238.255.255.255               RESERVED
239.0.0.0   - 239.255.255.255 (239/8)       Administratively Scoped
                                            Block

IANA usually hands out addresses from the Local Network Control, Internetwork Control, and AD-HOC blocks 🌈 The guidelines for each of those, plus the Source Specific Multicast, GLOP, and Administratively Scoped blocks, are all spelled out below 🫶

3. Local Network Control Block (224.0.0/24) 🌿

These addresses are for protocol control traffic that doesn't get forwarded off the link, so think of them as staying in your own neighborhood 🏡 An example is OSPFIGP All Routers (224.0.0.5) [RFC2328] ✨

3.1. Assignment Guidelines 📋

Following section 4.4.2 of RFC 2780 [RFC2780], assignments from the Local Network Control block go through an Expert Review, IESG Approval, or Standards Action process 💅 Check [IANA] for the current list of assignments.

4. Internetwork Control Block (224.0.1/24) 🌐

This block is for protocol control that has to be forwarded across the Internet, so it's got a bigger reach 🚀 Some examples are 224.0.1.1 (NTP [RFC2030]) and 224.0.1.68 (mdhcpdiscover [RFC2730]) 🧚

4.1. Assignment Guidelines 📋

Same vibe as the Local block: following section 4.4.2 of RFC 2780 [RFC2780], assignments from the Internetwork Control block go through an Expert Review, IESG Approval, or Standards Action process 💖 See [IANA] for what's currently assigned.

5. AD-HOC Block (224.0.2.0/24 - 224.0.255.0/24) 🎀

The AD-HOC block has traditionally been for applications that don't fit in the Local or Internetwork Control blocks 🌸 These addresses are globally routed, and they're usually used by apps that need small blocks of addresses (for example, less than a /24) 🍓

5.1. Assignment Guidelines 📋

Honestly, IANA SHOULD NOT assign addresses in the AD-HOC Block 🙅‍♀️ That said, IANA may, under special circumstances, assign addresses from this block. Following section 4.4.2 of RFC 2780 [RFC2780], assignments from the AD-HOC block go through an Expert Review, IESG Approval, or Standards Action process. See [IANA] for the current set of assignments 💜

6. SDP/SAP Block (224.2/16) 🦋

The SDP/SAP block is for applications that get their addresses through the Session Announcement Protocol [RFC2974], and then use them with stuff like the session directory tool (SDR [SDR]) 📡

6.1. Assignment Guidelines 📋

So here's the thing: addresses in the SDP/SAP block are picked randomly from the range of addresses that aren't already in use [RFC2974], which means no IANA assignment policy is required 🎲 Still, even though IANA doesn't need to assign anything here, addresses in the SDP/SAP block are explicitly for use by SDP/SAP, and they MUST NOT be used for other purposes. Don't be that person 😤🔥

15. References ✨

Okay bestie, here's the reference list, and every single source is listed with all its details 💅 Don't skip any of these, they're the receipts 🧾

  • [IANA] http://www.iana.org/numbers.html 🌸
  • [RFC1190] Topolcic, C., "Experimental Internet Stream Protocol, Version 2 (ST-II)", RFC 1190, October 1990. 🦋
  • [RFC1930] Hawkinson, J. and T. Bates, "Guidelines for creation, selection, and registration of an Autonomous System (AS)", RFC 1930, March 1996. 🎀
  • [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. 👑
  • [RFC2030] Mills, D., "Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI", RFC 2030, October 1996. ⭐
  • [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 💜
  • [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 🌈
  • [RFC2365] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, RFC 2365, July 1998. 🧚
  • [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. 🍓
  • [RFC2730] Hanna, S., Patel, B. and M. Shah, "Multicast Address Dynamic Client Allocation Protocol (MADCAP), RFC 2730, December 1999. 🫶
  • [RFC2770] Meyer, D. and P. Lothberg, "GLOP Addressing in 233/8", RFC 2770, February 2000. 🔥
  • [RFC2780] Bradner, S. and V. Paxson, "IANA Allocation Guidelines For Values In the Internet Protocol and Related Headers", BCP 37, RFC 2780, March 2000. ✨
  • [RFC2908] Thaler, D., Handley, M. and D.Estrin, "The Internet Multicast Address Allocation Architecture", RFC 2908, September 2000. 💖
  • [RFC2909] Thaler, D., Handley, M. and D. Estrin, "The Multicast Address-Set Claim (MASC) Protocol", RFC 2909, September 2000. 🌸
  • [RFC2974] Handley, M., Perkins, C. and E. Whelan, "Session Announcement Protocol", RFC 2974, October 2000. 🦋
  • [RFC3138] Meyer, D., "Extended Assignments in 233/8", RFC 3138, June 2001. 🎀
  • [SDR] http://www-mice.cs.ucl.ac.uk/multimedia/software/ 💅

Copyright (C) The Internet Society (2001). All Rights Reserved. 💖

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this 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, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. 🫶

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. ✨

This document and the information contained herein is 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. 💀

Acknowledgement 🍓

Funding for the RFC Editor function is currently provided by the Internet Society. 👑

📦 where this page comes from