Resumo

  • O PvD é uma fronteira de coerência para endereço de origem, DNS, primeiro salto e demais parâmetros. FQDN, sinalizadores e número de sequência identificam e atualizam essa fronteira, mas não funcionam como preferência de rota.
  • A confiança depende de uma cadeia: buscar as informações adicionais pelo próprio PvD, autenticar o identificador, conferir validade e prefixos, aplicar a política local e registrar qual origem, resolvedor, roteador e destino apareceram na conexão executada.

O domínio mais reconhecível não servia ao navegador

Um host recebe dois PvDs explícitos no mesmo enlace. O primeiro usa o FQDN de uma operadora conhecida, traz o sinalizador H e uma sequência recém-alterada. O painel de rede interpreta esses sinais como prova de escolha.

Só que o JSON autenticado desse PvD contém noInternet: true. O domínio entrega corretamente serviços locais restritos. Para abrir um site público, a política do host seleciona o segundo PvD, que oferece acesso geral. Um aplicativo corporativo ainda pode escolher o primeiro.

Nenhuma parte está defeituosa. O nome identifica, a sequência atualiza, noInternet limita o escopo e o host decide. O erro nasceu ao reduzir quatro afirmações a um único rótulo de “selecionado”.

Em hosts com mais de um acesso, a mistura de configurações é um risco recorrente. Uma origem de uma rede pode ser usada com o DNS de outra e o gateway de uma terceira. Cada componente parece válido isoladamente, mas o retorno, a resolução ou a política deixam de ser coerentes. A RFC 7556 criou o conceito de Provisioning Domain para preservar o contexto de cada conjunto.

Uma fronteira lógica, não uma placa de rede

A RFC 7556 define PvD como um conjunto consistente de informações de configuração. Prefixos de origem, servidores DNS, sufixos de busca, proxy e gateway padrão são exemplos.

Vários PvDs podem chegar pelo mesmo enlace; um PvD também pode atravessar mais de um enlace. Logo, interface e domínio não são sinônimos. A interface descreve onde os dados chegaram. O PvD descreve quais dados podem operar juntos.

Há domínios implícitos, inferidos da fonte, e domínios explícitos, marcados por uma identidade. Em ambos, o host preserva a associação entre configuração e origem. Para cada conexão, sistema operacional, usuário ou aplicativo escolhe um domínio segundo segurança, custo, alcance ou preferência e então usa parâmetros pertencentes a ele.

A arquitetura não impõe um ranking mundial. Uma rede industrial restrita pode ser a melhor opção para controle e a pior para navegação. O mesmo aparelho pode usar domínios distintos ao mesmo tempo sem declarar um vencedor absoluto.

O anúncio oferece um contexto

A RFC 8801 define a opção PvD de tipo 21 nas Router Advertisements IPv6. Ela carrega o PvD ID como FQDN, os sinalizadores H/L/R, sequência de 16 bits, Delay e, em certas formas, informações RA internas.

O operador deve possuir e administrar o FQDN anunciado. O mesmo ID só deve representar serviço realmente idêntico; ofertas diferentes merecem nomes distintos. Essa regra cria estabilidade administrativa, mas não autentica automaticamente o roteador local. Um emissor malicioso no enlace também pode escrever um nome conhecido.

H informa que há dados adicionais via HTTPS. L associa dados herdados de DHCPv4. R indica cabeçalho e opções RA internos para hosts conscientes de PvD. Nenhum deles significa “prefira este domínio”. H tampouco prova que a busca ou a validação terminou.

A sequência marca a geração da informação de um domínio. Ao mudar, invalida o objeto anterior e pode iniciar nova busca com atraso aleatório. Comparar a sequência 42 de um PvD com a 7 de outro não estabelece precedência. Delay controla carga, não prioridade.

A consulta precisa permanecer no domínio avaliado

Com H ativo, o host pode acessar https://<PvD-ID>/.well-known/pvd. Sem H, não deve usar esse mecanismo. A resposta é application/pvd+json.

DNS do PvD ID, verificações de certificado, HTTPS, endereço de origem e próximo salto da busca têm de usar exclusivamente a configuração daquele PvD. Resolver o nome em uma rede e baixar o objeto por outra desmonta a própria ligação que a operação deveria confirmar.

Isso importa em redes com DNS dividido, rotas dependentes do prefixo de origem e nomes internos. Consultar um FQDN corporativo por um acesso alheio pode revelar onde o dispositivo esteve. Por isso, uma auditoria que guarda só a URL não preserva prova suficiente.

O certificado TLS deve apresentar DNS-ID igual ao PvD ID. Se a validação falhar, a conexão é fechada e o domínio é tratado como se não tivesse informações adicionais. O certificado prova autorização do titular do FQDN para o serviço HTTPS; não prova sozinho que a RA local é legítima nem que os prefixos combinam.

Identidade e prefixos precisam concordar

O JSON válido inclui identifier, expires e prefixes. O identificador coincide com o nome anunciado, a expiração está no futuro e os prefixos cobrem todas as Prefix Information Options associadas à RA. Campo obrigatório ausente ou inválido faz o host ignorar o objeto; prefixo descoberto fora da cobertura caracteriza configuração incorreta.

O desenho cruza duas declarações. O roteador diz que um conjunto pertence a um nome. O serviço autenticado afirma que esse nome reconhece determinados prefixos. Quem controla apenas um lado não recebe autoridade sobre toda a relação.

dnsZones pode informar zonas acessíveis no domínio. noInternet: true indica acesso restrito, não falha. Para ambiente fabril, hospitalar ou empresarial, um caminho fechado pode ser o produto correto.

Chaves desconhecidas são ignoradas. A IANA mantém o registro compartilhado; extensões privadas devem ficar em subdicionários organizacionais ou vendor-*. Registro define significado interoperável, mas não confirma a veracidade de uma instância.

Atualização também tem limites

Mudança de sequência ou expiração torna obsoleta a informação armazenada. Delay e janelas aleatórias evitam atualizações simultâneas de milhares de hosts. Relógios podem estar errados, portanto a hora absoluta de expiração não deve, isoladamente, comandar decisões sensíveis de segurança.

Uma RA maliciosa poderia provocar DNS, TLS e HTTP contra muitos servidores. O host limita frequência, para de consultar um ID após erro de certificado, HTTP ou JSON durante a conexão atual e, depois de dez falhas ou mais, interrompe todas as buscas PvD naquele vínculo de rede.

Ao ativar H, o operador assume o dever de manter DNS, validação de certificado e HTTPS acessíveis até antes do login em captive portal. O host, por sua vez, deve preferir um endereço IPv6 temporário do próprio domínio e evitar cookies ou cabeçalhos identificáveis.

O uso real encerra a decisão

Depois da validação, o host ainda escolhe por finalidade. O operador nomeia e provisiona um contexto. O dono do FQDN autentica o serviço de informação. O JSON descreve propriedades. A política local determina se elas atendem à conexão.

A evidência final não é o emblema exibido no painel, mas a combinação observada de origem, DNS, primeiro salto, destino e resultado. Running-Code Primacy pede exatamente isso: respeitar a especificação mínima e verificar como o código em execução aplicou suas associações.

Fontes