domingo, 3 de octubre de 2010

No hay plan B: ¿Porque la transición de IPv4 a IPv6 no va a ser sencilla?

Este es un artículo que salió recién el jueves pasado (30/09/2010) en arstechnica sobre los problemas que enfrenta la transición del protocolo IPv4 a IPv6. El autor es Iljitsch van Beijnum y pueden encontrar sus datos aquí (tienen que registrarse). Además tiene un blog aquí.
El artículo original pueden verlo aquí. De nuevo, los textos en rojo y cursiva son míos, ahí se los dejo, provecho.



No hay plan B: ¿Porqué la transición de IPv4 a Ipv6 no va a ser sencilla?



















Hace 20 años el enlace de backbone más rápido que había en Internet era de 1.5Mbps. Hoy discutimos sobre si esa velocidad es suficiente para conectar usuarios particulares. En 1993 habían 1.3 millones de máquinas conectadas a la red. El pasado verano, ese número se elevó a 769 Millones y esto solo refiere los sistemas con nombres de DNS. La noción de una computadora sin conexión a la web es casi absurda hoy en día.
Pero todo este rápido progreso va a disminuir su velocidad en los años siguientes. Internet pronto navegará mares tormentosos, está por quedarse sin direcciones IP y en la necesidad de ser desarmada y reconfigurada para continuar creciendo desde la segunda mitad del 2010. Originalmente, la idea era que este cambio sucediese tranquilamente en el background, pero desde hace varios años se ha hecho evidente que el cambio del actual protocolo IPv4, que se está quedando sin direcciones, a la nueva versión IPv6 va a ser un asunto complicado.

Problemas de compatibilidad

En la industria de la computación, gastamos enormes cantidades de dinero y esfuerzos para mantener sistemas heredados (legacy en el original, en uno de los post sobre internals de los trabajos de Duarte explico al final que significa) en funcionamiento. Esto incluye tanto sistemas grandes y costosos como otros pequeños que solo traen molestias. Hay aviones volando en círculos en trayectorias de espera, quemando combustible solo porque los sistemas de control de tráfico no pueden actualizar sistemas menos potentes que un smartphone. Así que los ingenieros sueñan dejar atrás toda esa tecnología obsoleta y empezarlo todo desde cero. Pero estos inicios "en limpio" rara vez son posibles.
Por ejemplo la especificación ethernet original de 10 Mb permitía paquetes de 1500 bytes. Completar 10 mbps tomaría cerca de 830 de esos paquetes de 1500 bytes. Entonces apareció  Fast Ethernet que era de 100 mbps pero el tamaño de los paquetes permaneció igual de forma que los equipos de 100Mbps pudieran convivir con los de 10Mbps sin problemas de compatibilidad. Fast Ethernet necesita 8300 paquetes por segundo para llenar la tubería, Gigabit Ethernet necesita 83000 y 10 Gigabit Ethernet casi un millón de paquetes por segundo (830,000)
Para cada nuevo estándar, los fabricantes de switch necesitaban aumentar el número de paradas para procesar el excesivo número de paquetes por segundo, llevando a las CAMs que almacenaban las tablas de forwarding a velocidades enfermizas que demandaban inmensas cantidades de potencia. La necesidad de conectar una vieja tarjeta NE2000 significaba que Fast Ethernet debía atenerse a los 1500 bytes, y luego sucedió lo mismo con Fast Ethernet y GiGabit Ethernet y así. En cada punto el paso siguiente tenía sentido, pero el proceso entero era irracional.


Por supuesto, el cambio sucedía. Fuimos de 10 Mbps a 10Gbps, de cableado a inalámbrico y de una web que a duras penas mostraba textos parpadeantes a una que ejecuta toda clase de aplicaciones. Solo resolvimos los problemas de congestión de DNS y DHCP a finales de los 80´s. Pero la razón por la que pudimos cambiar todas esas tecnologías era porque todas sucedían o por arriba o por debajo de la capa IP en la pila del modelo de red.
Los protocolos de red se edifican en "pilas" en las que cada capa provee una parte de la funcionalidad requerida. El famoso modelo OSI tiene 7 capas, pero la pila TCP/IP tiene solo 4. Si empezamos desde abajo y nos movemos hacia arriba, la capa de enlace de datos solo sabe enviar paquetes a través de cables o del aire, la capa de red sabe de routeo y direccionamientos permitíendole a los paquetes encontrar su camino a través de las red,  la capa de trasporte provee la funcionalidad de comunicaciones multipaquetes  y finalmente la capa de aplicaciones hace que las aplicaciones funcionen a través de la red. Estas capas mapean las capas OSI 2,3,4 y 7 respectivamente, cada una de ellas tiene muchos protocolos diferentes para elegir, excepto la capa de red que solo tiene el protocolo IP así que luce como la cintura en los relojes de arena.


Ethernet opera en la capa de enlace de datos (la capa 1 OSI, la capa física) y soporta por si misma redes complejas, pero Ethernet sin embargo es mas limitada en tamaño y alcance y puede ser actualizada con relativa facilidad. La capa de trasporte, donde residen los protocolos TCP y UDP tiene algunos detalles de actualización pero en principio los routers no ven más allá de la capa de red, de manera que no les importa si los paquetes son TCP, UDP o cualquier otra cosa. Esto significa que cambiar a un nuevo protocolo de transporte solo incluye actualizar los sistemas finales  que envían o reciben los paquetes, a los routers en el medio no les va a importar (pero a los firewalls si, de ahí las complicaciones en la práctica). Lo mismo es válido para protocolos de aplicaciones como HTTP, FTP, o SMTP. Si tu navegador decide empezar a descargar páginas wed usando FTP, eso es entre el navegador y el servidor remoto, al resto de la red no le importa.
Pero en contraste a las otras capas de la pila, IP esta en todos lados. El emisor del paquete necesita crear un paquete IP  válido, que sea procesado adecuadamente por los routers en medio para llegar a su destino y el destinatario debe ser capáz de decodificar el paquete IP así que cambiar el protocolo IP significa cambiar todos los hosts y todos los routers.

Una breve historia de la transiciones de los protocolos en internet.

A principios de los 90's, se hizo evidente que las direcciones de 32 bits de los protocolos existentes resultaban insuficientes para permitir el crecimiento continuo de internet mas allá de los primeros años del siglo 21. 4.3 billones posibles de direcciones diferentes (con solo 3.7 billones usables en realidad) solo serían suficientes en un mundo con 6, 7 o incluso 10 billones de personas. De modo que los directivos de la IETF decidieron adoptar el protocolo OSI/ITU-T CLNP para reemplazar el protocolo IP. Y ahora que?. Sip de verdad, Connectionless Network Protocol. CLNP es básicamente el IP de un universo paralelo donde todo tiene un nombre diferente, Como el NSAP para direcciones. Las NSAPs son de longuitud variable con un maximo de 160 bits, lo cual sería un muy buen incremento sobre el existente de direcciones de 32 bits. Y debido a mandatos gubernamentales iniciales (la mayoría de ellos sin éxito) la mayoría de los fabricantes ya habian implementado el CLNP.
Pero la IETF, que sufre de un severo cuadro del síndrome de "aquí-no-lo-inventamos", finalmente no lo adoptó. Así que a mediados de 95, los esfuerzos del protocolo IP de siguiente generación resultaron en una versión nueva del protocolo IP para resolver las limitaciones en la longuitud de las direcciones. La IETF tomó ventajas de esta oportunidad para arreglar algunas limitaciones de IPV4 -nadie sabe que le sucedió a las versiones 1,2 y 3 pero tranquilos, las quejas sobre el nuevo protocolo quedaron equilibradas entre "cambiaron demasiado" y "no lo arreglaron lo suficiente". Como resultado, la manera en que IPV6 (no pregunten que le sucedio a la version 5) interactúa con Ethernet u otras capas es bastante diferente a IPV4, DHCP fue significativamente revisado, y ahora existe una auto-configuración sin estado (stateless en el original (en oposición a stateful), se refiera a si el sistema tiene en cuenta o no estados previos en su operación) para configurar las direcciones actuales de 128 bits. Pero además de eso, IPV6 sigue siendo IP, así que la transición sería bien sencilla.

Todo esto ya sucedió antes.

Curiosamente, ya la Internet había atravesado una transición de un protocolo a otro. En los años 70's ARPANET usaba el NCP (Network Control Program). NCP estaba lleno de nociones interesantes, como la habilidad de contactar un router remoto y consultarle acerca de si un mensaje anterior había sido recibido en el otro extremo o no. (era un poco como enviarle una carta al servicio postal  preguntándole si la carta que habías mandado antes a un amigo había sido entregada o no). Este tipo de complejidades son difíciles de cuadrar con redes llanas, directas y especialmente rápidas. De modo que un nuevo y brillante protocolo fue desarrollado en los 80's  IP/TCP (hoy le llamamos TCP/IP, o IPv4 o simplementre IP, toda vez que el termino TCP esta implícito)
La RFC-801 describe la transición de NCP a TCP/IP. Básicamente, los dos protocolos coexistieron durante 1982 y para enero del 83 NCP se desvaneció y solo quedo TC/IP. En suma, necesitaron un año para hacer la transición en una red con una centena de nodos y tres aplicaciones basicas: telnet, FTP y el correo. Así que no debería ser una sorpresa que hacer lo mismo (la transición del casi obsoleto IPv4 a IPv6) menos de dos décadas más tarde en una red con miles de millones de nodos y cientos sino miles de aplicaciones tomaría un tiempo bastante largo.
Lo único bueno es que IETF inició su esfuerzo de IP de nueva generación (IPng), el cual produjo eventualmente IPV6, muy temprano, dándonos casi 20 años entre el momento en que IPv6 fue estandarizado en el 95 y el momento en que IPv4 se va a quedar sin direcciones (más o menos para el 2012) Lo malo es que esos 20 años se nos están acabando.

Barcos en la noche: La solución IPv6

Mientras que IPv4 e IPv6 son muy parecidos para los usuarios y las aplicaciones, en realidad los dos protocolos están completamente separados y no interactúan. El el routeo le llamamos a esto la aproximación de "barcos en la noche" (cuando menos uno de los dos tiene radar). La ventaja de este diseño es que no tienes que cambiar la infraestructura IPv4 existente - IPv6 simplemente se adiciona como un nuevo protocolo. Y las limitaciones y errores que son parte de IPV4 son dejadas atrás.
El problema con esto es que la primera persona que quiera abandonar IPv4 tiene que esperar la ultima persona que quiera adoptar IPv6. Es como tener una red de celulares sin conexión a la red de telefonía fija. Todo el mundo tiene que tener los dos tipos de teléfonos, con la esperanza de que en un futuro lejano, podamos abandonar la telefonía fija y solo usar celulares. Y con los celulares hay una ventaja y es que no usan cables. (aun cuando las lineas fijas también tienen ventajas) Con IPv6 no hay ventajas reales para que cambien la mayoría de los usuarios (que tienden a no impresionarse con la elegancia tecnológica)
Esto convierte la transición a IPv6 como la estrategia de persecución en las carreras de ciclismo en las que los competidores tratan de que su oponente tome le delantera. Una vez que el oponente va delante en "ganador" de la persecución puede tomar ventaja de la estela de su oponente y mantiene el paso con muy poco esfuerzo. Luego de una decada de persecución, la migración a IPv6 comienza a tomar forma, pero por desgracia el progreso llega muy tarde para evitar problemas cuando IPv4 quede fuera. Pero regresaremos sobre ese asunto. Primero echémosle una ojeada a las diferencias entre IPv4 e IPv6 que dificultan una transición sencilla.

Quiere decir que IPv6 es en realidad diferente a IPv4?

Cuando se desarrolló IPv6 a mediados de los 90's cosas que hoy tomamos por hechas no existían o no eran usadas ampliamente. Por ejemplo, hoy casi todos los sistemas que no son routers o servidores dedicados adquieren su dirección IP y un montón de más información a través del DHCP. DHCP es marcadamente complejo y tiende a producir errores comparado a la manera en que otros protocolos de los años 80's como IPX y AppleTalk resolvían este problema. 
Con DHCP el cliente primero emite una solicitud por difusión (broadcasting en el original y en lo adelante), con la esperanza de que uno o mas servidores lo atiendan y envíen una oferta de dirección IP. El cliente entonces evalúa las ofertas y se decide por una. El servidor  debe entonces reservar la dirección concedida para no volver a ofrecerla hasta que el cliente la libere (o la concesión caduque) y el cliente debe recordar renovar la concesión de la IP antes de que esta expire.
Con IPX este proceso es mucho mas simple, y no depende que ninguna información almacenada en el servidor. Los routers envían una dirección de red por broadcasting y cada sistema crea su propia dirección combinando esta con la MAC que trae quemada en su chip ethernet. AppleTalk es muy similar, pero las direcciones son mucho más cortas, de modo que AppleTalk genera un número aleatorio en vez de usar la MAC y luego envía unos pocos paquetes para verificar que nadie más haya elegido la dirección, así de sencillo.
Entonces crearon IPv6, IETF se fijó en protocolos como IPX y AppleTalk y creó una autoconfiguración sin estado, el cual es básicamente el enfoque de IPX. Luego, aparecieron unos detalles de privacidad acerca de empotrar en la dirección IPv6 la MAC de la máquina, así que adicionaron una opción parecida a la de AppleTalk: sustituyeron la MAC por un número aleatorio, y cada 24 hrs lo borraban y repetían el proceso para mantener tranquilos al gobierno y demás espías. Pero, porque limitarnos a dos mecanismos para configurar una dirección IPv6? (tres si cuentan la configuración manual). 
Entonces rehicieron DHCP como DHCPv6. Aún cuando los dos DHCPs compartían los mismos conceptos y arquitecturas, los formatos de sus mensajes y muchos detalles operacionales son completamente diferentes. DHCP esta tan íntimamente entrelazado con IPv4 que hacer los campos de direcciones más largos para soportar IPv6 era poco menos que imposible. También los routers hacían un broadcast (bueno, multicast, que es más eficiente) de su existencia con propósitos de auto configuraciones sin estado, de modo que dos piezas de información críticas pueden ser extraídos solo de estos mensajes de los routers, y estos no están presentes en DHCPv6. Estos dos elementos son la dirección del gateway/router por defecto, y como muchos bits son parte del prefijo de red (el equivalente de la mascara de subred en IPv4)
Hay un  tercer elemento crucial de información necesario antes de que un hosts puede tener conectividad de red: la dirección de los servidores de DNS (recordar una dirección IPv6 de 128 bits es un dolor de cabeza). Esto es algo que IPv6 puede proporcionar sin problemas. También hay una especificación, recientemente elevada al status de de estándar por IETF, para poner las direcciones de los servidores de DNS en los mensajes de los routers. Pero todavía hoy los routers no hacen esto.
Al final el resultado es un poco enredado: todos los dispositivos IPv6 soportan la auto configuración sin estados; Windows Vista y Windows 7 soportan IPv6 pero el Xp y MAC OS no. Respecto a los sistemas operativos de código abierto usualmente se puede instalar un cliente DHCPv6 si es que ya no viene con la distribución, y Vista y Windows 7 también usan la dirección derivada del numero aleatorio temporal por defecto, mientras que otros sistemas operativos no.

El problema que viene.

A estas alturas de la historia, muchos administradores empiezan a sentirse incómodos con la transición a IPv6: simplemente no pueden configurar un gran servidor de DHCPv6 que guarde logs de todas las asignaciones de direcciones diarias. En redes que deban soportar sistemas diferentes a la mono cultura Vista/7 no es viable desactivar al auto configuración sin estados so pena de que algunos sistemas simplemente no agarren una dirección IPv6. Peor todavía, la información de auto configuración sin estados que no este en uso debería ser propagada por los routers. Con que solo un router diga lo contrario puede hacer que todos los hosts creen direcciones temporales impredecibles y pueden jalar todo el tráfico para si o toda clase de cosas horribles.
Claro esta que un router enviando mensajes no solicitados no es muy diferente de uno mandando información de DHCP IPv4, excepto por el hecho de que los switches empresariales saben como tratar con este último, mientras que no saben tratar con el primero. De todos modos si las soluciones que están ahora mismo en curso se materializan, algunos administradores de sistemas argumentan que deben coordinar la información en DHCPv6 y que las difusiones de los routers son muy onerosas, toda ves que la gente que administra  routers y la gente que administra servers no deberían tener que hablar entre ellos.
10 años atrás, las diferencias entre IPv4 e IPv6 podrían haberse resuelto con una actitud de si-se-puede o quizás con resignación, pero las peculiaridades de IPv4 están ahora tan arraigadas y los restos del mundo multiprotocolos que existió durante las últimas décadas del siglo pasado, que la falta de parecidos entre IPv4 e IPv6 puede convertirse en un obstáculo real hoy en día.


Ajusta y olvida.

Un problema fundamental con la migración a IPv6 es el asunto del "ajusta y olvida". Si las organizaciones deciden adoptar Ipv6, deberán actualizar software y hardware; el ISP deberá proporcionar conectividad y direcciones IPv6 y luego el nuevo protocolo deberá ser habilitado en los routers y el DNS. Todo bien hasta aquí. Luego habrá que ejecutar algunos pings IPv6 y algunos traceroute (tracert para WindowsIPv6, y cuando todo esta funcionando como debería, todo volverá al estado en que estaba.
Pero como que hay tantos jugadores involucrados en las redes de tanto en tanto las cosas se rompen. Puede ser resultado de fallas de hardware, cables rotos, actualizaciones de software, reconfiguraciones ... ustedes digan. Usualmente los departamentos de TI y los ISPs son bastante proactivos para solucionar estos problemas y si no lo fueran los usuarios siempre ayudan advirtiendo cuan costosa e inaceptable es la interrupción. De modo que los problemas tienden a resolverse bastante rápido ..... para IPv4.
Si algo sale mal con IPv6, nueve de cada diez veces nadie lo notará. La mayoría de la comunicación de todas formas es sobre IPv4. Si se inicia una sesión sobre IPv6 y falla automáticamente regresará a IPv4. Esto puede ocurrir despues de una demora significativa o luego de una fracción de segundo. Si los usuarios se quejan, no sera raro que los asuntos sobre IPv6 tengan una prioridad baja. Por ejemplo MAC OS X 10.6 Snow Leopard tiene una falla seria en el código del DNS que hace que ignore IPv6 cuando está involucrado un record CNAME, algo que es bastante frecuente. Un año y varias actualizaciones mas tarde el error sigue ahí.
Una variación del problema es una en la que se implementa una nueva tecnología en software pero aun no se despliega. Entonces cuando dicha tecnología es usada, las cosas no funcionan tan bien, frecuentemente debido a que las nuevas tecnologías son problemáticas. Un ejemplo que no es sobre IPv6 es el HTTP Pipelining, cuando el navegador te dice "cargando 93 de 126" visitando un sitio web, el protocolo http original requería un socket por cada una de las 126 transferencias, esto generaba demasiado gasto de modo que el la revision 1.1 ya era posible mantener la sesion abierta y utilizarla para las subsecuentes transferencias. A esto se le llamó pipelining y fue implementado erróneamente en el software servidor web ISS 4 de Microsoft. Una vez que los navegadores empezaron a usar la característica, llegaron los problemas, así que por muchos años los navegadores traían el pipelining desactivado por defecto. 
Algo similar sucedió con BitTorrent (BT) e IPv6. La operación básica de BitTorrent es conectarse a un tracker y decirle que archivo quiere descargar y porque número de puertos los demás se pueden conectar a ti. Entonces el tracker te da la IP y los puertos de quienes tienen el archivo disponible. Los clientes BT se conectan a las direcciones/puertos de sus iguales (peers), los cual es fueron proporcionados por el tracker. Los equipos entonces intercambian partes del archivo en cuestión  directamente entre ellos.
La especificación original del protocolo BT permitía usar direcciones IPv4 o IPv6, así como nombres de dominio, como referencias de los trackers a sus clientes/peers. pero como la mayoría de las personas no poseen nombres fijos de dominios en casa y no habían trackers capaces de usar IPv6 en los inicios de BT solo se usaban direcciones IPv4. Luego de un tiempo al protocolo se le adicionó la posibilidad de intercambiar direcciones IPv4 entre iguales en formato binario ahorrando bastantes recursos con esto. Por supuesto, esto rompió la compatibilidad con IPv6.
Entonces el mayor (bueno, cuando menos el mas visible) tracker BitTorrent, que era mantenido por "The Pirate Bay" (TPB) se cambió a direcciones IPv6. Para evitar problemas con la actualización del protocolo BT, TPB decidió tener conexiones dobles con los clientes BT, una conexión sobre IPv4 para recibir las direcciones de los peers Ipv4 y una sobre IPv6 para los clientes IPv6. Esta estrategia funcionaba bien si el cliente BT lo soportaba, pero no tan bien para los clientes BT existentes ejecutándose en máquinas que migraban silenciosamente a IPv6. Este último caso era común y muchos de estos clientes fueron escritos en lenguajes de alto nivel a los que no le importaban las diferencias entre IPv4 e IPv6. Así que estos clientes solo veían los pares IPv6 ... si veían algo.

DNS whitelisting.

Un ejemplo del problema "no puedo llegar allá desde aquí" es el asunto con los hosts que creen que tienen IPv6, pero que en realidad no funciona. (Hace unos años google calculó que mas del 25 % de los hosts que tenían IPv6 estaban en esta situación). Aún cuando sabemos como funciona IPv4 y sabemos como funciona IPv6, vivimos en un mundo en el que los dos protocolos existen lado a lado e interactúan de maneras inesperadas. Hosts que creen que tienen conectividad IPv6 tratarán de conectarse a servidores que tienen IPv6 en el DNS. Entonces si la conectividad no funciona, nada sucederá  durante un tiempo hasta que la aplicación de un time-out y trate con otra dirección suministrada por el DNS. Si es una dirección IPv4, la conexión va a establecerse sin problemas y todo va a funcionar bien, pero todo luego de un molesto retardo.
Retardos como estos le cuestan a empresas como google bastante dinero, asi que Google renunció a poner las direcciones IPv6 de sus servidores en los DNS. Google solo expone sus direcciones IPv6 a los servidores de DNS de los ISPs participantes del programa "Google sobre Ipv6". De modo que sabemos a donde queremos llegar: a una red completamente habilitada para IPv6, pero llegar ahí requiere torturantes demoras que además generan llamadas a soporte y pérdidas de dinero. Caso contrario la transición requerirá capas adicionales de esfuerzos y complejidad -- imaginen que las 100 caracteristicas web principales requirieran que un ISP manejara su servicio de DNS de la misma manera en que lo hace Google      
El hecho de que IPv6 tiende a deteriorarse en la manera descrita arriba es un resultado directo de crear el protocolo desde cero como un protocolo separado de IPv4. Supongamos que IPv6 fuera un reemplazo compatible con su antecesor, si un paquete tiene una dirección IP fuente de 32 bits y una de destino tambien de 32 bits, podría ser traducido de IPv6 a IPv4 sin pérdida de información. En esta situación, las organizaciones podrían haber elegido reemplazar IPv4 por IPv6 de manera que todo su tráfico fuera IPv6, al menos hasta que abandonara su red y tuviera que ser traducido a IPv4. Así no hubiera existido el "ajusta y olvida" e Ipv6 estaría funcionando porque sería usado para todo. Entonces una vez que suficiente gente estuvieran con IPv6, sería posible usar direcciones de 128 bits.  
Es difícil decir como este enfoque tendría ciertos problemas por si solo, pero de cierto parece que en el esfuerzo de crear un protocolo desde cero la IETF puso a la comunidad en una batalla en un camino cuesta arriba.

Fin del juego: NAT, dificultades P2P y cortafuegos.

Hoy el 99 % de internet todavía es IPv4, y no hay manera de que todo quede habilitado para IPv6 hasta que nos quedemos sin direcciones IPv4 en dos o tres años. Así que debemos poner a IPv4 en alguna clase de vida asistida.
Actualmente para los que tenemos direcciones IPv4 no hay muchos problemas a corto plazo. Lo que sucederá es que ya no habrá direcciones para los usuarios nuevos en algunos años más. Pero es obvio que servirle solo a usuarios existentes sin la posibilidad de crecer es algo que no cuadra con los negocios. Así que la solución es que los usuarios compartan direcciones IPv4. De hecho es lo que hace la gente actualmente en los hogares usando NAT  lo que hace posible que toda la casa esté en línea usando solo una dirección IP. Pero estos niveles de frugalidad no serán suficientes, los ISPs pronto estarán usando NAT para que varios clientes compartan una misma IP.
Desde el punto de vista de la arquitectura NAT no es algo bueno. Deshecha todo tipo de supuestos en los protocolos para favorecer a las aplicaciones. Esto es especialmente cierto para aplicaciones P2P como BitTorrent, pero tambien para VoIP (incluido Skype). De todas maneras a través de los años, los desarrolladores de aplicaciones han encontrado modos de evadir los problemas de NAT. Uno de los métodos supone negociar con el gateway de casa que ejecuta el NAT para que acceda a redireccionar las conexiones entrantes usando un protocolo de mapeo de puertos. Esto funciona muy bien cuando hablamos del NAT de la casa, pero no es así para los ISPs que manejan NAT mucho mayores. No solo los diferentes usuarios competirán por el mejor número de puerto, sino que además los protocolos más comunes de mapeo de puertos (UPnP IGD and NAT-PMP) no pueden hablarle a un NAT que esta a varios hops de distancia. 
Hacer que las aplicaciones P2P funcionen bien puede no ser una prioridad para los ISPs, los cuales tienden a estar en en negocio de distribución de contenidos en video o de llamadas de voz. Peor aún, los ISps que proporcionan NAT en realidad rompen los mecanismos de túneles IPv6 que permiten a la gente ganar conectividad IPv6 si su ISP no la proporciona. Y desplegar estos nuevos equipos de NAT  caros y complejos podría requerir recursos que de otro modo serían empleados para implementar IPv6 en la red.

Cortafuegos.

A principo de esta década, Windows venía con muchos protocolos inseguros habilitados por defecto y un efecto colateral no intencional de NAT -- el servicio prevenía a las máquinas detrás de la IP compartida (adentro) de recibir conexiones entrantes -- en realidad se convirtió en una característica comercializable en los routers caseros. Pero como que IPv6 no necesita de NAT, los routers NAT deben crear el mismo efecto de cortafuegos usando cortafuegos sin estado (stateless).          
Ahora, NAT solo impedía las conexiones entrantes por accidente, de modo que las aplicaciones podían evadirlo bastante fácilmente (vean el método de mapeo de puertos mas arriba). Pero los cortafuegos las impiden a propósito así que no es tan fácil evadirlos y no hay mecanismos de mapeo de puertos en IPv6 (no existe NAT ¿recuerdan?). Lo que significa que todos los protocolos P2P como las soluciones VoIP y BitTorrent funcionan peor sobre IPv6 que sobre IPv4. Esta situación probablemente no va a ser resuelta muy pronto que se diga, ya que la gente que tiene que ver con seguridad se rehúsan siquiera a considerar pasar paquetes entrantes no solicitados en cualquier manera o forma.

NAT IPv6

Mientras tanto, hay discusiones acaloradas dentro de la IETF, sobre si es correcto definir la temida NAT IPv6. El argumento en su contra es del tipo disgusto arquitectónico. (La IETF también se opuso al principio a la especificación del NAT IPv4). Pero el argumento a su favor es que un NAT IPv6 bien portado, no desgraciaría tanto software como un NAT IPv4 recompilado para direcciones de 128 bits. Lo que origina la mayoría de los problemas con NAT son las direcciones compartidas. Con un NAT IPv6, sería posible crear un mapeo de direcciones 1 a 1 en ves de 1 a varios como lo hace el NAT IPv4. De manera que aún será posible ofuscar una red interna que use direcciones privadas, pero las aplicaciones P2P, si se las permite pasar a través del cortafuegos podrían funcionar con un poco de lógica extra. La falta de un NAT IPv6 es citado como un obstáculo en el despliegue de IPv6 y esto es algo más que hay diferente entre IPv4 e IPv6. Un NAT IPv6 diferente al uno IPv4 en realidad no va a ayudar en esta área. De nuevo, lo único que luce, huele y sabe como IPv4 .... es .... IPv4. En algún momento IPv6 necesitará ser su propio protocolo. 

Plan B.

No hay plan B. A pesar de la larga lista de problemas con IPv6 y su despliegue, no hay alternativas. Nos tomó lo mejor de estas dos décadas llegar tan lejos con IPv6 y no hay manera de ofrecer implementar y desplegar una alternativa antes de que la escases de direcciones IPv4 se convierta en un problema serio. El empleo de direcciones compartidas usando NAT y algunas maneras de redistribución de direcciones IPv4 (hacerlas de pago o algo así) le permitirá a IPv4 continuar operando sin muchos problemas por algunos años más antes del agotamiento de las direcciones libres que restan. Pero actualmente se están concediendo cerca de 200 millones de nuevas direcciones a usuarios cada año. Esto con reglas bastante rígidas sobre a quien se le puede  dar una dirección y bastantes sistemas haciendo NAT. Algunos paises al norte y este de Europa, que no recibieron demasiadas concesiones del espacio de direcciones IPv4 cuando las cosas estaban en calma en los 80's todavía usan mas de una direccion IPv4 por habitante y están aun creciendo un poco. Incluso en EEUU con 1.5 billones de direcciones IPv4 , todavía están concediendo direcciones IPv4 a usuarios cada año.   

Pero no importa como se distribuya el espacio IPv4, no va a sostener una red global en el futuro donde países como China y Brazil, están avanzando rápidamente sobre los numerosos países en el mundo en desarrollo que no tienen siquiera nada parecido a una participación justa en las direcciones, al menos todavía. Así que aun cuando todavía estamos tratando de entender la pregunta, la respuesta tendrá que ser IPv6.

Algunas de las limitaciones reales o percibidas de IPv6 están siendo atendidas por la IETF y otras instituciones. Aun cuando todavía hoy el despliegue de IPv6 es muy limitado, ya hay un problema de compatibilidad: las primeras implementaciones de IPv6 no soportan DHCPv6 por ejemplo. Pero la mayoría de los sistemas capaces de soportar IPv6 todavía estan recibiendo actualizaciones (semi) automáticas, así que estos problemas de compatibilidad no serán insuperables en esta ocasión. Tendremos que atravesar por un período en el que IPv4 va a ir de bien a peor, debido a las sucesivas capas de NAT, mientras IPv6 todavía esta en su fase torpe y falto de las capacidades secundarias o de la compatibilidad sencilla a la que nos acostumbramos mientras crecíamos con IPv4. Y puede que haya sistemas solo IPv4 y sistemas solo IPv6. Aun cuando la transición no va a ser tan fácil como esperabamos, acabaremos con una Internet mas estable y fuerte, con un potencial infinito para el crecimiento luego de la transición. Solo si nos aseguramos que existe un camino para ir desde aquí hacia allá.

Lecturas adicionales:

Notas finales:

Como siempre les recomiendo (hablando de redes) que vayan a donde están todas las definiciones como Dios manda:
Hasta aquí el artículo, esta bastante largo así que márquenlo, les será útil mas adelante.
Provecho.