Policy Proposal: eGLOP multicast address assignments

[Member Services]

ARIN received the following policy proposal. In accordance with the ARIN
Internet Resource Policy Evaluation Process, the proposal is being
posted to the ARIN Public Policy Mailing List (PPML) and being placed on
ARIN's website.

The AC will review this proposal and may decide to:

1. Accept the proposal as a formal policy proposal as it is presented;

2. Work with the author to:
      a) clarify the language or intent of the proposal;
      b) divide the proposal into two (2) or more proposals; or
      c) combine the proposal with other proposals; or,

3. Not accept the proposal as a formal policy proposal.

The AC will review this proposal at their next meeting. If the AC
accepts the proposal, then it will be posted as a formal policy proposal
to PPML and it will be presented at a Public Policy Meeting. If the AC
does not accept the proposal, then the AC will explain that decision;
and at that time the author may elect to use the petition process to
advance their proposal. If the author elects not to petition or the
petition fails, then the proposal will be closed.

The ARIN Internet Resource Policy Evaluation Process can be found at:
http://www.arin.net/policy/irpep.html

Mailing list subscription information can be found at:
http://www.arin.net/mailing_lists/index.html

Regards,

Member Services
American Registry for Internet Numbers (ARIN)


## * ##


Policy Proposal Name: eGLOP multicast address assignments

Author:
Marshall Eubanks
David Meyer

Proposal Version: 1

Submission Date: 15 February 2007

Proposal type: new

Policy term: permanent

Policy statement:

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 addresses by the ARIN RIR
using the criteria set up in RFC 3180; equivalent proposals are being
sent to the other RIRs for their consideration.

Rationale:

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 addresses by the APNIC RIR;
equivalent proposals will be sent to the other RIRs for consideration in
due course.


RFC 2770 and RFC 3180 describe an experimental policy for use of the
class D address space by mapping 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.

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.)

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.


Timetable for implementation: Immediately