Del byte 0 al 7:
y tenemos la siguiente información de sus campos:
IHL: Especifica la longitud del encabezado de IP en palabras de 32 bits (4 Bytes) y el valor mínimo es 5.
TOS: Type of service, 8 bits, especifica los parámetros para el tipo de servicio solicitado. Los parámetros pueden ser utilizados por las redes para defini el manejo del datagrama durante el transporte. El bit M fue agregado en el RFC 1349.
Total Lenght: es la longitud total del datagrama, en este caso es 0x003C (60 bytes).
Identification: Usado para indentificar fragmentos de un datagrama deaquellos de otro. El módulo de protocolo que origina al datagrama fija el valor del campo de identificación a un valor que debe ser único para el par de Fuente-Destino y protocolo por todo el tiempo que el datagrama estará activo en el sistema de red. El módulo de protocolo de origen de un datagrama completo pone los bits MF y el Fragment Offset a cero.
Fragment Offset, 13 bits: usado para dirigir el reensamblado de un datagrama fragmentado. En este caso es cero porque no hay más fragmentos.
Del byte 8 al 15:
TTL: Time to live, es un temporizador para llevar un control del tiempo de vida del datagrama. Cuando el TTL es decrementado a cero, el datagrama es desechado.
Protocol: este campo especifica el protocolo encapsulado, en este caso el valor es 1, lo que nos indica que se trata de un paquete de ICMP (ping). Consulta los valores en la tabla (click aquí).
Header Checksum: 16 bits de la suma de verificación del encabezado de IP y las opciones IP.
Source IP Address: Es la dirección IP del transmisor, en este caso 192.168.1.1 (0xC0.A8.01.01).
Del byte 16 al 27:
Destination IP Address: es la dirección IP del destino, en este caso 192.168.1.17 (0xC0.A8.01.11).
C, Class y Option: en este caso indican (tabla de valores):
- 0x0: no copiar
- 0x00: mensaje de control
- 0x1000: solicitud de Echo (RFC 792, Summary of Message Types, 8 Echo).
Padding: es de longitud variable y sirve como relleno para asegurar que los datos comienzan tras de una frontera de 32 bits después de la dirección de destino.
Aquí es importante destacar que al tratarse de un mensaje de control (ICMP) se utilizan los bytes del 20 al 27 para información de control; y se usan de la siguiente manera (RFC792):
20 21 22 23
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type Code Checksum
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Identifier Sequence Number
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Data ...
+-+-+-+-+-
De aquí obtenemos que:
- byte 20, es un paquete tipo 8 (echo request)
- byte 21, siempre va a cero
- byte 22 y 23, es el checksum de ICMP
- bytes 24 y 25, si el byte 21=0 el identificador ayuda a hacer match entre las solicitudes y las respuestas de eco; puede ser 0 o puede usarse para identificar una sesión.
- bytes 26 y 27 son para llevar la secuencia de las solicitudes de eco, y quien responde debe usar el mismo número; la secuencia debe incrementarse con cada nueva solicitud (en una instrucción típica de ping se envían 4 paquetes, y pueden enviarse cuantos se desee).
Bytes del 28 al 59 (32 bytes)
Son los datos de relleno que se colocaron dentro del mensaje de Echo, y se trata de una secuencia, del 0x61 al 0x77, y se vuelve a comenzar. Cuando se responde la solicitud de eco se debe incluir exactamente la misma información en el campo de datos.
