¿Por qué la forma canónica IPv6 usa letras minúsculas y una compresión concreta?

RFC 5952 (Kawamura y Kawashima, 2010) endurece RFC 4291 al imponer una única forma textual por dirección, eliminando la ambigüedad que rompía las comparaciones de igualdad de string entre sistemas. §4.3 requiere hex en minúsculas ('a' a 'f', no 'A' a 'F'). §4.2.3 obliga a que :: comprima la racha más larga de campos 16-bit cero consecutivos; cuando dos rachas empatan, gana la primera. §4.2.2 prohíbe usar :: para elidir un único campo cero. Así 2001:DB8:0:0:0:0:0:1 debe canonicalizar a 2001:db8::1 — no 2001:db8:0:0::1 ni 2001:DB8::1. Las herramientas que no canonicalizan los inputs suelen mis-comparar direcciones o duplicar entradas de firewall; el conversor normaliza cada input IPv6 a la forma §4 antes de mostrar las representaciones alternativas.

¿Cuál es la diferencia entre el espacio privado RFC 1918 y el rango CGNAT 100.64.0.0/10?

RFC 1918 (Rekhter et al., 1996) reservó 10/8, 172.16/12 y 192.168/16 para organizaciones que usan NAT — estos rangos son enrutables dentro de una empresa pero nunca en la internet pública. Los ISPs chocaron con un problema al acercarse el agotamiento IPv4: sus routers de cliente ya usaban rangos RFC 1918 internamente, así que la capa NAT del lado del operador necesitaba un rango distinto para evitar colisiones cuando ambos extremos usaban 10/8. RFC 6598 (Weil, Kuarsingh, Donley, Liljenstolpe y Azinger, 2012) reservó 100.64.0.0/10 del espacio v4 sin asignar específicamente para esa capa ISP-CGNAT. Un paquete puede atravesar tres capas de NAT: LAN del cliente (RFC 1918) → CGNAT del ISP (RFC 6598 100.64/10) → internet pública. Las herramientas que sólo marcan RFC 1918 como 'privado' pierden el alcance carrier 100.64/10, razón por la que el conversor resalta ambos.

¿Siguen siendo relevantes las clases A, B y C?

Funcionalmente, no. La especificación IPv4 de 1981 (RFC 791 §3.2) introdujo el direccionamiento unicast por clases — la clase A reservaba 1.0.0.0–127.255.255.255 con máscara de 8 bits, clase B 128–191 con /16, clase C 192–223 con /24. La clase D para multicast (224.0.0.0–239.255.255.255) la añadió RFC 988 (1986) y la refinó RFC 1112 (1989); la clase E (240.0.0.0/4, reservada para uso futuro) quedó apartada en RFC 1112 §4. Cuando las tablas de routing explotaron a principios de los 90, el IETF deprecó el esquema unicast por clases y lo reemplazó con CIDR (Classless Inter-Domain Routing). Los documentos originales de CIDR (RFC 1518/1519, septiembre 1993) definieron el sistema de prefijos de longitud variable; RFC 4632 (Fuller y Li, 2006) es la especificación canónica actual. Los routers, asignadores y registries modernos no usan clases; las direcciones se describen sólo por /CIDR. La terminología sobrevive en currículos legacy, algunos comandos Cisco IOS ('ip classless') y la jerga de ingenieros que aprendieron en aquella era.

¿Por qué mi IP aparece como un entero gigante en logs de MySQL o Cloudflare?

INET_ATON('192.168.1.1') de MySQL devuelve 3232235777 — los cuatro octetos leídos como un entero sin signo de 32 bits big-endian (192*16777216 + 168*65536 + 1*256 + 1). La forma entera ocupa 4 bytes en almacenamiento frente a 15 caracteres del string punteado, y las comparaciones enteras corren más rápido que las operaciones de string contra columnas indexadas. INET_NTOA(3232235777) invierte la conversión. Los logs de Cloudflare y los exports a BigQuery siguen el mismo patrón big-endian. IPv6 necesita 16 bytes — INET6_ATON devuelve un blob binario, no un único Long. El network order (big-endian) es el formato canónico en cable definido para los campos IP en RFC 791; las herramientas que leen capturas de paquetes o buffers de socket ven esos bytes directamente, mientras que las aplicaciones que manejan direcciones IP como enteros pueden necesitar conversiones POSIX htonl()/ntohl() en hosts cuya CPU almacena enteros en little-endian. El conversor muestra la decimal punteada y el entero junto a hex/binario para que los operadores cruzen volcados de log sin matemática manual.

Conversor de Direcciones IP

Q: ¿Por qué mi dirección IPv6 aparece como ::ffff:192.168.1.1 en algunos logs?

Esa es una dirección IPv4-mapped IPv6, definida en RFC 4291 §2.5.5.2 (Hinden y Deering, 2006). El prefijo ::ffff:0:0/96 permite a un socket dual-stack recibir conexiones IPv4 e IPv6 sobre un único descriptor AF_INET6 — cuando un cliente IPv4 conecta, el kernel sintetiza esta forma textual para que la aplicación trate la dirección de manera uniforme. Java en particular expone estos mapeos: InetAddress.getByName("192.168.1.1") puede mostrar /192.168.1.1 pero bind() la devuelve como ::ffff:c0a8:0101 en un socket v6. Los logs que mezclan tráfico v4 y v6 sobre el mismo listener muestran esta forma para todo lo que el kernel mapeó, lo que sorprende a los ingenieros la primera vez que lo ven. La dirección subyacente sigue siendo el valor IPv4 de 32 bits; sólo la forma textual cambió.

Entrada Detectado: Decimal

Introduce una IP en cualquier formato: decimal con puntos, binario, hex (0xC0A80101 o C0.A8.01.01) o entero.

Conversiones

Decimal ?

192.168.1.1

Binario ?

11000000.10101000.00000001.00000001

Hexadecimal ?

C0.A8.01.01

Entero ?

3232235777

Octal ?

300.250.001.001

IPv4-Mapped IPv6 ?

::ffff:192.168.1.1

Sobre esta herramienta

Una dirección IP es un entero sin signo de 32 bits (IPv4) o 128 bits (IPv6). Ambas pueden escribirse de varias maneras sin cambiar los bits subyacentes. Decimal punteada (192.168.1.1) es la forma canónica de IPv4; entero (3232235777), hexadecimal (0xC0A80101), binario (11000000.10101000.00000001.00000001) y formas octales son codificaciones alternativas del mismo valor, encontradas en logs (MySQL INET_ATON), configs Cisco IOS, filtros BPF y expresiones de reglas de firewall. IPv6 tiene su propia forma textual canónica definida por RFC 5952 (Kawamura y Kawashima, 2010): los dígitos hex en minúsculas se DEBEN usar según §4.3, la racha más larga de campos 16-bit cero consecutivos se DEBE comprimir con :: según §4.2.3, y :: DEBE aparecer una sola vez. Esta herramienta convierte entre formatos en el cliente — ningún input sale de tu navegador — y muestra la representación IPv4-mapped IPv6 (::ffff:0:0/96, RFC 4291 §2.5.5.2) usada por sistemas dual-stack para embeber direcciones v4 dentro de sockets v6. Los rangos privados, espacio compartido CGNAT y IPv6 ULA se marcan en la salida para contexto rápido.

Cómo convertir formatos IP

Introduce una IP en cualquier formato admitido — decimal punteada (192.168.1.1), entero de 32 bits (3232235777), hexadecimal (0xC0A80101), binario, octal o IPv6 corta (::1).
La herramienta detecta el formato de entrada, lo valida y presenta cada otra representación simultáneamente.
Copia valores individuales para usar donde tu sistema destino espere una forma específica (firewalls, queries de log, CLIs de routers legacy).
Cambia entre modo IPv4 e IPv6 cuando los datos fuente usen la otra familia.

Casos de uso comunes

Traducir un IP entero de 32 bits desde un log MySQL a decimal punteada para una regla de firewall.
Leer máscaras binarias impresas por un volcado de tabla de routing como /CIDR legible o forma punteada.
Preparar direcciones para sistemas que exigen una representación específica (Cisco IOS hex, MySQL INET_ATON entero, Windows ipconfig punteado).
Enseñar la relación entre decimal punteada, entero host-order y bytes network-order al introducir el direccionamiento IP.

Preguntas frecuentes

¿Por qué mi dirección IPv6 aparece como ::ffff:192.168.1.1 en algunos logs?

Es una dirección IPv4-mapped IPv6 (RFC 4291 §2.5.5.2). Los sockets dual-stack reciben tráfico v4 y v6 sobre un único descriptor AF_INET6; el kernel sintetiza esta forma textual para que la aplicación trate las direcciones de manera uniforme.

¿Por qué la forma canónica IPv6 usa minúsculas?

RFC 5952 §4.3 requiere hex en minúsculas, §4.2.3 obliga a que :: comprima la racha más larga de campos cero, §4.2.2 prohíbe :: para un único campo cero. Las reglas eliminan la ambigüedad que rompía igualdad de string entre sistemas.

¿Cuál es la diferencia entre RFC 1918 privado y 100.64.0.0/10 CGNAT?

RFC 1918 (10/8, 172.16/12, 192.168/16) es para organizaciones detrás de NAT. RFC 6598 100.64/10 fue tallado específicamente para CGNAT del lado del ISP, evitando colisiones cuando ambos extremos ya usan 10/8.

¿Siguen siendo relevantes las clases A, B, C?

Funcionalmente no. CIDR (Classless Inter-Domain Routing) deprecó el direccionamiento por clases en 1993; RFC 4632 (Fuller y Li, 2006) es la especificación canónica. Las clases sobreviven en currículos legacy y unos cuantos comandos Cisco IOS.

¿Por qué mi IP aparece como un entero gigante en logs MySQL o Cloudflare?

INET_ATON('192.168.1.1') de MySQL devuelve 3232235777 — los cuatro bytes leídos como entero sin signo de 32 bits. Almacenamiento más pequeño, comparaciones indexadas más rápidas. INET_NTOA invierte la conversión.

Qué codifican realmente los formatos — y por qué aparecen CGNAT, ULA y clases A/B/C

La forma decimal punteada 192.168.1.1 es puramente una convención tipográfica: cada octeto es un byte renderizado en decimal entre 0 y 255. El entero único 3232235777 son los mismos cuatro bytes interpretados como un entero sin signo de 32 bits big-endian. Hexadecimal 0xC0A80101 muestra los bytes en base 16. Ninguna representación lleva semántica de routing distinta — todas producen el mismo valor de 32 bits en cabeceras IP. La endianness se vuelve relevante en la frontera C-API: los BSD sockets definen POSIX htonl()/ntohl() para convertir entre enteros host-order y bytes network-order (big-endian en el cable) cuando las aplicaciones manejan campos IP directamente. Rangos privados por capas. RFC 1918 (Rekhter, Moskowitz, Karrenberg, de Groot y Lear, 1996) reservó 10.0.0.0/8, 172.16.0.0/12 y 192.168.0.0/16 para uso detrás de NAT. El NAT carrier-grade necesita una reserva separada porque los rangos RFC 1918 ya se usan dentro de las redes de cliente; RFC 6598 (Weil, Kuarsingh, Donley, Liljenstolpe y Azinger, 2012) asignó 100.64.0.0/10 específicamente para esa capa ISP-CGNAT. RFC 4193 (Hinden y Haberman, 2005) definió el equivalente IPv6 fc00::/7, con FD00::/8 como la mitad asignada localmente y pseudo-aleatoria. El direccionamiento por clases A/B/C fue deprecado en 1993 por la propuesta CIDR original; RFC 4632 (Fuller y Li, 2006) es la especificación canónica actual, que deja obsoleto el RFC 1519. El concepto de clases sobrevive sólo en currículos legacy y un puñado de configuraciones no modernizadas.

Detección automática del formato desde cualquier notación admitida (decimal punteada, entero, hex, binario, octal, IPv6 corta)
Decimal punteada, binario, hexadecimal (prefijo 0x), entero de 32 bits, octal
Visualización IPv4-mapped IPv6 (::ffff:a.b.c.d, RFC 4291 §2.5.5.2)
Marcado de rangos RFC 1918 / RFC 6598 / RFC 4193 en la salida
Copiar cada valor individualmente
La conversión es matemática pura en el cliente (sin upload)

Gratis. Sin registro. Las tools de navegador (subred, JWT, fuerza de contraseña) corren localmente; las de consulta usan APIs públicas (Cloudflare DoH, RDAP, registros de certs). Detalle por herramienta en /es/methodology/.

Fuentes (9)

Kawamura, S., & Kawashima, M. (2010). A Recommendation for IPv6 Address Text Representation. RFC 5952, IETF.
Hinden, R., & Deering, S. (2006). IP Version 6 Addressing Architecture. RFC 4291, IETF (§2.5.5.2 IPv4-Mapped IPv6 Address).
Postel, J. (1981). Internet Protocol. RFC 791, IETF (§3.2 classful addressing).
Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. J., & Lear, E. (1996). Address Allocation for Private Internets. RFC 1918, IETF.
Weil, J., Kuarsingh, V., Donley, C., Liljenstolpe, C., & Azinger, M. (2012). IANA-Reserved IPv4 Prefix for Shared Address Space. RFC 6598, IETF (100.64.0.0/10 CGNAT).
Hinden, R., & Haberman, B. (2005). Unique Local IPv6 Unicast Addresses. RFC 4193, IETF (fc00::/7 with FD00::/8 locally-assigned half).
Rekhter, Y., & Li, T. (1993). An Architecture for IP Address Allocation with CIDR. RFC 1518, IETF (deprecated by RFC 4632).
Fuller, V., Li, T., Yu, J., & Varadhan, K. (1993). Classless Inter-Domain Routing (CIDR): an Address Assignment and Aggregation Strategy. RFC 1519, IETF (obsoleted by RFC 4632).
Fuller, V., & Li, T. (2006). Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan. RFC 4632, IETF (current canonical, obsoletes RFC 1519).

Son los RFCs del IETF, las publicaciones del NIST y los estándares del W3C que la herramienta implementa o consulta. Localízalos en el IETF Datatracker (datatracker.ietf.org) o en el organismo correspondiente.

Por Marco B. · Última verificación junio 2026 — corre en tu navegador