您确实可以通过 LIR 从本地 RIR 请求独立提供商 (PI) 分配。使用 BGP 路由 IPv6 地址空间块的方式与 IPv4 地址空间块相同。块只是有点大:-)

对于 IPv4，小于 /24（因此是 /25 或更长前缀）的块通常不会被 ISP 路由。在 IPv6 中，如今的常见限制似乎是 /48。

每个 RIR 都有自己的政策，因此您必须查看您所在地区的 RIR 以了解详细信息。如果您碰巧在 RIPE NCC 服务区域，我可以回答您可能遇到的任何问题。

这似乎是许多企业正在尝试的方法，但 IPv6 设计背后的目标是防止除对等规模的公司（例如 Google）之外的所有公司获取独立于提供商的块以减少全局路由表的大小.

IPv6 主机需要能够处理每个接口的多个地址，其目的是通过让企业的出口路由器每个通过其上行链路和路由器通告可用的块（通常是 /48 或 /56）来实现多宿主工作在企业内部将全局前缀（通常通过 DHCPv6 读取）附加到与前缀无关的子网号。迁移从路由器广告中获取信息的主机可以逐步完成，无需管理员干预。

不幸的是，在实际部署中，该模型因在AAAA记录上采用DNS 记录（仅存储文字 IP 地址）而受到阻碍，该A6记录允许指定地址组件（例如，企业范围的 48 位前缀部分和 80-位主机部分），可以独立管理和更新；通过早期路由器软件版本中基于前缀的脆弱地址支持，多地址模型似乎不太可能比 PI+BGP 模型获得任何牵引力。早期的 RFC 建议不要将 PI 块分配给非运输组织，但至少从 RFC6177 开始，该建议似乎已被撤回。

IPv6 支持者的最初想法是组织将并行运行多个地址块以允许多宿主。

然而在实践中这是有问题的，原因有几个。

1. 在这种设置中，当终端主机选择源 IP 时，它本质上是在做出路由决策，但终端主机在做出路由决策方面处于劣势。
2. 添加或删除 IP 前缀通常很困难，因为 IP 存储在许多地方。有人提议对 DNS 进行扩展以帮助解决此问题，但它们为 DNS 系统增加了复杂性和脆弱性，最终被视为“历史性”而放弃。
3. 当与一个提供商的连接意外中断时，它并没有真正处理这种情况。
4. 路由器需要根据源 IP 做出路由决定。有些路由器可以做到这一点，但这是一项高级功能，而不是普通路由。

最终似乎意识到组织不会忍受那些狗屎的权力，如果他们想看到 IPv6 被采用，他们必须以类似于 IPv4 PI 空间的条件提供 IPv6 PI 空间。

实际上，RIR 之间的确切策略略有不同，但通常，如果您可以证明多户的意图，您应该能够轻松获得一块 PI 空间。

从长远来看，这将如何发挥作用将会很有趣。由于强烈反对 IPv6 NAT，我可以看到随着中型企业从 natted v4 转向独立于供应商的 IPv6，路由表的大小会呈爆炸式增长。