Resumen

  • La RFC 3077 mantuvo unidireccional el medio satelital y recurrió a túneles entre interfaces bidireccionales para simular el tráfico de enlace que los receptores no podían emitir por la difusión.
  • Los anuncios DTCP, enviados también en un solo sentido, ayudaban a descubrir las estaciones de alimentación y retirar extremos de túnel caducados; no autenticaban la estación, imponían una ruta óptima común ni demostraban la entrega a una aplicación.

Publicada en marzo de 2001, la RFC 3077 parte de una limitación física. Una estación de alimentación puede transmitir por un enlace unidireccional; el receptor puede escuchar, pero no contestar por ese medio. A la inversa, una estación de solo envío tampoco recibe por esa interfaz. Sin embargo, muchos protocolos de Internet presuponen que los enlaces permiten tráfico en ambos sentidos: un router remite un paquete al siguiente salto y espera respuestas o actualizaciones de encaminamiento.

La solución no fue convertir el receptor satelital en transmisor. Tanto receptores como estaciones de alimentación necesitaban además una interfaz bidireccional convencional conectada a una infraestructura IP. Si un receptor quería enviar una trama de enlace a una estación de alimentación, la encapsulaba y la transportaba por un túnel hasta la dirección de esa estación en Internet. Allí se desencapsulaba y se entregaba al lado conectado al enlace unidireccional. La difusión satelital seguía siendo el camino descendente; el túnel aportaba el retorno entre nodos escogidos.

¿Por qué simular una red de enlace, en lugar de crear solo una red IP nueva? La simulación permitía que los protocolos de capas superiores funcionaran sin tener que conocer la física satelital. La RFC enumera seis intercambios posibles en una red de difusión bidireccional. La entrega desde la estación de alimentación hasta el receptor, el sexto caso, ya era posible por el medio físico. Los túneles debían habilitar los otros cinco: del receptor a la estación, entre receptores y para distintos tipos de difusión y multidifusión. Así, protocolos como ARP y los de encaminamiento de vecinos conectados podían conservar su lugar habitual en la pila.

Eso no significa que el enlace físico obtuviera un transmisor de retorno.

El documento recomienda Generic Routing Encapsulation (GRE) para transportar distintos paquetes interiores sobre IP. En el formato descrito, un paquete IP exterior llega a la dirección bidireccional de la estación; la cabecera GRE identifica el protocolo de enlace usado en el medio unidireccional y su carga contiene la trama MAC original. Pueden elegirse otros tipos de túnel si ambos extremos acuerdan qué significan. La RFC 3077 define la adaptación alrededor del túnel, no convierte GRE en un mecanismo de autorización o seguridad.

La parte menos intuitiva es cómo sabe el receptor a qué estación dirigir el túnel. El Dynamic Tunnel Configuration Protocol (DTCP) no usa la ruta de retorno de Internet para descubrirla. Sus mensajes HELLO viajan desde las estaciones de alimentación hasta los receptores por el propio enlace unidireccional. JOIN anuncia que una estación está activa; LEAVE puede anunciar que se detiene. HELLO también lleva un intervalo, un número de secuencia, el tipo de túnel y una o varias direcciones IP bidireccionales de la estación (FBIP).

Los receptores escuchan el anuncio multicast de DTCP y mantienen una lista de estaciones activas, sus extremos de túnel y temporizadores.

Un mensaje LEAVE permite quitar pronto una entrada. Si cesan los HELLO, la entrada termina caducando. La señal tiene un alcance limitado: puede haber fallado la estación o el enlace unidireccional. En cualquiera de los dos casos, ya no se puede dar por supuesta la conectividad bidireccional con esa estación. El temporizador indica qué dejar de intentar; no diagnostica qué componente se averió ni demuestra que llegara un paquete de aplicación.

La elección de estación sigue siendo local. Cada receptor escoge su propia estación predeterminada; la RFC menciona un menor tiempo de ida y vuelta como ejemplo, pero no impone una política uniforme. El administrador del receptor también puede preferir otro extremo anunciado si tiene mejor conectividad con él. Incluso la dirección MAC de la estación en el enlace unidireccional (FUMAC), necesaria para el funcionamiento, carece de un método de descubrimiento universal especificado. El formato permite intercambiar datos; la configuración local decide qué camino resulta útil.

La palabra «bidireccional» puede ocultar un coste. Una conexión geoestacionaria puede añadir cerca de 250 milisegundos de demora en un solo sentido, mientras que la ruta de retorno por Internet también varía. La RFC advierte que métodos reactivos de resolución como ARP pueden dejar esperando a una estación mientras se acumulan paquetes, agotar el búfer y provocar pérdidas. Es un riesgo de ingeniería descrito por la especificación, no una medición de un servicio identificado. Los caminos se combinan, pero conservan demoras, capacidades y responsables distintos.

Por eso, la RFC exige que los receptores desactiven los túneles si cae el enlace unidireccional. De otro modo, un router podría seguir recibiendo paquetes por un túnel y tomarlos como señal de que el enlace subyacente sigue operativo; algunos protocolos de encaminamiento evalúan al vecino a partir del tráfico recibido. La caída de una estación también debe detener el tráfico de túnel que ya no sirve. Desencapsular una trama es solo un paso de la cadena, no una ruta estable ni un servicio completado.

La confianza pertenece a otra capa. La RFC advierte que la suplantación ARP o IP puede dar acceso al servicio a nodos no autorizados. Indica que los túneles pueden autenticarse, pero no define el mecanismo. Los protocolos de encaminamiento que operen sobre el enlace simulado deben usar sus propios mecanismos de autenticación cuando estén disponibles, para impedir que un receptor no autorizado inyecte rutas falsas. Los mensajes JOIN y las direcciones anunciadas por DTCP son avisos, no credenciales.

La especificación tampoco promete interoperabilidad automática. Un perfil de despliegue debe definir el formato MAC y el tipo de túnel; si no se usa GRE, los dos extremos han de acordar expresamente la interpretación de ese tipo. La configuración del encaminamiento multicast y la escalabilidad quedan fuera de alcance. La RFC vuelve utilizable un medio unidireccional al componerlo con una red de retorno, pero no hace uniformes los caminos ni resuelve de forma implícita su confianza.

Fuentes principales