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

Sab Ene 22 18:37:08 BRST 2011

On 21 Jan 2011, at 17:56, Fernando Gont wrote:

> Estimados,
> 
> Permitaseme :-) resumir lo creo que que es la gran cuestion en este caso:
> 
> Si las direcciones v6 son para asignar a servidores, basicamente existe
> el problema de "happy-eyeballs". Creo que esta mas que demostrado que
> los proveedores de contenido no incluyen records AAAA para los dominios
> principales, a menos que tengan certeza que no existiran los problemas
> mencionados en el draft de "happy-eyeballs".

	Esto deberá ser temporal y va mejorando poco a poco. Creo que ayudará el IPv6 World Day (o como se llame) para quitar un poco el estigma, con suerte algunos encuentren más latoso regresar el registro AAAA a null que dejarlo. Y siendo bien honestos, cuantos websites que no hay implementando IPv6 no lo hacen porque el 0.02% de sus usuarios tienen problemas y porque esto representa mucho dinero? 

> Por otro lado, dada la
> infinidad de clientes v4-only,
> si o si es necesario que el servidor en
> cuestion tenga conectividad v4-nativa (lo cual hace que no se quite la
> presion sobre las direcciones v4).

	Mientras allá direcciones, también para los servidores se acabarán. Eventualmente será más caro tener NATeados los servidores que tenerlos en v6.

	Y eventualmente habrá más usuarios en v6 (ver abajo).

> 
> Si por el contrario las direcciones son para asignar a clientes, dado
> que vistualmente todos los contenidos estan en v4 y no en v6, o bien
> directamente no se utilizaria, o bien se utilizaria para luego pasar por
> NAT64 para llevar al contenido v4-only en cuestion. En tal caso, esto no
> difiere mucho de NATear en v4 (ni tampoco quita presion sobre las
> direcciones v4)

	Solo entre v4 y v6. En teoría el uso de NAT64 irá reduciéndose conforme se despliegue IPv6. Y en mi opinión si quita presión en direcciones v4, no toda pero al menos no es la misma que ahora, e.g si tienes 10M de usuarios solo necesitas 1M de direcciones v4.

> 
> Esta situación se puede resumir con una frase de idioma ingles que dice
> "We're really fu**ed". :-)
> 

	Andas negativo el fin de semana, eh? =)

> Saludos cordiales,
> Fernando
> 

Saludos!
-as

> 
> 
> 
> On 21/01/2011 03:41 p.m., Nicolás Ruiz wrote:
>> Hola,
>> 
>> 2011/1/21 Carlos Martinez-Cagnazzo <carlos en lacnic.net>:
>> 
>>> - Segundo, como network admin de mas de 10 años, no simpatizo con
>>> imposiciones técnicas, IPv6 o cualquiera otra
>> 
>> A mi no me gustan las imposiciones técnicas arbitrarias (y la
>> percepción de arbitrariedad es subjetiva), pero lo cierto es que como
>> netadmin tu ya estas cumpliendo con un montón de imposiciones técnicas
>> (o mejores prácticas, según como las quieras ver), a saber:
>> 
>> - No permites paquetes salientes con direcciones IP origen que no es
>> de tu rango asignado.
>> - No permites paquetes salientes con direcciones RFC1918.
>> - Tienes direcciones de contacto publicamente disponibles para casos
>> de problemas/abuso.
>> 
>> Y si incluimos sysadmins, tampoco tienes open mail relay,
>> probablemente no tienes open dns resolvers (a menos que realmente
>> sepas lo que haces), probablemente no tienes servidores ftp que
>> permiten anonymous upload sin supervisión, etc.
>> 
>> En resumen, uno como net admin ya esta cumpliendo con una serie de
>> imposiciones técnicas. Y si bien muchas de ellas no ofrecen un
>> beneficio directo tangible, es evidente que cuando la mayoria cumple
>> esas imposiciones es mejor para todos.
>> 
>>> - Sin embargo, ahora que tengo que mirar las cosas desde un punto de
>>> vista mas global, también veo que el espacio IPv4 funciona como lo que
>>> en economia creo se llama un "commons", es decir un recurso compartido
>>> y finito (ultimamente muy finito :-) ), que a menos que alguien tome
>>> alguna medida regulatoria esta expuesto a la "tragedia de los comunes"
>>> (http://en.wikipedia.org/wiki/Tragedy_of_the_commons), en el cual el
>>> recurso compartido termina depredado y agotado para todos.
>> 
>> Y aquí precisamente haz dado en el clavo.
>> 
>> A medida que la cantidad de direcciones IPv4 disponibles disminuye, su
>> costo va en aumento. Eso creo que es inevitable y evidente.
>> 
>> Implementar IPv6 es una alternativa para evitar el aumento del costo
>> de IPv4 (IPv6 tiene sus propios costos asociados, como bien lo
>> mencionó Fernando). Otras alternativas son expandir sin utilizar más
>> direcciones públicas, o no expandir. Esas alternativas también tienen
>> sus costos asociados.
>> 
>> Según yo lo veo, la diferencia entre estas tres alternativas es que el
>> costo de implementar IPv6 va en disminución (eso creo que también es
>> más o menos inevitable y evidente) mientras que el costo de las otras
>> dos alternativas aumenta a medida que crece la demanda de dispositivos
>> en la red interna.
>> 
>> Ahora, en este momento es impráctico instalar dispositivos que sean
>> IPv6-only, y si vas a usar IPv6, tienes que ir por dual stack.
>> 
>> Si bien hoy en día el costo de implementar IPv6 (o dual stack) es
>> mayor que el costo de implementar IPv4 solo, yo prefiero que tengamos
>> la responsabilidad de implementar dual-stack en nuevas redes. Eso me
>> va a facilitar la operación a mediano plazo a pesar de causar más
>> problemas a corto plazo.
>> 
>> Es por ello que yo estoy de acuerdo con la política de requerir
>> dual-stack para nuevas asignaciones de direcciones.
>> 
>> Hay ciertas similitudes a la implementación de registros AAAA en DNS
>> (y DNSSEC): uno de los factores a considerar fue la cantidad de
>> servidores que fallaban cuando recibian queries o respuestas
>> inesperadas. Llega un momento en el que uno no puede esperar más. Y mi
>> opinion personal es que ya llegamos a ese punto con IPv4.
>> 
>> nicolás
>> _______________________________________________
>> LACNOG mailing list
>> LACNOG en lacnic.net
>> https://mail.lacnic.net/mailman/listinfo/lacnog
>> 
> 
> -- 
> Fernando Gont
> e-mail: fernando en gont.com.ar || fgont en acm.org
> PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
> 
> 
> 
> 
> _______________________________________________
> LACNOG mailing list
> LACNOG en lacnic.net
> https://mail.lacnic.net/mailman/listinfo/lacnog