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. Contiene la información necesaria de direccionamiento, control de fragmentación, tiempo de vida y verificación que permite a los routers enrutar el paquete a través de múltiples redes interconectadas hasta su destino final.

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.

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 / DSCP & ECN (8 bits): Utilizado por mecanismos de **Calidad de Servicio (QoS)** para clasificar y priorizar diferentes tipos de tráfico (voz, vídeo, datos).
  • 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 que reúne todos los fragmentos pertenecientes a un mismo paquete original.
    • Flags: Control de fragmentación (bit *DF* = Don't Fragment, bit *MF* = More Fragments).
    • Fragment Offset: Indica la posición exacta del fragmento dentro del paquete original (en bloques de 8 bytes).
  • Time to Live / TTL (8 bits): Contador de saltos límite que 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.

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.

Analogía: La cabecera IPv4 es como el sobre de una carta postal. Contiene la dirección del remitente (IP Origen), la del destinatario (IP Destino), un sello que caduca si la carta da demasiadas vueltas de buzón en buzón (TTL), una etiqueta que indica si el contenido es urgente (QoS) e información de si la carta se ha tenido que cortar en varias partes por ser demasiado grande (Fragmentación). La carta que va dentro es la carga útil (TCP/UDP).

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** 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).



 Una cabecera IP es el conjunto de campos de control que precede a los datos en un paquete IP. Su función es proporcionar al dispositivo de red toda la información necesaria para el encaminamiento y entrega del paquete. En la versión IPv4, esta cabecera tiene una longitud mínima de 20 bytes y puede variar hasta 60 bytes.

Campos fundamentales de la cabecera IPv4:

  • Versión: Identifica si el paquete es IPv4 o IPv6.

  • Longitud de cabecera (IHL): Tamaño total de la cabecera.

  • Tipo de Servicio (ToS/DSCP): Define la prioridad o calidad de servicio del paquete.

  • Longitud Total: Tamaño completo del paquete (cabecera + datos).

  • Identificación, Flags y Fragment Offset: Gestionan la fragmentación del paquete en caso de pasar por enlaces con MTU reducida.

  • Tiempo de Vida (TTL): Contador que impide que un paquete circule indefinidamente por la red (se decrementa en cada router).

  • Protocolo: Indica el protocolo de capa superior (ej. TCP, UDP, ICMP).

  • Direcciones IP (Origen y Destino): Direcciones lógicas necesarias para el enrutamiento.


 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)

Desglose de Campos (Cabecera IPv4)

  1. Version (4 bits): Indica la versión del protocolo IP. Para IPv4, el vvalor es siempre 0100 (4).
  2. IHL (Internet Header Length - 4 bits): Indica la longitud de la cabecera en palabras de 32 bits. Si no hay opciones, su valor es 5 (5 x 4 bytes = 20 bytes).
  3. Type of Service (ToS - 8 bits): Originalmente definido para indicar la prioridad o calidad de servicio (QoS) solicitada. Actualmente se utiliza para DSCP (Differentiated Services Code Point).
  4. Total Length (16 bits): Longitud total del paquete (cabecera + datos) en bytes. El valor máximo es 65,535 bytes.
  5. Identification (16 bits): Identificador único asignado por el emisor para permitir el reensamblado de fragmentos de un paquete original.
  6. Flags (3 bits): Controlan la 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.
  7. Fragment Offset (13 bits): Indica la posición del fragmento dentro del paquete original, permitiendo reensamblar los datos en el orden correcto.
  8. Time to Live (TTL - 8 bits): Contador de saltos (hops). Se decrementa en 1 en cada router. Si llega a 0, el paquete se descarta para evitar bucles infinitos.
  9. Protocol (8 bits): Especifica qué protocolo de capa superior encapsula el paquete (ej. TCP=6, UDP=17, ICMP=1).
  10. Header Checksum (16 bits): Valor de verificación de integridad exclusivo de la cabecera. Se recalcula en cada router debido a la modificación del campo TTL.
  11. Source Address (32 bits): Dirección IP del nodo emisor.
  12. Destination Address (32 bits): Dirección IP del nodo destino.
  13. Options (Variable): Campos opcionales (diagnóstico, seguridad, enrutamiento estricto).
  14. 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.
Actividad Práctica:

Objetivo: Capturar y diseccionar una cabecera IP real mediante herramientas de análisis de protocolos.

Escenario: Se utilizará un analizador de protocolos (como Wireshark) para examinar la estructura binaria de un paquete capturado en la interfaz de red local.

Procedimiento:

  1. Captura de tráfico: Iniciar la captura de paquetes en la interfaz de red activa. Ejecutar un ping hacia un host externo para generar tráfico ICMP (que encapsula el paquete IP).

  2. Identificación: En la captura, localizar la sección "Internet Protocol" (IPv4).

  3. Inspección de campos: Expandir la sección de la cabecera y observar los valores de los campos mencionados (TTL, Protocolo, IP Origen, IP Destino).

  4. Verificación del TTL: Identificar el valor del campo "Time to Live" y comparar el valor observado con el valor esperado según la distancia (saltos) hasta el destino.

  5. Cuestión técnica: ¿Por qué un router debe recalcular el Header Checksum después de decrementar el campo TTL de un paquete?