AskOverflow.Dev

AskOverflow.Dev Logo AskOverflow.Dev Logo

AskOverflow.Dev Navigation

  • 主页
  • 系统&网络
  • Ubuntu
  • Unix
  • DBA
  • Computer
  • Coding
  • LangChain

Mobile menu

Close
  • 主页
  • 系统&网络
    • 最新
    • 热门
    • 标签
  • Ubuntu
    • 最新
    • 热门
    • 标签
  • Unix
    • 最新
    • 标签
  • DBA
    • 最新
    • 标签
  • Computer
    • 最新
    • 标签
  • Coding
    • 最新
    • 标签
主页 / server / 问题 / 588561
Accepted
jduncanator
jduncanator
Asked: 2014-04-13 00:16:38 +0800 CST2014-04-13 00:16:38 +0800 CST 2014-04-13 00:16:38 +0800 CST

为什么 ARIN(等)分配如此大的 IPv6 地址块?

  • 772

随着 IPv6 的部署(在某种程度上)增加,IPv4 耗尽和浪费的整个问题似乎终于被我们抛在了脑后。

IPv6 的唯一目的是解决 IPv4 地址空间耗尽的问题。如果是这样的话,那么为什么管理组织要分配如此大的 v6 地址块,这纯粹是过度杀伤和明显的浪费?

分配背后是否有逻辑推理,或者更像是“我很富有,让我们一起分享它们!” 那类的东西?

例如,我最近被分配了一个带有单个服务器的 /48 块 v6 地址。对于我的单个服务器来说,这是一个惊人的 1,208,925,819,614,629,174,706,176 个地址。我怀疑内核是否会让我将这么多地址分配给一个接口,我怀疑任何可用的 NIC 是否会支持其中的 10000 个地址。为什么 IPv6 地址以如此大的块分发?

ipv6
  • 3 3 个回答
  • 3318 Views

3 个回答

  • Voted
  1. Best Answer
    MadHatter
    2014-04-13T00:47:35+08:002014-04-13T00:47:35+08:00

    主要原因是根据 RFC4862 的无状态地址自动配置需要 /64 网络才能正常工作。再加上一个假设,即在安装时需要多个子网以及路由任意倍数的 /64 的难度,并且自动趋势似乎是分配 /56,或者如果懒惰,分配 /48。

    奇怪的是,我已经在英国看到了吝啬的最初迹象。 现在,我已经在我的家庭办公室安装了 v6 几年,但最近更换了供应商。旧的自动给了我/56;新的给了我一个/64,但是当我提到我正在划分子网时,我很高兴地将我免费升级到/56。

    我的猜测是,一旦 v6 变得普遍,基本分配将稳定在 /64,任何有正当理由的人都会获得 /56。

    • 19
  2. davidgo
    2014-04-13T00:22:40+08:002014-04-13T00:22:40+08:00

    我想路由更小的块会给 BGP 路由带来问题 - 块越小,所有不携带默认路由的路由器需要携带的路由就越多。

    此外,虽然 IPV6 背后的驱动力是增加地址空间,但与 IPv4 相比,IPv6 具有很多优势。(更高效的路由,简化的网络配置,不再需要 NAT - 如果您称其为优势,则更好的安全性 - IPSec 已融入其中)

    我的印象(仅此而已,尽管我处于 ISP 社区的边缘)是没有必要搜索 IPv4 地址,因为它只会延迟不可避免的情况——互联网迟早需要 IPv6 ,没有必要通过进一步扩展 IPv4 来延长痛苦。那些需要投资升级基础设施的人无论如何都会碰上同样的墙——他们现在还不如碰上。

    • 6
  3. bobpaul
    2018-10-05T18:33:43+08:002018-10-05T18:33:43+08:00

    我觉得这通常得到了充分的回答(有 240 万亿个/48分配,这意味着地球上每个人都可以获得 30,0000 个/48分配,我们仍然不会被淘汰)。但我会注意到 2011 年的RFC 6177将针对 ISP 和 RIR 的建议从“为客户站点提供/48至少/64/56

    引用 RFC:

    虽然 /48 建议确实简化了终端站点的地址空间管理,但它也被广泛批评为浪费。

    我不同意这一点。同样,有 240 万亿的/48分配。人类灭绝将导致我们耗尽。/48s 提供的地址空间比大多数站点所需的要多,但这并不是真正的浪费。它继续:

    同时,给家庭站点一个单一/64的 . 但是,这排除了即使家庭站点也会增长以支持多个子网的期望。 因此,在默认情况下,强烈建议即使是家庭站点也被赋予多个子网空间。因此,本文档仍然建议为主站点提供比单个更多的/64,但不建议为每个主站点提供/48任何一个。

    ……

    地址管理的一个关键原则是终端站点始终能够获得合理数量的地址空间,以供其实际和计划使用,并且在以年而不是几个月为单位指定的时间范围内。在实践中,这意味着至少 1 /64,并且在大多数情况下明显更多。 必须避免的一种特殊情况是让终端站点感觉被迫使用 IPv6 到 IPv6 网络地址转换或其他繁重的地址保存技术,因为它无法获得足够的地址空间。

    RFC 还建议仅在偶数半字节上拆分分配,因此/60, /56, /52,/48等。A/60为最终用户提供最多 16 个子网,这没问题,但比 255 个子网少 192.168.0.0/16 IPv4 上的私有寻址允许. 不难想象家庭用户需要超过 16 个子网。大多数不会,但不难想象。

    • 与终端站点已经分配给它的现有前缀相比,为终端站点分配更长的前缀可能会增加终端站点的运营成本和复杂性,而对任何人都没有足够的好处。

    我已经看到一些 ISP 终于开始为家庭用户部署 IPv6,但他们只提供/64而不提供静态前缀。这意味着家庭用户不能在 IPv6 上运行超过 1 个子网,这令人痛苦。对于家庭来说,大多数设备都有 1 个子网,而访客 Wifi 有 1 个子网是很常见的。我鼓励物联网智能家居设备的另一个子网,因为这些东西似乎有很多固件错误,你几乎不希望它们能够访问互联网,但肯定不希望它们访问你的 LAN。如果只有 /64,家庭用户将不得不:选择支持 IPv6 的子网并为其他子网使用 IPv4 + NAT或使用 IPv6 - IPv6 NAT。

    我觉得 a/128在某些情况下对于单个服务器是合理的,而/64在其他情况下是合理的。但是对于站点来说,a从来都不是合理的,虽然 RFC6177 为 ISP 提供了更多的回旋余地,但我们可能会坚持使用 2001 年RFC 3177/64中的“始终为最终用户站点提供至少一个 /48”而不会造成伤害。

    • 2

相关问题

  • IPv6 有哪些好的 IP 地址管理解决方案?[关闭]

  • 连接到 NAT 后启用 Teredo 的服务器

  • IPv4管理员的IPv6介绍[关闭]

  • 什么是支持 IPv6 胶水的又好又便宜的注册商?

  • 使用多少 IP V6 寻址?

Sidebar

Stats

  • 问题 205573
  • 回答 270741
  • 最佳答案 135370
  • 用户 68524
  • 热门
  • 回答
  • Marko Smith

    新安装后 postgres 的默认超级用户用户名/密码是什么?

    • 5 个回答
  • Marko Smith

    SFTP 使用什么端口?

    • 6 个回答
  • Marko Smith

    命令行列出 Windows Active Directory 组中的用户?

    • 9 个回答
  • Marko Smith

    什么是 Pem 文件,它与其他 OpenSSL 生成的密钥文件格式有何不同?

    • 3 个回答
  • Marko Smith

    如何确定bash变量是否为空?

    • 15 个回答
  • Martin Hope
    Tom Feiner 如何按大小对 du -h 输出进行排序 2009-02-26 05:42:42 +0800 CST
  • Martin Hope
    Noah Goodrich 什么是 Pem 文件,它与其他 OpenSSL 生成的密钥文件格式有何不同? 2009-05-19 18:24:42 +0800 CST
  • Martin Hope
    Brent 如何确定bash变量是否为空? 2009-05-13 09:54:48 +0800 CST
  • Martin Hope
    cletus 您如何找到在 Windows 中打开文件的进程? 2009-05-01 16:47:16 +0800 CST

热门标签

linux nginx windows networking ubuntu domain-name-system amazon-web-services active-directory apache-2.4 ssh

Explore

  • 主页
  • 问题
    • 最新
    • 热门
  • 标签
  • 帮助

Footer

AskOverflow.Dev

关于我们

  • 关于我们
  • 联系我们

Legal Stuff

  • Privacy Policy

Language

  • Pt
  • Server
  • Unix

© 2023 AskOverflow.DEV All Rights Reserve