Resumo

  • A RFC 3316 recomendou reaproveitar uma confirmação TCP nova, um relatório de recepção RTCP ou uma resposta SIP como evidência positiva de que tráfego recente atravessara o roteador do primeiro salto.
  • A inferência era limitada: podia atualizar o estado do vizinho e evitar uma sondagem NUD, mas não provava conclusão da aplicação, conectividade futura nem a validade de qualquer pacote recebido como teste do caminho de ida.

Em um enlace IPv6 celular do começo dos anos 2000, o pacote caro nem sempre carregava dados úteis. Às vezes ele fazia uma pergunta de controle para a qual o host já possuía uma resposta produzida por outra camada.

O Neighbor Unreachability Detection, NUD, mantém uma avaliação recente sobre o próximo salto. Quando essa confiança envelhece enquanto há tráfego ativo, o host pode enviar uma Neighbor Solicitation unicast e aguardar uma Neighbor Advertisement solicitada. Na Ethernet, a troca combina com a resolução de endereços. O GPRS e o UMTS descritos pela RFC 3316 formavam outro ambiente: o enlace se parecia com ponto a ponto, o host celular tinha como único vizinho o roteador padrão já descoberto e não havia endereço de camada 2 para resolver. A resolução era dispensável; detectar um primeiro salto falho, não.

O perfil então perguntava se outro protocolo já havia demonstrado que um pacote enviado há pouco avançara no sentido de saída.

A regra geral de Neighbor Discovery fornecia o raciocínio. Uma confirmação TCP nova mostra que dados enviados anteriormente chegaram ao par remoto. Se esse par está fora do enlace, o pacote necessariamente atravessou o roteador de primeiro salto. A confirmação fim a fim carrega, portanto, um fato local: o próximo salto estava alcançável quando o pacote passou. O host pode usar esse fato no Neighbor Cache em vez de gastar uma troca apenas para sondar o roteador.

A RFC 3316 estendeu a lógica às aplicações celulares baseadas em UDP. O UDP não confirma entrega sozinho; a aplicação precisava expor um sinal com a causalidade adequada. Para RTP, um bloco de relatório RTCP que mostrasse a chegada de alguns pacotes ao par podia servir. Em SIP, a resposta a uma requisição mostrava que a requisição saiu e chegou. Quando o host celular atuava no lado servidor SIP, apenas transmitir a resposta em geral não bastava; receber depois o ACK podia mostrar que a resposta ao INVITE alcançara o outro lado.

Esses sinais não eram luzes verdes equivalentes. Cada um precisava implicar a entrega de tráfego de saída recente. Um datagrama recebido sem relação não valia. Uma Router Advertisement não solicitada também não: ela demonstrava somente o caminho do roteador para o host, enquanto o NUD precisava avaliar o caminho do host para seu próximo salto. Ver atividade não é o mesmo que provar a direção examinada.

O estado obtido também era temporário. Uma confirmação superior podia colocar a entrada do Neighbor Cache em REACHABLE por um intervalo limitado. Sem nova prova, ela envelhecia para STALE; ao voltar a enviar, podia passar por DELAY e chegar a PROBE, quando as Neighbor Solicitations dedicadas retornavam. A RFC 3316 não aboliu o NUD. Evitou repetir uma pergunta enquanto a aplicação ativa já fornecia uma resposta válida.

Havia um motivo econômico concreto. A banda de rádio era limitada e o usuário podia pagar pelo volume transferido. Retirar mensagens desnecessárias podia proteger capacidade e custo. A RFC, porém, não mediu economia de pacotes, bateria ou cobrança. Ela descreveu uma política de implementação baseada na topologia e nas evidências existentes no fluxo.

O mecanismo sobreviveu ao documento. A RFC 7066 substituiu a RFC 3316 em 2013, atualizou o modelo para incluir EPS, manteve os exemplos de TCP, RTCP e SIP e acrescentou a resposta DNS. Essa continuidade mostra que a inferência permaneceu no perfil, não quais aparelhos a implementaram nem quantas sondagens foram evitadas.

A lição não é entregar o roteamento à aplicação. É permitir que uma máquina de estados reutilize evidência de outra camada somente quando a implicação estiver clara. O retorno remoto diz algo sobre o primeiro salto porque o pacote de saída precisou atravessá-lo. A conclusão termina ali: relatório RTCP não prova mídia boa; resposta SIP não prova chamada concluída; roteador alcançável não prova serviço disponível; e um pacote bem-sucedido não garante o próximo.

Fontes: RFC 3316, RFC 2461, RFC 4861, RFC 7066, RFC 7849, RFC 8504, RFC 3550 e RFC 3261.