RFC 3180 (rfc3180) - Page 2 of 5
GLOP Addressing in 233/8
Alternative Format: Original Text Document
RFC 3180 GLOP Addressing in 233/8 September 2001
The MALLOC working group has created a specific strategy for global
multicast address allocation [RFC 2730, RFC 2909]. However, this
approach has not been widely implemented or deployed. This document
proposes a solution for a subset of the problem, namely, those cases
not covered by Source Specific Multicast.
3. Address Space
The IANA has allocated 223/8 as per RFC 2770 [RFC 2770]. RFC 2770
describes the administration of the middle two octets of 233/8 in a
manner similar to that described in RFC 1797:
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
Consider, for example, AS 5662. Written in binary, left padded with
0s, we get 0001011000011110. Mapping the high order octet to the
second octet of the address, and the low order octet to the third
octet, we get 233.22.30/24.
4. Allocation
As mentioned above, the allocation proposed here follows the RFC 1797
(case 1) allocation scheme, modified as follows: the high-order octet
has the value 233, and the next 16 bits are a previously assigned
Autonomous System number (AS), as registered by a network registry
and listed in the RWhois database system. This allows a single /24
per AS.
As was the case with RFC 1797, using the AS number in this way allows
automatic assignment of a single /24 to each service provider and
does not require an additional registration step.
4.1. Private AS Space
The part of 233/8 that is mapped to the private AS space [RFC 1930] is
assigned to the IRRs [RFC 3138].
5. Large AS Numbers
It is important to note that this approach will work only for two
octet AS numbers. In particular, it does not work for any AS number
extension scheme.
Meyer & Lothberg Best Current Practice