IPv4 地址耗尽到底有多严重？

Question

多年来，媒体一直在报道现在可用的 IPv4 地址很少的问题。但另一方面，我正在使用一家服务器托管公司，该公司很乐意以少量资金提供公共 IPv4 地址。我的私人互联网连接带有公共 IPv4 地址。

这怎么可能？问题是否像媒体想让我们相信的那样严重？

Answer 1

这很糟糕。以下是我与消费者 ISP 为解决 IPv4 地址短缺而采取的第一手经验的示例列表：

• 在城市之间反复围绕 IPv4 块进行混洗，导致客户短暂中断和连接重置。
• 将DHCP租用时间从几天缩短到几分钟。
• 允许用户选择是否要在客户端设备 (CPE) 上进行网络地址转换 (NAT)，然后无论如何都要追溯地为每个人打开它。
• 为已经利用机会选择退出 NAT 的客户在 CPE 上启用 NAT。
• 减少CPE 强制执行的并发活动媒体访问控制 (MAC) 地址的数量上限。
• 为注册服务时拥有真实 IP 地址的客户部署运营商级 NAT (CGN)。

所有这些都降低了 ISP 向其客户销售的产品的质量。他们为什么要对客户这样做的唯一合理解释是缺乏 IPv4 地址。

IPv4地址短缺导致地址空间碎片化，存在多个缺点：

• 管理开销不仅花费时间和金钱，而且容易出错并导致中断。
• 几年前，骨干路由器上大量使用内容可寻址内存 (CAM)容量，当它超过特定流行路由器模型的限制时，导致多个 ISP出现严重中断。

如果没有 NAT，我们今天无法使用 37 亿个可路由的 IPv4 地址。但 NAT 是一种脆弱的解决方案，它为您提供不太可靠的连接和难以调试的问题。NAT 的层数越多，情况就越糟。二十年的努力使单层 NAT 大部分工作，但我们已经跨越了单层 NAT 足以解决 IPv4 地址短缺问题的地步。

Answer 2

在我们开始用完 IPv4 地址之前，我们没有（广泛）使用 NAT。每台互联网连接的计算机都有自己的全球唯一地址。首次引入 NAT 时，它从为 ISP 的客户提供每台客户使用/拥有的设备 1 个真实地址转变为为 1 个客户提供 1 个真实地址。当我们应该切换到 IPv6 时，这解决了一段时间（几年）的问题。与其切换到 IPv6，（大多数情况下）每个人都在等待其他人切换，因此（大多数情况下）没有人推出 IPv6。现在我们又遇到了同样的问题，但这一次，正在部署第二层 NAT (CGN)，以便 ISP 可以在多个客户之间共享 1 个真实地址。

如果 NAT 并不可怕，那么 IP 地址耗尽并不是什么大问题，包括在最终用户无法控制它的情况下（运营商级 NAT 或 CGN）。

但我认为 NAT 很糟糕，尤其是在最终用户无法控制它的情况下。并且（作为一个从事网络工程/管理工作但拥有软件工程学位的人）我认为，通过部署 NAT 而不是 IPv6，网络管理员已将解决地址耗尽的重心从他们的领域转移到最终用户身上和应用程序开发人员。

那么（在我看来），为什么 NAT 是一个应该避免的可怕、邪恶的事情？

让我们看看我是否可以公正地解释它破坏了什么（以及它导致了什么问题，我们已经习惯了以至于我们甚至没有意识到它可能会更好）：

• 网络层独立性
• 点对点连接
• 资源的一致命名和位置
• 流量的最佳路由，主机知道他们的真实地址
• 追踪恶意流量来源
• 将数据和控制分离到单独连接的网络协议

让我们看看我是否可以解释这些项目中的每一个。

网络层独立性

ISP 应该只传递第 3 层数据包，而不关心它上面的层中有什么。无论您是通过 TCP、UDP 还是更好/更奇特的东西（也许是 SCTP？甚至是其他一些比 TCP/UDP 更好但由于缺乏 NAT 支持而模糊的协议），您的 ISP 都不应该关心; 对他们来说，这一切都应该看起来像数据。

但事实并非如此——当他们实施 NAT 的“第二波”，“运营商级”NAT 时，情况并非如此。然后他们必须查看并支持您想要使用的第 4 层协议。现在，这实际上意味着您只能使用 TCP 和 UDP。其他协议要么被阻止/丢弃（根据我的经验，绝大多数情况下），要么只是转发到使用该协议的 NAT“内部”的最后一个主机（我见过 1 个执行此操作的实现）。即使转发到使用该协议的最后一台主机也不是真正的解决方案——只要两台主机使用它，它就会中断。

我想有一些 TCP 和 UDP 的替代协议目前尚未测试和使用，只是因为这个问题。不要误会我的意思，TCP 和 UDP 的设计非常好，令人惊讶的是，它们都能够扩展到我们今天使用互联网的方式。但谁知道我们错过了什么？我读过关于 SCTP 的文章，听起来不错，但从未使用过，因为 NAT 不切实际。

点对点连接

这是一个很大的。实际上，在我看来是最大的。如果您有两个最终用户，都在他们自己的 NAT 之后，无论哪一个先尝试连接，另一个用户的 NAT 都会丢弃他们的数据包，连接将不会成功。

这会影响游戏、语音/视频聊天（如 Skype）、托管您自己的服务器等。

有解决方法。问题在于，这些变通办法会花费开发人员时间、最终用户时间和不便，或者服务基础设施成本。而且它们并非万无一失，有时会损坏。（请参阅其他用户对 Skype 中断的评论。）

一种解决方法是端口转发，您可以对 NAT 设备进行编程以将特定传入端口转发到 NAT 设备后面的特定计算机。有很多网站专门介绍如何为所有不同的 NAT 设备执行此操作。请参阅https://portforward.com/。这通常会花费最终用户的时间和挫败感。

另一种解决方法是为应用程序添加对诸如打洞之类的支持，并维护不在 NAT 后面的服务器基础设施以引入两个 NAT 客户端。这通常会花费开发时间，并使开发人员处于潜在的维护服务器基础设施的位置，而这在以前是不需要的。

（还记得我说过部署 NAT 而不是 IPv6 将问题的重心从网络管理员转移到最终用户和应用程序开发人员吗？）

网络资源的一致命名/位置

由于在 NAT 内部和外部使用不同的地址空间，因此 NAT 内部设备提供的任何服务都有多个地址可以到达它，使用正确的地址取决于客户端从哪里访问它. （即使在端口转发工作之后，这仍然是一个问题。）

如果您在 NAT 中有一个 Web 服务器，例如在端口 192.168.0.23 端口 80 上，并且您的 NAT 设备（路由器/网关）的外部地址为 35.72.216.228，并且您为 TCP 端口 80 设置了端口转发，现在您的可以使用 192.168.0.23 端口 80 或 35.72.216.228 端口 80 访问网络服务器。您应该使用哪个取决于您是在 NAT 内部还是外部。如果您在 NAT 之外，并使用 192.168.0.23 地址，您将无法到达预期的位置。如果您在 NAT 内部，并且使用外部地址 35.72.216.228，则可能会到达您想要的位置，如果您的 NAT 实现是支持发夹的高级实现，但随后为您的请求提供服务的 Web 服务器会将该请求视为来自您的 NAT 设备。这意味着所有流量都必须通过 NAT 设备，即使 NAT 后面的网络中存在更短的路径，也意味着 Web 服务器上的日志变得不那么有用了，因为它们都将 NAT 设备列为来源连接。如果您的 NAT 实现不支持发夹，那么您将无法达到预期目标。

一旦您使用 DNS，这个问题就会变得更糟。突然间，如果您希望 NAT 后托管的某些东西一切正常，您将需要根据谁在询问（AKA 水平分割 DNS，IIRC），对托管在 NAT 内的服务的地址给出不同的答案。哎呀。

这一切都假设您有一个了解端口转发和发夹式 NAT 以及水平分割 DNS 的人。最终用户呢？当他们购买消费者路由器和一些 IP 安全摄像头并希望它“正常工作”时，他们有多少机会将这一切设置正确？

这导致我：

流量的最佳路由，主机知道他们的真实地址

正如我们所见，即使使用高级发夹式 NAT 流量也并不总是通过最佳路径流动。即使在知识渊博的管理员设置服务器并具有发夹式 NAT 的情况下也是如此。（当然，水平分割 DNS 可以在网络管理员手中实现内部流量的最佳路由。）

当应用程序开发人员创建一个像 Dropbox 这样的程序并将其分发给不专门配置网络设备的最终用户时会发生什么？具体来说，当我在我的共享文件中放入一个 4GB 的文件，然后尝试在下一台计算机上访问时会发生什么？它是直接在机器之间传输，还是我必须等待它通过慢速 WAN 连接上传到云服务器，然后再等待它通过相同的慢速 WAN 连接下载？

对于一个简单的实现，它会被上传然后下载，使用 Dropbox 的服务器基础设施作为中介，它不在 NAT 后面。但是如果两台机器只能意识到他们在同一个网络上，那么他们可以直接更快地传输文件。因此，对于我们第一次不太天真的实现尝试，我们可能会询问操作系统机器具有哪些 IP(v4) 地址，然后与在同一 Dropbox 帐户上注册的其他机器进行比较。如果和我们在同一个范围内，直接传输文件即可。这可能在很多情况下都有效。但即便如此，仍然存在一个问题：NAT 之所以有效，是因为我们可以重用地址。那么如果 192.168.0.23 地址和 192.168.0. 42 注册在同一个 Dropbox 帐户上的地址实际上在不同的网络上（例如您的家庭网络和您的工作网络）？现在您必须故障恢复到使用 Dropbox 服务器基础设施进行调解。（最后，Dropbox 试图通过让每个 Dropbox 客户端在本地网络上广播以希望找到其他客户端来解决这个问题。但是这些广播不会跨越 NAT 后面可能有的任何路由器，这意味着这不是一个完整的解决方案,特别是在 CGN 的情况下。）

静态 IP

此外，由于第一次短缺（和 NAT 浪潮）发生在许多消费者连接并不总是处于连接状态（如拨号）时，ISP 可以通过仅在您实际连接时分配公共/外部 IP 地址来更好地利用它们的地址。这意味着当你连接时，你得到任何可用的地址，而不是总是得到相同的地址。这使得运行你自己的服务器变得更加困难，也使得开发对等应用程序变得更加困难，因为它们需要处理移动的对等点而不是固定地址。

混淆恶意流量来源

因为 NAT 将传出连接重写为好像它们来自 NAT 设备本身一样，所以所有行为，无论好坏，都被汇总到一个外部 IP 地址中。我还没有看到任何默认情况下记录每个传出连接的 NAT 设备。这意味着默认情况下，过去恶意流量的来源只能追溯到它经过的 NAT 设备。虽然可以配置更多的企业级或运营商级设备来记录每个传出连接，但我还没有看到任何消费者路由器这样做。我当然认为，看看 ISP 是否（以及持续多长时间）会在推出 CGN 时保留通过 CGN 建立的所有 TCP 和 UDP 连接的日志会很有趣。需要此类记录来处理滥用投诉和 DMCA 投诉。

有些人认为 NAT 增加了安全性。如果是这样，它是通过默默无闻来实现的。NAT 强制要求的传入流量的默认丢弃与具有状态防火墙相同。我的理解是，任何能够执行 NAT 所需的连接跟踪的硬件都应该能够运行有状态的防火墙，因此 NAT 并不真正值得在那里获得任何分数。

使用第二个连接的协议

FTP 和 SIP (VoIP) 等协议倾向于使用单独的连接来控制和实际数据内容。执行此操作的每个协议都必须在它经过的每个 NAT 设备上具有称为 ALG（应用层网关）的辅助软件，或者使用某种中介或打孔来解决该问题。根据我的经验，ALG 很少更新，并且至少是我处理过的涉及 SIP 的几个问题的原因。每当我听到有人报告说 VoIP 对他们不起作用，因为音频只能以一种方式工作时，我立即怀疑在某个地方，有一个 NAT 网关丢弃了 UDP 数据包，它无法弄清楚如何处理。

综上所述，NAT 往往会破解：

• TCP 或 UDP 的替代协议
• 点对点系统
• 访问托管在 NAT 后面的东西
• SIP 和 FTP 之类的东西。解决这个问题的 ALG 今天仍然会导致随机和奇怪的问题，特别是对于 SIP。

在核心，网络堆栈采用的分层方法相对简单和优雅。尝试向网络新手解释它，他们不可避免地认为他们的家庭网络可能是一个很好的、简单的网络，可以尝试理解。我已经在几个案例中看到，由于外部地址和内部地址之间的混淆，这导致了关于路由如何工作的一些非常有趣（过于复杂）的想法。

我怀疑如果没有 NAT，VoIP 将无处不在并与 PSTN 集成在一起，并且从手机或计算机拨打电话将是免费的（除了您已经付费的互联网）。毕竟，当你和我可以打开 64K VoIP 流并且它和 PSTN 一样好用时，我为什么还要为电话付费？今天，部署 VoIP 的首要问题似乎是通过 NAT 设备。

我怀疑如果我们拥有 NAT 破坏的端到端连接，我们通常不会意识到很多事情会简单得多。人们仍然通过电子邮件（或 Dropbox）自己的文件，因为如果两个客户端在 NAT 后面时需要调解器的核心问题。

Answer 3

我在其他答案中没有提到的 IPv4 耗尽的一个重要症状是，一些移动服务提供商几年前才开始使用 IPv6。有可能您已经使用 IPv6 多年，甚至不知道它。移动供应商是互联网游戏的新手，不一定有大量的预先存在的 IPv4 分配可供利用。它们还需要比电缆/DSL/光纤更多的地址，因为您的电话无法与您家庭的其他成员共享公共 IP 地址。

我的猜测是 IaaS 和 PaaS 提供商将是下一个，因为它们的增长与客户的物理地址无关。如果 IaaS 供应商很快以折扣价提供 IPv6，我不会感到惊讶。

Answer 4

前一段时间，主要的 RIR 用完了正常分配的空间。因此，对于大多数提供商而言，IPv4 地址的唯一来源是他们自己的库存和市场。

在某些情况下，最好使用专用的公共 IPv4 IP，但这并不是绝对必要的。还有一堆已分配但当前未在公共互联网上使用的公共 IPv4 地址（它们可能正在专用网络上使用，也可能根本没有使用）。最后，还有一些较旧的网络，其地址分配比它们需要的要松散得多。

三个最大的 RIR 现在允许在其成员之间以及向其他成员之间出售地址。因此，我们在拥有未使用地址或地址可以通过付费释放的组织与另一方面确实需要更多 IP 地址的组织之间存在市场。

难以预测的是每个价格点的供需情况，以及未来市场价格的走势。到目前为止，每个 IP 的价格似乎仍然低得惊人。

Answer 5

理想情况下，互联网上的每个主机都应该能够获得一个全局范围的 IP 地址，但是 IPv4 地址耗尽是真实的，事实上ARIN 的空闲池中的地址已经用完了。

每个人仍然可以正常访问互联网服务的原因是网络地址转换 (NAT) 技术允许多个主机共享公共 IP 地址。然而，这并非没有问题。

Answer 6

ISP 过去常常向公司提供 256 个 IP 地址块。现在，ISP 很吝啬，给你（一家公司）像 5。回到那天（2003 年），你家中的每台 PC 和连接的设备都有自己的互联网 IP 地址。现在，cable/DSN/Fios 路由器有一个 IP 地址，并向您家中的所有 PC 发出 10.0.0.x ip 地址。总结：ISP 过去常常浪费 IP 地址，现在他们不再浪费它们了。

Answer 7

您已经得到了很多很好的答案，但我想补充一些尚未提及的内容。

是的，IPv4 地址耗尽很糟糕，这取决于您如何衡量。一些公司仍然拥有大量的 IPv4 地址，但我们开始看到诸如运营商级 NAT 之类的变通方法。

但是当他们转向 IPv6 时，许多答案都是错误的。

以下是可以帮助解决 IPv4 地址短缺问题的技术列表。每个都有自己的优点和缺点。

• IPv6

  • 优点：标准化，可在大多数操作系统中使用。
  • 缺点：尽管经常有相反的声明，但存在严重的安全问题。早在 2005 年，美国 CERT 就警告过 IPv6 的全球寻址引起的安全问题。IPv6可以得到适当的保护，但考虑到消费者路由器的状态，它可能不会发生。
  • 缺点：迁移需要时间、金钱和专业知识。
  • 缺点：许多消费级设备存在严重缺陷。例如，许多 D-Link 路由器通过简单地转发所有流量而不提供任何防火墙来支持 IPv6 。

另一个考虑：即使 IPv6 在今天完全流行起来，由于人们将使用很长时间的旧设备（我仍然看到 Windows 2003 服务器和 Windows XP 工作站），淘汰 IPv4 还需要 20 年左右的时间偶尔！更不用说所有不支持 IPv6 的打印机、相机和物联网设备）。

• CGNat：
  • 优点：无需更改客户场所即可工作。
  • 缺点：只支持出站连接。
  • 缺点：可能不支持少数协议。

最终，CGNat 是不够的。也许 IPv6 会流行起来，但也很有可能我们最终会看到国家级 NAT 或类似的东西。

目前，作为一名顾问，我经常不得不向我的客户指出他们暴露在 IPv6 上（通常要感谢 Teredo）。下一个问题总是：“解决这个问题需要多少钱？” 然后“阻止它需要多少钱？如果我们关闭它，我们会失去什么？” 猜猜每次的决定是什么。

底线：回答您的问题，是的，IPv4 耗尽是真实的。我们将看到相当多的应对机制。IPv6 可能会也可能不会成为等式。

明确地说：我并不是说我喜欢这种情况。我希望 IPv6 取得成功（并且我希望看到对 IPv6 的一些改进）。我只是看看现在的情况。