[LACNIC/Politicas] Segunda adjudicaci=?ISO-8859-1?B?8w==?=n IPv6

[JORDI PALET MARTINEZ]

Hola Christian,

Yo hable de vuestro caso sin decirlo, pero ya que tu lo dices no es problema
:-)

La cuestion es que si se hacen reservas mas grandes o como ha comentado
Ricardo en otro correo sparse allocation, e incluso mejor ambas cosas juntas
(reservas mas grandes y sparse allocation), entonces, el nuevo caso en el
que tu te encuentras no seria un problema.

Entiendo que mucho vais a dar servicio en, digamos que otros 8 paises mas ?
Es decir, que necesitas el equivalente a 8x/32 junto a lo que ya tienes.
Según como sea la reserva existente, no debe de ser un problema, y asi
evitas la renumeracion, o quedarte con ese bloque, obtener otro y anunciar
dos prefijos, pero como comentaba en otro correo, creo que es la peor
solucion.

Saludos,
Jordi




> De: "ARG-O'FLAHERTY, CHRISTIAN" <COFLAHERTY at IMPSAT.COM>
> Responder a: LACNIC Policy mailling list <politicas at lacnic.net>
> Fecha: Thu, 23 Nov 2006 15:18:31 -0300
> Para: LACNIC Policy mailling list <politicas at lacnic.net>
> Conversación: [LACNIC/Politicas] Segunda adjudicación IPv6
> Asunto: RE: [LACNIC/Politicas] Segunda adjudicación IPv6
> 
> 
> En Impsat tuvimos un caso similar al que comenta Roque y creo que el caso que
> mencionaron es el de Comsat. Tal vez el próximo año tengamos que devolver el
> bloque que recibimos y pedir uno mayor todavía porque fuimos comprados por
> otra empresa y tendremos servicios en mas cantidad de países de la región.
> 
> Tal vez podemos analizar el tema de manera mas general.
> ¿Es factible que un miembro pueda devolver un recurso (IPv4/IPv6) para recibir
> otro?
> 
> A FAVOR: Si no permitimos la devolución el miembro pide el bloque nuevo y se
> queda con el viejo sin usarlo.
> 
> EN CONTRA: ¿Como nos aseguramos que no habrá abusos? (pidiendo bloques que
> serán mal usados y cuando caen en blacklists o filtros de algún tipo los
> devuelve con la excusa que necesitan un bloque mas grande)
> 
> Christian
> 
> -----Original Message-----
> From: politicas-bounces at lacnic.net [mailto:politicas-bounces at lacnic.net] On
> Behalf Of JORDI PALET MARTINEZ
> Sent: Miércoles, 22 de Noviembre de 2006 04:26 p.m.
> To: politicas at lacnic.net
> Subject: Re: [LACNIC/Politicas] Segunda adjudicación IPv6
> 
> Hola Oscar,
> 
> Quizas me he expresado mal. No preveo que con esta operativa tengamos una bola
> de cristal, pero si esta prevision, que no hace daño, ayuda en evitar en unos
> años x renumeraciones y/o x prefijos adicionales en la tabla de routing, creo
> que ha de ser bienvenida.
> 
> Piensa que en los baremos/orden de magnitud en que nos movemos con 7-8 bits
> adicionales en un prefijo IPv6, es dificilmente creible que la gran mayoria
> (por no decir el 99%) de los ISPs se queden cortos en decenas de años, y bajo
> ese punto de vista seria una planificacion (mas que "prediccion") muy
> acertada, e insisto, sin causar ningun daño.
> 
> Yo confio plenamente en el criterio del staff, y precisamente por eso, pienso
> que seria mejor, ahora que se tiene un /12, ampliar la "distancia" en las
> reservas que ya se estan haciendo, y por tanto posiblemente no hace falta esta
> politica.
> 
> Sin embargo, si no se explica ese criterio, si se cambia o no, etc., los
> participantes de la lista pueden pensar que si que hace falta una politica
> para definir lo que yo pienso, como tu, que es operativa del staff.
> 
> Saludos,
> Jordi
> 
> 
> 
> 
>> De: "Oscar A. Robles-Garay" <orobles at nic.mx> Responder a:
>> <orobles at nic.mx>
>> Fecha: Wed, 22 Nov 2006 11:36:35 -0600
>> Para: <jordi.palet at consulintel.es>, LACNIC Policy mailling list
>> <politicas at lacnic.net>, <politicas at lacnic.net>
>> Asunto: Re: [LACNIC/Politicas] Segunda adjudicación IPv6
>> 
>> Roque, Jordi,
>> 
>> Me parece que no deberíamos meternos en estas complicaciones. Aunque
>> sería deseable preveer el futuro, no somos los primeros que lo
>> quisiéramos hacer con precisión y dudo mucho que seamos los primeros
>> que lo logremos.
>> 
>> Definir una regla para preveer/predecir el crecimiento de los clientes
>> de IPv6 raya más en temas esotéricos que ingenieriles... Un oráculo,
>> la baraja o las estrellas tendrán la misma efectividad en sus pronósticos.
>> 
>> Existen demasiados factores no determinísticos que afectan estas
>> predicciones: Aspectos macroeconómicos, alianzas comerciales,
>> disruptores tecnológicos, cambios políticos (o no cambios
>> políticos)... o el simple hecho de que despidan al responsable de la
>> Red puede afectar de manera muy seria el crecimiento de un ISP... a
>> favor o en contra.
>> 
>> Confiemos en que el staff de LACNIC utilice sus propios criterios,
>> sentido común y experiencia para estos asuntos. Sabemos que el grado
>> de eficiencia no será perfecto pero suficiente como para estar
>> tranquilos.
>> 
>> Saludos,
>> 
>> Oscar
>> 
>> 
>> At 03:32 PM 11/21/2006, 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
> 
> 
> 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
> 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.