TTL IPの改ざんが危険なのはなぜですか？
私はiptablesのマンページ（就寝前の軽い読書）を読んでいて、 'TTL'ターゲットに出くわしましたが、警告します：
TTLフィールドを設定またはインクリメントすることは非常に危険である可能性があります
そして
ローカルネットワークを出るパケットの値を設定したり、増分したりしないでください。
TTL lowerをデクリメントまたは設定すると、宛先に到達する前にパケットがドロップされる可能性がありますが、インクリメントによってどのような影響がありますか？
TTLは、ルーターを通過するときに減少します。これにより、パケットが循環して移動している場合、最終的には確実に死ぬことになります。
TTLフィールドは8ビットフィールド（10進数の255）です。そのため、最初に高く設定しても、実際にはそうすることができないので、大したことではありません。整形式のパケットで大きくなります（ただし、いくつかは不正な形式のIPパケットを受け入れる場合があります）。
ただし、何かがそれをインクリメントし、インクリメントのステップがループの一部である場合、パケットはゼロに到達せずに循環し続ける可能性があります。時間の経過とともに（非常に短くなるか、徐々にリークが発生する可能性があります）、そのループを含むシステムでパケットが蓄積され、過負荷が発生する可能性があります。
TTLは、基本的にルーティングを正常に保ちます。パケットに非常に大きなTTLがあり、何らかの理由で循環ルートでキャッチされた場合、大量のトラフィック（「パケットストーム」と呼ばれます）が発生し、通常の操作に干渉する可能性があります。TTLが低すぎると、宛先に到達する前にパケットが失われるため、接続が失われます。
答えが見落とされているように見えるが、純粋に学術的である1つの点があります（インターネット上で必要なホップの数が多いため）。パケットは宛先に到達できますが、返されるパケットには影響せず、ネットワークに到達する前に期限切れになります。
更新： Wikipediaのこのページ によると：
理論的には、IPv4では、存続時間は秒単位で測定されますが、データグラムを渡すすべてのホストはTTLを少なくとも1ユニット削減する必要があります。実際には、TTLフィールドは、ホップごとに1ずつ減らされます。この慣例を反映するために、フィールドはIPv6でホップ制限の名前が変更されました。
更新2：誰かが私の投稿を更新してWikipediaを参照したので、RFC自体を参照するのが最善だと思いました- http://www.ietf.org/rfc/rfc791.txt -ただ検索TTLそこにあり、それを説明するのはかなりうまくいきます：
このフィールドは、データグラムがインターネットシステムにとどまることができる最大時間を示します...データグラムを処理するすべてのモジュールは、データグラムをより少なく処理する場合でも、TTLを少なくとも1つ減らす必要があります秒より
より高いTTL値を使用できるプログラムは1つだけ知っています。これはtracerouteです。名前が示すように、このプログラムは、宛先ホストへのルートを変更して、= TTL値。標準の最大ホップ数は20ですが、増やすことができます。
パケットを処理する各ルーターは、パケットが宛先に到達するまでTTL=値をデクリメントするか、TTLがゼロに到達して終了します。
他の人が言ったように、TTLを増やすと、負のサイクルがある場合、パケットが死ぬことはありません。一般的に、TTL値が十分に大きくない場合、より大きなTTL=を試すロジックは、おそらくエンドツーエンドのクライアントによって処理されるべきです。
ルーターがサイクル（ツリーのようなトポロジ）にないことが確実な場合は、理論的にはTTLの値を安全に増やすことができます。ただし、標準よりも多くのホップを許可すると、外部ネットワークでの輻輳の可能性が高くなります。内部ネットワークと外部ネットワークの間にルーターのチェーンが長い場合は、サイクルがない限り、TTL=の値を大きくすると役立つ場合があります。 、エッジをネットワークに追加してサイクルを作成するのは非常に簡単です。そのため、最初にパケットが発信されたTTLの値が大きいほど、より安全です。