[LACNIC/Politicas] Segunda adjudicación IPv6

Fri Nov 24 09:32:25 BRST 2006

Hola Jordi,

| Hola Ricardo,
| 
| Para la mayor tranquilidad de los miembros, podria considerarse algo como lo
| que yo mencionaba de pasar a reservar un numero de bits mucho mayor, ademas
| de la sparse allocation ?

El sparse allocation, con mucho espacio como hay en un /12 debe
presentar buenos resultados, una vez que llevaria un cierto tiempo
para utilizar un espacio que este siguiente a una asignacion ya
hecha. Lo que aumenta las posibilidades de que esa asignacion pueda
crecer aun mas.

Acerca de la reserva...

Actualmente ya se reserva 3 bits para las asignaciones mas comunes,
las de /32 (se reserva el /29).

La idea seria reservar tambien 3 bits para asignaciones de prefijos
mas cortos. Pero hasta algun limite... Por ej. si uno justifica para
/20 (lo que creo ser muy raro), reservar un /17 seria mucho, pues
representaria un porcentaje considerable del espacio de LACNIC.

Y hay un otro problema con las reservas para IPv6. Actualmente para
IPv4 se hace reserva, mismo que las mismas no sean garantizadas a
ningun ISP. Y las mantenemos por un ano. Y en el mundo IPv4, hay una
grande probabilidad que un ano, el ISP vuelva a solicitar bloque
adicional.

Lo que no pasa con IPv6. Reservar por un ano solamente es muy poco en
el escenario de utilizacion actual del IPv6.

Por eso, pienso que debemos si hacer reservas pero con algunos
criterios, como comente inicialmente.

| Consideras necesaria una politica que os diga como hacer esto, o sigues
| pensando que es mejor que esa operativa la dejemos en vuestras manos, pero
| que de algun modo informeis del mecanismo para que todos sepan a que
| atenerse como yo indicaba ?

No creo que sea necesario una politica para eso.
Si tenemos criterios bien basados y que funcionen, estaremos
bien. Incluso estamos abiertos a sugerencias.

Ricardo

| Saludos,
| Jordi
| 
| 
| 
| 
| > De: Ricardo Patara <patara at lacnic.net>
| > Responder a: <patara at lacnic.net>
| > Fecha: Thu, 23 Nov 2006 16:32:15 -0200
| > Para: <jordi.palet at consulintel.es>, LACNIC Policy mailling list
| > <politicas at lacnic.net>
| > Asunto: Re: [LACNIC/Politicas] Segunda adjudicación IPv6
| > 
| > Jordi, 
| > 
| > Hemos acompañado la discusión y queríamos solamente hacer algunos
| > pequeños apuntes en lo que toca a la distribución y las reservas.
| > 
| > Nos parece muy lógicas las sugerencias y quisiéramos solamente agregar
| > algunos puntos:
| > 
| > Lo que hemos hecho hasta ese momento, es reservar hasta un /29 para
| > cuando se solicita un /32. Que un procedimiento que adopta los otros
| > RIRs también. Incluso, eso considerando las asignaciones no muy largas
| > que tenían los RIRs (algunos /23s)
| > 
| > Como es algo que todavía aun no sabemos como va se portar, puede ser
| > que para algunos, eso sea poco... mientras que para la mayoría deberá
| > ser suficiente.
| > 
| > Con el nuevo bloque de LACNIC (el /12) lo que estamos planeando en ese
| > momento, es implementar el sparce allocation.
| > 
| > Así, además de la reserva, habrá la posibilidad de que el espacio
| > contiguo a esa reserva aun este libre cuando ese ISP vuelva para
| > solicitar bloque adicional. Con eso, se garantiza también una
| > posibilidad de que un ISP crezca allá de la reserva original.
| > 
| > Saludos
| > Ricardo
| > 
| > On Tue, Nov 21, 2006 at 10:32:31PM +0100, JORDI PALET MARTINEZ wrote:
| > | Sino entiendo mal el problema, creo que la solucion menos optima es utilizar
| > | politicas para resolver problemas tecnicos (Traffic Engineering), salvo que
| > | realmente sea un caso extremo y entendamos que todos pagamos las
| > | consecuencias.
| > | 
| > | Nos hemos mal acostumbrado con IPv4 a hacer muchas de estas cosas, y el
| > | resultado es la desagregacion que hemos creado y el incontenible crecimiento
| > | de las tablas de routing.
| > | 
| > | Las ultimos previsiones hablan de que en 5-7 años necesitaras en tu red
| > | routers que sean capaces de gestionar 850.000-1.000.000 de rutas. Imaginas
| > | su coste ? Aun cuando los ISPs mas grandes lo puedan pagar, porque otros
| > | ISPs, posiblemente mas pequeños, tienen que pagar ese coste por la forma de
| > | hacer TE de los mas grandes ? Es eso justo y conveniente ?
| > | 
| > | En el ejemplo que tu indicas, aunque ahora hubiera pedido un /32 y al hacer
| > | el lanzamiento masivo necesite (hoy) un /28, no deberia de ser problema
| > | justificarlo y LACNIC modificaria el prefijo asignado para pasar de ese /32
| > | al /28. Le seguirian quedando suficientes bits en la reserva para el
| > | crecimiento futuro, por mucho que creciera en la mayoria de los casos ...
| > | 
| > | Si lo que se desea ahora es anunciar, digamos del /28 varios /32
| > | desagregados en lugar de un solo /28 agregado, por motivos de TE, creo que
| > | se podria hacer sin necesidad de desagregacion si se llega a acuerdos con
| > | los diversos upstreams. Otra cosa es que ellos no quieran colaborar al 100%
| > | ...
| > | 
| > | Que se pueda hacer con IPv4 no quiere decir que se deba, dado que se esta
| > | haciendo por medio de desagregacion y eso lo vamos a pagar muy caro en pocos
| > | años. Es un tema que esta en continuo debate especialmente desde hace unos
| > | meses en diversos foros, especialmente IETF. Nosotros tambien tenemos un
| > | proyecto nuevo, RiNG (Routing in Next Generation - http://www.ist-ring.eu)
| > | que esta intentando buscar una solucion a todo esto.
| > | 
| > | Pudieramos estar hablando de un proceso de transicion que resultara
| > | posiblemente mucho mas complejo y caro que la de IPv4 a IPv6 ... Salvo que
| > | demos con una varita magica :-)
| > | 
| > | Saludos,
| > | Jordi
| > | 
| > | 
| > | 
| > | 
| > | > De: Roque Gagliano <rgaglian at antel.net.uy>
| > | > Organización: ANTELDATA
| > | > Responder a: <rgaglian at antel.net.uy>
| > | > Fecha: Tue, 21 Nov 2006 19:06:03 -0200
| > | > Para: <jordi.palet at consulintel.es>, LACNIC Policy mailling list
| > | > <politicas at lacnic.net>
| > | > Asunto: Re: [LACNIC/Politicas] Segunda adjudicación IPv6
| > | > 
| > | > Jordi,
| > | > 
| > | > El problema yo lo veo más por el lado de la ingeniería de tráfico que
| > | > por el lado del consumo de /48s.
| > | > 
| > | > Te doy un caso concreto. Ese mismo ISP que puede asignar 50K clientes
| > | > con el bloque que tiene asignado sólo tiene 4 por ahora pues no hizo un
| > | > lanzamiento masivo. Ahora, si presentara el pedido inicial en este
| > | > momento lograría más de un /32, digamos un /28. Esto le permitiría tener
| > | > políticas de enrutamiento diferentes para diferentes servicios (por
| > | > ejemplo enrutar servicios residenciales en ciertos enlaces y servicios
| > | > empresariales en otros, controlar peering de voz y de 3G,etc.) todas
| > | > cosas que hoy se pueden hacer en IPv4, pero que no se pueden hacer con
| > | > un único /32. También te da la posibilidad de ir jugando con tus
| > | > publicaciones a medida que el tráfico ipv6 vaya creciendo.
| > | > 
| > | > 
| > | > slds
| > | > r.
| > | > 
| > | > On Tue, 2006-11-21 at 21:52 +0100, JORDI PALET MARTINEZ wrote:
| > | >> No lo entiendo. Creo que si la reserva es suficientemente grande, se te
| > | >> puede "alargar" el prefijo aun cuando al hacer la primera peticion no
| > hayas
| > | >> calculado nada y no debiera de ser un problema. Ten en cuenta que hay
| > | >> asignado un /12 !
| > | >> 
| > | >> Ejemplo, el ISP a pide hoy un /32 y no pide a LACNIC ninguna reserva
| > (cosa
| > | >> que no debiera de hacer por defecto sin estudiar al menos un poco su red
| > y
| > | >> expectativas de crecimiento).
| > | >> 
| > | >> Si ese /32 le permite, digamos que unos 50.000 clientes con un /48 en el
| > | >> peor de los casos (con una red muy mal estructurada !), aunque este ISP
| > de
| > | >> repente creciera hasta 8.000.000 de clientes (160 veces su tamaño actual
| > !),
| > | >> si se ha hecho una reserva de unos 7 bits mas, son mas que suficientes !
| > | >> 
| > | >> Y si no he hecho mal las cuentas, podria haber unos cuantos miles (8589)
| > de
| > | >> ISPs de este tamaña en la region con un solo /12 (y si se requiere otro,
| > se
| > | >> puede pedir a IANA). Dudo que la membresia pudiera crecer hasta 8500
| > ISPs,
| > | >> aunque seguro que Raul se pondria muy contento si asi fuera ;--)
| > | >> 
| > | >> Igual incluso la reserva de 7 bits es pequeña y hay que reservar 12 :-)
| > | >> 
| > | >> De todos modos yo haria esa reserva como "bits" adicionales respecto de
| > la
| > | >> peticion inicial. Como indicaba ayer, no es un desperdicio, solo es una
| > | >> reserva.
| > | >> 
| > | >> En cualquier caso no me opongo a la politica, sino que creo que hay que
| > | >> razonar primero si es necesaria o es una cuestion que puede resolverse
| > | >> operativamente y ademas maximizar de forma automatica la agregacion,
| > etc.,
| > | >> por mucho que haya falta de prevision a la hora de hacer la primera
| > | >> peticion.
| > | >> 
| > | >> Saludos,
| > | >> Jordi
| > | >> 
| > | >> 
| > | >> 
| > | >> 
| > | >>> De: Roque Gagliano <rgaglian at antel.net.uy>
| > | >>> Organización: ANTELDATA
| > | >>> Responder a: <rgaglian at antel.net.uy>
| > | >>> Fecha: Tue, 21 Nov 2006 18:32:35 -0200
| > | >>> Para: <jordi.palet at consulintel.es>, LACNIC Policy mailling list
| > | >>> <politicas at lacnic.net>
| > | >>> Asunto: Re: [LACNIC/Politicas] Segunda adjudicación IPv6
| > | >>> 
| > | >>> Jordi,
| > | >>> 
| > | >>> La política que estoy planteando es independiente de la política de
| > | >>> reservas. El beneficio de tener un bloque reservado mayor es evitar la
| > | >>> renumeración. Pero por más que esten las direcciones "esperándote" puede
| > | >>> ser que no las tengas en el momento de la planificación de los
| > | >>> servicios.
| > | >>> 
| > | >>> Creo que para lo que yo estoy planteando sí se necesita una política.
| > | >>> 
| > | >>> slds
| > | >>> r.
| > | >>> 
| > | >>> On Tue, 2006-11-21 at 20:45 +0100, JORDI PALET MARTINEZ wrote:
| > | >>>> Hola Roque,
| > | >>>> 
| > | >>>> Comprendido.
| > | >>>> 
| > | >>>> Yo hace tiempo que hable con Ricardo, aunque no directamente de un
| > ejemplo
| > | >>>> equivalente, pero si de como se hacian las reservas y de si hacia falta
| > una
| > | >>>> politica para establecer ese mecanismo y permitir el crecimiento tras
| > una
| > | >>>> primera asignacion.
| > | >>>> 
| > | >>>> Si no mal recuerdo me dijo que creia que era mejor que dado que esto
| > era
| > | >>>> pura operativa, continuara en sus manos.
| > | >>>> 
| > | >>>> Asi que quizas es mejor hacer una recomendación (que bien podria ser
| > | >>>> politica si fuera el caso, pero creo que no es preciso), de como
| > asignar
| > | >>>> esas reservas (vease el mi correo del otro dia que mencionaba reservar
| > un
| > | >>>> nuemero de bits mayor que el actual, etc.).
| > | >>>> 
| > | >>>> Recuerdo haber visto un par de documentos aunque no necesariamente al
| > | >>>> respecto de esto, pero que podrian ser usados para esta operativa
| > dentro de
| > | >>>> LACNIC:
| > | >>>> 
| > | >>>> http://www.ripe.net/docs/ipv6-sparse.html
| > | >>>> http://www.arin.net/meetings/minutes/ARIN_XV/PDF/mon/mei-wang.pdf
| > | >>>> 
| > | >>>> Saludos,
| > | >>>> Jordi
| > | >>>> 
| > | >>>> 
| > | >>>> 
| > | >>>> 
| > | >>>>> De: Roque Gagliano <rgaglian at antel.net.uy>
| > | >>>>> Organización: ANTELDATA
| > | >>>>> Responder a: <rgaglian at antel.net.uy>
| > | >>>>> Fecha: Tue, 21 Nov 2006 15:14:21 -0300
| > | >>>>> Para: <jordi.palet at consulintel.es>, LACNIC Policy mailling list
| > | >>>>> <politicas at lacnic.net>
| > | >>>>> Asunto: Re: [LACNIC/Politicas] Segunda adjudicación IPv6
| > | >>>>> 
| > | >>>>> Jordi, te contesto entre líneas.
| > | >>>>> 
| > | >>>>> On Mon, 2006-11-20 at 09:44 +0100, JORDI PALET MARTINEZ wrote:
| > | >>>>>> Hola Roque,
| > | >>>>>> 
| > | >>>>>> Me pregunto hasta que punto es realmente necesaria esta politica en
| > | >>>>>> funcion
| > | >>>>>> de como LACNIC esta asignando los bloques, haciendo reservas que
| > permiten
| > | >>>>>> obtener un bloque mas grande que incluya el bloque anterior, y por
| > tanto
| > | >>>>>> evitando la renumeracion.
| > | >>>>>> 
| > | >>>>> El hecho de que se haga la reserva es una tema administrativo de
| > LACNIC.
| > | >>>>> Justamente atendiendo a esta posibilidad la devolución del bloque
| > | >>>>> adicional puede no requerirse.
| > | >>>>> 
| > | >>>>>> Por otro lado, si de lo que se trata es de facilitar entornos de
| > pruebas
| > | >>>>>> (cosa que creo que hoy ya no es necesaria), siempre existen otras
| > formas,
| > | >>>>>> como los prefijos experimentales (aplicables solo en algunas casos),
| > o la
| > | >>>>>> cesion de bloques mas pequeños de forma temporal por parte del
| > upstream
| > | >>>>>> provider, etc.
| > | >>>>>> 
| > | >>>>> 
| > | >>>>> Muchos proveedores acceden primero a un bloque /32 que pueden
| > justificar
| > | >>>>> sin "pensar" mucho en sus planes a largo plazo, a eso lo llamo
| > "ambiente
| > | >>>>> de pruebas". Cuando haces los planes a largo plazo y te enfrentas a
| > | >>>>> necesitar más direcciones. Básicamente me refiero al paso desde la
| > etapa
| > | >>>>> 1 a la etapa 2 de lo establecido por el RFC 4029.
| > | >>>>> 
| > | >>>>> 
| > | >>>>>> Por ultimo, las facilidades existentes en LACNIC para recibir el
| > prefijo
| > | >>>>>> sin
| > | >>>>>> coste, y la facilidad de justificar el tamaño del prefijo desde el
| > primer
| > | >>>>>> momento (ejemplo, tengo N millones de clientes y a cada uno le voy a
| > | >>>>>> asignar
| > | >>>>>> un /48, luego asigneme un bloque de al menos Nx/48x180%), tambien me
| > | >>>>>> parecen
| > | >>>>>> suficientes.
| > | >>>>>> 
| > | >>>>> 
| > | >>>>> Esta claro que si se hubiera hecho una justificación inicial se podría
| > | >>>>> haber obtenido un bloque mayor. Por eso lo que planteo es que LACNIC
| > | >>>>> pueda estudiar la segunda asignación como si fuera una asignación
| > | >>>>> inicial. 
| > | >>>>> 
| > | >>>>> 
| > | >>>>>> En cualquier caso, quizas Ricardo nos puede aclarar como se determina
| > el
| > | >>>>>> bloque que se reserva con cada entrega, especialmente por si hay
| > | >>>>>> posibilidad
| > | >>>>>> "operativa" de que al contar la region con un /12 esta reserva se
| > | >>>>>> incremente
| > | >>>>>> aun mas (facilitando mas el crecimiento y la agregacion) ?
| > | >>>>>> 
| > | >>>>>> Saludos,
| > | >>>>>> Jordi
| > | >>>>>> 
| > | >>>>>> 
| > | >>>>>> 
| > | >>>>>> 
| > | >>>>>>> De: Roque Gagliano <rgaglian at antel.net.uy>
| > | >>>>>>> Organización: ANTELDATA
| > | >>>>>>> Responder a: LACNIC Policy mailling list <politicas at lacnic.net>
| > | >>>>>>> Fecha: Wed, 15 Nov 2006 09:58:13 -0300
| > | >>>>>>> Para: LACNIC Policy mailling list <politicas at lacnic.net>
| > | >>>>>>> Asunto: [LACNIC/Politicas] Segunda adjudicación IPv6
| > | >>>>>>> 
| > | >>>>>>> Hola,
| > | >>>>>> 
| > | >>>>>> Quisiera plantear el siguiente cambio para la política de
| > | >>>>>>> asignaciones
| > | >>>>>> sucesivas de IPv6 en la
| > | >>>>>>> región:
| > | >>>>>> 
| > | >>>>>> --------------------------------
| > | >>>>>> 5.2 Adjudicación subsiguiente
| > | >>>>>> 
| > | >>>>>> Las
| > | >>>>>>> organizaciones que ya tengan una adjudicación IPv6 pueden
| > | >>>>>>> recibir
| > | >>>>>> adjudicaciones subsiguientes de acuerdo a las siguientes
| > | >>>>>>> políticas.
| > | >>>>>> 
| > | >>>>>> Segunda adjudicación
| > | >>>>>> 
| > | >>>>>> En el caso de una organización cuente con
| > | >>>>>>> una única adjudicación IPv6,
| > | >>>>>> se realizará por única vez un análisis
| > | >>>>>>> diferencial.
| > | >>>>>> 
| > | >>>>>> Si una organización en estas condiciones está dispuesta a
| > | >>>>>>> devolver a
| > | >>>>>> LACNIC en un plazo de 6 meses el bloque inicial adjudicado, se
| > | >>>>>>> estudiará
| > | >>>>>> la nueva adjudicación como si se tratara de una adjudicación inicial
| > | >>>>>>> con
| > | >>>>>> los criterios descriptos en la sección 5.1. De esta forma, y sólo en
| > | >>>>>> este
| > | >>>>>>> caso, no valen los criterios descriptos en 5.2.1 (criterio) , 5.2.2
| > | >>>>>> (HD ratio)
| > | >>>>>>> y 5.2.3 (tamaño).
| > | >>>>>> 
| > | >>>>>> --------------------------------
| > | >>>>>> 
| > | >>>>>> Justificación:
| > | >>>>>> 
| > | >>>>>> Esta
| > | >>>>>>> política se plantea para facilitar la transición entre la etapa
| > | >>>>>> piloto y el
| > | >>>>>>> desarrollo extendido de IPv6,evitando la renumeración de la
| > | >>>>>> red.
| > | >>>>>> 
| > | >>>>>> Al menos en
| > | >>>>>>> nuestro caso, el pedido inicial de un bloque IPv6 fue para
| > | >>>>>> ser utilizado en un
| > | >>>>>>> ambiente de prueba, conocer protocolos y
| > | >>>>>> herramientas, pero es insuficiente
| > | >>>>>>> para las necesidades reales de la
| > | >>>>>> empresa.
| > | >>>>>> 
| > | >>>>>> En este momento estamos haciendo
| > | >>>>>>> un plan más ambicioso, pero nos
| > | >>>>>> encontramos que ante la necesidad de más
| > | >>>>>>> direcciones no llenamos en este
| > | >>>>>> momento los criterios de 5.2.1 a
| > | >>>>>>> 5.2.3.
| > | >>>>>> 
| > | >>>>>> 
| > | >>>>>> --------------------------------
| > | >>>>>> 
| > | >>>>>> ___________________________________
| > | >>>>>>> ____________
| > | >>>>>> Politicas mailing
| > | >>>>>>> list
| > | >>>>>> Politicas at lacnic.net
| > | >>>>>> http://www.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
| > | >>>>>> http://www.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
| > | >>>> http://www.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
| > | >> http://www.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
| > | http://www.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
| http://www.lacnic.net/mailman/listinfo/politicas
| 