Formato de Cabecera IPv6: Estructura, Campos y Cabeceras de Extensión

Por Qué IPv6 Cambió la Cabecera#

La cabecera de IPv4 creció orgánicamente durante décadas. Se añadieron opciones, se reutilizaron campos y al final tenías una cabecera de longitud variable con 14 campos diferentes (algunos opcionales) y una estructura compleja que los enrutadores tenían que analizar cuidadosamente en cada salto.

IPv6 adoptó un enfoque diferente: longitud fija, simplificado y optimizado para reenvío rápido. La cabecera base siempre tiene exactamente 40 bytes, con 8 campos bien definidos. Sin opciones de longitud variable, sin suma de verificación de cabecera, sin campos de fragmentación en la cabecera principal.

El resultado es una cabecera que los enrutadores pueden procesar más rápido, que es más fácil de implementar en hardware y que soporta extensión sin romper la compatibilidad hacia atrás. Entender la cabecera IPv6 significa entender por qué está construida de esta manera y qué compromisos hicieron los diseñadores.

La Cabecera Base de 40 Bytes#

Cada paquete IPv6 comienza con exactamente 40 bytes en este formato:

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| Traffic Class |           Flow Label                  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         Payload Length        |  Next Header  |   Hop Limit   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                                                               +
|                                                               |
+                         Source Address                        +
|                                                               |
+                                                               +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                                                               +
|                                                               |
+                      Destination Address                      +
|                                                               |
+                                                               +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Tamaño fijo. Sin opciones en la cabecera base. Cada enrutador sabe exactamente dónde está cada campo sin necesidad de análisis.

Los Ocho Campos#

Examinemos cada campo en el orden en que los enrutadores típicamente los procesan.

1. Versión (4 bits)#

Siempre 6 para paquetes IPv6. Siempre 4 para paquetes IPv4. Así es como los dispositivos distinguen IPv6 de IPv4 en la red.

Implicación práctica: Los sistemas de doble pila miran primero estos 4 bits para determinar cómo analizar el resto del paquete.

Versión = 6 (binario: 0110)

Simple, inmutable y crítico para la identificación del protocolo.

2. Clase de Tráfico (8 bits)#

Anteriormente llamado «Prioridad» en las primeras especificaciones de IPv6, este campo marca paquetes para tratamiento de Calidad de Servicio (QoS). Cumple el mismo propósito que el Tipo de Servicio (ToS) de IPv4 o el Punto de Código de Servicios Diferenciados (DSCP).

Estructura:

• Bits 0-5: DSCP (Differentiated Services Code Point)
• Bits 6-7: ECN (Explicit Congestion Notification)

Valores DSCP comunes:

ECN permite a los enrutadores señalar congestión sin descartar paquetes. Es utilizado por implementaciones modernas de TCP para mejor control de congestión.

3. Etiqueta de Flujo (20 bits)#

Una de las características más interesantes pero infrautilizadas de IPv6. La Etiqueta de Flujo identifica paquetes que pertenecen al mismo flujo y deben recibir tratamiento de enrutamiento idéntico.

Propósito:

• Permitir a los enrutadores identificar paquetes relacionados sin examinar cabeceras de capas superiores
• Soportar reenvío de ruta rápida para flujos conocidos
• Proporcionar un manejador para QoS por flujo

Especificación (RFC 6437):

• Valor 0: El paquete no es parte de un flujo
• Valor 1-0xFFFFF: Identificador de flujo (elegido aleatoriamente por el origen)
• Debe ser consistente para todos los paquetes en un flujo
• Debe ser pseudo-aleatorio para permitir hashing en enrutadores

4. Longitud de Carga Útil (16 bits)#

Longitud de la carga útil del paquete en bytes, excluyendo la cabecera base de 40 bytes.

Rango: 0 a 65,535 bytes

Detalles importantes:

• Incluye cabeceras de extensión (si las hay) más datos de capa superior
• NO incluye la cabecera IPv6 base de 40 bytes
• El valor máximo 65,535 significa que el tamaño máximo de paquete es 65,575 bytes (65,535 + 40)

5. Siguiente Cabecera (8 bits)#

Identifica el tipo de cabecera que sigue inmediatamente a la cabecera IPv6. Así es como se especifican las cabeceras de extensión y los protocolos de capa superior.

Valores comunes:

6. Límite de Saltos (8 bits)#

El número de saltos de enrutador que quedan antes de que el paquete sea descartado. Cada enrutador lo decrementa en 1. Cuando llega a 0, el enrutador descarta el paquete y envía un mensaje ICMPv6 Time Exceeded.

Rango: 0-255

Este es el equivalente en IPv6 del campo TTL (Time To Live) de IPv4, pero el nombre es más preciso: cuenta saltos, no tiempo.

7. Dirección de Origen (128 bits)#

La dirección IPv6 del remitente del paquete. Siempre 128 bits, sin excepciones.

Formato: Notación de dirección IPv6 estándar

2001:db8:1234:5678:9abc:def0:1234:5678

8. Dirección de Destino (128 bits)#

La dirección IPv6 del destinatario previsto del paquete. Como la Dirección de Origen, siempre 128 bits.

Formato: Notación de dirección IPv6 estándar

2001:4860:4860::8888

Comparación de Cabeceras IPv6 vs IPv4#

Entender qué cambió ayuda a apreciar las decisiones de diseño.

¿Qué Se Eliminó y Por Qué?#

Suma de verificación de cabecera: Los enrutadores IPv4 recalculan la suma de verificación en cada salto porque TTL cambia. Esto añade sobrecarga de procesamiento. IPv6 la elimina porque:

• La capa de enlace (Ethernet) tiene su propia suma de verificación
• La capa de transporte (TCP/UDP) tiene su propia suma de verificación
• Los enrutadores no necesitan verificar la integridad del paquete: los extremos lo hacen

Campo de longitud de cabecera: IPv4 lo necesita porque las opciones hacen que la cabecera sea de longitud variable. La cabecera fija de 40 bytes de IPv6 hace innecesario este campo.

Campos de fragmentación: IPv4 permite que cualquier enrutador fragmente paquetes. IPv6 requiere que el origen realice la fragmentación usando Path MTU Discovery. Esto mueve la complejidad a los extremos y mejora el rendimiento del enrutador.

Cabeceras de Extensión Explicadas#

Las cabeceras de extensión son la forma de IPv6 de añadir funcionalidad sin complicar la cabecera base. Aparecen entre la cabecera IPv6 y la capa de transporte (TCP/UDP), formando una cadena.

Cómo Funcionan las Cabeceras de Extensión#

Cada cabecera de extensión contiene un campo de Siguiente Cabecera que apunta a la siguiente cabecera en la cadena:

+--------+-------+--------+-------+--------+-------+-----+
| IPv6   | NH=0  | Hop-by | NH=43 | Routing| NH=6  | TCP |
| Header |       | -Hop   |       | Header |       |     |
+--------+-------+--------+-------+--------+-------+-----+

Los hosts procesan las cabeceras de extensión en orden. Los enrutadores típicamente solo procesan Hop-by-Hop Options; otras cabeceras son examinadas solo por el destino.

Cabeceras de Extensión Estándar#

RFC 8200 define el orden recomendado cuando están presentes múltiples cabeceras de extensión:

1. Hop-by-Hop Options (0)
2. Destination Options (para destinos intermedios cuando hay cabecera de Routing)
3. Routing (43)
4. Fragment (44)
5. Authentication Header (51)
6. Encapsulating Security Payload (50)
7. Destination Options (60) (para destino final)
8. Capa Superior (TCP=6, UDP=17, ICMPv6=58)

¿Por Qué No Hay Suma de Verificación?#

IPv4 incluye una suma de verificación de cabecera que los enrutadores deben recalcular en cada salto (porque TTL cambia). IPv6 deliberadamente la omite.

Razonamiento:

1. La capa de enlace ya tiene sumas de verificación: Ethernet tiene CRC32. Wi-Fi tiene sumas de verificación. Las capas de enlace modernas son confiables.

2. Sumas de verificación de capa de transporte: TCP y UDP incluyen sumas de verificación que cubren datos y cabeceras. La verificación extremo a extremo ocurre de todos modos.

3. Rendimiento del enrutador: Recalcular sumas de verificación en cada salto desperdicia ciclos de CPU. Los enrutadores de alta velocidad reenvían miles de millones de paquetes por segundo: eliminar el cálculo de suma de verificación ayuda.

4. Los errores son raros: Las redes modernas tienen bajas tasas de error de bits. Las sumas de verificación detectan menos errores que en los años 80 cuando se diseñó IPv4.

Implicaciones Prácticas#

Para Ingenieros de Redes#

Configuración de firewall:

• Debe analizar cadenas de cabeceras de extensión para encontrar cabeceras de transporte
• Debe limitar la profundidad de la cadena para prevenir abusos
• Descartar cabeceras obsoletas (Type 0 Routing)

Ajuste de rendimiento:

• Sin suma de verificación de cabecera significa reenvío más rápido en hardware
• El tamaño fijo de cabecera permite mejor pipelining en enrutadores
• Las cabeceras de extensión pueden activar procesamiento de ruta lenta

Resolución de problemas:

• tcpdump muestra todas las cabeceras: tcpdump -i eth0 -vv ip6
• Wireshark analiza las cabeceras de extensión claramente
• Verificar cabeceras de extensión inesperadas que causan descartes

Para Desarrolladores#

Programación de sockets:

• Los sockets IPv6 pueden recibir cabeceras de extensión vía datos auxiliares
• Las aplicaciones raramente necesitan construir cabeceras de extensión manualmente
• El sistema operativo maneja la fragmentación automáticamente

Construcción de paquetes:

• Establecer Traffic Class para aplicaciones sensibles a QoS (VoIP, video)
• Habilitar generación automática de Flow Label para mejor balanceo de carga ECMP
• No asumir que puedes fragmentar: usa PMTUD correctamente

Para Administradores de Sistemas#

Configuración de MTU:

• Asegurar que el MTU es al menos 1280 bytes en todos los enlaces
• MTUs más grandes mejoran el rendimiento (1500 estándar, 9000 para tramas jumbo)
• Permitir ICMPv6 Packet Too Big a través de firewalls

Configuración de QoS:

• Configurar enrutadores para honrar marcas de Traffic Class
• Mapear tráfico de aplicación a valores DSCP apropiados
• Monitorear que las políticas QoS funcionen correctamente

Examinar Cabeceras con Herramientas#

tcpdump#

Capturar y mostrar cabeceras IPv6:

# Captura básica de paquetes IPv6
sudo tcpdump -i eth0 -n ip6
 
# Salida detallada mostrando todos los campos de cabecera
sudo tcpdump -i eth0 -vv ip6
 
# Mostrar solo paquetes con cabeceras de extensión
sudo tcpdump -i eth0 -vv 'ip6 and ip6[6] != 6 and ip6[6] != 17 and ip6[6] != 58'
 
# Capturar paquetes fragmentados
sudo tcpdump -i eth0 -n 'ip6 and ip6[6] = 44'

Wireshark#

Wireshark proporciona análisis detallado de cabeceras:

Filtros:

# Todo el tráfico IPv6
ipv6
 
# Paquetes con cabeceras de extensión específicas
ipv6.nxt == 0    # Hop-by-Hop
ipv6.nxt == 43   # Routing
ipv6.nxt == 44   # Fragment
ipv6.nxt == 60   # Destination Options
 
# Paquetes fragmentados
ipv6.fragment
 
# Traffic Class específica
ipv6.tclass == 46  # Expedited Forwarding

Errores de Configuración Comunes#

Bloquear Cabeceras de Extensión Completamente#

Problema: El firewall descarta todos los paquetes con cabeceras de extensión.

Impacto:

• La fragmentación no funciona (tipo 44 bloqueado)
• Las VPN IPsec fallan (tipos 50/51 bloqueados)
• Cae tráfico legítimo

Solución: Permitir cabeceras necesarias (Fragment, AH, ESP), bloquear las obsoletas (Type 0 Routing).

# iptables: Permitir fragmentos, descartar Type 0 routing
ip6tables -A FORWARD -m rt --rt-type 0 -j DROP
ip6tables -A FORWARD -p ipv6-icmp --icmpv6-type packet-too-big -j ACCEPT

Ignorar Traffic Class#

Problema: Enrutadores configurados sin QoS, todos los paquetes obtienen tratamiento de mejor esfuerzo.

Impacto:

• Calidad de VoIP sufre
• Streams de video se atascan
• Tráfico sensible al tiempo compite con transferencias masivas

Solución: Configurar políticas QoS basadas en Traffic Class/DSCP.

Desajustes de MTU#

Problema: Enlaces con MTU < 1280 o firewalls bloqueando ICMPv6 Packet Too Big.

Impacto:

• Las conexiones se cuelgan
• Las transferencias grandes fallan
• PMTUD no funciona

Solución: Asegurar MTU mínimo de 1280 en todas partes, permitir ICMPv6 tipo 2.

# Establecer MTU
ip link set dev eth0 mtu 1500
 
# Verificar
ip -6 link show eth0
 
# Permitir Packet Too Big
ip6tables -A INPUT -p ipv6-icmp --icmpv6-type packet-too-big -j ACCEPT

Artículos Relacionados#

• Fundamentos de IPv6 - Entiende el direccionamiento básico y conceptos de IPv6 antes de profundizar en cabeceras.
• ICMPv6 Explicado - Aprende sobre ICMPv6, que usa el valor de Next Header 58 y es crítico para IPv6.
• Configuración de Firewall IPv6 - Configura firewalls para manejar cabeceras IPv6 y cabeceras de extensión correctamente.

Preguntas Frecuentes#