Summary

  • RFC 3180 turned a one-year experiment into BCP 53: in IPv4 multicast block 233/8, a two-octet Autonomous System number determined a /24, or 256 group addresses, without a second registration step.
  • The design borrowed the AS registry’s convenience and its limits. It could not encode four-octet ASNs, and one AS could contain multiple sites or organizations. RFC 6034 later added a prefix-based option but explicitly kept RFC 3180 in force.

The address was designed to carry a clue about who could allocate it. In 233/8, the first octet stayed fixed; the next two copied a 16-bit AS number; the final octet left 256 multicast groups for that AS. RFC 3180’s example maps AS 5662 to 233.22.30.0/24. A provider could derive the block from a number already assigned for routing, rather than claim a global group range through a separate inter-domain allocator.

That shortcut answered a specific coordination problem. RFC 2770, published in February 2000 as an experiment, said some content aggregators needed stable group addresses on a timescale that dynamic session allocation did not suit. It also described a lack of agreement among providers, aggregators and application writers on a coherent allocation scheme. Its proposed static use of 233/8 was initially time-limited to one year, with renewal possible. RFC 3180, in September 2001, obsoleted that experiment with Best Current Practice 53.

The policy’s stated target was the static-address subset not covered by Source-Specific Multicast—not all multicast allocation.

Reuse made the rule legible, but the borrowed identifier imposed a hard boundary. RFC 3180 explicitly restricted the method to two-octet AS numbers. When the ASN format expanded to four octets, GLOP had no bits in which to place the additional value. Its block also described an AS, not necessarily one organization or site. A large AS with several independent operations still needed internal coordination; knowing the AS encoded in a group address might not tell an operator which organization was responsible.

RFC 6034’s 2010 design approached the problem from the other direction. It derived IPv4 multicast ranges from an organization’s global unicast prefix, in a manner similar to IPv6’s prefix-based multicast format. That could offer finer coordination boundaries and avoid the four-byte-AS problem where the prefix length qualified. It was not a clean succession: RFC 6034 says it does not update or obsolete RFC 3180. Organizations with unicast allocations more specific than /24 could still need GLOP, and an organization could use both.

The two schemes allocate from different existing authorities: an AS number versus a globally routed address prefix.

IANA’s current registry still labels 233.0.0.0 through 233.251.255.255 as the GLOP block, with adjacent ranges handled separately. That records a recognized allocation boundary; it does not show how much traffic uses it, whether an assigned group is routed, or whether receivers obtained a stream. The historical record therefore supports neither universal adoption nor disappearance. It shows an effort to make static group allocation easy by embedding it in another numbering system—and the later decision to add a second mapping when that system’s granularity and width did not fit every case.

Sources