Algo parece moverse estos días en Internet, cada vez son más voces las que aseguran que la IANA (ver en el artículo el papel que desempeña si alguien quiere más datos) agotará todas las direcciones IPv4 hoy. Sí, hoy. Si los datos de Hurricane Electric son ciertos, en el momento de estar escribiendo estas letras tan solo quedarían en manos de la IANA unas 7.000.000 de direcciones IPv4.  ¿Que quiere decir esto? Bueno primero una pequeña introducción y algunos test para verificar si podemos o no alcanzar un host IPv6

 

  • La realidad sobre IPv4 e IPv6
  • Como nos afecta
  • Sistemas de transición
    • Pila doble
    • Servidores Proxy
    • Túneles (automáticos y configurados)
      • Teredo
      • ISATAP
      • 6to4
      • 6in4


¿Estas preparado para IPv6? Compruébalo

Test 1 -> Red IPv6 sin registro A, tan solo AAAA

http://ipv6.google.com ¿Se abre?
http://ipv6.whatismyv6.com ¿Se abre, aparece tu IPv6?

Test 2 -> Red IPv6 con registros tanto A como AAAA, que IP se usa por defecto en un host con los dos registros DNS (A y AAAA)

http://whatismyv6.com/ ¿Que IP detecta, IPv4 o IPv6?

Test 3 -> Red IPv6 accedida directamente por su IP (ipv6.google.com)

http://[2a00:1450:8002::69] ¿Logras acceder?


Test 4 -> Información sobre la IPv6 (o la no IPv6) que tenemos:

http://test-ipv6.com ¿Tienes una dirección IPv6? Teredo, un tunel configurado, 6to4, 6rd, nativa…

 

Y ahora al lío

Bueno, en el artículo sobre el protocolo IP (IPv4 e IPv6) se explicaba a groso modo el problema, y este artículo es una ampliación específica sobre IPv6 y el estado actual del “problema” o el “no problema” de IPv4. Señores, no es un mito, la IANA posiblemente agotará todas las direcciones IP en unos días, da igual que sean 2 o que sean 10. Es una realidad. El protocolo IPv4 usa direcciones con una longitud de 32 bits, lo cual quiere decir que en el mejor de los casos se tendrían 2^32 direcciones, lo que hace un total teórico de algo más de 4 mil millones de direcciones IPv4, y estas se han acabado, aunque más correcto sería decir que la IANA en unos días entregará el último paquete de IPs. Y digo que es más correcto porque ni hay que ser alarmistas ni hay que contar la verdad a media.

Como se habló en el primer artículo citado, la IANA se encarga de repartir las direcciones IP, o mejor dicho gestionarlas. En realidad la IANA no asigna individualmente ninguna IP, todo forma parte de una estructura jerárquica. La IANA gestiona por así decirlo los bloques de IP que asigna a sus diferentes RIR. Los RIR podrían verse como las autoridades intermedias en la gestión de las IPs (RIPE NCC, ARIN, AfriNIC, APNIC y LACNIC), cada uno de ellos gestiona de manera global los diferentes bloques de IPs asignados a ellos en diferentes zonas geográficas, por ejemplo AfriNIC gestiona todas las IPs africanas mientras que RIPE NCC se encarga de toda Europa y gran parte de Asia. Pero del mismo modo que la IANA no asigna individualmente las IPs, el papel de los RIR tampoco es ese exactamente, estos a su vez se encargan de gestionar los bloques de IPs de los ISP o en algunos casos de los NIR (Agentes registradores Nacionales). Prácticamente la totalidad de las IPs que son asignadas lo son el última instancia por nuestros ISP: Telefónica, ONO, Jazztell…

Si esto se ha entendido bien, creo que queda patente la gran diferencia en decir que se han agotado las direcciones IPv4 a decir que se han agotado las direcciones IPv4 de la IANA. Esto quiere decir que aun pasará mucho tiempo en el que IPv4 será el protocolo principal de Internet. Aun cuando dentro de unos días la IANA agote el Pool de IPv4, los RIR continuarán durante algún tiempo con un buen Pool remanente, que por supuesto se irá agotando poco a poco. Pero aun hay más, puesto que los ISP a su vez poseen sus propios pool de IP con el que satisfacen sus necesidades aun por mucho tiempo. Según los últimos datos de Hurricane Electric, RIPE NCC tendría disponibles algo más de 270.000, unas 200.000 LACNIC, 500.000 ARIN, 300.000 APNIC y 200.000 AfriNIC. OJO!! no son direcciones IP, serían bloques de redes /24, es decir, para calcular el número total de IPs se debería de multiplicar dicho número por 256

Hay que ser sensato, es cierto que es noticia que la IANA agote definitivamente las direcciones IPv4, pero tampoco significa que dentro de 2 días todos tengamos que estar usando IPv6 ni muchísimo menos. Si es cierto que posiblemente este agotamiento empiece a ser motivo para que los ISP terminen de adaptar todas sus infraestructuras y su hardware para IPv6, e incluso comiencen poco a poco a migrar o convivir tanto con IPv4 como con IPv6. Y este es en realidad el problema para el usuario final.

A día de hoy, la mayoría de todo el hardware y software que existe en el mercado es 100% compatible con IPv6 e incluso con tecnologías de transición IPv4 -> IPv6. Por ejemplo, dentro del software, Windows es compatible con IPv6 desde XP, y Windows 7 por defecto tiene habilitado Teredo (más adelante se hablará de ello). Firefox es compatible con IPv6 casi desde sus primeras versiones y posiblemente nadie siquiera tenía constancia de ello. Pero dentro del equipamiento doméstico, os digo que muchos de los routers y dispositivos que los usuarios tienen en sus hogares están preparados para IPv6 y muchos de ellos con la tecnología necesaria para permitir una transición sin molestias. Si los ISP van realizando progresivamente los cambios necesarios en equipamiento y software, es muy posible que la mayoría de los usuarios tan solo vean IPv6 como pequeñas notas de prensa q poco a poco irán apareciendo y que poco o nada se enterarán de que ha sucedido realmente. Hay que tener bien presente de que un dispositivo o software sea compatible con IPv6 no implica que sea compatible con alguno o todos de sus sistemas de transición.

El problema realmente aparece no en una red formada íntegramente por IPv4 o por IPv6, sino en el tiempo (que se augura relativamente largo) en el que ambos protocolos tendrán que convivir. Sin más tecnologías, un host IPv6 no puede comunicarse con otro IPv4 de ninguna forma (y viceversa), y es por ello por lo que existen desde un principio varias tecnologías que permiten la interoperatividad entre ambos, es decir, que un host IPv4 pueda comunicarse con un host IPv6 y al revés. Personalmente imagino, que la primera fase llegará poco a poco, en la que cada vez más portales, empresas y servicios de peso vayan suprimiendo IPv4 en pos de IPv6 y que nuestros equipos vayan usando estas diferentes tecnologías (mientras que los ISP hacen la migración completa) para poder comunicarse con ellos. La fase 2 llegará en el momento en el que IPv6 será tan usado o más que IPv4 y que nuestros propios equipos comenzarán a usar direcciones nativas IPv6, lo cual no significa que ya podamos prescindir de las tecnologías de transición, puesto que nuestro equipo tendrá que poder comunicarse entonces con los hosts aun en IPv4. Solo mucho tiempo después, cuando IPv6 sea el 100% casi en su totalidad podrá empezar a suprimirse IPv4 o de sus sistemas de transición. No hablo de un período de transición de un año, ojo, hablamos de que IPv4 e IPv6 convivirán durante muchos muchos años, 30 años? 40 años? posiblemente muchos de nosotros no vivamos lo suficiente para ver como IPv4 desaparece de forma completa.

Como digo, el problema reside sobre todo en los diferentes sistemas de transición, que en realidad si los ISP lo quieren hacer bien no tiene porque afectar lo más mínimo a los usuarios (o al menos en muy poco). Como de preparados están los ISP españoles? Bueno, es complicado saberlo a ciencia exacta, pero podemos al menos ir tanteando. Por ejemplo, comprobando sus servidores de DNS, que sería de los primeros pasos que deberían de dar. ¿Que quiere decir esto?

Como se hablo en el artículo anteriormente indicado (en protocolo DNS), los equipos requieren de servidores DNS para traducir los nombres de dominio en las IPs. Por ejemplo, Google.es posee la dirección IPv4 209.85.146.103. Esto quiere decir que cuando en el navegador indicamos que queremos visitar la web “google.es” nuestro navegador consulta la IP de dicho hosts, y nuestros servidores de DNS nos responderán con la dirección asociada. Pues bien, IPv6 funciona exactamente igual, con la salvedad de que los servidores DNS al igual que contienen en sus bases de datos los registros llamados “A” (Los registros A contienen la IPv4 del host asociado) deben de contener el registro específico para las direcciones IPv6, en este caso se conocen como registros “AAAA”. Si los servidores DNS de nuestros ISP no se encuentran ya preparados para IPv6, no podremos de ninguna manera visitar ninguna web ni acceder a ningún servicio por su nombre de dominio!! Es decir, jamás podremos acceder a la web http://ipv6.google.com si colocamos dicha dirección en nuestro navegador, con total independencia de que sistema usemos para navegar por redes IPv6. ¿Por qué? Si intentamos acceder a un servicio (web, correo…) que sea puramente IPv6, jamás obtendremos una IP asociada a dicho dominio, y por tanto será imposible acceder.

Lo gracioso es que a día de hoy se supondría que TODOS los ISP tienen al menos sus servidores de DNS actualizados con IPv6, pero no es así. A día de 01 de febrero de 2011, he verificado uno a uno todos los servidores DNS de los ISP españoles usando dig para consultarlos. El proceso es simple, con dig he realizado peticiones a cada uno de los servidores de DNS preguntado por el registro AAAA del host ipv6.google.com. Se han comprobado los siguientes ISPs:

Arrakis, Arsys, Comunitel, Euskaltel, Jazztel,  ONO, OpenForYou, Orange, Tele2, Tele2 – Comunitel, Telefónica (Telefonica, Terra…), Uni 2, Vodafone y Ya.com.

De todos ellos, podemos decir que tienen sus servidores de DNS preparados para IPv6: Orange, Telefónica, Tele2 – Comunitel, Uni 2, Vodafone y Ya.com, todos ellos resolvieron correctamente la IPv6 del host indicado.  Operadores mayoritarios como Jazztel e incluso ONO suspenden.

 

¿Que tipo de redes vamos a encontrar a partir de ahora (y hace ya tiempo) hasta posiblemente muchos años? Vamos a ver las diferentes opciones mayoritarias con las que nos vamos a encontrar y que necesitaremos para poder navegar por cualquiera de ellas. Microsoft tiene publicado un documento que explica bastante bien todo ello, aunque evidentemente orientado todo a Windows, pero no deja de ser interesante, lo dejo aqui: Microsft IPv6

 

- Redes puras IPv6:

Este será el objetivo final a alcanzar. Posiblemente para llegar a este punto aun tenga que pasar mucho tiempo para los usuarios domésticos, pero en cambio ya existen y funcionan a la perfección redes íntegras en IPv6. Evidentemente este tipo de redes las encontramos ahora mismo en dos lugares fundamentales: Redes privadas que no intercambian información al exterior por medio de IPv6 ó grandes empresas como por ejemplo Google y otros que desde hace ya tiempo mantienen IPv6 para experimentos y transición paulatina, los cuales además permiten sistemas de transición para poder acceder a sus redes IPv6.

El problema es que actualmente la penetración de IPv6 es mínima, aunque es de esperar que cuanto más avance el tiempo el avance sea exponencial.

Cual es la ventaja? Que prácticamente el 100% del software y equipamiento actual de todos los usuarios (desde routers, dispositivos portátiles, navegadores, sistemas operativos….) son completamente compatibles con IPv6, simplemente tienen que implementar el stack IPv6 en vez del Stack IP4. Y como he dicho, que sea compatible con IPv6 no significa que sean compatibles con sistemas de transición. Actualmente no se me ocurre ningún dispositivo no compatible con IPv6 nativo

 

- Doble Stack (Pila) IP

Este sistema de transición es prácticamente obligado. Dado que ambos protocolos van a tener que convivir durante un tiempo, parece lógico pensar que todos los dispositivos tendrán que tener implementado tanto la pila de protocolos IPv4 como IPv6. Visto desde un punto práctico, básicamente podemos decir que nuestros dispositivos tendrán por así decirlo en todo momento dos IPs, una IPv4 y otra IPv6, lo cual pare obvio. De este modo, en un mundo ideal por supuesto, si quisiésemos conectar a una red IPv4 se usaría nuestra IPv4 y si fuese una red IPv6 se usaría la IPv6.

Evidentemente esto no es tan simple, dado que como hemos dicho prácticamente todas las redes son IPv4, con lo que si intentásemos acceder a cualquier red con nuestra IPv6 tal cual, posiblemente nuestra petición no pasase siquiera de nuestro router, que ya ni siquiera hablar de la red de nuestro ISP. En cambio, es evidente que es un requisito prácticamente indispensable, sobre todo para uso interno de nuestros propios dispositivos, para los programadores, para nuestra propia red interna…

¿La ventaja? La mayoría de todos los dispositivos pueden en el peor de los casos generar su IPv6 a partir de su IPv4, lo cual es tremendamente útil como hemos dicho de cara al software y al propio sistema. Este proceso es prácticamente inmediato, básicamente se incrusta la dirección IPv4 en la siguiente plantilla IPv6: “::FFFF:0:0/96″ Recordar que el 96 establece por así decirlo los valores fijos, es decir, de los 128 bits de una dirección IPv6 tan solo quedan “libres” 32 bits, que es lo que ocupa precisamente una dirección IPv4. Por ejemplo, la direccion IPv4: 192.168.100.32 se mapearía como ::ffff:c0a8:6420. Lo no0rmal no obstante es usar una notación más inteligible: ::ffff:192.168.100.32

Prácticamente todos los dispositivos actuales usan sistemas de doble pila IP por defecto, aun cuando tan solo es visible de forma simple la IPv4, abría que ir buscando uno a uno a ver cuales sí o cuales no. Cualquier usuario de Windows puede por ejemplo escribir en la linea de comandos: ipconfig y con toda seguridad comprobará que tiene una IPv6 asignada, posiblemente no coincidente con la IP explicada más arriba, pero eso es porque Microsoft usa sistemas de transición de los que ahora hablaremos.

Actualmente todos los dispositivos compatible con IPv6 nativo estoy casi convencido que serán compatibles con esta tecnología


– Proxys

Como solución temporal, siempre dispondremos de servidores proxy que puedan enviar y recibir tráfico tanto en IPv4 como IPv6. Nuestros dispositivos se podrán conectar a estos y serán estos los que se conecten indistintamente a redes IPv6 o IPv4, del mismo modo que nosotros podremos conectarnos a ellos por cualquiera de los dos métodos.

La ventaja de estos sistemas es evidente, no se requiere absolutamente de nada, tan solo de especificar para la navegación un servidor proxy.

En cambio las desventajas son incontables. Primero la navegación será siempre bastante más lenta, la privacidad sería inexistente y posiblemente tampoco sea una alternativa viable para otros servicios que excedan el ámbito de la navegación, los gestores de correos y alguna decena más.

Todos los dispositivos deberían de ser compatible con esta tecnología

 

- Túneles

Es aquí donde reside la gran carga que durante muchos muchos años vamos a usar para una buena conexión. La idea es simple, que cualquier dispositivo o infraestructura que no ha migrado a IPv6 se pueda comunicar con dichas redes. Por un lado existe el problema de que aun cuando nuestro dispositivo tenga correctamente una IPv6 asociada y teóricamente pueda conectarse a un equipo IPv6, antes de poder llegar a dicha red IPv6 posiblemente, casi con toda seguridad tenga q cruzar por redes IPv4, con lo que la comunicación sería imposible.

Lo que se realiza es un tuenel IP. Para comunicarnos con un equipo IPv6 necesitamos una IPv6. Este paquete IPv6 se encapsula a su vez dentro de un paquete IPv4, siendo el paquete IPv6 el payload del paquete IPv4. Si recordamos, la cabecera IPv4 tiene un campo que especifica el protocolo que contiene el payload de este, y en este caso no se especificará un payload TCP o UDP, sino un payload llamado “Encapsulamiento de IPv6″, en muchos sitios viene tipificado como protocolo 41. En realidad ese 41 es el código que identifica el nombre del protocolo antes citado, igual que el tipo 6 es el protocolo TCP. En realidad, los túneles citados no tiene por qué usar el protocolo 41, pero dado que está para eso lo más normal es que así sea.

Existen dos tipos de túneles para todo esto, los túneles automáticos y los de configuración manual. Los túneles automáticos son aquellos que no requieren ningún tipo de configuración en ambos extremos, tan solo en todo caso de lado del cliente. Por otro lado, los túneles de configuración manual requieren una configuración en ambos extremos. Esto se comprenderá bien a continuación, veamos los sistemas de túneles más comunes usados.

El problema aquí es la compatibilidad hardware y software. Actualmente los equipos Windows y Linux son con mucha diferencia los equipos mejor preparados de cara a estos túneles, prácticamente compatible con todos los sistemas existentes sin tener siquiera que configurar nada. MAC OS aprueba, aunque no es tan inmediato como Windows o Linux, y tocará configurar a mano en varias ocasiones, por no decir que el soporte de Teredo que poseen es cuanto menos pobre y deficiente. Pero no hay que tener en cuenta tan solo los equipos de sobremesa, con el boom de los dispositivos portátiles es igualmente importante conocer la compatibilidad de nuestros dispositivos. De nuevo en este punto, y aunque me cueste reconocerlo, los dispositivos Windows Mobile son los mejor preparados, compatibles de nuevo prácticamente con todos los estándares existentes. Después de estos tendríamos a los dispositivos Android que tan solo fallarían en que no disponen de soporte para Teredo (aunque posiblemente existan ya modulos compilados para dotarlos), y en último lugar tendríamos a BlackBerry. Sí, no he nombrado a iPhone OS por una sencilla razón… el software de Apple para sus dispositivos portátiles (iPad, iPhone, iPod Touch) tan solo es compatible con iPv6 NATIVO a partir de iPhone OS 4.x (el resto de los dispositivos ni siquiera tendrán soporte para IPv6), pero incluso los dispositivos más actuales con el software más actual, no son compatibles con ningún tipo de túneles!! ni Teredo, ni 6to4, ni túneles configurados… nada.

 

  • Teredo

    Es la solución que Microsoft dio para Windows como primera opción simple. La idea de Teredo es la misma que otros túneles, permitir encapsular los paquetes IPv6 dentro de IPv4 de una forma simple y eficiente. Realmente funciona muy bien, cualquier equipo actualmente con Windows 7 tiene habilitado Teredo por defecto, esto quiere decir que puede comunicarse tal cual on cualquier hosts IPv6. Windows Vista también está equipado con Teredo, pero a diferencia de Windows 7, en Vista hay que habilitarlo y en XP instalarlo desde la configuración del adaptador. Así nuestros equipos se denominan como Clientes Teredo, mientras que los extremos fianles del tuenel se conocen como sistemas Teredo Relay. El papel de estos equipos/sistemas Teredo es evidente, extraer del mensaje UDP el paquete IPv6 y enrutar este a su destino final dentro de la red IPv6 que sea. También existen otros nodos llamados Teredo Server, que se encargan básicamente en establecer y mantener los túneles. Todo esto parece genial, pero hay algunos peros.

    Las ventajas de usar Teredo son varias. Por un lado, es un túnel automático, lo cual simplifica la labor de cara al usuario. Por otro lado, permite que los dispositivos puedan directamente comunicarse con el exterior sin tener que preocuparse por ningun router que pueda usar un Firewall. Para ello, en vez de encapsular el tráfico como protocolo 41 dentro de IPv4, lo hace encapsulándolo dentro de un mensaje UDP. Es decir, encapsula un paquete IPv6 dentro de UDP, este a su vez dentro de IPv4. El problema no es que los Firewall no filtren los mensajes UDP, sino que el firewall que posiblemente sea un dispositivo NAT no tendrá problema alguno para mapear correctamente los paquetes en nuesetra red, mientras que muchos dispositivos NAT/Firewall si podrían tener problemas por defecto cuando se encapsula el tráfico como protocolo 41. No obstante, Microsoft advierte que aquellos dispositivos NAT que actúen como NAT Simétrico pueden no ser compatibles. Teredo también usa UPnP para asegurarse el poder atravesar la mayoría de los routers domésticos.

    Pero Teredo no es quizás la mejor solución . Teredo por diseño funciona bien siempre que se realicen conexiones especificando la IP. Digamos que Microsoft no ha diseñado Teredo (no ha querido) que sea capaz de resolver ninguna dirección IPv6. ¿Que quiere decir esto? Que si cualquier equipo con Windows 7 intenta visitar la url iPv6 de Google: http://ipv6.google.com no podrá. En realidad el equipo puede conectarse, pero no será capaz de resolver la dirección IPv6 de dicho host (con total independencia del ISP que use). Se puede imaginar que la idea original de Microsft con Teredo era la conexión directa de equipos y/o que fuesen las propias aplicaciones quienes usasen Teredo, excluyendo evidentemente a navegadores de dichas aplicaciones (recordemos que navegar por la web no es todo lo que se puede hacer), aunque no me extrañaría que en futuras versiones o Service Packs este comportamiento fuese modificado. Esto no quiere decir que Teredo sea completamente inútil (más adelante se muestra como solucionar este problema), incluso cuando esta limitación no se salvaguarde, Teredo da a cualquier aplicación capacidad de IPv6, lo cual no es poca cosa, y por supuesto la siempre opción de poder visitar cualquier hosts especificando directamente su dirección IPv6. Si es cierto que por defecto no es posible alcanzar el host http://ipv6.google.com usando Teredo, si será posible si se accede especificando su IPv6: http://[2a00:1450:8006::68] Evidentemente no es algo práctico si se desea usar IPv6 para navegar

    Se puede saltear la limitación de Microsoft con la resolución de DNS haciendo un poco de trampas. Al margen del uso final que Microsoft quisiese darle a Teredo, es muy posible que la resolución DNS diese algunos problemas al funcionamiento de Teredo (sinceramente desconozco la causa si existió). ¿En que consiste la trampa? Teredo actúa así porque la IP que se asigna por defecto a nuestra interfaz principal (nuestro adaptador físico de red) es una IPv6 Teredo, comienza por 2001. Ojo! me refiero a la IPv6 del adaptador de red principal, no a la IP del adaptador virtual Teredo. Esta IP es la que le dice a Teredo a no realizar las resoluciones DNS, ¿pero que sucede si modificamos la IPv6 de nuestro adaptador de red por una que sea de tipo 6to4? Luego veremos que es 6to4, pero quitando eso, las IPs de 6to4 comienzan por 2002, y dado que la IPv6 que nuestro equipo enviará encapsulada en mensajes UDP es realmente la que posee la interfaz Teredo y no la de nuestro adaptador de red, si asignamos una IPv6 estática a nuestro dispositivo de red por uan de tipo 6to4 ya tendremos resoluciones DNS para equipos IPv4. Esto es tan simple como acceder al centro de redes y recursos compartidos, acceder a las opciones de nuestro adaptador de red, acceder a los ajustes de IPv6 y establecer la IP 6to4 que queramos (comenzando siempre por 2002), por ejemplo 2002:c0a8:A08:: y una máscara de 48 (Ojo! no hay que especificar una puerta de enlace). Una vez se realiza esta trampa, el sistema elimina de la tabla de ruta la entrada que establece que todo el tráfico IPv6 se envíe por el adaptador Teredo, con lo que hay que crearla de nuevo. La forma más simples es por medio del siguiente comando:

    netsh interface ipv6 add route ::/0 “NOMBRE_DE_LA_INTERFAZ_TEREDO”

    El nombre de la interfaz teredo suele ser “Teredo Tunneling Pseudo-Interface”, pero si se quiere estar completamente seguro se puede realizar antes lo siguiente:

    C:\Users\Theliel>netsh interface ipv6 show interface

    Índ     Mét         MTU         Estado              Nombre
    —  ———-  ———-  ————  —————————
    1          50  4294967295  connected     Loopback Pseudo-Interface 1
    12          50        1280  disconnected  isatap.{xxxxxxxxxxxxxxxxx}
    11          10        1500  connected     Conexión de área local
    15          50        1280  connected     Teredo Tunneling Pseudo-Interface

    Lo más simple por tanto será copiar el índice de la interfaz teredo (en mi caso el 15) y teclear en vez del comando anterior el siguiente:

    netsh interface ipv6 add route ::/0 interface=15

    Una vez realizados sendos cambios, nuestro equipo será capaz de conectarse a cualquier red IPv6 por medio de Teredo, aun usando sus nombres de dominio.

    Por otro lado, Teredo no se configura como la opción predeterminada, y tan solo será usado en el sistema cuando no exista en dicho host una dirección IPv4. Es decir, Teredo tan solo nos enviará a una red o equipo IPv6 cuando dicho equipo/host no disponga de una dirección IPv4. La mayoría de los hosts actuales migrados a IPv6 cuentan tanto con registros A como AAAA, con lo que pueden ser accedidos tanto por redes IPv4 como redes IPv6. Pues bien, en este caso Teredo nunca accederá a ellas por medio de IPv6, sino se usará el direccionamiento IPv4 estándar.

    Como último problema o mejor dicho contra que posee Teredo es que no está diseñado para dotar a una red con conectividad IPv6. Es decir, Teredo, una vez se aplica la pequeña trampa para resolver direcciones IPv6, es muy eficaz para dotar a cualquier equipo de usuario con conectividad para redes IPv6, pero nada más, es una solución para extremos, no redes. Es decir, si en nuestra casa disponemos de 10 dispositivos entre los que se encuentran 3 teléfonos Android, 4 equipos Windows 7 1 iPhone y 1 Linux, si queremos dotar a cada uno de ellos tendríamos que instalar (si fuese posible) Teredo en cada uno de ellos. Esto evidentemente no es la mejor opción.

    Veamos una conexión a ipv6.google.com por medio de Teredo en WireShark:

    El proceso de encapsulación de Teredo


    Como se puede ver, el paquete IPv4 parte del Host Theliel hacia una dirección IP que NO corresponde a la dirección IP de IPv6.google.com, que será el servidor Teredo al que estamos conectados, que será quien establezca y mantenga el Túnel. Dentro de este paquete IPv4 podemos observar como el contenido no es más que un mensaje UDP, pero dado que Wireshark lo reconoce como Teredo, es capaz de interpretar lo que hay dentro de este, y no es más que un paquete IPv6, el cual posee la dirección IPv6 del equipo Theliel, y destinado a la dirección IPv6 del host destino, en este caso sí el host ipv6.google.com.

    Como hemos dicho, Teredo usa paquetes UDP, si esto no fuesen “abiertos”, de cara a un ojo indiscreto no serían más que datos enviados a un servidor remoto sin mucho significado. En la siguiente imagen se puede apreciar tanto la petición DNS al servidor IPv6 como los paquetes IPv4 sin interpretar y en verde los paquetes IPv6 una vez se les quita el “envoltorio”

    Por razones evidente hay datos que he suprimido. Es simple, Teredo realiza una conexión a un Servidor Teredo. Este a su vez crea un túnel entre nuestro equipo y el Servidor Relay que estima, y este será quien envíe nuestros paquetes IPv6 al destino, el destino al servidor Relay y este a nosotros en forma de IPv4, y nuestro equipo extraerá de estos el paquete IPv6 y los datos.


  • ISATAP

    No puedo decir mucho de este protocolo creado por Microsoft. Realmente no lo conozco, tan solo puedo decir que es un protocolo orientado a la conexión y descubrimiento de equipos conectados a una misma red, por ejemplo Ethernet. Posiblemente sea un protocolo de apoyo de Microsoft, desconozco sinceramente el objetivo de este, pero no deja de ser un protocolo de túnel automático para IPv6, y por eso hay que nombrarlo


  • 6to4

    Posiblemente el protocolo de Túnel automático IPv6 más importante, dado su uso extenso. En realidad su funcionamiento es muy similar al de Teredo, y fundamentalmente realiza lo mismo, encapsular un paquete IPv6 dentro de otro paquete IPv4. En este caso, no será encapsulado dentro de mensaje UDP, sino que se usará el protocolo 41 que ya se citó. Por otro lado también se trata de un Túnel autoconfigurado, con lo que no requiere de ningún tipo de configuración en ambos extremos. En 6to4 encontramos dos tipos de nodos diferentes, los routers 6to4 y los 6to4 relay. Los primeros actuarían de puntos de entrada/salida de las redes “aisladas”, mientras que los segundos serían necesarios para redirigir el tráfico dentro de Internet IPv6.

    6to4 sin embargo no está pensado como sistema de transición para hosts, sino más bien para dotar a redes IPv4 completas de soporte necesario para poder alcanzar redes IPv6. Por supuesto esto no quiere decir que no se pueda usar 6to4 tan solo para un host. Es por ello que posiblemente alcance una importancia mucho mayor a la que pueda tener Teredo, sin contar por supuesto que el soporte para 6to4 es mucho más extenso que el de este. Visto esto las ventajas son claras, si disponemos de un router que sea compatible con 6to4 podremos dotar a toda nuestra red con la tecnología necesaria para poder como hemos dicho alcanzar redes IPv6, sin preocuparnos de ningún tipo de configuración por parte de ningún dispositivo “anclado” a dicha red. A diferencia de Teredo, a un solo enlace 6to4 (por así decirlo) se le asigna no una IPv6, sino un bloque de estas!! Esto quiere decir que si dicho dispositivo es un router puede asignar IPv6 de dicho bloque a cada uno de los equipos conectados a él, y si es un equipo dicho equipo podría optar por cualquiera de dicho bloque. Como ya se dijo, las IPv6 que identifican 6to4 son las que corresponden a 2002::/16, es decir, comienzan por 2002 (Teredo era 2001::/16). La posibilidad de dotar a un router o toda una red de conectividad IPv6, aparece la necesidad de lo que se conoce como mensajes RA (Router Advertisement), que son básicamente mensajes que envía el router a los dispositivos conectados para poder indicar a estos que existe un router ipv6 que los va a configurar para dotarlos de conectividad por medio de 6to4. Son algo así como un chivato.

    Otra gran ventaja es la resolución DNS, en el que podemos estar tranquilos, ya que no existirá problema alguno en esta, al contrario de lo que sucedía en Teredo, que era necesario hacer un poco de trampas para que usando Teredo pudiésemos resolver DNS.

    Por último y no menos importante, es que mientras que con Teredo era esta la interfaz virtual que “enviaba” los paquetes IPv6, con 6to4 es nuestra propia interfaz de red física la que lo hace. Evidentemente en Terdo los datos salían de nuestro adaptador físico, pero no me refiero a ello, con 6to4 desde el punto de vista del sistema todo es gestionado directamente por la doble pila de protocolos IPv4 e IPv6 de nuestro adaptador de red. Esto es importante a la hora de verificar o incluso aprender cualquier aspecto de IPv6. Toda la comunicación que haga nuestro equipo cuando esté conectando a otro equipo IPv6 hasta el router 6to4 será como si fuese una comunicación real por una red IPv6, lo que sucede es que será el router quien una vez llegado a este encapsulará dichos datos en un paquete IPv4. Evidentemente la comunicación a cualquier host IPv4 se realizará dentro de nuestra propia red sobre IPv4.

    Evidentemente no todo es positivo, y dado que son sistemas de transición, todo siempre tiene sus desventajas. Principalmente dentro de 6to4 es la necesidad de un hardware compatible, no solo que los clientes lo sean. En el caso de Teredo no hacía falta ningún tipo de soporte hardware específico ya que Teredo era aplicado directamente a los equipos, y estos por medio de UPnP, UDP y otros, eran independientes al router o puerta de enlace utilizados. Aquí se continúa necesitando el soporte por parte de los clientes (nuestros equipos tienen que ser compatibles con 6to4) pero además, nuestra red y más exactamente nuestro router tiene que ser capaz de esta tecnología. La mayoría de Routers decentes del mercado lo son desde hace tiempo, pero es cierto que la mayoría de los routers domésticos (esas puertas de enlace residenciales) no lo son, al menos nada más sacados de caja. En cuanto al soporte Software importa menos, prácticamente todos los dispositivos actuales son compatibles completamente con IPv6 6to4, es de todas las tecnologías que veremos la más aceptada, la más usada y la más compatible a día de hoy. De echo, creo que actualmente tan solo iPhone OS (iphone, ipad, ipod touch) es el único sistema operativo que no es compatible con 6to4. En realidad, iPhone OS no es compatible con ninguna tecnología de Túnel, lo cual quiere decir que estos dispositivos no podrán acceder a ninguna red IPv6 ni alcanzar ningún host ipv6 (que se espera que comiencen a aparecer de forma masiva a mediados finales de años) a menos que la red a la que se conecte (sea 3G o WIFI) sea una red IPv6 nativa (lo cual posiblemente no suceda de modo alguno a corto plazo).

    También hay que tener en cuenta que si se usa 6to4 para conectar directamente un host (sin usar un router) habrá que asegurarse que si estamos detrás de algún router/firewall el tráfico para el protocolo 41 esté permitido, y asegurarnos a sí mismo que NAT no es un problema.

    La configuración a nivel de Router de 6to4 depende evidentemente de este. Cualquier router con sistema linux debería de ser en teoría capaz de realizar estas operaciones, lo que no quiere decir que los fabricantes hallan pensado en ello. Muchos routers se limitarán tan solo a una opción o dos que indique la activación explícita de IPv6, y dentro de este 6to4. Otros en cambio requerirán a lo mejor de configuraciones más complejas. Todo tiene sus pros y sus contras, como siempre. Aquellos routers que tan solo permitan la activación o desactivación de sus servicios con un simple interruptor, tienen el problema de que son sistemas muy cerrados y que puede servir siempre y cuando el entorno sea siempre el que se pensó. Esto quiere decir que si un administrador de red o cualquier usuario necesita salirse de lo que dicho fabricante entiende como correcto no podrá, y eso puede dejar automáticamente sin conexión a toda la red. Pero en contrapartida, para el usuario medio es más simple tocar un interruptor que preguntarse si funcionará o no correctamente. Por el otro lado tendríamos exactamente lo contrario, los usuarios medios tendrían que buscar la información de configuración en Internet, pero permiten un control perfecto sobre lo que se requiere realizar.

    A continuación expongo un ejemplo de configuración de un router corriendo actualmente la última versión del software DD-WRT, quien no lo conozca es una firmware linux que soporta una gran cantidad de routers diferentes, y aunque no son quizás las firmwares más rapidas que existen, si las más versátiles y potentes. En este caso es necesario dos pequeñas configuraciones. La primera es necesaria para dotar al router con capacidades de RA, es decir, poder enviar mensajes a los otros hosts sobre como deben de configurarse para 6to4. A este servicio se le llama radvd, En segundo lugar es necesario configurar el router para especificar que deseamos habilitar el soporte para 6to4, y todo estará reparado. Por supuesto esta configuración es válida para mí, no quiere decir que para cualquiera lo sea, aun teniendo el mismo router con la misma firmware, cada red y configuración es diferente. Tampoco quiere decir que no le sirva a nadie.

    radvd

    interface br0 {
    MinRtrAdvInterval 30;
    MaxRtrAdvInterval 100;
    AdvLinkMTU 1434;
    AdvSendAdvert on;
    prefix 0:0:0:1::/64 {
    AdvOnLink on;
    AdvAutonomous on;
    AdvValidLifetime 86400;
    AdvPreferredLifetime 86400;
    Base6to4Interface ppp0;
    };
    };

    En realidad es simple. Primero se especifica que radvd se aplicará a la interface de mi router br0. bro es la interfaz puente que une la interfaz eth1 (wifi) con la interfaz vlan1 (mi switch), es decir, radvd se aplicará a todos los equipos conectados a mi router por ethernet o wifi. En segundo/tercer lugar se indica el tiempo en segundo en el que los RA no solicitados se enviarán. Como he dicho antes, radvd es de lo que se encarga, por medio de estos RA desponde a los clientes, pero aun así, también emite cada X tiempo RA para que los nuevos dispositivos puedan encontrar nuestro router. Estos parámetros especifica el tiempo mínimo y el tiempo máximo en segundos. Si el tiempo máximo y minimo son bajos, se generará más trafico en la red pero será más visible para el resto de los equipos, si se extienden sucederá lo contrario.

    Más adelante se especifica el MTU del enlace, y esto es MUY importante!! Como ya se ha dicho en alguna ocasión, un Frame Ethernet puede acarrear un tamaño máximo de 1518 Bytes (siempre que no se usen Jumbo Frames). Esto quiere decir que en teoría la mejor forma de maximizar el rendimiento de una red Ethernet es tener un MTU (Unidad de transmisión máxima) lo más alto posible, en este caso lo máximo serían 1500 Bytes (quitando los 18 Bytes de la cabecera del frame Ethernet), lo cual es por defecto el valor de prácticamente cualquier  Pero las conexiones DSL suelen usar PPPoE, y el protocolo PPPoE añade una cabecera de 8 Bytes, con lo que el MTU máximo para conexiones PPPoE sería de 1492 (que no significa que este valor sera el óptimo, que de echo no lo es). La mayoría de routers establecen el MTU de las conexiones PPPoE como 1492 (muchos no, OJO!! para PPPoE siempre 1492 como máximo). Yo soy uno de esos que usa una conexión DSL por PPPoE, luego mi MTU máximo para IPv4 debe de ser como máximo de 1492, particularmente mi MTU es de 1454 Bytes. ¿Por qué? porque es más eficiente. Las conexiones DSL transmiten los datos en lo que llamamos celdas. Estas celdas tienen un tamaño siempre fijo y obligado de 53 Bytes, 48 Bytes de datos si quitamos cabeceras y otros. Por último, la última celda transferida debe de contener una cola de 8 bytes llamada SAR que permite el correcto en ensamblaje de las celdas. Teniendo todo esto en cuenta, un MTU de 1492 para DSL (que sería un frame completo de 1518 Bytes( serían transmitidas como 31 celdas y 30 Bytes restantes, a los que sumados a los últimos 8 Bytes del SAR dan 38 Bytes. Esto quiere decir que la última celda desperdicia 10 Bytes (cada celda es de 48). Usando un MTU máximo de 1454 tenemos un frame Ethernet máximo de 1480 Bytes, que puede ser transmitido en 30 celdas y 40 Bytes restantes, que sumando los 8 Bytes del SAR nos dan el total exacto de 48 Bytes, que completa exactamente una celda más, sin desperdiciar un solo Byte.

    Según todo lo explicado, si el MTU para IPv4 es de 1454, el MTU optimizado para IPv6 será de 20 Bytes menos. ¿Por qué? Porque no olvidemos que cuando nuestro Frame Ethernet con IPv6 alcance el router, este lo encapsulará dentro de IPv4, con lo que habrá que añadirle a nuestro paquete IPv6 una cabecera IPv4 adicional, lo que son exactamente 20 Bytes, de ahí a usar en mi caso un MTU de 1434 Bytes.

    El resto a tener encuenta es el prefijo usado (prefix) que preconfigura la IPv6 que van a tener nuestros equipos. 0:0:0:1::/64 significa que todas nuestras IPv6 comenzarán con el siguiente formato: 2002:XXYY:ZZ:WW:1, donde XXYYZZWW será nuestra IP pública expresada en hexadecimal. La segunda parte de la IPv6 será derivada de la MAC de cada adaptador Ethernet. Al final también se especifica la interfaz a la cual será aplicado 6to4, en mi caso particular dado que me conecto por medio de PPPoE, mi router crea la interfaz virtual PPP0, que sería la interfaz a la que se le asigna la IP IPv4 pública. Para conexiones que no son PPPoE habría que modificarlo casi con toda seguridad.

    C:\Users\Theliel>ipconfig
    Configuración IP de Windows
    Adaptador de Ethernet Conexión de área local:

    Sufijo DNS específico para la conexión. . :
    Dirección IPv6 . . . . . . . . . . : 2002:5121:911d:1:xxxx:xxxx:xxxx:xxxx
    Dirección IPv6 temporal. . . . . . : 2002:5121:911d:1:yyyy:yyyy:yyyy:yyyy
    Vínculo: dirección IPv6 local. . . : fe80::xxxx:xxxx:xxxx:xxxx%11
    Dirección IPv4. . . . . . . . . . . . . . : 192.168.10.25
    Máscara de subred . . . . . . . . . . . . : 255.255.255.0
    Puerta de enlace predeterminada . . . . . : fe80::xxx:xxxx:xxxx:xxxx%11
    192.168.10.1

    Veamos una imagen en Wireshark que nos muestra el correcto funcionamiento de radvd y los RA enviados por el router. A destacar el uso de la dirección ff02::1 y ff02::16, direcciones multicast dentro de IPv6, ya que IPv6 no posee direcciones de broadcast.

    Con esto, el demonio radvd será capaz de configurar cualquier equipo compatible con 6to4, ya que estará enviando sus RA a los intervalos especificados, con el prefijo necesario para que cada equipo se autoconfigure sin problema alguno. Ahora tan solo quedaría en mi caso unos ajustes dentro del router, un pequeño script:

    insmod /lib/modules/`uname -r`/kernel/net/ipv6/sit.ko
    sleep 2
    radvd -C /tmp/radvd.conf start
    sleep 2
    WANIP=$(ip -4 addr show dev ppp0 | grep ‘inet ‘ | awk ‘{print $2}’ | cut -d/ -f1)
    if [ -n "$WANIP" ]
    then
    V6PREFIX=$(printf ‘2002:%02x%02x:%02x%02x’ $(echo $WANIP | tr . ‘ ‘))
    ip tunnel add tun6to4 mode sit ttl 255 remote any local $WANIP
    ip link set tun6to4 mtu 1434
    ip link set tun6to4 up
    ip addr add $V6PREFIX:0::1/16 dev tun6to4
    ip addr add $V6PREFIX:1::1/64 dev br0
    ip -6 route add 2000::/3 via ::192.88.99.1 dev tun6to4
    kill -HUP $(cat /var/run/radvd.pid)
    fi
    sleep 10
    radvd -C /tmp/radvd.conf start

    En realidad no es complicado de comprender el Script. Primero se carga el módulo sit.ko que dotará al router con las herramientas necesarias, después se ejecutará el demonio radvd con nuestros ajustes ya especificados, se obtendrá la dirección IPv4 pública para poder así conformar el prefijo IPv6 y se comenzará a añadir todas las interfaces necesarias para 6to4: El tunel 6to4, el MTU, habilitar el túnel, añadir la dirección IPv6 al túnel y al puente br, se añade la ruta nueva que enviará TODO nuestro tráfico ipv6 al servidor relay 6to4 y listo. La IP especificada aquí, es siempre esa, 192.88.99.1, no es arbitraria. Con estos pequeños cambios, nuestro router “linux” será más que capaz de establecer cualquier conexión IPv6 por medio de 6to4.

    Dependiendo del dispositivo, 6to4 será la opción predeterminada o no a la hora de visitar un host, es decir, en Windows por ejemplo, 6to4 será usado para alcanzar un host ipv4

    ¿El resultado final? Una imagen vale más que cien palabras:

  • 6in4

    Sería posiblemente junto con 6to4 el segundo sistema actualmente más usado. En realidad, podría verse prácticamente igual a 6to4, salvo que 6in4 no es un túnel de configuración automática, sino un túnel que requiere configuración específica al final de este. Por tanto, este sería el primer ejemplo que mostramos de este otro tipo de túneles. También se apoya en el protocolo 41 para encapsular los paquetes IPv6 dentro de los paquetes IPv4, pero a diferencia de 6to4 en el que nuestros paquetes IPv4 eran enviados a un servidor relay, específicamente a  192.88.99.1, en 6in4 estos servidores relay será el final del túnel que tengamos que configurar. Generalmente estos servicios actualmente se conocen como “Tunnel Broker”, que se podría traducir algo así como “Corredor o corredores de túnel”. Al igual que 6to4 se les permite asociar un bloque completo de IPs, con lo que puede ser usado como se ha dicho para dotar a toda una red, algo mucho más deseable sobre todo en estos tiempos, y así estar seguros de no tener problemas con nuestros dispositivos NAT/Firewall.

    Parece que no posee ninguna ventaja frente a 6to4, pero no necesariamente. 6in4 está más orientado a la interconexión de redes grandes (aunque por supuesto puede conectar a redes IPv6 a un simple host). Al ser túneles que hay que configurar podemos tener al menos la apreciación de un sistema más seguro, dado que a fin de cuenta estaremos usando un servicio concreto que estará completamente definido por nuestra propia configuración de dicho túnel. Un ISP que haya migrado íntegramente a IPv6 podría por ejemplo tener contratado por alguna gran empresa un túnel 6in4 para poder conectar su red IPv6 a cualquier otra red IPv6 saltando por la Internet actual IPv4 y con un túnel perfectamente definido.

    Conozco dos proveedores de túneles 6in4 gratuitos principalmente, el primero pertenece efectivamente a Hurricane Electronic y el otro perteneciente a SixXS. Yo me he basado en Hurricane Electronic, pero no debería de ser costoso configurar cual quier otro. Al igual que se comentó con 6to4, para poder configurar un túnel 6in4 (en este caso usando tunnelbroker.net) será necesario tener nuestro router el soporte necesario para ello. De nuevo, he usado un router corriendo la última versión de DD-WRT con kernel 2.6. Estos ajustes funcionan en mi configuración, de nuevo no tiene por qué funcionar en la de otros. Existe un problema añadido… la mayoría de nuestras conexiones poseen una IP dinámica, y para configurar/crear los túneles es necesario conocer la IP en todo momento. Esto produce que a menos que nuestro router posea una interfaz gráfica que sea compatible con tunnelbroker y nos solicite simplemente a “dedo” cada uno de los dedos, tendremos que valernos de un script un poquito más complejo que el que se vio anteriormente, pero que también es muy simple, dado que la misma web donde configuramos nuestro Túnel nos proporciona la configuración necesaria, prácticamente tan solo hay que copiar y pegar. De todos modos no es obligatorio, siempre se puede acceder a la configuración del túnel e indicar la nueva IP.

    Primero, dado que es un túnel que se debe de configurar, lo primero es acceder a la web citada con anterioridad y dar de alta (gratuitamente) una cuenta nueva. Una vez creada se deberá de crear un nuevo túnel. Una vez creado, la interfaz nos dará los datos que necesitamos para configurar el túnel en cualquier equipo, desde un router hasta Windows. Los datos relevantes serán principalmente la dirección IP del servidor, la dirección IPv6 que se nos ha asignado (client IPv6) y la dirección IPv6 del router. Si queremos que el script automáticamente actualice la IP pública por nosotros (al más puro estilo de los servicios DDNS) será necesario tomar nota también del ID del túnel y nuestro ID de usuario, que se muestra en la pantalla principal de nuestra cuenta. Con todo esto sería suficiente.

    En este caso dado que el script era algo más largo he preferido tenerlo fuera de la interfaz web del router y ejecutarlo al inicio del router, como un archivo independiente:

    #!/bin/sh
    IP_SERVIDOR=”216.66.84.42″ <- Este es mi servidor, pero se deberá de especificar el de cada uno
    IPV6_ROUTER=”2001:470:1f13:5c2::” <- Esta es la IPv6/64 asignada a mi router, cada cual debería especificar la suya
    IPV6_CLIENTE=”2001:470:1f12:5c2::2″ <- Esta es la IPv6 que se nos asignará,

    ID_USUARIO=”loquesea”
    PASSWORD=”laquesea”
    TUNEL=”elquesea”

    CONFIGURACION_RADVD=”/tmp/radvd.conf”

    insmod ipv6
    sleep 2
    insmod /lib/modules/`uname -r`/kernel/net/ipv6/sit.ko
    sleep 2

    PASS_MD5=`echo -n $PASSWD | md5sum | sed -e ‘s/  -//g’`
    wget -q “http://ipv4.tunnelbroker.net/ipv4_end.php?ipv4b=AUTO&pass=$
    PASS_MD5&user_id=$ID_USUARIO&tunnel_id=$TUNEL
    WANIP=$(ip -4 addr show dev ppp0 | grep ‘inet ‘ | awk ‘{print $2}’ | cut -d/ -f1)

    ip tunnel add he-ipv6 mode sit remote $IP_SERVIDOR local $WANIP ttl 255
    ip link set he-ipv6 up
    ip addr add $IPV6_CLIENTE/64 dev he-ipv6
    ip route add ::/0 dev he-ipv6
    ip -f inet6 addr
    ip -6 addr add $IPV6_ROUTER/64 dev br0
    ip route add 2000::/3 dev he-ipv6

    echo 1 > /proc/sys/net/ipv6/conf/all/forwarding
    iptables -I INPUT 2 -p ipv6 -i vlan2 -j ACCEPT
    iptables -t nat -A POSTROUTING –proto ! 41 -o eth0 -j MASQUERADE

    echo “interface br0 {” >> $CONFIGURACION_RADVD
    echo “AdvSendAdvert on;” >> $CONFIGURACION_RADVD
    echo “prefix “$IPV6_ROUTER”/64 {” >> $CONFIGURACION_RADVD
    echo “AdvOnLink on;” >> $CONFIGURACION_RADVD
    echo “AdvAutonomous on;” >> $CONFIGURACION_RADVD
    echo “AdvRouterAddr on;” >> $CONFIGURACION_RADVD
    echo “};” >> $CONFIGURACION_RADVD
    echo “};” >> $CONFIGURACION_RADVD

    radvd -C $CONFIGURACION_RADVD &
    fi

    Evidentemente una configuración de este tipo es mucho más propensa a cualquier error que 6to4, por no decir que es necesario el alta y creación del túnel en la web en cuestión. Por otro lado, en realidad si se analiza bien quitando las 5 líneas en rojo el resto de los datos son proporcionados directamente por la web de tunnelbroker o simplemente datos puesto ahí por comodidad. Por ejemplo, la actualización de la IP pública (en morado), o simplemente a ver colocado los datos de nuestro túnel directamente en vez de usar variables para ellos (en naranjita), y a ver habilitado desde la interfaz web tanto IPV6 como el demonio radvd (tambien en naranjita).

    Al final, el resultado es el mismo, poder navegar las redes IPv6. Tengo que decir que este tipo de túneles siempre me han dado muchos más problemas y navegaciones mucho más lentas que con 6to4 o Teredo. Posiblemente el problema sea algún ajuste por mi parte, pero la realidad es esa. Si usamos el dispositivo móvil de nuevo para comprobar si todo funciona bien:

Cuando comencé este artículo sobre nuestra amiga IPv6, quedaban 7 millones de direcciones IPv4 en manos de la IANA. Al cierre de ester artículo el pool de direcciones IPv4 en manos de estos se ha agotado por completo, Cero. A partir de ahora, tan solo quedan libres direcciones IPv4 en manos de los RIR, que aun tardarán un tiempo en agotarse.