Network Working Group IAB
Request for Comments: 3177 IESG
Category: Informational September 2001
Network Working Group IAB
Request for Comments: 3177 IESG
Category: Informational September 2001
IAB/IESG Recommendations on IPv6 Address Allocations to Sites
IAB/IESG关于向站点分配IPv6地址的建议
Status of this Memo
本备忘录的状况
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2001). All Rights Reserved.
版权所有（C）互联网协会（2001年）。版权所有。
Abstract
摘要
This document provides recommendations to the addressing registries (APNIC, ARIN and RIPE-NCC) on policies for assigning IPv6 address blocks to end sites. In particular, it recommends the assignment of /48 in the general case, /64 when it is known that one and only one subnet is needed and /128 when it is absolutely known that one and only one device is connecting.
本文件就向终端站点分配IPv6地址块的策略向寻址注册中心（APNIC、ARIN和RIME-NCC）提供建议。特别是，它建议在一般情况下分配/48，当知道只需要一个子网时分配/64，当绝对知道只需要一个设备连接时分配/128。
The original recommendations were made in an IAB/IESG statement mailed to the registries on September 1, 2000. This document refines the original recommendation and documents it for the historical record.
最初的建议是在2000年9月1日邮寄给注册处的IAB/IESG声明中提出的。本文件对原始建议进行了细化，并将其记录为历史记录。
There have been many discussions between IETF and RIR experts on the topic of IPv6 address allocation policy. This memo addresses the issue of the boundary in between the public and the private topology in the Internet, that is, how much address space should an ISP allocate to homes, small and large enterprises, mobile networks and transient customers.
IETF和RIR专家就IPv6地址分配策略进行了多次讨论。本备忘录讨论了互联网中公共和私有拓扑之间的边界问题，即ISP应为家庭、小型和大型企业、移动网络和临时客户分配多少地址空间。
This document does not address the issue of the other boundaries in the public topology, that is, between the RIRs and the LIRs.
本文件不涉及公共拓扑中的其他边界问题，即RIR和LIR之间的边界问题。
This document was developed by the IPv6 Directorate, IAB and IESG, and is a recommendation from the IAB and IESG to the RIRs.
本文件由IPv6董事会、IAB和IESG编制，是IAB和IESG向RIRs提出的建议。
The technical principles that apply to address allocation seek to balance healthy conservation practices and wisdom with a certain ease of access. On one hand, when managing a potentially limited resource, one must conserve wisely to prevent exhaustion within an expected lifetime. On the other hand, the IPv6 address space is in no sense as limited a resource as the IPv4 address space, and unwarranted conservatism acts as a disincentive in a marketplace already dampened by other factors. So from a market development perspective, we would like to see it be very easy for a user or an ISP to obtain as many IPv6 addresses as they really need without a prospect of immediate renumbering or of scaling inefficiencies.
适用于解决分配问题的技术原则力求在健康的保护实践和智慧与一定的易用性之间取得平衡。一方面，在管理可能有限的资源时，必须明智地节约，以防止在预期寿命内耗尽资源。另一方面，IPv6地址空间在任何意义上都不像IPv4地址空间那样是一种有限的资源，在一个已经受到其他因素影响的市场上，毫无根据的保守主义起到了抑制作用。因此，从市场发展的角度来看，我们希望用户或ISP能够非常容易地获得他们真正需要的IPv6地址，而不会出现立即重新编号或扩展效率低下的情况。
The IETF makes no comment on business issues or relationships. However, in general, we observe that technical delegation policy can have strong business impacts. A strong requirement of the address delegation plan is that it not be predicated on or unduly bias business relationships or models.
IETF对业务问题或关系不予评论。然而，一般来说，我们观察到技术授权政策可能会产生强大的业务影响。地址授权计划的一个强烈要求是，它不能基于业务关系或模型，也不能过度偏向业务关系或模型。
The IPv6 address, as currently defined, consists of 64 bits of "network number" and 64 bits of "host number". The technical reasons for this are several. The requirements for IPv6 agreed to in 1993 included a plan to be able to address approximately 2^40 networks and 2^50 hosts; the 64/64 split effectively accomplishes this. Procedures used in host address assignment, such as the router advertisement of a network's prefix to hosts [RFC2462], which in turn place a locally unique number in the host portion, depend on this split. Subnet numbers must be assumed to come from the network part. This is not to preclude routing protocols such as IS-IS level 1 (intra-area) routing, which routes individual host addresses, but says that it may not be depended upon in the world outside that zone. The 64-bit host field can also be used with EUI-64 for a flat, uniquely allocated space, and therefore it may not be globally treated as a subnetting resource. Those concerned with privacy issues linked to the presence of a globally unique identifier may note that 64 bits makes a large enough field to maintain excellent random-number-draw properties for self-configured End System Designators. That alternative construction of this 64-bit host part of an IPv6 address is documented in [RFC3041].
当前定义的IPv6地址由64位“网络号”和64位“主机号”组成。造成这种情况的技术原因有几个。1993年商定的IPv6要求包括一项能够处理大约2^40个网络和2^50个主机的计划；64/64分割有效地实现了这一点。主机地址分配中使用的过程，例如路由器向主机公布网络前缀[RFC2462]，这反过来又在主机部分中放置一个本地唯一的号码，取决于此拆分。必须假定子网编号来自网络部件。这并不是要排除路由协议，例如is-is级别1（区域内）路由，它路由单个主机地址，但表示在该区域之外的世界中可能不依赖它。64位主机字段也可与EUI-64一起用于平坦、唯一分配的空间，因此它可能不会被全局视为子网资源。那些关注与全局唯一标识符存在相关的隐私问题的人可能会注意到，64位的字段足够大，可以为自配置的终端系统指示符维护良好的随机数抽取属性。[RFC3041]中记录了IPv6地址的64位主机部分的替代结构。
While the IETF has also gone to a great deal of effort to minimize the impacts of network renumbering, renumbering of IPv6 networks is neither invisible nor completely painless. Therefore, renumbering should be considered a tolerable event, but to be avoided if reasonably feasible.
虽然IETF也做出了大量努力，以尽量减少网络重新编号的影响，但IPv6网络的重新编号既不是无形的，也不是完全无痛的。因此，重新编号应视为可容忍的事件，但在合理可行的情况下应避免。
In [RFC2374] and [RFC2450], the IETF's IPNG working group has recommended that the address block given to a single edge network which may be recursively subnetted be a 48-bit prefix. This gives each such network 2^16 subnet numbers to use in routing, and a very large number of unique host numbers within each network. This is deemed to be large enough for most enterprises, and to leave plenty of room for delegation of address blocks to aggregating entities.
在[RFC2374]和[RFC2450]中，IETF的IPNG工作组建议，可递归子网的单边网络的地址块应为48位前缀。这使得每个这样的网络在路由中使用2^16子网号，并且每个网络中有大量唯一的主机号。这被认为对大多数企业来说是足够大的，并且为将地址块委托给聚合实体留下了很大的空间。
It is not obvious, however, that all edge networks are likely to be recursively subnetted; a single PC in a home or a telephone in a mobile cellular network, for example, may or may not interface to a subnetted local network. When a network number is delegated to a place that will not require subnetting, therefore, it might be acceptable for an ISP to give a single 64-bit prefix - perhaps shared among the dial-in connections to the same ISP router. However this decision may be taken in the knowledge that there is objectively no shortage of /48s, and the expectation that personal, home networks will become the norm. Indeed, it is widely expected that all IPv6 subscribers, whether domestic (homes), mobile (vehicles or individuals), or enterprises of any size, will eventually possess multiple always-on hosts, at least one subnet with the potential for additional subnetting, and therefore some internal routing capability. In other words the subscriber allocation unit is not always a host; it is always potentially a site. The question this memo is addressing is how much address space should be delegated to such sites.
然而，不明显的是，所有的边缘网络都可能是递归的子网；例如，家庭中的单个PC或移动蜂窝网络中的电话可以连接到子网本地网络，也可以不连接到子网本地网络。因此，当一个网络号码被委派到一个不需要子网的地方时，ISP可以给出一个64位前缀，可能在同一ISP路由器的拨入连接之间共享。然而，在了解到客观上并不缺少/48，并且期望个人家庭网络将成为标准的情况下，可以做出这一决定。事实上，人们普遍预计，所有IPv6用户，无论是家庭用户、移动用户（车辆或个人用户）还是任何规模的企业，最终都将拥有多个始终在线的主机，至少有一个子网具有潜在的附加子网，从而拥有一些内部路由功能。换句话说，用户分配单元并不总是主机；它始终是一个潜在的站点。这份备忘录要解决的问题是，应该为这些网站分配多少地址空间。
The IESG and the IAB recommend the allocations for the boundary between the public and the private topology to follow those general rules:
IESG和IAB建议公共和私有拓扑之间的边界分配遵循以下一般规则：
- /48 in the general case, except for very large subscribers. - /64 when it is known that one and only one subnet is needed by design. - /128 when it is absolutely known that one and only one device is connecting.
- /48在一般情况下，除了非常大的订户/64当已知设计只需要一个子网时。-/128当完全知道只有一个设备正在连接时。
In particular, we recommend:
我们特别建议：
- Home network subscribers, connecting through on-demand or always-on connections should receive a /48. - Small and large enterprises should receive a /48. - Very large subscribers could receive a /47 or slightly shorter prefix, or multiple /48's.
- 家庭网络用户，通过按需或常开连接连接，应收到a/48。-小型和大型企业应获得a/48非常大的订户可以收到一个/47或略短的前缀，或多个/48。
- Mobile networks, such as vehicles or mobile phones with an additional network interface (such as bluetooth or 802.11b) should receive a static /64 prefix to allow the connection of multiple devices through one subnet. - A single PC, with no additional need to subnet, dialing-up from a hotel room may receive its /128 IPv6 address for a PPP style connection as part of a /64 prefix.
- 移动网络，如带有附加网络接口（如蓝牙或802.11b）的车辆或移动电话，应接收静态/64前缀，以允许通过一个子网连接多个设备。-从酒店房间拨号的一台PC（无需附加子网）可能会收到其作为/64前缀的一部分的PPP式连接的/128 IPv6地址。
Note that there seems to be little benefit in not giving a /48 if future growth is anticipated. In the following, we give the arguments for a uniform use of /48 and then demonstrate that it is entirely compatible with responsible stewardship of the total IPv6 address space.
请注意，如果预期未来的增长，不提供a/48似乎没有什么好处。在下文中，我们给出了统一使用/48的理由，然后证明它与负责管理整个IPv6地址空间完全兼容。
The arguments for the fixed boundary are:
固定边界的参数为：
- That only by having a provider-independent boundary can we guarantee that a change of ISP will not require a costly internal restructuring or consolidation of subnets.
- 只有拥有一个独立于提供商的边界，我们才能保证ISP的变更不需要昂贵的内部重组或子网整合。
- That during straightforward site renumbering from one prefix to another the whole process, including parallel running of the two prefixes, would be greatly complicated if the prefixes had different lengths (depending of course on the size and complexity of the site).
- 在直接将站点从一个前缀重新编号到另一个前缀的过程中，如果前缀的长度不同（当然取决于站点的大小和复杂性），整个过程（包括两个前缀的并行运行）将非常复杂。
- There are various possible approaches to multihoming for IPv6 sites, including the techniques already used for IPv4 multihoming. The main open issue is finding solutions that scale massively without unduly damaging route aggregation and/or optimal route selection. Much more work remains to be done in this area, but it seems likely that several approaches will be deployed in practice, each with their own advantages and disadvantages. Some (but not all) will work better with a fixed prefix boundary. (Multihoming is discussed in more detail below.)
- IPv6站点的多宿主有多种可能的方法，包括已用于IPv4多宿主的技术。主要的公开问题是找到大规模扩展的解决方案，而不会过度破坏路线聚合和/或最佳路线选择。在这方面还有许多工作要做，但似乎有可能在实践中采用几种方法，每种方法各有优缺点。有些（但不是全部）在使用固定前缀边界时效果更好。（下文将更详细地讨论多重归宿。）
- To allow easy growth of the subscribers' networks without need to go back to ISPs for more space (except for that relatively small number of subscribers for which a /48 is not enough).
- 允许用户网络的轻松增长，而无需回到ISP获得更多空间（除了数量相对较少的用户，a/48还不够）。
- To remove the burden from the ISPs and registries of judging sites' needs for address space, unless the site requests more space than a /48. This carries several advantages:
- 消除ISP和注册中心判断站点地址空间需求的负担，除非站点请求的空间超过a/48。这有几个好处：
- It may become less critical for ISPs to be able to maintain detailed knowledge of their customers' network architecture and growth plans,
- ISP能够保持对其客户网络架构和增长计划的详细了解可能变得不那么重要，
- ISPs and registries may reduce the effort spent on assessing rates of address consumption, with address space ample for long-term growth plans, - Registry operations may be made more efficient or more focused, by reducing the urgency of tracking and assessment. - Address space will no longer be a precious resource for customers, removing the major incentive for subscribers to install v6/v6 NATs, which would defeat the IPv6 restoration of address transparency.
- ISP和注册中心可能会减少在评估地址消耗率上所花费的精力，因为地址空间对于长期增长计划来说是充足的，-通过减少跟踪和评估的紧迫性，注册中心的运营可能会更加高效或更加集中。-地址空间将不再是客户的宝贵资源，从而消除了订阅者安装v6/v6 NAT的主要动机，这将破坏IPv6地址透明性恢复。
- To allow the site to maintain a single reverse-DNS zone covering all prefixes.
- 允许站点维护覆盖所有前缀的单个反向DNS区域。
- If and only if a site can use the same subnetting structure under each of its prefixes, then it can use the same zone file for the address-to-name mapping of all of them. And, using the conventions of [RFC2874], it can roll the reverse mapping data into the "forward" (name-keyed) zone.
- 如果且仅当一个站点可以在其每个前缀下使用相同的子网结构，则它可以使用相同的区域文件作为所有前缀的地址到名称映射。并且，使用[RFC2874]的约定，它可以将反向映射数据滚动到“前进”（名称键控）区域。
Specific advantages of the fixed boundary being at /48 include
at/48固定边界的具体优点包括
- To leave open the technical option of retro-fitting the GSE (Global, Site and End-System Designator, a.k.a., "8+8") proposal for separating locators and identifiers, which assumes a fixed boundary between global and site addressing at /48. Although the GSE technique was deferred a couple of years ago, it still has strong proponents. Also, the IRTF Namespace Research Group is actively looking into topics closely related to GSE. It is still possible that GSE or a derivative of GSE will be used with IPv6 in the future.
- 保留对GSE（全球、现场和终端系统指示器，也称“8+8”）进行重新装配的技术选项，用于分离定位器和标识符，假设全球和现场地址在/48之间存在固定边界。虽然GSE技术在几年前被推迟，但它仍然有强烈的支持者。此外，IRTF名称空间研究小组正在积极研究与GSE密切相关的主题。GSE或GSE的衍生物将来仍有可能与IPv6一起使用。
- Since the site-local prefix is fec0::/48, global site prefixes of /48 will allow sites to easily maintain a trivial (identity) mapping between the global topology and the site-local topology in the SLA field.
- 由于站点本地前缀为fec0:：/48，全局站点前缀为/48将允许站点在SLA字段中轻松维护全局拓扑和站点本地拓扑之间的简单（标识）映射。
- Similarly, if the 6to4 proposal is widely deployed, migration from a 6to4 prefix, which is /48 by construction, to a native IPv6 prefix will be simplified if the native prefix is /48.
- 类似地，如果6to4方案得到广泛部署，则如果本机前缀为/48，则从6to4前缀（构造为/48）到本机IPv6前缀的迁移将简化。
The question naturally arises whether giving a /48 to every subscriber represents a profligate waste of address space. Objective analysis shows that this is not the case. A /48 prefix under the 001 Global Unicast Address prefix contains 45 variable bits. That is, the number of available prefixes is 2 to the power 45 or about 35 trillion (35,184,372,088,832).
问题自然会出现，给每个订户分配a/48是否意味着地址空间的浪费。客观分析表明情况并非如此。001全局单播地址前缀下的A/48前缀包含45个可变位。也就是说，可用前缀的数量是45次方的2，即大约35万亿（35184372088832）。
More precisely,
更准确地说,，
- [RFC1715] defines an "H ratio" based on experience in address space assignment in various networks. The H ratio varies between 0 and 0.3, with larger values denoting denser, more efficient assignment. Experience shows that problems start to occur when the H ratio becomes greater than 0.25. At an H ratio of 0.25, a 45 bit address space would have 178 billion (178 thousand million) identifiers.
- [RFC1715]根据各种网络中地址空间分配的经验定义了“H比率”。H比率在0和0.3之间变化，较大的值表示更密集、更有效的分配。经验表明，当H比大于0.25时，问题开始出现。在H比率为0.25时，45位地址空间将有1780亿（178亿）标识符。
H = log10(178*10^9) / 45 = 0.25
H = log10(178*10^9) / 45 = 0.25
This means that we feel comfortable about the prospect of allocating 178 billions /48 prefixes under that scheme before problems start to appear. To understand how big that number is, one has to compare 178 billion to 10 billion, which is the projected population on earth in year 2050 (see http://www.census.gov/ipc/www/world.html). These numbers give no grounds for concern provided that the ISPs, under the guidance of the RIRs, allocate /48's prudently, and that the IETF refrains from new recommendations that further reduce the remaining 45 variable bits, unless a compelling requirement emerges.
这意味着，在问题开始出现之前，我们对在该方案下分配1780亿/48个前缀的前景感到放心。要了解这个数字有多大，我们必须将1780亿到100亿进行比较，这是2050年地球上的预计人口（参见http://www.census.gov/ipc/www/world.html). 如果ISP在RIRs的指导下谨慎分配/48，并且IETF不提出进一步减少剩余45个可变位的新建议，则这些数字没有理由令人担忧，除非出现强制要求。
- We are highly confident in the validity of this analysis, based on experience with IPv4 and several other address spaces, and on extremely ambitious scaling goals for the Internet amounting to an 80 bit address space *per person*. Even so, being acutely aware of the history of under-estimating demand, the IETF has reserved more than 85% of the address space (i.e., the bulk of the space not under the 001 Global Unicast Address prefix). Therefore, if the analysis does one day turn out to be wrong, our successors will still have the option of imposing much more restrictive allocation policies on the remaining 85%. However, we must stress that vendors should not encode any of the boundaries discussed here either in software nor hardware. Under that assumption, should we ever have to use the remaining 85% of the address space, such a migration may not be devoid of pain, but it should be far less disruptive than deployment of a new version of IP.
- 基于IPv4和其他几个地址空间的经验，以及互联网达到每人80位地址空间*的雄心勃勃的扩展目标，我们对该分析的有效性充满信心。即便如此，IETF敏锐地意识到低估需求的历史，保留了85%以上的地址空间（即，大部分空间不在001全局单播地址前缀下）。因此，如果有一天分析结果是错误的，我们的继任者仍然可以选择对剩下的85%实施更严格的分配政策。但是，我们必须强调，供应商不应在软件或硬件中对此处讨论的任何边界进行编码。在这种假设下，如果我们不得不使用剩余的85%的地址空间，这样的迁移可能并非毫无痛苦，但它应该比部署新版本的IP具有更少的破坏性。
To summarize, we argue that although careful stewardship of IPv6 address space is essential, this is completely compatible with the convenience and simplicity of a uniform prefix size for IPv6 sites of any size. The numbers are such that there seems to be no objective risk of running out of space, giving an unfair amount of space to early customers, or of getting back into the over-constrained IPv4
总而言之，我们认为，尽管谨慎管理IPv6地址空间至关重要，但这与任何大小的IPv6站点的统一前缀大小的方便性和简单性完全兼容。这些数字表明，似乎不存在空间不足、给早期客户不公平的空间量或重新进入过度受限的IPv4的客观风险
situation where address conservation and route aggregation damage each other.
地址保护和路由聚合相互损害的情况。
In the realm of multi-homed networks, the techniques used in IPv4 can all be applied, but they have known scaling problems. Specifically, if the same prefix is advertised by multiple ISPs, the routing information will grow as a function of the number of multihomed sites. To go beyond this for IPv6, we only have initial proposals on the table at this time, and active work is under way in the IETF IPNG and Multi6 working groups. Until current or new proposals become more fully developed, existing techniques known to work in IPv4 will continue to be used in IPv6.
在多宿网络领域，IPv4中使用的技术都可以应用，但它们都存在扩展问题。具体来说，如果多个ISP发布相同的前缀，则路由信息将随着多址站点数量的增加而增加。除了IPv6，我们目前只有初步建议，IETF-IPNG和Multi6工作组正在积极开展工作。在当前或新的提案得到更充分的开发之前，已知在IPv4中有效的现有技术将继续在IPv6中使用。
Key characteristics of an ideal multi-homing proposal include (at minimum) that it provides routing connectivity to any multi-homed network globally, conserves address space, produces high quality routes via any of the network's providers, enables a multi-homed network to connect to multiple ISPs, does not unintentionally bias routing to use any proper subset of those networks, does not damage route aggregation, and scales to very large numbers of multi-homed networks.
理想多宿方案的关键特征包括（至少）它提供全球范围内任何多宿网络的路由连接，节省地址空间，通过任何网络提供商生成高质量路由，使多宿网络能够连接到多个ISP，不会无意中偏向路由以使用这些网络的任何适当子集，不会损坏路由聚合，并可扩展到大量多宿网络。
One class of solutions being considered amounts to permanent parallel running of two (or more) prefixes per site. In the absence of a fixed prefix boundary, such a site might be required to have multiple different internal subnet numbering strategies, (one for each prefix length) or, if it only wanted one, be forced to use the most restrictive one as defined by the longest prefix it received from any of its ISPs. In this approach, a multi-homed network would have an address block from each of its upstream providers. Each host would either have exactly one address picked from the set of upstream providers, or one address per host from each of the upstream providers. The first case is essentially a variant on [RFC2260], with known scaling limits.
考虑的一类解决方案相当于每个站点永久并行运行两个（或多个）前缀。在没有固定前缀边界的情况下，这样的站点可能需要有多个不同的内部子网编号策略（每个前缀长度一个），或者，如果它只需要一个，则必须使用从其任何ISP收到的最长前缀定义的最严格的子网编号策略。在这种方法中，多宿网络将具有来自其每个上游提供商的地址块。每个主机都可以从一组上游提供程序中选择一个地址，或者每个主机都可以从每个上游提供程序中选择一个地址。第一种情况本质上是[RFC2260]上的一种变体，具有已知的缩放限制。
In the second case (multiple addresses per host), if two multi-homed networks communicate, having respectively M and N upstream providers, then the one initiating the connection will select one address pair from the N*M potential address pairs to connect between, and in so doing will select the providers, and therefore the applicable route, for the life of the connection. Given that each path will have a different available bit rate, loss rate, and delay, if neither host is in possession of any routing or metric information, the initiating host has only a 1/(M*N) probability of selecting the optimal address pair. Work on better-than-random address selection is in progress in the IETF, but is incomplete.
在第二种情况下（每个主机有多个地址），如果两个多宿网络通信，分别具有M个和N个上游提供者，则发起连接的网络将从N*M个潜在地址对中选择一个地址对进行连接，这样做将选择提供者，从而选择适用的路由，对于连接的生命周期。假设每个路径将具有不同的可用比特率、丢失率和延迟，如果两个主机都不拥有任何路由或度量信息，则发起主机选择最佳地址对的概率仅为1/（M*N）。IETF正在进行优于随机地址选择的工作，但尚未完成。
The existing IPv4 Internet shows us that a network prefix which is independent of, and globally advertised to, all upstream providers permits the routing system to select a reasonably good path within the applicable policy. Present-day routing policies are not QoS policies but reachability policies, which means that they will not necessarily select the optimal delay, bit rate, or loss rate, but the route will be the best within the metrics that are in use. One may therefore conclude that this would work correctly for IPv6 networks as well, apart from scaling issues.
现有的IPv4互联网向我们表明，独立于所有上游提供商并向其进行全球宣传的网络前缀允许路由系统在适用的策略内选择合理的良好路径。当前的路由策略不是QoS策略，而是可达性策略，这意味着它们不一定会选择最佳延迟、比特率或丢失率，但路由将在使用的度量中是最佳的。因此，人们可能会得出这样的结论：除了扩展问题外，这也适用于IPv6网络。
This document does not have any security implications.
本文件不涉及任何安全问题。
This document originated from the IETF IPv6 directorate, with much input from the IAB and IESG. The original text forming the basis of this document was contributed by Fred Baker and Brian Carpenter. Allison Mankin and Thomas Narten merged the original contributions into a single document, and Alain Durand edited the document through its final stages.
本文件来源于IETF IPv6理事会，IAB和IESG提供了大量信息。构成本文件基础的原始文本由Fred Baker和Brian Carpenter提供。Allison Mankin和Thomas Narten将原始贡献合并到一个文档中，Alain Durand在文档的最后阶段对其进行了编辑。
[RFC1715] Huitema, C., "The H Ratio for Address Assignment Efficiency", RFC 1715, November 1994.
[RFC1715]Huitema，C.，“地址分配效率的H比率”，RFC17151994年11月。
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[RFC2026]Bradner，S.，“互联网标准过程——第3版”，BCP 9，RFC 2026，1996年10月。
[RFC2260] Bates, T. and Y. Rekhter, "Scalable Support for Multi-homed Multi-provider Connectivity", RFC 2260, January 1998.
[RFC2260]Bates，T.和Y.Rekhter，“多宿多提供商连接的可扩展支持”，RFC 2260，1998年1月。
[RFC2374] Hinden, R., O'Dell, M. and S. Deering, "An IPv6 Aggregatable Global Unicast Address Format", RFC 2374, July 1998.
[RFC2374]Hinden，R.，O'Dell，M.和S.Deering，“一种IPv6可聚合全球单播地址格式”，RFC 2374，1998年7月。
[RFC2450] Hinden, R., "Proposed TLA and NLA Assignment Rule", RFC 2450, December 1998.
[RFC2450]Hinden，R.，“拟议的TLA和NLA分配规则”，RFC 2450，1998年12月。
[RFC2462] Thompson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998.
[RFC2462]Thompson，S.和T.Narten，“IPv6无状态地址自动配置”，RFC2462，1998年12月。
[RFC2874] Crawford, M. and C. Huitema, "DNS Extensions to Support IPv6 Address Aggregation and Renumbering", RFC 2874, July 2000.
[RFC2874]Crawford，M.和C.Huitema，“支持IPv6地址聚合和重新编号的DNS扩展”，RFC 28742000年7月。
[RFC3041] Narten, T. and R. Draves, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 3041, January 2001.
[RFC3041]Narten，T.和R.Draves，“IPv6中无状态地址自动配置的隐私扩展”，RFC 3041，2001年1月。
[MobIPv6] Johnson, D. and C. Perkins, "Mobility Support in IPv6", Work in Progress.
[Mobiv6]Johnson，D.和C.Perkins，“IPv6中的移动支持”，正在进行中。
Internet Architecture Board
互联网架构委员会
Email: iab@iab.org
Email: iab@iab.org
Internet Engineering Steering Group
互联网工程指导小组
Email: iesg@ietf.org
Email: iesg@ietf.org
Copyright (C) The Internet Society (2001). All Rights Reserved.
版权所有（C）互联网协会（2001年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。