[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 13:22:51 BRT 2007
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
>
More information about the Politicas
mailing list