Resumo
- O rascunho individual HCGA propõe usar uma chave pública para derivar os bits entre o prefixo agregado controlado pelo operador e o limite /64, ampliando o vínculo do RFC 3972.
- Com um agregado /48, essa parte tem 16 bits. Outra chave pode coincidir em cerca de 2^16 tentativas; a rede precisa registrar qual delas foi admitida e fiscalizar a origem dos pacotes.
Uma sub-rede pode receber duas credenciais matematicamente plausíveis. O rascunho Hierarchical Cryptographically Generated Addresses transforma essa disputa em questão operacional: uma carga de trabalho ganha um IPv6 /64 calculado com sua chave pública, mas o cálculo não escolhe o titular quando outra chave atinge os mesmos bits. O livro de entradas da rede passa a valer tanto quanto a equação.
O RFC 3972 já liga o identificador de interface, na parte inferior do IPv6, a uma chave pública. O prefixo /64 vem da infraestrutura. HCGA levaria a derivação para a faixa entre o agregado do operador e o /64, usando chave e modificador de prefixo. Para conferir o resultado depois, o verificador precisa da chave, dos modificadores e da contagem de colisões retidos na geração.
O trecho de segurança dá a medida do problema. Um /48 deixa 16 bits para formar o /64. Uma segunda chave ou outro modificador pode encontrar esses mesmos bits após aproximadamente 2^16 tentativas. É uma colisão de sub-rede, não uma quebra da chave privada nem uma falsificação de todos os 128 bits do endereço nesse número de tentativas. O identificador de interface tem outro limite de saída de hash, muito maior. Ainda assim, o /64 sozinho deixa de identificar uma chave de modo exclusivo.
Por isso a proposta pede a uma arquitetura em torno dela um registro da chave e do modificador aceitos para cada /64, com exclusividade. A mesma arquitetura precisa manter os parâmetros para uma auditoria fora do enlace local. Um pacote com o endereço correto exige ainda prova de origem: assinatura da chave privada correspondente ou imposição de endereço de origem pela rede. Sem esse controle, qualquer leitura da identidade pelo endereço confunde declaração com autoria.
A autorização de rota cobre um território mais amplo. O operador anuncia o agregado via BGP sob uma ROA do RPKI; os /64 internos não são anunciados externamente. Uma ROA válida sustenta a origem do agregado. Ela não escolhe qual chave entrou em uma sub-rede interna. Essa escolha, sua guarda documental e sua fiscalização ficam no domínio do operador.
Há um efeito colateral observável. O /64 previsto continua estável quando o identificador de interface muda, permitindo relacionar sessões da mesma carga de trabalho. O RFC 8981 trata de endereços temporários com outra meta de privacidade. A verificação HCGA também não revela a força do armazenamento da chave; o RFC 9334 descreve uma arquitetura separada de atestação.
O Datatracker do IETF registra o texto de 27 de outubro como rascunho individual Standards Track, ainda em «I-D Exists». Um ensaio útil produziria duas chaves que coincidam nos 16 bits sob um /48 de teste, barraria a segunda e pediria a um verificador distante que recuperasse a primeira, os parâmetros e a prova de origem de um pacote. É assim que a suposta identidade se transforma em procedimento verificável.
Briefing para membros
Contexto aprofundado do perfil
Faça login com o nível de assinatura correto para desbloquear o briefing completo e as notas das fontes.
Apenas para Strategic Circle
Strategic Circle
Aberto a todos os leitores. Desbloqueie Briefings de perfil após se inscrever e fazer login.
Junte-se ao Strategic CircleSomente para Leadership Alliance
Leadership Alliance
Para proprietários e gestores qualificados de ativos de PI; faça login para desbloquear os briefings da Leadership Alliance.
Junte-se ao Leadership Alliance





