[LACNIC/Politicas] Revision de politica - Asignaciones IPv6 Independientes del Proveedor (PI) para organizaciones-usuario-final

[Gustavo Lozano]

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.

>
> > 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.


>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.

>* 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.

>* 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.

>* 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.

>* 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."

>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.

>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".


>[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.

>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.

>
> > 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