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

Eduardo Trápani etrapani at unesco.org.uy
Wed Aug 1 07:32:11 PDT 2012


> 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


More information about the Uylug-varios mailing list