Resumo

  • IPv4 como serviço não elimina a dependência de IPv4; desloca-a para DNS64, descoberta de prefixo, CLAT, estado do PLAT e portas compartilhadas.
  • IPv6 nativo pode continuar normal enquanto falham apenas nomes IPv4, literais ou sessões traduzidas já estabelecidas.
  • A operação precisa de um recibo datado que una resolvedor, Pref64, caminho CLAT, estado e failover do PLAT, atribuição e limites de entrada.

O assinante muda o DNS no roteador de casa. Serviços nativos em IPv6 continuam abrindo. Um destino que só publica registro A deixa de receber um AAAA sintetizado e some. Em outro equipamento, o mesmo destino ainda funciona porque o CLAT aceita o pacote IPv4 e aprende o prefixo de tradução por outro mecanismo. Os dois acessos aparecem como “conectados”, mas a continuidade depende de caminhos diferentes.

Esse é o lado operacional do IPv4-as-a-Service, ou IPv4aaS. A operadora pode retirar IPv4 nativo do acesso ou do núcleo e manter a chegada a servidores IPv4 por tradução. O endereço público deixa de ser entregue de ponta a ponta a um assinante. A compatibilidade passa a ser montada pelo resolvedor, sistema operacional, equipamento do cliente, roteamento e tradutor da operadora.

Um endereço sintetizado promete um caminho

A RFC 6147 define DNS64. Quando uma consulta AAAA encontra apenas um registro A, o DNS64 pode inserir o IPv4 em um prefixo IPv6 de tradução, Pref64::/n, e devolver um AAAA sintético. O cliente envia então um pacote IPv6 para essa representação.

O prefixo precisa chegar ao NAT64 configurado com a mesma regra. O resolvedor e o tradutor não negociam isso a cada consulta. Uma resposta DNS bem-sucedida comprova a síntese, não a capacidade do PLAT, o alinhamento do prefixo ou a preservação de uma sessão.

DNSSEC torna essa fronteira explícita porque a síntese modifica uma resposta. Validação e síntese podem coexistir quando sua posição é planejada. O recibo deve registrar resolvedor, respostas A e AAAA, resultado DNSSEC e Pref64 observado.

O CLAT cobre endereços literais, não todo o IPv4

A RFC 6877 descreve 464XLAT. O CLAT sem estado, no terminal ou equipamento do cliente, converte IPv4 para IPv6. O PLAT com estado, na rede da operadora, converte de volta. Um aplicativo que usa nome pode aproveitar DNS64 e uma única tradução com estado. Um aplicativo que usa literal IPv4 ou API antiga depende do CLAT para a primeira etapa.

Por isso, trocar o resolvedor não produz um sintoma único. A RFC 8683 explica que NAT64 sem CLAT pode perder destinos IPv4 quando o usuário escolhe um DNS externo sem síntese. Com 464XLAT, o tráfego pode sobreviver sem DNS64 se o CLAT descobrir o Pref64 correto. Se o resolvedor sintetizar outro prefixo, o pacote ainda pode deixar de alcançar o PLAT esperado.

464XLAT também não recria IPv4 completo. A RFC 6877 cobre o modelo cliente-servidor rumo a servidores com IPv4 global; não fornece automaticamente entrada IPv4 geral nem qualquer comunicação ponto a ponto. Esses limites precisam aparecer na oferta e nos roteiros de suporte.

Pref64 tem escopo e validade

A RFC 8781 define a opção PREF64 em anúncios de roteador IPv6. Ela carrega comprimento e tempo de vida do prefixo; zero indica que ele não deve mais ser usado. O host deve associá-lo à interface recebida e, quando aplicável, ao domínio de provisionamento. Roteadores devem observar e registrar anúncios inconsistentes no mesmo enlace.

Logo, “o equipamento conhece Pref64” é pouco. O registro útil contém mecanismo de descoberta, prefixo, validade restante, interface ou PvD e consistência dos anúncios. Um prefixo antigo pode apontar para tradutor retirado; uma validade curta pode terminar antes do próximo anúncio válido.

Failover de equipamento não garante estado de sessão

A RFC 6146 define NAT64 com estado. O PLAT conserva vínculos e sessões para devolver pacotes ao cliente IPv6. Também deve limitar recursos usados por fragmentos contra esgotamento. A RFC não faz dois tradutores compartilharem sessões automaticamente.

Depois do failover, novas conexões podem funcionar e downloads, pagamentos ou túneis antigos podem cair. Uma sonda que abre TCP só depois da troca declara recuperação. O teste correto mantém a mesma sessão antes e depois, identifica o PLAT ativo, registra margem de estado, evento de failover e resultado esperado das associações existentes.

A RFC 9099 acrescenta pressão sobre estado, interação entre DNS64 e DNSSEC e interferência com a maioria dos usos de IPsec sem encapsulamento UDP. 464XLAT sem DNS64 evita a síntese, não as demais fronteiras.

Eficiência de endereço muda a obrigação contábil

A RFC 9313 compara cinco tecnologias IPv4aaS. Em 464XLAT, o NAT64 da operadora guarda estado por fluxo e distribui portas públicas dinamicamente. Isso melhora o compartilhamento de IPv4, mas concentra capacidade, recuperação e registro.

Quando vários assinantes usam o mesmo endereço público, atribuir endereço e porta exige um mapa ligado ao tempo. Registrar cada sessão custa mais. Conceder um bloco de portas por período reduz registros e perde eficiência. A escolha também depende da legislação; a RFC não estabelece retenção global.

Estado na operadora não entrega automaticamente uma porta pública de entrada. Certos servidores precisam de PCP ou mapeamento explícito. É um limite arquitetônico, não uma falha misteriosa.

As fontes não estabelecem adoção mundial em 2026, ganho universal ou taxa típica de falha. Elas estabelecem uma cadeia que pode ser observada e testada.

Fontes

  1. RFC 6146 — NAT64 com estado
  2. RFC 6147 — DNS64
  3. RFC 6877 — 464XLAT
  4. RFC 8683 — implantação de NAT64/464XLAT
  5. RFC 8781 — descoberta de PREF64
  6. RFC 9099 — segurança operacional em IPv6
  7. RFC 9313 — tecnologias IPv4aaS