为什么篡改 IP 的 TTL 很危险？

Question

我一直在阅读 iptables 手册页（睡前阅读），我遇到了“TTL”目标，但它警告：

设置或增加 TTL 字段可能非常危险

和

永远不要设置或增加离开本地网络的数据包的值！

我可以看到减少或将 TTL 设置得更低可能会导致数据包在到达目的地之前被丢弃，但是增加会产生什么影响？

Answer 1

当它通过路由器时，TTL 会递减。这可以确保如果数据包在绕圈传播，它最终会死亡。

IP v4 数据包的 TTL 字段是一个 8 位字段（十进制 255）。因此，在开始时将其设置为高并不是什么大问题，因为它在格式良好的数据包中实际上不可能那么大（尽管有些东西可能会接受格式错误的 IP 数据包）。

然而，如果有东西增加它，并且增加步骤是循环的一部分，数据包可以继续循环而不会达到零。随着时间的推移（可能很短，或逐渐泄漏），数据包可能会在包含该循环的系统中堆积，导致其过载。

Answer 2

数据包上的 TTL 基本上保持路由正常。如果一个数据包有一个非常大的 TTL 并且由于某种原因被捕获在一个循环路由中，它可能会导致大量流量（称为“数据包风暴”）并干扰正常操作。太低的 TTL 会导致连接丢失，因为您会在数据包到达目的地之前丢失数据包。

Answer 3

答案似乎遗漏了一点，但这纯粹是学术性的（因为 Internet 上似乎需要多少跳）：如果由于 TTL 到期，数据包通常无法到达目的地，则增加它将允许数据包到达其目的地，但不会影响返回的数据包，并且它们会在到达您的网络之前过期。

更新：根据维基百科上的这个页面：

理论上，在 IPv4 下，生存时间以秒为单位，尽管每个通过数据报的主机都必须将 TTL 减少至少一个单位。在实践中，TTL 字段在每一跳上减一。为了反映这种做法，该字段在 IPv6 中更名为跳数限制。

更新 2：当有人更新了我的帖子并引用了维基百科时，我认为最好参考 RFC 本身 - http://www.ietf.org/rfc/rfc791.txt - 只需在那里搜索 TTL 就可以了很好地解释了它：

该字段表示允许数据报保留在互联网系统中的最长时间...每个处理数据报的模块必须将 TTL 至少减少 1，即使它在不到一秒的时间内处理数据报