[LAC-TF] Introduccion a 6to4

[gerape]

Jordi tengo en Colombia servidores a mi cargo, he estado estudiando y
documentandome sobre el tema,
pueden ustedes indicarme quien en colombia trabaja en ese tema, o si Ustedes
me pueden colaborar
para iniciar con los servidores que tengo a cargo.

El día 6/06/07, JORDI PALET MARTINEZ <jordi.palet at consulintel.es> escribió:
>
> 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.
>
>
>
> _______________________________________________
> LACTF mailing list
> LACTF at lacnic.net
> https://mail.lacnic.net/mailman/listinfo/lactf
>



-- 
Vivo en Colombia y sigo vivo  !!!