[LAC-TF] Introduccion a 6to4

[Fernando Gont]

Jordi,

>Quier aclarar tambien que, la idea de estos correos no es discutir si es
>bueno o es malo. IPv6 es la unica opcion que hay, y aquí pretendemos ayudar
>a facilitar su despligue y a mejorar la conectividad con IPv6.

Mi intencion no es debatir si IPv6 es bueno o 
malo. Si se quiere, uno solo de mis comentarios 
(el del delay) podria enmarcarse en ese estilo de 
discusion. Mis preguntas/comentarios tienen dos motivadores:

a) Dudas que me surgieron al leer el mail (como 
por ejemplo lo de la IPR de Microsoft).

b) Hacer mencion a algunos temas que no se si 
todo el mundo los esta teniendo en cuenta. La 
charla aqui es sobre implantar IPv6 en ambientes 
de produccion. Y creo que es saludable, antes de 
implantar algo en un ambiente de produccion, 
analizar todas las posibles implicancias que esto 
puede tener (economicas, de interoperatividad, y de seguridad).



> > Segun tuve entendido en algun momento, Microsoft tenia una IPR sobre
> > Teredo? Tenes idea si esto es asi, y en tal caso, cuales son las
> > implicancias? (por ej., posibilidad de implementar Teredo en OSes libres).
>
>No que yo recuerde, y de hecho hay una implementacion libre de Teredo,
>llamada Miredo, pero por favor, no mezclemos temas, y atengamonos al asunto
>de cada correo o no terminaremos nunca y no facilitaremos a la gente seguir
>los diversos hilos !

Esto es algo que a una organizacion la afecta 
directamente. Entre los mecanismos de transicion, 
uno al que se suele hacer referencia es Teredo. 
Pero apostaria a que la gran mayoria de la gente 
no sabe sobre el IPR de Teredo.

Como administrador, a mi me interesa saber:
a) Voy a tener que pagar para utiliozar esta tecnologia?
b) Van a poder los OSes libres incluir esta 
tecnologia, libremente? (el hecho de que *exista* 
una implementacion libre no necesariamente es garantia de esto....)
c) Si no pudiera utilizar Teredo, hay alguna 
penalidad por no hacerlo. Es decir, que 
desventajas tendre con respecto a la gente que *si* utiliza Teredo?



> >> Hay que recordar que los usuarios de los Sistemas Operativos que soportan
> >> IPv6 (la mayoria de los actuales, muchos incluso activado por defecto),
> >
> > En mi opinion, hay casos en los cuales esto es cuestionable. Hay
> > sistemas que habilitan IPv6 por default,  sin tener en cuenta las
> > posibles implicancias.
[....]
>Nos guste o no esto es una fase de la transicion, y generalmente se debe a
>los proveedores de servicio o administradores de red haciendo mal su
>trabajo. Por ejemplo, si tienes un servidor web sin acceso a IPv6 estable,
>no le pongas un AAAA ! Igualmente, si tienes una LAN sin acceso estable a
>IPv6, no anuncies IPv6 !

El problema que describo, en mi opinion, no se 
enmarca en ninguna de estas dos categorias, sino 
que surge en escenarios tan comunes como el siguiente:

Un usuario usa un sistema dual-stack con v6 
habilitado por default. En algun lugar (por ej., 
un par de hops mas arriba), se corta la 
conectividad IPv6 (es decir, en algun punto el 
upstream no tiene ni conexion nativa IPv6, ni tunel, ni nada).
Supongamos que el usuario intenta visitar el site 
de Microsoft. Al resolver "www.microsoft.com", se 
obtendran tanto RRs AAAA como RRs A. Pero de 
acuerdo a lo establecido por las 
especificaciones, se deben intentar utilizar 
primero los RRs AAAA. Y ahi es donde surge el 
problema del delay. Ya que se perderan *decenas* 
de segundos (y hasta minutos) por cda RR AAAA.

Japon, tal vez uno de los principales propulsores 
de v6, ha y esta teniendo este problema. Ver, por 
ejemplo: http://www.nttv6.net/~fujisaki/fallback.pdf



>Precisamente con el mayor despliegue de reles 6to4 y Teredo, mejoramos la
>conectividad y evitamos timeouts innecesarios.

Claro, pero en muchos casos las cosas se estan 
haciendo en el orden incorrecto. Primero 
habilitaron v6 por defecto, y *crearon* el 
problema de los delays. Y *luego* se fijaron en 
que se puede hacer para solucionarlo. La gente de 
NTT estaba loca al respecto. Sus clientes 
quejandose, y Microsoft poniendo excusas tontas 
para no implementar los correspondients fixes.

Saludos,

-- 
Fernando Gont
e-mail: fernando at gont.com.ar || fgont at acm.org
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1