Resumo

  • O RFC 3338 colocou um tradutor entre a API de sockets e as pilhas IPv4/IPv6 de um host. Diante de um par que tinha apenas AAAA, ele podia sintetizar uma resposta A com um valor de um conjunto IPv4 local e associá-lo ao endereço IPv6 real, sem traduzir cabeçalhos IP.
  • O valor visto pelo aplicativo era estado do tradutor com escopo e geração. Esgotamento do conjunto, descarte e reutilização, diferenças semânticas entre APIs e o descompasso entre o AAAA do host e o suporte IPv6 de uma porta podiam desfazer a ilusão.

O resolvedor devolvia uma forma que o programa antigo reconhecia

Um aplicativo restrito ao IPv4 esperava resultados no estilo de gethostbyname e estruturas de socket IPv4. Reescrevê-lo podia ser impossível: o código-fonte talvez não existisse mais, ou o fornecedor já não desse suporte ao binário. O RFC 3338 tratou desse intervalo de transição, no qual o host já tinha uma pilha IPv6 nativa, mas certos programas continuavam presos à interface antiga.

O resolvedor de nomes do BIA interceptava a chamada e procurava registros A e AAAA. Quando encontrava apenas AAAA, o mapeador escolhia um valor em seu conjunto IPv4 interno, guardava o par IPv4–IPv6 e construía uma resposta A para o aplicativo. O programa recebia a forma familiar de quatro bytes e seguia sem alteração.

Mais tarde, quando o programa entregava esse valor a uma função de socket IPv4, o mapeador de funções interceptava a operação, consultava o endereço IPv6 e chamava a API IPv6 correspondente. Os pacotes percorriam a pilha IPv6 nativa. Ao contrário do Bump-in-the-Stack do RFC 2767, o BIA não precisava reescrever cabeçalhos IPv4 e IPv6 na camada de rede.

O endereço aparente apontava para uma linha da tabela

Um endereço de rede comum convida a uma leitura persistente: esse valor identifica uma interface ou um destino remoto. O valor sintético do BIA dizia muito menos. Ele apontava para um endereço IPv6 somente dentro de determinada tabela, em determinado escopo e durante uma geração específica.

O RFC 3338 deu como exemplo um conjunto de valores não atribuídos, de 0.0.0.1 a 0.0.0.255. Eles não deveriam sair do host. Sua unicidade só importava dentro da fronteira do tradutor. Tabelas por máquina, usuário ou processo podiam dar significados diferentes aos mesmos bits.

Por isso, um log que guardasse apenas o valor sintético seria ambíguo. Uma prova útil precisava incluir o escopo da tabela, a geração da entrada, o gatilho de criação, o referente IPv6, o conjunto de respostas DNS e o processo proprietário. Aquele “endereço” se parecia mais com um descritor de arquivo do que com um destino mundialmente significativo.

A reutilização podia transformar o identificador de ontem no par de hoje

O conjunto era finito. Se muitos aplicativos IPv4 consultassem muitos hosts IPv6, os valores poderiam acabar. O RFC examinou a possibilidade de liberar o mapeamento mais antigo e reutilizar seu valor IPv4. A capacidade voltava, mas o referente mudava.

Uma cópia antiga retida num cache, num retorno tardio, num log ou no próprio aplicativo podia continuar parecendo válida. Depois da reutilização, porém, uma consulta à tabela a levaria a outro host IPv6. Não era necessário haver conflito no roteamento global: uma divergência de vida útil entre componentes da mesma máquina já bastava para produzir entrega e atribuição erradas.

A cadeia de evidência deve registrar alocação, último uso, descarte, reutilização e geração. Cada chamada de socket precisa ser associada à geração vigente naquele momento. Os mesmos quatro bytes antes e depois da reutilização não representam a mesma identidade operacional.

Traduzir uma função não preservava toda a semântica

O mapeador substituía funções de socket IPv4 por equivalentes IPv6, mas o RFC 3338 advertiu que as APIs não eram plenamente compatíveis. IPv6 tinha recursos sem paralelo direto no IPv4. Sockets brutos, dados auxiliares, valores ICMP, curingas e endereços embutidos em protocolos de aplicação exigiam trabalho dependente do sistema operacional.

Uma substituição que retornasse sucesso provava que uma chamada fora realizada, não que toda opção, todo erro e todo efeito colateral mantivessem o sentido original. O aplicativo podia depender da família de endereços, do tamanho da estrutura, de uma regra de curinga ou de um erro específico que o tradutor não conseguiria reproduzir exatamente.

O recibo deve separar o nome e os argumentos da API original, a API produzida, a conversão de opções, a implementação do sistema operacional, o estado retornado e a interpretação do aplicativo. “Sem tradução de cabeçalho” simplificava uma camada; não eliminava a tradução semântica.

Um AAAA do host não provava que a porta falava IPv6

Uma máquina de servidor com pilha dupla podia publicar AAAA porque alguns serviços aceitavam IPv6, enquanto o programa na porta escolhida continuava restrito ao IPv4. O cliente equipado com BIA podia seguir o caminho AAAA, chegar ao host e ainda fracassar na fronteira do serviço.

O RFC 3338 considerou tentar todos os endereços devolvidos. Em TCP, o BIA talvez observasse a falha de connect e avançasse para a próxima opção. Em UDP, uma transmissão bem-sucedida não produz necessariamente uma resposta imediata e observável; era difícil ou impossível para o tradutor descobrir sozinho qual endereço funcionou, e o aplicativo podia ter de controlar a iteração.

Essa diferença continua relevante. DNS demonstra que o nome tem registros. Alcance de rede demonstra que pacotes chegam ao endereço. Uma porta em escuta demonstra uma entrada de serviço. Sucesso da aplicação demonstra que a operação pretendida aconteceu. Um recibo não substitui o seguinte.

A ponte de compatibilidade podia adiar a migração

O RFC fixou um limite de produto incomumente direto. BIA tinha estado Experimental e servia a adotantes iniciais que possuíam IPv6, mas ainda executavam programas legados sem código-fonte disponível. Não era recomendado para a produção corrente. Se o código existisse, a aplicação deveria ser adaptada; o mecanismo não poderia virar desculpa para adiar essa tarefa.

O alerta reconhecia um risco institucional. Uma ponte que resolve a lacuna do dia acumula tabelas, exceções, observabilidade e dependências operacionais. A equipe atual ganha continuidade; operadores futuros herdam comportamento oculto no resolvedor e endereços cujo significado depende de estado. Remover a ponte pode acabar mais caro do que fazer a adaptação original.

Os critérios de encerramento devem fazer parte do registro de implantação: quais programas realmente se qualificam, quem é dono da migração, quais chamadas não têm suporte e que observação autoriza desligar o tradutor. “Temporário” sem essa saída costuma tornar-se arquitetura permanente.

A corrida de conexões posterior respondeu a outro desenho

O BIS do RFC 2767 inseria a tradução mais abaixo na pilha e dependia do SIIT do RFC 2765. O RFC 3338 deslocou deliberadamente a adaptação para a fronteira da API. O RFC 2893 descreveu o contexto contemporâneo de transição, o RFC 3493 documentou extensões básicas de sockets IPv6 e o RFC 4038 reuniu aspectos de migração de aplicações.

O RFC 6555 e sua atualização, o RFC 8305, definiram mais tarde técnicas de Happy Eyeballs que ordenam ou disputam tentativas entre famílias de endereços. Elas reduzem demora e falha sem transformar um IPv4 sintético em apelido privado de um par IPv6. Projetar esse algoritmo posterior sobre o BIA apagaria a diferença histórica entre escolher candidatos reais e fabricar um identificador local mutável.

O RFC 4291 define o endereçamento IPv6, mas não dá significado global ao conjunto IPv4 interno do BIA. Nenhum desses documentos demonstra que um fornecedor ou operador tenha de fato implantado o RFC 3338; texto normativo descreve uma possibilidade, não comprova adoção.

Todo identificador de compatibilidade precisa de uma geração

O movimento elegante do BIA foi preservar a interface percebida pelo programa e mudar a implementação abaixo dela. O custo foi o estado oculto. O que parecia endereço tornou-se referência a uma tabela mutável; o que parecia uma chamada comum tornou-se tradução interceptada.

A lição operacional duradoura é guardar tanto a representação quanto a autoridade que a interpreta. Uma resposta A sintética deve vir com o recibo de mapeamento. A chamada traduzida deve conservar sua origem e seu resultado. A conexão deve registrar o endereço IPv6 e a porta reais, o desfecho do transporte e o resultado da aplicação.

Sem esses vínculos, o investigador encontra um número com formato IPv4 e lhe atribui um alcance global que nunca existiu. O RFC 3338 foi um mecanismo de transição e também uma lição sobre identificadores: os bits não são a identidade; o mapeamento vivo e verificável é que lhes dá sentido.

Fontes