IPv6 para humanos · redzilla

En una puesta en marcha de CCTV, un colega anotó con toda seriedad "la IP del NVR" en la carpeta del proyecto: fe80::ba27:ebff:fe12:34c9. Dos semanas después, desde la otra sede, nadie podía llegar al equipo. Obvio: había anotado la dirección link-local, que solo existe dentro de ese cable. Es como anotar "habitación del fondo, segunda puerta" como dirección postal: perfecta si ya estás dentro de la casa, inútil desde afuera.

Ese tipo de accidente pasa porque IPv6 se ve intimidante y la reacción natural es copiarlo sin mirarlo. La buena noticia: detrás de esos 128 bits hay menos misterio que en IPv4. Vamos por partes.

De 32 a 128 bits: por qué se ve tan rara

Una dirección IPv4 son 32 bits vestidos de cuatro números decimales. Una IPv6 son 128 bits vestidos de 8 grupos de 16 bits, cada grupo escrito con 4 dígitos hexadecimales y separados por dos puntos. Nada más. Si te parece larga es porque es larga: escrita completa mide 39 caracteres.

Como escribir 39 caracteres para cada dirección sería un castigo, el estándar (RFC 5952) define dos reglas de compresión:

Regla 1: dentro de cada grupo, elimina los ceros a la izquierda. 0db8 pasa a db8, 0000 pasa a 0.
Regla 2: la corrida más larga de grupos que quedaron en cero se colapsa en ::. Y esto solo se puede hacer UNA vez por dirección: si hubiera dos ::, no sabrías cuántos ceros pusiste en cada uno y la dirección sería ambigua.

Las dos reglas de compresión aplicadas a 2001:0db8:…:0001 → 2001:db8::1

Así, 2001:0db8:0000:0000:0000:0000:0000:0001 queda en 2001:db8::1. Misma dirección, 28 caracteres menos. Si quieres jugar con esto en ambos sentidos —expandir y comprimir— la calculadora IPv6 lo hace al instante y te muestra además el tipo de dirección y el rango.

Todos los ejemplos de esta guía usan 2001:db8::/32, el prefijo reservado para documentación (RFC 3849). En producción vas a ver el que te delegue tu ISP o tu RIR — jamás este.

Anatomía de una GUA: tres piezas, no ocho

El error de lectura más común es intentar leer los 8 grupos como si fueran los 4 octetos de IPv4. No: una dirección global (GUA) se lee en tres piezas, como un número telefónico internacional — código de país, código de área y número local:

Las tres piezas de una GUA: el ISP pone 48 bits, tú diseñas 16 y el host se encarga de 64

Fíjate en la proporción: de los 128 bits, tú solo administras 16. El prefijo te lo dan hecho y el identificador de interfaz se lo autogeneran los equipos con SLAAC. Todo el "diseño de red" de un sitio IPv6 vive en 4 dígitos hexadecimales. Por eso planificar IPv6 termina siendo más simple que IPv4: el problema es más pequeño, no más grande.

Los tipos que verás en terreno

La primera palabra de la dirección te dice de inmediato qué tienes al frente. Estas son las que aparecen en la vida real:

Tipo	Prefijo	La reconoces porque…	Para qué sirve
GUA (global unicast)	2000::/3	empieza con 2 o 3	Internet pública; te la delega el ISP
ULA (unique local)	fc00::/7	empieza con fc o fd (en la práctica, fd)	Privada y enrutable interna, sin NAT
Link-local	fe80::/10	empieza con fe8, fe9, fea o feb	Solo dentro del enlace; siempre presente
Multicast	ff00::/8	empieza con ff	Grupos: ff02::1 todos, ff02::2 routers
Loopback	::1/128	es literalmente ::1	El localhost de siempre

La link-local es la estrella incomprendida. Toda interfaz IPv6 tiene una fe80:: apenas se levanta, sin pedir permiso a nadie, y solo vale dentro de ese enlace físico. Los routers la usan para hablar entre ellos, y el gateway que te anuncia un router por RA es casi siempre una link-local. Por eso ver fe80::… como próximo salto en una tabla de rutas es normal — y por eso anotarla como "la IP del equipo" para alcanzarlo desde otra red es el error de mi colega del NVR.

Las ULA son el equivalente espiritual de 10.0.0.0/8, con una mejora: el estándar (RFC 4193) te pide generar 40 bits aleatorios para tu prefijo fd…::/48. Suena a burocracia hasta el día en que tu empresa se fusiona con otra y las dos usaban 10.0.0.0/8: en IPv4 eso es una renumeración dolorosa; con ULA aleatorias la colisión es casi imposible. Si heredaste redes de terceros, el verificador de solapamiento te dice en segundos si dos prefijos chocan.

¿Y el broadcast? No existe. IPv6 lo reemplazó por multicast bien dirigido: ff02::1 alcanza a todos los nodos del enlace y ff02::2 solo a los routers. Hasta el reemplazo de ARP (NDP) usa multicast selectivo en vez de gritarle a toda la red. Tu switch lo agradece.

La regla de oro: toda LAN es un /64

Grábatela: cada VLAN, cada segmento, cada LAN recibe un /64. No un /96 "porque son pocos equipos", no un /120 "para no desperdiciar". Un /64. Siempre.

La razón es técnica, no estética: SLAAC —el mecanismo con que los equipos se autoconfiguran la dirección— necesita exactamente 64 bits de identificador de interfaz (RFC 4862). Si le das menos, SLAAC no funciona y quedas dependiendo de DHCPv6 para todo… y Android no habla DHCPv6. Un /64 "recortado" es una red donde los celulares no obtienen dirección.

¿Y el "desperdicio"? Hagamos la aritmética: un /64 contiene 2⁶⁴ direcciones — 18,4 trillones. Todo el espacio IPv4 completo son 2³² ≈ 4.295 millones. O sea, cada /64 podría contener 4.295 millones de copias de todo el Internet IPv4, y aún así le asignamos uno a la VLAN de las tres impresoras. Está bien. Está diseñado así: los 64 bits de host no son inventario que se agota, son espacio para que la autoconfiguración y la privacidad de direcciones funcionen sin coordinación.

Subnetear un /64 en bloques pequeños "para ahorrar" es el clásico que después se paga: SLAAC deja de funcionar, Android no soporta DHCPv6, y terminas con una flota de dispositivos sin red y un ticket escalado un viernes. En IPv6 la escasez que aprendiste a administrar en IPv4 no existe. La única excepción legítima: /127 en enlaces punto a punto entre routers (RFC 6164) y /128 para loopbacks.

El plan jerárquico: /48 → /56 → /64

Con la regla de oro clara, planificar es repartir /64. Un /48 de sitio te deja 16 bits de subred: 2¹⁶ = 65.536 redes /64. La gracia no es la cantidad, es cómo la ordenas. El patrón que nunca falla:

/48 = el sitio. Lo que te delega el ISP (o tu bloque ULA).
/56 = el edificio (o piso, o zona): 8 bits → 256 edificios por sitio.
/64 = la VLAN: otros 8 bits → 256 VLANs por edificio.

El cuarto grupo hace todo el trabajo: 2 dígitos hex para el edificio, 2 para la VLAN

¿256 edificios te queda grande? No importa. El objetivo de un plan IPv6 no es "usar" el espacio, es que la dirección se lea sola: miras …cafe:0530::/64 y sabes que es el edificio 05, VLAN 30, sin abrir ninguna planilla. Eso, en una madrugada de incidente, vale oro.

El límite de nibble: por qué 4 en 4

Un nibble son 4 bits — exactamente un dígito hexadecimal. Si divides tus prefijos en múltiplos de 4 bits (/48, /52, /56, /60, /64), cada bloque empieza y termina en un dígito hex completo y los prefijos se leen a ojo. Si cortas en /49 o /57, la frontera queda en la mitad de un dígito: 2001:db8:cafe:8000::/49 existe y es válido, pero para saber qué direcciones contiene tienes que ponerte a hacer aritmética binaria mental. Nadie quiere eso a las 3 AM.

Hay un premio extra: el DNS inverso de IPv6 (ip6.arpa) se delega dígito por dígito, o sea, nibble por nibble. Un plan alineado al nibble se traduce en zonas PTR limpias y delegables; uno desalineado, en dolores de cabeza. La herramienta de zona PTR inversa te genera los nombres ip6.arpa desde cualquier prefijo y lo vas a ver de inmediato.

Escribe el número de VLAN "en decimal disfrazado de hex": VLAN 10 → grupo …10, VLAN 30 → grupo …30. Sacrificas los valores con letras (a–f), pero cualquier técnico lee la VLAN directo en la dirección sin convertir nada. El planificador IPv6 arma la jerarquía completa por límite de nibble y te lista las subredes listas para copiar.

Manos a la obra: un plan completo en 6 pasos

Supongamos que el ISP te delegó 2001:db8:cafe::/48 para un campus, y empezamos por la VLAN 10 (datos) del edificio 5:

Ubica tus 16 bits. Los primeros 48 bits (2001:0db8:cafe) son fijos. Tu lienzo es el cuarto grupo completo: 4 dígitos hex. Los últimos 64 bits son de los equipos.
Parte el grupo en el límite de nibble: 2 primeros dígitos = edificio (8 bits → 256 edificios), 2 últimos = VLAN (8 bits → 256 VLANs por edificio).
Edificio 5 → 05. Su bloque completo es 2001:db8:cafe:0500::/56: toda dirección cuyo cuarto grupo empiece con 05 vive ahí.
VLAN 10 → 10. El cuarto grupo queda 0510 y la LAN es 2001:db8:cafe:0510::/64.
Comprime (RFC 5952): cae el cero a la izquierda (0510 → 510) y los grupos de ceros colapsan en ::. Resultado: 2001:db8:cafe:510::/64, con gateway 2001:db8:cafe:510::1.
Cuenta lo que tienes: 256 edificios × 256 VLANs = 65.536 redes /64 en un solo /48. Y cada una con 2⁶⁴ direcciones adentro. Deja de sufrir: el plan te va a sobrar.

El plan del edificio 5 queda así de legible:

redzilla — plan ipv6 · edificio 05

sitio               2001:db8:cafe::/48
edificio 05         2001:db8:cafe:500::/56
├─ vlan 10 datos    2001:db8:cafe:510::/64
├─ vlan 20 voz      2001:db8:cafe:520::/64
├─ vlan 30 camaras  2001:db8:cafe:530::/64
└─ gw vlan 10       2001:db8:cafe:510::1

Cada línea se lee sola: sitio cafe, edificio 05, VLAN a la vista. Pega cualquiera de estos prefijos en la calculadora IPv6 y verifica la expansión, el rango y el tipo antes de configurarlo.

Qué hacer ahora

Toma un sitio real que administres, dibuja su jerarquía edificio → VLAN y pásala por el planificador IPv6: en cinco minutos tienes el plan completo alineado al nibble. Después revisa qué direcciones fe80:: tienes anotadas por ahí como si fueran alcanzables — ya sabes por qué no responden desde la otra sede.