-->

Cabecera IPv4

La cabecera IPv4 (IPv4 Header) es el conjunto de campos de control de capa de red (Capa 3 del modelo OSI) que se anteponen a los datos provenientes de la capa de transporte (como TCP o UDP) para formar un paquete de datos IP. Su función es proporcionar al dispositivo de red toda la información necesaria para el encaminamiento y entrega del paquete.

El tamaño estándar de una cabecera IPv4 sin opciones adicionales es de 20 bytes (160 bits), aunque puede expandirse hasta un máximo de 60 bytes si se incluyen campos de opciones opcionales. Comprender cada uno de sus campos es imprescindible para analizar el tráfico mediante analizadores de protocolos (como Wireshark) y solucionar problemas de enrutamiento y fragmentación.


 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|  IHL  |Type of Service|          Total Length         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Identification        |Flags|      Fragment Offset    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Time to Live |    Protocol   |         Header Checksum       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Source Address                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Destination Address                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Options                    |    Padding    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                    Example Internet Datagram Header (RFC 791)

Estructura de la Cabecera IPv4 (20 a 60 Bytes)

A continuación se detalla la disposición en memoria de los campos de la cabecera IPv4 organizada en filas de 32 bits (4 bytes):

Offset (Bits) 0 - 3 4 - 7 8 - 15 16 - 31
Bit 0 Version (4 bits) IHL (4 bits) Type of Service / DSCP (8 bits) Total Length (16 bits)
Bit 32 Identification (16 bits) Flags (3 bits) Fragment Offset (13 bits)
Bit 64 Time to Live - TTL (8 bits) Protocol (8 bits) Header Checksum (16 bits)
Bit 96 Source IP Address / Dirección IP Origen (32 bits)
Bit 128 Destination IP Address / Dirección IP Destino (32 bits)
Bit 160+ Options & Padding / Opciones y Relleno (Opcional, 0 a 40 bytes)

Descripción de los Campos Principales

  • Version (4 bits): Indica la versión del protocolo IP utilizada (para IPv4 siempre contiene el valor binario 0100).
  • IHL - Internet Header Length (4 bits): Longitud de la cabecera expresada en palabras de 32 bits (4 bytes). El valor mínimo es 5 (5 x 4 bytes = 20 bytes).
  • Type of Service (8 bits): Utilizado por mecanismos de Calidad de Servicio (QoS) para clasificar y priorizar diferentes tipos de tráfico (voz, vídeo, datos). Se utiliza par DSCP (Differentiated Services Code Point).
  • Total Length (16 bits): Define el tamaño total del paquete en bytes (incluyendo la cabecera IPv4 y los datos de la capa superior). El tamaño máximo es de 65.535 bytes.
  • Identification, Flags y Fragment Offset (32 bits combinados): Campos utilizados exclusivamente para gestionar la fragmentación de paquetes cuando el tamaño supera la MTU del enlace.
    • Identification: Identificador único asignado por el emisor que reúne todos los fragmentos pertenecientes a un mismo paquete original con el objetivo de permitir el ensamblado del paquete original.
    • Flags: Control de fragmentación (bit 0: reservado. bit 1: (DF = Don't Fragment), si está activo, el router no debe fragmentar el paquete. bit 2 (MF = More Fragments), si está activo, indica que el paquete es un fragmento y que faltan más partes por llegar.).
    • Fragment Offset: Indica la posición exacta del fragmento dentro del paquete original (en bloques de 8 bytes) permitiendo reensamblar los datos en el orden correcto.
  • Time to Live / TTL (8 bits): Contador de saltos (hops). Se decrementa en 1 en cada router que atraviesa. Evita que un paquete enrutado en un bucle infinito circule para siempre en la red. Si el TTL llega a 0, el paquete se descarta y el router envía un mensaje ICMP Time Exceeded.
  • Protocol (8 bits): Indica qué protocolo de capa superior está encapsulado en el campo de datos del paquete (ej. 1 = ICMP, 6 = TCP, 17 = UDP, 89 = OSPF).
  • Header Checksum (16 bits): Suma de comprobación de errores dedicada exclusivamente a la cabecera IP. Se recalcula en cada router debido al cambio continuo del campo TTL.
  • Source & Destination IP Address (32 bits cada una): Las direcciones IP de 4 bytes del emisor y del receptor final.
  • Options (Variable): Campos opcionales (diagnóstico, seguridad, enrutamiento estricto).
  • Padding (Variable): Relleno con ceros para asegurar que la cabecera termine en un límite de 32 bits.
NOTA: Es importante notar que Header Checksum sólo protege la cabecera, no los datos (payload). La integridad de los datos depende de los protocolos de capa de transporte (TCP/UDP), lo cual es una diferencia fundamental respecto a otros protocolos modernos que calculan el checksum sobre todo el paquete.

Cabecera IPv4 vs. Cabecera IPv6

Criterio de comparación Cabecera IPv4 Cabecera IPv6
Tamaño básico Variable: 20 a 60 Bytes (depende del IHL). Fijo: 40 Bytes.
Longitud de Direcciones 32 bits (4 bytes) por dirección. 128 bits (16 bytes) por dirección.
Suma de Comprobación (Checksum) Sí (recalculado en cada router intermediario). No (eliminado para acelerar el procesamiento en routers).
Gestión de Fragmentación Campos integrados en la cabecera base. Cabeceras de extensión opcionales (realizada solo en el origen).
Campo para limitar saltos Time to Live (TTL) Hop Limit

Características principales:

  • No proporciona entrega fiable de datos ni control de flujo; es un protocolo sin conexión (connectionless) y de mejor esfuerzo (best-effort).
  • Los routers intermediarios leen la dirección IP de destino de la cabecera para consultar su tabla de enrutamiento y determinar la interfaz de salida.
  • El campo Protocol es indispensable para que la capa de red sepa a qué protocolo de Capa 4 debe entregar la carga útil (payload) una vez desestructurada la cabecera.
  • La variabilidad del tamaño debido al campo de opciones exige a los equipos procesar el campo IHL antes de acceder a la carga útil.

Actividad práctica

Objetivo:

Capturar paquetes reales mediante Wireshark, inspeccionar los campos individuales de la cabecera IPv4 y analizar el comportamiento del TTL y la fragmentación.

Tareas:

  1. Abre el analizador de tráfico Wireshark e inicia una captura en tu interfaz de red activa.
  2. Abre la consola de comandos y ejecuta un ping indicando un TTL específico o forzando la no fragmentación:
    • En Windows: ping 8.8.8.8 -i 5 -l 2000 -f (Establece TTL=5, tamaño de datos=2000 bytes y activa el bit Don't Fragment).
    • En Linux: ping 8.8.8.8 -t 5 -s 2000 -M do
  3. Aplica el filtro de Wireshark ip.addr == 8.8.8.8 e inspecciona el árbol de protocolos desplegando la sección Internet Protocol Version 4.
  4. Identifica y anota en tu cuaderno de prácticas los valores hexadecimales y decimales de los campos IHL, Total Length, TTL, Protocol, IP origen, IP destino y Header Checksum.

Preguntas de reflexión:

  1. ¿Por qué el campo Header Checksum de la cabecera IPv4 debe ser recalculado por cada router que procesa el paquete a lo largo de su ruta?
  2. Si el campo IHL (Internet Header Length) contiene el valor decimal 5, ¿cuántos bytes ocupa exactamente la cabecera IPv4 y cuántos bytes de opciones contiene?
  3. ¿Qué ocurre con un paquete IP cuando su tamaño supera la MTU de una interfaz de salida pero tiene activo el bit DF (Don't Fragment) en los Flags de la cabecera?
  4. ¿Por qué en la cabecera IPv6 se eliminó el campo Header Checksum que sí estaba presente en la cabecera IPv4?
  5. ¿Qué protocolo de capa de transporte se está encapsulando en el paquete si el campo Protocol de la cabecera IPv4 muestra el valor decimal 6? ¿Y si muestra el valor 17?
Haz clic aquí para ver las soluciones y explicaciones

1. ¿Por qué el campo Header Checksum de la cabecera IPv4 debe ser recalculado por cada router que procesa el paquete a lo largo de su ruta?

Porque en cada router por el que pasa el paquete, el campo TTL (Time to Live) se decrementa en 1 unidad. Al cambiar un valor dentro de la cabecera, la suma de comprobación anterior queda invalidada y el router debe recalcular el Header Checksum antes de reenviar el paquete a la siguiente interfaz.

2. Si el campo IHL (Internet Header Length) contiene el valor decimal 5, ¿cuántos bytes ocupa exactamente la cabecera IPv4 y cuántos bytes de opciones contiene?

Puesto que el campo IHL mide la longitud en palabras de 32 bits (4 bytes), un valor de 5 representa 5 x 4 = 20 bytes. Al ser el tamaño mínimo de una cabecera estándar sin opciones, significa que contiene 0 bytes de opciones.

3. ¿Qué ocurre con un paquete IP cuando su tamaño supera la MTU de una interfaz de salida pero tiene activo el bit DF (Don't Fragment) en los Flags de la cabecera?

El router no puede fragmentar el paquete debido a la restricción del bit DF. En su lugar, el router descarta el paquete e informa al emisor enviando un mensaje de error 

ICMP Tipo 3 Código 4 (Destination Unreachable - Fragmentation Needed and DF Set)
indicando además la MTU del enlace.

4. ¿Por qué en la cabecera IPv6 se eliminó el campo Header Checksum que sí estaba presente en la cabecera IPv4?

Se eliminó para acelerar el procesamiento de paquetes en los routers. Como la comprobación de errores ya la realizan los protocolos de enlace de datos (Capa 2, como Ethernet) y de transporte (Capa 4, como TCP/UDP), se consideró redundante obligar a los routers de Capa 3 a recalcular el checksum en cada salto.

5. ¿Qué protocolo de capa de transporte se está encapsulando en el paquete si el campo Protocol de la cabecera IPv4 muestra el valor decimal 6? ¿Y si muestra el valor 17?

El valor decimal 6 indica que se está encapsulando el protocolo TCP (Transmission Control Protocol), mientras que el valor decimal 17 indica que se está encapsulando el protocolo UDP (User Datagram Protocol).