[LACNIC/Politicas] propuesta sobre direcciones multicast

Thu Mar 1 16:10:53 BRT 2007

Guillermo, ¿como piensan asegurar la ruteabilidad de estos /28?.

Roque

On Thu, 2007-03-01 at 14:51 -0300, Guillermo Cicileo wrote:
> 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
> _______________________________________________
> Politicas mailing list
> Politicas at lacnic.net
> https://mail.lacnic.net/mailman/listinfo/politicas