Túnel teredo

En redes de computadoras, Teredo es una tecnología de transición que brinda conectividad IPv6 completa para hosts con capacidad IPv6 que están en Internet IPv4 pero que no tienen una conexión nativa a una red IPv6. A diferencia de protocolos similares como 6to4, puede realizar su función incluso detrás de dispositivos de traducción de direcciones de red (NAT), como enrutadores domésticos.

Teredo opera utilizando un protocolo de túnel independiente de la plataforma que proporciona conectividad IPv6 (Protocolo de Internet versión 6) encapsulando paquetes de datagramas IPv6 dentro de paquetes de Protocolo de datagramas de usuario (UDP) IPv4. Teredo enruta estos datagramas en Internet IPv4 y a través de dispositivos NAT. Los nodos Teredo en otras partes de la red IPv6 (llamados retransmisiones Teredo) reciben los paquetes, los desencapsulan y los transmiten.

Teredo es una medida temporal. A largo plazo, todos los hosts IPv6 deberían utilizar conectividad IPv6 nativa. Teredo debe desactivarse cuando la conectividad IPv6 nativa esté disponible. Christian Huitema desarrolló Teredo en Microsoft y el IETF lo estandarizó como RFC 4380. El servidor Teredo escucha en el puerto UDP 3544.

Propósito

Para 6to4, el protocolo de túnel IPv6 sobre IPv4 más común, requiere que el punto final del túnel tenga una dirección IPv4 pública. Sin embargo, actualmente muchos hosts se conectan a Internet IPv4 a través de uno o varios dispositivos NAT, generalmente debido a la escasez de direcciones IPv4. En tal situación, la única dirección IPv4 pública disponible se asigna al dispositivo NAT y el punto final del túnel 6to4 debe implementarse en el propio dispositivo NAT. El problema es que muchos dispositivos NAT actualmente implementados no se pueden actualizar para implementar 6to4, por razones técnicas o económicas.

Teredo alivia este problema encapsulando paquetes IPv6 dentro de datagramas UDP/IPv4, que la mayoría de NAT pueden reenviar correctamente. Por lo tanto, los hosts compatibles con IPv6 detrás de NAT pueden servir como puntos finales del túnel Teredo incluso cuando no tienen una dirección IPv4 pública dedicada. De hecho, un host que implemente Teredo puede obtener conectividad IPv6 sin la cooperación del entorno de red local.

A largo plazo, todos los hosts IPv6 deberían utilizar conectividad IPv6 nativa. El protocolo temporal Teredo incluye disposiciones para un procedimiento de extinción: la implementación de Teredo debería proporcionar una manera de dejar de usar la conectividad Teredo cuando IPv6 madure y la conectividad esté disponible mediante un mecanismo menos frágil. A partir de IETF89, Microsoft planea desactivar sus servidores Teredo para clientes Windows en el primer semestre de 2014 (fecha exacta por determinar) y fomentar la desactivación de los repetidores Teredo operados públicamente.

Descripción general

El protocolo Teredo realiza varias funciones:

1. Diagnostica la conectividad UDP sobre IPv4 (UDPv4) y descubre el tipo de NAT presente (utilizando un reemplazo simplificado al protocolo STUN)
2. Asigna una dirección IPv6 única en todo el mundo a cada host usándolo
3. Encapsula paquetes IPv6 dentro de datagramas UDPv4 para la transmisión a través de una red IPv4 (esto incluye traversal NAT)
4. Tráfico de rutas entre anfitriones Teredo y anfitriones IPv6 nativos (o no Teredo)

Tipos de nodos

Teredo define varios tipos diferentes de nodos:

Teredo client

Un host que tiene conectividad IPv4 a Internet desde detrás de un NAT y utiliza el protocolo de túnel de Teredo para acceder a Internet IPv6. A los clientes de Teredo se les asigna una dirección IPv6 que comienza con el prefijo de Teredo (prefijo de Teredo)2001::/32).

Teredo server

Un host bien conocido utilizado para la configuración inicial de un túnel Teredo. Un servidor de Teredo nunca envía ningún tráfico para el cliente (aparte de IPv6 pings), y por lo tanto tiene requisitos modestos de ancho de banda (unos cientos bits por segundo por cliente en la mayoría), lo que significa que un solo servidor puede soportar a muchos clientes. Además, un servidor Teredo puede ser implementado de forma totalmente apátrida, utilizando la misma cantidad de memoria independientemente de cuántos clientes soporta.

Teredo relé

El extremo remoto de un túnel Teredo. Un relé de Teredo debe enviar todos los datos en nombre de los clientes de Teredo que sirve, con la excepción del cliente directo de Teredo a los intercambios de clientes de Teredo. Por lo tanto, un relé requiere mucho ancho de banda y sólo puede soportar un número limitado de clientes simultáneos. Cada relé de Teredo sirve a una gama de hosts IPv6 (por ejemplo, un campus o una empresa única, un ISP o una red de operadores entera, o incluso toda la Internet IPv6); avanza el tráfico entre cualquier cliente de Teredo y cualquier host dentro de dicho rango.

Relé de host específico de Teredo

Un relé de Teredo cuya gama de servicios está limitada al mismo anfitrión que se ejecuta. Como tal, no tiene requisitos particulares de ancho de banda o de enrutamiento. Un ordenador con un relé específico de host utiliza Teredo para comunicarse con clientes de Teredo, pero se adhiere a su principal proveedor de conectividad IPv6 para llegar al resto de Internet IPv6.

Direccionamiento IPv6

A cada cliente Teredo se le asigna una dirección IPv6 pública, que se construye de la siguiente manera (el bit de orden superior tiene el número 0):

• Los bits 0 a 31 sostienen el prefijo Teredo (2001:/32).
• Bits 32 a 63 incrustaron la dirección IPv4 primaria del servidor Teredo que se utiliza.
• Los bits 64 a 79 sostienen algunas banderas y otros bits; el formato para estos 16 bits, MSB primero, es "CRAAUG AAAAAAAA". El bit "C" se fijó a 1 si el cliente Teredo se encuentra detrás de un NAT de cono, 0 de lo contrario, pero RFC 5991 lo cambió para siempre ser 0 para evitar revelar este hecho a extraños. El bit "R" está actualmente sin firmar y debe ser enviado como 0. Los bits "U" y "G" se fijan en 0 para emular los bits "Universal/local" y "Group/individual" en direcciones MAC. Los 12 bits "A" fueron 0 en la especificación original RFC 4380, pero fueron cambiados a bits aleatorios elegidos por el cliente Teredo en RFC 5991 para proporcionar al nodo Teredo protección adicional contra ataques de escaneo basados en IPv6.
• Los bits 80 a 95 contienen el obfuscado Número de puerto UDP. Este es el número de puerto que el NAT mapea al cliente Teredo, con todos los bits invertidos.
• Los bits 96 a 127 contienen el obfuscado Dirección IPv4. Esta es la dirección IPv4 pública del NAT con todos los bits invertidos.

Como ejemplo, la dirección IPv6 2001:0000:4136:e378:8000:63bf:3fff:fdd2 se refiere a un cliente Teredo que:

• Utiliza el servidor Teredo en la dirección 65.54.227.120 (4136e378 en hexadecimal)
• Está detrás de un NAT de cono y el cliente no cumple plenamente con RFC 5991 (bit 64 se establece)
• Probablemente (99,98%) no cumple con RFC 5991 (los 12 bits aleatorios son todos 0, lo que sucede menos del 0,025% del tiempo)
• UDP mapped port 40000 on its NAT (in hexadecimal not 63bf equals 9c40, or decimal number 40000)
• Tiene una dirección IPv4 pública NAT de 192.0.2.45 (no 3ffdd2 equivale a c000022d, es decir, 192.0.2.45)

Servidores

Los clientes Teredo utilizan servidores Teredo para detectar automáticamente el tipo de NAT que están detrás (si corresponde), a través de un procedimiento de calificación simplificado similar a STUN. Los clientes Teredo también mantienen un vínculo en su NAT con su servidor Teredo enviando un paquete UDP a intervalos regulares. Esto garantiza que el servidor siempre pueda comunicarse con cualquiera de sus clientes, lo cual es necesario para que la perforación NAT funcione correctamente.

Si un repetidor Teredo (u otro cliente Teredo) debe enviar un paquete IPv6 a un cliente Teredo, primero envía un paquete burbuja Teredo al servidor Teredo del cliente, cuya dirección IP se infiere de la dirección Teredo IPv6 del cliente Teredo. Luego, el servidor reenvía la burbuja al cliente, por lo que el software del cliente Teredo sabe que debe perforar el relé Teredo.

Los servidores Teredo también pueden transmitir paquetes ICMPv6 desde clientes Teredo hacia Internet IPv6. En la práctica, cuando un cliente Teredo quiere contactar con un nodo IPv6 nativo, debe localizar el repetidor Teredo correspondiente, es decir, a qué número de puerto público IPv4 y UDP enviar paquetes IPv6 encapsulados. Para hacer eso, el cliente crea una solicitud de eco ICMPv6 (ping) hacia el nodo IPv6 y la envía a través de su servidor Teredo configurado. El servidor Teredo desencapsula el ping en Internet IPv6, de modo que el ping eventualmente llegue al nodo IPv6. Luego, el nodo IPv6 debe responder con una respuesta de eco ICMPv6, según lo exige RFC 2460. Este paquete de respuesta se enruta al relé Teredo más cercano, que, finalmente, intenta comunicarse con el cliente Teredo.

Mantener un servidor Teredo requiere poco ancho de banda, porque no participan en la transmisión y recepción reales de paquetes de tráfico IPv6. Además, no implica ningún acceso a los protocolos de enrutamiento de Internet. Los únicos requisitos para un servidor Teredo son:

• La capacidad de emitir paquetes ICMPv6 con una dirección de origen perteneciente al prefijo Teredo
• Dos direcciones IPv4 públicas distintas. Aunque no está escrito en la especificación oficial, los clientes de Microsoft Windows esperan que ambas direcciones sean consecutivas — la segunda dirección IPv4 es para la detección de NAT

Servidores públicos de Teredo:

• teredo.trex.fi (Finlandia)

Antiguos servidores públicos de Teredo:

• teredo.remlab.net / teredo-debian.remlab.net (Alemania), ahora redirecciona a teredo.trex.fi

Relés

Un repetidor Teredo requiere potencialmente mucho ancho de banda de red. Además, debe exportar (anunciar) una ruta hacia el prefijo Teredo IPv6 (2001::/32) a otros hosts IPv6. De esa manera, el repetidor Teredo recibe tráfico de los hosts IPv6 dirigidos a cualquier cliente Teredo y lo reenvía a través de UDP/IPv4. Simétricamente, recibe paquetes de clientes Teredo dirigidos a hosts IPv6 nativos a través de UDP/IPv4 y los inyecta en la red IPv6 nativa.

En la práctica, los administradores de red pueden configurar un repetidor Teredo privado para su empresa o campus. Esto proporciona una ruta corta entre su red IPv6 y cualquier cliente Teredo. Sin embargo, configurar una retransmisión Teredo a una escala superior a la de una sola red requiere la capacidad de exportar rutas BGP IPv6 a otros sistemas autónomos (AS).

A diferencia de 6to4, donde las dos mitades de una conexión pueden usar retransmisiones diferentes, el tráfico entre un host IPv6 nativo y un cliente Teredo utiliza el mismo retransmisión Teredo, es decir, el más cercano al host IPv6 nativo en cuanto a la red. El cliente Teredo no puede localizar una retransmisión por sí solo (ya que no puede enviar paquetes IPv6 por sí solo). Si necesita iniciar una conexión a un host IPv6 nativo, envía el primer paquete a través del servidor Teredo, que envía un paquete al host IPv6 nativo utilizando la dirección IPv6 de Teredo del cliente. Luego, el host IPv6 nativo responde como de costumbre a la dirección IPv6 de Teredo del cliente, lo que eventualmente hace que el paquete encuentre una retransmisión Teredo, que inicia una conexión con el cliente (posiblemente usando el servidor Teredo para la perforación NAT). El cliente Teredo y el host IPv6 nativo utilizan el relé para comunicarse siempre que lo necesiten. Este diseño significa que ni el servidor ni el cliente Teredo necesitan conocer la dirección IPv4 de ningún repetidor Teredo. Encuentran automáticamente uno adecuado a través de la tabla de enrutamiento IPv6 global, ya que todos los repetidores Teredo anuncian la red 2001::/32.

El 30 de marzo de 2006, el ISP italiano ITGate fue el primer AS en comenzar a anunciar una ruta hacia 2001::/32 en Internet IPv6, de modo que las implementaciones de Teredo compatibles con RFC 4380 fueran totalmente utilizables. El 16 de febrero de 2007 ya no funciona.

En el primer trimestre de 2009, la red troncal IPv6 Hurricane Electric habilitó 14 retransmisiones Teredo en una implementación anycast y publicidad 2001::/32 a nivel mundial. Los relevos estaban ubicados en Seattle, Fremont, Los Ángeles, Chicago, Dallas, Toronto, Nueva York, Ashburn, Miami, Londres, París, Ámsterdam, Frankfurt y Hong Kong.

Se espera que los grandes operadores de redes mantengan los repetidores Teredo. Al igual que con 6to4, aún no está claro qué tan bien crecerá el servicio Teredo si una gran proporción de servidores de Internet comienzan a usar IPv6 a través de Teredo además de IPv4. Si bien Microsoft ha operado un conjunto de servidores Teredo desde que lanzaron el primer pseudotúnel Teredo para Windows XP, nunca han proporcionado un servicio de retransmisión Teredo para Internet IPv6 en su conjunto.

Limitaciones

Teredo no es compatible con todos los dispositivos NAT. Utilizando la terminología de RFC 3489, admite dispositivos NAT de cono completo, restringidos y de puerto restringido, pero no admite NAT simétrica. La especificación original de Shipworm que condujo al protocolo Teredo final también admitía NAT simétricas, pero las abandonó por motivos de seguridad.

La gente de la Universidad Nacional Chiao Tung en Taiwán propuso posteriormente SymTeredo, que mejoró el protocolo Teredo original para admitir NAT simétricas, y las implementaciones de Microsoft y Miredo implementan ciertas extensiones no estándar no especificadas para mejorar el soporte para NAT simétricas. Sin embargo, la conectividad entre un cliente Teredo detrás de una NAT simétrica y un cliente Teredo detrás de una NAT simétrica o con puerto restringido sigue aparentemente imposible.

De hecho, Teredo asume que cuando dos clientes intercambian paquetes IPv6 encapsulados, los números de puerto UDP externos/mapeados utilizados serán los mismos que los que se utilizaron para contactar al servidor Teredo (y crear la dirección IPv6 de Teredo). Sin esta suposición, no sería posible establecer una comunicación directa entre los dos clientes y se tendría que utilizar un costoso relé para realizar el enrutamiento triangular. Una implementación de Teredo intenta detectar el tipo de NAT al inicio y se negará a funcionar si la NAT parece ser simétrica. (Esta limitación a veces se puede solucionar configurando manualmente una regla de reenvío de puerto en el cuadro NAT, que requiere acceso administrativo al dispositivo).

Teredo solo puede proporcionar una única dirección IPv6 por punto final del túnel. Como tal, no es posible utilizar un único túnel Teredo para conectar varios hosts, a diferencia de 6to4 y algunos túneles IPv6 punto a punto. El ancho de banda disponible para todos los clientes Teredo hacia Internet IPv6 está limitado por la disponibilidad de los repetidores Teredo, que no son diferentes de los repetidores 6to4 en ese sentido.

Alternativas

6to4 requiere una dirección IPv4 pública, pero proporciona un prefijo IPv6 grande de 48 bits para cada punto final del túnel y tiene una sobrecarga de encapsulación menor. Los túneles punto a punto pueden ser más confiables y responsables que Teredo y, por lo general, proporcionan direcciones IPv6 permanentes que no dependen de la dirección IPv4 del punto final del túnel. Algunos intermediarios de túneles punto a punto también admiten la encapsulación UDP para atravesar NAT (por ejemplo, el protocolo AYIYA puede hacer esto). Por el contrario, los túneles punto a punto normalmente requieren registro. Las herramientas automatizadas (por ejemplo, AICCU) facilitan el uso de túneles punto a punto.

Consideraciones de seguridad

Exposición

Teredo aumenta el ataque superficie asignando direcciones IPv6 en red a hosts de red detrás de dispositivos NAT, lo que de otro modo sería inalcanzable desde Internet. Al hacerlo, Teredo potencialmente expone cualquier aplicación IPv6 habilitada con un puerto abierto al exterior. La encapsulación del túnel de Teredo también puede causar que el contenido del tráfico de datos IPv6 sea invisible para el software de inspección de paquetes, facilitando la propagación del malware. Por último, Teredo expone la pila IPv6 y el software de túnel a ataques si tienen alguna vulnerabilidad remotamente explotable.

Para reducir la superficie de ataque, la pila IPv6 de Microsoft tiene un "nivel de protección" opción de enchufe. Esto permite que las aplicaciones especifiquen desde qué fuentes están dispuestas a aceptar tráfico IPv6: desde el túnel Teredo, desde cualquier lugar excepto Teredo (el valor predeterminado) o solo desde la intranet local.

El protocolo Teredo también encapsula información detallada sobre el punto final del túnel en sus paquetes de datos. Esta información puede ayudar a los atacantes potenciales al aumentar la viabilidad de un ataque y/o al reducir el esfuerzo requerido.

Firewalling, filtrado y bloqueo

Para que un pseudotúnel Teredo funcione correctamente, los paquetes UDP salientes al puerto 3544 no deben filtrarse. Además, las respuestas a estos paquetes (es decir, "tráfico solicitado") tampoco deben filtrarse. Esto corresponde a la configuración típica de una NAT y su funcionalidad de firewall con estado. El software de tunelización Teredo informa un error fatal y se detiene si se bloquea el tráfico UDP IPv4 saliente.

DoS a través de bucles de enrutamiento

En 2010, se descubrieron nuevos métodos para crear ataques de denegación de servicio a través de bucles de enrutamiento que utilizan túneles Teredo. Son relativamente fáciles de prevenir.

Uso predeterminado en MS-Windows

Microsoft Windows a partir de Windows 10, versión 1803 y posteriores desactiva Teredo de forma predeterminada. Si es necesario, esta tecnología de transición se puede habilitar mediante un comando CLI o una política de grupo.

Implementaciones

Actualmente hay varias implementaciones de Teredo disponibles:

• Windows XP SP2 incluye un cliente y host-specific relé (también en el paquete de red avanzado para Service Pack 1).
• Windows Server 2003 tiene un relé y servidor proporcionado bajo el programa Microsoft Beta.
• Windows Vista y Windows 7 tienen soporte incorporado para Teredo con una extensión no especificada para la traversal NAT simétrica. Sin embargo, si solo hay una dirección local y teredo, estos sistemas operativos no tratan de resolver los registros IPv6 DNS AAAA si hay un registro DNS A, en cuyo caso utilizan IPv4. Por lo tanto, sólo URLs IPv6 literales normalmente usan Teredo. Este comportamiento se puede modificar en el registro.
• Windows 10 versión 1803 y posteriormente deshabilita Teredo por defecto. Si es necesario, esta tecnología de transición se puede activar mediante un comando CLI o una política de grupo.
• Miredo es un cliente, relé y servidor para Linux, *BSD y Mac OS X,
• ng_teredo es un relé y servidor basado en netgraph para FreeBSD de la Universidad LIP6 y 6WIND.
• NICI-Teredo es un relé para el kernel de Linux y un servidor de usuario Teredo, desarrollado en la Universidad Nacional Chiao Tung.

Elección del nombre

El apodo inicial del protocolo de túnel Teredo era Shipworm. La idea era que el protocolo atravesaría los dispositivos NAT, de la misma manera que el gusano de barco (una especie de almeja marina que perfora la madera) perfora túneles a través de la madera. Los gusanos de barco han sido responsables de la pérdida de muchos cascos de madera. Christian Huitema, en el borrador original, señaló que el gusano de barco “sólo sobrevive en aguas relativamente limpias y no contaminadas; Su reciente reaparición en varios puertos de América del Norte es un testimonio de su limpieza recién recuperada. El servicio Shipworm debería, a su vez, contribuir [sic] a una nueva transparencia de Internet."

Para evitar confusión con los gusanos informáticos, Huitema luego cambió el nombre del protocolo de Shipworm a Teredo, después del nombre del género del gusano de barco Teredo. navalis.