[LAC-TF] Introduccion a 6to4

[JORDI PALET MARTINEZ]

Hola Fernando,

Sigo debajo, pero por favor, si esto no aclara el tema, inicia otro thread,
porque esta no era la motivacion de este, y pretendo ayudar a la gente que
quiera deplegar 6to4 y Teredo (que ira en otro thread), no desanimarles ni
confundirles. Yo no tengo necesitad de engañar a nadie, y lo que estoy
haciendo esta basado en la experience de muchos años y de varios ingenieros
de mi equipo, que creo que esta mas que demostrada habiendo desplegado IPv6
en mas de 170 redes en el ultimo par de años y hasta ahora ningun resultado
negativo como tu quieres indicar. Insisto en que la idea aquí es ayudar, no
convencer o desconvencer a nadie, y me gustaria que estos thread se
concentren en eso.

Si tu tienes esa experiencia negativa tu mismo (no de oidas de terceros o
pruebas con betas), indicalo en otro thread, y seguro que damos con el
motivo y todos aprendemos si hay algo que se esta haciendo mal.

Saludos,
Jordi




> De: Fernando Gont <fernando at gont.com.ar>
> Responder a: <lactf at lac.ipv6tf.org>
> Fecha: Wed, 06 Jun 2007 17:07:22 -0300
> Para: <lactf at lac.ipv6tf.org>
> Asunto: Re: [LAC-TF] Introduccion a 6to4
> 
> 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:

De acuerdo, pero la idea de los threads que estoy iniciando no es general
consultas al respecto de los mecanismos de transicion, sino al respecto de
como desplegarlos para que la gente pueda hacerlo facilmente, tal y como
indique en la reunion tras la iniciativa del directorio de fomentar el
despligue.

En cualquier caso, respondere esta vez, pero no quiero liar el thread y que
quien quiera luego consultar como ponerlos en marcha se pierda en otras
cosas. Insisto ademas en que el tema de Teredo ira en otro thread, y quiero
evitar que mezclemos los dos, porque se puede llegar a conclusiones erroneas
si no se lee detenidamente todos los emails.

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

El hecho de que haya un mecanismo ESTANDARIZADO por IETF, despeja todas las
dudas al respecto, pues aunque haya un IPR, ha sido liberado por Microsoft.
Dudo que alguien en esta lista pretenda desarrollar una nueva version de
Teredo, y seria el unico caso en el que tendrias que ver si te afecta y
como.

> 
> 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).
> 

Llevamos AÑOS haciendo ese ejercicio. El momento de desplegar IPv6 en
prouccion comenzo hace ya 2 o 3 años. Los pilotos, ya no son necesarios, mas
que para familiarizarse antes del entorno de produccion, pero no para probar
si va o no va y si es bueno o no. Hay mas de 800 ISPs en todo el mundo que
lo han hecho. Si piensas que estan equivocados, es tu punto de vista, pero
no el mio, y espero que el resto de los participantes tampoco tengan esa
perspectiva, en caso contrario posiblemente no estarian en esta lista.

Lo que intento es ayudar AL DESPLIEGUE, pero mi tiempo es limitado, y si
tengo que explicar cosas que se han hablado hasta la saciedad en esta y
otras listas, pues, la verdad, no seria productivo para nadie, creo.

> 
> 
>>> 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?

NO, de otro modo IETF no lo estandariza.

> 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....)

SI, tambien lo he dicho antes. Hay OSs libres que son muy estrictos y no
incluyen en su kernel cualquier cosa por el simple hecho de que haya un IPR,
aunque el IPR indique claramente que no manifiesta animo de lucro, ni
licencias, etc. Yo discrepo con ese talibanismo, por llamarlo de algun modo
y espero que mucha gente tambien.

> 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?

NO.

Es mas, y para concluir. La cuestion es que Teredo ya esta en el mercado, y
que si los ISPs de esta region no desean desplegar reles Teredo, los
usuarios van a seguir usandolo, y ello va en contra de los intereses de los
ISPs que no den el paso. Es decision de cada uno.

> 
> 
> 
>>>> 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).

Esto tambien ocurre con IPv4. De vez en cuando algo puede fallar. Es menos
frecuente, cierto, pero precisamente por eso, lo resolveremos cuando mas
conectividad IPv6 pongamos en marcha. No hay otra forma de resolverlo, hay
que incrementar la disponibilidad de multiples caminos, para que BGP pueda
hacer su trabajo correctamente.


> 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.

En ningun caso he visto que sea una cuestion de segundos como tu dices, ni
de minutos. Si ocurre, no podemos hacer nada, salvo mejorar el numero de
ISPs ofreciendo IPv6 para que ocurra menos.

No vamos a convencer a los usuarios de que desconecten IPv6, porque en
cambio para peer-to-peer tiene muchas mas ventajas.

Por otro lado, con la tabla de politicas que lleva Windows XP y Vista, esto
que comentas no ocurre (dado que si la conectividad es Teredo, no se usa
IPv6 para una web, pero si para peer-to-peer), en algunos sistemas
operativos de software libre, si es mas facil.

Se ha discutido hasta la saciedad este tema en NANOG y PPML, y la conclusion
es que al final todo el mundo reconoce que hay mas bulo que otra cosa, que
cuando la gente habilita AAAA, si el servidor tiene conectividad estable, no
hay quejas de los clientes. Y cuanto mas hagamos por el despliegue de IPv6,
menos ocurrira. Creo que la conclusion es bien sencilla.

> 
> 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
> 

Lo conozco, pero como decia antes, quedan peor muchos SOs libres. Y ademas,
esta basado en una beta de Windows Vista, y las betas son para eso, y
Microsoft corrigio los problemas en la version comercial, logicamente.

Ademas, fijate que indica que falla por lo mismo que yo he comentado.
Insisto el problema es de redes mal gestionadas, tando del lado del servidor
como del cliente. Un usuario final no tiene estos problemas. Nosotros
alojamos webs de cientos de clientes, que no estan relacionados con IPv6 ni
siquiera con telecomunicaciones, y por defecto todas tienen dual stack.
Hacemos mediciones y vemos lo que pasa, y la realidad es que no ha habido en
los dos ultimos años, ni una sola queja.

Ademas, yo no estoy diciendo que habilitemos AAAA en todos los servidores,
el thread es para otra cosa. Si un dia digo habilitar AAAA en todo, entonces
podemos tener esta discusion. Mi recomendación es que no es tan necesario
porque IPv6 en servidores webs no aporta, hoy por hoy, nada nuevo, es bueno
tenerlo, si, pero si tu red es estable.

> 
> 
>> 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.

No exageres. Conozco bien a la gente de NTT que ha hecho todo el despliegue,
y te puedo garantizar que en produccion no tienen problemas. Hasta el punto
de que el servicio de IPTV SOLO lo dan con IPv6 desde hace mas de dos años.

Ademas esto no tiene nada que ver con lo que yo estoy planteando. Creo que
no has seguido los documentos que he presentado en la ultima reunion :-(

Si tu y yo usamos peer-to-peer con el mismo mecanismos de transicion, no
necesitamos ningun rele. Pero como hay usuarios que estan detrás de NAT y
otros que usan en cambio un modem en el PC y por tanto no estan detrás de
NAT, usan diferentes mecanismos. En este caso hace falta usar un rele para
cada mecanismo y luego la conexión IPv6 nativa entre ellos. Si los reles
estan en los ISPs locales, estupendo, no pasa nada y eso es lo que pretendo
que esten en los ISPs locales o regionales. Pero si estan fuera, el trafico
puede estar rebotando por medio mundo.

Si en lugar de usar IPv6 se usa IPv4 el trafico tambien rebota desde el
usuario A a MSN y de ahí al usuario B ! Esto tiene implicaciones de retardo
y ademas de seguridad del trafico. Me parece mucho mas grave que asegurarse
de tener reles, cuyo coste de despliegue es despreciable.

Ademas lo que he comentado antes del address selection policy. Internet
Explorer no usar IPv6 si la conectividad es con Teredo y tambien hay soporte
de IPv4 en esa web: luego NO HAY RETARDOS ADICIONALES EN ESOS CASOS.

Por si fuera poco, cada vez hay mejor conectividad con IPv6 que con IPv4 en
redes que se han preparado bien, y eso lo han dicho varios operadores en
NANOG. La cuesiton es precisamente que despleguemos ya IPv6, porque el
demorarlo es lo que crea "desconexiones".

> 
> 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
> 
> 
> 
> 
> _______________________________________________
> LACTF mailing list
> LACTF at lacnic.net
> https://mail.lacnic.net/mailman/listinfo/lactf




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

Bye 6Bone. Hi, IPv6 !
http://www.ipv6day.org

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.