RFC 3180

GLOP Addressing in 233/8

📅 published September 2001, from ietf

RFC 3180: GLOP Addressing in 233/8 💖

okay bestie, here's the vibe check 🦋

  • Network Working Group: D. Meyer and P. Lothberg, both at Sprint 🌸
  • Category: Best Current Practice (BCP 53) ✨
  • Date: September 2001 📅
  • Obsoletes: RFC 2770 💅
  • Updates: nothing listed 🙈

Status of This Memo

this is a Best Current Practice for the Internet Community, and the authors are asking for your discussion and suggestions for improvements 🫶 anyone can pass it around freely, no cap.

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

Abstract

okay so this doc sets the policy for using 233/8 for statically assigned multicast addresses 🎀

1. Introduction ✨

the main vibe for this space is many-to-many applications 🌈 this allocation is on top of the stuff listed on [IANA] (think [RFC2365] for example). IANA already gave 223/8 out under [RFC2770] 💜 and this document obsoletes RFC 2770, so it's a glow-up 💅

2. Problem Statement 🔥

multicast addresses used to get handed out by a dynamic thing like SDR [RFC2974] 🙃 but a lot of current multicast setups don't vibe with dynamic allocation. like, content aggregators need group addresses that stay fixed for way longer than that kind of allocation can handle 😭

it's worse than that tho. providers, content aggregators, and app writers don't agree on how allocation should work, so the Internet basically has no coherent multicast allocation scheme 💀

the MALLOC working group made a specific global multicast allocation strategy [RFC2730, RFC2909] 💜 but it hasn't really been widely implemented or deployed. so this doc tackles a smaller slice of the problem: the cases not covered by Source Specific Multicast ✨

3. Address Space 🧚

IANA already gave 223/8 out under RFC 2770 [RFC2770] 🌸 RFC 2770 handles the middle two octets of 233/8 in a way that's similar to RFC 1797, and the layout looks like this:

    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      233      |           16 bits AS          |  local bits   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

3.1. Example 🍓

let's do AS 5662 as an example 🧮 written in binary and left padded with 0s, it's 0001011000011110. map the high order octet to the second octet of the address, and the low order octet to the third octet, and you get 233.22.30/24 🎀

4. Allocation 👑

like we said above, the allocation here follows the RFC 1797 (case 1) scheme, with a few changes: the high-order octet is 233, and the next 16 bits are a previously assigned Autonomous System number (AS). that AS number gets registered by a network registry and listed in the RWhois database system 💖 this gives a single /24 per AS ✨

same as RFC 1797, using the AS number this way means each service provider gets a single /24 automatically 🫶 and there's no extra registration step needed 🙌

4.1. Private AS Space 🌙

the part of 233/8 that maps to the private AS space [RFC1930] is assigned to the IRRs [RFC3138] 💜

5. Large AS Numbers 🙈

this is important: this approach only works for two octet AS numbers 🚫 it does not work with any AS number extension scheme 💔

6. Security Considerations 🔒

ngl this section is serious business 💀 the approach here may reduce exposure to denial-of-service attacks that are based on dynamic allocation. also, since dynamic assignment doesn't cross domain boundaries, well-known intra-domain security techniques can be applied 🛡️

7. IANA Considerations 🌈

IANA has assigned 233/8 for this purpose 🎀

8. Acknowledgments 🫶

this proposal started with Peter Lothberg's idea to use the same AS-based allocation described in RFC 1797 💖 Randy Bush and Mark Handley left many insightful comments, and Pete and Natalie Whiting made the document way more readable 👑

9. References 📚

  • [IANA] http://www.iana.org/numbers.html
  • [RFC1797] IANA, "Class A Subnet Experiment", RFC 1797, April 1995.
  • [RFC1930] Hawkinson, J. and T. Bates, "Guidelines for creation, selection, and registration of an Autonomous System (AS)", RFC 1930, March 1996.
  • [RFC2365] Meyer, D., "Administratively Scoped IP Multicast", RFC 2365, July 1998.
  • [RFC2374] Hinden, R., O'Dell, M. and S. Deering, "An IPv6 Aggregatable Global Unicast Address Format", RFC 2374, July 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.
  • [RFC2909] Radoslavov, P., Estrin, D., Govindan, R., Handley, M., Kumar, S. and D. Thaler, "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.

10. Authors' Addresses 💌

David Meyer
Sprint
VARESA0104
12502 Sunrise Valley Drive
Reston VA, 20196

EMail: dmm@sprint.net

Peter Lothberg
Sprint
VARESA0104
12502 Sunrise Valley Drive
Reston VA, 20196

EMail: roll@sprint.net

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

this document and translations of it may be copied and furnished to others. derivative works that comment on or otherwise explain it, or help with its implementation, may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, as long as 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 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