IAB/IESG关于向站点分配IPv6地址的建议

RFC3177：IAB/IESG Recommendations on IPv6 Address Allocations to Sites，September 2001
本备忘录的状态

这份备忘录为互联网社区提供了信息。它没有指定任何类型的互联网标准。这份备忘录的分发是无限的。
版权声明

版权所有（C）互联网协会（2001）。保留所有权利。
摘要

本文档为寻址注册表（APNIC、ARIN和RIPE-NCC）提供了关于向终端站点分配IPv6地址块的策略建议。特别是，它建议在一般情况下分配/48，当知道只需要一个子网时分配/64，当绝对知道只有一个设备正在连接时分配/128。
最初的建议是在2000年9月1日邮寄给登记处的IAB/IESG声明中提出的。本文档对原始建议进行了改进，并将其记录在案以供历史记录。
1、导言

IETF和RIR专家就IPv6地址分配策略进行了多次讨论。这份备忘录解决了互联网中公共和私有拓扑之间的边界问题，即ISP应该为家庭、小型和大型企业、移动网络和临时客户分配多少地址空间。
本文档不涉及公共拓扑中的其他边界问题，即RIR和LIR之间的边界。
本文件由IPv6理事会、IAB和IESG制定，是IAB和IER向RIR提出的建议。
2、背景

适用于解决分配问题的技术原则寻求在健康的保护实践和智慧与一定的易得性之间取得平衡。一方面，在管理潜在有限的资源时，必须明智地节约，以防止在预期的寿命内耗尽。另一方面，IPv6地址空间绝不是像IPv4地址空间那样有限的资源，在已经受到其他因素抑制的市场中，不必要的保守主义会起到抑制作用。因此，从市场发展的角度来看，我们希望用户或ISP能够很容易地获得他们真正需要的IPv6地址，而不会立即重新编号或扩展效率低下。
IETF不对业务问题或关系发表评论。然而，总的来说，我们观察到技术授权政策会对业务产生强烈的影响。地址委托计划的一个强烈要求是，它不能以业务关系或模式为基础，也不能过度偏向业务关系或模型。

目前定义的IPv6地址由64位“网络号”和64位“主机号”组成。造成这种情况的技术原因有几个。1993年达成的IPv6要求包括一项能够解决大约2^40个网络和2^50个主机的计划；64/64分割有效地实现了这一点。主机地址分配中使用的过程，例如路由器向主机通告网络前缀[RFC2462]，这反过来又在主机部分放置一个本地唯一的号码，取决于这种分割。必须假设子网编号来自网络部分。这并不是要排除路由协议，如IS-IS Level-1（区域内）路由，它路由单个主机地址，但表示在该区域之外的世界中可能不依赖它。64位主机字段也可以与EUI-64一起用于扁平、唯一分配的空间，因此它可能不会被全局视为子网资源。那些关注与全局唯一标识符存在相关的隐私问题的人可能会注意到，64位的字段足够大，可以为自配置的终端系统指示符保持出色的随机数绘制属性。IPv6地址的这个64位主机部分的替代构造记录在[RFC3041]中。
虽然IETF也付出了巨大的努力来尽量减少网络重新编号的影响，但IPv6网络的重新编号既不是看不见的，也不是完全无痛的。因此，重新编号应被视为一个可以容忍的事件，但在合理可行的情况下应避免。
在[RFC2374]和[RFC2450]中，IETF的IPNG工作组建议，给可以递归子网化的单个边缘网络的地址块是48位前缀。这为每个这样的网络提供了2^16个子网号用于路由，并在每个网络中提供了大量唯一的主机号。对于大多数企业来说，这被认为足够大，并为将地址块委托给聚合实体留出了足够的空间。
然而，并非所有边缘网络都可能递归地进行子网划分；例如，家庭中的一台个人电脑或移动蜂窝网络中的一部电话可能会也可能不会连接到子网本地网络。因此，当一个网络号码被委托给一个不需要子网的地方时，ISP可以提供一个64位的前缀，这可能是在同一ISP路由器的拨入连接之间共享的。然而，做出这一决定可能是因为客观上不乏/48，并且预计个人家庭网络将成为常态。事实上，人们普遍预计，所有IPv6用户，无论是家庭（家庭）、移动设备（车辆或个人）还是任何规模的企业，最终都将拥有多个始终在线的主机、至少一个子网，这些子网有可能进行额外的子网划分，因此具有一些内部路由能力。换句话说，用户分配单元并不总是主机；它总是一个潜在的网站。这份备忘录要解决的问题是，应该向这些网站委派多少地址空间。
3、地址委派的建议

IESG和IAB建议公共和私有拓扑之间的边界分配遵循这些一般规则：
在一般情况下使用/48，除了非常大的订阅者。
当已知设计只需要一个子网时使用/64。
当绝对知道只有一个设备正在连接时使用/128。

我们特别建议：
*家庭网络用户，通过按需或始终在线的连接进行连接，应收到/48。
*小型和大型企业应获得/48。
*非常大的用户可能会收到/47或稍短的前缀，或多个/48。
*移动网络，如带有额外网络接口（如蓝牙或802.11b）的车辆或手机，应接收静态/64前缀，以允许通过一个子网连接多个设备。
*从酒店房间拨号的单台PC，不需要额外的子网，可以接收其/128 IPv6地址作为/64前缀的一部分，用于PPP式连接。
请注意，如果预计未来的增长，不给出/48似乎没有什么好处。在下文中，我们给出了统一使用/48的论点，然后证明它与对整个IPv6地址空间的负责任管理完全兼容。
固定边界的论点是：
*只有拥有独立于提供商的边界，我们才能保证ISP的变更不需要昂贵的内部重组或子网整合。

*在直接将站点从一个前缀重新编号到另一个前缀的过程中，如果前缀的长度不同（当然取决于站点的大小和复杂性），整个过程，包括两个前缀的并行运行，将变得非常复杂。
*IPv6站点的多归属有各种可能的方法，包括已经用于IPv4多归属的技术。主要的未决问题是找到大规模扩展的解决方案，而不会过度破坏路线聚合和/或最佳路线选择。在这方面还有很多工作要做，但似乎有可能在实践中部署几种方法，每种方法都有自己的优缺点。一些（但不是全部）使用固定前缀边界会更好。（下文将更详细地讨论多归位。）
*允许用户网络的轻松增长，而不需要回到ISP那里获得更多空间（除了相对较少的用户，/48是不够的）。
*消除ISP和注册机构判断网站对地址空间需求的负担，除非网站请求的空间超过a/48。这有几个优点：
**ISP能够保持对其客户的网络架构和增长计划的详细了解可能变得不那么重要，
**ISP和注册机构可以减少在评估地址消耗率上花费的精力，
**通过降低跟踪和评估的紧迫性，可以使注册表操作更高效或更有针对性地址空间将不再是客户的宝贵资源，从而消除了用户安装v6/v6 NAT的主要动机，这将阻碍IPv6恢复地址透明度。
*允许站点维护一个覆盖所有前缀的反向DNS区域。
*如果并且只有当一个站点可以在其每个前缀下使用相同的子网结构时，它才能使用相同的区域文件进行所有前缀的地址到名称映射。而且，使用[RFC2874]的约定，它可以将反向映射数据滚动到“转发”（名称键控）区域。
固定边界为/48的具体优点包括：
*保留改装GSE（Global, Site and End-System Designator，全局、站点和终端系统指示符，也称为“8+8”）提案的技术选项，以分离定位器和标识符，该提案假设全局和站点寻址之间有一个固定的边界，即/48。尽管GSE技术在几年前被推迟，但它仍然有强有力的支持者。此外，IRTF命名空间研究小组正在积极研究与GSE密切相关的主题。未来，GSE或其衍生物仍有可能与IPv6一起使用。
*由于站点本地前缀是fec0::/48，因此/48的全局站点前缀将允许站点在SLA字段中轻松维护全局拓扑和站点本地拓扑之间的简单（身份）映射。
*同样，如果6to4提案得到广泛部署，如果本机前缀为/48，则从6to4前缀（构造为/48）迁移到本机IPv6前缀将得到简化。
4、地址空间的保护

问题自然会出现，给每个用户一个/48是否代表了地址空间的浪费。客观分析表明事实并非如此。001全球单播地址前缀下的/48前缀包含45个可变位。也就是说，可用前缀的数量是2的45次方，约为35万亿（35184372088832）。

更确切地说，
[RFC1715]根据各种网络中地址空间分配的经验定义了“H率”。H率在0和0.3之间变化，值越大表示分配越密集、效率越高。经验表明，当H率大于0.25时，问题开始出现。H率为0.25时，45位地址空间将有1780亿（178亿）个标识符。 H = log10(17810^9) / 45 = 0.25
这意味着，在问题开始出现之前，我们对在该方案下分配1780亿个/48前缀的前景感到满意。要了解这个数字有多大，必须将1780亿到100亿进行比较，这是2050年地球上的预计人口（见http://www.census.gov/ipc/www/world.html). 如果ISP在RIR的指导下谨慎分配/48，并且IETF不提出进一步减少剩余45个可变比特的新建议，除非出现强制要求，否则这些数字没有理由令人担忧。
*基于IPv4和其他几个地址空间的经验，以及互联网极其雄心勃勃的扩展目标，即每人80位地址空间，我们对这一分析的有效性充满信心。即便如此，IETF敏锐地意识到低估需求的历史，保留了85%以上的地址空间（即，不在001全球单播地址前缀下的大部分空间）。因此，如果有一天分析结果是错误的，我们的继任者仍然可以选择对剩余的85%实施更严格的分配政策。然而，我们必须强调，供应商不应该在软件或硬件中对这里讨论的任何边界进行编码。在这种假设下，如果我们必须使用剩余的85%的地址空间，这样的迁移可能不会没有痛苦，但它应该比部署新版本的IP破坏性小得多。
总之，我们认为，尽管谨慎管理IPv6地址空间至关重要，但这与任何规模的IPv6站点统一前缀大小的便利性和简单性完全兼容。这些数字表明，似乎不存在空间不足、为早期客户提供不公平的空间或重新陷入地址保护和路由聚合相互损害的过度受限的IPv4情况的客观风险。
5、多归属问题

在多归属网络领域，IPv4中使用的技术都可以应用，但它们存在已知的扩展问题。具体来说，如果多个ISP通告相同的前缀，则路由信息将随着多归属站点数量的增加而增长。为了在IPv6方面超越这一点，我们目前只有初步的建议，IETF IPNG和Multi6工作组正在积极开展工作。在当前或新的提案得到更充分的发展之前，已知在IPv4中工作的现有技术将继续在IPv6中使用。
理想的多归属方案的关键特征包括（至少）它为全球任何多归属网络提供路由连接，节省地址空间，通过网络的任何提供商产生高质量的路由，使多归属网络能够连接到多个ISP，不会无意中使路由偏向使用这些网络的任何适当子集，不会损坏路由聚合，并可扩展到大量多归属网络。
正在考虑的一类解决方案相当于每个站点两个（或多个）前缀的永久并行运行。在没有固定前缀边界的情况下，这样的站点可能需要有多个不同的内部子网编号策略（每个前缀长度对应一个），或者如果它只想要一个，则被迫使用它从任何ISP收到的最长前缀定义的最严格的子网编号。在这种方法中，多归属网络将具有来自其每个上游提供商的地址块。每个主机要么从一组上游提供商中选择一个地址，要么从每个上游提供商中为每个主机选择一个位置。第一种情况本质上是[RFC2260]的变体，具有已知的缩放限制。

在第二种情况下（每个主机有多个地址），如果两个多归属网络通信，分别有M个和N个上游提供商，则发起连接的网络将从NM个潜在地址对中选择一个地址对进行连接，这样做将选择提供商，从而选择连接生命周期内的适用路由。假设每条路径将具有不同的可用比特率、丢失率和延迟，如果两台主机都不拥有任何路由或度量信息，则发起主机只有1/（MN）的概率选择最佳地址对。IETF正在进行优于随机地址选择的工作，但尚未完成。
现有的IPv4互联网向我们表明，一个独立于所有上游提供商并在全球范围内通告的网络前缀允许路由系统在适用的策略内选择一个合理的好路径。目前的路由策略不是QoS策略，而是可达性策略，这意味着它们不一定会选择最佳的延迟、比特率或丢失率，但路由将是使用的度量中最好的。因此，人们可能会得出结论，除了扩展问题外，这也适用于IPv6网络。
6、安全注意事项

本文档不涉及任何安全问题。
7、致谢

本文档源自IETF IPv6理事会，并得到了IAB和IESG的大量投入。构成本文件基础的原始文本由Fred Baker和Brian Carpenter提供。Allison Mankin和Thomas Narten将原始贡献合并为一份文件，Alain Durand在文件的最后阶段对其进行了编辑。
8、参考文献

[RFC1715] Huitema, C., “The H Ratio for Address Assignment Efficiency”, RFC 1715, November 1994.
[RFC2026] Bradner, S., “The Internet Standards Process — Revision 3”, BCP 9, RFC 2026, October 1996.
[RFC2260] Bates, T. and Y. Rekhter, “Scalable Support for Multi-homed Multi-provider Connectivity”, RFC 2260, January 1998.
[RFC2374] Hinden, R., O’Dell, M. and S. Deering, “An IPv6 Aggregatable Global Unicast Address Format”, RFC 2374, July 1998.
[RFC2450] Hinden, R., “Proposed TLA and NLA Assignment Rule”, RFC 2450, December 1998.
[RFC2462] Thompson, S. and T. Narten, “IPv6 Stateless Address Autoconfiguration”, RFC 2462, December 1998.
[RFC2874] Crawford, M. and C. Huitema, “DNS Extensions to Support IPv6 Address Aggregation and Renumbering”, RFC 2874, July 2000.
[RFC3041] Narten, T. and R. Draves, “Privacy Extensions for Stateless Address Autoconfiguration in IPv6”, RFC 3041, January 2001.
[MobIPv6] Johnson, D. and C. Perkins, “Mobility Support in IPv6”, Work in Progress.
9、完整版权声明

版权所有（C）互联网协会（2001）。保留所有权利。
本文件及其翻译可复制并提供给他人，对其进行评论或以其他方式解释或协助其实施的衍生作品可全部或部分制作、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权声明或对互联网协会或其他互联网组织的引用，除非是为了制定互联网标准而需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或者需要将其翻译成英语以外的语言。
上述授予的有限权限是永久性的，互联网协会或其继承人或受让人不会撤销。
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于使用本文件中的信息不会侵犯任何权利或对适销性或特定用途适用性的任何暗示保证。
致谢

RFC编辑器功能的资金目前由互联网协会提供。