Internet Engineering Task Force (IETF) T. Narten
Request for Comments: 6177 IBM
BCP: 157 G. Huston
Obsoletes: 3177 APNIC
Category: Best Current Practice L. Roberts
ISSN: 2070-1721 Stanford University
March 2011
Internet Engineering Task Force (IETF) T. Narten
Request for Comments: 6177 IBM
BCP: 157 G. Huston
Obsoletes: 3177 APNIC
Category: Best Current Practice L. Roberts
ISSN: 2070-1721 Stanford University
March 2011
IPv6 Address Assignment to End Sites
向终端站点分配IPv6地址
Abstract
摘要
RFC 3177 argued that in IPv6, end sites should be assigned /48 blocks in most cases. The Regional Internet Registries (RIRs) adopted that recommendation in 2002, but began reconsidering the policy in 2005. This document obsoletes the RFC 3177 recommendations on the assignment of IPv6 address space to end sites. The exact choice of how much address space to assign end sites is an issue for the operational community. The IETF's role in this case is limited to providing guidance on IPv6 architectural and operational considerations. This document reviews the architectural and operational considerations of end site assignments as well as the motivations behind the original recommendations in RFC 3177. Moreover, this document clarifies that a one-size-fits-all recommendation of /48 is not nuanced enough for the broad range of end sites and is no longer recommended as a single default.
RFC3177认为，在IPv6中，在大多数情况下，应该为终端站点分配/48个块。区域互联网登记处于2002年通过了这项建议，但于2005年开始重新考虑这项政策。本文件废除了RFC 3177关于向终端站点分配IPv6地址空间的建议。如何准确选择分配多少地址空间给终端站点是运营社区的一个问题。在这种情况下，IETF的作用仅限于提供有关IPv6体系结构和操作注意事项的指导。本文件回顾了最终站点分配的架构和操作考虑，以及RFC 3177中原始建议背后的动机。此外，本文件澄清了/48的“一刀切”建议对于广泛的终端站点来说不够细致，不再建议作为单一默认。
This document obsoletes RFC 3177.
本文件淘汰了RFC 3177。
Status of This Memo
关于下段备忘
This memo documents an Internet Best Current Practice.
本备忘录记录了互联网最佳实践。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on BCPs is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关BCP的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6177.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6177.
Copyright Notice
版权公告
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2011 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
Table of Contents
目录
1. Introduction ....................................................3
2. On /48 Assignments to End Sites .................................4
3. Other RFC 3177 Considerations ...................................6
4. Impact on IPv6 Standards ........................................6
4.1. RFC 3056: Connection of IPv6 Domains via IPv4 Clouds .......6
4.2. IPv6 Multicast Addressing ..................................7
5. Summary .........................................................7
6. Security Considerations .........................................8
7. Acknowledgments .................................................8
8. Informative References ..........................................8
1. Introduction ....................................................3
2. On /48 Assignments to End Sites .................................4
3. Other RFC 3177 Considerations ...................................6
4. Impact on IPv6 Standards ........................................6
4.1. RFC 3056: Connection of IPv6 Domains via IPv4 Clouds .......6
4.2. IPv6 Multicast Addressing ..................................7
5. Summary .........................................................7
6. Security Considerations .........................................8
7. Acknowledgments .................................................8
8. Informative References ..........................................8
There are a number of considerations that factor into address assignment policies. For example, to provide for the long-term health and scalability of the public routing infrastructure, it is important that addresses aggregate well [ROUTE-SCALING]. Likewise, giving out an excessive amount of address space could result in premature depletion of the address space. This document focuses on the (more narrow) question of what is an appropriate IPv6 address assignment size for end sites. That is, when end sites request IPv6 address space from ISPs, what is an appropriate assignment size.
在地址分配策略中有许多考虑因素。例如，为了保证公共路由基础设施的长期健康和可伸缩性，必须很好地解决聚合问题[ROUTE-SCALING]。同样，给出过多的地址空间可能会导致地址空间过早耗尽。本文档重点讨论终端站点的适当IPv6地址分配大小（更窄）问题。也就是说，当终端站点从ISP请求IPv6地址空间时，合适的分配大小是多少。
RFC 3177 [RFC3177] called for a default end site IPv6 assignment size of /48. Subsequently, the Regional Internet Registries (RIRs) developed and adopted IPv6 address assignment and allocation policies consistent with the recommendations of RFC 3177 [RIR-IPV6]. In 2005, the RIRs began discussing IPv6 address assignment policy again. Since then, APNIC [APNIC-ENDSITE], ARIN [ARIN-ENDSITE], and RIPE [RIPE-ENDSITE] have revised the end site assignment policy to encourage the assignment of smaller (i.e., /56) blocks to end sites.
RFC 3177[RFC3177]要求默认的终端站点IPv6分配大小为/48。随后，区域互联网注册中心（RIR）制定并采用了符合RFC 3177[RIR-IPv6]建议的IPv6地址分配和分配政策。2005年，RIR再次开始讨论IPv6地址分配策略。此后，APNIC[APNIC-ENDSITE]、ARIN[ARIN-ENDSITE]和RIME[RIME-ENDSITE]修改了终端站点分配政策，以鼓励将较小（即/56）区块分配给终端站点。
This document obsoletes RFC 3177, updating its recommendations in the following ways:
本文件淘汰了RFC 3177，并通过以下方式更新其建议：
1) It is no longer recommended that /128s be given out. While there may be some cases where assigning only a single address may be justified, a site, by definition, implies multiple subnets and multiple devices.
1) 不再建议发出/128s。虽然在某些情况下，仅分配一个地址可能是合理的，但根据定义，一个站点意味着多个子网和多个设备。
2) RFC 3177 specifically recommended using prefix lengths of /48, /64, and /128. Specifying a small number of fixed boundaries has raised concerns that implementations and operational practices might become "hard-coded" to recognize only those fixed boundaries (i.e., a return to "classful addressing"). The actual intention has always been that there be no hard-coded boundaries within addresses, and that Classless Inter-Domain Routing (CIDR) continues to apply to all bits of the routing prefixes.
2) RFC 3177特别建议使用前缀长度/48、/64和/128。指定少量的固定边界引起了人们的担忧，即实现和操作实践可能会变得“硬编码”以仅识别这些固定边界（即，返回到“类式寻址”）。实际意图一直是在地址中没有硬编码边界，并且无类域间路由（CIDR）继续应用于路由前缀的所有位。
3) This document moves away from the previous recommendation that a single default assignment size (e.g., a /48) makes sense for all end sites in the general case. End sites come in different shapes and sizes, and a one-size-fits-all approach is not necessary or appropriate.
3) 本文件偏离了先前的建议，即在一般情况下，单一默认分配大小（如a/48）适用于所有终端站点。终端站点有不同的形状和大小，一个一刀切的方法是不必要或不合适的。
This document does, however, reaffirm an important assumption behind RFC 3177:
然而，本文件确实重申了RFC 3177背后的一个重要假设：
A key principle for address management is that end sites always be able to obtain a reasonable amount of address space for their actual and planned usage, and over time ranges specified in years rather than just months. In practice, that means at least one /64, and in most cases significantly more. One particular situation that must be avoided is having an end site feel compelled to use IPv6-to-IPv6 Network Address Translation or other burdensome address conservation techniques because it could not get sufficient address space.
地址管理的一个关键原则是，终端站点始终能够为其实际和计划使用获得合理数量的地址空间，并且在指定的时间范围内以年为单位，而不仅仅是以月为单位。在实践中，这意味着至少有1/64，而且在大多数情况下要多得多。必须避免的一种特殊情况是，由于无法获得足够的地址空间，终端站点不得不使用IPv6到IPv6的网络地址转换或其他繁重的地址保存技术。
This document does not make a formal recommendation on what the exact assignment size should be. The exact choice of how much address space to assign end sites is an issue for the operational community. The IETF's role in this case is limited to providing guidance on IPv6 architectural and operational considerations. This document provides input into those discussions. The focus of this document is to examine the architectural issues and some of the operational considerations relating to the size of the end site assignment.
本文件未就具体分配规模提出正式建议。如何准确选择分配多少地址空间给终端站点是运营社区的一个问题。在这种情况下，IETF的作用仅限于提供有关IPv6体系结构和操作注意事项的指导。本文件为这些讨论提供了投入。本文件的重点是检查与最终现场分配规模相关的架构问题和一些操作注意事项。
Looking back at some of the original motivations behind the /48 recommendation [RFC3177], there were three main concerns. The first motivation was to ensure that end sites could easily obtain sufficient address space without having to "jump through hoops" to do so. For example, if someone felt they needed more space, just the act of asking would at some level be sufficient justification. As a comparison point, in IPv4, typical home users are given a single public IP address (though even this is not always assured), but getting any more than one address is often difficult or even impossible -- unless one is willing to pay a (significantly) increased fee for what is often considered to be a "higher grade" of service. (It should be noted that increased ISP charges to obtain a small number of additional addresses cannot usually be justified by the real per-address cost levied by RIRs, but additional addresses are frequently only available to end users as part of a different type or "higher grade" of service, for which an additional charge is levied. The point here is that the additional cost is not due to the RIR fee structures, but to business choices ISPs make.) An important goal in IPv6 is to significantly change the default and minimal end site assignment, from "a single address" to "multiple networks" and to ensure that end sites can easily obtain address space.
回顾/48建议[RFC3177]背后的一些原始动机，有三个主要问题。第一个动机是确保终端站点可以轻松地获得足够的地址空间，而不必“跳转”。例如，如果有人觉得他们需要更多的空间，在某种程度上，仅仅是提问的行为就足够了。作为一个比较点，在IPv4中，典型的家庭用户被赋予一个单一的公共IP地址（尽管这并不总是确定），但获得多个地址通常是困难的，甚至是不可能的——除非人们愿意为通常被认为是“更高级别”的服务支付（显著）增加的费用。（应该注意的是，为获得少量额外地址而增加ISP费用通常不能以RIR征收的实际每个地址成本为理由，但额外地址通常仅作为不同类型或“更高级别”的一部分提供给最终用户。）IPv6的一个重要目标是显著改变默认和最小的终端站点分配，从“单个地址”到“多个网络”并确保终端站点可以轻松获得地址空间。
A second motivation behind the original /48 recommendation was to simplify the management of an end site's addressing plan in the presence of renumbering (e.g., when switching ISPs). In IPv6, a site may simultaneously use multiple prefixes, including one or more public prefixes from ISPs as well as Unique Local Addresses [ULA-ADDRESSES]. In the presence of multiple prefixes, it is significantly less complex to manage a numbering plan if the same subnet numbering plan can be used for all prefixes. That is, for a link that has (say) three different prefixes assigned to it, the subnet portion of those prefixes would be identical for all assigned addresses. In contrast, renumbering from a larger set of "subnet bits" into a smaller set is often painful, as it can require making changes to the network itself (e.g., collapsing subnets). Hence, renumbering a site into a prefix that has (at least) the same number of subnet bits is more straightforward, because only the top-level bits of the address need to change. A key goal of the recommendations in RFC 3177 is to ensure that upon renumbering, one does not have to deal with renumbering into a smaller subnet size.
原始/48建议背后的第二个动机是在重新编号的情况下（例如，在切换ISP时），简化终端站点寻址计划的管理。在IPv6中，站点可以同时使用多个前缀，包括来自ISP的一个或多个公共前缀以及唯一的本地地址[ULA-Addresses]。在存在多个前缀的情况下，如果可以对所有前缀使用相同的子网编号计划，则管理编号计划的复杂性将大大降低。也就是说，对于分配了（比如）三个不同前缀的链路，这些前缀的子网部分对于所有分配的地址都是相同的。相反，从较大的“子网位”集合重新编号到较小的集合通常是痛苦的，因为它可能需要对网络本身进行更改（例如，子网崩溃）。因此，将站点重新编号为具有（至少）相同数量子网位的前缀更为简单，因为只有地址的顶级位需要更改。RFC3177中建议的一个关键目标是确保在重新编号时，不必处理重新编号到更小的子网大小的问题。
It should be noted that similar arguments apply to the management of zone files in the DNS. In particular, managing the reverse (ip6.arpa) tree is simplified when all links are numbered using the same subnet ids.
应注意，类似的参数适用于DNS中区域文件的管理。特别是，当使用相同的子网ID对所有链路进行编号时，可以简化反向（ip6.arpa）树的管理。
A third motivation behind the /48 recommendation was to better support network growth common at many sites. In IPv4, it is usually difficult (or impossible) to obtain public address space for more than a few months worth of projected growth. Thus, even slow growth over several years can lead to the need to renumber into a larger address block. With IPv6's vast address space, end sites can easily be given more address space (compared with IPv4) to support expected growth over multi-year time periods.
48建议背后的第三个动机是更好地支持许多站点常见的网络增长。在IPv4中，通常很难（或不可能）获得超过几个月的预期增长的公共广播空间。因此，即使几年来增长缓慢，也可能导致需要重新编号为更大的地址块。有了IPv6巨大的地址空间，终端站点可以轻松获得更多的地址空间（与IPv4相比），以支持多年的预期增长。
While the /48 recommendation does simplify address space management for end sites, it has also been widely criticized as being wasteful. For example, a large business (which may have thousands of employees) would, by default, receive the same amount of address space as a home user, who today typically has a single (or small number of) LAN and a small number of devices (dozens or less). While it seems likely that the size of a typical home network will grow over the next few decades, it is hard to argue that home sites will make use of 65K subnets within the foreseeable future. At the same time, it might be tempting to give home sites a single /64, since that is already significantly more address space compared with today's IPv4 practice. However, this precludes the expectation that even home sites will grow to support multiple subnets going forward. Hence, it is strongly intended that even home sites be given multiple subnets
虽然/48建议确实简化了终端站点的地址空间管理，但也被广泛批评为浪费。例如，一家大型企业（可能有数千名员工）默认情况下会收到与家庭用户相同数量的地址空间，而家庭用户目前通常只有一个（或少量）局域网和少量设备（几十个或更少）。虽然在未来几十年内，一个典型家庭网络的规模可能会增长，但很难说家庭站点在可预见的未来会使用65K子网。同时，给家庭站点提供一个/64可能很有诱惑力，因为与今天的IPv4实践相比，这已经大大增加了地址空间。然而，这排除了即使是家庭站点也会增长以支持多个子网的期望。因此，强烈希望即使是家庭站点也能有多个子网
worth of space, by default. Hence, this document still recommends giving home sites significantly more than a single /64, but does not recommend that every home site be given a /48 either.
默认情况下，空间的价值。因此，本文件仍然建议提供比单个/64多得多的主页，但也不建议为每个主页提供/48。
A change in policy (such as above) would have a significant impact on address consumption projections and the expected longevity for IPv6. For example, changing the default assignment from a /48 to /56 (for the vast majority of end sites, e.g., home sites) would result in a savings of up to 8 bits, reducing the "total projected address consumption" by (up to) 8 bits or two orders of magnitude. (The exact amount of savings depends on the relative number of home users compared with the number of larger sites.)
政策的改变（如上文所述）将对IPv6的地址消耗预测和预期寿命产生重大影响。例如，将默认分配从a/48更改为a/56（对于绝大多数终端站点，例如家庭站点），将节省最多8位，从而将“总预计地址消耗”减少（最多）8位或两个数量级。（节省的确切数额取决于家庭用户的相对数量与大型网站的数量。）
The above-mentioned goals of RFC 3177 can easily be met by giving home users a default assignment of less than /48, such as a /56.
通过向家庭用户提供小于/48的默认分配（如a/56），可以轻松实现RFC 3177的上述目标。
RFC 3177 suggested that some multihoming approaches (e.g., Generalized Structure Element (GSE)) might benefit from having a fixed /48 boundary. This no longer appears to be a consideration.
RFC 3177建议，一些多归宿方法（例如，广义结构单元（GSE））可能受益于具有固定的/48边界。这似乎不再是一个考虑因素。
RFC 3177 argued that having a "one-size-fits-all" default assignment size reduced the need for customers to continually or repeatedly justify the usage of existing address space in order to get "a little more". Likewise, it also reduces the need for ISPs to evaluate such requests. Given the large amount of address space in IPv6, there is plenty of space to grant end sites enough space to be consistent with reasonable growth projections over multi-year time frames. Thus, it remains highly desirable to provide end sites with enough space (on both initial and subsequent assignments) to last several years. Fortunately, this goal can be achieved in a number of ways and does not require that all end sites receive the same default size assignment.
RFC 3177认为，“一刀切”的默认分配大小减少了客户持续或反复证明现有地址空间使用合理性的需要，以获得“多一点”。同样，它也减少了ISP评估此类请求的需要。考虑到IPv6中有大量的地址空间，有足够的空间授予终端站点足够的空间，以符合多年时间范围内的合理增长预测。因此，仍然非常希望为最终站点提供足够的空间（在初始任务和后续任务中）以持续几年。幸运的是，这一目标可以通过多种方式实现，并且不需要所有终端站点都接受相同的默认大小分配。
RFC 3056 [RFC3056] describes a way of generating IPv6 addresses from an existing public IPv4 address. That document describes an address format in which the first 48 bits concatenate a well-known prefix with a globally unique public IPv4 address. The "SLA ID" field is assumed to be 16 bits, consistent with a 16-bit "subnet id" field. To facilitate transitioning from the address numbering scheme in RFC 3056 to one based on a prefix obtained from an ISP, an end site would be advised to number out of the right most bits first, using the leftmost bits only if the size of the site made that necessary.
RFC 3056[RFC3056]描述了一种从现有公共IPv4地址生成IPv6地址的方法。该文档描述了一种地址格式，其中前48位将一个众所周知的前缀与一个全局唯一的公共IPv4地址连接起来。假定“SLA ID”字段为16位，与16位“子网ID”字段一致。为了便于从RFC 3056中的地址编号方案转换为基于从ISP获得的前缀的地址编号方案，建议终端站点首先从最右边的位进行编号，仅当站点的大小需要时才使用最左边的位。
Similar considerations apply to other documents that allow for a subnet id of 16 bits, including [ULA-ADDRESSES].
类似的考虑也适用于允许子网id为16位的其他文档，包括[ULA-ADDRESSES]。
Some IPv6 multicast address assignment schemes embed a unicast IPv6 prefix into the multicast address itself [RFC3306]. Such documents do not assume a particular size for the subnet id, per se, but do assume that the IPv6 prefix is a /64. Thus, the relative size of the subnet id has no direct impact on multicast address schemes.
一些IPv6多播地址分配方案将单播IPv6前缀嵌入多播地址本身[RFC3306]。此类文档本身并不假定子网id的特定大小，但假定IPv6前缀为a/64。因此，子网id的相对大小对多播地址方案没有直接影响。
The exact choice of how much address space to assign end sites is an issue for the operational community. The recommendation in RFC 3177 [RFC3177] to assign /48s as a default is not a requirement of the IPv6 architecture; anything of length /64 or shorter works from a standards perspective. However, there are important operational considerations as well, some of which are important if users are to share in the key benefit of IPv6: expanding the usable address space of the Internet. The IETF recommends that any policy on IPv6 address assignment policy to end sites take into consideration the following:
如何准确选择分配多少地址空间给终端站点是运营社区的一个问题。RFC 3177[RFC3177]中建议将/48s分配为默认值，这不是IPv6体系结构的要求；从标准的角度来看，长度为/64或更短的作品。然而，也有一些重要的操作考虑因素，如果用户想要分享IPv6的主要好处：扩展Internet的可用地址空间，其中一些是重要的。IETF建议，任何针对终端站点的IPv6地址分配策略都应考虑以下因素：
- it should be easy for an end site to obtain address space to number multiple subnets (i.e., a block larger than a single /64) and to support reasonable growth projections over long time periods (e.g., a decade or more).
- 终端站点应该很容易获得地址空间来对多个子网进行编号（即，大于单个/64的块），并支持长时间（例如，十年或更长时间）的合理增长预测。
- the default assignment size should take into consideration the likelihood that an end site will have need for multiple subnets in the future and avoid the IPv4 practice of having frequent and continual justification for obtaining small amounts of additional space.
- 默认分配大小应考虑到终端站点将来可能需要多个子网的可能性，并避免IPv4的做法，即为获得少量额外空间而频繁和持续地进行调整。
- Although a /64 can (in theory) address an almost unlimited number of devices, sites should be given sufficient address space to be able to lay out subnets as appropriate, and not be forced to use address conservation techniques such as using bridging. Whether or not bridging is an appropriate choice is an end site matter.
- 虽然a/64（理论上）可以寻址几乎无限数量的设备，但应为站点提供足够的地址空间，以便能够适当地布局子网，而不是被迫使用地址保护技术，例如使用桥接。桥接是否是一个合适的选择是最终站点的问题。
- assigning a longer prefix to an end site, compared with the existing prefixes the end site already has assigned to it, is likely to increase operational costs and complexity for the end site, with insufficient benefit to anyone.
- 与终端站点已经分配给它的现有前缀相比，为终端站点分配更长的前缀可能会增加终端站点的运营成本和复杂性，对任何人都没有足够的好处。
- the operational considerations of managing and delegating the reverse DNS tree under ip6.arpa on nibble versus non-nibble boundaries should be given adequate consideration.
- 应充分考虑在半字节和非半字节边界上管理和委派ip6.arpa下的反向DNS树的操作考虑。
This document has no known security implications.
此文档没有已知的安全含义。
This document was motivated by and benefited from numerous conversations held during the ARIN XV and RIPE 50 meetings in April-May, 2005.
本文件受2005年4月至5月ARIN XV和CREAME 50会议期间举行的多次对话的推动，并从中受益。
[APNIC-ENDSITE] "prop-031: Proposal to amend APNIC IPv6 assignment
and utilisation requirement policy,"
http://www.apnic.net/policy/proposals/prop-031
[APNIC-ENDSITE] "prop-031: Proposal to amend APNIC IPv6 assignment
and utilisation requirement policy,"
http://www.apnic.net/policy/proposals/prop-031
[ARIN-ENDSITE] "2005-8: Proposal to amend ARIN IPv6 assignment and
utilisation requirement",
http://www.arin.net/policy/proposals/2005_8.html
[ARIN-ENDSITE] "2005-8: Proposal to amend ARIN IPv6 assignment and
utilisation requirement",
http://www.arin.net/policy/proposals/2005_8.html
[RIR-IPV6] ARIN: http://www.arin.net/policy/nrpm.html#ipv6; RIPE
Document ID: ripe-267, Date: 22 January 2003
http://www.ripe.net/ripe/docs/ipv6policy.html; APNIC:
http://www.apnic.net/docs/policy/ipv6-address-
policy.html
[RIR-IPV6] ARIN: http://www.arin.net/policy/nrpm.html#ipv6; RIPE
Document ID: ripe-267, Date: 22 January 2003
http://www.ripe.net/ripe/docs/ipv6policy.html; APNIC:
http://www.apnic.net/docs/policy/ipv6-address-
policy.html
[RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4 Clouds", RFC 3056, February 2001.
[RFC3056]Carpenter，B.和K.Moore，“通过IPv4云连接IPv6域”，RFC 3056，2001年2月。
[RFC3306] Haberman, B. and D. Thaler, "Unicast-Prefix-based IPv6 Multicast Addresses", RFC 3306, August 2002.
[RFC3306]Haberman，B.和D.Thaler，“基于单播前缀的IPv6多播地址”，RFC3306，2002年8月。
[RFC3177] IAB and IESG, "IAB/IESG Recommendations on IPv6 Address Allocations to Sites", RFC 3177, September 2001.
[RFC3177]IAB和IESG，“IAB/IESG对站点IPv6地址分配的建议”，RFC3177，2001年9月。
[RIPE-ENDSITE] "Proposal to Amend the IPv6 Assignment and Utilisation Requirement Policy", 2005-8, http://www.ripe.net/ripe/policies/proposals/2005-08.
[RIME-ENDSITE]“修订IPv6分配和使用要求政策的提案”，2005-8，http://www.ripe.net/ripe/policies/proposals/2005-08.
[ROUTE-SCALING] "Routing and Addressing Problem Statement", Work in Progress, February 2010.
[ROUTE-SCALING]“路由和解决问题声明”，正在进行的工作，2010年2月。
[ULA-ADDRESSES] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, October 2005.
[ULA-ADDRESSES]Hinden，R.和B.Haberman，“唯一本地IPv6单播地址”，RFC 41932005年10月。
Authors' Addresses
作者地址
Thomas Narten IBM Corporation 3039 Cornwallis Ave. PO Box 12195 Research Triangle Park, NC 27709-2195
Thomas Narten IBM Corporation北卡罗来纳州研究三角公园康沃利斯大道3039号邮政信箱12195号，邮编27709-2195
Phone: 919-254-7798 EMail: narten@us.ibm.com
电话：919-254-7798电子邮件：narten@us.ibm.com
Geoff Huston APNIC
杰夫·休斯顿呼吸暂停
EMail: gih@apnic.net
EMail: gih@apnic.net
Rosalea G Roberts Stanford University, Networking Systems P.O. Box 19131 Stanford, CA 94309-9131
罗莎莉亚G罗伯茨斯坦福大学，网络系统，邮政信箱19131，加利福尼亚州斯坦福94309-9131
EMail: lea.roberts@stanford.edu
Phone: +1-650-723-3352
EMail: lea.roberts@stanford.edu
Phone: +1-650-723-3352