[LAC-TF] El costo (o no costo) de v6 (era: Introduccion a 6to4)

[Fernando Gont]

Jordi,

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

En ningun momento hice ningun tipo de alusion 
personal ni acusacion. Mis comentarios fueron 
siempre sobre aspectos tecnicos o legales de v6. 
(Creo que se tendria que poder mantener una 
discusion tecnica sin mayores inconvenientes... sin llevarlo a algo personal)



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

La experiencia esta documentada en 
http://www.gont.com.ar/drafts/tcp-soft-errors/draft-ietf-tcpm-tcp-soft-errors-05.txt 
. Y es ensayable con cualquier sistema que tenga 
v6 on por default. Y al menos en algun momento 
estuvo documentada en http://v6fix.net/ .



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

Mis dudas surgieron a partir de la presentacion 
que linkeaste en tu e-mail 
(http://www.lacnic.net/documentos/lacnicx/the_cost_of_not_deploying_ipv6_v6.pdf), 
tituladas "The cost of NOT deploying IPv6".



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

Personalmente, el hecho que la IETF haya 
estandarizado no es garantia de que uno pueda 
implementar una tecnologia de forma libre y 
gratuita. En el caso de Teredo, pareciera ser que 
hay que obtener una licencia por parte de MS. 
(http://mirror.switch.ch/ftp/doc/ietf/IPR/microsoft-ipr-draft-huitema-v6ops-teredo.txt 
, http://www.kame.net/newsletter/20040525/)



> > 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 muchos factores a considerar... que no solo 
radican en el protocolo en si, sino tambien en la 
madurez de las implementaciones.



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

Esto NO es cierto. Consulta por ejemplo la IPR del algoritmo Eiffel para TCP.



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

Las IPR implican, en todos los casos, perdida de 
libertad. Incluso si no tienen animo de lucro.

Hace no mucho tiempo atras discutimos con gente 
de algunos OSes libres sobre el tema de un "fix" 
para ataques contra TCP que propuso la gente de 
Cisco, sobre el cual hay una IPR. El IPR de Cisco 
basicamente dice "Mientras que vos no nos hagas 
juicio o nos pidas dinero para implementar tus 
estandares, nosotros no te pediremos dinero a cambio".

Pensa el siguiente escenario. Supongamos que 
determinada empresa (Evil Corporation) fabrica 
productos basandose en el codigo de FreeBSD. 
Asimismo, tiene IPRs sobre una serie de 
estandares, y le cobra a Cisco (y otros fabricantes por su implementacion).

Supongamos que FreeBSD implementa el fix 
propuesto por Cisco, y lo incluye en el codigo. 
Evil Corp. no se da cuenta que FreeBSD incluyo en 
el codigo el fix de Cisco, y saca productos al 
mercado. Cisco percibe que los productos de Evil 
Corp. implementan su fix, y entonces le hace juicio a Evil Corp.

Lo que en principio era un inocente IPR, termino 
en un juicio para una empresa (por mas 
cuestionable que sea la moral de Evil Corp....).



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

Entiendase: Este problema TIENE solucion. Una 
posible alternativa es 
http://www.gont.com.ar/drafts/tcp-soft-errors/draft-ietf-tcpm-tcp-soft-errors-05.txt 
.

El ejemplo NO lo plantie a modo de "esta es la 
razon para no implementar v6", sino como ejemplo 
de fabricantes que incluyen chiches nuevos sin 
considerar las consecuencias de hacerlo mal.



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

En las implementaciones derivadas de 4.4BSD el 
timeout es de 75 segundos, aprox.



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

El problema del escenario en cuestion es la 
conectividad del cliente, mas que la del servidor.



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

Yo hable con la gente de NTT (Arifumi) en la IETF 
de San Diego. Y lo que em comentaron ellos es que 
MS se negaba a implementar el fix propuesto, por 
no estar en std track. (lease: esto es estupidez 
del vendor, y no del protocolo en si). (ver 
discusion de los ultimos meses en la lista del tcpm wg)



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

Esto no me quedaba claro. Gracias por la aclaracion.



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

A mi me argumentaron recibir quejas por el 
problema descripto en el draft "soft errors". 
Incluso ellos publicaron un draft cuya unica 
intencion era publicar el fix de mi draft, pero 
en std track, ya que supuestamente microsoft les 
habia dicho que sino no iban a implementar el fix.


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

Usar Internet Explorer es cosa de suicidas. :-)

P.S.: Yo no mantengo religion ni por v4 ni por 
v6. Es mas, en general focalizo mi trabajo sobre 
la capa de transporte, y no sobre la capa de red. 
Por ello, desde ese punto de vista, me da lo 
mismo que v6 se implemente o que no. Mi unico 
planteo es que, cualsea la determinacion que uno 
tome, la misma sea consecuencia de un analisis 
tecnico y economico real de lo que se esta 
haciendo, y no por una cuestion de apuro (muchas 
veces motivado por el reiterado Armagedon de extincion de direcciones IP).

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