Resumo

  • Um endereço de origem legítimo podia ser inadequado para sair pela rede visitada. O filtro avaliava a posição do emissor na topologia, não apenas a legitimidade do endereço.
  • O túnel reverso acrescentava um cabeçalho externo compatível com o percurso até o agente de origem, mantendo os endereços da comunicação no pacote interno.
  • A entrega encapsulada permitia escolher o tráfego enviado por esse caminho. Depois de negociá-la, o agente estrangeiro não deveria colocar os pacotes sem encapsulamento no túnel reverso.

O recurso local que não precisava fazer a viagem

Imagine um computador que chega a outra rede e quer usar uma impressora disponível ali. O destino é local. O endereço que o computador conserva, porém, pertence à sua rede de origem. Se a solução para manter esse endereço exigir que cada pacote volte primeiro à origem, até uma comunicação próxima passa a depender de um trajeto distante.

O RFC 3024, publicado em janeiro de 2001, trata dessa distinção ao definir o túnel reverso de Mobile IPv4. Uma das formas de entrega permite ao nó móvel indicar, pelo encapsulamento, quais pacotes devem seguir para o agente de origem. Os que chegam sem essa indicação recebem encaminhamento normal.

Não há promessa de que a impressora sempre estará acessível. Rotas e políticas locais continuam valendo. O ponto é mais específico: o protocolo pode preservar a escolha de tentar a comunicação local, em vez de transformar a rede de origem em passagem obrigatória para tudo.

Essa escolha só se torna interessante porque, em algumas situações, voltar à origem era justamente o que permitia transmitir. O problema começava na dupla função de um endereço IP: identificar uma ponta da comunicação e informar algo sobre o lugar de onde o pacote aparece.

Mobilidade sem trocar a ponta da conversa

Em outubro de 1996, o RFC 2002 descreveu uma forma de mobilidade entre sub-redes IPv4 na qual o nó mantinha seu endereço de origem. Um agente nessa rede fazia os pacotes recebidos seguirem até a localização atual, representada por um endereço de encaminhamento, o care-of address.

Esse endereço podia ser o de um agente estrangeiro que atendia vários nós. Nesse caso, o agente encerrava o túnel e entregava os dados localmente. Também podia ser um endereço obtido pelo próprio nó, que então encerrava o túnel. As duas situações não devem ser confundidas: usar um agente compartilhado não exige um IPv4 local exclusivo para cada visitante.

O caminho de entrada já precisava acomodar a mudança de localização. O de saída parecia mais simples. O modelo se apoiava na hipótese de que o roteamento considerava o destino, não a origem. O nó podia enviar diretamente para o correspondente, usando como fonte seu endereço habitual, sem passar necessariamente pelo agente de origem.

Mas uma fronteira de rede pode verificar a fonte antes de aceitar encaminhar o pacote. Uma rota para o destino não é autorização suficiente para apresentar qualquer endereço no outro campo do cabeçalho.

Um filtro pode recusar uma informação verdadeira

O RFC 2827, de maio de 2000, consolidou a recomendação de restringir os endereços de origem aceitos de redes conectadas a um provedor. A ideia era reduzir a falsificação, admitindo os prefixos apropriados para aquele ponto de entrada.

Para o nó móvel, a dificuldade não era necessariamente uma fraude. Seu endereço podia estar correto e pertencer de fato à rede de origem, mas não fazer parte do conjunto esperado na rede visitada. A informação verdadeira sobre a identidade do nó se tornava uma informação topologicamente inadequada naquele lugar.

O próprio RFC reconhecia a tensão com Mobile IP e apontava o túnel reverso. Portanto, não se trata de escolher entre uma rede que aceita tudo e uma mobilidade que abandona qualquer endereço estável. O problema pede que as duas funções sejam separadas.

Também não se deve atribuir demais ao filtro. Limitar a fonte a um prefixo não identifica cada emissor dentro dele. Uma falsificação que permaneça no intervalo permitido pode passar por essa verificação. Coerência topológica e autenticação continuam sendo propriedades diferentes.

A volta muda o cabeçalho de fora

O RFC 2344, de maio de 1998, definiu a extensão de túnel reverso depois revisada pelo RFC 3024. O sentido é reverso em relação ao túnel que leva tráfego do agente de origem até o nó móvel. Na volta, o pacote sai da rede visitada rumo ao agente de origem e só depois segue para o correspondente.

O mecanismo depende da distinção entre cabeçalhos interno e externo, explicada no RFC 2003. O pacote interno mantém os endereços das pontas da comunicação. O externo descreve as pontas do túnel. Na etapa entre o agente estrangeiro e o agente de origem, o endereço externo de origem é o care-of address do agente estrangeiro.

Assim, a rede visitada vê uma fonte adequada ao percurso externo. Dentro do pacote continua o endereço de origem do nó. O túnel não corrige uma suposta mentira do dispositivo; permite que duas informações verdadeiras, sobre identidade e posição de envio, ocupem lugares diferentes.

Isso não implica sigilo. Encapsular não é criptografar. Tampouco significa preservar cada bit do pacote interno, já que o encaminhamento pode alterar campos como o TTL. E a correspondência entre as pontas dos túneis nos dois sentidos não garante que os mesmos enlaces físicos sejam percorridos na ida e na volta.

Deixar o agente escolher ou marcar cada entrega

Na entrega direta, o nó usa o agente estrangeiro como roteador padrão. Envia seu pacote sem um invólucro adicional, e o agente o encapsula para a rede de origem. Essa modalidade atende ao tráfego unicast, mas não oferece túnel reverso seletivo.

Na entrega encapsulada, o nó primeiro envolve o pacote para entregá-lo especificamente ao agente estrangeiro. O agente retira essa camada e acrescenta outra, agora dirigida ao agente de origem. É uma sequência de duas operações, não uma única embalagem carregada intacta por todo o caminho.

Há um detalhe decisivo: na camada externa da primeira etapa, do nó ao agente estrangeiro, a origem ainda é o endereço de origem do nó móvel. O care-of address passa a ser fonte externa apenas quando o agente estrangeiro envia para o agente de origem. Antecipar essa troca na explicação equivale a dar ao nó o endereço do agente como se fosse seu.

Depois de negociar a entrega encapsulada, os pacotes que o nó enviar sem encapsulamento não devem entrar no túnel reverso. Seguem pelo encaminhamento comum. É nessa diferença que cabe a tentativa de usar a impressora local. O agente não pode apagar a escolha, mandando de volta todo pacote que reconheça como pertencente ao visitante.

A modalidade encapsulada também é necessária para transportar broadcast e multicast em sentido reverso por meio do agente estrangeiro. A diferença entre as modalidades, portanto, não é apenas um custo adicional de cabeçalho. Ela muda o conjunto de comunicações atendidas e a capacidade de seleção do nó.

A oferta tem de caber na negociação

O bit T em um anúncio de agente indica que o serviço de túnel reverso está disponível. Na solicitação de registro, o bit T indica que o nó quer utilizá-lo. Anunciar e aceitar uma solicitação são atos diferentes, e nenhum deles equivale a observar os dados chegando ao destino final.

A entrega encapsulada é pedida por uma extensão de tipo 130, com comprimento zero. Sua ausência significa pedido de entrega direta. A extensão não deve acompanhar uma solicitação com T desativado. Sua posição entre extensões de autenticação é definida, e o agente estrangeiro a processa sem repassá-la ao agente de origem.

O escopo dessa escolha é concreto: como o nó entrega dados ao agente estrangeiro. Não é uma declaração de compatibilidade de todos os equipamentos no percurso. O RFC 3024 deixa explícito que não oferece uma solução geral para atravessar firewalls.

Até a obrigação de implementar as modalidades mudou. O RFC 2344 exigia ambas de um agente que anunciasse túnel reverso. O RFC 3024 manteve a direta obrigatória e tornou a encapsulada recomendada. O código 79 informa que a modalidade de entrega solicitada não é suportada.

O registro Mobile IP da IANA confirma essa atribuição. Uma observação antiga no meio do RFC 3024 ainda diz que 79 não estava atribuído, mas a seção de alocações e o apêndice de mudanças do próprio texto já registram a alteração. Não é seguro transformar essa observação isolada em descrição do estado atual.

Registrar não resolve todas as portas

Se o agente rejeita um pedido de túnel reverso, o nó pode tentar novamente sem T e obter um registro aceito. O RFC 3024 alerta que esse resultado pode ser inútil para o tráfego: se a rede visitada exige a adaptação da fonte externa, o mecanismo indispensável acabou de ser retirado.

O sucesso do registro continua sendo real, mas limitado. Ele diz que certas condições foram aceitas, não que elas bastam para a comunicação. Uma tentativa de compatibilidade pode substituir uma rejeição clara por um problema posterior, mais difícil de localizar.

A segurança também se divide em verificações. A solicitação deve usar TTL 255, e o agente estrangeiro exige receber esse valor. A passagem por um roteador IP reduz o TTL, o que limita algumas tentativas de se passar por um nó do mesmo enlace vindo de fora. Isso não autentica um vizinho que já esteja no enlace.

O agente de origem deve implementar a comparação com a associação registrada, e a recomendação é deixá-la ativa por padrão. Fonte externa, fonte interna e modalidade de encapsulamento precisam corresponder ao care-of address, ao endereço de origem e ao modo acordado. Sem associação ou com modalidade incorreta, o pacote deve ser descartado.

Essa comparação restringe o serviço de trânsito, mas não autentica criptograficamente cada dado. A própria descrição da atualização de estado exige uma correção: a errata técnica verificada do RFC 3024 troca uma referência à resposta de registro pela solicitação de registro. A direção da mensagem importa para entender quem fornece a informação que altera a associação.

Quando os endereços privados se repetem

O corpo principal do RFC 3024 pressupõe um espaço comum de endereços. O apêndice examina arranjos limitados com espaços distintos, não uma solução universal para sobreposição de endereços privados. Os agentes ainda precisam alcançar um ao outro no espaço externo, e os endereços internos precisam ter significado nos respectivos contextos.

Em certos arranjos, redes de origem diferentes podem reutilizar o mesmo endereço privado. O agente estrangeiro precisa do contexto dos agentes e do nó para distinguir o tráfego. Na entrega local, a associação com a identidade no enlace também é fundamental. A seção de segurança exige identificação segura nesse nível e não recomenda um Ethernet compartilhado sem autenticação para esse caso.

Em novembro de 2010, o RFC 5944 ainda remetia ao túnel reverso ao tratar de filtros de entrada. Isso mostra a continuidade do problema arquitetônico, não quantos operadores utilizavam a solução.

O recurso local do começo ajuda a resumir a escolha sem simplificá-la demais. O nó precisava conservar seu endereço, a rede visitada precisava reconhecer uma fonte apropriada e nem toda comunicação precisava voltar à origem. O túnel foi útil por distinguir essas necessidades, não por prometer que uma única rota resolveria todas elas.