随着 IPv6 部署的(某种程度上)增加,IPv4 耗尽和浪费的整个问题似乎终于被抛在脑后了。
IPv6 的唯一目的是解决 IPv4 地址空间耗尽的问题。如果是这样的话,那么为什么管理机构要分配如此大量的 v6 地址呢?这完全是过度浪费。
这些分配背后是否有逻辑推理,还是更像是“我很富有,大家一起分享吧!”那类的东西?
例如,我最近为一台服务器分配了一个 /48 的 v6 地址块。对于我的单台服务器来说,这是一个惊人的 1,208,925,819,614,629,174,706,176 个地址。我怀疑内核是否允许我为一个接口分配这么多地址,我怀疑任何可用的 NIC 是否能支持其中的 1/10000 个。为什么 IPv6 地址要以这么大的块来分配?
答案1
主要原因是按照 RFC4862 进行无状态地址自动配置需要 /64 网络才能正常工作。此外,假设用户在安装时需要多个子网,并且路由任意倍数的 /64 很困难,因此自动倾向似乎是分配一个 /56,或者如果比较懒,分配一个 /48。
奇怪的是,我已经看到英国出现了节俭的迹象。 我的家庭办公室里有 v6已经有几年了,但最近更换了提供商。旧提供商自动给我一个 /56;新提供商给我一个 /64,但当我提到我正在划分子网时,新提供商很高兴地免费为我升级到 /56。
我的猜测是,一旦 v6 变得普遍,基本分配将稳定在 /64,而任何有充分理由的人都会获得 /56。
答案2
我认为路由较小的块会给 BGP 路由带来问题 - 块越小,所有不携带默认路由的路由器需要携带的路由就越多。
此外,虽然 IPV6 背后的驱动力是增加地址空间,但 IPv6 也有很多优点通过 IPv4。(更高效的路由、简化的网络配置、不再需要 NAT - 如果您认为这是一个优势,那么更好的安全性 - IPSec 已内置其中)
我的印象(仅此而已,尽管我处于 ISP 社区的边缘)是,收集 IPv4 地址毫无意义,因为这只会拖延不可避免的事情 - 互联网迟早需要 IPv6,没有必要通过进一步扩展 IPv4 来延长痛苦。那些需要投资升级基础设施的人无论如何都会遇到同样的困难 - 他们现在就遇到这些困难。
答案3
我觉得这个问题的答案已经足够了(有 240 万亿个/48
分配,这意味着地球上的每个人都可以获得 30,0000 个/48
分配,我们仍然不会出局)。但我要指出的是,2011 年的RFC 6177将针对 ISP 和 RIR 的建议从“为客户站点提供最少/48
”改为“为客户站点提供少于 的站点/64
,可能为/56
,但需判断”
引用 RFC:
虽然 /48 建议确实简化了终端站点的地址空间管理,但它也因浪费而受到广泛批评。
我不同意这一点。同样,有 240 万亿个/48
分配。人类灭绝将导致我们耗尽。/48
s 提供的地址空间比大多数站点所需的多得多,但这并不是真正浪费。它继续说道:
与此同时,为家庭站点分配一个单独的地址可能很有吸引力
/64
,因为与今天的 IPv4 实践相比,这已经是更多的地址空间。 然而,这排除了家庭站点将来也能扩展以支持多个子网的预期。 因此,强烈建议默认情况下,即使是主站点也应获得多个子网大小的空间。因此,本文档仍建议为主站点提供远多于单个的空间/64
,但不建议为每个主站点提供/48
两个空间。
....
地址管理的一个关键原则是终端站点始终能够获得合理数量的地址空间,用于实际和计划使用,并且时间范围以年为单位,而不是以月为单位。实际上,这意味着至少一个 /64,在大多数情况下要多得多。 必须避免的一种特殊情况是让终端站点被迫使用 IPv6 到 IPv6 网络地址转换或其他繁重的地址节省技术,因为它无法获得足够的地址空间。
RFC 还建议只在偶数半字节上分配,因此,,,,,/60
等。A为最终用户提供最多 16 个子网,这是可以的,但比 IPv4 上的 192.168.0.0/16 私有寻址允许的 255 个子网要少得多。不难想象家庭用户需要超过 16 个子网。大多数不会,但这并不难想象。/56
/52
/48
/60
- 与终端站点已经分配的现有前缀相比,为终端站点分配更长的前缀可能会增加终端站点的运营成本和复杂性,而对任何人都没有多大好处。
我看到一些 ISP 终于开始为家庭用户部署 IPv6,但他们只提供/64
静态前缀,而不提供静态前缀。这意味着家庭用户无法在 IPv6 上运行超过 1 个子网,这令人苦恼。家庭为大多数设备设置 1 个子网,为 Guest Wifi 设置 1 个子网,这种情况相当常见。我鼓励为 IoT 智能家居设备设置另一个子网,因为这些东西似乎有太多固件错误,你几乎不希望它们能够访问互联网,但肯定不希望它们访问你的 LAN。由于只有 /64,家庭用户必须选择:选择哪个子网支持 IPv6,并为其他子网使用 IPv4 + NAT或者使用 IPv6 - IPv6 NAT。
我觉得/128
在某些情况下,对于单个服务器来说,a 是合理的,而/64
在其他情况下,a 是合理的。但/64
对于站点来说,a 永远是不合理的,虽然 RFC6177 为 ISP 提供了更多的自由度,但我们可能还是应该坚持 2001 年的“始终为最终用户站点提供至少一个 /48”的规定RFC 3177无害。