我一直在读Debian 系统管理员手册，我在入门部分看到了这样一段话：
...请注意，NAT 仅与 IPv4 及其有限的地址空间相关；在 IPv6 中，地址的广泛可用性大大降低了 NAT 的实用性，因为所有“内部”地址都可以在 Internet 上直接路由（这并不意味着内部机器可以访问，因为中间防火墙可以过滤流量）。
这让我想到... IPv6 仍然有一个私有范围。请参阅：RFC4193。公司真的要为所有内部机器设置公有地址吗？IPv6 的预期工作方式就是这样吗？
答案1
IPv6 的预期工作方式就是这样的吗？
简而言之，是的。使用 IPv6 大幅增加地址空间的主要原因之一是摆脱 NAT 等权宜之计，使网络路由更简单。
但不要混淆公用地址和可公开访问的主机的概念。仍然会有一些“内部”服务器，即使它们有公用地址，也无法通过互联网访问。它们将受到防火墙的保护，就像 IPv4 一样。但决定今天的内部专用服务器明天是否需要向互联网开放特定服务也将变得容易得多。
公司真的要为所有内部机器设置公有地址吗？
我认为聪明人会的。但你可能已经注意到，这需要相当长一段时间。
答案2
我们在公司网络中为所有设备使用公共 IPv6 地址。
我们在网关上使用状态防火墙，其特点是：
- 允许所有 icmpv6
- 允许从内部网络向外建立新连接
- 允许建立从公共到内部的连接
任何公共流量（ICMP 和已建立的连接除外）都不应进入我们的网络。
到目前为止，我们没有遇到任何问题，此设置运行完美。
答案3
如果不需要外部连接，则可以使用私有网络。这就是在 IPv6 中也定义私有地址空间的原因。
NAT 是一种黑客技术，旨在延缓 IPv4 地址空间耗尽。NAT 会导致应用程序出现问题，而要让应用程序与 NAT 配合使用，需要更多黑客技术，而这些黑客技术与 IP 的原始设计相冲突。
因此，首选方法是像 Yarik 回答的那样，在网络边缘使用适当的状态防火墙。
答案4
IPv6 支持者认为 NAT 只是缓解 IPv4 地址枯竭的一种临时方法，因此 IPv6 不需要 NAT。
然而，NAT 除了可以防止地址耗尽之外，还具有其他一些优点。
- NAT 将您的内部寻址与互联网连接分离。
- 至少在 Linux 上，NAT 倾向于失败关闭。如果 iptables 规则加载失败，则具有私有 IP 的设备将无法连接到互联网，这种情况很快就会被发现并修复。另一方面，如果 IP 转发已打开但 iptables 规则未加载，数据包检查防火墙很容易失败打开。
- NAT 隐藏了哪台内部机器发出了请求。隐私扩展在一定程度上有助于实现这一点，但它们不会隐藏子网，而且它们是一项客户端功能，因此由客户端操作系统（而不是网络管理员）选择是否使用它们。
因此，我预计至少有些公司会选择像部署 IPv4 一样部署带有 NAT 的 v6。其他公司可能会站在 IPv6 支持者一边，选择防火墙，但不进行地址转换。
我强烈建议你（以及其他任何考虑使用 IPv6 实现 NAT 的人）在阅读 RFC 4864 以获得关于如何替代 NAT 的建议后，重新考虑
我已阅读过它，但我不认为它能够完全替代 NAT。
- NAT 将您的内部寻址与互联网连接分离。
IPv6 支持者对此提出的“解决方案”有三方面：并行运行多个地址、自动将动态地址从提供商分配给内部网络以及使用 ULA 提供长期本地地址。
并行运行不同生命周期的地址存在非永久地址最终无意中进入长期配置的风险。并行运行多个互联网地址的问题在于，客户端操作系统无法知道其数据包将从哪个互联网网关发出。
前缀委派已在单级场景中得到稳固实施，其中单个 CPE 路由器从 ISP 请求前缀并将其分配给一个或多个本地接口，但目前似乎还没有针对客户站点内多级委派的良好实现。
- 至少在 Linux 上，NAT 倾向于失败关闭。如果 iptables 规则加载失败，则具有私有 IP 的设备将无法连接到互联网，这种情况很快就会被发现并修复。另一方面，如果 IP 转发已打开但 iptables 规则未加载，数据包检查防火墙很容易失败打开。
IPv6 的支持者似乎没有对此提供任何答案。他们似乎只是假设事故不会发生。
- NAT 隐藏了哪台内部机器提出了请求。
隐私扩展在一定程度上对此有所帮助，但它们不会隐藏子网，并且它们是一项客户端功能，因此客户端操作系统（而不是网络管理员）可以选择是否使用它们。
有一项提议是将 /128 分配给各个机器，然后创建 IGP 条目来路由它们，但我不知道是否有人在实践中真正实施这一点。