[sig-policy] prop-047: eGLOP multicast address assignments
The proposal "eGLOP multicast address assignments" has been sent to the
Policy SIG for review. This policy proposal was submitted after the
deadline for policy proposals to be discussed at APNIC 23. Therefore,
this proposal will be presented as an informational proposal at APNIC
23. At APNIC 24, the community will decide whether to adopt, modify,
or abandon the policy proposal.
You are invited to review and comment on the proposal on the mailing
list.
The proposal's history can be found at:
http://www.apnic.net/policy/proposals/prop-047-v001.html
Regards,
Toshiyuki Hosaka
on behalf of Policy SIG chairs
hosaka at nic dot ad dot jp
________________________________________________________________________
prop-047-v001: eGLOP multicast address assignments
________________________________________________________________________
Authors: Marshall Eubanks
<tme at multicasttech dot com>
David Meyer
<dmm at 1-4-5 dot net>
Version: 1
Date: 2 February 2007
SIG: Policy
Introduction
------------
RFC 2770 [now replaced by RFC 3180 / BCP 53] set up an automatic "GLOP"
multicast address assignment in 233/8 based on Autonomous System Numbers
(ASNs). The mechanism that was set up in RFC 3180 for extending GLOP
assignments, known as eGLOP, envisioned the assignment of multicast
addresses by RIRs from the portion of the 233/8 space corresponding to
the RFC 1930 private address space. This mechanism has never been used,
but its use has now imperative due to both an increased interest in
multicast address assignments to support IPTV and the adopted proposals
to assign 4-octet ASNs, which do not have GLOP assignments. This
proposal is for the assignment of Multicast addesses by the APNIC RIR;
equivalent proposals will be sent to the other RIRs for consideration in
due course.
Summary
-------
RFC 2770 and RFC 3180 describe an experimental policy for use of the
class D address space by maping 16 bits of Autonomous System number (AS)
into the middle two octets of 233/8 to yield a /24, which is
automatically assigned to that ASN. While this technique has been
successful, the assignments are inefficient in those cases in which a
/24 is too small or the user doesn't have its own AS, and it does not
work for 4-octet AS number extension scheme.
RFC 3138 expanded on RFC 2770 to allow routing registries to assign
multicast addresses from the GLOP space corresponding to the RFC 1930
private AS space; referred to as the EGLOP (Extended GLOP) address
space.
The failure to instantiate RFC 3138 assignments had lead to a situation
where some multicast users feel like they cannot obtain addresses, while
others apply directly to IANA, with there being at least 24 approved
applications in 2006. The current situations in inequitable and
inefficient and there is no reason not to apply the mechanism set up in
RFC 3138.
Situation
---------
We intend to make comparable proposals to the ARIN, LACNIC, and RIPE
NCCs in due course. This submission was motivated by the date of the
next APNIC meeting.
Details
-------
RFC 3138 allocated 233.252/14 to eGLOP. The RFC further says that:
Globally scoped IPv4 multicast addresses in the EGLOP space are
assigned by a Regional Registry (RIR). An applicant MUST, as
per [IANA], show that the request cannot be satisfied using
Administratively Scoped addressing [RFC2365], GLOP addressing
[RFC2770], or SSM. The fine-grained assignment policy is left
to the assigning RIR.
We propose that each RIR be allocated an initial /20 from this address
range, and allocate by default /28's to proposers (16 addresses as
Multicast address are not subject to CIDR default restrictions), subject
to the above criteria, and that the RIR assign more addresses based on
demonstrated need.
Note that Multicast addresses are not subject to classless aggregation
and address blocks as small as a /32 can be usefully assigned.
Pros/Cons
--------
The proposed policy should facilitate multicast deployment. The current
mechanism for non-GLOP multicast deployment involves requesting an
assignment from IANA, which has no ability to evaluate these requests
and relies on the IANA Multicast Expert appointed by the IESG (currently
David Meyer). This process is inefficient, inequitable (as this policy
route is not widely known), encourages the use of "rogue" self-
assignments, and discourages application developers and service
providers from developing and deploying multicast.
The only disadvantage that we can see from the proposed policy is that
the RIR's will have to set up and execute mechanisms to implement it.
Effect on APNIC: We feel that adoption of this proposal will help to
make multicast deployment more widespread, and should be of benefit to
APNIC members adopting Multicast for video distribution on the Internet.
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.
[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.
[RFC3138] Meyer, D., "Extended Assignments in 233/8", RFC 3138,
June 2001.
[RFC3180] Meyer, D., "GLOP Addressing in 233/8", BCP 53, RFC
3180, September 2001.