[LACNIC/Politicas] Revision de politica - Asignaciones IPv6 Independientes del Proveedor (PI) para organizaciones-usuario-final
JORDI PALET MARTINEZ
jordi.palet at consulintel.es
Tue Mar 20 20:05:50 BRT 2007
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.
More information about the Politicas
mailing list