En redes informáticas , Teredo es una tecnología de transición de Microsoft que brinda conectividad IPv6 completa para hosts con capacidad IPv6 que están en Internet IPv4 pero no tienen 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 tunelización 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 relés 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 debería 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 .
Para 6to4 , el protocolo de tunelización IPv6 sobre IPv4 más común, se requiere que el punto final del túnel tenga una dirección IPv4 pública. Sin embargo, muchos hosts actualmente 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 implementados actualmente no se pueden actualizar para implementar 6to4, por razones técnicas o económicas.
Teredo alivia este problema encapsulando los paquetes IPv6 dentro de datagramas UDP/IPv4, que la mayoría de los NAT pueden reenviar correctamente. De este modo, los hosts compatibles con IPv6 detrás de los NAT pueden actuar como puntos finales del túnel Teredo incluso cuando no tienen una dirección IPv4 pública dedicada. En efecto, un host que implementa 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 forma de dejar de utilizar la conectividad Teredo cuando IPv6 madure y la conectividad esté disponible utilizando un mecanismo menos frágil. A partir de IETF89 [ se necesita una aclaración ] , Microsoft planea desactivar sus servidores Teredo para clientes Windows en la primera mitad de 2014 [ se necesita una actualización ] (fecha exacta por determinar) y alentar la desactivación de los relés Teredo operados públicamente.
El protocolo Teredo realiza varias funciones:
Teredo define varios tipos diferentes de nodos: [1]
2001::/32). [2]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 está numerado 0):
A modo de ejemplo, la dirección IPv6 2001:0000:4136:e378:8000:63bf:3fff:fdd2 hace referencia a un cliente Teredo que:
Los clientes de Teredo utilizan servidores Teredo para detectar automáticamente el tipo de NAT que tienen detrás (si es que tienen alguno), a través de un procedimiento de calificación simplificado similar a STUN . Los clientes de Teredo también mantienen un enlace en su NAT hacia su servidor Teredo enviando un paquete UDP a intervalos regulares. Eso garantiza que el servidor siempre pueda comunicarse con cualquiera de sus clientes, lo cual es necesario para que la perforación de agujeros de NAT funcione correctamente.
Si un relé 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 infiere de la dirección IPv6 Teredo del cliente Teredo. A continuación, el servidor reenvía la burbuja al cliente, de modo que el software del cliente Teredo sepa que debe realizar la perforación hacia 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 desea contactar con un nodo IPv6 nativo, debe localizar el relé Teredo correspondiente, es decir , a qué número de puerto IPv4 y UDP público enviar paquetes IPv6 encapsulados. Para ello, 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 debería llegar finalmente al nodo IPv6. El nodo IPv6 debería entonces responder con una respuesta de eco ICMPv6, como lo exige RFC 2460. Este paquete de respuesta se enruta al relé Teredo más cercano , que, finalmente, intenta contactar con el cliente Teredo.
El mantenimiento de un servidor Teredo requiere poco ancho de banda, ya que no interviene en la transmisión y recepción 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:
Servidores públicos Teredo:
Antiguos servidores públicos de Teredo:
Un relé Teredo potencialmente requiere mucho ancho de banda de red. Además, debe exportar ( publicitar ) una ruta hacia el prefijo IPv6 de Teredo (2001::/32) a otros hosts IPv6. De esa manera, el relé Teredo recibe tráfico de los hosts IPv6 dirigidos a cualquier cliente Teredo y lo reenvía a través de UDP/IPv4. De manera simétrica, 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 relé Teredo privado para su empresa o campus. Esto proporciona una ruta corta entre su red IPv6 y cualquier cliente Teredo. Sin embargo, configurar un relé Teredo en una escala que supere la de una sola red requiere la capacidad de exportar rutas IPv6 BGP a otros sistemas autónomos (AS).
A diferencia de 6to4 , donde las dos mitades de una conexión pueden usar diferentes relés, el tráfico entre un host IPv6 nativo y un cliente Teredo usa el mismo relé Teredo, es decir, el más cercano a la red del host IPv6 nativo. El cliente Teredo no puede localizar un relé por sí mismo (ya que no puede enviar paquetes IPv6 por sí mismo). 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 usando la dirección IPv6 Teredo del cliente. El host IPv6 nativo responde entonces como de costumbre a la dirección IPv6 Teredo del cliente, lo que eventualmente hace que el paquete encuentre un relé Teredo, que inicia una conexión con el cliente (posiblemente usando el servidor Teredo para la perforación de NAT ). El cliente Teredo y el host IPv6 nativo usan entonces el relé para la comunicación mientras lo necesiten. Este diseño implica que ni el servidor ni el cliente Teredo necesitan conocer la dirección IPv4 de ningún relé Teredo. Encuentran una adecuada automáticamente a través de la tabla de enrutamiento IPv6 global, ya que todos los relés Teredo anuncian la red 2001::/32.
El 30 de marzo de 2006, el ISP italiano ITGate [4] 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. A partir del 16 de febrero de 2007, ya no está en funcionamiento.
En el primer trimestre de 2009, la red troncal IPv6 de Hurricane Electric habilitó 14 relés Teredo [5] en una implementación anycast y publicidad de 2001::/32 a nivel mundial. Los relés 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 repetidores Teredo. Al igual que con 6to4, no está claro hasta qué punto se ampliará el servicio Teredo si una gran proporción de hosts de Internet comienzan a utilizar IPv6 a través de Teredo además de IPv4. Si bien Microsoft ha operado un conjunto de servidores Teredo desde que lanzó el primer pseudotúnel Teredo para Windows XP, nunca ha proporcionado un servicio de repetidores Teredo para Internet IPv6 en su totalidad.
Oficialmente, este mecanismo fue creado para PC con Microsoft Windows XP y posteriores para proporcionar conectividad IPv6 a clientes IPv4 mediante la conexión a ipv6.microsoft.com y funciona en conjunto con el servicio IP Helper y el controlador de interfaz del adaptador de túnel Teredo . El servicio también abre un puerto UPNP en el enrutador para retransmisión.
Teredo no es compatible con todos los dispositivos NAT. Según la terminología de RFC 3489, admite dispositivos NAT de cono completo, restringidos y con puerto restringido , pero no admite NAT simétricos . La especificación Shipworm [6] original que dio origen al protocolo Teredo final también admitía NAT simétricos, pero lo abandonó por cuestiones de seguridad.
Posteriormente, en la Universidad Nacional Chiao Tung de Taiwán se propuso SymTeredo [7] , que mejoró el protocolo Teredo original para que admitiera NAT simétricos, y las implementaciones de Microsoft y Miredo implementan ciertas extensiones no estándar no especificadas para mejorar la compatibilidad con NAT simétricos. Sin embargo, la conectividad entre un cliente Teredo detrás de un NAT simétrico y un cliente Teredo detrás de un NAT simétrico o restringido por puerto sigue siendo aparentemente imposible. [ cita requerida ]
De hecho, Teredo supone 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 con el servidor Teredo (y construir 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 el NAT parece ser simétrico. (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. Por lo tanto, 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 relés Teredo, que no se diferencian de los relés 6to4 en ese aspecto.
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 más responsables que Teredo, y generalmente 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 otro lado, los túneles punto a punto normalmente requieren registro. Las herramientas automatizadas (por ejemplo , AICCU ) facilitan el uso de túneles punto a punto.
Teredo aumenta la superficie de ataque al asignar direcciones IPv6 enrutables globalmente a los hosts de red detrás de dispositivos NAT, que de otra manera serían inaccesibles desde Internet. Al hacerlo, Teredo potencialmente expone cualquier aplicación habilitada para IPv6 con un puerto abierto al exterior. La encapsulación del túnel Teredo también puede hacer que el contenido del tráfico de datos IPv6 se vuelva invisible para el software de inspección de paquetes, lo que facilita la propagación de malware. [8] Finalmente, Teredo expone la pila IPv6 y el software de tunelización a ataques si tienen alguna vulnerabilidad explotable de forma remota.
Para reducir la superficie de ataque, la pila IPv6 de Microsoft tiene una opción de socket de "nivel de protección" . Esto permite que las aplicaciones especifiquen de 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 posibles atacantes aumentando la viabilidad de un ataque y/o reduciendo el esfuerzo necesario. [9]
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, el "tráfico solicitado") tampoco deben filtrarse. Esto corresponde a la configuración típica de un 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.
En 2010 se descubrieron nuevos métodos para crear ataques de denegación de servicio mediante bucles de enrutamiento que utilizan túneles Teredo. Son relativamente fáciles de prevenir. [10]
Microsoft Windows a partir de Windows 10, versión 1803 y posteriores deshabilita Teredo de forma predeterminada. Si es necesario, esta tecnología de transición se puede habilitar mediante un comando CLI o una directiva de grupo . [11]
Actualmente hay varias implementaciones de Teredo disponibles:
El apodo inicial del protocolo de tunelización Teredo era Shipworm . La idea era que el protocolo atravesara los dispositivos NAT, de forma muy similar a como el Shipworm (una especie de almeja perforadora de madera) perfora túneles en la madera. Los Shipworms han sido responsables de la pérdida de muchos cascos de madera. Christian Huitema, en el borrador original, señaló que el Shipworm "sólo sobrevive en aguas relativamente limpias y no contaminadas; su reciente regreso a varios puertos de América del Norte es un testimonio de su nueva limpieza. El servicio Shipworm debería, a su vez, contribuir [ sic ] a una nueva transparencia de Internet". [15]
Para evitar confusiones con gusanos informáticos , [16] Huitema posteriormente cambió el nombre del protocolo de Shipworm a Teredo , en honor al nombre del género del gusano de barco Teredo navalis . [16]
Por el momento, teredo.remlab.net será el alias del servidor público Teredo proporcionado por la central regional TREX en la ciudad finlandesa de Tampere.