Resumo
- O identificador global pseudoaleatório de 40 bits da RFC 4193 faz com que prefixos ULA gerados separadamente tenham probabilidade muito alta de serem diferentes; ele não é registro, certificado ou alocação.
- “Global” descreve o objetivo de unicidade, não alcance público. O encaminhamento de ULA deve ficar no local ou em conexões entre locais aprovadas de forma explícita.
- Numa fusão ou VPN, a decisão depende dos valores reais: comparar todos os
/48, limitar rotas e DNS, manter segurança independente e prever renumeração ou retorno.
Há uma pergunta simples que costuma desaparecer de um projeto de integração: se os dois prefixos estão disponíveis na mesma planilha, por que confiar apenas na chance de serem diferentes?
A chance é excelente. A RFC 4193 foi feita para isso. Mas a possibilidade de comparar é melhor.
Publicada em outubro de 2005 como Proposed Standard, a RFC traz Robert Hinden e Brian Haberman como coautores e reconhece uma comunidade maior de colaboradores. Ela define os Unique Local Addresses, ou ULA, no bloco FC00::/7. O formato possui um bit L, um identificador global de 40 bits, um identificador de sub-rede de 16 bits e um identificador de interface de 64 bits. O valor L=1 representa a atribuição local descrita pelo documento e coloca a forma atualmente definida em FD00::/8.
O identificador não chega por solicitação a um registro. É produzido localmente de modo pseudoaleatório. A RFC proíbe sequências e valores conhecidos e sugere combinar o horário com um identificador específico do sistema, calcular SHA-1 e usar os 40 bits menos significativos.
Esse hash não transforma o processo em mecanismo criptográfico de confiança. Ele não autentica a equipe, não esconde a rede, não assina o prefixo e não comprova propriedade. Sua função é espalhar escolhas independentes por um espaço amplo.
A tabela de probabilidades da RFC expressa a promessa com precisão. Para dois identificadores produzidos de forma independente, a estimativa de colisão é de cerca de 1,81 × 10^-12. Para 10 mil identificadores, aproximadamente 4,54 × 10^-5. São números de um modelo, não uma medição da Internet. Eles justificam dispensar uma coordenação mundial antes da geração. Não justificam dispensar uma comparação concreta quando duas empresas já conhecem seus valores.
Também é preciso conter a palavra “global”. Ela qualifica a ambição de unicidade do identificador entre diferentes domínios administrativos. Não torna a rota globalmente alcançável. O registro atual da IANA para endereços IPv6 de uso especial classifica fc00::/7 como válido para origem e destino e passível de encaminhamento, porém não globalmente alcançável. A própria IANA ressalva que uma entrada no registro não garante roteabilidade em nenhum contexto.
O perímetro depende do operador
O uso normal previsto pela RFC 4193 é interno a um local ou restrito a locais que decidiram se conectar. A Internet deve ignorar FC00::/7 por padrão. Bordas devem filtrar rotas e pacotes ULA nos dois sentidos. Quando há uma exceção intencional, ela deve citar cada /48 necessário ou uma rota mais específica, e não liberar o bloco inteiro.
Isso impede tratar ULA como espaço incapaz de sair. Um roteador pode encaminhá-lo, um túnel pode carregá-lo e uma política de redistribuição pode vazá-lo. A fronteira nasce de filtros, topologia, responsabilidade e teste. Os primeiros bits não constroem um muro.
No DNS, a disciplina é semelhante. A RFC desaconselha publicar registros AAAA e PTR de ULA no DNS global porque a unicidade não é garantida. Consultas reversas de ULA não devem alcançar a infraestrutura DNS pública. Ao unir redes, portanto, é preciso levantar zonas internas, visões separadas, encaminhadores, zonas reversas e dependências de nomes nos aplicativos.
O prefixo também não configura hosts sozinho. Router Advertisement, DHCPv6, configuração manual, divisão de sub-redes e cadastro de nomes continuam sendo decisões separadas. A RFC 5375 explica que ULA pode coexistir com endereços IPv6 globais. Isso não equivale a recomendar tradução de endereços para IPv6.
Segurança pertence a outro plano. Serviços precisam autenticar e autorizar; firewalls precisam limitar fluxos; a origem de uma rota precisa ser avaliada; eventos precisam de registros. A RFC 4193 afirma que ULA não oferece segurança inerente. Um endereço local não prova quem enviou um pacote nem se a ação foi permitida.
A falha que o antigo escopo não resolvia
A RFC 3879 retirou os endereços site-local porque “local” não tinha uma interpretação única. Para uma organização com filiais, centros de dados e parceiros, o limite de um site podia variar conforme a equipe. Prefixos vazavam, aplicativos escolhiam o escopo errado e redes independentes chegavam a uma integração com blocos indistinguíveis.
O identificador aleatório corrige parte desse problema sem criar um alocador universal. Cada local escolhe seu espaço e mantém grande chance de já possuir uma marca diferente quando se conecta a outro. A RFC 5375 descreve essa vantagem para vazamentos e fusões: diminui a necessidade de renumerar imediatamente.
Não elimina a renumeração. A RFC 4193 desaconselha o roteamento mundial de ULA porque não existe garantia de unicidade e as rotas não têm agregação viável. Se dois locais conectados compartilham o mesmo ID, a comunicação pode falhar ou chegar ao destino errado. Um evento raro pode ter impacto elevado.
A autoria merece a mesma exatidão. Haberman divide a RFC com Hinden, e o texto registra outras contribuições. A página oficial de fotos do grupo IPv6 do IETF identifica Haberman e lista os dois como presidentes daquele grupo já concluído. Em agosto de 2026, a Internet Society o apresentava como presidente de seu Conselho, engenheiro distinto da Fastly, integrante da governança da NetDev e participante veterano do IETF, com trabalho inicial numa plataforma de roteadores IPv6. Essa trajetória situa a pessoa; as propriedades técnicas vêm dos documentos normativos.
O comprovante operacional de uma integração
O primeiro passo é reunir todos os /48 ativos e reservados dos dois lados. Produção não basta: entram laboratórios, nuvens, recuperação de desastre, parceiros VPN inativos, blocos futuros e endereços gravados em código ou modelos de configuração. Os valores completos são comparados. Se houver repetição, a decisão de renumerar precede a abertura de rotas.
Cada prefixo deve ter procedência operacional. Registre quando e como foi gerado, que classe de identificador do sistema participou e qual equipe o conserva. Não é necessário divulgar informação sensível do equipamento. É necessário descobrir se dez subsidiárias copiaram o mesmo modelo, cenário que deixa de ser uma geração independente.
Depois vem a admissão de rotas: nome da interconexão, prefixos permitidos, próximos saltos, filtros de importação e exportação, responsável pela observação e comando de retirada. Testes demonstram que o restante de FC00::/7 é recusado e que nenhum par de Internet recebe o anúncio.
DNS e seleção de endereço têm um ensaio próprio. IDs diferentes não impedem duas empresas de manter a mesma zona interna. Prefixos distintos tampouco impedem um aplicativo de preferir uma ULA inalcançável a um endereço global válido. Zonas autoritativas, visões, caminhos do resolvedor, consultas reversas e regras de preferência precisam ser observados.
A evidência de segurança fica separada. Qual identidade o serviço autentica? Que regra autoriza o fluxo? Qual firewall o contém? Qual fonte de rota é aceita? Qual log permite atribuir um incidente? A classificação ULA não responde a essas perguntas.
Por fim, o projeto estabelece a saída antes do corte. Uma colisão pode exigir renumeração. Um anúncio externo inesperado exige retirada. Vazamento de consulta reversa exige isolar o caminho DNS. Um aplicativo com literais pode manter as redes separadas até ser reparado. A reversão transforma a exceção estatística em risco controlável.
A primazia do código em funcionamento, de Heng Lu, aponta para a prova mais forte: tabelas de rotas, caminhos de pacotes, respostas de resolvedores e testes de aplicações mostram o comportamento, enquanto diagramas e declarações são registros administrativos. Sua especificação inicial mínima oferece o limite de coordenação: compartilhar o bastante para conectar com segurança e desfazer a conexão, sem centralizar todo o projeto interno.
Os 40 bits são uma infraestrutura de autonomia. Eles evitam que cada rede peça permissão antes de existir. Quando a autonomia cruza uma fronteira compartilhada, porém, ela precisa apresentar inventário, política e uma saída — não fingir que a probabilidade era um certificado.
Fontes
- RFC 4193 — Endereços IPv6 unicast locais únicos
- RFC 5375 — Considerações de atribuição de endereços IPv6 unicast
- RFC 3879 — Descontinuação dos endereços site-local
- IANA — Registro de endereços IPv6 de uso especial
- Internet Society — Entrevista com o novo presidente Brian Haberman
- IETF Datatracker — Fotos públicas do grupo IPv6
- Heng Lu — Primazia do código em funcionamento
- Heng Lu — Especificação inicial mínima
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
