Laboratorio 4 - Wireshark (IP y ICMP)

IP


1️⃣ Selecciona el primer mensaje de solicitud de eco ICMP enviado desde tu ordenador y expande la parte IP del paquete en la ventana de detalles del paquete. ¿Cuál es la dirección IP de tu ordenador?
192.168.1.102
2️⃣ Dentro de la cabecera IP, ¿cuál es el valor en el campo de protocolo de la capa superior?
Protocol: ICMP
3️⃣ ¿Cuántos bytes tiene la cabecera IP? ¿Cuántos bytes tiene el campo de datos del datagrama IP? Explica cómo determinas estos números.
  • Header → 20 Bytes
  • Datos → 64 Bytes
Si hacemos click en cada capa, nos muestra el tamaño de cada una de estas. También, si hace click en la capa de IP, vemos q el campo Header length es 20 Bytes, y el campo Total length es 84 bytes, por lo que también podremos comprobar así estos valores
4️⃣ ¿Ha sido fragmentado este datagrama IP? ¿Cómo lo sabes?
No, el Fragment offset está a 0 y no está puesta la flag More fragments
5️⃣ ¿Qué campos en el datagrama IP cambian siempre de un datagrama al siguiente dentro de esta serie de mensajes ICMP enviados por tu ordenador?
  • El campo del identificador
  • El checksum
  • El TTL
6️⃣ ¿Qué campos se mantienen constantes? ¿Qué campos deberían mantenerse constantes? ¿Qué campos deberían cambiar? ¿Por qué?
  • La IP origen y destino
  • El protocolo
  • La longitud y las flags
  • Header length
7️⃣ Describe el patrón que observas en los valores del campo Identification del datagrama IP
Se van incrementando desde 13008
8️⃣ ¿Cuál es el valor del campo Identification y del campo TTL?
  • Id → 40316
  • TTL → 255
9️⃣ ¿Permanecen estos valores inalterados para todas las respuestas ICMP TTL-excedido enviadas a tu ordenador desde el router más cercano (first hop)? ¿Por qué?
El identificador vale 0 en todas, pero el TTL se decrementa en 1 según cuantos hops de distancia está el router
1️⃣0️⃣ Encuentra el primer mensaje de solicitud de eco ICMP que fue enviado por tu ordenador después de haber cambiado el tamaño de paquete a 2000 bytes. ¿Se ha fragmentado este mensaje en más de un datagrama IP?
Sí el paquete se ha framentado en 2 datagramas IP (en la captura son el 92 y 93)
1️⃣1️⃣ Extrae el primer fragmento del datagrama IP fragmentado. ¿Qué información de la cabecera IP indica que el datagrama ha sido fragmentado? ¿Qué información de la cabecera IP indica si este es el primero o el último fragmento? ¿Cuánto de largo es este datagrama IP?
Al estar activada la flag More fragmets sabemos seguro que ha sido fragmentado, a su vez, sabemos que no es el último fragmento ya que el último fragmento no tiene esta flag activada nunca. Sabremos que fragmento es mirando el Fragment offset
 
Para saber el tamaño del datagrama miraremos el offset del último fragmento, a este valor le tendremos q sumar la longitud de los datos del último fragmento
  • Offset → 1480
  • Total length último frag. → 548
Dado que el campo total length ya tiene en cuenta la cabecera, no tenemos q sumarla otra vez
1480+548=20281480+548 = 2028
1️⃣2️⃣ Ahora observa el segundo fragmento del datagrama IP fragmentado. ¿Qué información de la cabecera IP indica que este no es el primer fragmento del datagrama? ¿Hay más fragmentos? ¿Cómo lo sabes?
Sabiendo q está fragmentado, con tan solo ver que el More fragments está a 0 ya sabemos q no es el primero, a su vez, al estar a cero, sé q no hay más datagramas. También podríamos haber mirado el offset, al no valer 0 sabemos que no es el primero
1️⃣3️⃣ ¿Qué campos cambian en la cabecera IP entre el primer y el segundo fragmentos?
  • El More fragments y el Fragment offset
  • El Total length
  • El checksum
1️⃣4️⃣ ¿Cuántos fragmentos se crearon del datagrama original?
Se crearon 3, esto lo sé ya tanto mirando la captura. Para encontrarlo facilmente buscaremos cuando aparezcan 2 paquetes seguidos en rojo (dos fragmento)
También lo podemos saber ya que si el paquete son 3500, lo que sin la cabecera son 3480, si divido eso entre 1500 me da 2.32, osea que necesitaré 3
1️⃣5️⃣ ¿Qué campos cambian en la cabecera IP entre fragmentos?
  • El More fragments y el Fragment offset
  • El Total length
  • El checksum

ICMP


1️⃣ ¿Cuál es la dirección IP de tu host? ¿Cuál es la dirección IP de tu host destino?
  • Host local → 192.168.1.101
  • Host remoto → 143.89.14.34
2️⃣ ¿Por qué los paquetes ICMP no tienen números de puerto de origen o destino?
Porque ICMP es un protocolo de red, y los puertos son para los protocolos de capa de transporte
3️⃣ Observa uno de los paquetes de solicitud de ping enviados por tu host. ¿Cuáles son el tipo y código ICMP? ¿Qué otros campos tiene este paquete ICMP? ¿Cuántos bytes tienen los campos de checksum, número de secuencia e identificador?
  • Tipo → 8
  • Código → 0
Tiene campos para el checksum, el identificador, y para el número de secuencia. Todos ellos son de 2 Bytes
4️⃣ No existe esta pregunta
5️⃣ ¿Cuál es la dirección IP de tu host? ¿Cuál es la dirección IP de tu host destino?
  • Host local → 192.168.1.101
  • Host remoto → 138.96.146.2
6️⃣ Si se enviaran paquetes UDP en lugar de ICMP (como en Unix/Linux), ¿ el número de protocolo IP sería aún 01 para los paquetes de prueba? Si no, ¿cuál sería?
Sería el 17
7️⃣ Examina el paquete ICMP de eco. ¿Es diferente a los paquetes ICMP de consulta ping que vimos en la primera parte de la práctica? Si es así, ¿por qué?
No hay diferencia
8️⃣ Examina ahora el paquete ICMP de error. Tiene más campos que el paquete ICMP de eco. ¿Qué se incluye en esos campos?
No tiene más campos, pero incluye el segmento IP y el paquete ICMP que produjo el error
9️⃣ Examina los últimos tres paquetes ICMP recibidos por el host origen. ¿En qué se diferencian estos paquetes de los paquetes ICMP de error? ¿Por qué son diferentes?
En que estos paquetes no han acabado en error, es decir, han llegado a su destino sin que se acabe su TTL
1️⃣0️⃣ Dentro de las medidas que realiza el traceroute, ¿hay algún enlace con un retardo significativamente mayor a los demás? Si observamos la Figura 4, ¿hay algún enlace con un retardo significativamente mayor a los demás? Basándote en los nombres de los routers, ¿puedes averiguar la localización de los dos routers al final de este enlace?
En el salto 10, se pasa de 26ms a 98ms por lo que este router tiene un retardo muy grande comparado con el retardo entre el resto de routers.
Parece q se está intentando hacer una conexión entre Nueva York y algún lugar de Francia, ya que en el paquete 9 podemos ver el subdominio nyc y en el salto 14 vemos un TLD de Francia, por lo que asumo q el retardo se debe a que la petición es transoceánica
Los dos últimos routers parecen estar en la ciudad de Niza dado que el paquete 16 tiene nice en su subdominio