RFC 3138

Extended Assignments in 233/8

πŸ“… published June 2001, from ietf

RFC 3138: Extended Assignments in 233/8 ✨

bestie, here's the deets πŸŽ€ This one is an Informational doc from June 2001, written by David Meyer at Sprint πŸ’… It doesn't say it obsoletes or updates anything, so it stands on its own πŸ¦‹


Status of This Memo 🌸

This memo gives information to the Internet community. It is not an Internet standard of any kind πŸ™ˆ Distribution is totally unlimited, so share away πŸ’–

Copyright (C) The Internet Society (2001). All Rights Reserved. πŸ’œ

Abstract ✨

This memo describes how GLOP addresses map onto the private AS space 🧚

1. Introduction πŸŽ€

okay so [RFC2770] is the experimental policy that uses the 233/8 class D range πŸ¦‹ Its trick is to take the 16-bit AS number and put it in the middle two octets of 233/8, which gives you a /24. It's worked well, but it's inefficient when a /24 is too small or when the user doesn't even have their own AS 😭

[RFC1930] sets the private AS space at 64512 through 65535 πŸ”₯ This memo builds on [RFC2770] so that routing registries can assign multicast addresses from the GLOP space that matches that private AS range. Bestie, we're calling this the EGLOP (Extended GLOP) address space πŸ‘‘

This memo is a product of the Multicast 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 authors πŸ’Œ

The terms "Specification Required", "Expert Review", "IESG Approval", "IETF Consensus", and "Standards Action" refer to the processes described in [RFC2434] πŸ’… The keywords MUST, MUST NOT, MAY, OPTIONAL, REQUIRED, RECOMMENDED, SHALL, SHALL NOT, SHOULD, and SHOULD NOT are to be interpreted as defined in [RFC2119] ✨

2. Overview πŸ¦‹

http://www.iana.org/assignments/multicast-addresses defines a way to assign multicast addresses that are mostly for network control applications 🫢 The plan is that addresses from the EGLOP space (233.252.0.0 - 233.255.255.255) get used by applications that can't use Administratively Scoped Addressing [RFC2365], GLOP Addressing [RFC2770], or Source Specific Multicast. (Source Specific Multicast, or SSM, is an extension of IP Multicast where traffic only gets forwarded to receivers from the multicast sources they've explicitly said they want. It's mainly aimed at one-to-many, which is broadcast-style, apps πŸ“‘)

3. Assignment Criteria πŸ’–

Globally scoped IPv4 multicast addresses in the EGLOP space get assigned by a Regional Registry (RIR) 🌸 An applicant MUST, as per [IANA], show that the request can't be satisfied with Administratively Scoped addressing [RFC2365], GLOP addressing [RFC2770], or SSM πŸ™ˆ The fine-grained assignment policy is up to the assigning RIR πŸ’…

4. Security Considerations πŸ’€

⚠️ Bestie, this part is serious. The assignment scheme in this document does NOT affect the security properties of the single source or any source multicast service models 😭 Read it like it matters, because it does.

5. Acknowledgments 🫢

Huge thanks to Kurt Kayser, Mirjam Kuehne, Michelle Schipper, and Randy Bush, who gave loads of insightful comments on earlier versions of this doc πŸ’œ

6. Author's Address πŸŽ€

David Meyer Sprint 12502 Sunrise Valley Dr Reston VA, 20191

EMail: dmm@sprint.net πŸ’Œ

7. References πŸ“š

  • [IANA] http://www.iana.org/assignments/multicast-addresses
  • [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. πŸ¦‹
  • [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. πŸ”₯
  • [RFC2365] Meyer, D., "Administratively Scoped IP Multicast", RFC 2365, July 1998. ✨
  • [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. πŸ‘‘

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

You can copy and hand this document and its translations to others. You can also make derivative works that comment on or explain it, or that help with implementing it, and publish and distribute those, in whole or in part, with no restrictions of any kind πŸ’– The only condition is that the copyright notice and this paragraph stay on all of those copies and derivative works πŸ’…

The document itself can't be modified in any way, like removing the copyright notice or the references to the Internet Society or other Internet organizations πŸ™ˆ The exceptions are for developing Internet standards, where the copyright procedures in the Internet Standards process have to be followed, and for translating it into languages other than English 🌈

The limited permissions above are perpetual and won't 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 πŸ¦‹

Acknowledgement πŸŽ€

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

πŸ“¦ where this page comes from