[lacnog] Policty Proposal 125 de ARIN o Como determinar si una organizacion usa IPv6

[Nicolás Ruiz]

Hola,

Yo también entiendo perfectamente la posición de Joao. Y al igual que
Alejandro, no comparto su punto de vista. Si bien la red es de Joao, y
Joao la administra de acuerdo a sus necesidades y capacidades, esta es
una política de asignación de direcciones. El correo origina dice que
la propuesta es "si quieres direcciones IPv4, debes instalar dual
stack".

Me parece razonable que las entidades que asignan direcciones quieran
favorecer aquellas organizaciones que se estan preparando para IPv6.
Es obvio que hay preocupación por la falta de preparación a IPv6. El
único momento cuando ARIN et.al. tienen un "bargaining chip" es
durante el proceso de solicitud de direcciones.

Ahora, como determinar que una organización está realmente utilizando
IPv6 es un problema interesante. El único caso que veo fácil de
determinar son los ISP comerciales, porque obviamente deberían ofrecer
direcciones duales a sus usuarios/clientes. Otros casos no los veo tan
claro.

nicolás

2011/1/19  <alejandro.acosta en bt.com>:
> Estimado Joao,
>  Mis comentarios entre líneas:
>
>> -----Mensaje original-----
>> De: lacnog-bounces en lacnic.net
>> [mailto:lacnog-bounces en lacnic.net] En nombre de Joao Damas
>> Enviado el: Miércoles, 19 de Enero de 2011 05:01 p.m.
>> Para: carlos en lacnic.net; Latin America and Caribbean Region
>> Network Operators Group
>> Asunto: Re: [lacnog] Policty Proposal 125 de ARIN o Como
>> determinar si una organizacion usa IPv6
>>
>>
>>
>>
>> On 7 Jan 2011, at 14:07, Carlos Martinez-Cagnazzo wrote:
>>
>> > Hola a todos, ¡espero que hayan tenido un excelente comienzo de año!
>> >
>> > Desde hace algunos días vengo siguiendo una discusión
>> interesante en
>> > la lista de Políticas de ARIN, en la cual hay un grupo de personas
>> > tratando de introducir una policy proposal que (resumiendo
>> bastante)
>> > propone modificar la politica de asignación de direcciones
>> IPv4 para
>> > requerir que la organización que recibe los recursos deba
>> también usar
>> > dual-stack con los mismos.
>> >
>> > Dicho de otra manera: "Si queres IPv4, vas a tener que poner dual
>> > stack con IPv6 tambien".
>>
>> esto parece como las propuestas que circularon en su día que
>> proponían un impuesto para el que no pusiera IPv6. Si yo soy
>> un ISP, *YO* gestiono mi red, con todas las consecuencias.
>> Nada más que decir sobre la política en si.
>
>  Muy buen punto el de Joao y en lo personal lo entiendo 100%, IMHO no comparto su posición. Yo si estoy de acuerdo con la política de ARIN y seguí toda su discusión en las listas.
>  La gestión de la red seguirá siendo como el/los administradores decidan.
>
>>
>> Por lo demás, se puede comprobar si una red tiene servicios
>> IPv4 e IPv6 pero no parece posible probar que una dirección
>> IPv4 y otra IPv6 corresponden al mismo sistema. El DNS no
>> indica nada: puedo tener una AAAA y una A para www.$ORG.org y
>> sin embargo estar usando dos sistemas separados para cada una
>> de ellas.
>
> Por eso mismo no es dual-stack a la fuerza. Si el administrador tiene un servidor Web y no quiere usar dual-stack se pueden colocar dos servidores Web, como con registro AAAA y otro con registro A. Es exagerado pensar que te van a obligar.
>
>
>> Forzar el uso de IPv6 me parece una mala política. No quiero
>> ser un ganso alimentado a la fuerza para producir paté.
>
>  Desde mi punto de vista todos los RIR han esperado a que los ISPs implementen IPv6 a su ritmo sin embargo esto ha ocurrido de manera muy lenta -más lento de lo esperado- y por ello pienso que ahora se encuentran en un punto de implementar un plan B lo cual es la política en cuestión. Igualmente ARIN _explicitamente_ no obliga al ISP a utilizar Dual Stack, es una manera de decirle al ISP, por favor utiliza IPv6 y seguirás recibiendo IPv4.
>  Por otro lado, en el supuesto que exista la "obligación" por parte de ARIN de forzar a utilizar IPv6, veo más puntos a favor que en contra, p.e.: incentivo del despliegue IPv6 y mejor aprovechamiento del espacio IPv4. La red sigue siendo gestionada y manejada como el administrador desee
>
>> ( y ojo, uso IPv6 en la red local y en los servidores, pero
>> lo uso como lo decido yo)
>
> Eso es exactamente lo que se quiere. Es como pensar que otras políticas también deciden/influyen sobre tu red. Por ejemplo, para solicitar direcciones IPv4 debes justificar su uso actual, ¿cierto?, en este sentido el mismo administrador subneteó (disculpen el cuasi verbo) la red a su gusto, cierto?. Lacnic no obligó a subnetear de X o Y manera.
>
>>
>> Saludos
>
> Igualmente
>
>> Joao
>
> Alejandro Acosta,
>
>>
>>
>> > No quiero entrar acá en si esto es bueno o malo (lo podemos
>> discutir
>> > en otro momento), sino que me gustaria profundizar en lo que parece
>> > ser uno de los principales obstáculos para esta politica,
>> que es como
>> > responder la pregunta "¿Como se si el rango de equipos que usa un
>> > cierto recurso IPv4  también tiene IPv6 dual-stack?"
>> >
>> > Es un problema interesante. A primera vista parece trivial (buscar
>> > A/AAAA, probar conexiones a ambos), pero a medida que uno le agrega
>> > componentes se vuelve mas dificil. ¿Que pasa con los usuarios
>> > residenciales? ¿Que pasa con las asignaciones utilizadas para
>> > infraestructura?
>> >
>> > La discusión de esta propuesta en ARIN comienza acá:
>> > http://lists.arin.net/pipermail/arin-ppml/2010-December/019053.html.
>> >
>> > ¡Me gustaria escuchar ideas sobre el problema!
>> >
>> > --
>> > --
>> > =========================
>> > Carlos M. Martinez-Cagnazzo
>> > http://www.labs.lacnic.net
>> > =========================
>> > _______________________________________________
>> > LACNOG mailing list
>> > LACNOG en lacnic.net
>> > https://mail.lacnic.net/mailman/listinfo/lacnog
>>
>> _______________________________________________
>> LACNOG mailing list
>> LACNOG en lacnic.net
>> https://mail.lacnic.net/mailman/listinfo/lacnog
>>
> _______________________________________________
> LACNOG mailing list
> LACNOG en lacnic.net
> https://mail.lacnic.net/mailman/listinfo/lacnog
>