Network Working Group G. Van de Velde
Request for Comments: 5375 C. Popoviciu
Category: Informational Cisco Systems
T. Chown
University of Southampton
O. Bonness
C. Hahn
T-Systems Enterprise Services GmbH
December 2008
Network Working Group G. Van de Velde
Request for Comments: 5375 C. Popoviciu
Category: Informational Cisco Systems
T. Chown
University of Southampton
O. Bonness
C. Hahn
T-Systems Enterprise Services GmbH
December 2008
IPv6 Unicast Address Assignment Considerations
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) 2008 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2008 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.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/ 许可证信息）在本文件发布之日生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
Abstract
摘要
One fundamental aspect of any IP communications infrastructure is its addressing plan. With its new address architecture and allocation policies, the introduction of IPv6 into a network means that network designers and operators need to reconsider their existing approaches to network addressing. Lack of guidelines on handling this aspect of network design could slow down the deployment and integration of IPv6. This document aims to provide the information and recommendations relevant to planning the addressing aspects of IPv6 deployments. The document also provides IPv6 addressing case studies for both an enterprise and an ISP network.
IP通信基础设施的一个基本方面是其寻址计划。凭借其新的地址体系结构和分配策略，将IPv6引入网络意味着网络设计者和运营商需要重新考虑其现有的网络寻址方法。缺乏处理网络设计这一方面的指南可能会减慢IPv6的部署和集成。本文档旨在提供与规划IPv6部署的寻址方面相关的信息和建议。该文件还提供了企业和ISP网络的IPv6寻址案例研究。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Network-Level Addressing Design Considerations . . . . . . . . 4
2.1. Globally Unique Addresses . . . . . . . . . . . . . . . . 4
2.2. Unique Local IPv6 Addresses . . . . . . . . . . . . . . . 5
2.3. 6bone Address Space . . . . . . . . . . . . . . . . . . . 6
2.4. Network-Level Design Considerations . . . . . . . . . . . 6
2.4.1. Sizing the Network Allocation . . . . . . . . . . . . 8
2.4.2. Address Space Conservation . . . . . . . . . . . . . . 8
3. Subnet Prefix Considerations . . . . . . . . . . . . . . . . . 8
3.1. Considerations for /64 Prefixes . . . . . . . . . . . . . 10
4. Allocation of the IID of an IPv6 Address . . . . . . . . . . . 10
4.1. Automatic EUI-64 Format Option . . . . . . . . . . . . . . 10
4.2. Using Privacy Extensions . . . . . . . . . . . . . . . . . 10
4.3. Manual/Dynamic Assignment Option . . . . . . . . . . . . . 11
5. Security Considerations . . . . . . . . . . . . . . . . . . . 11
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
7. Informative References . . . . . . . . . . . . . . . . . . . . 12
Appendix A. Case Studies . . . . . . . . . . . . . . . . . . . . 16
A.1. Enterprise Considerations . . . . . . . . . . . . . . . . 16
A.1.1. Obtaining General IPv6 Network Prefixes . . . . . . . 16
A.1.2. Forming an Address (Subnet) Allocation Plan . . . . . 17
A.1.3. Other Considerations . . . . . . . . . . . . . . . . . 18
A.1.4. Node Configuration Considerations . . . . . . . . . . 18
A.2. Service Provider Considerations . . . . . . . . . . . . . 19
A.2.1. Investigation of Objective Requirements for an
IPv6 Addressing Schema of a Service Provider . . . . . 19
A.2.2. Exemplary IPv6 Address Allocation Plan for a
Service Provider . . . . . . . . . . . . . . . . . . . 23
A.2.3. Additional Remarks . . . . . . . . . . . . . . . . . . 28
Appendix B. Considerations for Subnet Prefixes Different than
/64 . . . . . . . . . . . . . . . . . . . . . . . . . 30
B.1. Considerations for Subnet Prefixes Shorter than /64 . . . 30
B.2. Considerations for Subnet Prefixes Longer than /64 . . . . 31
B.2.1. /126 Addresses . . . . . . . . . . . . . . . . . . . . 31
B.2.2. /127 Addresses . . . . . . . . . . . . . . . . . . . . 31
B.2.3. /128 Addresses . . . . . . . . . . . . . . . . . . . . 31
B.2.4. EUI-64 'u' and 'g' Bits . . . . . . . . . . . . . . . 31
B.2.5. Anycast Addresses . . . . . . . . . . . . . . . . . . 32
B.2.6. Addresses Used by Embedded-RP (RFC 3956) . . . . . . . 33
B.2.7. ISATAP Addresses . . . . . . . . . . . . . . . . . . . 34
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Network-Level Addressing Design Considerations . . . . . . . . 4
2.1. Globally Unique Addresses . . . . . . . . . . . . . . . . 4
2.2. Unique Local IPv6 Addresses . . . . . . . . . . . . . . . 5
2.3. 6bone Address Space . . . . . . . . . . . . . . . . . . . 6
2.4. Network-Level Design Considerations . . . . . . . . . . . 6
2.4.1. Sizing the Network Allocation . . . . . . . . . . . . 8
2.4.2. Address Space Conservation . . . . . . . . . . . . . . 8
3. Subnet Prefix Considerations . . . . . . . . . . . . . . . . . 8
3.1. Considerations for /64 Prefixes . . . . . . . . . . . . . 10
4. Allocation of the IID of an IPv6 Address . . . . . . . . . . . 10
4.1. Automatic EUI-64 Format Option . . . . . . . . . . . . . . 10
4.2. Using Privacy Extensions . . . . . . . . . . . . . . . . . 10
4.3. Manual/Dynamic Assignment Option . . . . . . . . . . . . . 11
5. Security Considerations . . . . . . . . . . . . . . . . . . . 11
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
7. Informative References . . . . . . . . . . . . . . . . . . . . 12
Appendix A. Case Studies . . . . . . . . . . . . . . . . . . . . 16
A.1. Enterprise Considerations . . . . . . . . . . . . . . . . 16
A.1.1. Obtaining General IPv6 Network Prefixes . . . . . . . 16
A.1.2. Forming an Address (Subnet) Allocation Plan . . . . . 17
A.1.3. Other Considerations . . . . . . . . . . . . . . . . . 18
A.1.4. Node Configuration Considerations . . . . . . . . . . 18
A.2. Service Provider Considerations . . . . . . . . . . . . . 19
A.2.1. Investigation of Objective Requirements for an
IPv6 Addressing Schema of a Service Provider . . . . . 19
A.2.2. Exemplary IPv6 Address Allocation Plan for a
Service Provider . . . . . . . . . . . . . . . . . . . 23
A.2.3. Additional Remarks . . . . . . . . . . . . . . . . . . 28
Appendix B. Considerations for Subnet Prefixes Different than
/64 . . . . . . . . . . . . . . . . . . . . . . . . . 30
B.1. Considerations for Subnet Prefixes Shorter than /64 . . . 30
B.2. Considerations for Subnet Prefixes Longer than /64 . . . . 31
B.2.1. /126 Addresses . . . . . . . . . . . . . . . . . . . . 31
B.2.2. /127 Addresses . . . . . . . . . . . . . . . . . . . . 31
B.2.3. /128 Addresses . . . . . . . . . . . . . . . . . . . . 31
B.2.4. EUI-64 'u' and 'g' Bits . . . . . . . . . . . . . . . 31
B.2.5. Anycast Addresses . . . . . . . . . . . . . . . . . . 32
B.2.6. Addresses Used by Embedded-RP (RFC 3956) . . . . . . . 33
B.2.7. ISATAP Addresses . . . . . . . . . . . . . . . . . . . 34
The Internet Protocol Version 6 (IPv6) Addressing Architecture [RFC4291] defines three main types of addresses: unicast, anycast, and multicast. This document focuses on unicast addresses, for which there are currently two principal allocated types: Globally Unique Addresses ('globals') [RFC3587] and Unique Local IPv6 Addresses (ULAs) [RFC4193]. In addition, until recently there has been the 'experimental' 6bone address space [RFC3701], though its use has been deprecated since June 2006 [RFC3701].
Internet协议版本6（IPv6）寻址体系结构[RFC4291]定义了三种主要类型的地址：单播、选播和多播。本文档重点介绍单播地址，目前有两种主要分配类型：全局唯一地址（“全局”）[RFC3587]和唯一本地IPv6地址（ULA）[RFC4193]。此外，直到最近，还出现了“实验性”6bone地址空间[RFC3701]，尽管自2006年6月[RFC3701]以来，它的使用已被弃用。
The document covers aspects that should be considered during IPv6 deployment for the design and planning of an addressing scheme for an IPv6 network. The network's IPv6 addressing plan may be for an IPv6- only network, or for a dual-stack infrastructure where some or all devices have addresses in both protocols. These considerations will help an IPv6 network designer to efficiently and prudently assign the IPv6 address space that has been allocated to their organization.
本文档涵盖了在IPv6部署过程中设计和规划IPv6网络寻址方案时应考虑的方面。该网络的IPv6寻址计划可能适用于仅限IPv6的网络，也可能适用于某些或所有设备在两种协议中都有地址的双栈基础设施。这些注意事项将有助于IPv6网络设计者高效、谨慎地分配已分配给其组织的IPv6地址空间。
The address assignment considerations are analyzed separately for the two major components of the IPv6 unicast addresses -- namely, 'Network-Level Addressing' (the allocation of subnets) and the 'interface-id' (the identification of the interface within a subnet). Thus, the document includes a discussion of aspects of address assignment to nodes and interfaces in an IPv6 network. Finally, the document provides two examples of deployed addressing plans in a service provider (ISP) and an enterprise network.
分别分析了IPv6单播地址的两个主要组成部分的地址分配注意事项，即“网络级寻址”（子网的分配）和“接口id”（子网内接口的标识）。因此，本文件包括对IPv6网络中节点和接口的地址分配方面的讨论。最后，本文档提供了在服务提供商（ISP）和企业网络中部署的寻址计划的两个示例。
Parts of this document highlight the differences that an experienced IPv4 network designer should consider when planning an IPv6 deployment, for example:
本文档的部分突出了经验丰富的IPv4网络设计者在规划IPv6部署时应考虑的差异，例如：
o IPv6 devices will more likely be multi-addressed in comparison with their IPv4 counterparts.
o 与IPv4设备相比，IPv6设备更有可能是多地址的。
o The practically unlimited size of an IPv6 subnet (2^64 bits) reduces the requirement to size subnets to device counts for the purposes of (IPv4) address conservation.
o IPv6子网（2^64位）的大小实际上是无限的，因此为了（IPv4）地址保护的目的，减少了将子网的大小设置为设备计数的要求。
o The vastly increased subnet size has implications on the threat of address-based host scanning and other scanning techniques, as discussed in [RFC5157].
o 如[RFC5157]所述，大幅增加的子网大小对基于地址的主机扫描和其他扫描技术的威胁有影响。
We do not discuss here how a site or ISP should proceed with acquiring its globally routable IPv6 address prefix. In each case, the prefix received is either provider assigned (PA) or provider independent (PI).
我们在此不讨论站点或ISP应如何获取其全球可路由IPv6地址前缀。在每种情况下，接收到的前缀要么是提供者分配的（PA），要么是提供者独立的（PI）。
We do not discuss PI policy here. The observations and recommendations of this text are largely independent of the PA or PI nature of the address block being used. At this time, we assume that when an IPv6 network changes provider, typically it will need to undergo a renumbering process, as described in [RFC4192]. A separate document [THINKABOUT] makes recommendations to ease the IPv6 renumbering process.
我们这里不讨论PI政策。本文的观察结果和建议在很大程度上与所使用地址块的PA或PI性质无关。此时，我们假设当IPv6网络更改提供商时，通常需要进行重新编号过程，如[RFC4192]中所述。另一份文件[THINKABOUT]提出了简化IPv6重新编号过程的建议。
This document does not discuss implementation aspects related to the transition from the now obsoleted site-local addresses to ULAs. Some implementations know about site-local addresses even though they are deprecated, and do not know about ULAs even though they represent current specification. As a result, transitioning between these types of addresses may cause difficulties.
本文件不讨论从现已废弃的站点本地地址过渡到ULA的相关实施方面。有些实现知道站点本地地址，即使它们已被弃用，也不知道ULA，即使它们代表当前规范。因此，在这些类型的地址之间转换可能会造成困难。
This section discusses the kind of IPv6 addresses used at the network level for the IPv6 infrastructure. The kind of addresses that can be considered are Globally Unique Addresses and ULAs. We also comment here on the deprecated 6bone address space.
本节讨论IPv6基础架构在网络级别使用的IPv6地址类型。可以考虑的地址类型是全局唯一地址和ULA。这里我们还对不推荐使用的6bone地址空间进行了评论。
The most commonly used unicast addresses will be Globally Unique Addresses ('globals'). No significant considerations are necessary if the organization has an address space assignment and a single prefix is deployed through a single upstream provider.
最常用的单播地址是全局唯一地址（“全局”）。如果组织具有地址空间分配，并且通过单个上游提供程序部署了单个前缀，则无需考虑重大问题。
However, a multihomed site may deploy addresses from two or more service-provider-assigned IPv6 address ranges. Here, the network administrator must have awareness on where and how these ranges are used on the multihomed infrastructure environment. The nature of the usage of multiple prefixes may depend on the reason for multihoming (e.g., resilience failover, load balancing, policy-based routing, or multihoming during an IPv6 renumbering event). IPv6 introduces improved support for multi-addressed hosts through the IPv6 default address selection methods described in RFC 3484 [RFC3484]. A multihomed host may thus have two or more addresses, one per prefix (provider), and select source and destination addresses to use as described in that RFC. However, multihoming also has some operational and administrative burdens besides choosing multiple addresses per interface [RFC4218] [RFC4219].
但是，多址站点可以部署来自两个或多个服务提供商分配的IPv6地址范围的地址。在这里，网络管理员必须了解这些范围在多主机基础架构环境中的使用位置和方式。使用多个前缀的性质可能取决于多宿的原因（例如，弹性故障切换、负载平衡、基于策略的路由或IPv6重新编号事件期间的多宿）。IPv6通过RFC 3484[RFC3484]中描述的IPv6默认地址选择方法，改进了对多寻址主机的支持。因此，多宿主机可能有两个或多个地址，每个前缀一个（提供程序），并按照RFC中的描述选择要使用的源地址和目标地址。然而，除了为每个接口选择多个地址[RFC4218][RFC4219]之外，多主还具有一些操作和管理负担。
ULAs have replaced the originally conceived site-local addresses in the IPv6 addressing architecture, for reasons described in [RFC3879]. ULAs improve on site-locals by offering a high probability of the global uniqueness of the prefix used, which can be beneficial when there is (deliberate or accidental) leakage or when networks are merged. ULAs are akin to the private address space [RFC1918] assigned for IPv4 networks, except that in IPv6 networks we may expect to see ULAs used alongside global addresses, with ULAs used internally and globals used externally. Thus, use of ULAs does not imply use of NAT for IPv6.
由于[RFC3879]中所述的原因，ULAs已经取代了IPv6寻址体系结构中最初设想的站点本地地址。ULA通过提供所用前缀的全局唯一性的高概率来改善现场局部性，这在（故意或意外）泄漏或网络合并时是有益的。ULA类似于为IPv4网络分配的专用地址空间[RFC1918]，但在IPv6网络中，我们可能会看到ULA与全局地址一起使用，ULA在内部使用，全局地址在外部使用。因此，使用ULAs并不意味着将NAT用于IPv6。
The ULA address range allows network administrators to deploy IPv6 addresses on their network without asking for a globally unique registered IPv6 address range. A ULA prefix is 48 bits, i.e., a /48, the same as the currently recommended allocation for a site from the globally routable IPv6 address space [RFC3177].
ULA地址范围允许网络管理员在其网络上部署IPv6地址，而无需要求全局唯一的注册IPv6地址范围。ULA前缀为48位，即A/48，与当前从全局可路由IPv6地址空间为站点推荐的分配相同[RFC3177]。
A site that wishes to use ULAs can have (a) multiple /48 prefixes (e.g., a /44) (b) one /48, or (c) a less-than-/48 prefix (e.g., a /56 or /64). In all of the above cases, the ULAs can be randomly chosen according to the principles specified in [RFC4193]. However, in case (a) the use of randomly chosen ULAs will provide suboptimal aggregation capabilities.
希望使用ULAs的站点可以有（A）多个/48前缀（例如A/44）（b）一个/48，或（c）少于-48前缀（例如A/56或/64）。在上述所有情况下，可根据[RFC4193]中规定的原则随机选择ULA。然而，在案例（a）中，使用随机选择的ULA将提供次优的聚合能力。
ULAs provide the means to deploy a fixed addressing scheme that is not affected by a change in service provider and the corresponding PA global addresses. Internal operation of the network is thus unaffected during renumbering events. Nevertheless, this type of address must be used with caution.
ULA提供了部署固定寻址方案的方法，该方案不受服务提供商和相应PA全局地址变化的影响。因此，在重新编号事件期间，网络的内部操作不受影响。然而，这种类型的地址必须谨慎使用。
A site using ULAs may or may not also deploy global addresses. In an isolated network, ULAs may be deployed on their own. In a connected network that also deploys global addresses, both may be deployed, such that hosts become multi-addressed (one global and one ULA), and the IPv6 default address selection algorithm will pick the appropriate source and destination addresses to use, e.g., ULAs will be selected where both the source and destination hosts have ULAs. Because a ULA and a global site prefix are both /48 length, an administrator can choose to use the same subnetting (and host addressing) plan for both prefixes.
使用ULAs的站点可能也可能不部署全局地址。在隔离网络中，可以自行部署ULA。在也部署全局地址的连接网络中，可以部署这两个地址，以便主机成为多地址（一个全局地址和一个ULA），IPv6默认地址选择算法将选择要使用的适当源地址和目标地址，例如，如果源主机和目标主机都有ULA，则将选择ULA。由于ULA和全局站点前缀都是/48长度，管理员可以选择对这两个前缀使用相同的子网（和主机寻址）计划。
As an example of the problems ULAs may cause, when using IPv6 multicast within the network, the IPv6 default address selection algorithm prefers the ULA as the source address for the IPv6 multicast streams. This is NOT a valid option when sending an IPv6 multicast stream to the IPv6 Internet for two reasons. For one,
作为ULAs可能导致的问题的一个示例，当在网络内使用IPv6多播时，IPv6默认地址选择算法首选ULA作为IPv6多播流的源地址。在将IPv6多播流发送到IPv6 Internet时，此选项无效，原因有二。首先，
these addresses are not globally routable, so Reverse Path Forwarding checks for such traffic will fail outside the internal network. The other reason is that the traffic will likely not cross the network boundary due to multicast domain control and perimeter security policies.
这些地址不是全局可路由的，因此对此类流量的反向路径转发检查将在内部网络之外失败。另一个原因是，由于多播域控制和外围安全策略，流量可能不会跨越网络边界。
In principle, ULAs allow easier network mergers than RFC 1918 addresses do for IPv4 because ULA prefixes have a high probability of uniqueness, if the prefix is chosen as described in the RFC.
原则上，ULA允许比RFC 1918地址更容易的网络合并，因为如果按照RFC中的描述选择前缀，ULA前缀具有很高的唯一性概率。
The 6bone address space was used before the Regional Internet Registries (RIRs) started to distribute 'production' IPv6 prefixes. The 6bone prefixes have a common first 16 bits in the IPv6 Prefix of 3FFE::/16. This address range has been deprecated as of 6 June 2006 [RFC3701] and must not be used on any new IPv6 network deployments. Sites using 6bone address space should renumber to production address space using procedures as defined in [RFC4192].
6bone地址空间是在区域互联网注册中心（RIR）开始分发“生产”IPv6前缀之前使用的。6bone前缀在IPv6前缀3FFE:：/16中有一个公共的前16位。自2006年6月6日[RFC3701]起，此地址范围已被弃用，不得用于任何新的IPv6网络部署。使用6bone地址空间的站点应使用[RFC4192]中定义的程序重新编号为生产地址空间。
IPv6 provides network administrators with a significantly larger address space, enabling them to be very creative in how they can define logical and practical addressing plans. The subnetting of assigned prefixes can be done based on various logical schemes that involve factors such as:
IPv6为网络管理员提供了更大的地址空间，使他们能够非常有创造性地定义逻辑和实用的寻址计划。指定前缀的子网化可以基于各种逻辑方案完成，这些方案涉及以下因素：
o Using existing systems
o 使用现有系统
* translate the existing subnet numbers into IPv6 subnet IDs
* 将现有子网编号转换为IPv6子网ID
* translate the VLAN IDs into IPv6 subnet IDs
* 将VLAN ID转换为IPv6子网ID
o Redesign
o 重新设计
* allocate according to your need
* 根据你的需要分配
o Aggregation
o 聚集
* Geographical Boundaries - by assigning a common prefix to all subnets within a geographical area.
* 地理边界-为地理区域内的所有子网指定一个公共前缀。
* Organizational Boundaries - by assigning a common prefix to an entire organization or group within a corporate infrastructure.
* 组织边界-通过为公司基础架构中的整个组织或组分配公共前缀。
* Service Type - by reserving certain prefixes for predefined services such as: VoIP, content distribution, wireless services, Internet access, security areas, etc. This type of addressing may create dependencies on IP addresses that can make renumbering harder if the nodes or interfaces supporting those services on the network are sparse within the topology.
* 服务类型-通过为预定义服务保留某些前缀，例如：VoIP、内容分发、无线服务、Internet访问、安全区域、，等。如果网络上支持这些服务的节点或接口在拓扑中是稀疏的，这种类型的寻址可能会创建对IP地址的依赖，从而使重新编号变得更加困难。
Such logical addressing plans have the potential to simplify network operations and service offerings, and to simplify network management and troubleshooting. A very large network would not need to consider using private address space for its infrastructure devices, thereby simplifying network management.
这种逻辑寻址计划有可能简化网络操作和服务，并简化网络管理和故障排除。一个非常大的网络不需要考虑为其基础设施设备使用私有地址空间，从而简化了网络管理。
The network designer must however keep in mind several factors when developing these new addressing schemes for networks with and without global connectivity:
然而，在为具有和不具有全局连接的网络开发这些新的寻址方案时，网络设计者必须牢记以下几个因素：
o Prefix aggregation - The larger IPv6 addresses can lead to larger routing tables unless network designers are actively pursuing aggregation. While prefix aggregation will be enforced by the service provider, it is beneficial for the individual organizations to observe the same principles in their network design process.
o 前缀聚合-较大的IPv6地址可能导致较大的路由表，除非网络设计者积极追求聚合。虽然前缀聚合将由服务提供商强制执行，但在其网络设计过程中遵守相同的原则对各个组织来说是有益的。
o Network growth - The allocation mechanism for flexible growth of a network prefix, documented in RFC 3531 [RFC3531] can be used to allow the network infrastructure to grow and be numbered in a way that is likely to preserve aggregation (the plan leaves 'holes' for growth).
o 网络增长-RFC 3531[RFC3531]中记录的网络前缀灵活增长的分配机制可用于允许网络基础设施以可能保持聚合的方式增长和编号（该计划为增长留下了“漏洞”）。
o ULA usage in large networks - Networks that have a large number of 'sites' that each deploy a ULA prefix that will by default be a 'random' /48 under fc00::/7 will have no aggregation of those prefixes. Thus, the end result may be cumbersome because the network will have large amounts of non-aggregated ULA prefixes. However, there is no rule to disallow large networks from using a single ULA prefix for all 'sites', as a ULA still provides 16 bits for subnetting to be used internally.
o 大型网络中的ULA使用情况-具有大量“站点”的网络，每个站点部署一个默认为“随机”的ULA前缀/48，在fc00:：/7下，这些前缀没有聚合。因此，最终结果可能很麻烦，因为网络将有大量非聚合前缀。然而，没有规则禁止大型网络对所有“站点”使用单一的ULA前缀，因为ULA仍然为内部使用的子网提供16位。
o Compact numbering of small sites - It is possible that as registry policies evolve, a small site may experience an increase in prefix length when renumbering, e.g., from /48 to /56. For this reason, the best practice is to number subnets compactly rather than sparsely, and to use low-order bits as much as possible when numbering subnets. In other words, even if a /48 is allocated, act as though only a /56 is available. Clearly, this advice does not apply to large sites and enterprises that have an intrinsic need for a /48 prefix.
o 小型站点的紧凑编号-随着注册表策略的发展，小型站点在重新编号时可能会经历前缀长度的增加，例如从/48到/56。因此，最佳做法是对子网进行紧凑编号，而不是稀疏编号，并在对子网进行编号时尽可能多地使用低阶位。换句话说，即使分配了a/48，也要像只有a/56可用一样行事。显然，这一建议不适用于内在需要a/48前缀的大型站点和企业。
o Consider assigning more than one /64 to a site - A small site may want to enable routing amongst interfaces connected to a gateway device. For example, a residential gateway that receives a /48 and is situated in a home with multiple LANs of different media types (sensor network, wired, Wi-Fi, etc.), or has a need for traffic segmentation (home, work, kids, etc.), could benefit greatly from multiple subnets and routing in IPv6. Ideally, residential networks would be given an address range of a /48 or /56 [RIPE_Nov07] such that multiple /64 subnets could be used within the residence.
o 考虑将多于一个/ 64分配给一个站点——一个小站点可能希望在连接到网关设备的接口之间启用路由。例如，接收a/48并位于具有不同媒体类型（传感器网络、有线、Wi-Fi等）的多个LAN的家庭中，或需要流量分段（家庭、工作、孩子等）的家庭网关可以从IPv6中的多个子网和路由中获得极大的好处。理想情况下，住宅网络的地址范围应为a/48或a/56[2007年11月11日]，以便住宅内可以使用多个/64子网。
We do not discuss here how a network designer sizes their application for address space. By default, a site will receive a /48 prefix [RFC3177]; however, different RIR service regions policies may suggest alternative default assignments or let the ISPs decide on what they believe is more appropriate for their specific case (see Section 6.5.4, "Assignments from LIRs/ISPs", of [ARIN]). The default provider allocation via the RIRs is currently a /32 [RIPE_Nov07]. These allocations are indicators for a first allocation for a network. Different sizes may be obtained based on the anticipated address usage [RIPE_Nov07]. At the time of writing, there are examples of allocations as large as /19 having been made from RIRs to providers.
这里我们不讨论网络设计师如何根据地址空间调整其应用程序的大小。默认情况下，站点将接收/48前缀[RFC3177]；然而，不同的RIR服务区域政策可能会建议替代默认分配，或让ISP决定他们认为更适合其具体情况的分配（见[ARIN]第6.5.4节“LIR/ISP的分配”）。通过RIRs的默认提供者分配目前为a/32[2007年11月11日]。这些分配是网络第一次分配的指标。根据预期的地址使用情况，可以获得不同的大小[2007年11月11日]。在撰写本文时，有一些例子表明，RIR向供应商进行了多达/19的分配。
Despite the large IPv6 address space, which enables easier subnetting, it still is important to ensure an efficient use of this resource. Some addressing schemes, while facilitating aggregation and management, could lead to significant numbers of addresses being unused. Address conservation requirements are less stringent in IPv6, but they should still be observed.
尽管IPv6地址空间很大，这使得子网更容易实现，但确保有效使用此资源仍然很重要。一些寻址方案在促进聚合和管理的同时，可能导致大量地址未使用。IPv6中的地址保护要求不那么严格，但仍应遵守。
The proposed Host-Density (HD) value [RFC3194] for IPv6 is 0.94 compared to the current value of 0.96 for IPv4. Note that with IPv6, HD is calculated for sites (e.g., on a basis of /56), instead of for addresses as with IPv4.
IPv6的建议主机密度（HD）值[RFC3194]为0.94，而IPv4的当前值为0.96。请注意，对于IPv6，HD是针对站点计算的（例如，基于/56），而不是针对IPv4的地址。
An important part of an IPv4 addressing plan is deciding the length of each subnet prefix. Unlike in IPv4, the IPv6 addressing architecture [RFC4291] specifies that all subnets using Globally Unique Addresses and ULAs always have the same prefix length of 64 bits. (This also applies to the deprecated 6bone and site-local addresses.)
IPv4寻址计划的一个重要部分是确定每个子网前缀的长度。与IPv4不同，IPv6寻址体系结构[RFC4291]指定使用全局唯一地址和ULA的所有子网始终具有相同的64位前缀长度。（这也适用于不推荐使用的6bone和站点本地地址。）
The only exception to this rule are special addresses starting with the binary value 000, such as IPv4-compatible IPv6 addresses. These exceptions are largely beyond the scope of this document.
此规则的唯一例外是以二进制值000开头的特殊地址，例如与IPv4兼容的IPv6地址。这些例外情况在很大程度上超出了本文件的范围。
Using a subnet prefix length other than a /64 will break many features of IPv6, including Neighbor Discovery (ND), Secure Neighbor Discovery (SEND) [RFC3971], privacy extensions [RFC4941], parts of Mobile IPv6 [RFC4866], Protocol Independent Multicast - Sparse Mode (PIM-SM) with Embedded-RP [RFC3956], and Site Multihoming by IPv6 Intermediation (SHIM6) [SHIM6], among others. A number of other features currently in development, or being proposed, also rely on /64 subnet prefixes.
使用除a/64以外的子网前缀长度将破坏IPv6的许多功能，包括邻居发现（ND）、安全邻居发现（SEND）[RFC3971]、隐私扩展[RFC4941]、移动IPv6的部分[RFC4866]、带有嵌入式RP[RFC3956]的协议独立多播稀疏模式（PIM-SM）以及通过IPv6中介实现的站点多主（SHIM6）[SHIM6]等。目前正在开发或正在提出的许多其他功能也依赖于/64子网前缀。
Nevertheless, many IPv6 implementations do not prevent the administrator from configuring a subnet prefix length shorter or longer than 64 bits. Using subnet prefixes shorter than /64 would rarely be useful; see Appendix B.1 for discussion.
然而，许多IPv6实施并不阻止管理员配置长度小于或大于64位的子网前缀。使用小于/64的子网前缀很少有用；有关讨论，请参见附录B.1。
However, some network administrators have used prefixes longer than /64 for links connecting routers, usually just two routers on a point-to-point link. On links where all the addresses are assigned by manual configuration, and all nodes on the link are routers (not end hosts) that are known by the network, administrators do not need any of the IPv6 features that rely on /64 subnet prefixes, this can work. Using subnet prefixes longer than /64 is not recommended for general use, and using them for links containing end hosts would be an especially bad idea, as it is difficult to predict what IPv6 features the hosts will use in the future.
然而，一些网络管理员在连接路由器的链路上使用了长于/64的前缀，通常一个点到点链路上只有两个路由器。在所有地址都通过手动配置分配的链路上，并且链路上的所有节点都是网络已知的路由器（而不是终端主机），管理员不需要任何依赖/64子网前缀的IPv6功能，这可以工作。一般情况下，不建议使用长于/64的子网前缀，而将它们用于包含终端主机的链路将是一个特别糟糕的主意，因为很难预测主机将来将使用哪些IPv6功能。
Appendix B.2 describes some practical considerations that need to be taken into account when using prefixes longer than /64 in limited cases. In particular, a number of IPv6 features use interface identifiers that have a special form (such as a certain fixed value in some bit positions). When using prefixes longer than /64, it is prudent to avoid certain subnet prefix values so that nodes who assume that the prefix is /64 will not incorrectly identify the addresses in that subnet as having a special form. Appendix B.2 describes the subnet prefix values that are currently believed to be potentially problematic; however, the list is not exhaustive and can be expected to grow in the future.
附录B.2描述了在有限情况下使用长度超过/64的前缀时需要考虑的一些实际注意事项。特别是，许多IPv6功能使用具有特殊形式的接口标识符（例如某些位位置中的某个固定值）。当使用长于/64的前缀时，谨慎的做法是避免使用某些子网前缀值，以便假定前缀为/64的节点不会错误地将该子网中的地址标识为具有特殊形式。附录B.2描述了目前认为存在潜在问题的子网前缀值；然而，这份清单并非详尽无遗，预计今后还会增加。
Using /64 subnets is strongly recommended, also for links connecting only routers. A deployment compliant with the current IPv6 specifications cannot use other prefix lengths. However, the V6OPS WG believes that despite the drawbacks (and a potentially expensive network redesign, if IPv6 features relying on /64 subnets are needed in the future), some networks administrators will use prefixes longer than /64.
强烈建议使用/64子网，也适用于仅连接路由器的链路。符合当前IPv6规范的部署不能使用其他前缀长度。然而，V6OPS工作组认为，尽管存在这些缺点（而且如果将来需要依赖/64子网的IPv6功能，重新设计网络可能会很昂贵），但一些网络管理员将使用长于/64的前缀。
Based on RFC 3177 [RFC3177], 64 bits is the prescribed subnet prefix length to allocate to interfaces and nodes.
基于RFC 3177[RFC3177]，64位是指定的子网前缀长度，用于分配给接口和节点。
When using a /64 subnet length, the address assignment for these addresses can be made either by manual configuration, by a Dynamic Host Configuration Protocol [RFC3315], by stateless autoconfiguration [RFC4862], or by a combination thereof [RFC3736].
当使用/64子网长度时，这些地址的地址分配可以通过手动配置、动态主机配置协议[RFC3315]、无状态自动配置[RFC4862]或其组合[RFC3736]进行。
Note that RFC 3177 strongly prescribes 64-bit subnets for general usage, and that stateless autoconfiguration on most link layers (including Ethernet) is only defined for 64-bit subnets. While in theory it might be possible that some future autoconfiguration mechanisms would allow longer than 64-bit prefix lengths to be used, the use of such prefixes is not recommended at this time.
请注意，RFC 3177强烈规定了64位子网的一般用途，并且大多数链路层（包括以太网）上的无状态自动配置仅为64位子网定义。虽然从理论上讲，未来的一些自动配置机制可能允许使用长度超过64位的前缀，但目前不建议使用此类前缀。
In order to have a complete IPv6 address, an interface must be associated with a prefix and an Interface Identifier (IID). Section 3 of this document analyzed the prefix selection considerations. This section discusses the elements that should be considered when assigning the IID portion of the IPv6 address.
为了拥有完整的IPv6地址，接口必须与前缀和接口标识符（IID）相关联。本文件第3节分析了前缀选择注意事项。本节讨论在分配IPv6地址的IID部分时应考虑的元素。
There are various ways to allocate an IPv6 address to a device or interface. The option with the least amount of caveats for the network administrator is that of EUI-64 [RFC4862] based addresses. For the manual or dynamic options, the overlap with well-known IPv6 addresses should be avoided.
有多种方法可以将IPv6地址分配给设备或接口。对网络管理员来说，警告最少的选项是基于EUI-64[RFC4862]的地址。对于手动或动态选项，应避免与已知IPv6地址重叠。
When using this method, the network administrator has to allocate a valid 64-bit subnet prefix. Once that allocation has been made, the EUI-64 [RFC4862] allocation procedure can assign the remaining 64 IID bits in a stateless manner. All the considerations for selecting a valid IID have been incorporated into the EUI-64 methodology.
使用此方法时，网络管理员必须分配有效的64位子网前缀。一旦分配完成，EUI-64[RFC4862]分配程序可以无状态方式分配剩余的64个IID位。EUI-64方法中包含了选择有效IID的所有考虑因素。
The main purpose of IIDs generated based on RFC 4941 [RFC4941] is to provide privacy to the entity using an IPv6 address. While there are no particular constraints in the usage of IPv6 addresses with IIDs as defined in [RFC4941], there are some implications to be aware of when using privacy addresses as documented in Section 4 of RFC 4941 [RFC4941]
基于RFC 4941[RFC4941]生成的IID的主要目的是为使用IPv6地址的实体提供隐私。虽然[RFC4941]中定义的IPv6地址与IID的使用没有特殊限制，但在使用RFC 4941[RFC4941]第4节中记录的隐私地址时，有一些含义需要注意
This section discusses those IID allocations that are not implemented through stateless address configuration (Section 4.1). They are applicable regardless of the prefix length used on the link. It is out of scope for this section to discuss the various assignment methods (e.g., manual configuration, DHCPv6, etc).
本节讨论未通过无状态地址配置实现的IID分配（第4.1节）。无论链接上使用的前缀长度如何，它们都适用。本节不讨论各种分配方法（例如，手动配置、DHCPv6等）。
In this situation, the actual allocation is done by human intervention, and consideration needs to be given to the complete IPv6 address so that it does not result in overlaps with any of the well-known IPv6 addresses:
在这种情况下，实际分配是通过人工干预完成的，需要考虑完整的IPv6地址，以便不会导致与任何已知IPv6地址重叠：
o Subnet Router Anycast Address (Appendix B.2.5.1)
o 子网路由器选播地址（附录B.2.5.1）
o Reserved Subnet Anycast Address (Appendix B.2.5.2)
o 保留子网选播地址（附录B.2.5.2）
o Addresses used by Embedded-RP (Appendix B.2.6)
o 嵌入式RP使用的地址（附录B.2.6）
o Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) Addresses (Appendix B.2.7)
o 站点内自动隧道寻址协议（ISATAP）地址（附录B.2.7）
When using an address assigned by human intervention, it is recommended to choose IPv6 addresses that are not obvious to guess and/or to avoid any IPv6 addresses that embed IPv4 addresses used in the current infrastructure. Following these two recommendations will make it more difficult for malicious third parties to guess targets for attack, and thus reduce security threats to a certain extent.
使用人工干预分配的地址时，建议选择不易猜测的IPv6地址和/或避免任何嵌入当前基础结构中使用的IPv4地址的IPv6地址。遵循这两条建议将使恶意第三方更难猜测攻击目标，从而在一定程度上减少安全威胁。
This document doesn't add any new security considerations that aren't already outlined in the security considerations of the references.
本文档不添加任何新的安全注意事项，这些注意事项在参考的安全注意事项中没有列出。
It must be noted that using subnet prefixes other than /64 breaks security mechanisms such as Cryptographically Generated Addresses (CGAs) and Hash-Based Addresses (HBAs), and thus makes it impossible to use protocols that depend on them.
必须注意，使用/64以外的子网前缀会破坏安全机制，如加密生成的地址（CGA）和基于哈希的地址（HBA），因此无法使用依赖于它们的协议。
Constructive feedback and contributions have been received during IESG review cycle and from Marla Azinger, Stig Venaas, Pekka Savola, John Spence, Patrick Grossetete, Carlos Garcia Braschi, Brian Carpenter, Mark Smith, Janos Mohacsi, Jim Bound, Fred Templin, Ginny Listman, Salman Assadullah, Krishnan Thirukonda, and the IESG.
在IESG审查周期内，收到了来自玛拉·阿辛格、斯蒂格·维纳斯、佩卡·萨沃拉、约翰·斯彭斯、帕特里克·格罗塞特、卡洛斯·加西亚·布拉斯基、布赖恩·卡彭特、马克·史密斯、雅诺斯·莫哈西、吉姆·邦德、弗雷德·坦普林、金尼·利斯曼、萨尔曼·阿萨杜拉、克里希南·蒂鲁孔达和IESG的建设性反馈和意见。
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.
[RFC1918]Rekhter，Y.，Moskowitz，R.，Karrenberg，D.，Groot，G.，和E.Lear，“私人互联网地址分配”，BCP 5，RFC 1918，1996年2月。
[RFC2526] Johnson, D. and S. Deering, "Reserved IPv6 Subnet Anycast Addresses", RFC 2526, March 1999.
[RFC2526]Johnson，D.和S.Deering，“保留的IPv6子网选播地址”，RFC 25261999年3月。
[RFC3021] Retana, A., White, R., Fuller, V., and D. McPherson, "Using 31-Bit Prefixes on IPv4 Point-to-Point Links", RFC 3021, December 2000.
[RFC3021]Retana，A.，White，R.，Fuller，V.，和D.McPherson，“在IPv4点到点链路上使用31位前缀”，RFC 30212000年12月。
[RFC3053] Durand, A., Fasano, P., Guardini, I., and D. Lento, "IPv6 Tunnel Broker", RFC 3053, January 2001.
[RFC3053]Durand，A.，Fasano，P.，Guardini，I.，和D.Lento，“IPv6隧道代理”，RFC 3053，2001年1月。
[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月。
[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月。
[RFC3180] Meyer, D. and P. Lothberg, "GLOP Addressing in 233/8", BCP 53, RFC 3180, September 2001.
[RFC3180]Meyer，D.和P.Lothberg，“233/8中的GLOP寻址”，BCP 53，RFC 31802001年9月。
[RFC3194] Durand, A. and C. Huitema, "The H-Density Ratio for Address Assignment Efficiency An Update on the H ratio", RFC 3194, November 2001.
[RFC3194]Durand，A.和C.Huitema，“地址分配效率的H密度比——H比率的更新”，RFC 31942001年11月。
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3315]Droms，R.，Bound，J.，Volz，B.，Lemon，T.，Perkins，C.，和M.Carney，“IPv6的动态主机配置协议（DHCPv6）”，RFC3315，2003年7月。
[RFC3484] Draves, R., "Default Address Selection for Internet Protocol version 6 (IPv6)", RFC 3484, February 2003.
[RFC3484]Draves，R.，“互联网协议版本6（IPv6）的默认地址选择”，RFC 3484，2003年2月。
[RFC3531] Blanchet, M., "A Flexible Method for Managing the Assignment of Bits of an IPv6 Address Block", RFC 3531, April 2003.
[RFC3531]Blanchet，M.“管理IPv6地址块位分配的灵活方法”，RFC 3531，2003年4月。
[RFC3587] Hinden, R., Deering, S., and E. Nordmark, "IPv6 Global Unicast Address Format", RFC 3587, August 2003.
[RFC3587]Hinden，R.，Deering，S.，和E.Nordmark，“IPv6全球单播地址格式”，RFC 3587，2003年8月。
[RFC3627] Savola, P., "Use of /127 Prefix Length Between Routers Considered Harmful", RFC 3627, September 2003.
[RFC3627]Savola，P.，“在路由器之间使用/127前缀长度被认为是有害的”，RFC 3627，2003年9月。
[RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6", RFC 3633, December 2003.
[RFC3633]Troan，O.和R.Droms，“动态主机配置协议（DHCP）版本6的IPv6前缀选项”，RFC 3633，2003年12月。
[RFC3701] Fink, R. and R. Hinden, "6bone (IPv6 Testing Address Allocation) Phaseout", RFC 3701, March 2004.
[RFC3701]Fink，R.和R.Hinden，“6bone（IPv6测试地址分配）逐步淘汰”，RFC 37012004年3月。
[RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol (DHCP) Service for IPv6", RFC 3736, April 2004.
[RFC3736]Droms，R.，“IPv6的无状态动态主机配置协议（DHCP）服务”，RFC 3736，2004年4月。
[RFC3879] Huitema, C. and B. Carpenter, "Deprecating Site Local Addresses", RFC 3879, September 2004.
[RFC3879]Huitema，C.和B.Carpenter，“不推荐现场本地地址”，RFC 3879，2004年9月。
[RFC3956] Savola, P. and B. Haberman, "Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast Address", RFC 3956, November 2004.
[RFC3956]Savola，P.和B.Haberman，“将集合点（RP）地址嵌入IPv6多播地址”，RFC 3956，2004年11月。
[RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005.
[RFC3971]Arkko，J.，Kempf，J.，Zill，B.，和P.Nikander，“安全邻居发现（SEND）”，RFC 39712005年3月。
[RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for Renumbering an IPv6 Network without a Flag Day", RFC 4192, September 2005.
[RFC4192]Baker，F.，Lear，E.，和R.Droms，“在没有国旗日的情况下对IPv6网络重新编号的程序”，RFC 41922005年9月。
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, October 2005.
[RFC4193]Hinden，R.和B.Haberman，“唯一本地IPv6单播地址”，RFC 41932005年10月。
[RFC4218] Nordmark, E. and T. Li, "Threats Relating to IPv6 Multihoming Solutions", RFC 4218, October 2005.
[RFC4218]Nordmark，E.和T.Li，“与IPv6多宿主解决方案相关的威胁”，RFC 4218，2005年10月。
[RFC4219] Lear, E., "Things Multihoming in IPv6 (MULTI6) Developers Should Think About", RFC 4219, October 2005.
[RFC4219]Lear，E.“IPv6（MULTI6）中的多宿主开发人员应该考虑的事情”，RFC 4219，2005年10月。
[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006.
[RFC4271]Rekhter，Y.，Li，T.，和S.Hares，“边境网关协议4（BGP-4）”，RFC 42712006年1月。
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.
[RFC4291]Hinden，R.和S.Deering，“IP版本6寻址体系结构”，RFC 42912006年2月。
[RFC4477] Chown, T., Venaas, S., and C. Strauf, "Dynamic Host Configuration Protocol (DHCP): IPv4 and IPv6 Dual-Stack Issues", RFC 4477, May 2006.
[RFC4477]Chown，T.，Venaas，S.，和C.Strauf，“动态主机配置协议（DHCP）：IPv4和IPv6双栈问题”，RFC 4477，2006年5月。
[RFC4798] De Clercq, J., Ooms, D., Prevost, S., and F. Le Faucheur, "Connecting IPv6 Islands over IPv4 MPLS Using IPv6 Provider Edge Routers (6PE)", RFC 4798, February 2007.
[RFC4798]De Clercq，J.，Ooms，D.，Prevost，S.，和F.Le Faucheur，“使用IPv6提供商边缘路由器（6PE）通过IPv4 MPLS连接IPv6孤岛”，RFC 4798，2007年2月。
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, September 2007.
[RFC4862]Thomson，S.，Narten，T.，和T.Jinmei，“IPv6无状态地址自动配置”，RFC 48622007年9月。
[RFC4866] Arkko, J., Vogt, C., and W. Haddad, "Enhanced Route Optimization for Mobile IPv6", RFC 4866, May 2007.
[RFC4866]Arkko，J.，Vogt，C.，和W.Haddad，“移动IPv6的增强路由优化”，RFC 4866，2007年5月。
[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 4941, September 2007.
[RFC4941]Narten，T.，Draves，R.，和S.Krishnan，“IPv6中无状态地址自动配置的隐私扩展”，RFC 49412007年9月。
[RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, March 2008.
[RFC5214]Templin，F.，Gleeson，T.，和D.Thaler，“站点内自动隧道寻址协议（ISATAP）”，RFC 52142008年3月。
[RFC5157] Chown, T., "IPv6 Implications for Network Scanning", RFC 5157, March 2008.
[RFC5157]Chown，T.，“IPv6对网络扫描的影响”，RFC 5157，2008年3月。
[SHIM6] IETF, "Site Multihoming by IPv6 Intermediation (shim6) Charter", <http://www.ietf.org/html.charters/ shim6-charter.html>.
[SHIM6]IETF，“通过IPv6中介实现站点多主（SHIM6）宪章”<http://www.ietf.org/html.charters/ shim6 charter.html>。
[ARIN] ARIN, "ARIN Number Resource Policy Manual", Version 2008.4, September 2008, <http://www.arin.net/policy/nrpm.html>.
[ARIN]ARIN，“ARIN编号资源政策手册”，2008.4版，2008年9月<http://www.arin.net/policy/nrpm.html>.
[RIPE_Nov07] APNIC, ARIN, RIPE NCC, "IPv6 Address Allocation and Assignment Policy", ripe-421, November 2007, <http://www.ripe.net/ripe/docs/ipv6policy.html>.
[RIME_Nov07]APNIC，ARIN，RIME NCC，“IPv6地址分配和分配策略”，RIME-4212007年11月<http://www.ripe.net/ripe/docs/ipv6policy.html>.
[RIPE_Jul07] APNIC, ARIN, RIPE NCC, "IPv6 Address Allocation and Assignment Policy", ripe-412, July 2007, <http://www.ripe.net/ripe/docs/ripe-412.html>.
[RIME_Jul07]APNIC，ARIN，RIME NCC，“IPv6地址分配和分配策略”，RIME-4122007年7月<http://www.ripe.net/ripe/docs/ripe-412.html>.
[APNIC_IPv6] APNIC, "IPv6 Address Allocation and Assignment Policy", APNIC-089, August 2008, <http:// www.apnic.net/policy/ipv6-address-policy.html>.
[APNIC_IPv6]APNIC，“IPv6地址分配和分配策略”，APNIC-0892008年8月，<http://www.APNIC.net/Policy/IPv6 Address Policy.html>。
[LACNIC_IPv6] LACNIC, "Internet Resource Management Policies in Latin America and the Caribbean: IPv6 Address Allocation and Assignment Policy", <http://lacnic.net/en/politicas/ipv6.html>.
[LACNIC_IPv6]LACNIC，“拉丁美洲和加勒比地区的互联网资源管理政策：IPv6地址分配和分配政策”<http://lacnic.net/en/politicas/ipv6.html>.
[AFRINIC_IPv6] AfriNIC, "AfriNIC IPv6 Address Allocation and Assignment Policy", March 2004, <http://www.afrinic.net/docs/policies/ afpol-v6200407-000.htm>.
[AFRINIC_IPv6]AFRINIC，“AFRINIC IPv6地址分配和分配策略”，2004年3月<http://www.afrinic.net/docs/policies/ afpol-v6200407-000.htm>。
[THINKABOUT] Chown, T., Thompson, M., Ford, A., and S. Venaas, "Things to think about when Renumbering an IPv6 network", Work in Progress, March 2007.
[Thinkout]Chown，T.，Thompson，M.，Ford，A.，和S.Venaas，“重新编号IPv6网络时需要考虑的事情”，正在进行的工作，2007年3月。
This appendix contains two case studies for IPv6 addressing schemas that have been based on the statements and considerations of this document. These case studies illustrate how this document has been used in two specific network scenarios. The case studies may serve as basic considerations for an administrator who designs the IPv6 addressing schema for an enterprise or ISP network, but are not intended to serve as a general design proposal for every kind of IPv6 network. All subnet sizes used in this appendix are for practical visualization and do not dictate RIR policy.
本附录包含两个IPv6寻址模式的案例研究，这些案例研究基于本文档的陈述和考虑事项。这些案例研究说明了本文档如何在两个特定的网络场景中使用。对于为企业或ISP网络设计IPv6寻址模式的管理员来说，案例研究可以作为基本考虑事项，但并不打算作为每种IPv6网络的通用设计方案。本附录中使用的所有子网大小均用于实际可视化，不规定RIR策略。
In this section, one considers a case study of a campus network that is deploying IPv6 in parallel with existing IPv4 protocols in a dual-stack environment. The specific example is the University of Southampton (UK), focusing on a large department within that network. The deployment currently spans around 1,000 hosts and over 1,500 users.
在本节中，我们将考虑一个校园网的案例研究，该校园网正在双栈环境中与现有IPv4协议并行部署IPv6。具体的例子是南安普敦大学（英国），专注于该网络中的一个大部门。该部署目前跨越约1000台主机和1500多个用户。
In the case of a campus network, the site will typically take its connectivity from its National Research and Education Network (NREN). Southampton connects to JANET, the UK academic network, via its local regional network LeNSE (Learning Network South East). JANET currently has a /32 allocation from RIPE NCC. The current recommended practice is for sites to receive a /48 allocation; on this basis, Southampton has received such a prefix for its own use. The regional network also uses its own allocation from the NREN provider.
在校园网的情况下，该站点通常从其国家研究和教育网络（NREN）获取连接。南安普敦通过其本地区域网络LeNSE（东南学习网络）与英国学术网络JANET相连。JANET目前拥有来自成熟NCC的a/32分配。目前建议的做法是，各站点接受a/48分配；在此基础上，南安普敦已经收到了这样一个前缀供自己使用。区域网络还使用来自NREN提供商的自己的分配。
No ULA addressing is used on site. The campus is not multihomed (JANET is the sole provider), nor does it expect to change service provider, and thus does not plan to use ULAs for the (perceived) benefit of easing network renumbering. Indeed, the campus has renumbered following the aforementioned renumbering procedure [RFC4192] on two occasions, and this has proven adequate (with provisos documented in [THINKABOUT]). The campus does not see any need to deploy ULAs for in-band or out-of-band network management; there are enough IPv6 prefixes available in the site allocation for the infrastructure. In some cases, use of private IP address space in IPv4 creates problems, so University of Southampton believes that the availability of ample global IPv6 address space for infrastructure may be a benefit for many sites.
现场未使用ULA地址。校园不是多址的（JANET是唯一的提供商），也不希望改变服务提供商，因此不打算使用ULAs来（感知）简化网络重新编号的好处。事实上，校园已经按照上述重新编号程序[RFC4192]进行了两次重新编号，这已经证明是足够的（附带[THINKABOUT]中记录的但书）。校园不需要部署用于带内或带外网络管理的ULA；基础架构的站点分配中有足够的IPv6前缀可用。在某些情况下，使用IPv4中的私有IP地址空间会产生问题，因此南安普敦大学认为，为基础设施提供足够的全局IPv6地址空间可能对许多站点有益。
No 6bone addressing is used on site any more. Since the 6bone phaseout of June 2006 [RFC3701], most transit ISPs have begun filtering attempted use of such prefixes.
现场不再使用6bone地址。自2006年6月6bone淘汰[RFC3701]以来，大多数公交ISP已经开始过滤使用此类前缀的尝试。
Southampton does participate in global and organizational scope IPv6 multicast networks. Multicast address allocations are not discussed here as they are not in scope for the document. It is noted that IPv6 has advantages for multicast group address allocation. In IPv4, a site needs to use techniques like GLOP [RFC3180] to pick a globally unique multicast group to use. This is problematic if the site does not use the Border Gateway Protocol (BGP) [RFC4271] and does not have an Autonomous System Number (ASN). In IPv6,0 unicast-prefix-based IPv6 multicast addresses empower a site to pick a globally unique group address based on its own unicast site or link prefix. Embedded-RP is also in use, is seen as a potential advantage for IPv6 and multicast, and has been tested successfully across providers between sites (including paths to/from the US and UK).
南安普敦确实参与了全球和组织范围的IPv6多播网络。此处不讨论多播地址分配，因为它们不在文档的范围内。需要注意的是，IPv6对于多播组地址分配具有优势。在IPv4中，站点需要使用GLOP[RFC3180]等技术来选择要使用的全局唯一多播组。如果站点不使用边界网关协议（BGP）[RFC4271]并且没有自治系统号（ASN），则这是有问题的。在IPv6中，0基于单播前缀的IPv6多播地址使站点能够基于其自己的单播站点或链路前缀选择全局唯一的组地址。嵌入式RP也在使用中，被视为IPv6和多播的潜在优势，并已在站点之间的提供商之间成功测试（包括美国和英国之间的路径）。
The campus has a /16 prefix for IPv4 use; in principle, 256 subnets of 256 addresses. In reality, the subnetting is muddier, because of concerns of IPv4 address conservation; subnets are sized to the hosts within them, e.g., a /26 IPv4 prefix is used if a subnet has 35 hosts in it. While this is efficient, it increases management burden when physical deployments change, and IPv4 subnets require resizing (up or down), even when DHCP is in use.
校园具有IPv4使用的/16前缀；原则上，256个地址的256个子网。事实上，由于IPv4地址保护的考虑，子网更加混乱；子网的大小取决于其中的主机，例如，如果子网中有35台主机，则使用/26 IPv4前缀。虽然这是有效的，但当物理部署发生变化时，它会增加管理负担，并且IPv4子网需要调整大小（向上或向下），即使在使用DHCP时也是如此。
The /48 IPv6 prefix is considerably larger than the IPv4 allocation already in place at the site. It is loosely equivalent to a 'Class A' IPv4 prefix in that it has 2^16 (over 65,000) subnets, but has an effectively unlimited subnet address size (2^64) compared to 256 in the IPv4 equivalent. The increased subnet size means that /64 IPv6 prefixes can be used on all subnets, without any requirement to resize them at a later date. The increased subnet volume allows subnets to be allocated more generously to schools and departments in the campus. While address conservation is still important, it is no longer an impediment to network management. Rather, address (subnet) allocation is more about embracing the available address space and planning for future expansion.
/48 IPv6前缀远远大于站点上已经存在的IPv4分配。它大致相当于“a类”IPv4前缀，因为它有2^16（超过65000）个子网，但实际上有一个无限制的子网地址大小（2^64），而IPv4前缀为256。子网大小的增加意味着/64 IPv6前缀可以在所有子网上使用，而无需在以后调整它们的大小。子网容量的增加使得子网可以更慷慨地分配给校园内的学校和部门。虽然地址保护仍然很重要，但它不再是网络管理的障碍。相反，地址（子网）分配更多的是利用可用的地址空间和规划未来的扩展。
In a dual-stack network, it was chosen to deploy the IP subnets congruently for IPv4 and IPv6. This is because the systems are still in the same administrative domains and the same geography. It is not expected to have IPv6-only subnets in production use for a while yet, outside the test beds and some early Mobile IPv6 trials. With congruent addressing, the firewall policies are also aligned for IPv4 and IPv6 traffic at the site border.
在一个双栈网络中，它被选择为IPv4和IPv6一致地部署IP子网。这是因为这些系统仍然位于相同的管理域和相同的地理位置。在测试台和一些早期的移动IPv6试验之外，预计在一段时间内还不会有只使用IPv6的子网投入生产使用。通过一致寻址，防火墙策略也针对站点边界的IPv4和IPv6流量进行了调整。
The subnet allocation plan required a division of the address space per school or department. Here, a /56 was allocated to the school level of the university; there are around 30 schools currently. A /56 of IPv6 address space equates to 256 /64 subnet allocations. Further /56 allocations were made for central IT infrastructure, the network infrastructure, and the server side systems.
子网分配计划要求每个学校或部门分配地址空间。在这里，a/56分配给大学的学校一级；目前大约有30所学校。IPv6地址空间的A/56等于256/64子网分配。对中央IT基础设施、网络基础设施和服务器端系统进行了进一步的/56分配。
The network uses a Demilitarized Zone (DMZ) topology for some level of protection of 'public' systems. Again, this topology is congruent with the IPv4 network.
该网络使用非军事区（DMZ）拓扑对“公共”系统进行某种程度的保护。同样，此拓扑与IPv4网络一致。
There are no specific transition methods deployed internally to the campus; everything is using the conventional dual-stack approach. There is no use of ISATAP [RFC5214] for example.
没有在校园内部部署具体的过渡方法；一切都使用传统的双堆栈方法。例如，ISATAP[RFC5214]没有任何用途。
For the Mobile IPv6 early trials, there is one allocated prefix for Home Agent (HA) use. However, there has been no detailed consideration yet regarding how Mobile IPv6 usage may grow, and whether more subnets (or even every subnet) will require HA support.
对于移动IPv6早期试验，有一个分配的前缀供归属代理（HA）使用。然而，还没有详细考虑移动IPv6的使用可能如何增长，以及是否有更多的子网（甚至每个子网）需要HA支持。
The university operates a tunnel broker [RFC3053] service on behalf of the United Kingdom Education and Research Network Association (UKERNA) for JANET sites. This uses separate address space from JANET, not the university site allocation.
该大学代表英国教育和研究网络协会（UKERNA）为珍妮特网站提供隧道代理[RFC3053]服务。这与JANET使用单独的地址空间，而不是大学站点分配。
Currently, stateless autoconfiguration is used on most subnets for IPv6 hosts. There is no DHCPv6 service deployed yet, beyond tests of early code releases. It is planned to deploy DHCPv6 for address assignment when robust client and server code is available (at the time of writing, the potential for this looks good, e.g., via the Internet Systems Consortium (ISC) implementation). University of Southampton is also investigating a common integrated DHCP/DNS management platform, even if the servers themselves are not co-located, including integrated DHCPv4 and DHCPv6 server configuration, as discussed in [RFC4477]. Currently, clients with statelessly autoconfigured addresses are added to the DNS manually, though dynamic DNS is an option. The network administrators would prefer the use of DHCP because they believe it gives them more management control.
目前，IPv6主机的大多数子网都使用无状态自动配置。除了早期代码版本的测试之外，还没有部署DHCPv6服务。计划在健壮的客户机和服务器代码可用时部署DHCPv6进行地址分配（在撰写本文时，这方面的潜力看起来不错，例如通过Internet Systems Consortium（ISC）实施）。南安普敦大学也正在研究一个通用的集成DHCP/DNS管理平台，即使服务器本身不在同一位置，包括集成的DHCPv4和DHCPv6服务器配置，如[RCF477 ]中所讨论的。目前，具有无状态自动配置地址的客户端被手动添加到DNS，尽管动态DNS是一个选项。网络管理员更倾向于使用DHCP，因为他们认为它可以提供更多的管理控制。
Regarding the implications of the larger IPv6 subnet address space on scanning attacks [RFC5157], it is noted that all the hosts are dual-stack, and thus are potentially exposed over both protocols anyway. All addresses are published in DNS, and the site does not operate a two-faced DNS.
关于较大的IPv6子网地址空间对扫描攻击的影响[RFC5157]，需要注意的是，所有主机都是双栈的，因此无论如何都可能通过这两种协议暴露。所有地址都在DNS中发布，并且该站点不运行双面DNS。
Currently, there is internal usage of RFC 4941 privacy addresses [RFC4941] (certain platforms ship with it on by default), but network administrators may desire to disable this (perhaps via DHCP) to ease management complexity. However, it is desired to determine the feasibility of this on all systems, e.g., for guests on wireless LAN or other user-maintained systems. Network management and monitoring should be simpler without RFC 4941 in operation, in terms of identifying which physical hosts are using which addresses. Note that RFC 4941 is only an issue for outbound connections, and that there is potential to assign privacy addresses via DHCPv6.
目前，内部使用RFC 4941隐私地址[RFC4941]（默认情况下，某些平台随附），但网络管理员可能希望禁用此功能（可能通过DHCP）以减轻管理复杂性。然而，需要确定这在所有系统上的可行性，例如，对于无线LAN或其他用户维护系统上的来宾。在识别哪些物理主机正在使用哪些地址方面，如果没有运行RFC 4941，网络管理和监控应该更简单。请注意，RFC4941只是出站连接的问题，并且有可能通过DHCPv6分配隐私地址。
Manually configured server addresses are used to avoid address changes based upon change of network adaptor. With IPv6 you can pick ::53 for a DNS server, or you can pick 'random' addresses for obfuscation, though that's not an issue for publicly advertised addresses (dns, mx, web, etc.).
手动配置的服务器地址用于避免基于网络适配器的更改而更改地址。使用IPv6，您可以为DNS服务器选择：：53，也可以选择“随机”地址进行模糊处理，但对于公开公布的地址（DNS、mx、web等），这不是一个问题。
In this section an IPv6 addressing schema is sketched that could serve as an example for an Internet Service Provider.
在本节中，将绘制一个IPv6寻址模式，作为Internet服务提供商的示例。
Appendix A.2.1 starts with some thoughts regarding objective requirements of such an addressing schema and derives a few general rules of thumb that have to be kept in mind when designing an ISP IPv6 addressing plan.
附录A.2.1首先介绍了有关此类寻址模式的客观要求的一些想法，并得出了一些在设计ISP IPv6寻址计划时必须牢记的一般经验法则。
Appendix A.2.2 illustrates the findings of Appendix A.2.1 with an exemplary IPv6 addressing schema for an MPLS-based ISP offering Internet services as well as network access services to several millions of customers.
附录A.2.2说明了附录A.2.1的调查结果，其中给出了基于MPLS的ISP的IPv6寻址模式示例，该ISP向数百万客户提供互联网服务和网络访问服务。
A.2.1. Investigation of Objective Requirements for an IPv6 Addressing Schema of a Service Provider
A.2.1. 服务提供商IPv6寻址模式的目标需求调查
The first step of the IPv6 addressing plan design for a service provider should identify all technical, operational, political, and business requirements that have to be satisfied by the services supported by this addressing schema.
服务提供商IPv6寻址计划设计的第一步应确定此寻址模式支持的服务必须满足的所有技术、运营、政治和业务需求。
According to the different technical constraints and business models as well as the different weights of these requirements (from the point of view of the corresponding service provider), it is very likely that different addressing schemas will be developed and deployed by different ISPs. Nevertheless, the addressing schema of Appendix A.2.2 is one possible example.
根据不同的技术约束和业务模型以及这些需求的不同权重（从相应服务提供商的角度来看），不同的ISP很可能会开发和部署不同的寻址模式。然而，附录A.2.2中的寻址模式是一个可能的示例。
For this document, it is assumed that our exemplary ISP has to fulfill several roles for its customers such as:
在本文档中，假设我们的示例性ISP必须为其客户履行多个角色，例如：
o Local Internet Registry
o 本地互联网注册处
o Network Access Provider
o 网络接入提供商
o Internet Service Provider
o 互联网服务提供商
A.2.1.1. Recommendations for an IPv6 Addressing Schema from the LIR Perspective of the Service Provider
A.2.1.1. 从服务提供商的LIR角度对IPv6寻址模式的建议
In its role as Local Internet Registry (LIR), the service provider has to care about the policy constraints of the RIRs and the standards of the IETF regarding IPv6 addressing. In this context, the following basic recommendations have to be considered and should be satisfied by the IPv6 address allocation plan of a service provider:
作为本地互联网注册中心（LIR），服务提供商必须关注RIR的政策约束和IETF关于IPv6寻址的标准。在这种情况下，服务提供商的IPv6地址分配计划必须考虑并满足以下基本建议：
o As recommended in RFC 3177 [RFC3177] and in several RIR policies, "Common" customers sites (normally private customers) should receive a /48 prefix from the aggregate of the service provider. (Note: The addressing plan must be flexible enough and take into account the possible change of the minimum allocation size for end users currently under definition by the RIRs.)
o 根据RFC 3177[RFC3177]和若干RIR政策的建议，“普通”客户站点（通常为私人客户）应从服务提供商的集合中接收/48前缀。（注：寻址计划必须足够灵活，并考虑到RIR目前定义的终端用户最小分配规模的可能变化。）
o "Big customers" (like big enterprises, governmental agencies, etc.) may receive shorter prefixes according to their needs, when their needs can be documented and justified to the RIR.
o “大客户”（如大企业、政府机构等）可能会根据其需求收到较短的前缀，前提是可以记录其需求并向RIR证明其合理性。
o The IPv6 address allocation schema has to be able to meet the HD-ratio that is proposed for IPv6. This requirement corresponds to the demand for an efficient usage of the IPv6 address aggregate by the service provider. (Note: The currently valid IPv6 HD-ratio of 0.94 means an effective usage rate of about 22% of a /20 prefix of the service provider, on the basis of /56 assignments.)
o IPv6地址分配模式必须能够满足针对IPv6提出的HD比率。此要求对应于服务提供商高效使用IPv6地址聚合的要求。（注：当前有效的IPv6 HD比率为0.94意味着根据/56分配，服务提供商的a/20前缀的有效使用率约为22%。）
o All assignments to customers have to be documented and stored into a database that can also be queried by the RIR.
o 所有分配给客户的任务都必须记录并存储到一个数据库中，该数据库也可以由RIR查询。
o The LIR has to make available the means for supporting the reverse DNS mapping of the customer prefixes.
o LIR必须提供支持客户前缀反向DNS映射的方法。
o IPv6 Address Allocation and Assignment Policies can be found at RIRs and are similar in many aspects. See [RIPE_Nov07], [RIPE_Jul07], [APNIC_IPv6], [LACNIC_IPv6], [AFRINIC_IPv6], and Section 6 of [ARIN].
o IPv6地址分配和分配策略可以在RIRs中找到，并且在许多方面类似。参见[2007年11月成熟]、[2007年7月成熟]、[APNIC_IPv6]、[LACNIC_IPv6]、[AFRINIC_IPv6]和[ARIN]第6节。
A.2.1.2. IPv6 Addressing Schema Recommendations from the ISP Perspective of the Service Provider
A.2.1.2. 从服务提供商的ISP角度看IPv6寻址模式建议
From the ISP perspective, the following basic requirements can be identified:
从ISP的角度来看，可以确定以下基本要求：
o The IPv6 address allocation schema must be able to realize a maximal aggregation of all IPv6 address delegations to customers into the address aggregate of the service provider. Only this provider aggregate will be routed and injected into the global routing table (DFZ, "Default-Free Zone"). This strong aggregation keeps the routing tables of the DFZ small and eases filtering and access control very much.
o IPv6地址分配模式必须能够最大限度地将向客户的所有IPv6地址委托聚合到服务提供商的地址聚合中。只有此提供程序聚合将被路由并注入全局路由表（DFZ，“默认自由区”）。这种强大的聚合使DFZ的路由表保持较小，并大大简化了过滤和访问控制。
o The IPv6 addressing schema of the SP should contain optimal flexibility since the infrastructure of the SP will change over time with new customers, transport technologies, and business cases. The requirement of optimal flexibility is contrary to the recommendation of strong IPv6 address aggregation and efficient address usage, but each SP has to decide which of these requirements to prioritize.
o SP的IPv6寻址模式应具有最佳的灵活性，因为SP的基础架构将随着新客户、传输技术和业务案例的变化而变化。最佳灵活性的要求与强烈的IPv6地址聚合和高效的地址使用的建议相反，但每个SP必须决定优先考虑这些要求中的哪一个。
o While keeping the multilevel network hierarchy of an ISP in mind, note that due to addressing efficiency reasons, not all hierarchy levels can and should be mapped into the IPv6 addressing schema of an ISP. Sometimes it is much better to implement a more "flat" addressing for the ISP network than to lose big chunks of the IPv6 address aggregate in addressing each level of network hierarchy. (Note: In special cases, it is even recommended for really "small" ISPs to design and implement a totally flat IPv6 addressing schema without any level of hierarchy.)
o 在牢记ISP的多级网络层次结构的同时，请注意，由于寻址效率的原因，并非所有层次结构级别都可以而且应该映射到ISP的IPv6寻址模式中。有时，为ISP网络实现更“平坦”的寻址比在寻址网络层次结构的每一层时丢失IPv6地址聚合的大块要好得多。（注意：在特殊情况下，甚至建议真正的“小型”ISP设计和实现完全平坦的IPv6寻址模式，而不采用任何层次结构。）
o A decoupling of provider network addressing and customer addressing is recommended. (Note: A strong aggregation (e.g., on POP, Aggregation Router (AG), or Label Edge Router (LER) level) limits the numbers of customer routes that are visible within the ISP network, but also brings down the efficiency of the IPv6 addressing schema. That's why each ISP has to decide how many internal aggregation levels it wants to deploy.)
o 建议将提供商网络寻址和客户寻址分离。（注意：强聚合（例如，在POP、聚合路由器（AG）或标签边缘路由器（LER）级别上）会限制ISP网络中可见的客户路由数量，但也会降低IPv6寻址模式的效率。这就是为什么每个ISP必须决定要部署多少内部聚合级别。）
A.2.1.3. IPv6 Addressing Schema Recommendations from the Network Access Provider Perspective of the Service Provider
A.2.1.3. 从服务提供商的网络访问提供商角度看IPv6寻址模式建议
As already done for the LIR and the ISP roles of the SP it is also necessary to identify requirements that come from its Network Access Provider role. Some of the basic requirements are:
正如已经对SP的LIR和ISP角色所做的那样，还需要确定来自其网络访问提供商角色的要求。其中一些基本要求是：
o The IPv6 addressing schema of the SP, it must be chosen in a way that it can handle new requirements that are triggered from customer side. For instance, this can be the customer's growing needs for IPv6 addresses as well as customer-driven modifications within the access network topology (e.g., when the customer moves from one point of network attachment (POP) to another). (See Appendix A.2.3.4, "Changing the Point of Network Attachment".)
o SP的IPv6寻址模式，其选择方式必须能够处理从客户端触发的新需求。例如，这可能是客户对IPv6地址的日益增长的需求，以及在接入网络拓扑中由客户驱动的修改（例如，当客户从一个网络连接点（POP）移动到另一个时）。（见附录A.2.3.4，“更改网络连接点”。）
o For each IPv6 address assignment to customers, a "buffer zone" should be reserved that allows the customer to grow in its addressing range without renumbering or assignment of additional prefixes.
o 对于向客户分配的每个IPv6地址，应保留一个“缓冲区”，允许客户在其寻址范围内增长，而无需重新编号或分配额外的前缀。
o The IPv6 addressing schema of the SP must deal with multiple attachments of a single customer to the SP network infrastructure (i.e., multihomed network access with the same SP).
o SP的IPv6寻址模式必须处理单个客户到SP网络基础架构的多个附件（即，使用同一SP的多宿网络访问）。
These few requirements are only part of the requirements a service provider has to investigate and keep in mind during the definition phase of its addressing architecture. Each SP will most likely add more constraints to this list.
这几个需求只是服务提供商在其寻址体系结构的定义阶段必须调查和记住的需求的一部分。每个SP很可能会在此列表中添加更多约束。
A.2.1.4. A Few Rules of Thumb for Designing an ISP IPv6 Addressing Architecture
A.2.1.4. 设计ISP IPv6寻址体系结构的几个经验法则
As a result of the above enumeration of requirements regarding an ISP IPv6 addressing plan, the following design "rules of thumb" have been derived:
根据以上列举的有关ISP IPv6寻址计划的要求，得出了以下设计“经验法则”：
o No "One size fits all". Each ISP must develop its own IPv6 address allocation schema depending on its concrete business needs. It is not practical to design one addressing plan that fits for all kinds of ISPs (small / big, routed / MPLS-based, access / transit, LIR / No LIR, etc.).
o 没有“一刀切”。每个ISP必须根据其具体的业务需求开发自己的IPv6地址分配模式。设计一个适合所有类型ISP（小型/大型、基于路由/MPLS、访问/传输、LIR/无LIR等）的寻址方案是不现实的。
o The levels of IPv6 address aggregation within the ISP addressing schema should strongly correspond to the implemented network structure, and their number should be minimized because of efficiency reasons. It is assumed that the SP's own
o ISP寻址模式中的IPv6地址聚合级别应与实现的网络结构紧密对应，并且出于效率原因，应尽量减少其数量。假设SP自己的
infrastructure will be addressed in a fairly flat way, whereas part of the customer addressing architecture should contain several levels of aggregation.
基础架构将以一种相当平坦的方式进行处理，而客户寻址体系结构的一部分应该包含多个聚合级别。
o Keep the number of IPv6 customer routes inside your network as small as possible. A totally flat customer IPv6 addressing architecture without any intermediate aggregation level will lead to lots of customer routes inside the SP network. A fair trade-off between address aggregation levels (and hence the size of the internal routing table of the SP) and address conservation of the addressing architecture has to be found.
o 尽可能减少网络中IPv6客户路由的数量。没有任何中间聚合级别的完全扁平的客户IPv6寻址体系结构将在SP网络中产生大量客户路由。必须在地址聚合级别（以及SP内部路由表的大小）和寻址体系结构的地址保护之间找到一个公平的权衡。
o The ISP IPv6 addressing schema should provide maximal flexibility. This has to be realized for supporting different sizes of customer IPv6 address aggregates ("big" customers vs. "small" customers) as well as to allow future growth rates (e.g., of customer aggregates) and possible topological or infrastructural changes.
o ISP IPv6寻址模式应提供最大的灵活性。必须实现这一点，以支持不同规模的客户IPv6地址聚合（“大”客户与“小”客户），并允许未来的增长率（例如，客户聚合）和可能的拓扑或基础结构变化。
o A limited number of aggregation levels and sizes of customer aggregates will ease the management of the addressing schema. This has to be weighed against the previous "rule of thumb" -- flexibility.
o 数量有限的聚合级别和客户聚合的大小将简化寻址模式的管理。这必须与之前的“经验法则”——灵活性——进行权衡。
In this example, the service provider is assumed to operate an MPLS-based backbone and to implement IPv6 Provider Edge Routers (6PE) [RFC4798] to provide IPv6 backbone transport between the different locations (POPs) of a fully dual-stacked network access and aggregation area.
在此示例中，假定服务提供商操作基于MPLS的主干网，并实现IPv6提供商边缘路由器（6PE）[RFC4798]，以在完全双堆叠网络接入和聚合区域的不同位置（pop）之间提供IPv6主干网传输。
In addition, it is assumed that the service provider:
此外，假定服务提供商：
o has received a /20 from its RIR
o 已从RIR收到a/20
o operates its own LIR
o 运营自己的LIR
o has to address its own IPv6 infrastructure
o 必须解决自己的IPv6基础设施问题
o delegates prefixes from this aggregate to its customers
o 将此聚合的前缀委托给其客户
This addressing schema should illustrate how the /20 IPv6 prefix of the SP can be used to address the SP's own infrastructure and to delegate IPv6 prefixes to its customers, following the above-mentioned requirements and rules of thumb as far as possible.
此寻址模式应说明如何使用SP的/20 IPv6前缀来寻址SP自己的基础架构，并尽可能按照上述要求和经验规则将IPv6前缀委托给其客户。
The figure below summarizes the device types in an SP network and the typical network design of a MPLS-based service provider. The network hierarchy of the SP has to be taken into account for the design of an IPv6 addressing schema; it defines the basic shape of the addressing schema and the various levels of aggregation.
下图总结了SP网络中的设备类型以及基于MPLS的服务提供商的典型网络设计。在设计IPv6寻址模式时，必须考虑SP的网络层次结构；它定义了寻址模式的基本形状和聚合的各个级别。
+------------------------------------------------------------------+
| LSRs of the MPLS Backbone of the SP |
+------------------------------------------------------------------+
| | | | |
| | | | |
+-----+ +-----+ +--------+ +--------+ +--------+
| LER | | LER | | LER-BB | | LER-BB | | LER-BB |
+-----+ +-----+ +--------+ +--------+ +--------+
| | | | | | / | | |
| | | | | | / | | |
| | | | +------+ +------+ +------+ | |
| | | | |BB-RAR| |BB-RAR| | AG | | |
| | | | +------+ +------+ +------+ | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | +-----+ +-----+ +-----+ +-----+
| | | | | | | | | RAR | | RAR | | RAR | | RAR |
| | | | | | | | +-----+ +-----+ +-----+ +-----+
| | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | |
+-------------------------------------------------------------------+
| Customer networks |
+-------------------------------------------------------------------+
+------------------------------------------------------------------+
| LSRs of the MPLS Backbone of the SP |
+------------------------------------------------------------------+
| | | | |
| | | | |
+-----+ +-----+ +--------+ +--------+ +--------+
| LER | | LER | | LER-BB | | LER-BB | | LER-BB |
+-----+ +-----+ +--------+ +--------+ +--------+
| | | | | | / | | |
| | | | | | / | | |
| | | | +------+ +------+ +------+ | |
| | | | |BB-RAR| |BB-RAR| | AG | | |
| | | | +------+ +------+ +------+ | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | +-----+ +-----+ +-----+ +-----+
| | | | | | | | | RAR | | RAR | | RAR | | RAR |
| | | | | | | | +-----+ +-----+ +-----+ +-----+
| | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | |
+-------------------------------------------------------------------+
| Customer networks |
+-------------------------------------------------------------------+
LSR Label Switch Router LER Label Edge Router LER-BB Broadband Label Edge Router RAR Remote Access Router BB-RAR Broadband Remote Access Router AG Aggregation Router
LSR标签交换路由器LER标签边缘路由器LER-BB宽带标签边缘路由器RAR远程访问路由器BB-RAR宽带远程访问路由器AG聚合路由器
Exemplary Service Provider Network
示范性服务提供商网络
The following should be taken into consideration when making the basic design decisions for the exemplary service provider IPv6 addressing plan regarding customer prefixes.
在为示例性服务提供商IPv6寻址计划制定有关客户前缀的基本设计决策时，应考虑以下因素。
o The prefixes assigned to all customers behind the same LER (or LER-BB) are aggregated under one LER prefix. This ensures that the number of labels that have to be used for 6PE is limited and hence provides strong MPLS label conservation.
o 分配给同一LER（或LER-BB）后面的所有客户的前缀聚合在一个LER前缀下。这确保了6PE必须使用的标签数量是有限的，因此提供了强大的MPLS标签保护。
o The /20 prefix of the SP is separated into 3 different pools that are used to allocate IPv6 prefixes to the customers of the SP:
o SP的/20前缀分为3个不同的池，用于将IPv6前缀分配给SP的客户：
1. A pool (e.g., /24) for satisfying the addressing needs of really "big" customers (as defined in Appendix A.2.2.1.1) that need IPv6 prefixes larger than /48 (e.g., /32). These customers are assumed to be connected to several POPs of the access network, so that this customer prefix will be visible in each of these POPs.
1. 一个池（如/24），用于满足需要大于/48（如/32）IPv6前缀的真正“大”客户（如附录A.2.2.1.1所定义）的寻址需求。假设这些客户连接到接入网络的多个POP，因此每个POP中都可以看到该客户前缀。
2. A pool (e.g., /24) for the LERs with direct customer connections (e.g., dedicated line access) and without an additional aggregation area between the customer and the LER. (These LERs are mostly connected to a limited number of customers because of the limited number of interfaces/ports.)
2. 用于LER的池（如/24），具有直接客户连接（如专线接入），且在客户和LER之间没有额外的聚合区域。（由于接口/端口数量有限，这些LER大多连接到数量有限的客户。）
3. A larger pool (e.g., 14*/24) for LERs (or LER-BBs) that serve a high number of customers that are normally connected via some kind of aggregation network (e.g., DSL customers behind a BB-RAR or dial-in customers behind a RAR).
3. 用于LER（或LER BBs）的较大池（例如14*/24），其服务于通常通过某种聚合网络连接的大量客户（例如，BB-RAR后面的DSL客户或RAR后面的拨入客户）。
o The IPv6 address delegation within each pool (the end customer delegation or the aggregates that are dedicated to the LER itself) should be chosen with an additional buffer zone of 100-300% for future growth. That is, 1 or 2 additional prefix bits should be reserved according to the expected future growth rate of the corresponding customer or the corresponding network device aggregate.
o 每个池中的IPv6地址委派（最终客户委派或专用于LER本身的聚合）应选择100-300%的额外缓冲区，以供未来增长。也就是说，应根据相应客户或相应网络设备聚合的预期未来增长率保留1或2个额外前缀位。
A.2.2.1. Defining an IPv6 Address Allocation Plan for Customers of the Service Provider
A.2.2.1. 为服务提供商的客户定义IPv6地址分配计划
The SP's "big" customers receive their prefix from the /24 IPv6 address aggregate that has been reserved for their "big" customers. A customer is considered a "big" customer if it has a very complex network infrastructure and/or huge IPv6 address needs (e.g., because of very large customer numbers) and/or several uplinks to different POPs of the SP network.
SP的“大”客户从为其“大”客户保留的/24 IPv6地址聚合接收其前缀。如果客户具有非常复杂的网络基础设施和/或巨大的IPv6地址需求（例如，由于客户数量非常大）和/或多个到SP网络不同POP的上行链路，则该客户被视为“大”客户。
The assigned IPv6 address prefixes can have a prefix length in the range 32-48 and for each assignment a 100 or 300% future growing zone is marked as "reserved" for this customer. For instance, this means that with a delegation of a /34 to a customer the corresponding /32 prefix (which contains this /34) is reserved for the customer's future usage.
分配的IPv6地址前缀的前缀长度可以在32-48范围内，并且对于每个分配，将100%或300%的未来增长区域标记为该客户的“保留”。例如，这意味着将a/34委托给客户时，相应的/32前缀（包含此/34）将保留供客户将来使用。
The prefixes for the "big" customers can be chosen from the corresponding "big customer" pool by either using an equidistant algorithm or using mechanisms similar to the Sparse Allocation Algorithm (SAA) [RIPE_Nov07].
“大”客户的前缀可以通过使用等距算法或使用类似于稀疏分配算法（SAA）的机制从相应的“大客户”池中选择[RIME_Nov07]。
All customers that are not "big" customers are considered as "common" customers. They represent the majority of customers, hence they receive a /48 out of the IPv6 customer address pool of the LER where they are directly connected or aggregated.
所有不是“大”客户的客户都被视为“普通”客户。他们代表大多数客户，因此他们从直接连接或聚合的LER的IPv6客户地址池中接收a/48。
Again a 100-300% future growing IPv6 address range is reserved for each customer, so that a "common" customer receives a /48 allocation but has a /47 or /46 reserved.
同样，为每个客户保留100-300%的未来增长IPv6地址范围，以便“普通”客户接收/48分配，但保留/47或/46。
(Note: If it is obvious that the likelihood of needing a /47 or /46 in the future is very small for a "common" customer, then no growing buffer should be reserved for it, and only a /48 will be assigned without any growing buffer.)
（注意：如果很明显，对于“普通”客户来说，未来需要a/47或a/46的可能性非常小，则不应为其保留增长缓冲区，并且只分配a/48，而不分配任何增长缓冲区。）
In the network access scenarios where the customer is directly connected to the LER, the customer prefix is directly taken out of the customer IPv6 address aggregate (e.g., /38) of the corresponding LER.
在客户直接连接到LER的网络访问场景中，客户前缀直接从相应LER的客户IPv6地址聚合（例如，/38）中取出。
For other cases (e.g., the customer is attached to a RAR that is itself aggregated to an AG or to a LER-BB), at least 2 different approaches are possible.
对于其他情况（例如，客户附加到自身聚合到AG或LER-BB的RAR），至少有两种不同的方法是可能的。
1) Mapping of Aggregation Network Hierarchy into Customer IPv6 Addressing Schema. The aggregation network hierarchy could be mapped into the design of the customer prefix pools of each network level in order to achieve a maximal aggregation at the LER level as well as at the intermediate levels. (Example: Customer - /48, RAR - /38, AG - /32, LER-BB - /30). At each network level, an adequate growing zone should be reserved. (Note: Of course, this approach requires some "fine tuning" of the addressing schema based on a very good knowledge of the Service Provider network topology including actual growing ranges and rates.)
1) 将聚合网络层次结构映射到客户IPv6寻址模式。聚合网络层次结构可以映射到每个网络级别的客户前缀池的设计中，以便在LER级别和中间级别实现最大聚合。（例如：客户-/48、RAR-/38、AG-/32、LER-BB-/30）。在每个网络级别，应保留足够的增长区。（注意：当然，这种方法需要对寻址模式进行一些“微调”，这是基于对服务提供商网络拓扑（包括实际增长范围和速率）的非常好的了解。）
When the IPv6 customer address pool of a LER (or another device of the aggregation network -- AG or RAR) is exhausted, the related LER (or AG or RAR) prefix is shortened by 1 or 2 bits (e.g., from /38 to /37 or /36) so that the originally reserved growing zone can be used for further IPv6 address allocations to
当LER（或聚合网络的另一个设备——AG或RAR）的IPv6客户地址池耗尽时，相关的LER（或AG或RAR）前缀缩短1或2位（例如，从/38缩短到/37或/36），以便最初保留的增长区域可用于进一步的IPv6地址分配
customers. In the case where this growing zone is exhausted as well, a new prefix range from the corresponding pool of the next-higher hierarchy level can be requested.
客户。在这个增长区域也耗尽的情况下，可以从下一个更高层次的对应池请求一个新的前缀范围。
2) "Flat" Customer IPv6 Addressing Schema. The other option is to allocate all the customer prefixes directly out of the customer IPv6 address pool of the LER where the customers are attached and aggregated and to ignore the intermediate aggregation network infrastructure. Of course, this approach leads to a higher amount of customer routes at the LER and aggregation network level, but it takes a great amount of complexity out of the addressing schema. Nevertheless, the aggregation of the customer prefixes to one prefix at the LER level is realized as required above.
2) “平面”客户IPv6寻址模式。另一个选项是直接从连接和聚合客户的LER的客户IPv6地址池中分配所有客户前缀，并忽略中间聚合网络基础设施。当然，这种方法会在LER和聚合网络级别上产生更多的客户路由，但它会使寻址模式变得非常复杂。然而，按照上述要求，在LER级别将客户前缀聚合为一个前缀。
Note: The handling of changes (e.g., technically triggered changes) within the ISP access network is discussed briefly in Appendix A.2.3.5.
注：附录A.2.3.5简要讨论了ISP接入网络内变更（如技术触发变更）的处理。
If the actual observed growing rates show that the reserved growing zones are not needed, then they can be freed and used for assignments for prefix pools to other devices at the same level of the network hierarchy.
如果实际观察到的增长率表明不需要保留的增长区域，则可以释放这些区域，并将其用于将前缀池分配给网络层次结构相同级别的其他设备。
A.2.2.2. Defining an IPv6 Address Allocation Plan for the Service Provider Network Infrastructure
A.2.2.2. 为服务提供商网络基础结构定义IPv6地址分配计划
For the IPv6 addressing of the SP's own network infrastructure, a /32 (or /40) from the "big" customers address pool can be chosen.
对于SP自身网络基础设施的IPv6寻址，可以选择“大”客户地址池中的/32（或/40）。
This SP infrastructure prefix is used to code the network infrastructure of the SP by assigning a /48 to every POP/location and using (for instance) a /56 for coding the corresponding router within this POP. Each SP internal link behind a router interface could be coded using a /64 prefix. (Note: While it is suggested to choose a /48 for addressing the POP/location of the SP network, it is left to each SP to decide what prefix length to assign to the routers and links within the POP.)
此SP infrastructure前缀用于对SP的网络基础设施进行编码，方法是将a/48分配给每个POP/位置，并使用（例如）a/56对该POP内的相应路由器进行编码。路由器接口后面的每个SP内部链路都可以使用/64前缀进行编码。（注意：虽然建议选择a/48来寻址SP网络的POP/位置，但由每个SP决定分配给POP内路由器和链路的前缀长度。）
The IIDs of the router interfaces may be generated by using EUI-64 or through plain manual configuration, e.g., for coding additional network or operational information into the IID.
路由器接口的IID可通过使用EUI-64或通过普通手动配置生成，例如，用于将附加网络或操作信息编码到IID中。
Again, it is assumed that 100-300% growing zones are needed for each level of network hierarchy, and additional prefix bits may be assigned to POPs and/or routers if needed.
同样，假设每一级网络层次结构都需要100-300%的增长区域，并且如果需要，可以向POP和/或路由器分配额外的前缀位。
Loopback interfaces of routers may be chosen from the first /64 of the /56 router prefix (in the example above).
路由器的环回接口可以从/56路由器前缀的第一/64中选择（在上面的示例中）。
(Note: The /32 (or /40) prefix that has been chosen for addressing the SP's own IPv6 network infrastructure leaves enough space to code additional functionalities like security levels or private and test infrastructure, although such approaches haven't been considered in more detail for the above-described SP until now.)
（注意：为解决SP自己的IPv6网络基础设施而选择的/32（或/40）前缀留出了足够的空间来编码其他功能，如安全级别或专用和测试基础设施，尽管到目前为止，尚未对上述SP详细考虑此类方法。）
Point-to-point links to customers (e.g., PPP links, dedicated lines, etc.) may be addressed using /126 prefixes out of the first /64 of the access routers that could be reserved for this reason.
到客户的点对点链路（例如，PPP链路、专用线路等）可以使用第一个/64个接入路由器中的/126前缀进行寻址，这些路由器可能因此而保留。
There are no compelling reasons for service providers to use ULAs. See Section 2.2.
服务提供商没有令人信服的理由使用ULA。见第2.2节。
ULAs could be used inside the SP network in order to have an additional "site-local scoped" IPv6 address for the SP's own infrastructure, for instance, for network management reasons and in order to have an addressing schema that can't be reached from outside the SP network.
可以在SP网络内部使用ULA，以便为SP自身的基础设施提供额外的“站点本地范围”IPv6地址，例如，出于网络管理原因，以及为了拥有无法从SP网络外部访问的寻址模式。
When ULAs are used, it is possible to map the proposed internal IPv6 addressing of the SP's own network infrastructure (as described in Appendix A.2.2.2) directly to the ULA addressing schema by substituting the /48 POP prefix with a /48 ULA site prefix.
使用ULA时，可以通过将/48 POP前缀替换为/48 ULA站点前缀，将SP自己的网络基础设施（如附录A.2.2.2所述）的拟议内部IPv6寻址直接映射到ULA寻址模式。
IPv6 multicast-related addressing issues are out of the scope of this document.
与IPv6多播相关的寻址问题超出了本文档的范围。
POP multihoming (or better, LER multihoming) of customers with the same SP can be realized within the proposed IPv6 addressing schema of the SP by assigning multiple LER-dependent prefixes to this customer (i.e., considering each customer location as a single customer) or by choosing a customer prefix out of the pool of "big" customers. The second solution has the disadvantage that in every LER where the customer is attached, this prefix will appear inside the IGP routing table, thus requiring an explicit MPLS label.
通过将多个LER相关前缀分配给该客户（即，将每个客户位置视为单个客户），或从“大”客户池中选择一个客户前缀，可以在SP的拟议IPv6寻址模式内实现具有相同SP的客户的POP多主（或更好的LER多主）。第二种解决方案的缺点是，在连接客户的每个LER中，该前缀将出现在IGP路由表中，因此需要明确的MPLS标签。
Note: The negative effects (described above) of POP/LER multihoming on the addressing architecture in the SP access network are not resolved by implementing the Site Multihoming by IPv6 Intermediation (SHIM6) approach. SHIM6 only targets a mechanism for dealing with multiple prefixes in end systems. The SP is expected to have unaggregated customer prefixes in its internal routing tables.
注：POP/LER多宿对SP接入网寻址体系结构的负面影响（如上所述）无法通过实施IPv6中介的站点多宿（SHIM6）方法来解决。SHIM6只针对在终端系统中处理多个前缀的机制。SP的内部路由表中应包含未聚合的客户前缀。
In the possible case that a customer has to change its point of network attachment to another POP/LER within the ISP access network, two different approaches can be applied, assuming that the customer uses PA addresses out of the SP aggregate:
在可能的情况下，客户必须将其网络连接点更改为ISP接入网络内的另一个POP/LER，假设客户使用SP聚合之外的PA地址，则可以采用两种不同的方法：
1) The customer has to renumber its network with an adequate customer prefix out of the aggregate of the corresponding LER/RAR of its new network attachment. To minimize the administrative burden for the customer, the prefix should be of the same size as the former. This conserves the IPv6 address aggregation within the SP network (and the MPLS label space) but adds additional burden to the customer. Hence, this approach will most likely only be chosen in the case of "small customers" with temporary addressing needs and/or prefix delegation with address autoconfiguration.
1) 客户必须从其新网络附件的相应LER/RAR集合中，使用适当的客户前缀对其网络重新编号。为了最大限度地减少客户的管理负担，前缀的大小应与前者相同。这在SP网络（和MPLS标签空间）中保留了IPv6地址聚合，但给客户增加了额外负担。因此，这种方法很可能仅在“小客户”具有临时寻址需求和/或具有地址自动配置的前缀委托的情况下选择。
2) The customer does not need to renumber its network and keeps its address aggregate.
2) 客户不需要重新编号其网络，并保持其地址聚合。
This approach leads to additional more-specific routing entries within the IGP routing table of the LER and will hence consume additional MPLS labels, but it is totally transparent to the customer. Because this results in additional administrative effort and will stress the router resources (label space, memory) of the ISP, this solution will only be offered to the most valuable customers of an ISP (e.g., "big customers" or "enterprise customers").
这种方法会在LER的IGP路由表中产生额外的更具体的路由条目，因此会消耗额外的MPLS标签，但对客户来说是完全透明的。由于这将导致额外的管理工作，并将强调ISP的路由器资源（标签空间、内存），因此此解决方案将仅提供给ISP最有价值的客户（例如，“大客户”或“企业客户”）。
Nevertheless, the ISP again has to find a fair trade-off between customer renumbering and sub-optimal address aggregation (i.e., the generation of additional more-specific routing entries within the IGP and the waste of MPLS label space).
尽管如此，ISP仍然必须在客户重新编号和次优地址聚合（即，在IGP内生成更多更具体的路由条目和浪费MPLS标签空间）之间找到一个公平的权衡。
A technically triggered restructuring of the SP (access) network (for instance, because of split of equipment or installation of new equipment) should not lead to a customer network renumbering. This challenge should be handled in advance by an intelligent network design and IPv6 address planning.
SP（接入）网络的技术触发重组（例如，由于设备拆分或安装新设备）不应导致客户网络重新编号。应通过智能网络设计和IPv6地址规划提前应对这一挑战。
In the worst case, the customer network renumbering could be avoided through the implementation of more-specific customer routes. (Note: Since this kind of network restructuring will mostly happen within the access network (at the level) below the LER, the LER aggregation level will not be harmed and the more-specific routes will not consume additional MPLS label space.)
在最坏的情况下，可以通过实施更具体的客户路线来避免客户网络重新编号。（注意：由于此类网络重组大多发生在LER以下的接入网络（在级别）内，因此不会损害LER聚合级别，更具体的路由也不会消耗额外的MPLS标签空间。）
The proposed IPv6 addressing schema for an SP needs some slight enhancements / modifications for the later phases of IPv6 integration, for instance, when the whole MPLS backbone infrastructure (LDP, IGP, etc.) is realized over IPv6 transport, and an IPv6 addressing of the LSRs is needed. Other changes may be necessary as well but should not be explained at this point.
在IPv6集成的后期阶段，SP的拟议IPv6寻址模式需要一些轻微的增强/修改，例如，当整个MPLS主干基础设施（LDP、IGP等）通过IPv6传输实现时，需要LSR的IPv6寻址。也可能需要进行其他更改，但此时不应进行解释。
Appendix B. Considerations for Subnet Prefixes Different than /64
附录B.不同于/64的子网前缀的注意事项
An allocation of a prefix shorter then 64 bits to a node or interface is considered bad practice. One exception to this statement is when using 6to4 technology where a /16 prefix is utilized for the pseudo-interface [RFC3056]. The shortest subnet prefix that could theoretically be assigned to an interface or node is limited by the size of the network prefix allocated to the organization.
将短于64位的前缀分配给节点或接口被认为是不好的做法。此语句的一个例外是使用6to4技术时，伪接口[RFC3056]使用了/16前缀。理论上可以分配给接口或节点的最短子网前缀受到分配给组织的网络前缀大小的限制。
A possible reason for choosing the subnet prefix for an interface shorter than /64 is that it would allow more nodes to be attached to that interface compared to a prescribed length of 64 bits. The prescribed /64 does include 2 functional bits, the 'g' bit and the inverted 'u' (universal/local) bit and these can not be chosen at will. However, a larger address space then a /64 is unnecessary for most networks, considering that 2^62 provides plenty of node addresses.
为小于/64的接口选择子网前缀的一个可能原因是，与规定的64位长度相比，它将允许更多节点连接到该接口。规定的/64包含2个功能位，“g”位和倒“u”（通用/本地）位，不能随意选择。但是，考虑到2^62提供了大量节点地址，大多数网络不需要比a/64更大的地址空间。
The subnet prefix assignments can be made by manual configuration, by a stateful Host Configuration Protocol [RFC3315], by a stateful prefix delegation mechanism [RFC3633], or implied by stateless autoconfiguration from prefix Router Advertisements (RAs).
子网前缀分配可以通过手动配置、有状态主机配置协议[RFC3315]、有状态前缀委派机制[RFC3633]或前缀路由器播发（RAs）的无状态自动配置进行。
The following subsections describe subnet prefix values that should be avoided in deployments because nodes who assume that the subnet prefix is /64 could treat them incorrectly.
以下小节介绍了在部署中应避免的子网前缀值，因为假定子网前缀为/64的节点可能会错误地处理这些值。
126-bit subnet prefixes are typically used for point-to-point links similar to a the IPv4 address-conservative /30 allocation for point-to-point links. The usage of this subnet address length does not lead to any considerations beyond those discussed earlier in this section, particularly those related to the 'u' and 'g' bits (see B.2.4.
126位子网前缀通常用于点到点链路，类似于点到点链路的IPv4地址/30分配。除本节前面讨论的内容外，使用此子网地址长度不会引起任何考虑，尤其是与“u”和“g”位相关的考虑（见B.2.4）。
The usage of the /127 addresses, the equivalent of IPv4's RFC 3021 [RFC3021], is not valid and should be strongly discouraged as documented in RFC 3627 [RFC3627].
与IPv4的RFC 3021[RFC3021]等效的/127地址的使用无效，如RFC 3627[RFC3627]中所述，应强烈反对使用。
The 128-bit address prefix may be used in those situations where we know that one, and only one, address is sufficient. Example usage would be the off-link loopback address of a network device.
128位地址前缀可用于我们知道只有一个地址就足够的情况。例如，使用网络设备的断开链路环回地址。
When choosing a 128 bit prefix, it is recommended to take the 'u' and 'g' bits into consideration and to make sure that there is no overlap with any of the following well-known addresses:
选择128位前缀时，建议考虑“u”和“g”位，并确保与以下任何已知地址没有重叠：
o Subnet Router Anycast Address
o 子网路由器选播地址
o Reserved Subnet Anycast Address
o 保留子网选播地址
o Addresses used by Embedded-RP
o 嵌入式RP使用的地址
o ISATAP Addresses
o ISATAP地址
When using subnet prefix lengths other than /64, the interface identifier cannot be in Modified EUI-64 format as required by [RFC4291]. However, nodes not aware that a prefix length other than /64 is used might still think it's an EUI-64; therefore, it's prudent to take into account the following points when setting the bits.
当使用除/64以外的子网前缀长度时，接口标识符不能采用[RFC4291]要求的修改过的EUI-64格式。然而，不知道使用了/64以外的前缀长度的节点可能仍然认为它是EUI-64；因此，在设置位时，谨慎地考虑以下几点。
Address space conservation is the main motivation for using a subnet prefix length longer than 64 bits; however, this kind of address conservation is of little benefit compared with the additional considerations one must make when creating and maintaining an IPv6 addressing plan.
节省地址空间是使用长度超过64位的子网前缀的主要动机；然而，与创建和维护IPv6寻址计划时必须考虑的其他因素相比，这种地址保护没有什么好处。
The address assignment can be made either by manual configuration or by a stateful Host Configuration Protocol [RFC3315].
地址分配可以通过手动配置或有状态主机配置协议[RFC3315]进行。
When assigning a subnet prefix of more then 70 bits, according to RFC 4291 [RFC4291], 'u' and 'g' bits (the 71st and 72nd bit, respectively) need to be taken into consideration and should be set correctly.
当分配超过70位的子网前缀时，根据RFC 4291[RFC4291]，需要考虑“u”和“g”位（分别为第71位和第72位），并应正确设置。
The 71st bit of a IPv6 address is the inverted 'u' (universal/local) bit and is used to determine whether the address is universally or locally administered. If 1, the IEEE, through the designation of a unique company ID, has administered the address. If 0, the address is locally administered. The network administrator has overridden the manufactured address and specified a different address.
IPv6地址的第71位是倒“u”（通用/本地）位，用于确定该地址是通用还是本地管理的。如果为1，则IEEE通过指定唯一的公司ID管理地址。如果为0，则该地址是本地管理的。网络管理员已覆盖制造的地址并指定了其他地址。
The 'g' (the individual/group) bit is the 72nd bit and is used to determine whether the address is an individual address (unicast) or a group address (multicast). If '0', the address is a unicast address. If '1', the address is a multicast address.
“g”（单个/组）位是第72位，用于确定地址是单个地址（单播）还是组地址（多播）。如果为“0”，则该地址为单播地址。如果为“1”，则该地址为多播地址。
In current IPv6 protocol stacks, the relevance of the 'u' and 'g' bits is marginal and typically will not give an error when configured wrongly; however, future implementations may turn out differently if they process the 'u' and 'g' bits in IEEE-like behavior.
在当前的IPv6协议栈中，“u”和“g”位的相关性很小，通常在配置错误时不会出现错误；但是，如果将来的实现以类似IEEE的方式处理“u”和“g”位，结果可能会有所不同。
When using subnet lengths longer then 64 bits, it is important to avoid selecting addresses that may have a predefined use and could confuse IPv6 protocol stacks. The alternate usage may not be a simple unicast address in all cases. The following points should be considered when selecting a subnet length longer then 64 bits.
当使用长于64位的子网长度时，避免选择可能具有预定义用途且可能混淆IPv6协议栈的地址非常重要。在所有情况下，替代用法可能不是简单的单播地址。选择长于64位的子网长度时，应考虑以下几点。
RFC 4291 [RFC4291] provides a definition for the required Subnet Router Anycast Address as follows:
RFC 4291[RFC4291]为所需的子网路由器选播地址提供定义，如下所示：
| n bits | 128-n bits |
+--------------------------------------------+----------------+
| subnet prefix | 00000000000000 |
+--------------------------------------------+----------------+
| n bits | 128-n bits |
+--------------------------------------------+----------------+
| subnet prefix | 00000000000000 |
+--------------------------------------------+----------------+
It is recommended to avoid allocating this IPv6 address to a device that expects to have a normal unicast address.
建议避免将此IPv6地址分配给预期具有正常单播地址的设备。
RFC 2526 [RFC2526] stated that within each subnet, the highest 128 interface identifier values are reserved for assignment as subnet anycast addresses.
RFC 2526[RFC2526]指出，在每个子网内，保留最高的128个接口标识符值作为子网选播地址进行分配。
The construction of a reserved subnet anycast address depends on the type of IPv6 addresses used within the subnet, as indicated by the format prefix in the addresses.
保留子网选播地址的构造取决于子网内使用的IPv6地址类型，如地址中的格式前缀所示。
The first type of Subnet Anycast addresses have been defined as follows for the Modified EUI-64 format:
对于修改后的EUI-64格式，第一类子网选播地址定义如下：
| 64 bits | 57 bits | 7 bits |
+------------------------------+------------------+------------+
| subnet prefix | 1111110111...111 | anycast ID |
+------------------------------+------------------+------------+
| 64 bits | 57 bits | 7 bits |
+------------------------------+------------------+------------+
| subnet prefix | 1111110111...111 | anycast ID |
+------------------------------+------------------+------------+
The anycast address structure implies that it is important to avoid creating a subnet prefix where the bits 65 to 121 are defined as "1111110111...111" (57 bits in total) in order to prevent confusion.
选播地址结构意味着重要的是避免创建子网前缀，其中位65至121定义为“111111 0111…111”（总共57位），以防止混淆。
For other IPv6 address types (that is, with format prefixes other than those listed above), the interface identifier is not in 64-bit extended unique identifier (EUI-64) format and may not be 64 bits in length. The reserved subnet anycast addresses for such address types are constructed as follows:
对于其他IPv6地址类型（即，格式前缀不是上面列出的前缀），接口标识符不是64位扩展唯一标识符（EUI-64）格式，并且长度可能不是64位。此类地址类型的保留子网选播地址构造如下：
| n bits | 121-n bits | 7 bits |
+------------------------------+------------------+------------+
| subnet prefix | 1111111...111111 | anycast ID |
+------------------------------+------------------+------------+
| interface identifier field |
| n bits | 121-n bits | 7 bits |
+------------------------------+------------------+------------+
| subnet prefix | 1111111...111111 | anycast ID |
+------------------------------+------------------+------------+
| interface identifier field |
It is recommended to avoid allocating this IPv6 address to a device that expects to have a normal unicast address.
建议避免将此IPv6地址分配给预期具有正常单播地址的设备。
Embedded-RP [RFC3956] reflects the concept of integrating the Rendezvous Point (RP) IPv6 address into the IPv6 multicast group address. Due to this embedding and the fact that the length of the IPv6 address AND the IPv6 multicast address are 128 bits, it is not possible to have the complete IPv6 address of the multicast RP embedded as such.
嵌入式RP[RFC3956]反映了将集合点（RP）IPv6地址集成到IPv6多播组地址的概念。由于这种嵌入以及IPv6地址和IPv6多播地址的长度为128位的事实，因此不可能将多播RP的完整IPv6地址作为这样的嵌入。
This results in a restriction of 15 possible RP-addresses per prefix that can be used with embedded-RP. The space assigned for the embedded-RP is based on the 4 low-order bits, while the remainder of the Rendezvous Interface ID (RIID) is set to all '0'. The format of the IPv6 multicast group address used by embedded-RP is as follows:
这导致每个前缀可与嵌入式RP一起使用的RP地址限制为15个。为嵌入式RP分配的空间基于4个低阶位，而交会接口ID（RIID）的其余部分设置为所有“0”。嵌入式RP使用的IPv6多播组地址格式如下：
(IPv6-prefix (64 bits))(60 bits all '0')(RIID)
（IPv6前缀（64位））（60位全部为“0”）（RIID）
where: (RIID) = 4 bits.
其中：（RIID）=4位。
This format implies that when selecting subnet prefixes longer than 64, and when the bits beyond the 64th bit are non-zero, the subnet cannot use embedded-RP.
此格式意味着，当选择长于64的子网前缀时，并且当第64位以外的位为非零时，子网不能使用embedded-RP。
In addition, it is discouraged to assign a matching embedded-RP IPv6 address to a device that is not a real Multicast Rendezvous Point, even though it would not generate major problems.
此外，不鼓励将匹配的嵌入式RP IPv6地址分配给不是真正的多播集合点的设备，即使这不会产生重大问题。
ISATAP [RFC5214] is an experimental automatic tunneling protocol used to provide IPv6 connectivity over an IPv4 campus or enterprise environment. In order to leverage the underlying IPv4 infrastructure, the IPv6 addresses are constructed in a special format.
ISATAP[RFC5214]是一种实验性的自动隧道协议，用于通过IPv4园区或企业环境提供IPv6连接。为了利用底层IPv4基础设施，IPv6地址以特殊格式构造。
An IPv6 ISATAP address has the IPv4 address embedded, based on a predefined structure policy that identifies them as an ISATAP address. The format is as follows:
IPv6 ISATAP地址基于将其标识为ISATAP地址的预定义结构策略，嵌入了IPv4地址。格式如下:
[IPv6 Prefix (64 bits)][0000:5EFE][IPv4 address]
[IPv6前缀（64位）][0000:5EFE][IPv4地址]
When using a subnet prefix length longer then 64 bits, it is good engineering practice to ensure that the portion of the IPv6 prefix from bit 65 to the end of the host-ID does not match with the well-known ISATAP [0000:5EFE] address when assigning an IPv6 address to a non-ISATAP interface.
当使用长度超过64位的子网前缀时，良好的工程实践是，在将IPv6地址分配给非ISATAP接口时，确保从位65到主机ID末尾的IPv6前缀部分与众所周知的ISATAP[0000:5EFE]地址不匹配。
Note that the definition of ISATAP does not support multicast.
请注意，ISATAP的定义不支持多播。
Authors' Addresses
作者地址
Gunter Van de Velde Cisco Systems De Kleetlaan 6a Diegem 1831 Belgium Phone: +32 2704 5473 EMail: gunter@cisco.com
Gunter Van de Velde Cisco Systems de Kleetlaan 6a Diegem 1831比利时电话：+32 2704 5473电子邮件：gunter@cisco.com
Ciprian Popoviciu Cisco Systems 7025-6 Kit Creek Road Research Triangle Park, North Carolina USA EMail: cpopovic@cisco.com
Ciprian Popoviciu Cisco Systems 7025-6 Kit Creek Road Research Triangle Park，美国北卡罗来纳州电子邮件：cpopovic@cisco.com
Tim Chown University of Southampton Highfield Southampton SO17 1BJ United Kingdom Phone: +44 23 8059 3257 EMail: tjc@ecs.soton.ac.uk
提姆Chann南安普敦大学菲尔德南安普顿SO171BJ英国电话：+ 44 23 8059 8059电子邮件：tjc@ecs.soton.ac.uk
T-Systems Enterprise Services GmbH Goslarer Ufer 35 Berlin 10589 Germany Phone: +49 30 3497 3124 EMail: Olaf.Bonness@t-systems.com
T-Systems企业服务有限公司戈斯拉尔Ufer 35柏林10589德国电话：+49 30 3497 3124电子邮件：Olaf。Bonness@t-系统网
Christian Hahn T-Systems Enterprise Services GmbH Goslarer Ufer 35 Berlin 10589 Germany Phone: +49 30 3497 3164 EMail: HahnC@t-systems.com
Christian Hahn T-Systems企业服务有限公司Goslarer Ufer 35柏林10589德国电话：+49 30 3497 3164电子邮件：HahnC@t-系统网