Formateador de compresión de ceros de dirección IPv6 | Canonicaliza según RFC 5952

Introduce una dirección IPv6 y obtén cuatro formas a la vez: la comprimida canónica RFC 5952, la totalmente expandida de ocho grupos, una variante en mayúsculas y la forma mapeada a IPv4 con puntos. Se muestran el número de series de ceros, la serie más larga y la longitud en caracteres para entender por qué dos cadenas no coinciden.

💡 Sobre esta herramienta

Lo complicado de IPv6 es que una misma dirección admite muchas escrituras válidas. 2001:db8::1 y 2001:0db8:0000:0000:0000:0000:0000:0001 son la misma dirección, pero cadenas distintas. Al comparar una ACL de firewall con la configuración de un router, o al cruzar un registro PTR con un log de acceso, una diferencia de escritura se lee como una diferencia de valor aunque los bits sean idénticos.

RFC 5952 resuelve esto definiendo una única representación canónica: colapsar la serie más larga de dos o más grupos de ceros a ::, eliminar los ceros iniciales de cada grupo y usar hexadecimal en minúsculas. Esta herramienta aplica esas reglas de forma mecánica y muestra la forma canónica junto a la expandida (útil para cruzar logs y registros PTR) y una variante en mayúsculas para comparar con equipos antiguos. Para direcciones dentro de ::ffff:0:0/96 genera también la forma ::ffff:a.b.c.d; fuera de ese rango el campo indica N/A. Está pensada para quien necesita unificar la escritura de IPv6 entre dispositivos, logs y documentación.

🧐 Preguntas frecuentes

P. ¿Dónde va exactamente el ::? R. RFC 5952 colapsa la serie más larga de dos o más grupos de ceros consecutivos. Si dos series tienen la misma longitud, gana la situada más a la izquierda. Un único grupo de ceros nunca se reduce a ::.

P. ¿Qué pasa con una dirección que tiene dos series de ceros separadas? R. Solo se colapsa la más larga. Por ejemplo, 2001:0:0:1:0:0:0:1 comprime los tres ceros finales en 2001:0:0:1::1. La tarjeta de detalles muestra el número de series y la más larga para confirmar cuál se eligió.

P. ¿Por qué el campo mapeado a IPv4 dice N/A? R. La notación ::ffff:a.b.c.d solo existe para direcciones de ::ffff:0:0/96: los primeros 80 bits a cero y los siguientes 16 bits ffff. Cualquier otra dirección no tiene equivalente IPv4, por lo que el campo muestra N/A.

P. ¿Se eliminan los ceros iniciales? R. Sí. Cada grupo pierde sus ceros iniciales: 0db8 pasa a db8 y 0042 a 42. La forma expandida hace lo contrario y rellena cada grupo a cuatro dígitos.

P. ¿Puedo incluir un identificador de zona como %eth0? R. Sí. El identificador de zona se excluye del cálculo de compresión y se añade al final de cada salida tal como lo escribiste.

P. ¿La salida es siempre una única cadena canónica? R. Para una dirección válida, sí: RFC 5952 se redactó para que cada dirección IPv6 tenga exactamente una representación recomendada, que es la forma comprimida mostrada aquí.

📚 Por qué hizo falta un segundo RFC

RFC 4291 ya permitía el :: (usado una vez) y la omisión de ceros iniciales, pero describía lo permitido, no lo canónico. Eso dejaba válidas a la vez 2001:db8:0:0:0:0:0:1 y 2001:db8::1, así que distintas pilas de red y personas emitían cadenas diferentes para la misma dirección.

Esa ambigüedad complicaba la correlación de logs y la comparación de direcciones, así que RFC 5952 fijó una representación recomendada: hexadecimal en minúsculas, compresión de la serie de ceros más larga y desempate por la izquierda. IPv4 nunca tuvo este problema —192.0.2.1 se ve igual lo escriba quien lo escriba— pero IPv6, con direcciones más largas y abreviaturas opcionales, se dispersa en variantes si no se normaliza. Esa normalización es justo el paso que resuelve este formateador.