[LACNIC/Politicas] Asignacion PI (era Re: Politicas para el foro publico

marcelo bagnulo braun marcelo at it.uc3m.es
Mon May 22 04:12:52 BRT 2006


Hola Jordi,

El 20/05/2006, a las 22:08, JORDI PALET MARTINEZ escribió:
>> Debo decir que estoy de acuerdo con el espiritu de la propuesta, pero
>> lamentablemente, creo que esto es completamente irreal
>>
>> Digo me parece poco realista pensar podremos reclamar las direcciones 
>> a
>> las instituciones que los obtienen. Es mas creo que no sera posible
>
> Pero esto no es un problema de esta propuesta. Es un problema generico 
> de
> reclamacion de recursos que hay que resolverlo y no solo para esta
> propuesta.
>
> Yo he estado hablando en las ultimas semanas al respecto de este tema 
> con
> los diferentes RIRs y todos me confirman que tienen politicas de 
> reclamacion
> de recursos y que funcionan. Asi que no es irreal en absoluto.
>
> El problema se produce con los recursos pre-RIR, pero no es el caso de 
> esta
> politica.
>
>> lograr acuerdo en la comunidad para lograr esto, mucho menos lograr
>> acuerdo que la nueva solucion que aprezca en un futuro provee un
>> alternativa aceptable (no importa cual sea). Es mas, si la solucion
>
> Si creemos en el consenso para todo, tambien hay que creer en el 
> consenso
> para decidir en la comunidad si la solucion A, la B, o ambas, son 
> validas.
>
> Lo siento, pero si no es el caso, mejor nos dejamos de consenso y 
> "cerramos
> el kiosko". Eso si que es ser realista :-)
>

el problema que yo veo aquie es el siguiente:

esta propuesta parece que no es tan "mala" (en el sentido de su impacto 
en la escalabilidad del sistema de rutas) porque es transitoria. Es 
decir, que uno de los argumentos para aceptarla es "no hay problema 
porque es transitoria y ya expirara"

el tema es que yo no creo que esto vaya a ser posible, sobre todo 
porque no creo que sea posible, en un ocrto plazo encontrar una 
solucion alternativa sobre la cual haya consenso (digo la solucion 
propuesta por el ietf, que llevo mas de 6 años en llegar a concenso 
dentro del ietf, es exactamente uno de los agrumentos usados para crear 
esta politica... que la solution propuesta no satisface los 
requirimientos...)

El tema de fondo, es lo que menciono Nicolas y es que los sitios 
quieren tener direcciones PI... es decir no es que quieren tener una 
solucion para multihoming, lo que quieren es tener su bloque propio. No 
hay solucion alternativa porque el propio requerimiento es el bloque PI 
propio...

Por eso, creo que el argumento de aceptamos esto por ahora porque solo 
es transitorio es falaz porque no veo en el horizonte cercano una 
solucion alternativa viable, por eso me gustari que eso no este en la 
politica y la comunidad pueda considera esto como lo que realmente es: 
darle espacio PI a los sitios grandes


por eso  creo que seria mucho mas realista decir directamente que esta 
es la solucion, que es definitiva (por supuesto, si encotnramos una 
solucion alternativa, no sera necesario reclamar los recursos, ya que 
la solucion alternativa sera mucho mejor por lo que naturalmente los 
usuarios se pasaran a ella...)

Ademas, tampoco creo en las politicas de recuperacion de recursos, creo 
que son dificiles de implementar, creo que el poder que tiene la 
comunidad para imponer esas politicas es muy limitado y no creo que sea 
una buena idea lanzar un ordago para que devuelvan los recusrsos, si no 
lo podemos hacer cumplir, ya que diezma la credibilidad del sistema



>>
>>> 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
>
> Quizas no estas entendiendo la idea o yo no me he explicado bien. En 
> 6-7
> años, que es el plazo minimo en el que estoy pensando (intentando ser
> realista), una entidad *puede* haber cambiado y estar proporcionando
> transito a terceros. Tambien puede haber cambiado la calificacion de 
> quien
> puede ser o no LIR, etc. Yo no estoy intentando sugerir que 
> desvirtuemos el
> concepto de LIR sino que si se da el caso, pueda acogerse a ese mismo
> prefijo.
>

seguro pero eso se aplica a cualquier institucion... digo cualqueir 
institucion a lo largo de 6 años puede convertirse en un LIR y no por 
eso tenemos una politica general que diga que si una institucion se 
convierte en un LIR puede tener los derechos de un LIR.... esto es 
sabido y no hay ninguna necesidad de expresarlo en la politica

>>
>>> 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
>
> Sabemos bien que un /32 en general no es filtrado. Yo he visto casos 
> en que
> incluso el /33 se filtra. Ejemplo el propio prefijo de la 
> infraestructura de
> APNIC, lo anuncian como 2x/33 porque tienen la infraestructura en dos
> sitios, y de vez en cuando no son alcanzables.
>

_hoy_ se filtran porque no hay un politica para asignar /48, pero en 
cuanto haya un politica que los asigna, los /48 se aceptaran...

digo, el hecho de que hoy se filtern los /32 es perfectamente coherente 
con que la asignacion hoy es /32

si empiezan a hacerse asignaciones de /48 se empezaran a aceptar

> Asi que si queremos ser realistas, debe de ser un /32.
>

no

> Es mas, las asignaciones de /48 para infraestructuras criticas que 
> utilizan
> en alguna region (en otras precisamente por esto decidieron usar /32), 
> son
> ridiculos, porque es contradictorio. Eres una infraestructura critica 
> como
> un TLD, se te asigna un /48, y no eres alcanzable desde todos los 
> sitios.
> Que te parece ?
>


que si alguien filtra un TLD tiene un error conceptual muy grave y no 
creo que le queden muchos clientes....

> No es cuestion de lo que se necesite, sino de facilitar al maximo la
> enrutabilidad del prefijo. Esto se dice en las politicas actuales y si 
> no lo
> seguismos, nos contradecimos !

los principios de las politicas son muchos, entre ellos uno de los mas 
importantes es el conservacion del espacio (ya hablaremos mas abajo de 
esto)

el hecho de asignar un /48 implicara que durante un periodo de 
transicion no se acpetaran los /48 pero pasado un tiempo, no habra 
problemas con esto...

>
>>
>> /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
>
> No es un desperdicio, precisamente porque 1) es temporal,


NO es temporal....


esto es exactamente lo que me molesta del concepto de temporal.... que 
es un artilugio para que la politica sea aceptada mas facilmente....

no es temproal porque no hay ninguna solucion alternativa que tenga 
algun tipo de posibilidad en el corto o medioan plazo... ni siquiera a 
nivel de investiagacion hay propuestas fuertes para una solucion 
alternativa al sistema de rutas... como podemos decir que esto es 
temporal si no  existen siquiera propuestas para soluciones 
alternativas...? digo es tan temporal como IP... cuando encontremos 
algo mejor dejaremos de usar IP...

>  2) si la entidad
> se acoge a la politica actual obtiene un /32 aunque tampoco lo utilice
> (ejemplos de muchas universidades en LAC en esta situacion),

las universaidad¡es no obtienen asignaciones directas son las redes 
academicas las cuales tienen muchos clientes... en algunos casos (como 
rediris) tienen mas de doscientos que era el numero pedido 
anteriormente... asi que no veo ningun problema con esto...

>  3) el espacio
> de direcciones de IPv6 se ha previsto que dure unos 480 años (creo que 
> es
> ridiculo pensar que dentro de 150 sigamos usando IP, aunque sigamos
> llamandolo IP !).
>

segun las predicciones de quien? desde cuando es posible hacer 
predicciones sobre el futuro de internet? (digo previsiones se pueden 
hacer pero cuado han sido acertadas?)

considera el caso de v4 cuando asignaban calses A a sitios finales.... 
en ese momento las P2redicciones" decian que no hay problema...

el tema es que el futuro es incierto y que exsiten muchos elementos que 
pueden cambiar radicalmentela necesidad de direcciones...

ejemplos:
- una posibilidad (que ya estamos usando) es almacenar informacion 
criptografica en las direcciones por temas de seguridad... esto es muy 
util porque es una herramienta de seguridad autocontenida que no 
require una infraestructura de clave publica para solucionar muchos 
problemas... el tema por supuesto es que necesita bitts... mcuhos bits 
en las direcciones... ademas con lo ataques recientes a las fucniones 
de hash, es posible que necesitemos mas bits para eso...
- otro factor que puede tener un efecto muy importante es exactamente 
una solucion alternativa de routing.... ciertas soluciones alternativas 
que prometen tener mejores caracteristicas de escalabilidad, requieren 
codificar mucha informacion en la propia direccion (el balance es entre 
codificar inforamcionen el sistema de rutas o en las propias 
direcciones) para esto puede ser que necesitemos muchos bits


como te digo, el futuro es incierto y no sabemos (no podemos saber) 
cuales son las necesidades futuras...


lo unico que nos queda para hacer lo correcto es ser conservadores y 
aceptar nuestras limitaciones como adivinos...
no desperdiciemos el espacio de direcciones.... no sabemos si va a 
durar 480 años o hasta la proxima generacion de sistema de rutas...

> Por otro lado, el coste de recursos humanos de configurar los prefijos 
> cada
> vez que se asigne un PI es mucho mas alto que ese "mal entendido"
> desperdicio de espacio. Hay que tener un balance entre ambos.
>

es interesante... como cuantificas el coste de desperdiciar direcciones 
IP?


esto no es un tema de comparaciones ya que no es posible comparar... es 
un tema de apreciacion y de valoracion...

perosnalmente creo que es mas inportante conservar el espacio para el 
futuro... el coste de configurar los filtros es cuantificable... el de 
desperdiciar direcciones, no lo es

> Entenderia esa "extra-conservacion" si realmente hablaramos de que 
> ello nos
> supone que IPv6 solo dure 50 años, pero hablamos de 480 años 
> (aceptando el
> cambio del HD). Seamos realistas !
>

de vuelta... no creo es estas predicciones (ni en ninguna otra, 640 k 
de memoria RAM deberia ser suficiente para todos...) pero mucho menos 
no creo en predicciones que se extienden a 480 años... en serio Jordi, 
es serio crees en un predccion de aqui a 480 años en el campo de la 
tecnologia????? no te parece un poco exagerado al menos?


>>
>>> 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
>
> No, hay quien no quiere configurar un unico filtro, porque ello implica
> permitir, por ejemplo, a un spammer, usar un /48 que no este asignado. 
> Mi
> idea del superbloque era mas bien para permitir a quien lo desee un 
> filtrado
> "deny", pues quien desee no aceptar el coste de las entradas PI en sus
> routers, tiene derecho a hacerlo.

pero ese razonamiento no se sostiene...

digo esto es exatamente el mismo caso si es un /32 o un /48... digo, si 
un spammer quiere robar, robara entonces un /32 del espacio no asignado 
y estamos en las mismas...
para evitar esto lo que hay que hacer es configurar filtros por cada 
asignacion, independientemente que sea /32 o /48, por lo que este 
razaonmiento es invalido como argumento para preferir un /32

saludos, marcelo




More information about the Politicas mailing list