Formatador de compressão de zeros de endereço IPv6 | Canonicalize pela RFC 5952
Insira um endereço IPv6 e obtenha quatro formas lado a lado: a comprimida canônica RFC 5952, a totalmente expandida de oito grupos, uma variante em maiúsculas e a forma mapeada para IPv4 com pontos. O número de sequências de zeros, a sequência mais longa e o comprimento em caracteres são exibidos para entender por que duas strings divergem.
💡 Sobre esta ferramenta
O complicado do IPv6 é que um mesmo endereço admite várias escritas válidas. 2001:db8::1 e 2001:0db8:0000:0000:0000:0000:0000:0001 são o mesmo endereço, mas strings diferentes. Ao comparar uma ACL de firewall com a configuração de um roteador, ou ao cruzar um registro PTR com um log de acesso, uma diferença de escrita é lida como diferença de valor mesmo que os bits sejam idênticos.
A RFC 5952 resolve isso definindo uma única representação canônica: reduzir a :: a sequência mais longa de dois ou mais grupos de zeros, remover os zeros à esquerda de cada grupo e usar hexadecimal em minúsculas. Esta ferramenta aplica essas regras de forma mecânica e exibe a forma canônica ao lado da expandida (útil para cruzar logs e registros PTR) e uma variante em maiúsculas para comparar com equipamentos antigos. Para endereços dentro de ::ffff:0:0/96 ela também gera a forma ::ffff:a.b.c.d; fora desse intervalo, o campo mostra N/A. É feita para quem precisa uniformizar a escrita IPv6 entre dispositivos, logs e documentação.
🧐 Perguntas frequentes
P. Onde exatamente entra o ::?
R. A RFC 5952 reduz a sequência mais longa de dois ou mais grupos de zeros consecutivos. Quando duas sequências têm o mesmo comprimento, vence a mais à esquerda. Um único grupo de zeros nunca vira ::.
P. O que acontece com um endereço que tem duas sequências de zeros separadas?
R. Apenas a mais longa é reduzida. Por exemplo, 2001:0:0:1:0:0:0:1 comprime os três zeros finais em 2001:0:0:1::1. O cartão de detalhes mostra o número de sequências e a mais longa para confirmar qual foi escolhida.
P. Por que o campo mapeado para IPv4 mostra N/A?
R. A notação ::ffff:a.b.c.d só existe para endereços de ::ffff:0:0/96: os primeiros 80 bits zero e os 16 bits seguintes ffff. Qualquer outro endereço não tem equivalente IPv4, então o campo mostra N/A.
P. Os zeros à esquerda são removidos?
R. Sim. Cada grupo perde seus zeros à esquerda: 0db8 vira db8 e 0042 vira 42. A forma expandida faz o contrário, completando cada grupo com quatro dígitos.
P. Posso incluir um identificador de zona como %eth0?
R. Sim. O identificador de zona é excluído do cálculo de compressão e reanexado ao final de cada saída exatamente como você digitou.
P. A saída é sempre uma única string canônica? R. Para um endereço válido, sim: a RFC 5952 foi redigida para que cada endereço IPv6 tenha exatamente uma representação recomendada, que é a forma comprimida exibida aqui.
📚 Por que foi preciso uma segunda RFC
A RFC 4291 já permitia o :: (usado uma vez) e a omissão de zeros à esquerda, mas descrevia o que era permitido, não o que era canônico. Isso deixava 2001:db8:0:0:0:0:0:1 e 2001:db8::1 ambas válidas, de modo que diferentes pilhas de rede e pessoas emitiam strings distintas para o mesmo endereço.
Essa ambiguidade tornava a correlação de logs e a comparação de endereços propensas a erros, então a RFC 5952 fixou uma representação recomendada: hexadecimal em minúsculas, compressão da sequência de zeros mais longa e desempate pela esquerda. O IPv4 nunca teve esse problema — 192.0.2.1 é escrito igual por qualquer pessoa — mas o IPv6, com endereços mais longos e abreviações opcionais, se dispersa em variantes sem normalização. Essa normalização é exatamente o passo que este formatador resolve.