直到最近,ISP 才能获得他们可以证明的所有 IPv4 地址。西方的大多数固网 ISP 为每个订户获得一个 IPv4 IP。
另一方面,移动提供商倾向于在 ISP 级别运行广泛的 NAT,我怀疑这是因为虽然为每个订户获取 IP 很容易,但很难获得足够的 IP 来拥有大型本地池“以防万一”大量订户聚集在给定区域。
然而,现在 ICANN 的 IPv4 IP 已经用完,大多数 RIR 甚至私人持有的股票都在减少。普通 IPv6 不是解决方案,因为大多数 Internet 服务尚不支持它。许多以前没有实施地址共享的 ISP 最近要么不得不这样做,要么正在考虑在可预见的未来不得不这样做。
因此需要某种形式的共享 IPv4 地址的机制。有一个数字,每个都有其优点和缺点,包括。
- 传统的 IPv4 NAT
- NAT64+DNS64(使用 DNS 将客户端指向基于有状态 ISP 的有状态 NAT64)
- DS-lite(封装数据包并将它们发送到基于 NAT44 的特殊状态 ISP)
- 464XLAT(客户端的大部分无状态* NAT46 与 ISP 端的有状态 NAT64 相结合)
- MAP-T(具有端口范围限制的有状态 NAT44 和客户端的大部分无状态 NAT46 与 ISP 端的大部分无状态 NAT64 相结合)
- MAP-E(在客户端具有端口范围限制的有状态 NAT44,然后封装数据包并通过隧道将它们发送到 ISP 的特殊路由/封装盒)。
(可能还有其他几个我没有关注的)
移动端的另一个问题是,一些移动网络正在耗尽私有 IPv4,或者更糟的是已经诉诸于“占用空间”。移动网络使用的大部分“占用空间”现在已分配用于互联网。我记得 T-Mobile USA 订户无法访问我的服务器时遇到问题,因为它的 IP 地址来自 5.0.0.0/8。
这导致许多移动网络(从 T-Mobile USA 开始)开始逐渐从传统的 IPv4 NAT 转向 NAT64/DNS64。在 Andriod 和 Windows Mobile 上实施了 464XLAT 以简化旧应用程序的转换。Apple 决定不实施 464XLAT,而是要求应用程序开发人员让他们的应用程序在 NAT64 环境中工作。
在这一点上,哪种地址共享机制将成为最流行的固网连接仍然是一个悬而未决的问题。
* IPv6 和 IPv4 之间的转换需要片段处理,因此即使 IP/端口处理是无状态的,整个转换过程也不是。