[LACNIC/Politicas] Revision de politica - Asignaciones IPv6 Independientes del Proveedor (PI) para organizaciones-usuario-final
Jose Enrique Diaz Jolly
ediaz at ironport.com
Tue Mar 20 20:33:40 BRT 2007
Esas situaciones no son nuevas en las listas y a veces unos cuanttos correos directos no pierden sentido a las discusiones.... Por lo que pueden ponerse de acuerdo en algunos puntos, particularmente a los que puedan generar confusion y regresar siempre a la lista para ilustracion de los que no tenemos el expertise que tienen los dema. Yo en lo particular he aprendido varias cosas, de esta y otras discusiones con respecto a IPv6, tema del que me considero neofito.....
---
José Enrique Díaz Jolly Aristóteles 81-202
Systems Engineer Chapultepec Polanco
IronPort Systems, México México, D.F., 11560
Ph: +52(1)55-2300-5458 (Mobile) Ph:
www.ironport.com - The Leader in E-Mail Security
---
IronPort Systems Toll-Free Customer Support Numbers:
Mexico: 001-866-296-5992
U.S.: 1-877-641-IRON (4766)
Int'l : www.ironport.com/support/contact_support.html
Support Portal: www.ironport.com/support
> -----Original Message-----
> From: politicas-bounces at lacnic.net
> [mailto:politicas-bounces at lacnic.net] On Behalf Of JORDI
> PALET MARTINEZ
> Sent: Tuesday, March 20, 2007 5:06 PM
> To: LACNIC Policy mailling list
> Subject: Re: [LACNIC/Politicas] Revision de politica -
> Asignaciones IPv6 Independientes del Proveedor (PI) para
> organizaciones-usuario-final
>
> Totalmente de acuerdo y soy siempre partidario de estos
> debates en la lista, no en privado, pero creo que en este
> caso el email no nos esta ayudando porque en algunos puntos
> creo que no nos estamos entendiendo, y quizas aprovechar que
> estamos en la misma reunion, ayude para luego explicarlo en la lista.
>
> Saludos,
> Jordi
>
>
>
>
> > De: Jose Enrique Diaz Jolly <ediaz at ironport.com> Responder a:
> > <prvs=ediaz=592eb885b at ironport.com>
> > Fecha: Tue, 20 Mar 2007 09:22:51 -0700
> > Para: <jordi.palet at consulintel.es>, LACNIC Policy mailling list
> > <politicas at lacnic.net>
> > Conversación: [LACNIC/Politicas] Revision de politica -
> Asignaciones
> > IPv6 Independientes del Proveedor (PI) para
> > organizaciones-usuario-final
> > Asunto: RE: [LACNIC/Politicas] Revision de politica - Asignaciones
> > IPv6 Independientes del Proveedor (PI) para
> > organizaciones-usuario-final
> >
> >
> > Jordi, Gustavo
> >
> >
> > Creo que es sano que se siga discutiendo aqui, ya que forma una
> > opinion y un criterio puede ser definido.
> >
> >
> > ---
> >
> > José Enrique Díaz Jolly Aristóteles 81-202
> > Systems Engineer Chapultepec Polanco
> > IronPort Systems, México México, D.F., 11560
> >
> > Ph: +52(1)55-2300-5458 (Mobile) Ph:
> >
> > www.ironport.com - The Leader in E-Mail Security
> >
> > ---
> >
> > IronPort Systems Toll-Free Customer Support Numbers:
> >
> > Mexico: 001-866-296-5992
> > U.S.: 1-877-641-IRON (4766)
> > Int'l : www.ironport.com/support/contact_support.html
> >
> > Support Portal: www.ironport.com/support
> >
> >
> >> -----Original Message-----
> >> From: politicas-bounces at lacnic.net
> >> [mailto:politicas-bounces at lacnic.net] On Behalf Of JORDI PALET
> >> MARTINEZ
> >> Sent: Tuesday, March 20, 2007 7:24 AM
> >> To: LACNIC Policy mailling list
> >> Subject: Re: [LACNIC/Politicas] Revision de politica -
> Asignaciones
> >> IPv6 Independientes del Proveedor (PI) para
> >> organizaciones-usuario-final
> >>
> >> Hola Gustavo,
> >>
> >> Contesto debajo.
> >>
> >> Por cierto, como estamos ambos en el IETF en Praga, igual interesa
> >> que cuando nos veamos mañana lo comentemos y veamos si
> podemos llegar
> >> a un acuerdo en lugar de seguir bombardeando a la lista
> :-) Lo digo
> >> porque igual obtenemos el efector contrario, que la gente
> no opine al
> >> respecto !
> >>
> >> Saludos,
> >> Jordi
> >>
> >>
> >>
> >>
> >>> De: Gustavo Lozano <glozano at nic.mx>
> >>> Responder a: <glozano at nic.mx>
> >>> Fecha: Tue, 20 Mar 2007 13:35:55 +0100
> >>> Para: <jordi.palet at consulintel.es>, LACNIC Policy mailling list
> >>> <politicas at lacnic.net>, LACNIC Policy mailling list
> >>> <politicas at lacnic.net>
> >>> Asunto: Re: [LACNIC/Politicas] Revision de politica - Asignaciones
> >>> IPv6 Independientes del Proveedor (PI) para
> >>> organizaciones-usuario-final
> >>>
> >>> Comentarios entre lineas.
> >>>
> >>> At 20:49 19/03/2007, JORDI PALET MARTINEZ wrote:
> >>>> Hola Gustavo, y todos (seria importante tener la opinion
> >> de TODOS los
> >>>> participantes !),
> >>>>
> >>>> No se si hay un limite preciso de fecha para enviar una nueva
> >>>> version, pero mi intencion era enviarlo a lo sumo a lo
> >> largo de la proxima semana.
> >>>>
> >>>> Precisamente estaba esperando nuevos comentarios, y estos son
> >>>> bienvenido para animar a otros a opinar al respecto.
> >>>>
> >>>> Tengo claro, que igual que en la version 2, sera
> >> permanente, eso no
> >>>> tiene sentido ir hacia atrás. No crees ?
> >>>
> >>> De acuerdo, las version 3.0 de tu propuesta o nuevas
> >> propuestas deben
> >>> generar una política permanente.
> >>>
> >>>> Tambien tengo claro que el punto de partida es un /48, pero
> >>>> sinceramente no te puedo decir si mantendre la
> posibilidad de que
> >>>> pueda crecer a hasta lo justificado o no.
> >>>> En principio creo que no es bueno cerrarlo, y si lo
> >> cerramos, desde
> >>>> luego propondre tambien que entonces se haga lo mismo con las
> >>>> infraestructuras criticas, porque en realidad es PI, y no
> >> hay por que
> >>>> hacer diferencia. PERO, me atengo a lo comentarios que
> haya en los
> >>>> proximos dias.
> >>>
> >>> Tienes la libertad de proponer lo que tu consideres adecuado para
> >>> infraestructuras criticas, pero, por favor, por el BIEN de
> >> la región,
> >>> realiza una nueva propuesta para infraestructuras criticas y no
> >>> incluyas texto sobre infraestructuras criticas en la
> >> propuesta de PI
> >>> para END-SITES. Si incluyes texto de infraestructuras
> >> críticas en lo
> >>> de PI para END-SITES se puede convertir en algo muy difuso
> >> y entonces
> >>> lo más probable es que no se llegue a consenso sobre la
> política y
> >>> sigamos discutiendo lo mismo en el 2008.
> >>
> >> Totalmente de acuerdo, seria algo separado, si es el caso
> (espero que
> >> no).
> >>
> >>>
> >>>> Unas preguntas, sin divagar para concretar, y una observacion:
> >>>>
> >>>> 1) Que mal le ves a permitir que si se justifica se crezca ?
> >>>
> >>> Si dejamos un /32 para el /48, entonces se sigue
> desperdiciando el
> >>> recurso y llegamos a lo mismo que hemos discutido todo
> este tiempo.
> >>
> >> No me referia a dejar la reserva. Creo que lo dejemos dejar a la
> >> discrecion de LACNIC y que lo resuelvan ellos como mas conveniente
> >> les sea.
> >>
> >> A lo que me refiero es que la politica no se limite a
> hablar de dos
> >> medidas
> >> /48 y /44, sino /48 o un prefijo mas corto si se justifica.
> >>
> >>>
> >>> Desde LACNIC pasado se ha propuesto dejar reservado un
> /44 para el
> >>> crecimiento del END-SITE, no se esta cerrando a un /48.
> >>>
> >>>
> >>>> 2) Entiendes que no es "fair" hacer diferencia con la politia de
> >>>> infraestructuras criticas si decidimos que no ?
> >>>
> >>> Si crees que no es "fair" entonces realiza una nueva
> política para
> >>> infraestructura críticas y la discutimos. Lo que yo no
> creo que sea
> >>> "fair" es recuperar recurso que ya fue asignado bajo el
> >> esquema actual
> >>> de asignacion para infraestructuras críticas. Existe la
> política de
> >>> recuperación de IPv4 pero la misma es por falta de USO del
> >> recurso. No
> >>> creo que sea bueno meternos ahorita a discutir sobre políticas
> >>> RETROACTIVAS.
> >>>
> >>>> La observacion es que en algun correo (empiezo a perderme
> >> y no se si
> >>>> ha sido en esta region u en otro) se ha comentado que si
> >> se llega a
> >>>> un /32, es mejor ser un LIR (es decir, recibir PA), pero
> >> esto NO es
> >>>> posible con la politica actual, pues para eso hay que ser
> >> ISP y dar
> >>>> servicio a terceros. Esto es imporante para enteder porque
> >> no se puede optar a PA.
> >>>>
> >>>> Y un ejemplo. Crees que una gran empresa, que tenga multiples
> >>>> end-sites (un banco), que incluso puede ser multinacional, si
> >>>> justifica la necesidad de PI, y necesita un /38 (por poner
> >> una cifra
> >>>> que no estamos barajando, simplemente de ejemplo), deberia
> >> de optar a
> >>>> ello ? Si limitamos a que sea
> >>>> /48 o /44, no tendria opcion. Por eso creo que el criterio
> >> del staff
> >>>> es muy relevante aquí.
> >>>
> >>> Vamos a leer lo que dice la actual política de IPv6
> >> referente a LIRs.
> >>>
> >>> "Un Local Intenet Registry (LIR) es un IR que asigna,
> >> principalmente,
> >>> espacios de direcciones a los usuarios de los servicios
> de red que
> >>> éste provee. Los LIRs son generalmente ISPs, cuyos clientes son
> >>> principalmente usuarios finales y posiblemente otros ISPs."
> >>>
> >>> En ningún lado dice que un LIR tiene que ser forzosamente un ISP
> >>> (Generalmente no es sinónimo de forzosamente). Una gran
> >> empresa, una
> >>> universidad, un banco, una multinacional, etc.
> >>> pueden caer en la definición de un LIR porque asignan
> direcciones a
> >>> los usuarios de los servicios de red que provee.
> >>>
> >>
> >>
> >> Yo no tengo la misma lectura, porque la parte del criterio de
> >> adjudicacion inicial NO lo permite, pues dice bien claro:
> >>
> >> b) no ser un sitio final (usuario final);
> >>
> >> De hecho esto es lo que ha motivado en esta y otras regiones la
> >> necesidad de PI, sino no seria preciso, pues cualquier
> organización
> >> que necesite PI puede argumentar que tiene una estructura
> con varios
> >> "end-sites" de su propia organization.
> >>
> >>>
> >>>
> >>>> Debajo contesto al resto de tu correo.
> >>>>
> >>>> Saludos,
> >>>> Jordi
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>> De: Gustavo Lozano <glozano at nic.mx> Responder a:
> <glozano at nic.mx>
> >>>>> Fecha: Mon, 19 Mar 2007 19:25:54 +0100
> >>>>> Para: <jordi.palet at consulintel.es>, LACNIC Policy mailling list
> >>>>> <politicas at lacnic.net>, <politicas at lacnic.net>
> >>>>> Asunto: Re: [LACNIC/Politicas] Revision de politica -
> >> Asignaciones
> >>>>> IPv6 Independientes del Proveedor (PI) para
> >>>>> organizaciones-usuario-final
> >>>>>
> >>>>> Jordi,
> >>>>>
> >>>>> La pregunta es que va a decir la version 3 de tu
> propuesta en los
> >>>>> puntos discutidos en el foro publico.
> >>>>>
> >>>>> Nos podrias decir porfavor que va a decir la version 3.0 de tu
> >>>>> propuesta en los siguientes puntos:
> >>>>>
> >>>>> Asignacion fija a /48 con /44 de reserva o permitir
> hasta un /32.
> >>>>> Es temporal o permanente.
> >>>>>
> >>>>> Esto es necesario para saber si se envia una politica
> alternativa
> >>>>> porque no es bueno para los operadores de la region esten en
> >>>>> desventaja.
> >>>>>
> >>>>> Comentarios en el texto.
> >>>>>
> >>>>> At 18:18 19/03/2007, JORDI PALET MARTINEZ wrote:
> >>>>>> Hola Gustavo,
> >>>>>>
> >>>>>> Mil gracias por los comentarios.
> >>>>>>
> >>>>>> En realidad ya estaba trabajando en una
> >>>> version 3 por otros comentarios que
> >>>>>> he recibido.
> >>>>>>
> >>>>>> Respecto de las otras regiones, tambien lo he comentado en un
> >>>>>> correo anterior. Tanto ARIN como APNIC ya han implementado las
> >>>>>> politicas de IPv6 PI.
> >>>>>>
> >>>>>> Te contesto entre lineas al resto.
> >>>>>>
> >>>>>> Saludos,
> >>>>>> Jordi
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> De: Gustavo Lozano <glozano at nic.mx> Responder a:
> <glozano at nic.mx>
> >>>>>> Fecha: Mon, 19 Mar 2007 17:22:22 +0100
> >>>>>> Para: <politicas at lacnic.net>, JORDI PALET MARTINEZ
> >>>>>> <jordi.palet at consulintel.es>
> >>>>>> Asunto: Re: [LACNIC/Politicas] Revision de politica -
> >> Asignaciones
> >>>>>> IPv6 Independientes del Proveedor (PI) para
> >>>>>> organizaciones-usuario-final
> >>>>>>
> >>>>>> Jordi,
> >>>>>>
> >>>>>> El texto de la versión 2.0 de la política me parece
> que toma en
> >>>>>> cuenta algunos de los comentarios que se hicieron
> >>>> en el foro publico pero no todos.
> >>>>>>
> >>>>>> Mis comentarios entre líneas.
> >>>>>>
> >>>>>> Creo que también es importante que la comunidad conozca que en
> >>>>>> otras regiones ya es posible solicitar espacio portable
> >> en IPv6, y
> >>>>>> en la región LAC estamos en desventaja.
> >>>>>>
> >>>>>> Moderador de la lista de políticas creo que mis
> >> comentarios entre
> >>>>>> líneas deben ser evaluados en el foro. ¿Cual es el proceso a
> >>>>>> seguir? Si Jordi accede, puede Jordi volver a enviar la
> >>>> política con el texto modificado o es
> >>>>>> necesario enviar una nueva política escrita por alguien mas?
> >>>>>>
> >>>>>> On Tue, 2007-03-06 at 18:33 +0100, JORDI PALET MARTINEZ wrote:
> >>>>>>> Hola a todos,
> >>>>>>>
> >>>>>>> Esta es una version revisada de la ya
> >>>> anteriormente presentada, teniendo en
> >>>>>>> cuenta comentarios recibidos, etc. Os ruego
> >>>> comentarios al respecto en los
> >>>>>>> proximos dias, por si fuera preciso
> >>>>>> modificarla de cara a la proxima reunion
> >>>>>>> y facilitar asi una redaccion mas "limpia".
> >>>>>>>
> >>>>>>>
> >>>>>>> 1. Numero: (a asignar por LACNIC)
> >>>>>>>
> >>>>>>> 2. Nombre de la Propuesta de Politica:
> >>>>>>>
> >>>>>>> Asignaciones IPv6 Independientes del Proveedor (PI) para
> >>>>>>> Organizaciones-Usuario-Final
> >>>>>>>
> >>>>>>> 3. Autor:
> >>>>>>> a. name: Jordi Palet Martinez
> >>>>>>> b. e-mail: jordi.palet at consulintel.es
> >>>>>>> c. organisation: Consulintel
> >>>>>>>
> >>>>>>> 4. Version de la Propuesta: 2.0
> >>>>>>>
> >>>>>>> 5. Fecha de envio: 6/3/2007
> >>>>>>>
> >>>>>>> 6. Tipo de Propuesta:
> >>>>>>> NUEVA
> >>>>>>>
> >>>>>>> 7. Plazo de la Politica:
> >>>>>>>
> >>>>>>> Permanente
> >>>>>>>
> >>>>>>> 8. Sumario de la propuesta:
> >>>>>>>
> >>>>>>> Esta politica se presenta como posible solucion para
> >>>>>>> organizaciones que necesitan asignaciones IPv6 independientes
> >>>> del proveedor (en adelante PI).
> >>>>>>>
> >>>>>>> Por lo general dichas organizaciones requeriran la
> >> asignacion del
> >>>>>>> PI para cumplir con requisitos de multihoming en la
> >>>> forma tradicional utilizada con
> >>>>>>> IPv4, pero puede haber otras razones detrás
> >>>> de dicha peticion. Por ejemplo,
> >>>>>>> algunas organizations no requieren
> >>>> multihoming, pero aun así necesitan que
> >>>>>>> sus asignaciones sean globalmente
> >>>>>> encaminables con direccionamiento estable.
> >>>>>>> Podria haber el deseo de evitar la renumeracion si
> >> cambian de proveedor.
> >>>>>>> Esto podria deberse a razones
> >>>> administrativas, politicas o de seguridad. En
> >>>>>>> estos casos, parece que actualmente no hay otra
> >> solucion mas que
> >>>>>>> las asignaciones de PI.
> >>>>>>>
> >>>>>>> Considerando las consecuencias del medio/largo plazo que esta
> >>>>>>> politica podria ocasionar en las tablas de encaminado,
> >> la anterior
> >>>>>>> version de esta propuesta sugeria una fecha de expiracion
> >>>> de tres años para esta politica.
> >>>>>>> Este periodo de tres años comenzaria a contar una vez
> >> que exista
> >>>>>>> una solucion tecnicamente viable y operacionalmente
> >> desplegable,
> >>>>>>> que sea aceptada por la comunidad de Internet. Tras el
> >> periodo de
> >>>>>>> gracia, las asignaciones hechas con propositos de
> >>>>>> multihoming deberian de ser reclamadas
> >>>>>>> y esta politica deberia de ser modificara para continuar
> >>>>>>> permitiendo las asignaciones que sean requeridas para
> >>>> propositos diferentes al multihoming.
> >>>>>>> En dicho momento, cualquier organización que
> >>>>>> requiera evitar la renumeracion
> >>>>>>> podria optar a convertirse en LIR, si asi cualifica
> >> para ello, y
> >>>>>>> se le adjudicaria el mismo prefijo.
> >>>>>>>
> >>>>>>> El cambio introducido en esta version
> >>>> considera que la comunidad "no cree"
> >>>>>>> en las politicas temporales, y en cualquier
> >>>> caso, cualquier politica puede
> >>>>>>> ser derogada si es preciso por el propio
> >>>> proceso. Por tanto se presenta en
> >>>>>>> este caso como una politica permanente.
> >>>>>>>
> >>>>>>
> >>>>>> Creo que no es necesario documentar la
> >>>> percepción sobre el sentimiento de la
> >>>>>> comunidad para el proceso de creación de políticas. Aunque no
> >>>>>> afecta el texto de la política quiero comentar que no estoy de
> >>>>>> acuerdo con el argumento presentado en el párrafo anterior.
> >>>>>>
> >>>>>> [Jordi] Se trataba de dar una vision de la situacion. No
> >> se si lo
> >>>>>> que te parece poco oportuno es el "no creer", pero
> >>>> la realidad es que el comentario
> >>>>>> recibido fue bastante claro en este sentido,
> >>>> no veian una politica temporal
> >>>>>> como valida. Como tu dices en cualquier caso no afecta
> >> al texto de
> >>>>>> la propuesta.
> >>>>>
> >>>>> [Gustavo] Creo que es una falicia tratar de dar una
> >> vision de lo que
> >>>>> piensa una comunidad por completo. Al menos para mi persona una
> >>>>> politica temporal no es valida para este caso en particular.
> >>>>
> >>>> Creo que no nos hemos entendido. Lo version 2 ya es
> >> permanente y la 3
> >>>> tambien lo sera !
> >>>
> >>> La idea es que se clarificara el punto. Nada impide cambiar la
> >>> politica a temporal en la version 3.0.
> >>>
> >>>>>
> >>>>>>
> >>>>>>> 10. Texto de la Politica:
> >>>>>>>
> >>>>>>> Cualificacion para una asignacion IPv6 PI:
> >>>>>>> Para cualificar para una asignacion
> >>>> directa, la organización no debe de ser
> >>>>>>> un LIR IPv6, y debe cualificar para una
> >>>> asignacion o adjudicacion IPv4 por
> >>>>>>> parte de LACNIC. Esto aplica tanto si la organización
> >> tiene como
> >>>>>>> si no, asignado o adjudicado dicho espacio IPv4.
> >>>>>>>
> >>>>>>> Tamaño de la asignacion IPv6 PI:
> >>>>>>> El tamaño minimo para la asignacion es un
> >>>>>> /48, aunque un bloque mayor podria
> >>>>>>> ser asignado si se documenta y justifica
> >>>>>> convenientemente. Por ejemplo si se
> >>>>>>> justifica a los hostmasters que un /48 es filtrado, se podria
> >>>>>>> optar a un /32. El criterio de los hostsmasters podria ser el
> >>>>>>> mismo utilizado en la politica de infraestructuras
> >> criticas, pues
> >>>>>>> basicamente no tiene sentido entregar un /48 que sea
> >> filtrado, y
> >>>>>>> por tanto la politica no cumple su cometido en ese
> >> caso, por lo que es preciso utilizar un /32.
> >>>>>>>
> >>>>>>
> >>>>>> Como lo comente en la pasada reunión de LACNIC:
> >>>>>> * Esta política esta enfocada a los ³end-sites², porque si no
> >>>>>> fueran un ³end-site² fueran un LIR y no tendrían
> >>>> problemas para actualmente solicitar
> >>>>>> un /32.
> >>>>>> * He escuchado los argumentos de que el
> >>>> espacio en IPv6 es casi ilimitado y
> >>>>>> las hipótesis de que durará siglos, etc.,
> >>>> pero lo mismo se decía de IPv4, no
> >>>>>>
> >>>>>> [Jordi] Creo que el orden de magnitud, es casi infinitamente
> >>>>>> incomparable con IPv4. A mi me basta con que IPv6 dure
> >>>> unos 100 años, y las expectativas
> >>>>>> estan en 480 en el peor de los casos, aun cuando nos
> >> equivaramos,
> >>>>>> no seria grave, pues sinceramente dudo que tengamos
> >>>> IP tal y como lo conocemos hoy en
> >>>>>> 100-150 años ?.
> >>>>>
> >>>>> [Gustavo] Las HIPOTESIS dicen que 480 años es el peor de
> >> los casos.
> >>>>> Creo que nadie conoce el futuro y las aplicaciones que
> se puedan
> >>>>> crear. En la mayoria de las actividades de la vida se toman
> >>>>> precauciones para evitar el desperdicio innecesario. En
> mi ciudad
> >>>>> hay 5 años de reserva de agua en las presas locales y no
> >> por eso me
> >>>>> voy a poner a tirar el agua. Imaginate que alguna
> aplicacion por
> >>>>> seguridad codifica el timestamp actual de un cliente en
> >> la direccion
> >>>>> de IPv6 o alguna otra cosa que a nadie se le ha ocurrido.
> >>>>>
> >>>>
> >>>> Serian direcciones temporales, de prefijos especiales, no
> >> de prefijos
> >>>> de produccion que son el 1/8 de las disponibles y es
> como se estan
> >>>> haciendo las cuentas ahora mismo.
> >>>>
> >>>> Piensa simplemente en la poblacion mundial y a cada uno le
> >> asignas un /48.
> >>>> Por mucho que queramos en la tierra la capacidad de
> >> crecimiento de la
> >>>> poblacion es limitada ... y que a cada uno de las posibles
> >>>> organizaciones (en el RRG creo que contaron 6 mil
> >> millones) asignas
> >>>> un /32. Creo que te da un orden de magnitud y aun sobra ...
> >>>>
> >>>> De todos modos, creo que no tiene sentido divagar, pues ambos
> >>>> podriamos buscar argumentos en todos los extremos.
> >>>
> >>> Exactamente, nadie puede ver el futuro. No es logico desperdiciar
> >>> recurso si no sabemos lo que puede venir en un futuro.
> >>>
> >>>>>
> >>>>>> sabemos que aplicaciones vienen en el futuro. Lo que si
> >> sabemos es
> >>>>>> que actualmente LACNIC recomienda a los operadores
> asignar a los
> >>>>>> ³end-site² un /48.
> >>>>>>
> >>>>>> [Jordi] Y ese es el cambio mas importante en mi
> >> propuesta, partir
> >>>>>> de /48, pero no ser restrictivos si se puede justificar
> >> otra cosa.
> >>>>>
> >>>>> [Gustavo] Si dejamos abierto a justificar, entonces para que
> >>>>> clasificamos entre LIRs, end sites, etc. Si no sirve la
> >>>>> clasificacion porque obtienes lo que justificas entonces
> >> mejor vamos
> >>>>> haciendo una politica que diga que se te da el espacio
> que puedas
> >>>>> justificar y eliminamos las otras politicas. Las
> >> politicas ambiguas
> >>>>> llevan a loop holes asi que tendrias que detallar todos
> >> los casos
> >>>>> para los cuales es justificante asignar un /32 en lugar
> >> de un /48 o
> >>>>> al menos dar hints.
> >>>>
> >>>> Mira lo que he comentado antes de la diferencia entre
> >> receptor de PI
> >>>> y PA (LIR). Por otro lado mi idea no es que se asignen todos los
> >>>> baremos intermedios posibles. Hoy seria un /48 o un /32.
> Mañana la
> >>>> politica de asignacion puede cambiar y definirse otros
> valores, y
> >>>> consecuentemente unos criterios para cada uno.
> >>>>
> >>>> Pensemos en que las politicas estan sujetas a cambio, y
> por tanto
> >>>> fijemonos en los valores usados hoy.
> >>>>
> >>>> Ya hay quien ha propuesto que se elimine el /32 y se
> >> asigne según lo
> >>>> que se justifique, quizas en un par de años se haga asi. No veo
> >>>> ningun problema (no digo si estoy a favor o en contra, o
> >> es bueno o
> >>>> es malo, porque seguro que tiene pros y contras, pero en
> >> este momento no me lo planteo).
> >>>>
> >>>>>
> >>>>>> * Respecto al argumento del filtrado, etc., NO es tarea
> >> de LACNIC
> >>>>>> ser el policía de la ruteabilidad en Internet.
> >>>>>>
> >>>>>> [Jordi] Correcto, pero es absurdo tener una politica sin
> >> aplicación
> >>>>>> practica. Hoy se ha demostrado aquie en el IETF, que
> de momento,
> >>>>>> las asignationes PI de ARIN estan siendo filtradas por
> >> el 63% de la
> >>>>>> red. Creo que es bastante significativo. Esto puede
> >>>> cambiar, pero hoy es una realidad
> >>>>>> y creo que es importante que quede
> >>>> constancia de ello. No afecta al texto de
> >>>>>> la politica si esta situacion de filtrado desaparece,
> >> luego no hace daño.
> >>>>>
> >>>>> [Gustavo] Entonces la red de IPv6 es tan pequeña y sin
> >> importancia
> >>>>> como para poder medir con exactitud como tu comentas TODOS los
> >>>>> puntos desde la red desde donde no se ve un anuncio.
> >> Volvemos a lo
> >>>>> mismo, LACNIC no es el policia de la ruteabilidad.
> >>>>
> >>>> Es mas grande de lo que parece, pero no viene al caso
> >> creo. Cada RIR
> >>>> suele tener sus propios route servers, posiblemente lo
> >> mejor para ser
> >>>> neutral seria medirlo en los demas. 4 puntos de medida me
> >> parecen suficientes.
> >>>>
> >>>> Olvidate de argumentarlo con el filtrado si eso te
> >> molesta, y si hace
> >>>> falta lo quito de la redaccion, pero admite que puede
> haber otras
> >>>> razones, como el ejemplo del banco, en que un /48 y un /44
> >> son pequeños. Porque limitarlo ?
> >>>
> >>> Un banco puede aplicar para ser LIR como puede aplicar una
> >> universidad.
> >>>
> >>>>>
> >>>>>> * En otras regiones (ARIN y APNIC) asignan un /48 y no tienen
> >>>>>> previsiones para un /32 por el desperdicio conlleva.
> >>>>>> http://www.arin.net/policy/proposals/2005_1.html y
> >>>>>> http://www.apnic.net/docs/policy/discussions/prop-035-v002.txt.
> >>>>>>
> >>>>>> [Jordi] Correcto, pero insisto en que si no
> >>>> se soluciona lo de los filtros,
> >>>>>> creo que esas politicas podrian terminar cambiando (toda
> >> politica
> >>>>>> esta sujeta a cambios).
> >>>>>
> >>>>> [Gustavo] Exacto Jordi, toda politica esta sujeta a cambios.
> >>>>> Entonces, si la tendencia en otras regiones con mayor
> >> penetracion de
> >>>>> IPv6 es un /48 y dejar reserva un /44 creo que podemos
> seguir el
> >>>>> mismo camino. OJO. Mi argumento del /48 va mas por el lado del
> >>>>> desperdicio. Uso el argumento de lo que han hecho otros
> RIRs para
> >>>>> apoyar mi argumento.
> >>>>
> >>>> Lo entiendo, tambien los otros RIRs usan /48 para
> infraestructuras
> >>>> criticas, y nosotros usamos /48 o menor (hasta /32). No
> >>>> necesariamente tenemos que seguir TODO lo que hacen los
> demas y al
> >>>> pie de la letra, sino hariamos todo como politicas globales, y
> >>>> ademas, nos ahorrariamos estos debates. La gente de cada
> >> region tiene
> >>>> que opinar (no solo 3 o 4 participantes, que es el caso
> >> ahora y ojala cambien !).
> >>>
> >>> Yo no estoy diciendo que tenemos que hacer lo que hacen los demas.
> >>> Creo que podemos nutrirnos de las discuciones y experencias
> >> de otras
> >>> regiones.
> >>> Te estoy dando los argumentos de porque pienso que el /32
> no es una
> >>> buena idea para END-SITES.
> >>> Tu has puesto como referencia lo discutido en AfriNIC, yo
> >> te pongo de
> >>> referencia lo que se ha discutido en otras regiones.
> >>>
> >>>>>
> >>>>>> * El sentimiento de la region ARIN y APNIC es asignar un /48 y
> >>>>>> dejar reservado un /44. En RIPE tu misma política esta
> >> en discusión
> >>>>>> y no esta aprobada así que no podemos saber el
> >> sentimiento de la comunidad europea.
> >>>>>>
> >>>>>> [Jordi] En RIPE NCC voy a enviar una nueva version en
> >> 3-4 semanas
> >>>>>> con el mismo sentido que el aquí presentado. De hecho,
> asi lo he
> >>>>>> hecho tambien en AfriNIC, y *parece* que se acepta esta
> >> opcion de
> >>>>>> un prefijo /48 como punto de partida, pero que crezca si
> >> es preciso.
> >>>>>
> >>>>> [Gustavo] En las regiones donde se ACEPTADO la politica sobre
> >>>>> multihoming en IPv6 es un /48 y reserva de /44, y son
> >> regiones con
> >>>>> una gran cantidad de usuarios de Internet. Y si hablamos
> >> de usuarios
> >>>>> en IPv6, APNIC debe tener varios usuarios usando IPv6.
> >>>>
> >>>> RIPE NCC es quien tiene mas usuarios y mis ultimas medidas
> >> de trafico
> >>>> me dicen que es donde hay mas trafico tambien, seguido de APNIC,
> >>>> ARIN, LACNIC y AfriNIC. Tambien hay que tener en cuenta
> >> que APNIC ha
> >>>> implementado esta politica ayer, asi que no es posible
> >> hacer ningun
> >>>> tipo de apreciacion practica.
> >>>>
> >>>> Sin embargo, si nos tenemos que comparar con alguien, creo
> >> que somos
> >>>> mas comparables a AfriNIC en muchos aspectos (refiriendonos a
> >>>> politicas). Creo que no me equivoco si digo que cuando
> lleguemos a
> >>>> nuestra reunion, AfriNIC tendre una politica de PI
> >> aceptada tal y como yo la estoy proponiendo aquí.
> >>>> Por eso digo que las comparativas no son totalmente
> validas cuando
> >>>> estan
> >>>> *cambiando* ahora.
> >>>
> >>> No es compararte en tamaño o no con AfriNIC o APNIC o
> ARIN. No creo
> >>> que valga la pena entrar en discusiones sobre que región es mas o
> >>> menos importante en el mundo de IPv6 o para el Internet, y
> >> si eso es
> >>> lo que quieres discutir porque la variable para fijar la
> >> importancia
> >>> de la region tiene que ser el trafico?. La variable puede ser
> >>> capacidad económica para comprar servicios de IPv6 o
> >> penetración per
> >>> capita de Internet o que se yo. Inclusive, la mayoría del
> >> expertise y
> >>> desarrollo de Internet se da en ARIN, APNIC y RIPE. Y si a
> >>> comparaciones vamos, que no creo que valen la pena, si en
> >> dos de las
> >>> tres regiones con mas desarrollo de Internet llegaron a la
> >> conclusiòn
> >>> del /44, algo debe de haber de logica al respecto, no crees?.
> >>>
> >>>>>
> >>>>>> * Creo que la palabra criterio es muy
> >>>> ambigua para una política, ¿Como puede
> >>>>>> LACNIC saber si realmente esta siendo
> >>>> filtrado el anuncio del /48 para negar
> >>>>>> o aceptar la asignacion del /32?. ¿Se va a meter a todos los
> >>>>>> ruteadores involucrados? Que le voy a recomendar a las
> >> personas que requieren un /48.
> >>>>>> Solicita un /48 y si alguien te esta
> >>>> filtrando entonces pides un /32 y haces
> >>>>>> RENUMERACION de tu red.
> >>>>>>
> >>>>>> [Jordi] Creo que hay que dar cierta
> >>>> flexibilidad a los hotsmasters. De hecho
> >>>>>> esta idea parte de las asignaciones para
> >>>> infraestructuras criticas. Se estan
> >>>>>> asignando a end-sites /32 a criterio de LACNIC, porque de otro
> >>>>>> modo, esas infrastructuras criticas no serian
> visibles. Para mi,
> >>>>>> quien necesita PI es tan critico como un TLD.
> >>>>>
> >>>>> [Gustavo] Yo no estoy hablando de quitar flexibilidad a los
> >>>>> hostmaster, pero TODO puede ser un "end-site". En cambio
> >> hay hints
> >>>>> de lo que es infraestructura critica para que los hostmaster se
> >>>>> puedan basar en lo mismo. La politica actual le da un
> >> hint a LACNIC
> >>>>> de que es infraestructura critica. "LACNIC podrá realizar
> >>>>> micro-asignaciones en casos de proyectos e
> >> infraestructuras de redes
> >>>>> claves o críticas para el funcionamiento, y desarrollo de
> >> IPv6 en la
> >>>>> región como son IXP (Internet Exchange Point), NAP
> >> (Network Access
> >>>>> Point), RIR, proveedores de DNS ccTLD, entre otros."
> >>>>
> >>>> Si, pero "entre otros" le da flexibilidad.
> >>>>
> >>>> Fijate tambien que yo NO hablo de end-site sino
> >>>> end-user-organization. Es decir, estoy limitando que
> >> acceda a PI un
> >>>> usuario residencial. Vuelvo al ejemplo del banco. Te
> >> pareceria logico
> >>>> limitar a esa entidad una realidad manifiesta ? Crees que los
> >>>> hostmasters tienen el criterio para tomar esa decision si
> >> es el caso ?
> >>>
> >>> En ningun lado de la politica actual de IPv6 se menciona
> la palabra
> >>> end-user-organization.
> >>> Podrias decir un documento (politica de LACNIC) donde se
> >> defina lo que
> >>> es un end-user-organization por favor.
> >>>
> >>> Los hostmasters siguen las guias fijadas en las politicas.
> >> Como lo he
> >>> comentado anteriormente porque no le dejamos entonces todo
> >> al criterio
> >>> de los hostmasters y elminamos las politicas actuales.
> >>>
> >>>>>
> >>>>>> Con que LACNIC acceda a cualquier de los looking glass
> >> disponibles,
> >>>>>> puede tener una vision que le permita comprobar si es
> >> cierto que se
> >>>>>> produce un filtrado o no, y decidir en consecuencia.
> >>>>>
> >>>>> [Gustavo] Hay "n" cantidad de operadores que pueden tener o no
> >>>>> filtros. Lo que dice la politica es tan ambiguo que si hago un
> >>>>> peering privado con alguien mas y le digo que filtre mi prefijo
> >>>>> porque es un /48 entonces obtengo por consiguiente un
> /32. Si nos
> >>>>> vamos a meter a definir una politica sobre filtrado hay
> >> que definir
> >>>>> cuando se considera filtrado: Solo es filtrado si me lo
> filtra un
> >>>>> Tier 1 (que primero habria que definir que es un Tier 1),
> >> o solo es
> >>>>> filtrado si es mi upstream provider, o si es un peering
> >> privado o si
> >>>>> es un peering a un IX, etc.
> >>>>
> >>>> No digo que el texto no sea el mejor. Quizas contemplando
> >> todo lo que
> >>>> he comentado se te ocurre una redaccion mas sencilla,
> que como te
> >>>> decia antes, no hable de filtros, sino simplemente de que
> >> el punto de
> >>>> partida es un /48 y los hostmasters pueden optar hasta un
> >> /32 o lo que sea, si esta justificado.
> >>>
> >>> Si la entidad cree que requerira arriba de un /44 que
> >> aplique para ser
> >>> un LIR. Los END-SITES que requieren multihoming solicitan
> el /48 y
> >>> pueden crecer hasta el /44. La misma política actual de
> >>> IPv6 de LACNIC sugiere que un LIR asigne un /48 a un end-site.
> >>>
> >>>
> >>>>>
> >>>>>> De otro
> >>>>>> modo, tambien tendriamos que cambiar para
> >>>> tener coherencia, la redaccion de
> >>>>>> la politica que permite a LACNIC tomar la decision del
> tamaño de
> >>>>>> las asginaciones de infraestructuras criticas, no te parece ?
> >>>>>
> >>>>> [Gustavo] No porque estas clasificando en
> >> infraestructuras criticas,
> >>>>> pero sin embargo, TODO puede ser un "end-site".
> >>>>
> >>>> La definicion de infraestructura critica es totalmente subjetiva.
> >>>> Podriamos hablar de que es mas critico un banco o un
> sitio web de
> >>>> voto por correo electronico que un TLD, porque en este
> ultimo hay
> >>>> redundancia por otros medios, mirrors, etc.
> >>>>
> >>>>>
> >>>>>
> >>>>>> [Jordi] No se trata de hacer una renumeracion. Se puede
> >> establecer
> >>>>>> un superbloque que asigne /48, reservando hasta el /32.
> >> El filtrado
> >>>>>> es algo rapido, y si no se produce, rapidaente se puede
> >> utilizar el
> >>>>>> resto del /32 (quizas reservando un /44) para otras peticiones.
> >>>>>
> >>>>> [Gustavo] Volvemos a lo mismo del desperdicio.
> >>>>> Entonces si me das un /32 reservame un /12 no sabes hasta donde
> >>>>> puedo crecer. El /44 no es algo que se haya inventado de
> >> la nada, se
> >>>>> llego a este valor en otras regiones tras largas
> >> discuciones y las
> >>>>> comunidades de ARIN y APNIC llegaron la conclusion que un
> >> /44 es lo
> >>>>> acertado para reservar.
> >>>>
> >>>> Bueno no exageremos !
> >>>>
> >>>> El /44 fue una decision de ARIN solo. APNIC lo "tomo"
> tal cual sin
> >>>> mas discusion, asi fue como se presento la propuesta en
> la reunion
> >>>> (yo estaba alli, y esta en video).
> >>>
> >>> No entiendo a que viene este punto, estas afirmando que
> NADIE en la
> >>> region APNIC se tomo la tarea de leer la politica o que
> >> nadie en APNIC
> >>> tiene la capacidad para decidir si el /44 era lo
> correcto?. No creo
> >>> que venga al caso discutir este punto.
> >>>
> >>>>>
> >>>>>> Creo que de nuevo LACNIC
> >>>>>> debe de gestionar esto como mejor le parezca.
> >>>>>> Hubo un comentario parecido
> >>>>>> acerca de esto y la "sparse-allocation" y
> >>>> Ricardo comento que efectivamente
> >>>>>> era parte de su operativa y preferian que la politica no
> >> defina con
> >>>>>> exactitud el procedimiento para permitirles optimizarlo.
> >>>>>>
> >>>>>
> >>>>> [Gustavo] Esta parte que comentas es diferente a lo que estamos
> >>>>> discutiendo. El caso del /48 y la reserva del /44 es muy
> >> especifico
> >>>>> al problema
> >>>> de multihoming de "end-sites".
> >>>>>
> >>>>>>
> >>>>>> Mi propuesta es que la asignación sea un /48 y se
> reserve un /44
> >>>>>> para futuras asignaciones. Eliminar el texto del /32 y
> >> los filtros,
> >>>>>> etc. LACNIC como otros RIR anunciará en las listas de
> >>>> operadores que empezará a realizar
> >>>>>> asignaciones de /48s de un /32 o lo que se defina.
> >>>>>>
> >>>>>> [Jordi] Como decia antes, si queremos seguir
> >>>> este camino, no tengo problema
> >>>>>> (lo que decida la comunidad), pero entonces
> >>>> hay que ser coherentes y cambiar
> >>>>>> la asignacion a infraestructuras criticas, y reclamar
> >> los bloques
> >>>>>> redundantes. Advierto que no es nada bueno, hay muchos TLDs en
> >>>>>> otras regiones con /48 que NO son alcanzables, pero me
> >> atendre al
> >>>>>> consenso, logicamente.
> >>>>>
> >>>>> [Gustavo] Entonces los puntos de donde NO son alcanzables son
> >>>>> irrelevantes. Un ISP no se puede dar el lujo de
> bloquear TLDs. Si
> >>>>> los ISPs grandes bloquean a un /32 y hay TLDs que no se
> >> pueden ver,
> >>>>> entonces IPv6 esta destinado al fracaso o es irrelevante en la
> >>>>> actualidad.
> >>>>
> >>>> Creo que no me he explicado. Hay infraestructuras criticas
> >> en otras
> >>>> regiones, que reciben /48 en lugar de /32 y no son
> alcanzables por
> >>>> ciertos paths. Como te decia antes, no pasa nada, se produce un
> >>>> retardo adicional, timeout y se va al mirror o se ve por
> >> IPv4. Ello
> >>>> demuestra que son incluso "menos criticas" que un banco
> o una web
> >>>> electoral :-(
> >>>
> >>> Cuales son esos ciertos paths?. Cuantos usuarios se ven
> >> afectados por
> >>> esos filtros? Donde esta la metodologia de medicion y las
> variables
> >>> que hay que considerar, etc. Te pregunto que le impide
> >> actualmente a
> >>> un ISP u operador de un ruteador bloquear hasta un /20 en
> IPv4 por
> >>> ejemplo, nada.
> >>> El Internet es un acuerdo entre muchos operadores, y cada
> >> operador es
> >>> libre de hacer lo que quiera. Algo te puedo decir, cuando
> >> los clientes
> >>> del operador se quejen de que no pueden alcanzar ciertos
> >> puntos se van
> >>> a quitar los famosos filtros y se acabo el problema.
> >>>
> >>>>>
> >>>>>>
> >>>>>>> Asignaciones subsecuentes:
> >>>>>>> Siempre que sea posible, sucesivas
> >>>> asignaciones se realizarian de un bloque
> >>>>>>> de direcciones adyacente, pero solo si se documenta y
> justifica
> >>>>>>> convenientemente.
> >>>>>>>
> >>>>>>
> >>>>>> El texto de la politica debe decir que se dejara
> >> reservado un /44
> >>>>>> para subsecuentes asignaciones.
> >>>>>>
> >>>>>>> "Super-Bloque" de asignacion:
> >>>>>>> Las asignaciones seran asignadas desde un
> >> "super-bloque" separado,
> >>>>>>> para facilitar a los RIR el filtrado de las mismas, si
> >> fuera requerido.
> >>>>>>>
> >>>>>>> 11. Justificacion:
> >>>>>>>
> >>>>>>> En IPv4, hay organizaciones que cualifican para una
> >> asignacion PI,
> >>>>>>> o que podrian optar a ser un LIR. Esto podria ser bien porque
> >>>>>>> necesiten multihoming, o tengan otras razones
> administrativas o
> >>>>>>> tecnicas para un bloque de direccionamiento portable.
> >>>>>>>
> >>>>>>> Este no es el caso, en la actualidad, para
> >>>>>> IPv6, y se percibe como una clara
> >>>>>>> barrera para su despligue por parte de
> >>>>>> algunas organizaciones. Esta propuesa
> >>>>>>> de politica pretende evitar dicha barrera por
> >>>>>> medio de la asignacion directa
> >>>>>>> desde LACNIC.
> >>>>>>>
> >>>>>>> Cualquier organización recibiendo dicha asignacion, no podria
> >>>>>>> realizar sucesivas asignaciones a otras organizaciones
> >> externas, y
> >>>>>>> por tanto solo podria asignar subredes internamente
> >> dentro de sus propias entidades.
> >>>>>>>
> >>>>>>> Asignar un /32 permite a estos bloques comportarse como
> >> cualquier
> >>>>>>> otra asignacion adjudicada a un LIR, y por tanto
> >>>> seguir las practicas habituales
> >>>>>>> de filtrado de rutas, pero podria ocurrir que un /48,
> que es un
> >>>>>>> espacio suficiente para muchos casos, dejara de ser
> >>>>>> filtrado y pudiera ser por tanto
> >>>>>>> adecuado para cumplir con el objetivo de la
> >>>> politica. Al mismo tiempo, los
> >>>>>>> bloques podrian ser facilmente identificables como
> >> pertenecientes
> >>>>>>> a un "super-bloque" especial.
> >>>>>>>
> >>>>>>> Por medio de esta politica, evitamos la creacion de una
> >> situacion
> >>>>>>> injusta entre diferentes regiones, y satisfacemos los
> >> requisitos
> >>>>>>> de cualquier organización que requiera espacio PI.
> >>>>>>>
> >>>>>>>
> >>>>>>> Saludos,
> >>>>>>> Jordi
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> **********************************************
> >>>>>>> The IPv6 Portal: http://www.ipv6tf.org
> >>>>>> <http://www.ipv6tf.org/> >
> >>>>>>> Bye 6Bone. Hi, IPv6 !
> >>>>>>> http://www.ipv6day.org
> >>>>>> <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
> >>>>>> <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
> >>>>>
> >>>>> Gustavo Lozano
> >>>>> NIC Mexico
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> **********************************************
> >>>> 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
> >>>
> >>> Gustavo Lozano
> >>> NIC Mexico
> >>>
> >>>
> >>
> >>
> >>
> >>
> >> **********************************************
> >> 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
> >>
>
>
>
>
> **********************************************
> 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
>
More information about the Politicas
mailing list