[uylug-varios] Migrando a IPv6 (era: Pregunta sobre enlaces CES)

Wed Aug 1 07:53:50 PDT 2012

	Bueno, cada quien platica como le va en la feria (no se si este dicho sea conocido aqui).

	Pero yo estoy a cargo de 2 centros de datos que soportan muchas aplicaciones externas, hechas en casa y hasta infraestructura critica para la operación del Internet y si, he tenido problemas, es mucho mayor el nivel de soportar 2 protocolos pero nada que no hayamos podido resolver. Nuestro plan en 2 años es eliminar IPv4 de la red interna de los datacenters y solo exponer los servicios a usuarios en v4 para hacer mas facil nuestra administración de la red.

	La opción es de cada uno, nadie está forzando a nadie a moverse a IPv6 pero creo que es importante y beneficioso hacerlo. Es un dolor, si, pero de todas formas los vas a hacer algun dia, mejor ahora que tienes tiempo a despues.

	Y sin ir por todo el correo de Eduardo, algunos problemas pueden verse como oportunidades:

	- GeoIP, no existe, igual sea interesante verlo como negocio.
	- Dyndns, oportunidad?
	- Problemas con servicio en v6 para algunos clientes, pon 3 nombres en el dns, algunos con AAAA y otros sin.
	- SPAM, oportunidad

	
Slds
as

On 1 Aug 2012, at 07:32, Eduardo Trápani wrote:

>> estas son solo algunas cosas que podes encontrar, por eso creo que pasar
>> a ipv6 puede ser un trabajo muy grande que se puede hacer despues de
>> trabajo enorme, o sea una atenta analisis y planificacion, y los dos
>> pueden absorbir muuuuucho tiempo para que todo funcione.
> 
> Sí, tocaste un punto súper importante.  No se trata solo de manejar el
> protocolo.  En aras de una implementación saludable se debería ser más
> honesto.  Si los programas no están listos ... los problemas te saltan
> por otro lado y después hay que poder atacarlos.  Y se necesita tiempo
> para eso.  No hablo en el aire, tengo ejemplos bien concretitos, propios
> y documentados.  Van algunos, tengo más:
> 
> Yo por ejemplo me pasé a la nativa ni bien pude y me llevé la primera
> sorpresa, el plugin de GeoIP de awstats no funciona para IPv6[1].
> Conclusión, me quedé sin parte de la información de las visitas en uno
> de los servidores.  O sea, a partir de IPv6 pierdo información.  Algo
> que andaba ahora no anda y no tiene arreglo todavía.  ¿Que hago?  Por
> ahora me jorobo, se escuchan sugerencias.
> 
> Después, aprovechando la conectividad punta a punta puse un repositorio
> git con dirección IPv6 estática.  ¡NO ANDUVO!  Después de buscar la
> razón (no todos tenemos siempre el tiempo de hacerlo) encontré el
> problema: el análisis de direcciones en el cliente git y el uso de un
> puerto no estándar.  Todo eso anda en IPv4, pero no en IPv6.  Lo reporté
> y sigue abierto el fallo aunque han intentado un par de parches[2].  De
> nuevo, perdí tiempo por algo que nunca hubiera fallado en IPv4.  Al
> final se arregla con DNS o /etc/hosts pero en IPv4 no hubiera tenido que
> hacer nada.
> 
> Claro, antes de eso quise tener dyndns para IPv6 y casi nadie me lo
> ofrecía y cuando sí, no había programa que lo actualizara, así que hice
> un parche[3] para ddnsclient y la verdad es que me quedé contento :)
> porque hay gente que lo usa[4].  Los desarrolladores, después de un
> breve intercambio[5] lo dejaron ahí sin más.  Yo lo sigo usando y con
> eso puedo dar soporte a los familiares que están atrás de NAT, con VNC.
> Pero cada vez que instalo el cliente tengo que meterle el parche
> manualmente.  Y tengo dejar el paquete en hold y perderme las
> actualizaciones o salir a poner el parche cada vez que haya una.
> Ninguna de las dos es una buena solución.
> 
> Tampoco fue tan fácil el acceso remoto porque Reminna (el cliente de
> VNC) que anda al pelo en IPv4 no tiene manera de darle prioridad a IPv6,
> así que con ese cliente tengo que hacer un ping6 al dns dinámico, copiar
> la dirección IPv6, ponerle los paréntesis rectos y el :0 y recién ahí
> conectarme.  Otra cosa rota e incómoda, pero bueno, sin IPv6 tenía que
> armar una VPN.  Dicho sea de paso, la rotura viene por el hecho de que
> dyndns no acepta solamente un registro AAAA (otros ni siquiera lo
> aceptan), así que cuando lo agregás te pone "de oficio" un A (IPv4)
> acompañándolo y reminna resuelve ese, que va al router.
> 
> Eso desde el punto de vista solamente de *programas*.  Recién ahí
> entraría la parte de conectividad.  Ya mostré en la lista (y cualquiera
> con IPv6 nativa desde Uruguay lo puede verificar) la diferencia de
> latencia con Google desde Uruguay en IPv4 e IPv6.  ¡20 veces más
> latencia por IPv6!  Después hay que configurar el firewall para la red
> local (no hablo de la DMZ).  En IPv4+NAT es casi trivial.  En IPv4 con
> varias públicas dejás las salientes y listo.  Pero en IPv6 *tenés*
> además que permitir ICMPv6 entrante.  *Suponiendo* que no estés usando
> proxies, en cuyo caso tenés que además ver que no te lo esquiven (con
> sus políticas de seguridad, límites de ancho de banda y acceso
> incluídas) por IPv6.  De hecho por lo menos hay que duplicar las
> políticas, ponerlas en los dos stacks y asegurarse de mantenerlas
> sincronizadas.
> 
> Carlos decía con gracia que IPv6 andaba y que ya recibía spam por ahí.
> Genial, súper divertido.  ¡Salvo que el dnsbl que uno esté usando no
> maneje IPv6!  En ese caso el bloqueo que tenías por IPv4 deja de andar
> en IPv6, cualquiera te puede mandar (hablo del bloqueo por dirección de
> origen, los demás, por ejemplo spamassassin, siguen en efecto).  Yo en
> IPv4 uso Barracuda, Spamhaus y Uce-protect.  ¿Qué hago al prender IPv6
> en un servidor de correo?  Cruzar los dedos y esperar que se detecten a
> más algo nivel.  Con IPv6 tendría una barrera menos para combatir spam
> (y ni siquiera entro en la discusión de para qué serviría un DNSBL con
> espacios de direcciones tan grandes, aunque pueden ver algo acá[6] de
> parte de alguien implementándolo, no suena esperanzador).  Y sí, hay
> otras cosas a futuro y ahora.  Pero el hecho es que lo que me funciona
> hoy bien, deja de andar tan bien al meter IPv6.
> 
> Sin inventario de servicios y programas y su adaptabilidad a IPv6 meter
> el stack en la red es, por lo menos, audaz.  O cuenta con un equipo
> capaz de dedicarse a resolver las cosas que vayan surgiendo.  Y ni
> siquiera mencioné los dispositivos.  Entiendo perfectamente a Ernesto y
> lo que dice y las prioridades.  Poner un AAAA y un servidor es juego de
> niños.  Recibir el prefijo en el router no es gran cosa.  Habilitar
> SLAAC tampoco.  Lo demás que puede pasar ... creo que queda claro que no
> es tan simple.
> 
>> Bueno, te recomendaría cambiarle la prioridad a v6. De entrada te quitas el NAT para sitios como Google, Facebook, Wikipedia, Yahoo, etc.
>> 
>> Y bueno, no NAT al menos para mi es una ganancia en desempeño y manejabilidad de la red.
> 
> Conclusión, está bárbaro IPv6.  Pero no es ni ahí "soplar y hacer
> botellas".  Intentar venderlo como que se trata de poner un stack más
> para "de entrada quitar NAT a Google", pretendiendo que eso es ya una
> mejora (suponiendo que no hay proxies y olvidando mencionar el aumento
> x20 de la latencia al día de hoy desde Uruguay), es de una simpleza que
> raya en el engaño.
> 
> "Mejorar la manejabilidad" de la red teniendo que poner políticas de
> firewall específicas para la red local, que antes no existían, y
> teniendo que duplicar y mantener duplicadas y sincronizadas las
> políticas actuales ... es difícil de entender.  Y no hablo por ejemplo
> de cosas simples como DDNS con DHCPv4.  Eso hay que migrarlo también o
> dejar que las IPv6 sean decorativas.
> 
> A eso me refería hace un tiempo con no apoyar IPv6 a ultranza y mucho
> menos informando a medias.  Sin tomarse el trabajo de verificar el
> funcionamiento de todos los programas (en mi caso mencioné que fallaron
> o tuve problemas con awstat, git, ddclient y reminna, pero hay más) lo
> que puede pasar es que a quien hayan convencido termine desactivando
> IPv6 o priorizando IPv4 (yo lamentablemente lo tuve que hacer en un proxy).
> 
> Y eso, más que empujar a IPv6 va a frenar su uso, y mucho, porque esos
> administradores van a volver a "subirse" solamente cuando ya no haya
> posibilidad de huir.  Seamos razonablemente cautos para que quienes se
> embarquen lo hagan sabiendo que puede haber problemas sin resolución,
> como los que mencioné y muchas cosas a tener en cuenta.  Doble stack
> tiene bastante de doble trabajo y algunas sorpresas en la manga.
> 
> Eduardo.
> 
> [1] http://awstats.sourceforge.net/docs/awstats_contrib.html
> [2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=646178
> [3] http://sourceforge.net/mailarchive/message.php?msg_id=28068392
> [4]
> http://www.ip-phone-forum.de/showthread.php?t=244692&p=1802791&viewfull=1#post1802791
> [5] http://sourceforge.net/mailarchive/message.php?msg_id=28068392
> [6] http://www.gossamer-threads.com/lists/nsp/ipv6/21944#21944
> _______________________________________________
> Uylug-varios mailing list
> Uylug-varios at listas.uylug.org.uy
> http://listas.uylug.org.uy/listinfo.cgi/uylug-varios-uylug.org.uy