Resumo

  • A RFC 3077 preservou a natureza física unidirecional do feed via satélite e usou túneis entre interfaces IP bidirecionais para simular o tráfego de enlace que os receptores não podiam enviar pela difusão.
  • Os anúncios DTCP, também transmitidos em um só sentido, ajudavam a descobrir feeds e remover pontas de túnel expiradas; não autenticavam um feed, não elegiam uma rota ótima para todos nem comprovavam a entrega à aplicação.

Publicada em março de 2001, a RFC 3077 parte de uma limitação física. O feed pode transmitir por um enlace unidirecional; o receptor consegue ouvir, mas não responder pelo mesmo meio. Um feed somente de envio também não recebe por aquela interface. Muitos protocolos da Internet, porém, pressupõem enlaces capazes de transportar pacotes nos dois sentidos: o roteador envia ao próximo salto e espera respostas ou atualizações de roteamento.

A solução não foi tornar transmissor o receptor via satélite. Receptor e feed precisavam também de uma interface bidirecional convencional, conectada a uma infraestrutura IP. Quando o receptor queria mandar um quadro de enlace ao feed, encapsulava esse quadro e o transportava por um túnel até o endereço do feed voltado para a Internet. O feed desencapsulava o pacote e o entregava ao lado conectado ao enlace unidirecional. A difusão via satélite continuava sendo o caminho de descida; o túnel fornecia o retorno entre nós escolhidos.

Por que simular o enlace em vez de criar apenas outra rede IP? A simulação permitia que os protocolos das camadas superiores operassem sem conhecer a física do satélite. A RFC descreve seis comunicações possíveis em uma rede de difusão bidirecional. A entrega do feed ao receptor, o sexto caso, já funcionava pelo meio físico. O túnel deveria tornar possíveis os outros cinco: do receptor ao feed, entre receptores e em tráfego de difusão e multicast. Assim, ARP e protocolos de roteamento entre vizinhos diretamente conectados podiam permanecer na camada habitual. Isso não significa que o enlace físico passasse a transmitir na direção inversa.

O documento recomenda Generic Routing Encapsulation (GRE) para transportar diferentes pacotes internos sobre IP. No formato descrito, um pacote IP externo chega ao endereço bidirecional do feed, o cabeçalho GRE identifica o protocolo de enlace usado no meio unidirecional e a carga útil contém o quadro MAC original. Outros tipos de túnel são possíveis se as duas pontas concordarem sobre sua interpretação. A RFC 3077 define a adaptação ao redor do túnel; não transforma GRE em um mecanismo de autorização ou segurança.

A parte menos óbvia é como o receptor descobre para qual feed deve tunelar. O Dynamic Tunnel Configuration Protocol (DTCP) não usa o retorno pela Internet para isso. Suas mensagens HELLO vão dos feeds aos receptores pelo próprio enlace unidirecional. JOIN anuncia que um feed está operando; LEAVE pode avisar que ele vai parar. HELLO também carrega intervalo, sequência, tipo de túnel e um ou mais endereços IP bidirecionais do feed (FBIP). Os receptores escutam o anúncio multicast de DTCP e mantêm uma lista de feeds ativos, pontas de túnel e temporizadores.

Com LEAVE, o receptor pode remover a entrada rapidamente. Se os HELLO cessarem, ela acaba expirando. É um sinal limitado: o feed pode ter falhado ou o próprio enlace unidirecional pode estar fora. Em ambos os casos, já não é possível presumir conectividade bidirecional por aquele feed. O temporizador indica o que deixar de tentar; não diagnostica o componente defeituoso nem comprova que um pacote de aplicação chegou.

A escolha do feed é local. Cada receptor define seu próprio feed padrão; menor tempo de ida e volta é apenas um exemplo da RFC, não uma política obrigatória. O administrador pode preferir outra ponta anunciada que seja mais acessível. Até mesmo o endereço MAC do feed no enlace unidirecional (FUMAC), necessário ao funcionamento, não tem um método universal de descoberta definido. O formato comum organiza a troca de dados, mas a configuração local ainda decide qual caminho é útil.

A palavra “bidirecional” esconde um custo. Um enlace geoestacionário pode acrescentar cerca de 250 milissegundos de atraso em um sentido, enquanto a rota de retorno pela Internet também varia. A RFC alerta que a resolução reativa de endereços, como ARP, pode deixar o feed esperando uma resposta enquanto os pacotes se acumulam, esgotam o buffer e são descartados. É um risco de engenharia descrito na especificação, não uma medição de um serviço identificado. Os caminhos são combinados, mas continuam distintos em atraso, capacidade e responsabilidade.

Por isso, a RFC exige que o receptor desative os túneis se o enlace unidirecional cair. Caso contrário, um roteador pode continuar recebendo pacotes pelo túnel e interpretar isso como prova de que o enlace subjacente ainda opera; alguns protocolos de roteamento avaliam vizinhos com base no tráfego recebido. A falha de um feed também deve interromper tráfego de túnel desnecessário. Desencapsular um quadro é só uma etapa, não comprova rota estável nem serviço concluído.

Confiança é outra camada. A RFC alerta para falsificação de ARP e IP que permita a nós não autorizados acessar o serviço. Diz que os túneis podem ser autenticados, mas não especifica o mecanismo. Protocolos de roteamento sobre o enlace emulado devem usar a autenticação própria quando disponível, para impedir que receptores não autorizados injetem rotas falsas. JOIN e os endereços anunciados pelo DTCP são avisos, não credenciais.

A especificação tampouco promete interoperabilidade imediata. Um perfil de implantação precisa definir o formato MAC e o tipo de túnel; se não usar GRE, as duas pontas devem acordar a interpretação desse tipo. A configuração de roteamento multicast e a escalabilidade ficam fora do escopo. A RFC torna utilizável um meio unidirecional ao combiná-lo com uma rede de retorno, mas não uniformiza os caminhos nem resolve sua confiança por padrão.

Fontes primárias