He estado leyendo la página de manual de iptables (lectura ligera antes de dormir) y me encontré con el objetivo 'TTL', pero advierte:
Establecer o incrementar el campo TTL puede ser muy peligroso
y
¡Nunca establezca o incremente el valor de los paquetes que salen de su red local!
Puedo ver cómo quizás disminuir o establecer el TTL más bajo podría hacer que los paquetes se caigan antes de llegar al destino, pero ¿qué efecto podría tener el incremento?
Respuestas:
El TTL se reduce cuando pasa a través de un enrutador. Esto asegura que si el paquete viaja en círculos, eventualmente morirá.
El campo TTL de un paquete IP v4 es un campo de 8 bits (255 decimales). Por lo tanto, establecerlo alto al principio no es un gran problema ya que en realidad no puede ser tan grande en un paquete bien formado (aunque, algunas cosas pueden aceptar paquetes IP mal formados).
Sin embargo, si algo lo incrementa, y el paso de incremento es parte del ciclo , el paquete podría continuar en círculos sin llegar a cero. Con el tiempo (podría ser muy corto o una fuga gradual), los paquetes podrían acumularse en el sistema que contiene ese bucle y provocar una sobrecarga.
El TTL en los paquetes mantiene el enrutamiento sano, básicamente. Si un paquete tuviera un TTL muy grande y fuera atrapado en una ruta circular por alguna razón, podría causar una tonelada de tráfico (llamada "tormenta de paquetes") e interferir con las operaciones normales. Un TTL demasiado bajo daría como resultado una pérdida de conectividad, ya que perderías el paquete antes de que llegara al destino.
Hay un punto en el que las respuestas parecen haberse perdido, pero que sería puramente académico (debido a la cantidad de saltos que se requieren en Internet): si un paquete normalmente no llega a su destino debido a un TTL que expira, entonces increméntelo permitiría que el paquete llegue a su destino, pero no afectaría a los paquetes devueltos y expirarían antes de llegar a su red.
ACTUALIZACIÓN: Según esta página en Wikipedia :
En teoría, bajo IPv4, el tiempo de vida se mide en segundos, aunque cada host que pasa el datagrama debe reducir el TTL en al menos una unidad. En la práctica, el campo TTL se reduce en uno en cada salto. Para reflejar esta práctica, el campo se renombra como límite de salto en IPv6.
ACTUALIZACIÓN 2: cuando alguien actualizó mi publicación y hizo referencia a Wikipedia, pensé que sería mejor hacer referencia al RFC en sí mismo - http://www.ietf.org/rfc/rfc791.txt - Simplemente busque TTL allí y lo hace bastante un buen trabajo de explicarlo:
Este campo indica el tiempo máximo que el datagrama puede permanecer en el sistema de Internet ... 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
Conozco solo un programa, que podría usar un valor TTL más alto, y eso es traceroute. Como su nombre lo indica, rastrea la ruta a un host de destino modificando el valor TTL. El salto máximo estándar es de 20, pero puede aumentarlo.
Cada enrutador que maneja un paquete disminuye el valor TTL, hasta que el paquete llega a su destino, o TTL llega a cero, y muere.
Como han dicho otros, aumentar TTL podría dar como resultado paquetes que nunca mueren, si hay un ciclo negativo. En general, si un valor TTL no es lo suficientemente grande, la lógica para probar un TTL más grande probablemente debería ser manejada por los clientes de extremo a extremo.
Si está seguro de que un enrutador no está en un ciclo (topología en forma de árbol), en teoría podría aumentar de forma segura el valor TTL. Dicho esto, permitir más saltos de lo normal podría hacer que la congestión sea más probable en la red externa. Si tiene una larga cadena de enrutadores entre la red interna y la externa, siempre que no haya un ciclo, un valor TTL más grande podría ayudar. Dicho esto, podría ser bastante fácil para alguien agregar un borde a la red y crear un ciclo, por lo que comenzar con un valor TTL más grande donde el paquete se originó en primer lugar es mucho más seguro.