[LACNIC/Politicas] propuesta sobre direcciones multicast

[Guillermo Cicileo]

Estimados:

En otros RIRs se está proponiendo poner en vigencia la RFC 3138 que
define un rango de direcciones para ser usadas por aplicaciones
multicast (en casos que no se pueda utilizar otras soluciones como
SSM, GLOP, etc). Esto implica que los RIRs deberán tener un mecanismo
para asignar estas direcciones a quienes lo soliciten. El rango que se
utiliza para estas direcciones, llamadas eGLOP, es el 233.252.0.0/14,
que se corresponde con el rango de AS privados (ver RFC3180 donde se
describe como mapear un AS a estas direcciones).

Propongo que LACNIC se sume a esta iniciativa, destinando un bloque
/20 para esto, tal como se está planteando en otros RIRs. Incluyo
abajo el mail con la propuesta que se presentó en ARIN.

Saludos,

                                                                 Guillermo.



http://lists.arin.net/pipermail/ppml/2007-February/005970.html

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