[LACNIC/Politicas] propuesta sobre direcciones multicast
Guillermo Cicileo
gcicileo at gmail.com
Tue Mar 13 13:14:36 BRT 2007
Hola,
Voy a tratar de describir brevemente las características principales
de multicast en IPv4 que tienen relación con esta política que se está
discutiendo.
Existen 2 modelos que se están utilizando principalmente en la
actualidad para emisiones multicast: ASM y SSM.
En el caso de ASM (any source multicast), los datos son transmitidos a
un grupo de hosts identificados por una IP que representa al grupo, G.
Esa IP está dentro del rango 224.0.0.0 a 239.255.255.255. En este
modelo es posible que muchos emisores estén enviando tráfico al mismo
conjunto de hosts. Para esto sólo es necesario que especifiquen la
dirección G que representa al grupo, como destino de esos paquetes.
Por ejemplo, supongamos que queremos realizar una videoconferencia
entre distintos puntos. En ese caso, cada sitio que quiera participar
utilizará la misma dirección de grupo, por ejemplo 233.16.174.25 y en
la aplicación de videoconferencia utilizará esa dirección como
"destino" (la IP fuente será la del equipo del usuario). El problema
aquí es determinar cuál es la dirección a utilizar, de manera que no
se superponga con otras aplicaciones que puedan estar utilizandola, ya
que no hay control de acceso para esto.
En el caso SSM (source specific multicast), un emisor específico S
emite a un grupo G identificado por una dirección. Los receptores
interesados se suscriben a un canal identificado por (S, G), con lo
cual no existe el mismo problema que en ASM.
Actualmente el modelo más implementado en las redes y que mejor escala
es ASM. Para poder utilizar este modelo con éxito se debe poder
utilizar direcciones (en realidad, "identificadores de grupo") que no
colisionen entre sí. Para esto hay diversas soluciones que se han
propuesto. En el caso de contar con un número de AS se pueden utilizar
las llamadas direcciones GLOP, que son 233.x.y.*, donde los bytes x e
y se forman con los 16 bits del AS (los 8 superiores para x, los 8
inferiores para y).
Sin embargo, esto no brinda una solución cuando no se tiene un número
de AS o, como puede suceder actualmente si el AS es de 32 bits
(también en el caso que 256 direcciones no sean suficientes).
Si leyeron hasta aca, ya llegamos al tema de la política propuesta.
Existe una extension de estas direcciones GLOP para utilizar el
espacio que correspondería a los AS privados,
233.252.0.0-233.255.255.255 llamada eGLOP. Tal como se especifica en
la RFC 3138, la propuesta es que los RIRs asignen direcciones de ese
rango a quienes necesiten proveer servicios multicast.
Creo que el punto principal en discusión pasa por si esta asignación
la debe hacer IANA o, tal como propone la RFC 3138, los RIRs deben
recibir un bloque y asignar direcciones de ese bloque a quienes lo
soliciten.
Como ven, no es facil resumir este tema en pocas líneas. Espero al
menos haber sido claro y que sirva para fomentar la discusión.
Saludos,
Guillermo.
On 3/12/07, ARG-O'FLAHERTY, CHRISTIAN <COFLAHERTY at impsat.com> wrote:
>
>
> Guillermo,
>
> Este tema ha generado mucho debate en otros registros y seria bueno que
> tambien en Lacnic hagamos un análisis del impacto de su aplicación.
>
> Como muchos no conocemos los detalles de utilización del multicast seria
> muy conveniente que nos hagas una descripción del tema para que todos
> podamos analizar como impacta esta política en los servicios que prestamos.
>
> Podés por favor enviar un mail a la lista explicando como se utilizan las
> direcciones multicast, que problema resuelve esta propuesta y como se
> relaciona con los RFCs existentes?
>
> Gracias,
>
> Christian
>
> -----Original Message-----
> From: politicas-bounces at lacnic.net [mailto:politicas-bounces at lacnic.net]
> On Behalf Of Guillermo Cicileo
> Sent: Viernes, 02 de Marzo de 2007 06:56 p.m.
> To: politicas at lacnic.net
> Subject: Re: [LACNIC/Politicas] propuesta sobre direcciones multicast
>
> Jordi:
>
> Coincido con tus comentarios acerca de que conviene promover la tecnología
> nueva (multicast IPv6, en este caso) y que a eso hay que dedicarle los
> mayores esfuerzos. Sin embargo, sabemos que aun tendremos que convivir con
> IPv4 por unos cuantos años y alguna solución hay que darle a quienes hoy
> quieren utilizar multicast.
>
> En el caso de las redes académicas de América Latina, multicast es una
> tecnología que cada vez se está utilizando en mayor medida, ya que muchas
> aplicaciones la requieren. En Argentina en particular, la mayoría de las
> Universidades no tiene sistema autónomo propio, por lo cual no podrían
> utilizar GLOP convencional y esta propuesta eGLOP parece una solución
> adecuada. Lo mismo sucede con las instituciones del ámbito
> académico/científico de Latinoamérica, tengamos en cuenta que en algunos
> países incluso la NREN conectada a RedCLARA usa AS privado (si bien
> podríamos pensar que todo el que quiera utilizar multicast tenga su propio
> AS, creo que esa solución es impracticable a gran escala).
>
> Coincido también que obliga a una propuesta unificada entre los RIRs, pero
> la situación al dia de hoy es que muchos de quienes utilizan multicast no
> solicitan a la IANA los recursos, sino que obtienen las direcciones de otra
> manera (en muchos casos puede ser simplemente por desconocimiento). Esto
> representa un problema ya que puede provocar que mas de un servicio esté
> utilizando las mismas direcciones de grupo.
>
> Estoy viendo que hay bastante debate sobre este tema en otros RIRs, creo
> que es bueno comenzar a plantear el tema aquí también.
>
> Saludos,
>
>
> Guillermo.
>
>
>
> On 3/1/07, JORDI PALET MARTINEZ <jordi.palet at consulintel.es> wrote:
> >
> > Hola Guillermo,
> >
> > Igual que exprese ayer cuando se presento esta propuesta de politica
> > en la reunion de APNIC, IANA ya esta instruido por el IETF para
> > asignar estas direcciones y de hecho asi se esta produciendo.
> >
> > El autor de la propuesta decia que las pequeñas empresas que necesitan
> > estas direcciones no pueden acceder a IANA y las grandes si. Sin
> > embargo, el representante de IANA confirmo que esto no es cierto, que
> > IANA atiendo todas las peticiones, como asi a mi me consta.
> >
> > Yo sinceramente creo que esto no es preciso, y ademas, de serlo, dado
> > que habria que delegar a los RIRs prefijos que estan reservados por
> > IETF, se requeriria una politica global, lo cual llevaria un gran
> > esfuerzo y tiempo.
> >
> > Mi punto de vista es que ademas, como se ha demostrado, el despliegue
> > comercial de multicast, con IPv4, ha fallado, y sin embargo el de
> > multicat con IPv6, tambien de forma comercial, esta teniendo mucho mas
> > éxito. Asi que lo logico seria concentrar nuestros esfuerzos en ese
> > sentido y no intentar "promocionar" una tecnologia que cada vez tiene
> > menos futuro, teniendo en cuenta que cada vez las expectativas de
> > "continuidad" de IPv4 son menores.
> >
> >
> > Saludos,
> > Jordi
> >
> >
> >
> >
> > > De: Guillermo Cicileo <gcicileo at gmail.com> Responder a: LACNIC
> > > Policy mailling list < politicas at lacnic.net>
> > > Fecha: Thu, 1 Mar 2007 14:51:33 -0300
> > > Para: <politicas at lacnic.net>
> > > Asunto: [LACNIC/Politicas] propuesta sobre direcciones multicast
> > >
> > > 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
> >
> >
> >
> >
> > **********************************************
> > The IPv6 Portal: http://www.ipv6tf.org
> >
> > Bye 6Bone. Hi, IPv6 !
> > http://www.ipv6day.org
> >
> > This electronic message contains information which may be privileged
> > or confidential. The information is intended to be for the use of the
> > individual(s) named above. If you are not the intended recipient be
> > aware that any disclosure, copying, distribution or use of the
> > contents of this information, including attached files, is prohibited.
> >
> >
> >
> > _______________________________________________
> > 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
>
>
> Esta comunicación es confidencial y puede contener información cuya
> divulgación esté restringida por la ley o en virtud de obligaciones de
> confidencialidad asumidas por acuerdos escritos. Si usted no es su
> destinatario, por favor advierta que cualquier divulgación, distribución o
> copia de esta comunicación le está estrictamente prohibida. Si usted recibió
> este mail por error, agradeceremos tenga a bien informar esa circunstancia
> al remitente mediante comunicación a la dirección de e-mail o al número
> telefónico : (5411) 5170-0000, y le solicitamos asimismo que por favor
> proceda a borrarlo de su computadora. Por favor no copie ni use la
> información contenida en este mail para ningún propósito y no divulgue su
> contenido a ninguna otra persona.
>
>
> This communication is confidential and may contain information that is
> exempt from disclosure by law or pursuant to confidentiality obligations
> assumed by written agreement. If you are not the intended recipient, please
> note that any dissemination, distribution, or copying of this communication
> is strictly prohibited. If you receive this e-mail in error, please notify
> the sender immediately at the electronic mail address or phone number :
> (5411) 5170-0000 and delete the information from your computer. Please do
> not copy or use it for any purpose nor disclose its contents to any other
> person.
>
>
>
> _______________________________________________
> Politicas mailing list
> Politicas at lacnic.net
> https://mail.lacnic.net/mailman/listinfo/politicas
>
More information about the Politicas
mailing list