多年来，媒体一直在报道现在可用的 IPv4 地址非常少的问题。但另一方面，我使用的服务器托管公司很乐意以少量费用提供公共 IPv4 地址。而且我的私人互联网连接附带一个公共 IPv4 地址。
这怎么可能？问题真如媒体所报道的那样严重吗？
答案1
这非常糟糕。下面是我亲身体验过的消费者 ISP 为应对 IPv4 地址短缺所采取的一些措施：
- 在城市之间反复调整 IPv4 地址块会导致客户出现短暂停电和连接重置。
- 缩短DHCP租赁时间从几天到几分钟。
- 允许用户选择是否网络地址转换 (NAT)无论是否在客户端设备 (CPE) 上，都应追溯性地为所有人打开它。
- 为已经利用机会退出 NAT 的客户在 CPE 上启用 NAT。
- 降低同时活跃用户数上限媒体访问控制 (MAC) 地址由 CPE 强制执行。
- 部署运营商级 NAT (CGN)对于那些在注册服务时拥有真实IP地址的客户。
所有这些都降低了 ISP 向其客户销售的产品的质量。他们这样做的唯一合理解释是 IPv4 地址短缺。
IPv4 地址短缺导致地址空间碎片化，这存在多个缺点：
- 管理开销不仅浪费时间和金钱，而且容易出错并导致停机。
- 大量使用内容寻址存储器 (CAM)几年前，骨干路由器的容量导致了多个 ISP 发生严重中断当它超越了特定流行路由器型号的限制时。
如果没有 NAT，我们今天就无法利用 37 亿个可路由 IPv4 地址。但 NAT 是一种脆弱的解决方案，它会导致连接可靠性降低，并且会出现难以调试的问题。NAT 层数越多，情况就越糟。二十年的艰苦努力使得单层 NAT 基本可以发挥作用，但我们已经越过了单层 NAT 足以解决 IPv4 地址短缺问题的临界点。
答案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时，情况并非如此。然后他们必须查看并支持您想要使用的第四层协议。目前，这实际上意味着您只能使用 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 访问您的 Web 服务器。您应该使用哪个端口取决于您是在 NAT 内部还是外部。如果您在 NAT 外部，并使用 192.168.0.23 地址，您将无法到达预期的位置。如果您在 NAT 内部，并使用外部地址 35.72.216.228，您可能到达你想去的地方，如果你的 NAT 实现是支持发夹结构的高级 NAT，但处理您请求的 Web 服务器会将该请求视为来自您的 NAT 设备。这意味着所有流量都必须经过 NAT 设备，即使 NAT 后面的网络中存在更短的路径，也意味着 Web 服务器上的日志变得没那么有用，因为它们都将 NAT 设备列为连接的来源。如果您的 NAT 实现不支持发夹，那么您将无法到达您期望去的地方。
而一旦使用 DNS，这个问题就会变得更糟。突然间，如果您希望托管在 NAT 后面的某些东西一切正常，您将需要根据询问者（又称水平分割 DNS，如果我没记错的话）对托管在 NAT 内的服务的地址给出不同的答案。真恶心。
这一切都假设您有一位精通端口转发、发夹式 NAT 和水平分割 DNS 的人。那么最终用户呢？当他们购买消费级路由器和一些 IP 安全摄像头并希望它们“正常工作”时，他们正确设置这一切的可能性有多大？
这让我想到：
优化流量路由，主机知道其真实地址
正如我们所见，即使使用高级发夹式 NAT，流量也并不总是通过最佳路径流动。即使是知识渊博的管理员设置了服务器并拥有发夹式 NAT 的情况下也是如此。（当然，在网络管理员的手中，水平分割 DNS 可以实现内部流量的最佳路由。）
如果应用程序开发人员创建了 Dropbox 之类的程序，并将其分发给不擅长配置网络设备的最终用户，会发生什么情况？具体来说，如果我将一个 4GB 的文件放入共享文件中，然后尝试在下一台计算机上访问，会发生什么情况？它是直接在机器之间传输，还是我必须等待它通过慢速 WAN 连接上传到云服务器，然后再等待它通过相同的慢速 WAN 连接下载？
对于一个简单的实现，它将被上传然后下载，使用不在 NAT 后面的 Dropbox 服务器基础设施作为中介。但如果两台机器能够意识到它们在同一个网络上，那么它们就可以直接传输文件，速度要快得多。因此，对于我们第一次不太简单的实现尝试，我们可能会询问操作系统机器的 IP（v4）地址是什么，然后将其与在同一个 Dropbox 帐户上注册的其他机器进行检查。如果它与我们在同一范围内，则直接传输文件。这可能在很多情况下有效。但即便如此，也存在一个问题：NAT 之所以有效，只是因为我们可以重复使用地址。那么，如果在同一个 Dropbox 帐户上注册的 192.168.0.23 地址和 192.168.0.42 地址实际上位于不同的网络上（例如您的家庭网络和工作网络）怎么办？现在您必须恢复使用 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 后面时需要一个中介。
答案3
我在其他答案中没有看到提到的 IPv4 耗尽的一个重要症状是一些移动服务提供商几年前就开始只使用 IPv6。您可能已经使用 IPv6 多年了，但甚至都不知道。移动提供商是互联网游戏的新手，不一定有大量现有的 IPv4 分配可供使用。它们还需要比有线/DSL/光纤更多的地址，因为您的手机不能与家庭其他成员共享公共 IP 地址。
我猜 IaaS 和 PaaS 提供商将是下一个，因为它们的增长与客户的物理地址无关。我不会惊讶于 IaaS 提供商很快以折扣价提供仅限 IPv6 的服务。
答案4
理想情况下，互联网上的每个主机都应该能够获得一个全球范围的 IP 地址，但 IPv4 地址枯竭是真实存在的，事实上ARIN 的空闲地址池已经用完了。
大家之所以能顺利访问互联网服务，是因为网络地址转换 (NAT) 技术允许多台主机共享公共 IP 地址。然而，这并非没有问题。