[LACNIC/Politicas] propuesta sobre direcciones multicast

Thu Mar 1 16:33:02 BRT 2007

Roque:
Esos bloques no son direcciones ruteables, sino que estan dentro del rango
de direcciones multicast (224.0.0.0 a 239.255.255.255). Se utilizan para
representar "grupos multicast" a los que los emisores y receptores se
suscriben. Pero no se llevan en las tablas de ruteo normal.

El problema es que para emitir informacion hay que "elegir" una direccion
dentro de ese rango y no hay un mecanismo claro que permita evitar
superposiciones, en particular para quienes no tienen número de AS publico.

En esta política lo que se propone es que haya un rango asignable por los
RIRs siguiendo los lineamientos de la RFC 3138, que recomienda que todos los
RIRs lo hagan.

Saludos,

Guillermo.

On 3/1/07, Roque Gagliano <rgaglian at antel.net.uy> wrote:
>
> 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
>
> _______________________________________________
> Politicas mailing list
> Politicas at lacnic.net
> https://mail.lacnic.net/mailman/listinfo/politicas
>