En el contexto de las redes informáticas , un intermediario de túneles es un servicio que proporciona un túnel de red . Estos túneles pueden proporcionar conectividad encapsulada a través de una infraestructura existente hacia otra infraestructura.
Hay una variedad de agentes de túnel, incluidos los agentes de túnel IPv4 , aunque el término se utiliza más comúnmente para referirse a un agente de túnel IPv6 como se define en RFC 3053.
Los intermediarios de túneles IPv6 suelen proporcionar IPv6 a sitios o usuarios finales a través de IPv4. En general, los intermediarios de túneles IPv6 ofrecen los denominados túneles de "protocolo 41" o proto-41. Se trata de túneles en los que el IPv6 se tuneliza directamente dentro de paquetes IPv4 al tener el campo de protocolo establecido en "41" (IPv6) en el paquete IPv4 . En el caso de los intermediarios de túneles IPv4, los túneles IPv4 se proporcionan a los usuarios encapsulando el IPv4 dentro de IPv6, tal como se define en RFC 2473.
La configuración de túneles IPv6 se realiza normalmente mediante el protocolo de configuración de túneles (TSP) o mediante el protocolo de control de información de túneles (TIC). Un cliente capaz de realizar esto es AICCU (Utilidad de cliente de conectividad IPv6 automática). Además de los túneles IPv6, el TSP también se puede utilizar para configurar túneles IPv4.
Es posible que los túneles Proto-41 (IPv6 directo en IPv4) no funcionen bien si se encuentran detrás de NAT . Una forma de evitarlo es configurar el punto final real del túnel para que sea la DMZ en el equipo que utiliza NAT. Otro método es utilizar AYIYA o TSP , que envían IPv6 dentro de paquetes UDP , lo que permite atravesar la mayoría de las configuraciones NAT e incluso los firewalls .
Un problema que aún puede ocurrir es el de la expiración del estado en la máquina NAT. Cuando un NAT recuerda que un paquete salió a Internet , permite que otro paquete regrese desde Internet que esté relacionado con el paquete proto-41 inicial. Cuando este estado expira, no se aceptarán otros paquetes de Internet. Por lo tanto, esto interrumpe la conectividad del túnel hasta que el host del usuario vuelva a enviar un paquete al agente del túnel.
Cuando el punto final no es una dirección IP estática, el usuario o un programa deben indicarle al agente de túnel que actualice la dirección del punto final. Esto se puede hacer mediante el sitio web del agente de túnel o mediante un protocolo automatizado como TSP o Heartbeat, como los que utiliza AICCU. En el caso de un agente de túnel que utilice TSP, el cliente que reinicie automáticamente el túnel hará que se actualicen la dirección y el puerto del punto final.
La primera implementación de un broker de túneles IPv6 fue en la empresa italiana CSELT SpA por Ivano Guardini, autor del RFC 3053 [1] [ verificación fallida ]
Existe una variedad de agentes de túneles que ofrecen sus propias implementaciones personalizadas en función de diferentes objetivos. A continuación, se enumeran las implementaciones comunes que utilizan los agentes de túneles IPv6 enumerados.
gogoSERVER (anteriormente Gateway6) es utilizado por el servicio Freenet6, que es el segundo servicio de intermediación de túneles IPv6, que entró en producción en 1999. Comenzó como un proyecto de Viagenie y luego Hexago se separó como una empresa comercial que vendía Gateway6, que impulsaba Freenet6, como su producto estrella. En junio de 2009, Hexago se convirtió en gogo6 a través de una compra por parte de la gerencia y el servicio Freenet6 pasó a formar parte de gogoNET, una red social para profesionales de IPv6. [2] El 23 de marzo de 2016 se suspendieron todos los servicios de Freenet6/Gogo6.
SixXS's sixxsd es lo que alimenta todos los PoP de SixXS. Es un software creado a medida con el propósito de crear túneles de alto rendimiento con baja latencia. El desarrollo de sixxsd comenzó en 2002 [3] y ha evolucionado hasta la versión v4 actual del software. El software está disponible para los ISP que proporcionan y ejecutan PoP de SixXS. Originalmente, en 2000, SixXS usaba scripts de shell bash. [4] [ verificación fallida ] Debido a problemas de escalabilidad y otros problemas, se diseñó y desarrolló sixxsd. Después de 17 años, el túnel de SixXS dejó de funcionar el 6 de junio de 2017.
CITC Tunnel Broker, administrado por el Grupo de trabajo IPv6 de Arabia Saudita, utiliza su propia implementación del RFC TSP denominada 'ddtb'. [5]