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 la infraestructura existente hacia otra infraestructura.
Hay una variedad de corredores de túneles, incluidos los corredores de túneles IPv4 , aunque más comúnmente el término se usa para referirse a un corredor de túneles IPv6 como se define en RFC 3053.
Los agentes de túneles IPv6 suelen proporcionar IPv6 a sitios o usuarios finales a través de IPv4. En general, los corredores de túneles IPv6 ofrecen los llamados túneles 'protocolo 41' o protocolo-41. Estos son túneles donde IPv6 se canaliza directamente dentro de paquetes IPv4 al tener el campo de protocolo configurado en '41' (IPv6) en el paquete IPv4 . En el caso de los corredores de túneles IPv4, los túneles IPv4 se proporcionan a los usuarios encapsulando IPv4 dentro de IPv6 como se define en RFC 2473.
La configuración de los túneles IPv6 generalmente se realiza mediante el protocolo de configuración de túneles (TSP) o el protocolo de control de información de túneles (TIC). Un cliente capaz de hacer esto es AICCU (Utilidad de cliente de conectividad IPv6 automática). Además de los túneles IPv6, 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 situados detrás de NAT . Una forma de evitar esto 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 , los cuales envían IPv6 dentro de paquetes UDP , que pueden cruzar la mayoría de las configuraciones NAT e incluso firewalls .
Un problema que aún podría ocurrir es el del tiempo de espera del estado en la máquina NAT. Como un NAT recuerda que un paquete salió a Internet , permite que otro paquete regrese desde Internet relacionado con el paquete proto-41 inicial. Cuando este estado expire, no se aceptarán otros paquetes de Internet. Por lo tanto, esto interrumpe la conectividad del túnel hasta que el host del usuario envía nuevamente un paquete al intermediario del túnel.
Cuando el punto final no es una dirección IP estática, el usuario o un programa debe indicarle al agente de túnel que actualice la dirección del punto final. Esto se puede hacer utilizando el sitio web del agente del túnel o utilizando un protocolo automatizado como TSP o Heartbeat, como el que utiliza AICCU. En el caso de un intermediario de túnel que utiliza TSP, el cliente que reinicia automáticamente el túnel hará que se actualicen la dirección y el puerto del punto final.
La primera implementación de un Tunnel Broker IPv6 fue en la CSELT SpA italiana por Ivano Guardini, autor del RFC 3053 [1] [ verificación fallida ]
Existe una variedad de agentes de túneles que proporcionan sus propias implementaciones personalizadas basadas en diferentes objetivos. A continuación se enumeran las implementaciones comunes utilizadas por los agentes de túneles IPv6 enumerados.
gogoSERVER (anteriormente Gateway6) es utilizado por el servicio Freenet6, que es el segundo servicio de intermediario de túneles IPv6, que entró en producción en 1999. Se inició como un proyecto de Viagenie y luego Hexago se escindió como una empresa comercial que vendía Gateway6, que impulsó Freenet6, como su producto estrella. En junio de 2009, Hexago se convirtió en gogo6 mediante una compra de la dirección 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.
El sixxsd de SixXS es lo que alimenta todos los PoP de SixXS. Es un software personalizado con el fin de realizar túneles de alto rendimiento con baja latencia. El desarrollo de sixxsd comenzó en 2002 [3] y ha evolucionado hasta la versión actual v4 del software. El software está disponible para los ISP que proporcionan y ejecutan SixXS PoP. Originalmente, en 2000, SixXS usaba scripts de bash de shell. [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 SixXS desapareció el 6 de junio de 2017.
CITC Tunnel Broker, dirigido por el Grupo de Trabajo IPv6 de Arabia Saudita, utiliza su propia implementación del RFC de TSP denominada 'ddtb'. [5]