Resumo

  • Dois endereços, dois roteadores e dois resolvedores não formam automaticamente redundância; uma combinação cruzada pode ser inválida embora cada componente esteja disponível.
  • O recibo operacional deve ligar DNS, endereço de origem e primeiro salto à mesma tentativa, sem confundir política recebida, escolha aplicada, aceitação do provedor e resposta do serviço.

O notebook exibe Wi‑Fi, rede móvel e VPN como conexões ativas. O DNS respondeu, o sistema escolheu um endereço IPv6 global e há um roteador padrão alcançável. Mesmo assim, a aplicação não recebe resposta. O erro está numa frase que os três painéis não conseguem formar juntos: o nome veio do VPN, a origem pertence à banda larga e a porta escolhida aponta para a rede móvel.

A RFC 7157, IPv6 Multihoming without Network Address Translation, organiza esse problema. Publicada em março de 2014 como RFC Informativa que reflete consenso do IETF, ela traz O. Troan como editor, ao lado de David Miles, Satoru Matsushima, Takashi Okimoto e Dan Wing. O perfil oficial de Ole Trøan no Datatracker registra essa participação. É evidência de trabalho editorial coletivo, não de invenção isolada, comando sobre redes reais ou autoria das especificações que vieram depois.

O ponto inicial é o conjunto de tarefas escondido no NAPT. Na prática comum do IPv4, o equipamento de borda não apenas reescreve endereços. Ele escolhe um endereço de origem externo, resolve o próximo salto e, em algumas instalações, intermedeia o DNS. O host interno usa um endereço privado e uma porta aparente. A relação entre endereço público, provedor, caminho e mapa de nomes fica concentrada numa caixa.

Com IPv6, um pequeno escritório pode receber um prefixo global de cada provedor. Um dispositivo pode manter mais de uma interface e adicionar um túnel corporativo. Isso favorece conectividade transparente de ponta a ponta sem obrigar todo fluxo a atravessar um tradutor invisível. Mas o tamanho do espaço de endereços não diz quais configurações pertencem à mesma rede de provisão.

A RFC 7157 enumera três escolhas necessárias antes do primeiro pacote. O host precisa selecionar o endereço de origem apropriado, o primeiro salto compatível e o servidor DNS recursivo que conhece o espaço de nomes desejado. Provedores costumam aplicar filtragem de ingresso contra falsificação de origem. Um pacote com prefixo legitimamente atribuído pelo provedor A pode ser descartado quando sai pelo provedor B. Validade individual não garante validade da composição.

A primeira decisão é a origem. A RFC 6724 define algoritmos padrão para seleção de endereços de origem e destino e admite uma tabela de políticas administrativas. A RFC 7157 observa que, diante de vários prefixos de provedores, o comportamento padrão pode não resolver de modo determinístico a fonte adequada. A RFC 7078 cria uma opção DHCPv6 para distribuir a tabela. Esse transporte não fecha a prova: receber a opção não demonstra que o host a instalou, que ela continua vigente ou que foi consultada para este pacote.

A segunda decisão é a porta. Router Advertisements de redes diferentes podem manter dois roteadores padrão válidos. Selecionar qualquer um deles pode entregar uma origem correta ao upstream errado. A RFC 8028, publicada depois como Standards Track, explicita a ordem: o host escolhe a origem antes do primeiro salto e deve procurar um roteador que tenha anunciado o prefixo daquela origem. Fred Baker e Brian Carpenter são os autores. Ole Troan aparece nos agradecimentos por texto importante; contribuição e autoria continuam registros distintos.

A terceira decisão é o DNS. Um VPN pode ter nomes que não existem na Internet pública. Um provedor pode responder de forma diferente conforme a origem da consulta. Escolher o resolvedor mais rápido pode produzir um endereço real que não funciona na saída selecionada. A RFC 7157 discute política associada ao espaço de nomes e cita a RFC 6731 para seleção de DNS distribuída por DHCPv6. A resposta precisa preservar o contexto da consulta para que seu significado sobreviva.

As decisões seguem uma sequência, mas não pertencem ao mesmo ator. A aplicação declara um nome e uma finalidade. A política DNS escolhe um domínio de provisão e obtém destinos. O host seleciona a origem. A pilha de rede escolhe o primeiro salto. O gateway e os filtros do provedor decidem aceitar ou descartar. O serviço remoto responde ou permanece silencioso. Guardar apenas “IPv6 funcionou” elimina as relações que explicariam a próxima falha.

As alternativas também exigem leitura sem slogans. A RFC 7157 afirma que NAT e NPTv6 devem ser evitados quando possível para preservar a transparência ponta a ponta. Na conclusão, considera adequadas soluções baseadas em DHCPv6 para os problemas analisados e admite que NPTv6 pode ser necessário como etapa intermediária. A RFC 6296 descreve tradução stateless de prefixo IPv6. Nenhuma dessas frases ordena adoção ou rejeição universal.

Trabalhos posteriores deram forma ao agrupamento das configurações. A RFC 7556 define Provisioning Domain, ou PvD, como conjunto coerente de informações: prefixos de origem, servidores e sufixos DNS, gateway padrão e outros elementos. O modelo procura impedir que um nó misture dados de domínios diferentes sem intenção. A RFC 8801 permite anunciar um identificador PvD baseado em FQDN e oferecer informações JSON opcionais. O identificador associa peças; não comprova confiança, alcance presente nem sucesso da aplicação.

O registro que merece auditoria é uma tentativa de conexão. Um identificador comum deve ligar nome e intenção, PvD e resolvedor escolhidos, origem e interface da consulta, conjunto de respostas e TTL, destino escolhido, fontes candidatas, fonte efetiva, versão da política, roteadores candidatos, primeiro salto, prefixos anunciados, estado de vizinhança, decisão de filtro, mudanças em novas tentativas e qualquer observação do upstream ou do destino. Tempos monotônicos preservam a ordem quando o relógio civil é corrigido.

Cada campo tem limite próprio. Endereço configurado não é endereço selecionado. Origem selecionada não é origem aceita. Anúncio de roteador não é comprovante de encaminhamento. Resposta DNS não é entrega. Uma resposta da aplicação comprova somente que uma combinação funcionou naquele momento; não valida todos os destinos, namespaces e caminhos de contingência.

É assim que o papel documentado de Trøan continua útil. A RFC não promete simplicidade automática. Ela separa as decisões antes escondidas, abrindo espaço para política local e prova verificável. Transparência não significa ausência de controle. Significa poder ver a origem do controle, sua duração, sua aplicação e sua saída.

Fontes