Podcast: Descargar (Duración: 19:56 — 18.9MB)
TTL y Hop Limit, su homólogo en IPv6, definen un concepto que tocamos el otro día cuando hablábamos de traceroute.
En cualquier red queremos garantizar que los paquetes puedan circular por ella, pero no queremos que puedan circular eternamente, así que es necesario definir de alguna manera el tiempo que pueden permanecer en la red.
Pero más que definir el tiempo que pueden permanecer nos interesa definir el número de saltos de nivel 3 que pueden atravesar, es decir, el número de redes a atravesar.
En el capítulo de «cómo funciona el traceroute» ya comentamos que se empezaba con un número de saltos definido en el campo TTL de la cabecera y que se iría decrementando en uno por cada nivel 3 que se atravesara.
Si os fijáis en la cabecera de Ipv4 tenemos el campo TTL, pero en la cabecera de Ipv6 tenemos el Hop Limit, en ambos caso 8 bits, así que el número máximo a definir será de 255.
TTL y Hop Limit en sus RFCs
Lo primero será leernos las RFCs asociadas para ver qué es exactamente el TTL tanto en IPv4 como en IPv6, y aquí nos llevamos la primera sorpresa y es que el TTL en IPv4 se ideó para ser usado con segundos y no con saltos,
TTL en IPv4
Obviamente era muy complicado medir el tiempo en segundos en la cabecera de Ipv4, así que se optó por saltos.
Tiempo de vida: 8 bits
Este campo indica el tiempo máximo que se permite que el datagrama permanecer en el sistema de Internet. Si este campo contiene el valor cero, entonces el datagrama debe destruirse. Este campo está modificado en el procesamiento de encabezados de IP. El tiempo se mide en unidades de segundos, pero dado que cada módulo que procesa un datagrama debe disminuir el TTL en al menos uno incluso si procesa el datagrama en menos de un segundo, el TTL debe considerarse solo como un ligado al tiempo que puede existir un datagrama. La intención es que los datagramas que no se pueden entregar deben descartarse y así limitar el máximo de vida útil del datagrama.
TTL en la RFC 791 – IPv4
En IPv6 sin embargo viene mejor descrito, pero entre la RFC 2460, la original de Diciembre de 1998 y la RFC 8200 de Julio de 2017 hay un cambio significativo que nos afecta muchísimo.
Hop Limit en IPv6
Mientras en la primera versión se establecía que en el momento en el que el Hop Limit llegara a 0 se descartaba en la modificación de 2017 se establece que en el caso que el paquete llegue a Hop Limit de 0 si ha llegado al destino entocnes debe procesarse el paquete y no descartarlo.
Hop Limit
Entero sin signo de 8 bits. Decrementado en 1 por cada nodo que reenvía el paquete. El paquete se descarta si el límite de saltos se reduce a cero.
Hop Limit en la RFC 2460 – IPv6 (obsoleta)
Hop Limit
Entero sin signo de 8 bits. Decrementado en 1 por cada nodo que reenvía el paquete. Al reenviar, el paquete se descarta si el límite de saltos era cero cuando se recibe o se reduce a cero. Un nodo que es el destino de un paquete no debe descartar un paquete con límite de saltos igual a cero; debería procesar el paquete normalmente.
Hop Limit en la RFC 8200 – IPv6
Tanto en IPv4 como en IPv6 en el caso de descartar un datagrama se puede contestar con un «Time Exceeded Message» que viene definido para IPv4 en la RFC 792 en la página 6 y para IPv6 viene definido en la RFC 4443 en la sección 3.3 de la página 11.
Traceroute en Ipv6
Una vez explicado todo esto comentaros que el traceroute en IPv6 utiliza el Hop Limit para su funcionamiento, el resto es igual.
Os dejo aquí un vídeo para que podáis ver la captura de los paquetes de un traceroute con ipv6, se ha colado algún paquete de más, pero se ve claro el tracerotue.
MTR
En el caso de MTR no se utiliza UDP, sino que simplemente ICMP y el TTL o el Hop Count.
Foto de cabecera Jill Wellington en Pexels