[LACNIC/Politicas] Asignacion PI

Sat May 20 16:23:02 BRT 2006

Debajo.

Saludos,
Jordi

> De: marcelo bagnulo braun <marcelo at it.uc3m.es>
> Responder a: <politicas-bounces at lacnic.net>
> Fecha: Fri, 12 May 2006 09:19:21 +0300
> Para: Nicolás Ruiz <nicolas at ula.ve>
> CC: <politicas at lacnic.net>
> Asunto: Re: [LACNIC/Politicas] Asignacion PI
> 
> 
>> Estrictamente hablando, es cierto que no se pueden reclamar las
>> direcciones a las instituciones que las obtienen. Pero en el pasado se
>> han establecido (y publicado) medidas que tienen el mismo efecto, como
>> es el caso de 6bone phaseout (RFC3701). El resultado del 3701 es que
>> quienes utilizan direcciones 6bone lo abandonan y han de utilizar otras
>> alternativas.
>> 
> 
> claro pero en el caso del 6bone, la obtencion de direcciones nuevas
> producia beneficios, en el sentido que el 6bone era una eestrucutra de
> exprimentacion y las direcciones nuevas eran de produccion... digo creo
> que las institiciones en el 6bone no utilizaban esta red como
> produccion sino para hacer prubas...

Como tu mismo comentaste, no deberia de hacer falta la reclamacion. Si
tenemos una tecnica mejor, lo natural es que la mayoria prefieran ese
camino.

Si no logramos esta tecnica, entonces los que necesitan PI tienen derecho a
ello. La propuesta busca ese punto intermedio de forma que no nos quedamos
atrapados ni en un caso ni en el otro.

> 
> esto es un caso completamente diferente, ya que estas asignaciones PI
> son exactamente para poner en produccion sitios grandes que ya son
> multihomed en v4 y que quieren poner en produccion sus servicions en
> v6. las implicaciones de un evento de renumeracion en ambos casos son
> muy diferentes...

No estoy de acuerdo. Hay grandes redes que estan usando 6Bone como
produccion, en contra de para lo que fue establecido, y aun no han
renumerado a produccion a pesar de tener el prefijo. Por tanto, de hecho,
creo que no hay tanta diferencia como parece ...

> 
>>>> 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.
>>>> 
>>> esto me parece incorrecto.
>>> 
>>> una institucion es un lir o no lo es porque ofrece transito a sus
>>> clientes. No creo que sea una buen idea desvirtuar el concepto de lir
>>> creando una politica que sugiera que una organizacion que claramente
>>> es
>>> un sitio final y no vende transito, deba hacerse lir para obtener un
>>> bloque propio
>> 
>> Estoy totalmente de acuerdo en no desvirtuar el concepto del LIR. Pero
>> yo tendria cuidado al indicar que un LIR ha de *vender* tránsito. Esa
>> es
>> una restricción innecesaria.
>> 
> 
> bueno, debe proveer transito a otras insituciones, y en general hay
> algun tipo de venta de transito (solo que los modelos de pago pueden
> diferir, com por ejemplo las redes academicas, donde el pago es mucho
> mas indirecto)

Una Universidad tiene campus, facultades, etc., pueden ser la misma entidad
legal y la red de la universidad, esta proporcionando transito. Se trata de
un pequeño matiz que con la politica actual se esta flexibilizando, y creo
que es lo correcto.

Por tanto, la alternativa a mi propuesta es que no sea una flexibilizacion,
sujeta a interpretacion, sino un hecho no discutible. Precisamente la
proxima semana vera la luz mi propuesta para RIPE para modificar la politica
actual de IPv6 de forma que permita a entidades que no porporcionan transito
a otras, sino a otros departamentos, recibir su prefijo, por defecto el /32
como todos.

Si creeis que la propuesta de PI no es correcta, quizas tengo que preparar
una version de la de RIPE tambien en esta region.

> 
>>>> 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 /32, aunque un bloque mayor
>>>> podria ser asignado si se documenta y justifica convenientemente.
>>>> 
>>> 
>>> esto me parece una mala idea.
>>> un sitio final no necesita un /32
>>> creo que hay acuerdo en la comunidad que un /48 es en general
>>> suficiente para un sitio final
>>> 
>>> /48 debe ser el tamaño de asignacion PI
>>> 
>>> La unica razon por la que se desearia asignar un /32 es por los
>>> filtros
>>> creo que esta no es razon suficiente para desperdiciar esa cantidad de
>>> espacio
>> 
>> La existencia de los filtros es precisamente la razón que fuerzan a que
>> se asigne un /32. Si se otorga un /48 y el prefijo no se propaga en las
>> tablas de enrutamiento, la asignación no es PI.
> 
> creo que no tenemos las misma definicion de PI....
> La asignacion es PI porque no proviene del bloque asignado a uno de los
> proveedores del sitio y proviene directamente del RIR
> 
> Ser o no ser PI no tiene absolutamente nada que ver con el hecho de que
> sea routeable o no
> 
> en mas, los RIRs no tienen ninguna influencia sobre si los prefijos son
> routeables en internet o no. Lor rirs, nos hacen ningun tipo de
> declaracion sobre la potencial routeabilidad de los prefijos

Correcto, pero la politica dice que se busca incrementar esa routeabilidad,
y una forma de lograrlo es que sea /32.

> 
>> 
>> La asignación es básicamente "el prefijo mínimo necesario para que sea
>> propagado con éxito en las tablas de enrutamiento global".
> 
> no
> el RIR no toma posicion sobre el potencial routeabilidad del prefijo
> asignado
> 
>>  Si los ISP se
>> niegan a aceptar prefijos menores a un /32 para evitar una explosión de
>> las tablas de enrutamiento, todas aquellas organizaciones/instituciones
>> que necesiten PI necesitan un /32.
>> 
> pero esto no tiene nada que ver con que la asignacion sea un /32 o un
> /48, sino con el numero potencial de sitios multihomed....
> 
>>  Si asumimos que el número de
>> instituciones que requieren direcciones PI es acotado, las entradas en
>> las tabla de enrutamiento asociadas a estas instituciones son acotadas
>> tambien.
> 
> si, independientemete que se les asigne un /32 o /48
> 
>> La otra alternativa es simplemente que estas instituciones no
>> adopten IPv6, que todos estamos de acuerdo no es deseable.
>> 
> 
> y la otra alternativa, es que los ISPs propaguen y acepten estos /48
> que provienen de un prefijo conocido para asignaciones PI
> 
> porque? porque los sitios multihomed con PI estan dispuestos a pagar
> por este servicio

Si, pero el cliente que necesita PI puede pagar a su upstream, pero no a
todos los del mundo. Es decir, su upstream no le garantiza, aunque pague,
esa ruteabilidad. Luego no sirve este camino del pago para aue me anuncies
...

> 
>> Como digo al principio (y como dije hace varios mes
>> es), yo prefiero que
>> la asignación sea un /48, siempre y cuando el prefijo se propague en
>> las
>> tablas de enrutamiento globales.
>> 
> 
> pregunta: crees que los /48 PI asignados por ARIN no van a ser
> encaminados?

Ellos mismos tienen sus dudas !

> 
> 
> 
> 
>>>> Asignaciones subsecuentes:
>>>> Siempre que sea posible, sucesivas asignaciones se realizarian de un
>>>> bloque de direcciones adyacente, pero solo si se documenta y
>>>> justifica
>>>> convenientemente.
>>>> 
>>>> "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.
>>>> 
>>> 
>>> esto deberia ser suficiente para solucionar de forma simple el tema
>>> del
>>> filtrado... los bloques de este super bloque seran anunciados con
>>> prefijos mas largos
>> 
>> por quien? Como logras PI? Si yo tengo 3 proveedores y solo uno de los
>> tres propaga mis rutas, no tengo PI.
> 
> ver mas arriba... ser o no ser PI no tiene absolutamente nada que ver
> con si el bloque es encaminable o no
> 
> 
> saludos, marcelo
> 
> 
>> 
>>> 
>>>> Expiracion de las asignaciones:
>>>> Los bloques asignados mediante esta propuesta como solucion para
>>>> multihoming, deben ser devueltos a LACNIC en un plazo maximo de tres
>>>> años.
>>>> El periodo de tres años comienza una vez que haya una solucion
>>>> tecnicamente valida y desplegable que sea aceptada por la comunidad
>>>> Internet. Cualquier organización que desee evitar renumerar podria
>>>> optar a convertirse en LIR, si cualifica para ello, y le seria
>>>> adjudicado el mismo prefijo.
>>>> 
>>> 
>>> como he dicho, esto me parece irreal y creo que no debemos desvirtuar
>>> el concepto de lir
>>> 
>>> 
>>> mi propuesta es realizar las siguientes modificaciones:
>>> - asignacion /48
>>> - politica de caracter permanente y sacar el tema de cconvertirse en
>>> lirs
>>> 
>>> saludos, marcelo
>>> _______________________________________________
>>> Politicas mailing list
>>> Politicas at lacnic.net
>>> http://www.lacnic.net/mailman/listinfo/politicas
>>> 
>>> 
>> 
>> - --
>> Juan Nicolás Ruiz        | Corporación Parque Tecnológico de Mérida
>> Investigación/Desarrollo | Centro de Tecnologias de Información
>> nicolas at ula.ve           | Edif B (Fac. Ingeniería) Nivel Plaza, Ala
>> Sur
>> +58-(0)274-240-3889      | La Hechicera, Mérida - Edo. Mérida.
>> Venezuela
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v1.4.3 (GNU/Linux)
>> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>> 
>> iD8DBQFEY6nfmjsZS9ZBxv8RAju5AJ9DB9VzlVz92B9rPu6D7c3hbH7oWQCeNK/4
>> Z8/IGopfE6ssRq5vFHqeP1k=
>> =wI0X
>> -----END PGP SIGNATURE-----
>> 
> 
> _______________________________________________
> Politicas mailing list
> Politicas at lacnic.net
> http://www.lacnic.net/mailman/listinfo/politicas

**********************************************
The IPv6 Portal: http://www.ipv6tf.org

Barcelona 2005 Global IPv6 Summit
Slides available at:
http://www.ipv6-es.com

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.